From: ebiederm@xmission.com (Eric W. Biederman)
To: Hugh Dickins <hughd@google.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH 2/2] sysfs: only access bin file vm_ops with the active lock
Date: Wed, 22 Sep 2010 14:59:15 -0700 [thread overview]
Message-ID: <m1zkv9v3rg.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <alpine.LSU.2.00.1009221231251.29127@tigran.mtv.corp.google.com> (Hugh Dickins's message of "Wed, 22 Sep 2010 12:49:51 -0700 (PDT)")
Hugh Dickins <hughd@google.com> writes:
> On Mon, 20 Sep 2010, Eric W. Biederman wrote:
>>
>> bb->vm_ops is a cached copy of the vm_ops of the underlying
>> sysfs bin file, which means that after sysfs_bin_remove_file
>> completes it is only longer valid to deference bb->vm_ops.
>>
>> So move all of the tests of bb->vm_ops inside of where
>> we hold the sysfs active lock.
>>
>> Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
>
> Good point. There's a couple of cases (the ones below) where you've
> changed the return value from success to failure when the entry point
> didn't exist for an object that is no longer active; but on reflection,
> I accept that's just not worth worrying about.
Good spotting and thanks for the review.
Thinking about this it looks like bin_set_policy should only ever
error if the underlying function errors, and that will clear up
one inconsistency.
As for bin_page_mkwrite if sysfs_get_active fails there is no mapping
because we have called unmap_mapping_range to zap everything, so
page_mkwrite should simply not be called. However there is the
interesting case what should page_mkwrite return if there are no
vm_ops at all.
I expect the right choice for page_mkwrite it to simply have to
different sets of vm_ops and only write of page_mkwrite in one
of them and to simply call VM_FAULT_NOPAGE on error. Implementing
page_mkwrite when it isn't needed appears to have all kinds of
interesting side effects where we do a lot more work than we other
wise would. Lock dropping and regrabbing, as well as some extra
dirty page balancing logic gets triggered.
I will see if I can cook up a patch to that effect.
Eric
prev parent reply other threads:[~2010-09-22 21:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 7:55 [PATCH 0/2] Fix mmap bugs with sysfs_remove_bin_file Eric W. Biederman
2010-09-20 7:56 ` [PATCH 1/2] sysfs: Fail bin file mmap if vma close is implemented Eric W. Biederman
2010-09-22 19:31 ` Hugh Dickins
2010-09-22 21:01 ` Eric W. Biederman
2010-09-20 7:57 ` [PATCH 2/2] sysfs: only access bin file vm_ops with the active lock Eric W. Biederman
2010-09-22 19:49 ` Hugh Dickins
2010-09-22 21:59 ` Eric W. Biederman [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=m1zkv9v3rg.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/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
Powered by JetHome