Ingo Schwarze writes:
Hello Ingo,
> Hi Gregoire,
>
> Gregoire Jadi wrote on Tue, Apr 17, 2018 at 11:44:41AM +0200:
>> Ingo Schwarze writes:
>
>>> Feedback is welcome both on the general idea and on the specific
>>> implementation.
>
> The result of that feeback was "we don't want it, the whole
Hi Gregoire,
Gregoire Jadi wrote on Tue, Apr 17, 2018 at 11:44:41AM +0200:
> Ingo Schwarze writes:
>> Feedback is welcome both on the general idea and on the specific
>> implementation.
The result of that feeback was "we don't want it, the whole
idea of changing this is pointless and dangerous"
Hi Stuart et al.,
Sorry for the delay. Meanwhile, I've been reproducing the
issue on 6.3 by adding device rd and increasing MINIROOTSIZE
to grow the non-gdb amd64 kernel beyond 16 MB. The kernel
simply fails to boot.
> If the kernel should grow to a point where we run past some limit, we'll fix
On Tue, 17 Apr 2018 09:50:49 +0200, Martin Pieuchot wrote:
> Sure, here's an updated diff. It also moves the FRELE(9) in the error
> loop down as suggested by visa@.
OK millert@
- todd
Ingo Schwarze writes:
Hi,
> Hi,
>
> Gregoire Jadi wrote on Fri, Mar 30, 2018 at 06:07:42PM +0200:
>
>> While working on a port of keyringer, I observed the following behavior
>> of rm(1) with the -P option: if the file does not have write permission,
>> the file is removed without being overwrit
Diff below introduces a new helper function to iterate on `filehead'.
This global data structures contains a reference to living 'struct file *'
so its access must be serialized with fdrop(). This is what the comment
below explains. Currently the serialization is done by the KERNEL_LOCK(),
but
On 16/04/18(Mon) 09:09, Todd C. Miller wrote:
> On Mon, 16 Apr 2018 10:19:40 +0200, Martin Pieuchot wrote:
>
> > Diff below does FREF(9) earlier instead of incrementing `f_count' by hand.
> >
> > The error path is also updated to call FRELE(9) accordingly.
>
> Wouldn't it be less error prone to s