Patch "fs/pipe: Fix lockdep false-positive in watchqueue pipe_write()" has been added to the 6.7-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    fs/pipe: Fix lockdep false-positive in watchqueue pipe_write()

to the 6.7-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     fs-pipe-fix-lockdep-false-positive-in-watchqueue-pip.patch
and it can be found in the queue-6.7 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit a9197d27406825457a1b2ba3aa0d8c4aed8b2f0c
Author: Jann Horn <jannh@xxxxxxxxxx>
Date:   Fri Nov 24 16:08:22 2023 +0100

    fs/pipe: Fix lockdep false-positive in watchqueue pipe_write()
    
    [ Upstream commit 055ca83559912f2cfd91c9441427bac4caf3c74e ]
    
    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@xxxxxxxxxxxxxxxxxxxxxxxxx>
    Closes: https://syzkaller.appspot.com/bug?extid=011e4ea1da6692cf881c
    Fixes: c73be61cede5 ("pipe: Add general notification queue support")
    Signed-off-by: Jann Horn <jannh@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20231124150822.2121798-1-jannh@xxxxxxxxxx
    Signed-off-by: Christian Brauner <brauner@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

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.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux