From: Oleg Nesterov <oleg@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Al Viro <viro@zeniv.linux.org.uk>,
Vitaly Mayatskikh <vmayatsk@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: BUG? "Call fasync() functions without the BKL" is racy
Date: Mon, 1 Dec 2008 20:15:55 +0100 [thread overview]
Message-ID: <20081201191555.GA21385@redhat.com> (raw)
In-Reply-To: <4933CBB0.2060003@linux.intel.com>
On 12/01, Andi Kleen wrote:
>
> Oleg Nesterov wrote:
>>
>> Let's suppose we have the tasks T1, T2, T3 which share the same file,
>> all do sys_fcntl(file, F_SETFL) in parallel. file->f_flags == 0.
>>
>> setfl(arg) does:
>>
>> if ((arg ^ filp->f_flags) & FASYNC)
>> // --- WINDOW_1 ---
>> filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0)
>> // --- WINDOW_2 ---
>> filp->f_flags = arg;
>>
>> T1 calls setfl(FASYNC), preempted in WINDOW_1.
>>
>> T2 calls setfl(FASYNC), does all job and returns.
>>
>> T3 calls setfl(0), sees ->f_flags & FASYNC, does ->fasync(on => 0),
>> preempted in WINDOW_2.
>>
>> T1 resumes, does ->fasync(on => 1) again, update ->f_flags (it
>> already has FASYNC) and returns.
>>
>> T3 resumes, and clears FASYNC from ->f_flags.
>>
>>
>>
>> Now, this file was added into some "struct fasync_struct", but
>> ->f_flags doesn't have FASYNC. This means __fput() will skip
>> ->fasync(on => 0) and the next kill_fasync() can crash because
>> fa_file points to the freed/reused memory.
>
> Nasty. Thanks for catching.
Actually, this is more simple. Somehow I missed that setf() _always_
updates ->f_flags, so we have a trivial race with 2 threads.
>>
>> I think a238b790d5f99c7832f9b73ac8847025815b85f7 should be reverted.
>> Or do you see the better fix?
>
> Hmm, about checking for this case and retrying?
>
> Or put a fasync mutex into files_struct.
Perhaps, we can add O_LOCK_FLAGS, then something like
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -175,6 +175,15 @@ static int setfl(int fd, struct file * f
if (error)
return error;
+ spin_lock(¤t->files->file_lock);
+ if (!(filp->f_flags & O_LOCK_FLAGS))
+ filp->f_flags |= O_LOCK_FLAGS;
+ else
+ error = -EAGAIN;
+ spin_unlock(¤t->files->file_lock);
+ if (error) /* pretend ->f_flags was changed after us */
+ return 0;
+
if ((arg ^ filp->f_flags) & FASYNC) {
if (filp->f_op && filp->f_op->fasync) {
error = filp->f_op->fasync(fd, filp, (arg & FASYNC) != 0);
@@ -183,7 +192,8 @@ static int setfl(int fd, struct file * f
}
}
- filp->f_flags = (arg & SETFL_MASK) | (filp->f_flags & ~SETFL_MASK);
+ filp->f_flags = (arg & SETFL_MASK) |
+ (filp->f_flags & ~(SETFL_MASK | O_LOCK_FLAGS));
out:
return error;
}
What do you think?
(btw, ioctl_fioasync() calls lock_kernel() but it doesn't protect ->f_flags)
Oleg.
next prev parent reply other threads:[~2008-12-01 19:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-28 19:25 BUG? "Call fasync() functions without the BKL" is racy Oleg Nesterov
2008-12-01 11:34 ` Andi Kleen
2008-12-01 19:15 ` Oleg Nesterov [this message]
2008-12-01 19:34 ` Jonathan Corbet
2008-12-02 12:29 ` Oleg Nesterov
2008-12-02 16:30 ` Andi Kleen
2008-12-03 19:06 ` Oleg Nesterov
2008-12-03 21:21 ` Andi Kleen
2008-12-03 22:45 ` Jonathan Corbet
2008-12-04 14:34 ` Oleg Nesterov
2008-12-05 23:12 ` [PATCH 2.6.28] Fix FASYNC race Jonathan Corbet
2008-12-02 0:15 ` BUG? "Call fasync() functions without the BKL" is racy Andi Kleen
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=20081201191555.GA21385@redhat.com \
--to=oleg@redhat.com \
--cc=ak@linux.intel.com \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vmayatsk@redhat.com \
/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.