lkml.org 
[lkml]   [2017]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4][PoC][RFC] Allow to trace fd usage with rlimit-events
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.

\
 
 \ /
  Last update: 2017-10-22 17:19    [W:0.141 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site