On Fri, Jul 10, 2020 at 08:41:40PM +0700, Robert Elz wrote:
> I have spent a little time looking at this now, and I think
> it is just all a mess.
Indeed...
> As best I can work out, and someone correct me if I'm wrong,
> the whole purpose of pg_jobc is so that orphanpg() can be called
>
>> [...] I'd be astonished if there aren't at least a few programs
>> [in pkgsrc] that grub around in things like this.
> No question, there are, but this particular field seems very unlikely
> to have any users - really really unlikely.
Especially since, come to think of it, the value is
In article <27763.1594388...@jinx.noi.kre.to>,
Robert Elz wrote:
>Date:Tue, 9 Jun 2020 08:23:19 - (UTC)
>From:mlel...@serpens.de (Michael van Elst)
>Message-ID:
>
>I have spent a little time looking at this now, and I think
>it is just all a mess.
>
> | pg_jobc
Date:Fri, 10 Jul 2020 16:47:28 +0200
From:Rhialto
Message-ID: <20200710144728.gy3...@falu.nl>
| It also seems to be involved in deciding wether to send a SIGTTOU or
| SIGTTIN to a process
Ah, right, thanks ... when I was reviewing uses in the kernel I
was
On Fri 10 Jul 2020 at 20:41:40 +0700, Robert Elz wrote:
> As best I can work out, and someone correct me if I'm wrong,
> the whole purpose of pg_jobc is so that orphanpg() can be called
> when a process group is orphaned (no longer has a session leader).
>
> If it has any other use, I cannot see
On 10.07.2020 15:41, Robert Elz wrote:
> Unfortunately
> I have no idea what "qualifying pgrp for job control" is supposed to mean.
The Design and implementation of 4.4book phrases it as: number of
processes with parent controlling terminal.
Unfortunately the book does not explain whether
> [... pg_jobc ...]
> I see 3 ways forward...
I count 4, but maybe kre is counting two of them as subclasses of a
single one.
> simply drop the KASSERT the way that FreeBSD have done, and let
> things return to the semi-broken but rarely bothersome code that was
> there before.
> Or, we could
Date:Tue, 9 Jun 2020 08:23:19 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
I have spent a little time looking at this now, and I think
it is just all a mess.
| pg_jobc is not a reference counter.
Maybe not technically a "reference" counter,
Date:Mon, 29 Jun 2020 23:22:52 +0200
From:Kamil Rytarowski
Message-ID:
| Ping? This kernel crash is blocking GDB/etc and it is an instant crash.
Sorry, been side-tracked, will get to it soon.
kre
On 09.06.2020 20:11, Robert Elz wrote:
> Date:Tue, 9 Jun 2020 17:04:54 +0200
> From:Kamil Rytarowski
> Message-ID:
>
>
> | Yes... syzkaller had like 12 different ways to reproduce it.
>
> OK, thanks.
>
> | There is still a race and we randomly go to negative
Date:Tue, 9 Jun 2020 14:16:16 -0400
From:Christos Zoulas
Message-ID:
| The FreeBSD refactoring LGTM. It also simplifies the code.
Sorry, been off net all day ... that may very well be the way to go,
but I'd like to understand what is happening with our current
The FreeBSD refactoring LGTM. It also simplifies the code.
christos
> On Jun 9, 2020, at 2:11 PM, Robert Elz wrote:
>
>Date:Tue, 9 Jun 2020 17:04:54 +0200
>From:Kamil Rytarowski
>Message-ID:
>
>
> | Yes... syzkaller had like 12 different ways to reproduce it.
Date:Tue, 9 Jun 2020 17:04:54 +0200
From:Kamil Rytarowski
Message-ID:
| Yes... syzkaller had like 12 different ways to reproduce it.
OK, thanks.
| There is still a race and we randomly go to negative pg_jobc.
I am not at all surprised...
I will look at it
On 09.06.2020 16:35, Robert Elz wrote:
> Date:Tue, 9 Jun 2020 14:13:56 +0200
> From:Kamil Rytarowski
> Message-ID: <85d5e51f-afd1-1038-fd68-2366ff073...@netbsd.org>
>
> | Here is the simplest reproducer crashing the kernel on negative pg_jobc:
>
> I have not
Date:Tue, 9 Jun 2020 14:13:56 +0200
From:Kamil Rytarowski
Message-ID: <85d5e51f-afd1-1038-fd68-2366ff073...@netbsd.org>
| Here is the simplest reproducer crashing the kernel on negative pg_jobc:
I have not looked at this closely yet, but this is likely because
On 09.06.2020 08:38, Maxime Villard wrote:
>> Should we allow pg_jobc going negative?
>
> I don't think so, the code is not designed to expect negative values.
Here is the simplest reproducer crashing the kernel on negative pg_jobc:
http://netbsd.org/~kamil/ptrace/pg_jobc-crash.c
O
On 09.06.2020 10:23, Michael van Elst wrote:
> m...@m00nbsd.net (Maxime Villard) writes:
>
>> You can see they are all different, but all have to do with reading the
>> group pointer, which was either freed, overwritten, not initialized,
>> unmapped, or contained pure garbage. This is typical of
m...@m00nbsd.net (Maxime Villard) writes:
>You can see they are all different, but all have to do with reading the
>group pointer, which was either freed, overwritten, not initialized,
>unmapped, or contained pure garbage. This is typical of refcounting bugs
>where a resource disappears under
mo...@rodents-montreal.org (Mouse) writes:
>> pg_jobc is a process group struct member counting the number of
>> processes with [...]
>> [W]e caught issues that pg_jobc can go negative. [...]
>> Is going negative in the first place a real bug?
>I would say, yes. A "count of processes with
ble triggering a negative pg_jobc,
however there are racy tests doing the same as triggered by syzkaller
(mentioned at least in [1]).
Should we allow pg_jobc going negative?
I don't think so, the code is not designed to expect negative values.
(Other BSDs allow this.)
They don't &qu
> pg_jobc is a process group struct member counting the number of
> processes with [...]
> [W]e caught issues that pg_jobc can go negative. [...]
> Is going negative in the first place a real bug?
I would say, yes. A "count of processes with [condition]" cannot ever
truly be negative.
The
ver there are racy tests doing the same as triggered by syzkaller
(mentioned at least in [1]).
Should we allow pg_jobc going negative? (Other BSDs allow this.)
Is going negative in the first place a real bug?
Are the races triggered by syzkaller real bugs?
[1] http://mail-index.netbsd.org/current-users/2020
22 matches
Mail list logo
