[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <72fb7d8085a644e4a3e2e540a9ed6847@AcuMS.aculab.com>
Date: Mon, 27 Nov 2023 10:35:42 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Clément Léger' <cleger@...osinc.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Christoph Hellwig <hch@...radead.org>,
Ben Dooks <ben.dooks@...ethink.co.uk>,
kernel test robot <lkp@...el.com>
Subject: RE: [PATCH v2] riscv: fix incorrect use of __user pointer
From: Clément Léger
> Sent: 27 November 2023 10:24
>
> On 25/11/2023 16:37, David Laight wrote:
> > ...
> >> @@ -491,7 +486,7 @@ int handle_misaligned_load(struct pt_regs *regs)
> >>
> >> val.data_u64 = 0;
> >> for (i = 0; i < len; i++) {
> >> - if (load_u8(regs, (void *)(addr + i), &val.data_bytes[i]))
> >> + if (load_u8(regs, addr + i, &val.data_bytes[i]))
> >> return -1;
> >> }
> >
> > I'd really have thought that you'd want to pull the kernel/user
> > check way outside the loop?
>
> Hi David,
>
> I hope the compiler is able to extract that 'if' out of the loop since
> regs isn't modified in the loop. Nevertheless, that could be more
> "clear" if put outside indeed.
If has access regs->xxx then the compiler can't do so because it
will must assume that the assignment might alias into 'regs'.
That is even true for byte writes if 'strict-aliasing' is enabled
- which it isn't for linux kernel builds.
It might do so if 'regs' were 'const'; it tends to assume that if
it can't change something nothing can - although that isn't true.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists