>> How does fexecve() make anything possible here that wasn't possible
>> before? It seems to me that updating .so libraries has always
>> carried this risk, so I must be missing something.
> Without fexecve() it's at least theoretically possible to remove the
> old bins first, update the
On Sun, Sep 08, 2019 at 04:43:50PM -0400, Mouse wrote:
> > (2) Losing the command name isn't good; lots of people turn process
> > accounting on for logging (in fact, I'd assume 99.9% of people who
> > turn process accounting on use it purely for logging) and it
> > substantially decreases the
Truncating and resending to tech-kern@ as this message was dropped, as
too long.
On 23.09.2019 10:19, Kamil Rytarowski wrote:
> kern_rndq.c has a special corner case triggered by the fuzzer (1 hit in
> 2**32 attempts?).
>
> 393 /*
> 394 * Delta estimator for 32 or bit values. "Wrap"
> wd1 has bad blocks and is marked failed. I replace it and reconstruct
> the RAID with a new disk. But wd0 also has bad blocks, and RAIDframe
> will give up reconstruction because of the read failure.
My ideas/whishlist in this area:
-- Teach RAIDframe about TRIM so it knows which stripes
