f65d0
The repro looks pretty much like sqpoll-exit-hang test and issues
that were just recently fixed.
#syz test: git://git.kernel.dk/linux-block for-5.13/io_uring
>
> The issue was bisected to:
>
> commit d9d05217cb6990b9a56e13b56e7a1b71e2551f6c
> Author: Pavel B
h:
>
> #syz fix: io_uring: Convert personality_idr to XArray
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
#syz fix: io_uring: Convert personality_idr to XArray
--
Pavel Begunkov
+0xa64/0x12d0 fs/io_uring.c:8620
> process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
>
#syz test: git://git.kernel.dk/linux-block for-5.13/io_uring
--
Pavel Begunkov
On 11/04/2021 09:58, Hao Sun wrote:
> Pavel Begunkov 于2021年4月11日周日 下午4:14写道：
>>
>> On 11/04/2021 04:08, Hao Sun wrote:
>>> Hi
>>>
>>> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
>>> the Linux kernel, I found a null
R10: 0001 R11: 88804b8e0280 R12:
> R13: 8880409d5140 R14: 88804b8e0280 R15: 8880481c1800
> FS: 7f046fa1a700() GS:88807ec0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0040 CR3: 479a5000 CR4: 00750ee0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> PKRU: 5554
>
--
Pavel Begunkov
?x=86318203e865a02b
> dashboard link: https://syzkaller.appspot.com/bug?extid=93f72b3885406bb09e0d
> compiler:
>
--
Pavel Begunkov
On 08/04/2021 06:05, syzbot wrote:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering
> an issue:
> INFO: task hung in io_ring_exit_work
Ok, it's really fancy, we add task_work with TWA_SIGNAL to a guaranteed
not exited/exec task, it succeeds, but the
On 07/04/2021 20:51, Pavel Begunkov wrote:
> On 05/04/2021 20:34, syzbot wrote:
>> Hello,
>>
>> syzbot has tested the proposed patch but the reproducer is still triggering
>> an issue:
>> INFO: task hung in io_ring_exit_work
>
> Let's see if it's due to q
k.c:294
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
> Sending NMI from CPU 1 to CPUs 0:
> NMI backtrace for cpu 0
> CPU: 0 PID: 2124 Comm: kswapd1 Not tainted 5.12.0-rc2-syzkaller #0
> Hardware name: Google Google Comput
00 R09: 7ffe75923090
> R10: R11: 0246 R12: 7ffe758f7ce4
> R13: 7ffe758f7d40 R14: 028f R15: 7ffe758f7d20
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
--
Pavel Begunkov
On 20/11/2020 19:13, Jens Axboe wrote:
> On 11/20/20 10:10 AM, Pavel Begunkov wrote:
>> io_uring's direct nowait requests end up waiting on io_schedule() in
>> sbitmap, that's seems to be so because blkdev_direct_IO() fails to
>> propagate IOCB_NOWAIT to a bio and hence to blk
e a reason why not. Jens?
Better not right away though. IMHO it's safer to let the change settle
down for some time.
--
Pavel Begunkov
don't know, for up-to-date code all submission functions are under
128 bytes for me, including io_submit_sqes with everything heavily
inlined into it. I believe it's just a strange config keeping
everything on stack for some reason (too under optimised?).
>
>
> vim +/io_submit_sqes
fb fb fb fb fb fb
> ==
>
>
> Tested on:
>
> commit: dfea9fce io_uring: close a small race gap for files cancel
> git tree: git://git.kernel.dk/linux-block
> console output: https://syzkaller.appspot.com/x/log.txt?x=1263a46b50
> kernel config: https://syzkaller.appspot.com/x/.config?x=4db50a97037d9f3e
> dashboard link: https://syzkaller.appspot.com/bug?extid=12056a09a0311d758e60
> compiler: gcc (GCC) 10.1.0-syz 20200507
>
--
Pavel Begunkov
urn NULL;
> +
> switch (req->submit.opcode) {
> case IORING_OP_READV:
> case IORING_OP_READ_FIXED:
>
--
Pavel Begunkov
On 18/03/2021 08:33, Hillf Danton wrote:
> On Mon, 15 Mar 2021 12:18:20 +0000 Pavel Begunkov wrote:
>> On 15/03/2021 11:58, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:75013c6c Merge tag
t; *(uint32_t*)0x2650 = 0;
> *(uint32_t*)0x2654 = -1;
> *(uint32_t*)0x2658 = 0;
> *(uint32_t*)0x265c = 0;
> *(uint64_t*)0x2660 = 0;
> *(uint16_t*)0x2668 = 0;
> *(uint16_t*)0x266a = 0;
> *(uint32_t*)0
r buf[TASK_COMM_LEN];
>
> worker->flags |= (IO_WORKER_F_UP | IO_WORKER_F_RUNNING);
> +
> + if (wq == NULL)
> + return -EFAULT;
> +
> io_wqe_inc_running(worker);
>
> sprintf(buf, "iou-wrk-%d", wq->task_pid);
>
--
Pavel Begunkov
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
if (fatal_signal_pending(current))
> break;
> - }
> sqt_spin = false;
> cap_entries = !list_is_singular(>ctx_list);
> list_for_each_entry(ctx, >ctx_list, sqd_list) {
>
--
Pavel Begunkov
On 07/03/2021 12:39, Pavel Begunkov wrote:
> On 07/03/2021 09:49, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:a38fd874 Linux 5.12-rc2
>> git tree: upstream
>> console output: https://syzkaller.app
rocess_one_work+0x98d/0x1600 kernel/workqueue.c:2275
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
:171 [inline]
> exit_to_user_mode_prepare+0x148/0x250 kernel/entry/common.c:208
> __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
> syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:301
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x465ef9
> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7ffb56aa0218 EFLAGS: 0246 ORIG_RAX: 00ca
> RAX: RBX: 0056bf68 RCX: 00465ef9
> RDX: RSI: 0080 RDI: 0056bf68
> RBP: 0056bf60 R08: R09:
> R10: R11: 0246 R12: 0056bf6c
> R13: 7fff198147ff R14: 7ffb56aa0300 R15: 00022000
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
chain gcc-10
> --kconfig s3c6400_defconfig
> or
> tuxmake --runtime podman --target-arch mips --toolchain gcc-9
> --kconfig e55_defconfig
>
>
--
Pavel Begunkov
On 19/02/2021 12:05, Pavel Begunkov wrote:
> On 18/02/2021 12:27, Lennert Buytenhek wrote:
>> IORING_OP_GETDENTS behaves much like getdents64(2) and takes the same
>> arguments, but with a small twist: it takes an additional offset
>> argument, and reading from the speci
}
> +
> + if (pos_unlock)
> + mutex_unlock(>file->f_pos_lock);
> +
> + if (ret < 0) {
> + if (ret == -ERESTARTSYS)
> + ret = -EINTR;
> + req_set_fail_links(req);
> + }
> + io_req_complete(req, ret);
> + return 0;
> +}
[...]
--
Pavel Begunkov
On 10/02/2021 17:37, Randy Dunlap wrote:
> Fix build errors when CONFIG_NET is not enabled.
Thanks, but already fixed up.
>
> Fixes: b268c951abf8 ("io_uring: don't propagate io_comp_state")
> Signed-off-by: Randy Dunlap
> Cc: Pavel Begunkov
> Cc:
_work kernel/entry/common.c:291 [inline]
> syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7fb450c54840
> Code: 73 01 c3 48 8b 0d 68 77 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44
> 00 00 83 3d 89 bb 20 00 00 75 10 b8 02 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73
> 31 c3 48 83 ec 08 e8 1e f6 ff ff 48 89 04 24
> RSP: 002b:7ffd66c13138 EFLAGS: 0246 ORIG_RAX: 0002
> RAX: fffe RBX: 7ffd66c13440 RCX: 7fb450c54840
> RDX: 01a0 RSI: 00080042 RDI: 55b07430c150
> RBP: 000d R08: ffc0 R09:
> R10: 0069 R11: 0246 R12:
> R13: 55b0742fe060 R14: 7ffd66c13400 R15: 55b07430c1a0
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
--
Pavel Begunkov
put: https://syzkaller.appspot.com/x/log.txt?x=14532690d00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=fe3e1032f57d6d25
> dashboard link: https://syzkaller.appspot.com/bug?extid=2f5d1785dc624932da78
> compiler:
>
--
Pavel Begunkov
: 0003
> RBP: 006cc018 R08: R09:
> R10: R11: 0246 R12: 004023c0
> R13: 00402450 R14: 0000 R15:
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
--
Pavel Begunkov
c:716
> process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
>
>
> Tested on:
>
> commit: a1235e44 io_uring: cancel all requests on task exit
> git tree: git://git.kernel.dk/linux-block io_uring-5.11
> console output: https://syzkaller.appspot.com/x/log.txt?x=10c53584d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=c6b6b5cccb0f38f2
> dashboard link: https://syzkaller.appspot.com/bug?extid=2f5d1785dc624932da78
> compiler: gcc (GCC) 10.1.0-syz 20200507
>
--
Pavel Begunkov
On 28/01/2021 17:25, Jens Axboe wrote:
> On 1/28/21 10:12 AM, Pavel Begunkov wrote:
>> On 28/01/2021 16:58, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:76c057c8 Merge branch 'parisc-5.11-
0: 2280 R11: 0206 R12: 20ff8000
> R13: 20ff1000 R14: 22c0 R15: 2280
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
cc52843..39ae1f821cef 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -6460,7 +6460,8 @@ static struct file *io_file_get(struct io_submit_state
*state,
file = __io_file_get(state, fd);
}
- if (file && file->f_op == _uring_fops) {
+ if (file && file->f_op == _uring_fops &&
+ !(req->flags & REQ_F_INFLIGHT)) {
io_req_init_async(req);
req->flags |= REQ_F_INFLIGHT;
--
Pavel Begunkov
signature.asc
Description: OpenPGP digital signature
On 27/01/2021 18:31, Al Viro wrote:
> On Wed, Jan 27, 2021 at 03:48:10PM +0000, Pavel Begunkov wrote:
>> On 16/01/2021 05:18, Al Viro wrote:
>>> On Sat, Jan 09, 2021 at 10:11:09PM +0000, Pavel Begunkov wrote:
>>>
>>>>> Does any code actually look at
On 27/01/2021 15:42, Pavel Begunkov wrote:
> On 27/01/2021 15:00, Kanchan Joshi wrote:
>> This RFC patchset adds asynchronous ioctl capability for NVMe devices.
>> Purpose of RFC is to get the feedback and optimize the path.
>>
>> At the uppermost io-uring layer, a ne
On 16/01/2021 05:18, Al Viro wrote:
> On Sat, Jan 09, 2021 at 10:11:09PM +0000, Pavel Begunkov wrote:
>
>>> Does any code actually look at the fields as a pair?
>>> Would it even be better to use separate bytes?
>>> Even growing the on-stack structure by a word w
ernel: export task_work_add
> nvme: add async ioctl support
> io_uring: add async passthrough ioctl support
>
> drivers/nvme/host/core.c | 347 +++---
> fs/io_uring.c | 77
> include/linux/blkdev.h| 12 ++
> include/uapi/linux/io_uring.h | 7 +-
> kernel/task_work.c| 2 +-
> 5 files changed, 376 insertions(+), 69 deletions(-)
>
--
Pavel Begunkov
On 26/01/2021 18:43, Noah Goldstein wrote:
> On Tue, Jan 26, 2021 at 12:24 PM Pavel Begunkov
> wrote:
>>
>> On 26/01/2021 17:14, Noah Goldstein wrote:
>>> On Tue, Jan 26, 2021 at 7:29 AM Pavel Begunkov
>>> wrote:
>>>>
>>>> On 22/12/
On 26/01/2021 17:14, Noah Goldstein wrote:
> On Tue, Jan 26, 2021 at 7:29 AM Pavel Begunkov wrote:
>>
>> On 22/12/2020 02:10, Noah Goldstein wrote:
>>> On Sun, Dec 20, 2020 at 03:18:05PM +, Pavel Begunkov wrote:
>>>> On 20/12/2020 06:50, noah wrote:> F
On 22/12/2020 02:10, Noah Goldstein wrote:
> On Sun, Dec 20, 2020 at 03:18:05PM +0000, Pavel Begunkov wrote:
>> On 20/12/2020 06:50, noah wrote:> From: noah
>>>
>>> This patch makes it so that specify a file descriptor value of -2 will
>>> skip upda
On 02/01/2021 19:25, Pavel Begunkov wrote:
> On 24/12/2020 03:02, Yejune Deng wrote:
>> The function io_remove_personalities() is very similar to
>> io_unregister_personality(),so implement io_remove_personalities()
>> calling io_unregister_personality().
>
> Plea
66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7f85abf54c68 EFLAGS: 0246 ORIG_RAX: 0003
> RAX: ffda RBX: 0001 RCX: 0045e219
> RDX: RSI: RDI: 0004
> RBP: 0119bfb0 R08: R09: 0000
> R10: R11: 0246 R12: 0119bf8c
> R13: 7ffe5217973f R14: 7f85abf559c0 R15: 0119bf8c
>
--
Pavel Begunkov
> R10: R11: 0246 R12: 0119bf8c
> R13: 7ffe7c5112ff R14: 7fe4399819c0 R15: 0119bf8c
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
On 17/01/2021 02:31, Hillf Danton wrote:
> On Sat, 16 Jan 2021 05:32:30 +0000 Pavel Begunkov wrote:
>>
>> @@ -9126,7 +9126,10 @@ static int io_uring_flush(struct file *file, void
>> *data)
>>
>> if (ctx->flags & IORING_SETUP_SQPOLL) {
>>
7d2f R14: 7f49d69f49c0 R15: 0119bf8c
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
EFLAGS: 0246 ORIG_RAX: 0003
> RAX: ffda RBX: 0001 RCX: 0045e219
> RDX: RSI: RDI: 0007
> RBP: 0119bfb0 R08: 0000 R09: 0000
> R10: R11: 0246 R12: 0119bf8c
> R13: 7ffc626b58ff R14: 7fe461a719c0 R15: 0119bf8c
--
Pavel Begunkov
rrect, but the one-line fix is unable to cover this report,
> as per the Call Trace in both reports.
>
> Feel free to double check if what you trimmed fixes both reports.
I believe they do (when considered together).
--
Pavel Begunkov
g?extid=06b7d55a62acca161485
> compiler: clang version 11.0.1
>
> Note: testing is done by a robot and is best-effort only.
>
--
Pavel Begunkov
d0d0
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1527be48d0
>>
>> The issue was bisected to:
>>
>> commit d9d05217cb6990b9a56e13b56e7a1b71e2551f6c
>> Author: Pavel Begunkov
>> Date: Fri Jan 8 20:57:25 2021 +
>>
>
ff08af6e18b)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17ef17fb50
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1045ef6750
>
> The issue was bisected to:
>
> commit d9d05217cb6990b9a56e13b56e7a1b71e2551f6c
> Author: Pavel Begunkov
> Date: Fri Jan
On 11/01/2021 09:35, David Laight wrote:
> From: Pavel Begunkov
>> Sent: 09 January 2021 22:11
>
>>> Does any code actually look at the fields as a pair?
>>> Would it even be better to use separate bytes?
>>> Even growing the on-stack structure by a word
On 11/01/2021 05:23, Chaitanya Kulkarni wrote:
> On 1/10/21 18:32, Pavel Begunkov wrote:
>> On 11/01/2021 02:06, Chaitanya Kulkarni wrote:
>>> On 1/9/21 13:29, Pavel Begunkov wrote:
>>>> On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
>>>>> On 1/9/21 12:
On 11/01/2021 02:06, Chaitanya Kulkarni wrote:
> On 1/9/21 13:29, Pavel Begunkov wrote:
>> On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
>>> On 1/9/21 12:40, Pavel Begunkov wrote:
>>>> I expect you won't find any, but such little things can pile up
>>>>
On 09/01/2021 21:49, David Laight wrote:
> From: Al Viro
>> Sent: 09 January 2021 17:04
>>
>> On Sat, Jan 09, 2021 at 04:09:08PM +, Pavel Begunkov wrote:
>>> On 06/12/2020 16:01, Pavel Begunkov wrote:
>>>> On 21/11/2020 14:37, Pavel Begunkov wrote:
&
On 09/01/2021 20:52, Chaitanya Kulkarni wrote:
> On 1/9/21 12:40, Pavel Begunkov wrote:
>> I expect you won't find any, but such little things can pile up
>> into a not-easy-to-spot overhead over time.
>
> That is what I suspected with the resulting assembly. The commit lo
On 09/01/2021 17:03, Al Viro wrote:
> On Sat, Jan 09, 2021 at 04:09:08PM +0000, Pavel Begunkov wrote:
>> On 06/12/2020 16:01, Pavel Begunkov wrote:
>>> On 21/11/2020 14:37, Pavel Begunkov wrote:
>>>> The problem here is that iov_iter_is_*() helpers check types for
&
On 09/01/2021 20:09, Chaitanya Kulkarni wrote:
> On 1/9/21 07:59, Pavel Begunkov wrote:
>> iov_iter_bvec() initialises iterators well, no need to pre-zero it
>> beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it
>> out and generate extra code for that (co
g?extid=99ed55100402022a6276
> compiler: gcc (GCC) 10.1.0-syz 20200507
>
> Note: testing is done by a robot and is best-effort only.
>
--
Pavel Begunkov
syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
--
Pavel Begunkov
po in 1ffc54220c44
Thanks for the suggestion, but it was already fixed
#syz fix: io_uring: Fix return value from alloc_fixed_file_ref_node
>
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -7255,8 +7255,8 @@ static int io_sqe_files_unregister(struc
> if (!data)
> return -ENXIO;
> backup_node = alloc_fixed_file_ref_node(ctx);
> - if (!backup_node)
> - return -ENOMEM;
> + if (IS_ERR(backup_node))
> + return PTR_ERR(backup_node);
>
> spin_lock_bh(>lock);
> ref_node = data->node;
>
--
Pavel Begunkov
On 06/12/2020 16:01, Pavel Begunkov wrote:
> On 21/11/2020 14:37, Pavel Begunkov wrote:
>> The problem here is that iov_iter_is_*() helpers check types for
>> equality, but all iterate_* helpers do bitwise ands. This confuses
>> compilers, so even if some cases we
iter_file_splice_write() may spawn bvec segments with zero-length. In
preparation for prohibiting them, filter out by hand at splice level.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
fs/splice.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Add a helper function calculating the number of bvec segments we need to
allocate to construct a bio. It doesn't change anything functionally,
but will be used to not duplicate special cases in the future.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
fs/block_dev.c
reduces memory footprint.
Suggested-by: Matthew Wilcox
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
Documentation/filesystems/porting.rst | 9
block/bio.c | 67 ---
include/linux/bio.h | 5 +-
3 files
iov_iter_advance() is heavily used, but implemented through generic
means. For bvecs there is a specifically crafted function for that, so
use bvec_iter_advance() instead, it's faster and slimmer.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
lib/iov_iter.c | 19
.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
Documentation/block/biovecs.rst | 2 ++
Documentation/filesystems/porting.rst | 7 +++
lib/iov_iter.c| 2 --
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/block
for them clear out BIO_WORKINGSET flag. Do same for
dio_bio_submit() because fs/direct_io constructs bios by hand directly
calling bio_add_page().
Reported-by: Christoph Hellwig
Suggested-by: Christoph Hellwig
Suggested-by: Johannes Weiner
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel
From: Christoph Hellwig
This saves one memory allocation, and ensures the bvecs aren't freed
before the AIO completion. This will allow the lower level code to be
optimized so that it can avoid allocating another bvec array.
Signed-off-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
(Dave)
- other nits by Christoph
since v2:
- add a comment in 1/7 (Christoph)
- add a note about 0-len bvecs in biovecs.rst (Matthew)
Christoph Hellwig (1):
target/file: allocate the bvec array as part of struct
target_core_file_cmd
Pavel Begunkov (6):
splice: don't generate zero-len
Currently, if I/O is enqueued for async execution direct paths of
generic_file_{read,write}_iter() will always revert the iter. There are
no users expecting that, and that is also costly. Leave iterators as is
on -EIOCBQUEUED.
Signed-off-by: Pavel Begunkov
---
mm/filemap.c | 6 --
1 file
iov_iter_bvec() initialises iterators well, no need to pre-zero it
beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it
out and generate extra code for that (confirmed with assembly).
Signed-off-by: Pavel Begunkov
---
drivers/target/target_core_file.c | 2 +-
1 file changed, 1
lo_rw_aio() knows what iocb.ki_complete it set, so instead of an
expensive indirect call it can call lo_rw_aio_complete() directly.
Signed-off-by: Pavel Begunkov
---
drivers/block/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/loop.c b/drivers/block
On 04/01/2021 16:37, Matthew Wilcox wrote:
> On Sat, Jan 02, 2021 at 03:17:34PM +0000, Pavel Begunkov wrote:
>> --- a/Documentation/filesystems/porting.rst
>> +++ b/Documentation/filesystems/porting.rst
>> @@ -865,3 +865,10 @@ no matter what. Everything is
On 04/01/2021 16:17, Christoph Hellwig wrote:
> On Sat, Jan 02, 2021 at 03:17:33PM +0000, Pavel Begunkov wrote:
>> iter_file_splice_write() may spawn bvec segments with zero-length. In
>> preparation for prohibiting them, filter out by hand at splice level.
>>
>> Si
On 04/01/2021 15:57, Greg Kroah-Hartman wrote:
> From: Pavel Begunkov
>
> commit b1b6b5a30dce872f500dc43f067cba8e7f86fc7d upstream.
>
> For cancelling io_uring requests it needs either to be able to run
> currently enqueued task_works or having it shut down by that m
v2], add a changelog after "---" and add tags from previous
threads if any.
Looks good
Reviewed-by: Pavel Begunkov
>
> Signed-off-by: Yejune Deng
> ---
> fs/io_uring.c | 28 +++-
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git
reduces memory footprint.
Suggested-by: Matthew Wilcox
Signed-off-by: Pavel Begunkov
---
Documentation/filesystems/porting.rst | 9
block/bio.c | 67 ---
include/linux/bio.h | 5 +-
3 files changed, 42 insertions(+), 39
Add a helper function calculating the number of bvec segments we need to
allocate to construct a bio. It doesn't change anything functionally,
but will be used to not duplicate special cases in the future.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
fs/block_dev.c
From: Christoph Hellwig
This saves one memory allocation, and ensures the bvecs aren't freed
before the AIO completion. This will allow the lower level code to be
optimized so that it can avoid allocating another bvec array.
Signed-off-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
.
Signed-off-by: Pavel Begunkov
---
Documentation/filesystems/porting.rst | 7 +++
lib/iov_iter.c| 2 --
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesystems/porting.rst
b/Documentation/filesystems/porting.rst
index 867036aa90b8
iov_iter_advance() is heavily used, but implemented through generic
means. For bvecs there is a specifically crafted function for that, so
use bvec_iter_advance() instead, it's faster and slimmer.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
lib/iov_iter.c | 19
for them clear out BIO_WORKINGSET flag. Do same for
dio_bio_submit() because fs/direct_io constructs bios by hand directly
calling bio_add_page().
Reported-by: Christoph Hellwig
Suggested-by: Christoph Hellwig
Suggested-by: Johannes Weiner
Signed-off-by: Pavel Begunkov
---
block/bio.c| 6
iter_file_splice_write() may spawn bvec segments with zero-length. In
preparation for prohibiting them, filter out by hand at splice level.
Signed-off-by: Pavel Begunkov
---
fs/splice.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/splice.c b/fs/splice.c
index
(Dave)
- other nits by Christoph
Christoph Hellwig (1):
target/file: allocate the bvec array as part of struct
target_core_file_cmd
Pavel Begunkov (6):
splice: don't generate zero-len segement bvecs
bvec/iter: disallow zero-length segment bvecs
block/psi: remove PSI annotations from
b fb fb fb fb fb fb fb fb fb
> 888073de3480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ======
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
--
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
On 23/12/2020 20:23, Douglas Gilbert wrote:
> On 2020-12-23 11:04 a.m., James Bottomley wrote:
>> On Wed, 2020-12-23 at 15:51 +, Christoph Hellwig wrote:
>>> On Wed, Dec 23, 2020 at 12:52:59PM +0000, Pavel Begunkov wrote:
>>>> Can scatterlist have 0-len entries?
On 22/12/2020 14:11, Christoph Hellwig wrote:
> On Tue, Dec 15, 2020 at 02:05:35PM +0000, Pavel Begunkov wrote:
>>> You may find clue from the following link:
>>>
>>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2262077.html
>>
>> Thanks f
_personality(void *, ...)
{
struct io_ring_ctx *ctx = data;
io_unregister_personality(ctx, id);
return 0;
}
--
Pavel Begunkov
+7898,6 @@ static int __io_sqe_files_update(struct io_ring_ctx *ctx,
break;
}
}
- nr_args--;
- done++;
- up->offset++;
}
if (needs_switch) {
--
Pavel Begunkov
On 20/12/2020 13:58, Oleg Nesterov wrote:
> On 12/20, Pavel Begunkov wrote:
>>
>> On 08/12/2020 01:37, Al Viro wrote:
>>> On Thu, Dec 03, 2020 at 02:30:46AM +, Pavel Begunkov wrote:
>>>> Handle task works and lock it earlier before it starts killing off
>
On 08/12/2020 01:37, Al Viro wrote:
> On Thu, Dec 03, 2020 at 02:30:46AM +0000, Pavel Begunkov wrote:
>> Handle task works and lock it earlier before it starts killing off
>> task's resources like mm. io_uring makes use of it a lot and it'd
>> nicer to have all added ta
ant to solve a problem rather than mask it. So, can it really
happen or a problem is somewhere else?
>
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -8379,7 +8379,13 @@ static void io_ring_exit_work(struct wor
> static void io_ring_ctx_wait_and_kill(struct io_ring_ctx *ctx)
> {
> mutex_lock(>uring_lock);
> - percpu_ref_kill(>refs);
> + /*
> + * try to avoid killing dead ctx, see the comments for dropping
> + * ring mutex in __io_uring_register()
> + */
> + if (!percpu_ref_is_dying(>refs))
> + percpu_ref_kill(>refs);
> +
> mutex_unlock(>uring_lock);
>
> io_kill_timeouts(ctx, NULL);
>
--
Pavel Begunkov
ddress:
> 888032eb2b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 888032eb2b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> 888032eb2c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> 888032eb2c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 888032eb2d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
>
#syz test: git://git.kernel.dk/linux-block
dfea9fce29fda6f2f91161677e0e0d9b671bc099
--
Pavel Begunkov
On 15/12/2020 12:03, Ming Lei wrote:
> On Tue, Dec 15, 2020 at 11:14:20AM +0000, Pavel Begunkov wrote:
>> On 15/12/2020 01:41, Ming Lei wrote:
>>> On Tue, Dec 15, 2020 at 12:20:19AM +0000, Pavel Begunkov wrote:
>>>> Instead of creating a full copy of ite
On 15/12/2020 13:54, David Laight wrote:
> From: Pavel Begunkov
>> Sent: 15 December 2020 11:24
>>
>> On 15/12/2020 09:37, David Laight wrote:
>>> From: Pavel Begunkov
>>>> Sent: 15 December 2020 00:20
>>>>
>>>> iov_iter_advance
On 15/12/2020 01:33, Dave Chinner wrote:
> On Tue, Dec 15, 2020 at 01:03:45AM +0000, Pavel Begunkov wrote:
>> On 15/12/2020 00:56, Dave Chinner wrote:
>>> On Tue, Dec 15, 2020 at 12:20:23AM +0000, Pavel Begunkov wrote:
>>>> As reported, we must not do pressur
On 15/12/2020 09:37, David Laight wrote:
> From: Pavel Begunkov
>> Sent: 15 December 2020 00:20
>>
>> iov_iter_advance() is heavily used, but implemented through generic
>> iteration. As bvecs have a specifically crafted advance() function, i.e.
>> bvec_iter_advan
On 15/12/2020 01:41, Ming Lei wrote:
> On Tue, Dec 15, 2020 at 12:20:19AM +0000, Pavel Begunkov wrote:
>> Instead of creating a full copy of iter->bvec into bio in direct I/O,
>> the patchset makes use of the one provided. It changes semantics and
>> obliges users of asy
1 - 100 of 397 matches
Mail list logo
