From: Krzysztof Opasiak <k.opasiak@samsung.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: gregkh@linuxfoundation.org, arnd@arndb.de,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-arch@vger.kernel.org, k.lewandowsk@samsung.com,
l.stelmach@samsung.com, p.szewczyk@samsung.com,
b.zolnierkie@samsung.com, andrzej.p@samsung.com,
kopasiak90@gmail.com
Subject: Re: [PATCH 4/4][PoC][RFC] Allow to trace fd usage with rlimit-events
Date: Thu, 19 Oct 2017 19:28:21 +0200 [thread overview]
Message-ID: <e9dd8610-abb3-2247-666d-e12fd656c2d6@samsung.com> (raw)
In-Reply-To: <20171018230521.GP21978@ZenIV.linux.org.uk>
Hi,
On 10/19/2017 01:05 AM, Al Viro wrote:
> On Wed, Oct 18, 2017 at 10:32:30PM +0200, Krzysztof Opasiak wrote:
>
>> @@ -417,7 +417,7 @@ static int task_get_unused_fd_flags(struct binder_proc *proc, int flags)
>> rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE);
>> unlock_task_sighand(proc->tsk, &irqs);
>>
>> - return __alloc_fd(files, 0, rlim_cur, flags);
>> + return __alloc_fd(proc->tsk, 0, rlim_cur, flags);
>
> Who said that proc->files will remain equal to proc->tsk->files?
>
>> -static void __put_unused_fd(struct files_struct *files, unsigned int fd)
>> +static void __put_unused_fd(struct task_struct *owner, unsigned int fd)
>> {
>> + struct files_struct *files = owner->files;
>> struct fdtable *fdt = files_fdtable(files);
>> __clear_open_fd(fd, fdt);
>> if (fd < files->next_fd)
>> files->next_fd = fd;
>> +
>> + if (rlimit_noti_watch_active(owner, RLIMIT_NOFILE)) {
>> + unsigned int count;
>> +
>> + count = count_open_fds(fdt);
>> + rlimit_noti_res_changed(owner, RLIMIT_NOFILE, count + 1, count);
>> + }
>> }
>
> [... and similar for other __...fd() primitives]
> This is blatantly wrong - you *CAN'T* modify files_struct unless it's
> a) yours (i.e. current->files) or
> b) you've had its refcount incremented for you by some process that
> did, at the time, have current->files pointing to it.
>
> There is a reason why binder keeps ->files explicitly, rather than going through
> ->tsk->files.
Your are perfectly right! Thank you very much for catching this.
To be honest, initially I just added the struct task_struct ptr to the
argument list keeping that in mind. Then when I was cleaning up patches
before sending I found this to look a litlle bit odd and forgot that I
did this on purpose because tsk->files can be reassigned and that's why
I removed the files param.
I'll fix this for v2. Thanks once again.
Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
prev parent reply other threads:[~2017-10-19 17:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20171018203324epcas2p310def24eea6171d0821f1068d055d3b7@epcas2p3.samsung.com>
2017-10-18 20:32 ` [PATCH 0/4][PoC][RFC] Add rlimit-resources change notification mechanism Krzysztof Opasiak
[not found] ` <CGME20171018203328epcas2p4bdcc3650d1c0f0add143488792243932@epcas2p4.samsung.com>
2017-10-18 20:32 ` [PATCH 1/4][PoC][RFC] sched: Allow to get() and put() signal struct Krzysztof Opasiak
2017-10-19 7:34 ` Greg KH
2017-10-19 17:33 ` Krzysztof Opasiak
[not found] ` <CGME20171018203333epcas1p3d8dd8f3a755cb6ee8e9dde63cb91851b@epcas1p3.samsung.com>
2017-10-18 20:32 ` [PATCH 2/4][PoC][RFC] Add rlimit-events framework Krzysztof Opasiak
2017-10-19 7:41 ` Greg KH
2017-10-19 18:17 ` Krzysztof Opasiak
[not found] ` <CGME20171018203337epcas2p22bc3a5ac063486c9c7906fe6e88277bb@epcas2p2.samsung.com>
2017-10-18 20:32 ` [PATCH 3/4][PoC][RFC] Connect rlimit-events with process life cycle Krzysztof Opasiak
2017-10-19 7:41 ` Greg KH
2017-10-19 18:19 ` Krzysztof Opasiak
[not found] ` <CGME20171018203342epcas1p23933a20a33807f92c716433374374397@epcas1p2.samsung.com>
2017-10-18 20:32 ` [PATCH 4/4][PoC][RFC] Allow to trace fd usage with rlimit-events Krzysztof Opasiak
2017-10-18 23:05 ` Al Viro
2017-10-19 17:28 ` Krzysztof Opasiak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e9dd8610-abb3-2247-666d-e12fd656c2d6@samsung.com \
--to=k.opasiak@samsung.com \
--cc=andrzej.p@samsung.com \
--cc=arnd@arndb.de \
--cc=b.zolnierkie@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=k.lewandowsk@samsung.com \
--cc=kopasiak90@gmail.com \
--cc=l.stelmach@samsung.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.szewczyk@samsung.com \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®