Python is essentially uncrosscompilable and its maintainers have repeatedly
rudely rejected efforts to make it so.
If that weren't the case, and the way installed Python modules were "managed"
(I use the term liberally) were made sane, I'd think it were a fine thing to
use in base. But it is the
i'm not very interested in a solution that doesn't use tools
available to the build. you've not shown that there is
sufficient pain here to force an external solution. i'm not
sure i buy your claims about awk and size of program. IME,
it just requires that one is strict to rules.
if you want
On 10.06.2020 01:13, David Holland wrote:
> The question is: do we want the Python version in the tree now
For this, I would say "NO", at least as long Python is out of base and
IMO it shall not be there.
But it is fine to put into othersrc/.
On 10.06.2020 01:13, David Holland wrote:
>
Between various forms of prompting I got tired of waiting for a gsoc
student to take up code generation for syscall argument handling. We
should really be generating all the calls to copyin/copyout, not to
mention all the compat32 and compat_* glue, not maintaining them by
hand. More on that
On Tue, Jun 09, 2020 at 05:16:27PM +, Taylor R Campbell wrote:
> It's great to see improvements to our calibration of the TSC (and I
> tend to agree that cpu_counter should be serializing, so that, e.g.,
> cpu_counter(); ...; cpu_counter() reliably measures time taken in the
> ellipsis).
I'm
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
It's great to see improvements to our calibration of the TSC (and I
tend to agree that cpu_counter should be serializing, so that, e.g.,
cpu_counter(); ...; cpu_counter() reliably measures time taken in the
ellipsis).
At the same time, I wonder whether we should _also_:
1. Modify the tsc
.tgz
Diff is at:
http://www.netbsd.org/~msaitoh/tsc/tsc-20200609-0.dif
In this diff, cpu_counter*(those functions are MI API) uses serializing.
We can provide both cpu_counter() and cpu_counter_serializing(). I think
almost all usecases requires serializing on x86. For RNG, serializing i
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
On 09.06.2020
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
Le 09/06/2020 à 02:49, Kamil Rytarowski a écrit :
pg_jobc is a process group struct member counting the number of
processes with a parent capable of doing job control. Once reaching 0,
the process group is orphaned.
With the addition of asserts checking for pg_jobc > 0 (by maxv@), we
caught
16 matches
Mail list logo
