Hi Jens,
>> I know you brought this one up as part of your series, not sure I get
>> why you want it owned by root and read-only? cmdline and exe, yeah those
>> could be hidden, but is there really any point?
>>
>> Maybe I'm missing something here, if so, do clue me in!
>
> I looked through
Hi Jens,
>> And /proc/$iothread/ should be read only and owned by root with
>> "cmdline" and "exe" being empty.
>
> I know you brought this one up as part of your series, not sure I get
> why you want it owned by root and read-only? cmdline and exe, yeah those
> could be hidden, but is there
On 3/25/21 3:57 PM, Stefan Metzmacher wrote:
>
> Am 25.03.21 um 22:44 schrieb Jens Axboe:
>> On 3/25/21 2:40 PM, Jens Axboe wrote:
>>> On 3/25/21 2:12 PM, Linus Torvalds wrote:
On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
wrote:
>
> On Thu, Mar 25, 2021 at 12:38 PM Linus
On 3/25/21 4:37 PM, Linus Torvalds wrote:
> On Thu, Mar 25, 2021 at 2:44 PM Jens Axboe wrote:
>>
>> In the spirit of "let's just try it", I ran with the below patch. With
>> that, I can gdb attach just fine to a test case that creates an io_uring
>> and a regular thread with pthread_create(). The
On Thu, Mar 25, 2021 at 2:44 PM Jens Axboe wrote:
>
> In the spirit of "let's just try it", I ran with the below patch. With
> that, I can gdb attach just fine to a test case that creates an io_uring
> and a regular thread with pthread_create(). The regular thread uses
> the ring, so you end up
Am 25.03.21 um 22:44 schrieb Jens Axboe:
> On 3/25/21 2:40 PM, Jens Axboe wrote:
>> On 3/25/21 2:12 PM, Linus Torvalds wrote:
>>> On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
>>> wrote:
On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
wrote:
>
> I don't know what the
On 3/25/21 2:43 PM, Eric W. Biederman wrote:
> Linus Torvalds writes:
>
>> On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
>> wrote:
>>>
>>> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
>>> wrote:
I don't know what the gdb logic is, but maybe there's some other
option that
Am 25.03.21 um 22:20 schrieb Stefan Metzmacher:
>
> Am 25.03.21 um 21:55 schrieb Eric W. Biederman:
>> Oleg Nesterov writes:
>>
>>> On 03/25, Linus Torvalds wrote:
The whole "signals are very special for IO threads" thing has caused
so many problems, that maybe the solution is
On 3/25/21 2:40 PM, Jens Axboe wrote:
> On 3/25/21 2:12 PM, Linus Torvalds wrote:
>> On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
>> wrote:
>>>
>>> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
>>> wrote:
I don't know what the gdb logic is, but maybe there's some other
option
Am 25.03.21 um 21:55 schrieb Eric W. Biederman:
> Oleg Nesterov writes:
>
>> On 03/25, Linus Torvalds wrote:
>>>
>>> The whole "signals are very special for IO threads" thing has caused
>>> so many problems, that maybe the solution is simply to _not_ make them
>>> special?
>>
>> Or may be IO
Oleg Nesterov writes:
> On 03/25, Linus Torvalds wrote:
>>
>> The whole "signals are very special for IO threads" thing has caused
>> so many problems, that maybe the solution is simply to _not_ make them
>> special?
>
> Or may be IO threads should not abuse CLONE_THREAD?
>
> Why does
Oleg Nesterov writes:
> On 03/25, Eric W. Biederman wrote:
>>
>> So looking quickly the flip side of the coin is gdb (and other
>> debuggers) needs a way to know these threads are special, so it can know
>> not to attach.
>
> may be,
>
>> I suspect getting -EPERM (or possibly a different error
Linus Torvalds writes:
> On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
> wrote:
>>
>> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
>> wrote:
>> >
>> > I don't know what the gdb logic is, but maybe there's some other
>> > option that makes gdb not react to them?
>>
>> .. maybe we could
On 03/25, Linus Torvalds wrote:
>
> The whole "signals are very special for IO threads" thing has caused
> so many problems, that maybe the solution is simply to _not_ make them
> special?
Or may be IO threads should not abuse CLONE_THREAD?
Why does create_io_thread() abuse CLONE_THREAD ?
One
On 3/25/21 2:40 PM, Oleg Nesterov wrote:
> On 03/25, Eric W. Biederman wrote:
>>
>> So looking quickly the flip side of the coin is gdb (and other
>> debuggers) needs a way to know these threads are special, so it can know
>> not to attach.
>
> may be,
>
>> I suspect getting -EPERM (or possibly
On 3/25/21 2:21 PM, Eric W. Biederman wrote:
> Jens Axboe writes:
>
>> On 3/25/21 1:42 PM, Linus Torvalds wrote:
>>> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
>>> wrote:
I don't know what the gdb logic is, but maybe there's some other
option that makes gdb not react to
On 3/25/21 2:12 PM, Linus Torvalds wrote:
> On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
> wrote:
>>
>> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
>> wrote:
>>>
>>> I don't know what the gdb logic is, but maybe there's some other
>>> option that makes gdb not react to them?
>>
>> ..
On 03/25, Eric W. Biederman wrote:
>
> So looking quickly the flip side of the coin is gdb (and other
> debuggers) needs a way to know these threads are special, so it can know
> not to attach.
may be,
> I suspect getting -EPERM (or possibly a different error code) when
> attempting attach is
I didn't even try to read this series yet, will try tomorrow.
But sorry, I can't resist...
On 03/25, Jens Axboe wrote:
>
> On 3/25/21 1:33 PM, Eric W. Biederman wrote:
> > Jens Axboe writes:
> >
> >> Hi,
> >>
> >> Stefan reports that attaching to a task with io_uring will leave gdb
> >> very
Jens Axboe writes:
> On 3/25/21 1:42 PM, Linus Torvalds wrote:
>> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
>> wrote:
>>>
>>> I don't know what the gdb logic is, but maybe there's some other
>>> option that makes gdb not react to them?
>>
>> .. maybe we could have a different name for
On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds
wrote:
>
> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
> wrote:
> >
> > I don't know what the gdb logic is, but maybe there's some other
> > option that makes gdb not react to them?
>
> .. maybe we could have a different name for them under the
On 3/25/21 1:42 PM, Linus Torvalds wrote:
> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
> wrote:
>>
>> I don't know what the gdb logic is, but maybe there's some other
>> option that makes gdb not react to them?
>
> .. maybe we could have a different name for them under the task/
>
On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds
wrote:
>
> I don't know what the gdb logic is, but maybe there's some other
> option that makes gdb not react to them?
.. maybe we could have a different name for them under the task/
subdirectory, for example (not just the pid)? Although that
On 3/25/21 1:38 PM, Linus Torvalds wrote:
> On Thu, Mar 25, 2021 at 12:34 PM Eric W. Biederman
> wrote:
>>
>> 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
On 3/25/21 1:33 PM, Eric W. Biederman wrote:
> Jens Axboe 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
On Thu, Mar 25, 2021 at 12:34 PM Eric W. Biederman
wrote:
>
> 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
Jens Axboe 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
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
28 matches
Mail list logo
