[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v8e0m26q.ffs@tglx>
Date: Mon, 31 Jul 2023 19:16:29 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>, axboe@...nel.dk
Cc: linux-kernel@...r.kernel.org, peterz@...radead.org,
mingo@...hat.com, dvhart@...radead.org, dave@...olabs.net,
andrealmeid@...lia.com, Andrew Morton <akpm@...ux-foundation.org>,
urezki@...il.com, hch@...radead.org, lstoakes@...il.com,
Arnd Bergmann <arnd@...db.de>, linux-api@...r.kernel.org,
linux-mm@...ck.org, linux-arch@...r.kernel.org,
malteskarupke@....de
Subject: Re: [PATCH v1 02/14] futex: Extend the FUTEX2 flags
On Mon, Jul 31 2023 at 18:11, Thomas Gleixner wrote:
> On Fri, Jul 21 2023 at 12:22, Peter Zijlstra wrote:
>> -#define FUTEX2_MASK (FUTEX2_32 | FUTEX2_PRIVATE)
>> +#define FUTEX2_MASK (FUTEX2_64 | FUTEX2_PRIVATE)
>>
>> /**
>> * futex_parse_waitv - Parse a waitv array from userspace
>> @@ -207,7 +207,12 @@ static int futex_parse_waitv(struct fute
>> if ((aux.flags & ~FUTEX2_MASK) || aux.__reserved)
>> return -EINVAL;
>
> With the above aux.flags with FUTEX2_32 set will result in -EINVAL. I
> don't think that's intentional.
Also if you allow 64bit wide futexes, how is that supposed to work with
the existing code, which clearly expects a 32bit uval throughout the
place?
Thanks,
tglx
Powered by blists - more mailing lists