| Message ID | 20231124150822.2121798-1-jannh@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fs/pipe: Fix lockdep false-positive in watchqueue pipe_write() | expand |
On Fri, 24 Nov 2023 16:08:22 +0100, Jann Horn wrote: > When you try to splice between a normal pipe and a notification pipe, > get_pipe_info(..., true) fails, so splice() falls back to treating the > notification pipe like a normal pipe - so we end up in > iter_file_splice_write(), which first locks the input pipe, then calls > vfs_iter_write(), which locks the output pipe. > > Lockdep complains about that, because we're taking a pipe lock while > already holding another pipe lock. > > [...] Yeah, that looks to be a improvement in general, since you can't upgrade a regular pipe to a O_NOTIFICATION pipe. IOW, peforming that check with pipe_lock() isn't necessary. (The check for watch queue in pipe_set_size() called from pipe_fcntl() also wouldn't need to be done with __pipe_lock() held fwiw.) --- Applied to the vfs.misc branch of the vfs/vfs.git tree. Patches in the vfs.misc branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.misc [1/1] fs/pipe: Fix lockdep false-positive in watchqueue pipe_write() https://git.kernel.org/vfs/vfs/c/efb8f498327c
Jann Horn <jannh@google.com> wrote: > + /* > + * Reject writing to watch queue pipes before the point where we lock > + * the pipe. > + * Otherwise, lockdep would be unhappy if the caller already has another > + * pipe locked. > + * If we had to support locking a normal pipe and a notification pipe at > + * the same time, we could set up lockdep annotations for that, but > + * since we don't actually need that, it's simpler to just bail here. > + */ > + if (pipe_has_watch_queue(pipe)) > + return -EXDEV; > + Linus wanted it to be possible for the user to write to a notificaiton pipe. David
On Fri, Nov 24, 2023 at 03:53:47PM +0000, David Howells wrote: > Jann Horn <jannh@google.com> wrote: > > > + /* > > + * Reject writing to watch queue pipes before the point where we lock > > + * the pipe. > > + * Otherwise, lockdep would be unhappy if the caller already has another > > + * pipe locked. > > + * If we had to support locking a normal pipe and a notification pipe at > > + * the same time, we could set up lockdep annotations for that, but > > + * since we don't actually need that, it's simpler to just bail here. > > + */ > > + if (pipe_has_watch_queue(pipe)) > > + return -EXDEV; > > + > > Linus wanted it to be possible for the user to write to a notificaiton pipe. Since it has been disabled from the start and nothing has ever actually materialized we just don't need to care. If we start caring this needs more work anyway iirc.
diff --git a/fs/pipe.c b/fs/pipe.c index 804a7d789452..226e7f66b590 100644 --- a/fs/pipe.c +++ b/fs/pipe.c @@ -446,6 +446,18 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from) bool was_empty = false; bool wake_next_writer = false; + /* + * Reject writing to watch queue pipes before the point where we lock + * the pipe. + * Otherwise, lockdep would be unhappy if the caller already has another + * pipe locked. + * If we had to support locking a normal pipe and a notification pipe at + * the same time, we could set up lockdep annotations for that, but + * since we don't actually need that, it's simpler to just bail here. + */ + if (pipe_has_watch_queue(pipe)) + return -EXDEV; + /* Null write succeeds. */ if (unlikely(total_len == 0)) return 0; @@ -458,11 +470,6 @@ pipe_write(struct kiocb *iocb, struct iov_iter *from) goto out; } - if (pipe_has_watch_queue(pipe)) { - ret = -EXDEV; - goto out; - } - /* * If it wasn't empty we try to merge new data into * the last buffer.
When you try to splice between a normal pipe and a notification pipe, get_pipe_info(..., true) fails, so splice() falls back to treating the notification pipe like a normal pipe - so we end up in iter_file_splice_write(), which first locks the input pipe, then calls vfs_iter_write(), which locks the output pipe. Lockdep complains about that, because we're taking a pipe lock while already holding another pipe lock. I think this probably (?) can't actually lead to deadlocks, since you'd need another way to nest locking a normal pipe into locking a watch_queue pipe, but the lockdep annotations don't make that clear. Bail out earlier in pipe_write() for notification pipes, before taking the pipe lock. Reported-and-tested-by: syzbot+011e4ea1da6692cf881c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=011e4ea1da6692cf881c Fixes: c73be61cede5 ("pipe: Add general notification queue support") Signed-off-by: Jann Horn <jannh@google.com> --- fs/pipe.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) base-commit: 98b1cc82c4affc16f5598d4fa14b1858671b2263