From: ebiederm@xmission.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@redhat.com>
Cc: Jeff Layton <jlayton@kernel.org>,
viro@zeniv.linux.org.uk, berrange@redhat.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 1/3] exec: separate thread_count for files_struct
Date: Mon, 17 Sep 2018 22:45:09 +0200 [thread overview]
Message-ID: <87d0tbn99m.fsf@xmission.com> (raw)
In-Reply-To: <20180917152424.GA25173@redhat.com> (Oleg Nesterov's message of "Mon, 17 Sep 2018 17:24:24 +0200")
Oleg Nesterov <oleg@redhat.com> writes:
> On 09/16, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <oleg@redhat.com> writes:
>>
>> > As for binder.c, in this case we probably actually want to unshare ->files
>> > on exec so we can ignore it?
>>
>> Looking at the binder case it only captures ->files on mmap. Exec
>> ditches the mmap. So if the order of operations are correct than
>> the dropping of the old mm will also drop the count on files_struct
>> held by binder.
>>
>> So semantically binder should not effect locks on exec,
>
> Agreed, but it does.
>
> Before your "[PATCH 0/3] exec: Moving unshare_files_struct" unshare_files()
> is called before exec_mmap().
>
> And even with this series we can have another CLONE_VM process.
>
> Howver, I think this doesn't really matter. binder does __fd_install(files),
> so if it actually has a reference to execing_task->files, I think it should
> be unshared anyway.
>
>> In short as long as we get the oder of operations correct we should be
>> able to safely ignore binder, and not have binder affect the results of
>> this code.
>
> Agreed.
I may have spoken too soon. Binder uses schedule_work to call
put_files_struct from munmap. So the files->count may still be elevated
after the mm is put. Ick.
Eric
next prev parent reply other threads:[~2018-09-17 20:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 10:53 [PATCH v3 0/3] exec: fix passing of file locks across execve in multithreaded processes Jeff Layton
2018-09-14 10:53 ` [PATCH v3 1/3] exec: separate thread_count for files_struct Jeff Layton
2018-09-15 16:04 ` Oleg Nesterov
2018-09-16 16:10 ` Eric W. Biederman
2018-09-17 15:24 ` Oleg Nesterov
2018-09-17 20:45 ` Eric W. Biederman [this message]
2018-09-14 10:53 ` [PATCH v3 2/3] exec: delay clone(CLONE_FILES) if task associated with current files_struct is exec'ing Jeff Layton
2018-09-14 10:53 ` [PATCH v3 3/3] exec: do unshare_files after de_thread Jeff Layton
2018-09-15 16:37 ` Oleg Nesterov
2018-09-16 16:49 ` Eric W. Biederman
2018-09-17 15:28 ` Oleg Nesterov
2018-09-16 16:59 ` Eric W. Biederman
2018-09-16 17:38 ` [RFC][PATCH 0/3] exec: Moving unshare_files_struct Eric W. Biederman
2018-09-16 17:39 ` [RFC][PATCH 1/3] exec: Move unshare_files down to avoid locks being dropped on exec Eric W. Biederman
2018-09-17 15:49 ` Oleg Nesterov
2018-09-16 17:40 ` [RFC][PATCH 2/3] exec: Simplify unshare_files Eric W. Biederman
2018-09-17 16:23 ` Oleg Nesterov
2018-09-17 20:26 ` Eric W. Biederman
2018-09-16 17:41 ` [RFC][PATCH 3/3] exec: Remove reset_files_struct Eric W. Biederman
2018-09-17 15:59 ` [RFC][PATCH 0/3] exec: Moving unshare_files_struct Oleg Nesterov
2018-09-18 22:18 ` Eric W. Biederman
2018-09-17 16:24 ` Jeff Layton
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=87d0tbn99m.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=berrange@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.