Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c"

Arnd Bergmann arnd at arndb.de
Fri Oct 23 01:28:20 AEDT 2020


On Thu, Oct 22, 2020 at 3:50 PM Greg KH <gregkh at linuxfoundation.org> wrote:
> On Thu, Oct 22, 2020 at 02:57:59PM +0200, Greg KH wrote:
> > On Thu, Oct 22, 2020 at 02:42:24PM +0200, David Hildenbrand wrote:

> > >  struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > > -               unsigned long nr_segs, unsigned long fast_segs,
> > > +               unsigned nr_segs, unsigned fast_segs,
> > >                 struct iovec *fast_iov, bool compat)
> > >  {
> > >         struct iovec *iov = fast_iov;
> > > @@ -1738,7 +1738,7 @@ ssize_t __import_iovec(int type, const struct
> > > iovec __user *uvec,
> > >                  struct iov_iter *i, bool compat)
> > >  {
> > >         ssize_t total_len = 0;
> > > -       unsigned long seg;
> > > +       unsigned seg;
> > >         struct iovec *iov;
> > >
> > >         iov = iovec_from_user(uvec, nr_segs, fast_segs, *iovp, compat);
> > >
> >
> > Ah, I tested the other way around, making everything "unsigned long"
> > instead.  Will go try this too, as other tests are still running...
>
> Ok, no, this didn't work either.
>
> Nick, I think I need some compiler help here.  Any ideas?

I don't think the patch above would reliably clear the upper bits if they
contain garbage.

If the integer extension is the problem, the way I'd try it is to make the
function take an 'unsigned long' and then explictly mask the upper
bits with

     seg = lower_32_bits(seg);

Can you attach the iov_iter.s files from the broken build, plus the
one with 'noinline' for comparison? Maybe something can be seen
in there.

       Arnd


More information about the Linuxppc-dev mailing list