On 3/1/21 6:11 PM, Jens Axboe wrote:
> On 3/1/21 5:57 PM, Alex Xu (Hello71) wrote:
>> Hi,
>>
>> On Linux 5.12-rc1, I am unable to suspend to RAM. The system freezes for
>> about 40 seconds and then continues operation. The following messages
>> are printed to th
r. Let me know which troubleshooting steps I
> should perform next.
Can you try and pull in:
git://git.kernel.dk/linux-block io_uring-5.12
and see if that resolves it? I usually always run -git on my laptop as
well, but something broke it in the merge window so I need to figure
out what that is first...
What distro are you running?
--
Jens Axboe
#syz test: git://git.kernel.dk/linux-block syzbot-test
--
Jens Axboe
xed by replying with:
#syz fix: block: pre-initialize struct block_device in bdev_alloc_inode
--
Jens Axboe
On 2/28/21 7:08 PM, Zhang, Qiang wrote:
>
>
> ____
> 发件人: Jens Axboe
> 发送时间: 2021年3月1日 7:08
> 收件人: syzbot; asml.sile...@gmail.com; io-ur...@vger.kernel.org;
> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> syzkaller-
On 2/27/21 5:19 PM, Finn Thain wrote:
> On Sun, 3 Jan 2021, Jens Axboe wrote:
>
>>>
>>> This patch was sent in September and subsequently resent in November.
>>> I've since learned that the maintainer has been ill. What's the best
>>> way
/cpuidle/cpuidle.c:351
> call_cpuidle kernel/sched/idle.c:158 [inline]
> cpuidle_idle_call kernel/sched/idle.c:239 [inline]
> do_idle+0x3e1/0x590 kernel/sched/idle.c:300
> cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:397
> start_secondary+0x274/0x350 arch/x86/kernel/smpboot.c:272
> secondary_startup_64_no_verify+0xb0/0xbb
This looks very odd, only thing I can think of is someone doing
poll_wait() twice with different entries but for the same
waitqueue head.
#syz test: git://git.kernel.dk/linux-block syzbot-test
--
Jens Axboe
/asm/irqflags.h:51 [inline]
> NMI backtrace for cpu 1 skipped: idling at arch_safe_halt
> arch/x86/include/asm/irqflags.h:89 [inline]
> NMI backtrace for cpu 1 skipped: idling at acpi_safe_halt
> drivers/acpi/processor_idle.c:110 [inline]
> NMI backtrace for cpu 1 skipped: idling at acpi_idle_do_entry+0x1c9/0x250
> drivers/acpi/processor_idle.c:516
Once for-next gets to something more recent, then this one (and others) will
be gone.
--
Jens Axboe
.c:2217 [inline]
> BUG: KASAN: use-after-free in tctx_task_work+0x238/0x280 fs/io_uring.c:2230
> Read of size 4 at addr 88802178e3f0 by task syz-executor.2/12656
This should fix it.
commit adc34362605c08e622c0750ae3377ed03637abd1
Author: Jens Axboe
Date: Sun Feb 28 09:59:26 2021 -0700
On 2/26/21 1:38 PM, Matthew Wilcox wrote:
>
> This seems to have missed the merge window ;-(
It ain't over yet, and I haven't shipped my final bits for 5.12 for
block yet... I'll queue it up.
--
Jens Axboe
tag to the commit:
> Reported-by: syzbot+38769495e847cea2d...@syzkaller.appspotmail.com
This one is already fixed in the current tree.
--
Jens Axboe
/0x1120 kernel/workqueue.c:2421
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Looks like an error introduced in the switch, can you see if this
helps?
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 15a9c59e9a13..fc7137aea698 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -7135,6 +7135,7 @@ static void io_sq_thread_finish(struct io_ring_ctx *ctx)
struct io_sq_data *sqd = ctx->sq_data;
if (sqd) {
+ complete(&sqd->startup);
if (sqd->thread) {
wait_for_completion(&ctx->sq_thread_comp);
io_sq_thread_park(sqd);
--
Jens Axboe
888030dc0780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 888030dc0800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> 888030dc0880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> 888030dc0900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 888030dc0980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
Same that trinity reported, that one already got fixed and merged
into the parent.
#syz invalid
--
Jens Axboe
nel.org/cgit/linux/kernel/git/next/linux-next.git master
This one has been fixed.
--
Jens Axboe
sistency
> and clarity of the code.
>
> If you do go ahead, please update the blk_get_request() doc comment
> explicitly mentioning that blk_mq_free_request() needs to be called.
Would make sense to rename blk_get_request() to blk_mq_alloc_request()
and then we have API symmetry. The get/put don't make sense when there
are no references involved.
But it's a lot of churn for very little reward, which is always kind
of annoying. Especially for the person that has to carry the patches.
--
Jens Axboe
Applied, thanks.
--
Jens Axboe
al update from Greg, not a patch that was backported.
I did! Greg really needs an alter-ego for these kinds of patches.
--
Jens Axboe
n created as it's not necessary.
Applied, thanks.
--
Jens Axboe
t;> 888012eaae80: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
>> 888012eaaf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ==
>
> Fix double free by reverting 41be53e94fb0 ("io_uring: kill cached
> requests from exiting task closing the ring") - it ruins kworker's life.
>
> --- x/fs/io_uring.c
> +++ y/fs/io_uring.c
> @@ -9234,7 +9234,6 @@ static int io_uring_flush(struct file *f
>
> if (fatal_signal_pending(current) || (current->flags & PF_EXITING)) {
> io_uring_cancel_task_requests(ctx, NULL);
> - io_req_caches_free(ctx, current);
> }
>
> if (!tctx)
Already merged the right fix this morning:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.12/io_uring&id=8e5c66c485a8af3f39a8b0358e9e09f002016d92
--
Jens Axboe
)
>
> I have used the block tree from next-20210222 for today.
You got very unlucky, that bad commit only lasted for about 1-2 min.
--
Jens Axboe
On 2/22/21 5:41 PM, Jens Axboe wrote:
> On 2/22/21 5:34 PM, Jens Axboe wrote:
>> On 2/22/21 4:53 PM, Sergei Trofimovich wrote:
>>> On Mon, 22 Feb 2021 16:34:50 -0700
>>> Jens Axboe wrote:
>>>
>>>> On 2/22/21 4:05 PM, Sergei Trofimovich wrote:
>
On 2/22/21 5:34 PM, Jens Axboe wrote:
> On 2/22/21 4:53 PM, Sergei Trofimovich wrote:
>> On Mon, 22 Feb 2021 16:34:50 -0700
>> Jens Axboe wrote:
>>
>>> On 2/22/21 4:05 PM, Sergei Trofimovich wrote:
>>>> Hia Jens!
>>>>
>>>> Tried
On 2/22/21 4:53 PM, Sergei Trofimovich wrote:
> On Mon, 22 Feb 2021 16:34:50 -0700
> Jens Axboe wrote:
>
>> On 2/22/21 4:05 PM, Sergei Trofimovich wrote:
>>> Hia Jens!
>>>
>>> Tried 5.11 on rx3600 box and noticed it has
>>> a problem handling
init!
> exitcode=0x000b
> [ 34.973948] SIG deliver (gendepends.sh:69): sig=17 sp=6f6ad480
> ip=a0040740 handler=4b4c59b6
> [ 34.973948] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b ]---
>
> Bisect
On 2/22/21 2:31 PM, Hugh Dickins wrote:
> On Thu, 18 Feb 2021, Jens Axboe wrote:
>> On 2/18/21 4:16 PM, Andrew Morton wrote:
>>> On Thu, 18 Feb 2021 14:36:31 -0700 Jens Axboe wrote:
>>>
>>>> Currently we cap the batch count at max(32, 2*nr_online_cpus), wh
ges.
> Now the value of async depth is too small for queue_depth=256, this may
> cause hang.
>
> This patch introduces kyber_depth_updated(), so that kyber can update
> async depth when queue depth changes.
Applied, thanks.
--
Jens Axboe
On 2/22/21 6:42 AM, Kanchan Joshi wrote:
> On Thu, Jan 28, 2021 at 10:54 PM Jens Axboe wrote:
>>
>> On 1/28/21 10:13 AM, Kanchan Joshi wrote:
>>> On Thu, Jan 28, 2021 at 8:08 PM Jens Axboe wrote:
>>>>
>>>> On 1/28/21 5:04 AM, Kanchan Joshi wr
On 2/22/21 3:11 AM, Alexey Gladkov wrote:
> On Sun, Feb 21, 2021 at 04:38:10PM -0700, Jens Axboe wrote:
>> On 2/15/21 5:41 AM, Alexey Gladkov wrote:
>>> diff --git a/fs/io-wq.c b/fs/io-wq.c
>>> index a564f36e260c..5b6940c90c61 100644
>>> --- a/fs/io-wq.c
uring-worker.v3 series, as then you would not
have to touch io-wq at all.
--
Jens Axboe
On 2/21/21 12:38 PM, David Laight wrote:
> From: Jens Axboe
>> Sent: 20 February 2021 18:29
>>
>> On 2/20/21 10:44 AM, David Laight wrote:
>>> From: Lennert Buytenhek
>>>> Sent: 18 February 2021 12:27
>>>>
>>>> These patches add s
ating the list of directories to process.
> That should get the equivalent overlapping that io_uring gives
> without much of the complexity.
But this is what take the most offense to - it's _trivial_ to
write that program with io_uring, especially compared to managing
threads. Threads are certainly a more known paradigm at this point,
but an io_uring submit + reap loop is definitely not "much of the
complexity". If you're referring to the kernel change itself, that's
trivial, as the diffstat shows.
--
Jens Axboe
;)
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Maybe you meant
>
> Fixes: a4f2225d1cb2 ("io_uring: don't hold uring_lock when calling
> io_run_task_work*")
Fixed it up, thanks Stephen.
--
Jens Axboe
it-function-declaration]
>return io_sendmsg_prep_async(req);
> ^
> io_req_prep_async
>
> Reported-by: Naresh Kamboju
This should fix it, cleaning it up a bit at the same time.
commit b1c892df32ebf6f30c995e23dcafeae2392ad1bc
Author: Jens Axboe
Date: Fri
ep_async'; did you mean 'io_req_prep_async'?
>> [-Werror=implicit-function-declaration]
>>return io_sendmsg_prep_async(req);
>> ^
>> io_req_prep_async
>
> !CONFIG_NET, I guess. Thanks for letting know
Yep, I'm making a cleanup for that.
--
Jens Axboe
ed, 5 insertions(+), 5 deletions(-)
Applied for 5.12, thanks.
--
Jens Axboe
On 2/18/21 4:16 PM, Andrew Morton wrote:
> On Thu, 18 Feb 2021 14:36:31 -0700 Jens Axboe wrote:
>
>> Currently we cap the batch count at max(32, 2*nr_online_cpus), which these
>> days is kind of silly as systems have gotten much bigger than in 2009 when
>> this
tracks per-task inflight count
using percpu counters.
Signed-off-by: Jens Axboe
---
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index 00f666d94486..c3a9af5462ba 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -188,7 +188,7 @@ static int compute_batch_value(unsigned
/cgit/linux/kernel/git/axboe/linux-block.git
> dio-mem-align
This patch has been dropped, we did identify last week that btrfs
needs more work to support sub bs memory alignment for dio.
--
Jens Axboe
On 2/12/21 9:18 AM, Peter Zijlstra wrote:
> On Fri, Feb 12, 2021 at 08:26:56AM -0700, Jens Axboe wrote:
>> But I think I made a mistake in that it should've been sched/smp instead,
>> which would likely get rid of this issue too? I'll rebase it, it's just
>> a
On 2/12/21 8:33 AM, Aneesh Kumar K.V wrote:
> On 2/12/21 8:45 PM, Jens Axboe wrote:
>> On 2/11/21 11:59 PM, Aneesh Kumar K.V wrote:
>>>
>>> Hi,
>>>
>>> I am trying to estabilish the behaviour we should expect when passing a
>>> buffer with memo
;s just sched/core in a
topic branch, to satisfy a dependency.
But as mentioned in the previous email, I just need sched/smp to satisfy
that dependency. So I've rebased that small topic branch with that
pulled in instead. Won't solve the sched/core vs rcu tree conflict, but
at least it's out of my hands now :-)
--
Jens Axboe
hed/core looks like, because there was a dependency
for 2 block fixes from Sebastian:
https://git.kernel.dk/cgit/linux-block/log/?h=for-5.12/block-ipi
But I think I made a mistake in that it should've been sched/smp instead,
which would likely get rid of this issue too? I'll rebase it, it's just
a single topic branch with just those two patches on top.
--
Jens Axboe
o be the one that got all
> access
> allowed via keys or we could update that access is denied via kernel
> thread for any key value other than default key (key 0). Other option
> is to inherit the memory key restrictions when doing
> io_uring_submit() and use the same when accessing the userspace from
> kernel thread.
>
> Any thoughts here with respect to what should be behaviour?
It this a powerpc thing? I get -EFAULT on x86 for both reads, io_uring
and regular syscall. That includes SQPOLL, not using SQPOLL, or
explicitly setting IOSQE_ASYNC on the sqe.
--
Jens Axboe
On 2/10/21 4:51 PM, Kees Cook wrote:
> As started by commit 05a5f51ca566 ("Documentation: Replace lkml.org
> links with lore"), replace lkml.org links with lore to better use a
> single source that's more likely to stay available long-term.
Applied, thanks.
--
Jens Axboe
On 2/10/21 1:00 PM, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed.
Applied, thanks.
--
Jens Axboe
t for passing through inline crypto support
>> dm: support key eviction from keyslot managers of underlying devices
>> dm: set DM_TARGET_PASSES_CRYPTO feature for some targets
>>
>> block/blk-crypto.c | 1 +
>> block/keyslot-manager.c | 146 ++
>> drivers/md/dm-core.h| 5 +
>> drivers/md/dm-flakey.c | 4 +-
>> drivers/md/dm-linear.c | 5 +-
>> drivers/md/dm-table.c | 210
>> drivers/md/dm.c | 18 ++-
>> include/linux/device-mapper.h | 11 ++
>> include/linux/keyslot-manager.h | 11 ++
>> 9 files changed, 407 insertions(+), 4 deletions(-)
>>
>> --
>> 2.30.0.365.g02bc693789-goog
>>
>
> This set looks good to me now.
>
> To avoid DM needing another rebase on block: Jens (and others), would
> you like to review patches 1 and 2 (and reply with your Reviewed-by) so
> I could pickup the DM required keyslot-manager changes along with
> patches 3-5?
You can add my acked-by to 1+2 and queue it up.
--
Jens Axboe
On 2/6/21 12:10 AM, winnd...@163.com wrote:
> From: Liao Pingfang
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Applied, thanks.
--
Jens Axboe
q_update_next_in_service(struct
>>> bfq_sched_data *sd,
>>>
>>> sd->next_in_service = next_in_service;
>>>
>>> - if (!next_in_service)
>>> - return parent_sched_may_change;
>>> -
>
> Unless I'm missing something, this has already been fixed here:
>
> https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.12/block&id=1a23e06cdab2be07cbda460c6417d7de564c48e6
Yep indeed.
--
Jens Axboe
pening interrupts from within do_softirq().
Applied, thanks.
--
Jens Axboe
ooks like SQPOLL. I wonder if that's due to parked SQPOLL task that
> won't be able to do task_work run, and so reap poll-cancelled requests
> killed by io_put_deferred().
>
> I'll test it out tomorrow.
It is indeed SQPOLL. From a quick look, it's doing a POLL_ADD on the ring
fd itself.
--
Jens Axboe
On 2/8/21 7:42 PM, zangchun...@bytedance.com wrote:
> From: Chunxin Zang
>
> Change "sane" to "same" in a comment in io_uring.c
It's supposed to say 'sane'.
--
Jens Axboe
ble in the Git repository at:
>
> https://github.com/evdenis/linux-floppy tags/floppy-for-5.12
Pulled, thanks.
--
Jens Axboe
On 2/3/21 4:59 PM, Andres Freund wrote:
> Hi,
>
> On 2021-02-03 15:58:33 -0700, Jens Axboe wrote:
>> On 2/3/21 3:06 PM, Greg Kroah-Hartman wrote:
>>> On Wed, Feb 03, 2021 at 01:28:26PM -0800, Andres Freund wrote:
>>>> On 2021-02-03 14:03:09 +0100, Greg Kroah-
gt;>>
>>>> I haven't checked which major kernel version fixed this again, but I did
>>>> verify that it's still broken in 5.4.94 and that 5.10.9 works.
>>>>
>>>> I would suspect it's
>>>>
>>>> commit 4503b7
On 2/2/21 7:36 PM, Lin Feng wrote:
> Hi all,
>
> On 2/2/21 22:20, Jens Axboe wrote:
>> On 2/2/21 5:28 AM, Jan Kara wrote:
>>> Hello!
>>>
>>> On Fri 29-01-21 19:18:08, Lin Feng wrote:
>>>> This reverts commit 6d4d273588378c65915acaf7b2ee74e9
On 2/2/21 1:16 PM, Noah Goldstein wrote:
> Ping
It's already in.
--
Jens Axboe
but that's unrelated to your revert. So feel free to add:
>
> Reviewed-by: Jan Kara
I don't have the original patch (neither directly nor in the archive), so
I had to hand-apply it. In any case, applied for 5.11, thanks.
--
Jens Axboe
On 1/30/21 11:56 AM, Joe Perches wrote:
> On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
>> Use semicolons and braces.
>
> ping?
Queued for 5.12.
--
Jens Axboe
On 1/30/21 11:57 AM, Joe Perches wrote:
> On Mon, 2020-08-24 at 21:56 -0700, Joe Perches wrote:
>> Use semicolons and braces.
>
> ping?
Queued for 5.12.
--
Jens Axboe
ome Broadcom STB systems that do expect
> regulators to be turned on to link up with attached hard drives.
Applied, thanks.
--
Jens Axboe
z 20200507
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a3872cd0
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ab17a4d0
>>
>> The issue was bisected to:
>>
>> commit 02a13674fa0e8dd326de8b9f4514b41b03d99003
>> A
On 1/28/21 10:13 AM, Kanchan Joshi wrote:
> On Thu, Jan 28, 2021 at 8:08 PM Jens Axboe wrote:
>>
>> On 1/28/21 5:04 AM, Kanchan Joshi wrote:
>>> On Wed, Jan 27, 2021 at 9:32 PM Pavel Begunkov
>>> wrote:
>>>>
>>>> On 27/01/2021 15:42,
erything setup for it, and I'd rather avoid
having drivers touch any of those parts. Could be done by having an
io_uring helper ala:
io_uring_cmd_complete_in_task(cmd, handler);
which takes care of the nitty gritty details.
--
Jens Axboe
everything,
nothing ever will be, but should work for a lot of cases without
requiring per-command allocations just for the actual command.
> And for some ioctls, driver may still need to use task-work to update
> the user-space pointers (embedded in uring/ioctl cmd) during
> completion.
>
> @Jens - will it be fine if I start looking at plumbing nvme-part of
> this series on top of your work?
Sure, go ahead. Just beware that things are still changing, so you might
have to adapt it a few times. It's still early days, but I do think
that's the way forward in providing controlled access to what is
basically async ioctls.
--
Jens Axboe
On 1/28/21 12:18 AM, Baolin Wang wrote:
> Remove the obsolete 'MAX_KEY_LEN' macro.
Applied, thanks.
--
Jens Axboe
[ 4757.010705] kthread+0x108/0x138
Thanks, applied.
--
Jens Axboe
On 1/27/21 8:49 PM, Baolin Wang wrote:
>
>
> 在 2021/1/28 11:41, Jens Axboe 写道:
>> On 1/27/21 8:22 PM, Baolin Wang wrote:
>>> On !PREEMPT kernel, we can get below softlockup when doing stress
>>> testing with creating and destroying block cgroup repeatly. The
>
d_resched();
spin_lock_irq(&blkcg->lock);
+ continue;
}
+
+ blkg_destroy(blkg);
+ spin_unlock(&q->queue_lock);
}
spin_unlock_irq(&blkcg->lock);
--
Jens Axboe
rivers&id=294ed6b9f00665acc22253044890257c5d9d18c1
--
Jens Axboe
ound on this device) - that is
> likely related to other optimizations done between the faulty commit and
> 5.10.10 which also improved the read speed.
Can't argue with these numbers, and while this should probably get
fixed up instead, let's leave that for future kernels. I'll apply this
for 5.11, thanks.
--
Jens Axboe
On 1/21/21 2:43 AM, Yang Li wrote:
> Fix below warnings reported by coccicheck:
> ./drivers/block/rsxx/dma.c:948:3-8: WARNING: NULL check
> before some freeing functions is not needed.
Applied, thanks.
--
Jens Axboe
On 1/25/21 4:27 AM, chenle...@gmail.com wrote:
> From: Lei Chen
>
> The first parameter rwb is not used for this function.
> So just remove it.
Applied, thanks.
--
Jens Axboe
gt; drivers/block/mtip32xx/mtip32xx.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
Applied, thanks.
--
Jens Axboe
struct loop_device.
>
> Keep loop_ctl_mutex to protect global data: loop_index_idr, loop_lookup,
> loop_add.
>
> The new lock ordering requirement is that loop_ctl_mutex must be taken
> before lo_mutex.
Applied, thanks.
--
Jens Axboe
ssed in iter bvec.
Applied, thanks.
--
Jens Axboe
;&
> + (bfqq->waker_bfqq == bfqd->in_service_queue ||
> + bfqd->in_service_queue->waker_bfqq == bfqq)) ||
> + at_head || blk_rq_is_passthrough(rq)) {
> if (at_head)
> list_add(&rq->queuelist, &bfqd->dispatch);
> else
>
This is unreadable... Just seems like you are piling heuristics in to
catch some case, and it's neither readable nor clean.
--
Jens Axboe
mpty(&bfqq->woken_list) ?
> + container_of(bfqq->woken_list.first,
> + struct bfq_queue,
> + woken_list_node)
> + : NULL;
hlist_first_entry_or_null?
--
Jens Axboe
se code analyzer false warnings. Outside
of that, it needs a comment on why it's ok NOT to grab the lock when
bfqd is zero, because that seems counter-intuitive and more a case of
"well we can't grab a lock for something we don't have". Maybe it's
because bfqd is no longer visible at this point, and it's ok, but it's
definitely not clear just looking at this patch. Even with that, is the
bfqq visible? Should the ref be atomic, and locking happen further down
instead?
--
Jens Axboe
On 1/26/21 9:01 AM, Jan Kara wrote:
> On Tue 26-01-21 08:47:55, Jens Axboe wrote:
>> On 1/26/21 6:29 AM, Jan Kara wrote:
>>> On Mon 25-01-21 11:39:50, Jens Axboe wrote:
>>>> On 1/25/21 11:35 AM, Paolo Valente wrote:
>>>>>
>>>>>
&g
On 1/26/21 6:29 AM, Jan Kara wrote:
> On Mon 25-01-21 11:39:50, Jens Axboe wrote:
>> On 1/25/21 11:35 AM, Paolo Valente wrote:
>>>
>>>
>>>> Il giorno 25 gen 2021, alle ore 10:40, Stephen Rothwell
>>>> ha scritto:
>>>>
>>>
("io_uring: generalize io_queue_rsrc_removal")
> a63c1259317d ("io_uring: rename file related variables to rsrc")
>
> are missing a Signed-off-by from their author.
Fixed up, thanks.
--
Jens Axboe
ant
>>
>> Fixes: 13a857a4c4e8 ("block, bfq: detect wakers and unconditionally inject
>> their I/O")
>>
>
> Hi Jens,
> how to proceed in such a case (with patches already applied by you)?
> Shall I send you a v2 with only this change?
We just have to ignore it... But in the future, always double check that
you are using the right shas, not some sha from an internal tree.
--
Jens Axboe
+++--
> block/bfq-iosched.h | 29 ++--
> 2 files changed, 214 insertions(+), 143 deletions(-)
Applied, thanks.
--
Jens Axboe
On 1/19/21 5:33 AM, Pan Bian wrote:
> Free the request rq before returning error code.
Applied, thanks.
--
Jens Axboe
On 1/17/21 1:50 AM, Dinghao Liu wrote:
> Once we have called device_initialize(), we should use put_device() to
> give up the reference on error, just like what we have done on failure
> of device_add().
Applied for 5.11, thanks.
--
Jens Axboe
pening interrupts from within do_softirq().
>
> [0] https://lkml.kernel.org/r/1ee4b31b-350e-a9f5-4349-cfb34b898...@kernel.dk
I can queue up the block side once the IPI fix is in some stable branch
that I can pull in.
--
Jens Axboe
rformance improvements.
Applied, thanks.
--
Jens Axboe
ven though that's the name of the syscall.
Agreed, only case we do mimic the names are for things like
IORING_OP_OPENAT2 where it does carry meaning. For this one, it should
just be IORING_OP_GETDENTS.
--
Jens Axboe
On 1/23/21 11:16 AM, Lennert Buytenhek wrote:
> On Sat, Jan 23, 2021 at 10:37:25AM -0700, Jens Axboe wrote:
>
>>> IORING_OP_GETDENTS64 behaves like getdents64(2) and takes the same
>>> arguments.
>>>
>>> Signed-off-by: Lennert Buytenhek
>>>
/when these operations need to go async and finish
out-of-line, the contents are stable and there's no requirement for the
application to keep them valid once submission is done.
Not sure how best to solve that, since the vfs side relies heavily on
linux_dirent64 being a user pointer...
Outside of that, implementation looks straight forward.
--
Jens Axboe
we remove it? The project seems dead from my pov, and I don't
even remember anyone even reviewing fixes from other people.
--
Jens Axboe
On 12/23/20 8:02 PM, Yejune Deng wrote:
> The function io_remove_personalities() is very similar to
> io_unregister_personality(),so implement io_remove_personalities()
> calling io_unregister_personality().
Better late than never, applied for 5.12. Thanks.
--
Jens Axboe
021-01-08
09:14:21 -0700)
task_work-2021-01-19
----
Jens Axboe (1):
task_work: unconditionally run task_work from get_signal()
kernel/signal.c | 3 +++
1 file changed, 3 insertions(+)
--
Jens Axboe
#syz test: git://git.kernel.dk/linux-block io_uring-5.11
--
Jens Axboe
r setups like that. Think
of it like a strong hint.
Things aren't going to break if this CPU goes away and we end up being
affinitized to some other CPU, though it is suboptimal. So I guess we
might need some notifiers to ensure that we reset the CPU back again
if it's gone offline+online again? I can take a look at that.
--
Jens Axboe
On 1/8/21 9:10 AM, Jens Axboe wrote:
> On 1/8/21 8:58 AM, Al Viro wrote:
>> On Fri, Jan 08, 2021 at 08:13:25AM -0700, Jens Axboe wrote:
>>>> Anyway, bedtime for me; right now it looks like at least for task ==
>>>> current we always want TWA_SIGNAL. I'll lo
On 1/8/21 8:58 AM, Al Viro wrote:
> On Fri, Jan 08, 2021 at 08:13:25AM -0700, Jens Axboe wrote:
>>> Anyway, bedtime for me; right now it looks like at least for task ==
>>> current we always want TWA_SIGNAL. I'll look into that more tomorrow
>>> when I get up,
On 1/8/21 1:55 AM, John Garry wrote:
> Showing the hctx flags for when BLK_MQ_F_TAG_HCTX_SHARED is set gives
> something like:
>
> root@debian:/home/john# more /sys/kernel/debug/block/sda/hctx0/flags
> alloc_policy=FIFO SHOULD_MERGE|TAG_QUEUE_SHARED|3
Applied, thanks.
--
Jens Axboe
On 1/7/21 11:46 PM, Al Viro wrote:
> On Fri, Jan 08, 2021 at 05:26:51AM +, Al Viro wrote:
>> On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote:
>>> Song reported a boot regression in a kvm image with 5.11-rc, and bisected
>>> it down to the below patch. Debu
On 1/7/21 3:17 PM, Doug Anderson wrote:
> Hi,
>
> On Tue, Jan 5, 2021 at 10:30 AM Jens Axboe wrote:
>>
>> Song reported a boot regression in a kvm image with 5.11-rc, and bisected
>> it down to the below patch. Debugging this issue, turns out that the boot
>> st
201 - 300 of 3896 matches
Mail list logo
