FAILED: patch "[PATCH] io_uring: fix up O_NONBLOCK handling for sockets" failed to apply to 5.3-stable tree

PATCH [email protected] 3 participants 8 messages Oct 27, 2019 – Oct 28, 2019

Subsystems (2)

Stable branch VFS

lore

Share & tools

lore

[email protected]

author maintainer

2019-10-27 17:23 UTC #0 lore raw

The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 491381ce07ca57f68c49c79a8a43da5b60749e32 Mon Sep 17 00:00:00 2001
From: Jens Axboe <[email protected]>
Date: Thu, 17 Oct 2019 09:20:46 -0600
Subject: [PATCH] io_uring: fix up O_NONBLOCK handling for sockets

We've got two issues with the non-regular file handling for non-blocking IO:

1) We don't want to re-do a short read in full for a non-regular file, as we can't just read the data again.
2) For non-regular files that don't support non-blocking IO attempts, we need to punt to async context even if the file is opened as non-blocking. Otherwise the caller always gets -EAGAIN.

Add two new request flags to handle these cases. One is just a cache of the inode S_ISREG() status, the other tells io_uring that we always need to punt this request to async context, even if REQ_F_NOWAIT is set.

Cc [email protected]

Reported-by Hrvoje Zeba <[email protected]>

Tested-by Hrvoje Zeba <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

fs/io_uring.c +39 ~~-18~~

