let()
>
> - out_cast() or outer_cast()
> - from_member().
> - container_from() or from_container()
>
> from_container() sounds fine, would trimming it a bit work? like from_cont().
I like container_from() the most, since it's the closest to contain_of()
which is a well known idiom for years. The lines will already be shorter
without the need to specify the struct, so don't like the idea of
squeezing container into cont for any of them. For most people, cont is
usually short for continue, not container.
--
Jens Axboe
On 8/19/20 6:31 AM, Ilya Dryomov wrote:
> On Wed, Aug 19, 2020 at 3:03 PM Jens Axboe wrote:
>>
>> On 8/19/20 1:53 AM, Miaohe Lin wrote:
>>> Convert the uses of fallthrough comments to fallthrough macro.
>>
>> Applied, thanks.
>
> Hi Jens,
>
> Th
> path.
>
>
> I'm thinking that the raw_spinlock_t option would permit leaving that
> single:
>
> if (tsk->flags & (PF_WQ_WORKER | PF_IO_WORKER))
>
> branch intact?
Yes, the raw spinlock would do it, and leave the single branch intact
in the hot path. I'd be fine with going that route for io-wq.
--
Jens Axboe
On 8/19/20 6:11 AM, Greg KH wrote:
> On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
>> On 8/18/20 1:00 PM, James Bottomley wrote:
>>> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
>>>> On 8/17/20 12:48 PM, Kees Cook wrote:
>>>>> O
On 8/19/20 5:32 AM, Geert Uytterhoeven wrote:
> The various header files are part of the Block Layer.
> Add them to the corresponding section in the MAINTAINERS file, so
> scripts/get_maintainer.pl will pick them up.
Applied, thanks.
--
Jens Axboe
On 8/19/20 1:53 AM, Miaohe Lin wrote:
> Convert the uses of fallthrough comments to fallthrough macro.
Applied, thanks.
--
Jens Axboe
On 8/19/20 1:50 AM, Miaohe Lin wrote:
> Convert the uses of fallthrough comments to fallthrough macro.
Applied, thanks.
--
Jens Axboe
On 8/18/20 1:00 PM, James Bottomley wrote:
> On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
>> On 8/17/20 12:48 PM, Kees Cook wrote:
>>> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
>>>> On 8/17/20 12:29 PM, Kees Cook wrote:
>>>>> O
.
Applied, thanks.
--
Jens Axboe
this into 5.9 to have a longer deprecation
> period?
Wow, hadn't thought about this one in forever. Yeah let's see if we can
get this into 5.9. I can't imagine anyone using this thing, well, ever.
--
Jens Axboe
On 8/18/20 11:11 AM, Theodore Y. Ts'o wrote:
> On Mon, Aug 03, 2020 at 05:02:11PM -0600, Jens Axboe wrote:
>> ext4 uses generic_file_read_iter(), which already supports this.
>>
>> Cc: Theodore Ts'o
>> Signed-off-by: Jens Axboe
>>
>> ---
&
Ensure that it
> is assigned the error value of bio before jumping to the error handling
> label.
Applied, thanks.
--
Jens Axboe
Applied with stable and Fixes tag, and noted Oleksandr's testing.
--
Jens Axboe
hat the two pages are compatible with each other.
Applied, thanks.
--
Jens Axboe
On 8/17/20 12:48 PM, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
>> On 8/17/20 12:29 PM, Kees Cook wrote:
>>> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
>>>> On 8/17/20 2:15 AM, Allen Pais wrote:
>>>>>
On 8/17/20 12:29 PM, Kees Cook wrote:
> On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
>> On 8/17/20 2:15 AM, Allen Pais wrote:
>>> From: Allen Pais
>>>
>>> In preparation for unconditionally passing the
>>> struct tasklet_struct pointer
/nvme.git/commit/286155561ecd13b6c85a78eaf2880d3baea03b9e
That would have been nice to have in -rc1...
--
Jens Axboe
On 8/16/20 5:31 PM, Davidlohr Bueso wrote:
> do_each_pid_thread(PIDTYPE_PGID) can race with a concurrent
> change_pid(PIDTYPE_PGID) that can move the task from one hlist
> to another while iterating. Serialize ioprio_get/set to take
> the tasklist_lock in this case.
LGTM:
Reviewed-by
on few ata devices are necessary.
Didn't we agree to split this up into separate patches??
> I tried but unfortunately, I couldn't find or arrange devices to test upon. I
> have added the authors of the previous commit(s) for respective drivers as
> recipients. It would be very h
e up with the idea to add a macro 'from_tasklet' that is just
container_of? container_of in the code would be _much_ more readable,
and not leave anyone guessing wtf from_tasklet is doing.
I'd fix that up now before everything else goes in...
--
Jens Axboe
On 8/16/20 8:29 PM, Xu Wang wrote:
> Using ata_link_info() instead of ata_link_printk().
Applied, thanks.
--
Jens Axboe
On 8/16/20 7:16 PM, Xu Wang wrote:
> Replace a comma between expression statements by a semicolon.
Thanks, applied.
--
Jens Axboe
gt; - ata_link_printk(link, KERN_INFO, "avn bounce port%d\n",
> + ata_link_info(link, "avn bounce port%d\n",
> port);
Why not collapse that into one line as well when making that change, as
it now fits just fine?
Apart from that, looks fine to me.
--
Jens Axboe
doing that anyway, I removed
the 'new' from the commit message. Looks like it was from 5.6, so not
what I'd call new.
--
Jens Axboe
On 8/16/20 3:25 PM, Randy Dunlap wrote:
> Fix a new kernel-doc warning in block/blk-mq.c:
>
> ../block/blk-mq.c:1844: warning: Function parameter or member 'at_head' not
> described in 'blk_mq_request_bypass_insert'
Applied, thanks.
--
Jens Axboe
-
io_uring-5.9-2020-08-15
Guoyu Huang (1):
io_uring: Fix NULL pointer dereference in loop_rw_iter()
Jens Axboe (17):
io_uring: io_async_buf_func() need not test page bit
io_uring: ad
#syz dup general protection fault in io_poll_double_wake
--
Jens Axboe
#syz dupe general protection fault in io_poll_double_wake
--
Jens Axboe
yz repro: https://syzkaller.appspot.com/x/repro.syz?x=10f211d290
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1721b0ce90
>
> The issue was bisected to:
>
> commit 18bceab101adde8f38de76016bc77f3f25cf22f4
> Author: Jens Axboe
> Date: Fri May 1
On 8/15/20 11:16 AM, Jens Axboe wrote:
> On 8/15/20 10:00 AM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:7fca4dee Merge tag 'powerpc-5.9-2' of git://git.kernel.org..
>> git tree: upstream
>>
=
> BUG: KASAN: use-after-free in radix_tree_next_slot
> include/linux/radix-tree.h:421 [inline]
> BUG: KASAN: use-after-free in idr_for_each+0x206/0x220 lib/idr.c:202
> Read of size 8 at addr 888082058c78 by task syz-executor999/3765
Should already be fixed by:
commit
le for some other code to look at ->ki_filp
> concurrently... maybe Jens Axboe knows whether that could plausibly
> happen?
I looked into the io_uring use case, and we're using req->file (which is
the same as kiocb->ki_filp) after submission for the polled-IO case.
That's
AL handling quite a bit, which is important now
that io_uring is relying on it for all task_work deliveries.
Cc: Peter Zijlstra
Cc: Jann Horn
Acked-by: Oleg Nesterov
Signed-off-by: Jens Axboe
---
diff --git a/kernel/signal.c b/kernel/signal.c
index 6f16f7c5d375..42b67d2cea37 100644
--- a/kern
for 5.4-stable, it doesn't affect any kernels newer
than that.
--
Jens Axboe
On 8/12/20 8:54 AM, Oleg Nesterov wrote:
> On 08/11, Oleg Nesterov wrote:
>>
>> On 08/11, Jens Axboe wrote:
>>>
>>> --- a/kernel/task_work.c
>>> +++ b/kernel/task_work.c
>>> @@ -42,7 +42,8 @@ task_work_add(struct task_struct
#syz dup: KASAN: use-after-free Read in io_async_task_func
--
Jens Axboe
On 8/11/20 9:23 AM, Oleg Nesterov wrote:
> On 08/11, Jens Axboe wrote:
>>
>> --- a/kernel/task_work.c
>> +++ b/kernel/task_work.c
>> @@ -42,7 +42,8 @@ task_work_add(struct task_struct *task, struct
>> callback_head *work, int notify)
>> set_not
On 8/11/20 9:23 AM, Jens Axboe wrote:
> On 8/11/20 8:59 AM, Jens Axboe wrote:
>> On 8/11/20 7:57 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:d6efb3ac Merge tag 'tty-5.9-rc1' of g
On 8/11/20 8:59 AM, Jens Axboe wrote:
> On 8/11/20 7:57 AM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:d6efb3ac Merge tag 'tty-5.9-rc1' of git://git.kernel.org/p..
>> git tree: upstream
>> co
[<a4116b07>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> [<67b2aefc>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
This one looks very odd, and I cannot reproduce it. The socket() calls
reliably fails for me, and even if I hack it to use 0 for protocol instead
of 2, I don't see anything interesting happening here. An IORING_OP_WRITEV
is submitted on the socket, which just fails with ENOTCONN.
--
Jens Axboe
On 8/11/20 8:44 AM, Stefano Garzarella wrote:
> On Tue, Aug 11, 2020 at 08:21:12AM -0600, Jens Axboe wrote:
>> On 8/11/20 8:00 AM, Stefano Garzarella wrote:
>>> On Mon, Aug 10, 2020 at 09:55:17AM -0600, Jens Axboe wrote:
>>>> On 8/10/20 9:36 AM, syzbot wrote:
>>
On 8/3/20 5:02 PM, Jens Axboe wrote:
> ext4 uses generic_file_read_iter(), which already supports this.
Ping...
--
Jens Axboe
If JOBCTL_TASK_WORK is already set on the targeted task, then we need
not go through {lock,unlock}_task_sighand() to set it again and queue
a signal wakeup. This is safe as we're checking it _after adding the
new task_work with cmpxchg().
Signed-off-by: Jens Axboe
---
Tested this wi
On 8/11/20 8:00 AM, Stefano Garzarella wrote:
> On Mon, Aug 10, 2020 at 09:55:17AM -0600, Jens Axboe wrote:
>> On 8/10/20 9:36 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:449dc8c9 Merge tag
struct callback_head *cb)
if (io_poll_rewait(req, &apoll->poll)) {
spin_unlock_irq(&ctx->completion_lock);
+ percpu_ref_put(&ctx->refs);
return;
}
--
Jens Axboe
;>
>> Fixes: 3448914e8cc5("loop: Add LOOP_CONFIGURE ioctl")
>>
>> Signed-off-by: Lennart Poettering
>> Acked-by: Martijn Coenen
>
> Thanks, still looks good to me.
Applied.
--
Jens Axboe
read-ahead with IOCB_NOWAIT set")
Reported-by: Dave Chinner
Signed-off-by: Jens Axboe
---
This was a known change with the buffered async read change, but we
didn't have IOCB_NOIO until late in 5.8. Now that bases are synced,
make the change to make RWF_NOWAIT behave like past kernels
On 8/10/20 4:56 PM, Dave Chinner wrote:
> On Wed, Jun 24, 2020 at 10:44:21AM -0600, Jens Axboe wrote:
>> On 6/24/20 10:41 AM, Matthew Wilcox wrote:
>>> On Wed, Jun 24, 2020 at 09:35:19AM -0600, Jens Axboe wrote:
>>>> On 6/24/20 9:00 AM, Jens Axboe wrote:
>>&g
#syz dup: INFO: task hung in io_uring_flush
--
Jens Axboe
On 8/10/20 10:08 AM, Pavel Begunkov wrote:
> On 10/08/2020 19:04, syzbot wrote:
>> syzbot has bisected this issue to:
>>
>> commit f86cd20c9454847a524ddbdcdec32c0380ed7c9b
>> Author: Jens Axboe
>> Date: Wed Jan 29 20:46:44 2020 +
>>
>>
On 8/10/20 8:37 AM, Jens Axboe wrote:
> On 8/10/20 5:44 AM, pet...@infradead.org wrote:
>> On Sat, Aug 08, 2020 at 03:43:50PM -0600, Jens Axboe wrote:
>>> Any pre-existing caller of this function uses 'true' to signal to use
>>> notifications or not, but we
gt;task_work, 0);
- wake_up_process(tsk);
- }
-}
-
static void io_queue_next(struct io_kiocb *req)
{
struct io_kiocb *nxt = io_req_find_next(req);
@@ -1872,7 +1911,7 @@ static void io_req_free_batch(struct req_batch *rb,
struct io_kiocb *req)
req->flags &= ~REQ_F_TASK_PINNED;
}
- io_dismantle_req(req);
+ WARN_ON_ONCE(io_dismantle_req(req));
rb->reqs[rb->to_free++] = req;
if (unlikely(rb->to_free == ARRAY_SIZE(rb->reqs)))
__io_req_free_batch_flush(req->ctx, rb);
--
Jens Axboe
it.kernel.dk/cgit/linux-block/commit/?h=io_uring-5.9&id=2dd2111d0d383df104b144e0d1f6b5a00cb7cd88
--
Jens Axboe
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1672fd3490
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+d4586d3028284ff8a...@syzkaller.appspotmail.com
Looks like a dupe of: syzbot+996f91b6ec3812c48...@syzkaller.appspotmail.com
--
Jens Axboe
data->mode);
}
+}
+
+static void io_queue_linked_timeout(struct io_kiocb *req)
+{
+ struct io_ring_ctx *ctx = req->ctx;
+
+ spin_lock_irq(&ctx->completion_lock);
+ __io_queue_linked_timeout(req);
spin_unlock_irq(&ctx->completion_lock);
/* drop submission reference */
--
Jens Axboe
On 8/10/20 5:44 AM, pet...@infradead.org wrote:
> On Sat, Aug 08, 2020 at 03:43:50PM -0600, Jens Axboe wrote:
>> Any pre-existing caller of this function uses 'true' to signal to use
>> notifications or not, but we now also have signaled notifications.
>> Update exis
well:
e91b48162332 ("task_work: teach task_work_add() to do signal_wake_up()")
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Signed-off-by: Jens Axboe
---
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 14e4b4d17ee5..615a34d697df 100644
--- a/arch/x86/kernel
what it does.
If the bio list is contiguous, then we do the plugging to improve
merging at the lower level. You probably ran into a case where
you saw sub-optimal merging? And now the performance is better
with the patch? How much?
--
Jens Axboe
kdev_issue_discard() before composing the discard bio. If the value
> is 0, then prints a warning oops information and returns -EOPNOTSUPP to
> the caller to indicate that this buggy device driver doesn't support
> discard request.
Applied, thanks.
--
Jens Axboe
0010 DS: ES: CR0: 000080050033
> [ 99.899197] CR2: ffd6 CR3: 7ac66000 CR4:
> 06e0
Thanks, applied (slightly modified for current -git), and marked with the right
fixes tag and stable CC'ed.
--
Jens Axboe
like an old one, that affects 5.4 only. I've massaged
it to apply on top of another fix, will ask to get it queued up for
stable. Thanks!
--
Jens Axboe
On 8/3/20 5:49 PM, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 4:31 PM Jens Axboe wrote:
>>
>> Updated to honor exclusive return value as well:
>
> See my previous email, You're just adding code that makes no sense,
> because your wait entry fundamentally isn'
On 8/3/20 5:34 PM, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 4:18 PM Jens Axboe wrote:
>>
>>
>> I took a look at the rewrite you queued up, and made a matching change
>> on the io_uring side:
>
> Oh, no, you made it worse.
>
> Now you're tying yo
On 8/3/20 5:18 PM, Jens Axboe wrote:
> On 8/3/20 4:30 PM, Jens Axboe wrote:
>>> Adding random kiocb helper functions to a core header file, when they
>>> are only used in one place, and when they only make sense in that one
>>> place?
>>>
>>> No
On 8/3/20 4:30 PM, Jens Axboe wrote:
>> Adding random kiocb helper functions to a core header file, when they
>> are only used in one place, and when they only make sense in that one
>> place?
>>
>> Not ok.
>
> I'll move that into io_uring instead.
I se
ext4 uses generic_file_read_iter(), which already supports this.
Cc: Theodore Ts'o
Signed-off-by: Jens Axboe
---
Resending this one, as I've been carrying it privately since May. The
necessary bits are now upstream (and XFS/btrfs equiv changes as well),
please consider this o
efinitely
wasn't because the tag wasn't there.
In terms of attachments, I'm usually a fan of inlining, but seemed cleaner
to me to attach the merge resolution as there's already a ton of other
stuff in that email.
--
Jens Axboe
On 8/3/20 2:48 PM, Linus Torvalds wrote:
> On Sun, Aug 2, 2020 at 2:41 PM Jens Axboe wrote:
>>
>> Lots of cleanups in here, hardening the code and/or making it easier to
>> read and fixing buts, but a core feature/change too adding support for
>> real async buffere
try Vyukov (1):
io_uring: fix sq array offset calculation
Jens Axboe (31):
block: provide plug based way of signaling forced no-wait semantics
io_uring: always plug for any number of IOs
io_uring: catch -EIO from buffered issue request failure
io_uring: re-issue block request
On 8/1/20 4:36 AM, Pavel Begunkov wrote:
> Use a local var to collect flags in kiocb_set_rw_flags(). That spares
> some memory writes and allows to replace most of the jumps with MOVEcc.
I've picked this one up.
--
Jens Axboe
userspace ABI,
> IOCB flags are not). iocb_flags() probably doesn't get any worse because
> the IOCB_ flags don't have the same numbers as the O_ bits (which differ
> by arch anyway).
Yeah that's not a bad idea, would kill a lot of branches.
--
Jens Axboe
On 7/30/20 7:42 PM, Randy Dunlap wrote:
> Drop doubled words or fix them to what they should be.
> Also fix a few typos and kernel-doc notation.
Applied, thanks.
--
Jens Axboe
On 7/30/20 8:28 PM, Hillf Danton wrote:
>
> On Thu, 30 Jul 2020 20:07:59 -0600 Jens Axboe wrote:
>> On 7/30/20 7:45 PM, Hillf Danton wrote:
>>>
>>> Add the missing percpu_ref_get when creating ctx.
>>>
> [...]
>> The error path doesn't care, t
eate(unsigned entr
> free_uid(user);
> return -ENOMEM;
> }
> + percpu_ref_get(&ctx->refs);
> ctx->compat = in_compat_syscall();
> ctx->user = user;
> ctx->creds = get_current_cred();
> @@ -8369,8 +8370,10 @@ static int io_uring_create(unsigned entr
> io_account_mem(ctx, ring_pages(p->sq_entries, p->cq_entries),
> ACCT_LOCKED);
> ctx->limit_mem = limit_mem;
> + percpu_ref_put(&ctx->refs);
> return ret;
> err:
> + percpu_ref_put(&ctx->refs);
> io_ring_ctx_wait_and_kill(ctx);
> return ret;
> }
The error path doesn't care, the issue is only after fd install. Hence
we don't need to grab a reference, just make sure we don't touch the ctx
after fd install. Since you saw this one, you must have also seen my
patch. Why not comment on that instead?
--
Jens Axboe
_entries, p->flags);
- io_account_mem(ctx, ring_pages(p->sq_entries, p->cq_entries),
- ACCT_LOCKED);
- ctx->limit_mem = limit_mem;
return ret;
err:
io_ring_ctx_wait_and_kill(ctx);
--
Jens Axboe
On 7/30/20 11:51 AM, Kanchan Joshi wrote:
> On Thu, Jul 30, 2020 at 11:10 PM Pavel Begunkov
> wrote:
>>
>> On 30/07/2020 20:16, Jens Axboe wrote:
>>> On 7/30/20 10:26 AM, Pavel Begunkov wrote:
>>>> On 30/07/2020 19:13, Jens Axboe wrote:
>>>>>
On 7/30/20 3:03 AM, Chengming Zhou wrote:
> We shouldn't skip iocg when its abs_vdebt is not zero.
Applied, thanks.
> Fixes: 0b80f9866e6b ("iocost: protect iocg->abs_vdebt with
> iocg->waitq.lock")
Minor note, and I fixed this up, but these should be one line.
--
Jens Axboe
On 7/30/20 6:31 AM, Chengming Zhou wrote:
> iocg usage_idx is the latest usage index, we should start from the
> oldest usage index to show the consecutive NR_USAGE_SLOTS usages.
Applied, thanks.
--
Jens Axboe
On 7/30/20 10:26 AM, Pavel Begunkov wrote:
> On 30/07/2020 19:13, Jens Axboe wrote:
>> On 7/30/20 10:08 AM, Pavel Begunkov wrote:
>>> On 27/07/2020 23:34, Jens Axboe wrote:
>>>> On 7/27/20 1:16 PM, Kanchan Joshi wrote:
>>>>> On Fri, Jul 24, 2020 at 10:0
On 7/30/20 10:08 AM, Pavel Begunkov wrote:
> On 27/07/2020 23:34, Jens Axboe wrote:
>> On 7/27/20 1:16 PM, Kanchan Joshi wrote:
>>> On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>>>>
>>>> On 7/24/20 9:49 AM, Kanchan Joshi wrote:
>>>>&g
Pavel Begunkov (2):
io_uring: fix ->work corruption with poll_add
io_uring: fix lockup in io_fail_links()
fs/io_uring.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
--
Jens Axboe
gt;>
>> Fixes tag
>>
>> Fixes: aa63fa6776a7 ("nvme-fabrics: allow to queue requests for live
>> queues")
>>
>> has these problem(s):
>>
>> - Target SHA1 does not exist
>>
>> I can't easily find what commit is meant :-(
Yeah, it's obviously garbage, the commit doesn't even exist, let alone the sha.
Chaitanya, where's this from??
--
Jens Axboe
On 7/28/20 9:41 AM, Jens Axboe wrote:
> On 7/24/20 1:32 AM, Christoph Hellwig wrote:
>> Hi Jens,
>>
>> this series contains a bunch of different BDI cleanups. The biggest item
>> is to isolate block drivers from the BDI in preparation of changing the
>> life
On 7/28/20 10:20 AM, Daniel Wagner wrote:
> No need to define typedefs for the callbacks, because there is not a
> single user except blk_mq_ops.
v2 I guess, but looks good to me, thanks.
--
Jens Axboe
On 7/28/20 10:05 AM, Daniel Wagner wrote:
> No need to define typedefs for the callbacks, because there is not a
> single user except blk_mq_ops.
Concept looks fine to me, but you're mixing indentations a bit. Just
remove the indentation bits, we don't need them here.
--
Jens Axboe
On 7/27/20 11:17 PM, Vaibhav Gupta wrote:
> On Mon, Jul 27, 2020 at 02:30:03PM -0600, Jens Axboe wrote:
>> On 7/27/20 12:11 PM, Vaibhav Gupta wrote:
>>> On Mon, Jul 27, 2020 at 11:59:05AM -0600, Jens Axboe wrote:
>>>> On 7/27/20 11:51 AM, Vaibhav Gupta wrote:
>&
On 7/24/20 1:32 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> this series contains a bunch of different BDI cleanups. The biggest item
> is to isolate block drivers from the BDI in preparation of changing the
> lifetime of the block device BDI in a follow up series.
Applied, th
quot;blk-mq: Make it
> safe to use RCU to iterate over blk_mq_tag_set.tag_list") and
> 05b79413946d ("Revert "blk-mq: don't handle TAG_SHARED in restart"").
> Those changes got reverted later but the cleanup commit missed a
> couple of places to undo the changes.
Applied, thanks.
--
Jens Axboe
On 7/27/20 1:16 PM, Kanchan Joshi wrote:
> On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>>
>> On 7/24/20 9:49 AM, Kanchan Joshi wrote:
>>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>>> index 7809ab2..6510cf5 100644
>>> --- a/fs/io_uring.c
>&
On 7/27/20 12:11 PM, Vaibhav Gupta wrote:
> On Mon, Jul 27, 2020 at 11:59:05AM -0600, Jens Axboe wrote:
>> On 7/27/20 11:51 AM, Vaibhav Gupta wrote:
>>> On Mon, Jul 27, 2020 at 11:42:51AM -0600, Jens Axboe wrote:
>>>> On 7/27/20 11:40 AM, Vaibhav Gupta wrote:
>>
On 7/27/20 11:51 AM, Vaibhav Gupta wrote:
> On Mon, Jul 27, 2020 at 11:42:51AM -0600, Jens Axboe wrote:
>> On 7/27/20 11:40 AM, Vaibhav Gupta wrote:
>>> The patch is compile-tested only.
>>
>> Please test and verify actual functionality, if you're serious about
&
On 7/27/20 11:40 AM, Vaibhav Gupta wrote:
> The patch is compile-tested only.
Please test and verify actual functionality, if you're serious about
potentially getting this into the kernel.
--
Jens Axboe
_t sense;
unsigned char data_direction;
+ unsigned char pad[3];
compat_int_tquiet;
compat_int_ttimeout;
compat_caddr_t reserved[1];
--
Jens Axboe
ink/async sqe flags
Jens Axboe (1):
io_uring: ensure double poll additions work with both request types
Pavel Begunkov (1):
io_uring: missed req_init_async() for IOSQE_ASYNC
fs/io_uring.c | 61 +++
1 file changed, 36 inserti
and that also clashes with mainline. The next available
bit would be 10, IOCB_WAITQ and IOCB_NOIO are 8 and 9.
--
Jens Axboe
ave this weird API where liburing or the app would need to
distinguish this cqe from all others based on... the user_data? Hence
liburing can't do it, only the app would be able to.
Just seems like a hack to me.
--
Jens Axboe
cks for non-NULL
before calling __kfree() or whatever the real function would then be.
--
Jens Axboe
On 7/21/20 1:44 PM, Andy Lutomirski wrote:
> On Tue, Jul 21, 2020 at 11:39 AM Jens Axboe wrote:
>>
>> On 7/21/20 11:44 AM, Andy Lutomirski wrote:
>>> On Tue, Jul 21, 2020 at 10:30 AM Jens Axboe wrote:
>>>>
>>>> On 7/21/20 11:23 AM, Andy Lutomir
On 7/21/20 11:44 AM, Andy Lutomirski wrote:
> On Tue, Jul 21, 2020 at 10:30 AM Jens Axboe wrote:
>>
>> On 7/21/20 11:23 AM, Andy Lutomirski wrote:
>>> On Tue, Jul 21, 2020 at 8:31 AM Jens Axboe wrote:
>>>>
>>>> On 7/21/20 9:27 AM, Andy Lutomir
On 7/21/20 11:23 AM, Andy Lutomirski wrote:
> On Tue, Jul 21, 2020 at 8:31 AM Jens Axboe wrote:
>>
>> On 7/21/20 9:27 AM, Andy Lutomirski wrote:
>>> On Fri, Jul 17, 2020 at 1:02 AM Stefano Garzarella
>>> wrote:
>>>>
>>>> On Thu, Jul 16
701 - 800 of 5145 matches
Mail list logo
