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.
>>
>
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.
>
>> Does io_wq_manager() exits without cleaning up on SIGK
On 3/26/21 7:31 AM, Stefan Metzmacher wrote:
> Am 26.03.21 um 13:56 schrieb Jens Axboe:
>> On 3/26/21 5:48 AM, Stefan Metzmacher wrote:
>>>
>>> Am 26.03.21 um 01:39 schrieb Jens Axboe:
>>>> Hi,
>>>>
>>>> As discussed in a previous
On 3/26/21 5:48 AM, Stefan Metzmacher wrote:
>
> Am 26.03.21 um 01:39 schrieb Jens Axboe:
>> Hi,
>>
>> As discussed in a previous thread today, the seemingly much saner approach
>> is just to allow signals (including SIGSTOP) for the PF_IO_WORKER IO
>> threa
The io_uring PF_IO_WORKER threads no longer have PF_KTHREAD set, so no
need to special case them for credential checks.
Cc: Tetsuo Handa
Signed-off-by: Jens Axboe
---
security/tomoyo/network.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/tomoyo/network.c b
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 credential checks.
Cc: Casey Schaufler
Signed-off-by: Jens Axboe
---
security/smack/smack_access.c | 5 ++---
1 file changed, 2
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
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
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| 21 +
fs/io_uring.c | 10 --
2 files changed, 25
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
right way to do it
indeed. The fact that this series is 2/3rds revert further drives that
point home. Also thanks to Eric for diligent review on the signal side
of things for the past changes (and hopefully ditto on this series :-))
--
Jens Axboe
1 - 100 of 3898 matches
Mail list logo
