On Fri, 28 Sep 2018, Max Filippov wrote:
> On Fri, Sep 28, 2018 at 2:08 PM, Andy Lutomirski wrote:
> >> On Sep 28, 2018, at 1:26 PM, Thomas Gleixner wrote:
> >>
> >>> On Fri, 28 Sep 2018, Max Filippov wrote:
> >>>
> On Fri, Sep 28, 2018 at 11:02 AM, Andy Lutomirski
> wrote:
> The
On Fri, Sep 28, 2018 at 2:08 PM, Andy Lutomirski wrote:
>
>
>> On Sep 28, 2018, at 1:26 PM, Thomas Gleixner wrote:
>>
>>> On Fri, 28 Sep 2018, Max Filippov wrote:
>>>
On Fri, Sep 28, 2018 at 11:02 AM, Andy Lutomirski
wrote:
There may be a much nicer solution. Unless I missed som
> On Sep 28, 2018, at 1:26 PM, Thomas Gleixner wrote:
>
>> On Fri, 28 Sep 2018, Max Filippov wrote:
>>
>>> On Fri, Sep 28, 2018 at 11:02 AM, Andy Lutomirski
>>> wrote:
>>> There may be a much nicer solution. Unless I missed something, only
>>> mips and xtensa even have the possibility of c
On Fri, 28 Sep 2018, Max Filippov wrote:
> On Fri, Sep 28, 2018 at 11:02 AM, Andy Lutomirski wrote:
> > There may be a much nicer solution. Unless I missed something, only
> > mips and xtensa even have the possibility of cmpxchg being missing.
> > We could just make those arches supply a futex-d
On Fri, Sep 28, 2018 at 11:02 AM, Andy Lutomirski wrote:
> There may be a much nicer solution. Unless I missed something, only
> mips and xtensa even have the possibility of cmpxchg being missing.
> We could just make those arches supply a futex-detecting helper.
In case of xtensa availability o
On Fri, 28 Sep 2018, Andy Lutomirski wrote:
> On Fri, Sep 28, 2018 at 7:53 AM Martin Schwidefsky
> wrote:
> > On Fri, 28 Sep 2018 07:11:44 -0700 Andy Lutomirski
> > wrote:
> >
> > > There’s another way to skin this cat: keep KERNEL_DS but pass a valid
> > > pointer.
> > > I don’t suppose you r
On Fri, Sep 28, 2018 at 7:53 AM Martin Schwidefsky
wrote:
>
> On Fri, 28 Sep 2018 07:11:44 -0700
> Andy Lutomirski wrote:
>
> > > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> > >
> > >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> > >> On Fri, 28 Sep 2018 09:12:10 +0200
> > >> Geert
On Fri, 28 Sep 2018 07:11:44 -0700
Andy Lutomirski wrote:
> > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> >> On Fri, 28 Sep 2018 09:12:10 +0200
> >> Geert Uytterhoeven wrote:
> >>> I don't know if that has happened, and whet
On Fri, 28 Sep 2018, Andy Lutomirski wrote:
> > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> >> On Fri, 28 Sep 2018 09:12:10 +0200
> >> Geert Uytterhoeven wrote:
> >>> I don't know if that has happened, and whether it would work on
> On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
>
>> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
>> On Fri, 28 Sep 2018 09:12:10 +0200
>> Geert Uytterhoeven wrote:
>>> I don't know if that has happened, and whether it would work on s390 now.
>>
>> commit 03b8c7b623c80af264c4c8d6111e
On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> On Fri, 28 Sep 2018 09:12:10 +0200
> Geert Uytterhoeven wrote:
> > I don't know if that has happened, and whether it would work on s390 now.
>
> commit 03b8c7b623c80af264c4c8d6111e5c6289933666
> Author: Heiko Carstens
> Date: Sun Mar 2 13:09:47
On Fri, 28 Sep 2018 09:12:10 +0200
Geert Uytterhoeven wrote:
> Hi Thomas,
>
> On Fri, Sep 28, 2018 at 8:21 AM Thomas Gleixner wrote:
> > On Thu, 27 Sep 2018, Andy Lutomirski wrote:
> > > I have a couple questions here:
> > >
> > > - Is this actually okay on all architectures? That is, are t
On Fri, 28 Sep 2018, Geert Uytterhoeven wrote:
>
> On Fri, Sep 28, 2018 at 8:21 AM Thomas Gleixner wrote:
> > On Thu, 27 Sep 2018, Andy Lutomirski wrote:
> > > I have a couple questions here:
> > >
> > > - Is this actually okay on all architectures? That is, are there
> > >cases where we'll
Hi Thomas,
On Fri, Sep 28, 2018 at 8:21 AM Thomas Gleixner wrote:
> On Thu, 27 Sep 2018, Andy Lutomirski wrote:
> > I have a couple questions here:
> >
> > - Is this actually okay on all architectures? That is, are there
> >cases where we'll screw up if we fail a USER_DS access this early?
On Fri, 28 Sep 2018, Thomas Gleixner wrote:
> On Thu, 27 Sep 2018, Andy Lutomirski wrote:
> > I have a couple questions here:
> >
> > - Is this actually okay on all architectures? That is, are there
> >cases where we'll screw up if we fail a USER_DS access this early?
> >s390 stands out
On Thu, 27 Sep 2018, Andy Lutomirski wrote:
> I have a couple questions here:
>
> - Is this actually okay on all architectures? That is, are there
>cases where we'll screw up if we fail a USER_DS access this early?
>s390 stands out as the obvious special case (where USER_DS is not
>t
futex_detect_cmpxchg() checks whether cmpxchg is available by trying
it on the NULL pointer and seeing what the error code is (EFAULT vs
ENOSYS). This happens with KERNEL_DS set, which is impolite: while
the NULL *user* pointer is definitely invalid when there is no user
program running, the NULL
17 matches
Mail list logo