[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210621142833.GB186979@ojas>
Date: Mon, 21 Jun 2021 19:58:33 +0530
From: Ojaswin Mujoo <ojaswin98@...il.com>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: nsaenz@...nel.org, gregkh@...uxfoundation.org,
stefan.wahren@...e.com, arnd@...db.de, phil@...pberrypi.com,
bcm-kernel-feedback-list@...adcom.com,
linux-arm-kernel@...ts.infradead.org,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/5] staging: vchiq: Move vchiq char driver to its own
file
On Mon, Jun 21, 2021 at 12:56:31PM +0300, Dan Carpenter wrote:
> On Sun, Jun 20, 2021 at 06:26:34PM +0530, Ojaswin Mujoo wrote:
> > +/* read a user pointer value from an array pointers in user space */
> > +static inline int vchiq_get_user_ptr(void __user **buf, void __user *ubuf, int index)
> > +{
> > + int ret;
> > +
> > + if (in_compat_syscall()) {
> > + compat_uptr_t ptr32;
> > +
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> When I'm reviewing these sorts of patches then what I'm trying to verify
> is that you are not a UMN "researcher" trying to change the code without
> anyone noticing. In the orignal code, there was no blank line here
>
> > + compat_uptr_t __user *uptr = ubuf;
>
> but there was a blank line here.
>
> > + ret = get_user(ptr32, uptr + index);
> > + *buf = compat_ptr(ptr32);
> > + } else {
>
> These sorts of minor white space changes make it hard to verify the code
> in an automated way.
>
Ohh I see, I get the point. I'm not sure how this creeped in here.
Especially with this patch, the git diff looks very ugly and confusing
to me. I'm not sure if that is because I unknownigly introduced some
whitespace changes or if thats normal when shifting a lof of code
around. Anyways, I'll fix this in the next revision.
PS: I was unable to get mainline kernel working on my Pi and instead
submitted this patch which is built against the raspberry downstream
kernel. I now know this definitely not the right thing to do and am
trying to recreate this patchset with mainline. Hopefully I'll be able
to iron out all such anomalies in the next revision
> > + uintptr_t ptr, __user *uptr = ubuf;
> > +
> > + ret = get_user(ptr, uptr + index);
> > + *buf = (void __user *)ptr;
> > + }
> > +
> > + return ret;
> > +}
> > +
>
> regards,
> dan carpenter
>
Thank you for the help!
Ojaswin
Powered by blists - more mailing lists