On 3/25/21 1:33 PM, Eric W. Biederman wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: > >> Hi, >> >> Stefan reports that attaching to a task with io_uring will leave gdb >> very confused and just repeatedly attempting to attach to the IO threads, >> even though it receives an -EPERM every time. This patchset proposes to >> skip PF_IO_WORKER threads as same_thread_group(), except for accounting >> purposes which we still desire. >> >> We also skip listing the IO threads in /proc/<pid>/task/ so that gdb >> doesn't think it should stop and attach to them. This makes us consistent >> with earlier kernels, where these async threads were not related to the >> ring owning task, and hence gdb (and others) ignored them anyway. >> >> Seems to me that this is the right approach, but open to comments on if >> others agree with this. Oleg, I did see your messages as well on SIGSTOP, >> and as was discussed with Eric as well, this is something we most >> certainly can revisit. I do think that the visibility of these threads >> is a separate issue. Even with SIGSTOP implemented (which I did try as >> well), we're never going to allow ptrace attach and hence gdb would still >> be broken. Hence I'd rather treat them as separate issues to attack. > > A quick skim shows that these threads are not showing up anywhere in > proc which appears to be a problem, as it hides them from top. > > Sysadmins need the ability to dig into a system and find out where all > their cpu usage or io's have gone when there is a problem. I general I > think this argues that these threads should show up as threads of the > process so I am not even certain this is the right fix to deal with gdb. That's a good point, overall hiding was not really what I desired, just getting them out of gdb's hands. And arguably it _is_ a gdb bug, but... -- Jens Axboe
