On 4/24/25 5:29 PM, Jakub Kicinski wrote:
> On Thu, 24 Apr 2025 17:09:28 -0600 Jens Axboe wrote:
>> On Sat, 19 Apr 2025 22:10:15 +0800, Haiyue Wang wrote:
>>> Use the API `sysconf()` to query page size at runtime, instead of using
>>> hard code number 4096.
>>
Get the page size at runtime
commit: 6f4cc653bf408ad0cc203c6ab3088b11f5da11df
Best regards,
--
Jens Axboe
in the normal
completion stream.
--
Jens Axboe
mpatible and inferior event system.
Exactly, this is how we do async IO elsewhere, not sure why networking
needs to be special here, and definitely not special in a good way.
--
Jens Axboe
On 3/21/25 10:36 AM, Joe Damato wrote:
> On Fri, Mar 21, 2025 at 05:14:59AM -0600, Jens Axboe wrote:
>> On 3/20/25 11:56 PM, Christoph Hellwig wrote:
>>>> I don't know the entire historical context, but I presume sendmsg
>>>> did that because there was no o
On 3/21/25 2:30 PM, Joe Damato wrote:
> On Fri, Mar 21, 2025 at 09:36:34AM -0700, Joe Damato wrote:
>> On Fri, Mar 21, 2025 at 05:14:59AM -0600, Jens Axboe wrote:
>>> On 3/20/25 11:56 PM, Christoph Hellwig wrote:
>>>>> I don't know the entire historical co
and stick with the splice changes only, if you are (at a high
> level) OK with the idea of adding a flag for this to splice.
>
> In the meantime, I'll take a few more reads through the iouring code
> to see if I can work out how sendfile2 might be built on top of that
> instead of splice in the kernel.
Heh I don't know how you jumped to that conclusion based on my feedback,
and seems like it's solidified through other replies. No I'm not saying
that the approach makes sense for the kernel, it makes some vague amount
of sense only on the premise of "oh but this is easy for applications as
they already know how to use sendfile(2)".
--
Jens Axboe
On 3/19/25 11:45 AM, Joe Damato wrote:
> On Wed, Mar 19, 2025 at 11:20:50AM -0600, Jens Axboe wrote:
>> On 3/19/25 11:04 AM, Joe Damato wrote:
>>> On Wed, Mar 19, 2025 at 10:07:27AM -0600, Jens Axboe wrote:
>>>> On 3/19/25 9:32 AM, Joe Damato wrote:
>>>>
On 3/19/25 11:04 AM, Joe Damato wrote:
> On Wed, Mar 19, 2025 at 10:07:27AM -0600, Jens Axboe wrote:
>> On 3/19/25 9:32 AM, Joe Damato wrote:
>>> On Wed, Mar 19, 2025 at 01:04:48AM -0700, Christoph Hellwig wrote:
>>>> On Wed, Mar 19, 2025 at 12:15:11AM +, Joe Dama
ing way to do accomplish this, with
free-to-reuse notifications". If the answer is "because splice", then it
would seem saner to plumb up those bits only. Would be much simpler
too...
--
Jens Axboe
On 1/16/25 1:02 PM, Paul E. McKenney wrote:
> This commit documents the fact that a given RCU callback function can
> repost itself.
Thanks for adding this!
--
Jens Axboe
On 10/2/24 10:02 AM, Mathieu Desnoyers wrote:
> On 2024-10-02 17:58, Jens Axboe wrote:
>> On 10/2/24 9:53 AM, Mathieu Desnoyers wrote:
>>> On 2024-10-02 17:36, Mathieu Desnoyers wrote:
>>>> On 2024-10-02 17:33, Matthew Wilcox wrote:
>>>>> On Wed, Oct 02
654 96-Core Processor
>> CPU family: 25
>> Model:17
>> Thread(s) per core: 2
>> Core(s) per socket: 96
>> Socket(s):2
>> Stepping: 1
>> Frequency boost: enabled
>>
, "iou-sqp-%d", sqd->task_pid);
set_task_comm(current, buf);
@@ -371,7 +375,7 @@ static int io_sq_thread(void *data)
atomic_or(IORING_SQ_NEED_WAKEUP, &ctx->rings->sq_flags);
io_run_task_work();
mutex_unlock(&sqd->lock);
-
+err_out:
complete(&sqd->exited);
do_exit(0);
}
--
Jens Axboe
h behave as-expected.
Should it? Seems like there's a very high risk of breaking existing use
cases here.
Have you at all looked into the approach of enabling splice to/from
_without_ holding the pipe lock? That, to me, would seem like a much
saner approach, with the caveat that I have not looked into that at all
so there may indeed be reasons why this is not feasible.
--
Jens Axboe
On 4/20/21 2:25 PM, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping: who can take this, please?
Applied, thanks.
--
Jens Axboe
r libata adds a break, this one annotates fallthrough. But the cases
are really 100% the same. Why aren't the changes consistent? Both are
obviously fine, but for identical cases it seems odd that they differ.
IMHO, adding a break makes more sense. Annotate the fallthrough if the
two cases share work that needs to be done, as then that solution makes
sense.
--
Jens Axboe
On 4/20/21 2:11 PM, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping: who can take this, please?
Applied for 5.13.
--
Jens Axboe
ring-submit
> [2] https://lore.kernel.org/io-uring/a08121be-f481-e9f8-b28d-3eb5d4f
> a5...@gmail.com/
This should be a backport of the 5.12 fix, not a separate patch.
--
Jens Axboe
On 4/19/21 8:41 AM, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 470ec4ed8c91b4db398ad607c700e9ce88365202
> Author: Jens Axboe
> Date: Fri Feb 26 17:20:34 2021 +
>
> io-wq: fix double put of 'wq' in error
s on BLK_DEV", I understand
> it is acceptable that LIBNVDIMM option to disappear from "make
> menuconfig" if BLK_DEV is not enabled.
>
> For such condition, which one is the proper way to set the dependence ?
> - Change "select LIBNVDIMM" and "select DAX" to "depends on LIBNVDIMM"
> and "depends on DAX" in bcache Kconfig
> - Or change "depends on BLK_DEV" to "select BLK_DEV" in nvdimm Kconfig.
The former.
--
Jens Axboe
in the block device
> initialization sequence.
>
> A simple check for debugfs_dir has been added to thwart premature
> debugfs directory/file creation attempts.
Applied, thanks.
--
Jens Axboe
sed on your branch for-5.13/drivers.
I have applied it, thanks.
--
Jens Axboe
ush_plug_list and
> has lots of indirect callers.)
Applied, with the bfq bits hand edited to apply for 5.13.
--
Jens Axboe
3 0.38813 39952 D R 24 [dmraid]
> 8,024 0.4435624 C R [0]
>
> This patch introduce a new wrapper to make code not that ugly.
Applied, thanks.
--
Jens Axboe
On 4/16/21 2:34 AM, Denis Efremov wrote:
> Just a couple of patches to make checkpatch.pl a bit more happy.
> All these patches preserve original semantics of the code and only
> memset(), memcpy() patches change binary code.
Applied, thanks.
--
Jens Axboe
On 4/13/21 5:14 PM, Dave Chinner wrote:
> On Tue, Apr 13, 2021 at 10:13:24AM -0600, Jens Axboe wrote:
>> On 4/13/21 1:51 AM, SeongJae Park wrote:
>>> From: SeongJae Park
>>>
>>> Hello,
>>>
>>>
>>> Very interesting work, thank you fo
On 4/13/21 1:51 AM, SeongJae Park wrote:
> From: SeongJae Park
>
> Hello,
>
>
> Very interesting work, thank you for sharing this :)
>
> On Tue, 13 Apr 2021 00:56:17 -0600 Yu Zhao wrote:
>
>> What's new in v2
>>
>> Special
?
Yep, I think that would make it the most painless for everyone.
Dan/Andrew, you can add my Acked-by to the series.
--
Jens Axboe
- io_resubmit_prep(req))
- fail = false;
-#endif
- if (fail) {
+ if (!(res == -EAGAIN && io_rw_should_reissue(req) &&
+ io_resubmit_prep(req))) {
req_set_fail_links(req);
req->flags |= REQ_F_DONT_REISSUE;
}
--
Jens Axboe
On 4/11/21 8:26 PM, Sowjanya Komatineni wrote:
>
> On 4/11/21 7:14 PM, Jens Axboe wrote:
>> On 4/11/21 4:34 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Commit
>>>
>>>6fa6517fe62e ("ata: ahci_tegra: call tegra_powergate_power_of
re OK with me adding your Signed-off-by to that
patch.
--
Jens Axboe
undeclared
>> (first use in this function)
>> 586 | __raw_writel(page_to_phys(bio_page(req->bio)) + bio_offset(rq->bio),
>> | ^~
>
> How about adding a Fixes: tag?
Indeed, that's definitely missing. I've added it and applied it.
--
Jens Axboe
position to
> keep the code format.
>
> ./drivers/ata/pata_ixp4xx_cf.c:168:5-8:
> WARNING: Unsigned expression compared with zero: irq > 0
Applied, thanks.
--
Jens Axboe
On 4/8/21 2:55 PM, Sowjanya Komatineni wrote:
> This patch adds check to call legacy power domain API
> tegra_powergate_power_off() only when PM domain is not present.
Applied, and added a Fixes line.
--
Jens Axboe
On 4/8/21 3:46 AM, Peter Zijlstra wrote:
>
> do_each_pid_thread() { } while_each_pid_thread() is a double loop and
> thus break doesn't work as expected. Also, it should be used under
> tasklist_lock because otherwise we can race against change_pid() for
> PGID/SID.
Applie
that it can be observed running outside
> of its allowed mask for potentially significant time.
>
> Use the proper API instead.
Applied, thanks Peter.
--
Jens Axboe
On 4/7/21 10:27 AM, Andy Shevchenko wrote:
> On Wed, Apr 07, 2021 at 10:04:49AM -0600, Jens Axboe wrote:
>> On 4/7/21 10:03 AM, Andy Shevchenko wrote:
>>> On Wed, Apr 07, 2021 at 11:51:31PM +0800, kernel test robot wrote:
>
> ...
>
>>>> All errors (new o
xed by >>):
>
> Thanks, we need to include bits.h.
> (It passed my simple build, but appears I have no such driver included)
>
> Jens, I saw your message, should I send a follow up fix, or a v2?
Let's just drop it, not worth it for the risk imho.
--
Jens Axboe
On 4/6/21 7:25 PM, Sowjanya Komatineni wrote:
> Re-sending dt-binding and ahci_tegra driver patches as v4 as device
> tree patches from v3 are merged but not the AHCI Tegra driver.
>
> Missed to add Jens Axboe to mailing list in v3. Adding for v4.
>
> This series adds support
On 4/7/21 7:47 AM, Andy Shevchenko wrote:
> There is no need to have kernel.h included, I do not see any
> direct users of it in ata.h. Drop unneeded inclusion of kernel.h.
Applied, thanks.
--
Jens Axboe
On 4/6/21 11:47 AM, Oleg Nesterov wrote:
> On 04/04, Jens Axboe wrote:
>>
>> +struct callback_head *task_work_cancel_match(struct task_struct *task,
>> +bool (*match)(struct callback_head *, void *data), void *data);
> ^^^
e, you could handle those in path_init() (or delay grabbing rcu_read_lock()
> in there, spreading it in a bunch of branches), but duplicated cleanup logics
> for a bunch of failure exits is asking for trouble.
Thanks for taking care of this Al, fwiw I'm (mostly) out on vacation.
--
Jens Axboe
On 4/6/21 6:09 AM, Huang Guobin wrote:
> From: Guobin Huang
>
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
Applied, thanks.
--
Jens Axboe
PATA adapter at the usual primary I/O location. They have also been
> verified (mainly for the correctness of MODULE_PARM_DESC use) with an
> x86/PC build (for pata_legacy) and a MIPS/SWARM build (for pata_platform).
Applied, thanks.
--
Jens Axboe
t;
> I am happy to take this series via the PCI tree but I'd need your
> ACK on this patch, please let me know if you are OK with it.
That'd be fine:
Acked-by: Jens Axboe
--
Jens Axboe
On 3/5/21 2:10 AM, Piyush Mehta wrote:
> Updated code with already prepared dev_err_probe(). It reduces code size
> and simplifies EPROBE_DEFER handling.
Applied, thanks.
--
Jens Axboe
On 3/12/21 3:55 AM, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Applied 2-11, 1 is already in the my tree.
--
Jens Axboe
of purely the callback function used.
task_work_cancel() can be trivially implemented on top of that, hence do
so.
Signed-off-by: Jens Axboe
---
I've got a patch on top of this that uses task_work_cancel_match(), but
sending this one out separately. There should be no functional chang
h the cracks, and I didn't notice
until I went and directly tested some of this...
iomap suffers from the same issue, fwiw.
--
Jens Axboe
+ io_uring]
>
> Hm, this reproducer uses io_uring and it's the io_uring_enter() that
> triggers this reliably. With this reproducer I've managed to reproduce
> the issue on v5.12-rc4, and v5.12-rc3, v5.12-rc2 and v5.12-rc1.
> It's not reproducible at
> 9820b4dca0f9c6b7ab8b4307286cdace171b724d
> which is the commit immediately before the first v5.12 io_uring merge.
> It's first reproducible with the first io_uring merge for v5.12, i.e.
> 5bbb336ba75d95611a7b9456355b48705016bdb1
Thanks, that's good info. I'll take a look at it and see if I can
reproduce.
--
Jens Axboe
.c:713)
> [ 47.862381] do_syscall_64 (kbuild/src/consumer/arch/x86/entry/common.c:46)
> [ 47.862443] entry_SYSCALL_64_after_hwframe
> (kbuild/src/consumer/arch/x86/entry/entry_64.S:112)
> [ 47.862526] RIP: 0033:0x7f5c66692a37
> [ 47.862586] Code: ff ff eb b6 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
> 48 8d 05 c9 7c 0d 00 49 89 ca 8b 00 85 c0 75 10 b8 12 00 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 59 c3 41 55 49 89 cd 41 54 49 89 d4 55 48 89
Thanks for the report, I've fixed this up in the current branch and
pushed a new one out.
--
Jens Axboe
On 3/15/21 5:29 AM, luojiaxing wrote:
>
> On 2021/3/12 22:27, Jens Axboe wrote:
>> Is this controller arm exclusive?
>
>
> Yes, our SoC is base on ARM64 only.
Applied, thanks.
--
Jens Axboe
error codes,
> and override the IRQ0 with -EINVAL (as we don't want the polling mode).
Applied, thanks.
--
Jens Axboe
On 3/18/21 2:51 AM, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> This is set 2 out of 2 sets required.
Applied, thanks.
--
Jens Axboe
b fb fb fb fb fb fb fb fb
>> 88801bf15080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> 88801bf15100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 88801bf15180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
#syz test: git://git.kernel.dk/linux-block for-5.13/io_uring
--
Jens Axboe
On 3/29/21 3:53 AM, Shixin Liu wrote:
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
Applied both, thanks.
--
Jens Axboe
xt4/ext4.h:3383 [inline]
> __ext4_new_inode+0x384f/0x5570 fs/ext4/ialloc.c:1188
> ext4_symlink+0x489/0xd50 fs/ext4/namei.c:3347
> vfs_symlink fs/namei.c:4176 [inline]
> vfs_symlink+0x10f/0x270 fs/namei.c:4161
> do_symlinkat+0x27a/0x300 fs/namei.c:4206
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
Same one that keeps happening, it's not related.
--
Jens Axboe
/x/repro.c?x=150764bed0
#syz test: git://git.kernel.dk/linux-block io_uring-5.12
--
Jens Axboe
On 3/27/21 11:40 AM, Eric W. Biederman wrote:
> Jens Axboe writes:
>
>> On 3/26/21 4:38 PM, Jens Axboe wrote:
>>> OK good point, and follows the same logic even if it won't make a
>>> difference in my case. I'll make the change.
>>
>> Made the
;
> kthread_frame_init(frame, sp, arg);
> return 0;
> }
Confirmed, it stops complaining about the arch at that point.
> I'm wondering if we should decouple the PF_KTHREAD and PF_IO_WORKER
> cases even more and keep as much of a userspace-like copy_thread as
> possible.
Probably makes sense, the only thing they really share is the func+arg
setup. Hence PF_IO_WORKER threads likely just use the rest of the init,
where it doesn't conflict with the frame setup.
--
Jens Axboe
quot;) added a generic infrastructure to achieve the same.
> Replace our bespoke solution with the generic one.
>
> Signed-off-by: Miroslav Benes
Looks good to me.
Reviewed-by: Jens Axboe
--
Jens Axboe
On 3/26/21 1:52 PM, Colin King wrote:
> From: Colin Ian King
>
> There is an assignment to io that is never read after the assignment,
> the assignment is redundant and can be removed.
Thanks, applied.
--
Jens Axboe
On 3/26/21 4:38 PM, Jens Axboe wrote:
> On 3/26/21 4:35 PM, Eric W. Biederman wrote:
>> Jens Axboe writes:
>>
>>> On 3/26/21 4:23 PM, Eric W. Biederman wrote:
>>>> Jens Axboe writes:
>>>>
>>>>> On 3/26/21 2:29 PM, Eric W. Biederman
On 3/26/21 4:35 PM, Eric W. Biederman wrote:
> Jens Axboe writes:
>
>> On 3/26/21 4:23 PM, Eric W. Biederman wrote:
>>> Jens Axboe writes:
>>>
>>>> On 3/26/21 2:29 PM, Eric W. Biederman wrote:
>>>>> Jens Axboe writes:
>>>&g
this one was actually re-added, which
does make sense. So don't think that one should be added to the list.
--
Jens Axboe
On 3/26/21 4:23 PM, Eric W. Biederman wrote:
> Jens Axboe writes:
>
>> On 3/26/21 2:29 PM, Eric W. Biederman wrote:
>>> Jens Axboe writes:
>>>
>>>> We go through various hoops to disallow signals for the IO threads, but
>>>> there's rea
On 3/26/21 2:29 PM, Eric W. Biederman wrote:
> Jens Axboe writes:
>
>> We go through various hoops to disallow signals for the IO threads, but
>> there's really no reason why we cannot just allow them. The IO threads
>> never return to userspace like a normal threa
On 3/26/21 2:43 PM, Eric W. Biederman wrote:
> Jens Axboe writes:
>
>> Right now we're never calling get_signal() from PF_IO_WORKER threads, but
>> in preparation for doing so, don't handle a fatal signal for them. The
>> workers have state they need to clean
On 3/26/21 12:01 PM, Stefan Metzmacher wrote:
> Am 26.03.21 um 16:29 schrieb Jens Axboe:
>> On 3/26/21 9:23 AM, Stefan Metzmacher wrote:
>>> Am 26.03.21 um 16:01 schrieb Jens Axboe:
>>>> On 3/26/21 7:48 AM, Oleg Nesterov wrote:
>>>>> Jens, sorry, I
On 3/26/21 10:03 AM, Casey Schaufler wrote:
> On 3/25/2021 5:44 PM, Jens Axboe wrote:
>> The io_uring PF_IO_WORKER threads no longer have PF_KTHREAD set, so no
>> need to special case them for credential checks.
>
> Could you cite the commit where that change was made?
See
On 3/26/21 10:00 AM, Casey Schaufler wrote:
> On 3/25/2021 5:42 PM, Jens Axboe wrote:
>> This reverts commit 942cb357ae7d9249088e3687ee6a00ed2745a0c7.
>>
>> The io_uring PF_IO_WORKER threads no longer have PF_KTHREAD set, so no
>> need to special case them for creden
On 3/26/21 9:51 AM, Jens Axboe wrote:
> Hi,
>
> For the v1 posting, see here:
Sigh, just ignore the last 4 patches (07...10/10) in this series,
there are sitting on top of this series and I messed up the git send-email.
This patch series ends in the 4 reverts.
--
Jens Axboe
org/r/72ace588772c0f14834a6a4185d56c445a366fb4.1616696997.git.asml.sile...@gmail.com
Signed-off-by: Jens Axboe
---
fs/io_uring.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 4d0cb2548a67..69896ae
nd so leads to extra
cancellations, that wasn't a case before per-task io-wq.
Signed-off-by: Pavel Begunkov
Link:
https://lore.kernel.org/r/0566c1de9b9dd417f5de345c817ca953580e0e2e.1616696997.git.asml.sile...@gmail.com
Signed-off-by: Jens Axboe
---
fs/io_uring.c | 2 --
1 file changed, 2 de
6b83.1616696997.git.asml.sile...@gmail.com
Signed-off-by: Jens Axboe
---
fs/io_uring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 69896ae204d6..4189e1b684e1 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -5563,7 +5563,8 @@ static int
This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5.
IO threads now take signals just fine, so there's no reason to limit them
specifically. Revert the change that prevented that from happening.
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 ---
1 file changed, 3 dele
-by: Jens Axboe
---
fs/io_uring.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 350418a88db3..4d0cb2548a67 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1247,7 +1247,7 @@ static void io_queue_async_work(struct io_kiocb *req
thout complaining. And once attached, it will allow
the usual introspection into regular threads.
Signed-off-by: Jens Axboe
---
kernel/ptrace.c | 2 +-
kernel/signal.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 821cf17
freezer.
Signed-off-by: Jens Axboe
---
kernel/freezer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 1a2d57d1327c..dc520f01f99d 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -134,7 +134,7 @@ bool freeze_task(struct
freezer.
Signed-off-by: Jens Axboe
---
kernel/freezer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 1a2d57d1327c..dc520f01f99d 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -134,7 +134,7 @@ bool freeze_task(struct
This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597.
The IO threads allow and handle SIGSTOP now, so don't special case them
anymore in task_set_jobctl_pending().
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/k
This reverts commit 4db4b1a0d1779dc159f7b87feb97030ec0b12597.
The IO threads allow and handle SIGSTOP now, so don't special case them
anymore in task_set_jobctl_pending().
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/k
thout complaining. And once attached, it will allow
the usual introspection into regular threads.
Signed-off-by: Jens Axboe
---
kernel/ptrace.c | 2 +-
kernel/signal.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 821cf17
as part
of the work loop, and call get_signal() to handle it for us if anything
is pending.
With that, we can support receiving signals, including special ones like
SIGSTOP.
Signed-off-by: Jens Axboe
---
fs/io-wq.c| 24 +---
fs/io_uring.c | 12
2 files c
This is racy - move the blocking into when the task is created and
we're marking it as PF_IO_WORKER anyway. The IO threads are now
prepared to handle signals like SIGSTOP as well, so clear that from
the mask to allow proper stopping of IO threads.
Reported-by: Oleg Nesterov
Signed-off-by:
This reverts commit 5be28c8f85ce99ed2d329d2ad8bdd18ea19473a5.
IO threads now take signals just fine, so there's no reason to limit them
specifically. Revert the change that prevented that from happening.
Signed-off-by: Jens Axboe
---
kernel/signal.c | 3 ---
1 file changed, 3 dele
calling
do_exit() on their behalf. The threads themselves will detect a fatal
signal and do proper shutdown.
Signed-off-by: Jens Axboe
---
kernel/signal.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index f2a1b898da29..e3e1b8fbfe8a 100644
--- a/
++
kernel/fork.c| 16
kernel/freezer.c | 2 +-
kernel/ptrace.c | 2 +-
kernel/signal.c | 19 ---
6 files changed, 47 insertions(+), 28 deletions(-)
--
Jens Axboe
On 3/26/21 9:45 AM, Tom Saeger wrote:
> On Fri, Mar 26, 2021 at 09:41:49AM -0600, Jens Axboe wrote:
>> On 3/25/21 9:04 PM, Tom Saeger wrote:
>>>
>>> s/Additonal/Additional/
>>> s/assocaited/associated/
>>> s/assocaited/associated/
>>>
dd complications to backports and stable patches, for example, and
I'd prefer not to take them for that reason alone.
--
Jens Axboe
On 3/26/21 9:23 AM, Stefan Metzmacher wrote:
> Am 26.03.21 um 16:01 schrieb Jens Axboe:
>> On 3/26/21 7:48 AM, Oleg Nesterov wrote:
>>> Jens, sorry, I got lost :/
>>
>> Let's bring you back in :-)
>>
>>> On 03/25, Jens Axboe wrote:
>>>
On 3/26/21 9:11 AM, Stefan Metzmacher wrote:
> Am 26.03.21 um 16:10 schrieb Jens Axboe:
>> On 3/26/21 9:08 AM, Stefan Metzmacher wrote:
>>> Am 26.03.21 um 15:55 schrieb Jens Axboe:
>>>> On 3/26/21 8:53 AM, Jens Axboe wrote:
>>>>> On 3/26/21 8:45 AM, S
On 3/26/21 9:08 AM, Stefan Metzmacher wrote:
> Am 26.03.21 um 15:55 schrieb Jens Axboe:
>> On 3/26/21 8:53 AM, Jens Axboe wrote:
>>> On 3/26/21 8:45 AM, Stefan Metzmacher wrote:
>>>> Am 26.03.21 um 15:43 schrieb Stefan Metzmacher:
>>>>> Am 26.03.21 um
On 3/26/21 9:04 AM, Stefan Metzmacher wrote:
>
> Am 26.03.21 um 15:53 schrieb Jens Axboe:
>> On 3/26/21 8:45 AM, Stefan Metzmacher wrote:
>>> Am 26.03.21 um 15:43 schrieb Stefan Metzmacher:
>>>> Am 26.03.21 um 15:38 schrieb Jens Axboe:
>>>>> On 3/26
On 3/26/21 7:48 AM, Oleg Nesterov wrote:
> Jens, sorry, I got lost :/
Let's bring you back in :-)
> On 03/25, Jens Axboe wrote:
>>
>> With IO threads accepting signals, including SIGSTOP,
>
> where can I find this change? Looks like I wasn't cc'ed...
On 3/26/21 8:53 AM, Jens Axboe wrote:
> On 3/26/21 8:45 AM, Stefan Metzmacher wrote:
>> Am 26.03.21 um 15:43 schrieb Stefan Metzmacher:
>>> Am 26.03.21 um 15:38 schrieb Jens Axboe:
>>>> On 3/26/21 7:59 AM, Jens Axboe wrote:
>>>>> On 3/26/21 7:54 AM,
On 3/26/21 8:45 AM, Stefan Metzmacher wrote:
> Am 26.03.21 um 15:43 schrieb Stefan Metzmacher:
>> Am 26.03.21 um 15:38 schrieb Jens Axboe:
>>> On 3/26/21 7:59 AM, Jens Axboe wrote:
>>>> On 3/26/21 7:54 AM, Jens Axboe wrote:
>>>>>> The KILL after
On 3/26/21 8:43 AM, Stefan Metzmacher wrote:
> Am 26.03.21 um 15:38 schrieb Jens Axboe:
>> On 3/26/21 7:59 AM, Jens Axboe wrote:
>>> On 3/26/21 7:54 AM, Jens Axboe wrote:
>>>>> The KILL after STOP deadlock still exists.
>>>>
>>>> In whic
On 3/26/21 7:59 AM, Jens Axboe wrote:
> On 3/26/21 7:54 AM, Jens Axboe wrote:
>>> The KILL after STOP deadlock still exists.
>>
>> In which tree? Sounds like you're still on the old one with that
>> incremental you sent, which wasn't complete.
>>
>
1 - 100 of 3909 matches
Mail list logo