index d2cb277da2f4..b7d4085d6ffd 100644
@@ -322,6 +322,8 @@ struct io_kiocb {
 #define REQ_F_FAIL_LINK		256	/* fail rest of links */
 #define REQ_F_SHADOW_DRAIN	512	/* link-drain shadow req */
 #define REQ_F_TIMEOUT		1024	/* timeout request */
+#define REQ_F_ISREG		2048	/* regular file */
+#define REQ_F_MUST_PUNT		4096	/* must be punted even for NONBLOCK */
 	u64			user_data;
 	u32			result;
 	u32			sequence;

@@ -914,26 +916,26 @@ static int io_iopoll_check(struct io_ring_ctx *ctx, unsigned *nr_events,
 	return ret;
 }
 
-static void kiocb_end_write(struct kiocb *kiocb)
+static void kiocb_end_write(struct io_kiocb *req)
 {
-	if (kiocb->ki_flags & IOCB_WRITE) {
-		struct inode *inode = file_inode(kiocb->ki_filp);
+	/*
+	 * Tell lockdep we inherited freeze protection from submission
+	 * thread.
+	 */
+	if (req->flags & REQ_F_ISREG) {
+		struct inode *inode = file_inode(req->file);
 
-		/*
-		 * Tell lockdep we inherited freeze protection from submission
-		 * thread.
-		 */
-		if (S_ISREG(inode->i_mode))
-			__sb_writers_acquired(inode->i_sb, SB_FREEZE_WRITE);
-		file_end_write(kiocb->ki_filp);
+		__sb_writers_acquired(inode->i_sb, SB_FREEZE_WRITE);
 	}
+	file_end_write(req->file);
 }
 
 static void io_complete_rw(struct kiocb *kiocb, long res, long res2)
 {
 	struct io_kiocb *req = container_of(kiocb, struct io_kiocb, rw);
 
-	kiocb_end_write(kiocb);
+	if (kiocb->ki_flags & IOCB_WRITE)
+		kiocb_end_write(req);
 
 	if ((req->flags & REQ_F_LINK) && res != req->result)
 		req->flags |= REQ_F_FAIL_LINK;

@@ -945,7 +947,8 @@ static void io_complete_rw_iopoll(struct kiocb *kiocb, long res, long res2)
 {
 	struct io_kiocb *req = container_of(kiocb, struct io_kiocb, rw);
 
-	kiocb_end_write(kiocb);
+	if (kiocb->ki_flags & IOCB_WRITE)
+		kiocb_end_write(req);
 
 	if ((req->flags & REQ_F_LINK) && res != req->result)
 		req->flags |= REQ_F_FAIL_LINK;

@@ -1059,8 +1062,17 @@ static int io_prep_rw(struct io_kiocb *req, const struct sqe_submit *s,
 	if (!req->file)
 		return -EBADF;
 
-	if (force_nonblock && !io_file_supports_async(req->file))
-		force_nonblock = false;
+	if (S_ISREG(file_inode(req->file)->i_mode))
+		req->flags |= REQ_F_ISREG;
+
+	/*
+	 * If the file doesn't support async, mark it as REQ_F_MUST_PUNT so
+	 * we know to async punt it even if it was opened O_NONBLOCK
+	 */
+	if (force_nonblock && !io_file_supports_async(req->file)) {
+		req->flags |= REQ_F_MUST_PUNT;
+		return -EAGAIN;
+	}
 
 	kiocb->ki_pos = READ_ONCE(sqe->off);
 	kiocb->ki_flags = iocb_flags(kiocb->ki_filp);

@@ -1081,7 +1093,8 @@ static int io_prep_rw(struct io_kiocb *req, const struct sqe_submit *s,
 		return ret;
 
 	/* don't allow async punt if RWF_NOWAIT was requested */
-	if (kiocb->ki_flags & IOCB_NOWAIT)
+	if ((kiocb->ki_flags & IOCB_NOWAIT) ||
+	    (req->file->f_flags & O_NONBLOCK))
 		req->flags |= REQ_F_NOWAIT;
 
 	if (force_nonblock)

@@ -1382,7 +1395,9 @@ static int io_read(struct io_kiocb *req, const struct sqe_submit *s,
 		 * need async punt anyway, so it's more efficient to do it
 		 * here.
 		 */
-		if (force_nonblock && ret2 > 0 && ret2 < read_size)
+		if (force_nonblock && !(req->flags & REQ_F_NOWAIT) &&
+		    (req->flags & REQ_F_ISREG) &&
+		    ret2 > 0 && ret2 < read_size)
 			ret2 = -EAGAIN;
 		/* Catch -EAGAIN return for forced non-blocking submission */
 		if (!force_nonblock || ret2 != -EAGAIN) {

@@ -1447,7 +1462,7 @@ static int io_write(struct io_kiocb *req, const struct sqe_submit *s,
 		 * released so that it doesn't complain about the held lock when
 		 * we return to userspace.
 		 */
-		if (S_ISREG(file_inode(file)->i_mode)) {
+		if (req->flags & REQ_F_ISREG) {
 			__sb_start_write(file_inode(file)->i_sb,
 						SB_FREEZE_WRITE, true);
 			__sb_writers_release(file_inode(file)->i_sb,

@@ -2282,7 +2297,13 @@ static int __io_queue_sqe(struct io_ring_ctx *ctx, struct io_kiocb *req,
 	int ret;
 
 	ret = __io_submit_sqe(ctx, req, s, force_nonblock);
-	if (ret == -EAGAIN && !(req->flags & REQ_F_NOWAIT)) {
+
+	/*
+	 * We async punt it if the file wasn't marked NOWAIT, or if the file
+	 * doesn't support non-blocking read/write attempts
+	 */
+	if (ret == -EAGAIN && (!(req->flags & REQ_F_NOWAIT) ||
+	    (req->flags & REQ_F_MUST_PUNT))) {
 		struct io_uring_sqe *sqe_copy;
 
 		sqe_copy = kmemdup(s->sqe, sizeof(*sqe_copy), GFP_KERNEL);

Jens Axboe

2019-10-27 18:58 UTC #1 lore raw

Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:

The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.

Signature · 1 line

Jens Axboe

Greg KH

author maintainer

2019-10-27 20:00 UTC #2 lore raw

Quoted 9 lines · Jens Axboe

Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:
The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.

Ok, wait for the next 5.3.y release in a few days and send stuff off of that if you can.

thanks,

greg k-h

Jens Axboe

2019-10-27 20:22 UTC #3 lore raw

Quoted 8 lines · Greg KH

Quoted 7 lines · Jens Axboe
Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:
The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

Quoted 5 lines

Quoted 2 lines
I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.
Ok, wait for the next 5.3.y release in a few days and send stuff off of that if you can.

Is there no "current" or similar tree to work of off? Would be a shame to miss the next one, especially since the newer fixes are already in.

If not, I'll just wait for the next one.

Signature · 1 line

Jens Axboe

Greg KH

author maintainer

2019-10-27 20:26 UTC #4 lore raw

Quoted 9 lines · Jens Axboe

Quoted 8 lines · Greg KH
Quoted 7 lines · Jens Axboe
Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:
The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.
Ok, wait for the next 5.3.y release in a few days and send stuff off of that if you can.
Is there no "current" or similar tree to work of off? Would be a shame to miss the next one, especially since the newer fixes are already in.

I'm about to push out the -rcs right now. You can base off of that and send me the patch and I'll add it, or just wait a few days, either is fine.

thanks,

greg k-h

Jens Axboe

2019-10-27 20:39 UTC #5 lore raw

Quoted 16 lines · Greg KH

Quoted 15 lines · Jens Axboe
Quoted 13 lines · Greg KH
Quoted 9 lines · Jens Axboe
Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:
The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.
Ok, wait for the next 5.3.y release in a few days and send stuff off of that if you can.

Quoted 6 lines

Quoted 2 lines
Is there no "current" or similar tree to work of off? Would be a shame to miss the next one, especially since the newer fixes are already in.
I'm about to push out the -rcs right now. You can base off of that and send me the patch and I'll add it, or just wait a few days, either is fine.

Sounds good, thanks Greg.

Signature · 1 line

Jens Axboe

Sasha Levin

maintainer

2019-10-28 08:26 UTC #6 lore raw

Quoted 17 lines · Jens Axboe

Quoted 16 lines · Greg KH
Quoted 15 lines · Jens Axboe
Quoted 13 lines · Greg KH
Quoted 9 lines · Jens Axboe
Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:
The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.
Ok, wait for the next 5.3.y release in a few days and send stuff off of that if you can.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
Is there no "current" or similar tree to work of off? Would be a shame to miss the next one, especially since the newer fixes are already in.
I'm about to push out the -rcs right now. You can base off of that and send me the patch and I'll add it, or just wait a few days, either is fine.
Sounds good, thanks Greg.

I'll queue up a backport for this. The conflict is due to not having the io_queue_sqe()/__io_queue_sqe() split introduced by 4fe2c963154c3 ("io_uring: add support for link with drain").

Signature · 2 lines

Thanks,
Sasha

Jens Axboe

2019-10-28 15:21 UTC #7 lore raw

Quoted 25 lines · Sasha Levin

Quoted 24 lines · Jens Axboe
Quoted 22 lines · Greg KH
Quoted 9 lines · Jens Axboe
Quoted 8 lines · Greg KH
Quoted 7 lines · Jens Axboe
Quoted 5 lines · On 10/27/19 9:53 AM, [email protected] wrote:
The patch below does not apply to the 5.3-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
I can fix this up, but I probably need to see Sasha's queue first for the io_uring patches. I need to base it against that.
Ok, wait for the next 5.3.y release in a few days and send stuff off of that if you can.
Is there no "current" or similar tree to work of off? Would be a shame to miss the next one, especially since the newer fixes are already in.
I'm about to push out the -rcs right now. You can base off of that and send me the patch and I'll add it, or just wait a few days, either is fine.

Quoted 5 lines

Quoted 1 line
Sounds good, thanks Greg.
I'll queue up a backport for this. The conflict is due to not having the io_queue_sqe()/__io_queue_sqe() split introduced by 4fe2c963154c3 ("io_uring: add support for link with drain").

Thanks!

Signature · 1 line

Jens Axboe