Hello,
On Thu, Mar 03, 2016 at 08:46:41AM +0100, Sedat Dilek wrote:
> One technical question:
> How do I get the latest Linux version shipped userfaultfd first?
> ( Maybe there exist more elegant ways I do. Always open to improve my
> Git knowledge. )
Perhaps there are cleaner ways, I would do th
On 3/3/16, Linus Torvalds wrote:
> On Mar 2, 2016 23:14, "Sedat Dilek" wrote:
>>
>> Is that commit [1] Linux-4.5 material or affects other versions, too?
>
> Hmm. I guess this affects anything with userfaultfd.
>
OK, Linux v4.4.y LTS has userfaultfd - is affected.
Just anorganizational question
On 3/2/16, Linus Torvalds wrote:
> On Wed, Mar 2, 2016 at 6:55 AM, Andrea Arcangeli
> wrote:
>>
>> Running page faults that late in the exit path with signal disabled
>> was frankly unexpected.
>
> I agree that it's less than wonderful.
>
>>Apparently it's not just
>> PF_EXITING that prev
On Wed, Mar 02, 2016 at 09:03:01AM -0800, Linus Torvalds wrote:
> It's not just "exit_futex()" (what is that? I assume you mean
That come from a cleanup (appended below but not very well tested) I
did initially to consolidate the futex exit code before attempting to
relocate its call location.
>
On Wed, Mar 2, 2016 at 6:55 AM, Andrea Arcangeli wrote:
>
> Running page faults that late in the exit path with signal disabled
> was frankly unexpected.
I agree that it's less than wonderful.
>Apparently it's not just
> PF_EXITING that prevents SIGKILL to reach handle_userfault(). The
>
Hello,
On Wed, Mar 02, 2016 at 12:48:46AM +, Al Viro wrote:
> On Tue, Mar 01, 2016 at 12:06:49PM -0800, Linus Torvalds wrote:
>
> > So the only access we really care about is the child tid-pointer
> > clearing one, and that always happens after PF_EXITING has been set
> > afaik.
> >
> > No o
On Tue, Mar 1, 2016 at 9:28 PM, Linus Torvalds
wrote:
> On Tue, Mar 1, 2016 at 11:56 AM, Linus Torvalds
> wrote:
>>
>> (The above patches are entirely untested, maybe I misread the reason
>> it might be hanging and it's something else going on).
>
> Ok, I did some half-arsed testing. I didn't hav
On Tue, Mar 01, 2016 at 12:06:49PM -0800, Linus Torvalds wrote:
> So the only access we really care about is the child tid-pointer
> clearing one, and that always happens after PF_EXITING has been set
> afaik.
>
> No other case really matters. If somebody accesses a userfault region
> just as ano
On Tue, Mar 1, 2016 at 11:56 AM, Linus Torvalds
wrote:
>
> (The above patches are entirely untested, maybe I misread the reason
> it might be hanging and it's something else going on).
Ok, I did some half-arsed testing. I didn't have a kernel with
USERFAULT enabled, but I did compile one with bot
On Tue, Mar 1, 2016 at 11:59 AM, Al Viro wrote:
> On Tue, Mar 01, 2016 at 11:56:22AM -0800, Linus Torvalds wrote:
>> (a) special-case the PF_EXITING case for usefaultfd, something like
>>
>> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
>> index 50311703135b..66cdb44616d5 100644
>>
On Tue, Mar 01, 2016 at 11:56:22AM -0800, Linus Torvalds wrote:
> (a) special-case the PF_EXITING case for usefaultfd, something like
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 50311703135b..66cdb44616d5 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
>
On Tue, Mar 1, 2016 at 3:29 AM, Dmitry Vyukov wrote:
>
> The following program creates an unkillable process in D state:
It seems to be usefaultfd that *tries* to handle signals, but there's
one special fault case where signals won't make it through: when we're
exiting and doing the final child p
12 matches
Mail list logo
