All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Atul Gopinathan <atulgopinathan@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type
Date: Thu, 18 Feb 2021 18:51:59 +0300	[thread overview]
Message-ID: <20210218155159.GL2087@kadam> (raw)
In-Reply-To: <20210218125220.GA19456@atulu-nitro>

On Thu, Feb 18, 2021 at 06:22:20PM +0530, Atul Gopinathan wrote:
> On Thu, Feb 18, 2021 at 01:21:05PM +0100, Greg KH wrote:
> > On Thu, Feb 18, 2021 at 04:17:55PM +0530, Atul Gopinathan wrote:
> > > On Thu, Feb 18, 2021 at 10:31:15AM +0000, Ian Abbott wrote:
> > > > On 18/02/2021 08:44, Atul Gopinathan wrote:
> > > > > Fix the following warning generated by sparse:
> > > > > 
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in assignment (different address spaces)
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23:    expected unsigned int *chanlist
> > > > > drivers/staging//comedi/comedi_fops.c:2956:23:    got void [noderef] <asn:1> *
> > > > > 
> > > > > compat_ptr() has a return type of "void __user *"
> > > > > as defined in "include/linux/compat.h"
> > > > > 
> > > > > cmd->chanlist is of type "unsigned int *" as defined
> > > > > in drivers/staging/comedi/comedi.h" in struct
> > > > > comedi_cmd.
> > > > > 
> > > > > Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com>
> > > > > ---
> > > > >   drivers/staging/comedi/comedi_fops.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c
> > > > > index e85a99b68f31..fc4ec38012b4 100644
> > > > > --- a/drivers/staging/comedi/comedi_fops.c
> > > > > +++ b/drivers/staging/comedi/comedi_fops.c
> > > > > @@ -2953,7 +2953,7 @@ static int get_compat_cmd(struct comedi_cmd *cmd,
> > > > >   	cmd->scan_end_arg = v32.scan_end_arg;
> > > > >   	cmd->stop_src = v32.stop_src;
> > > > >   	cmd->stop_arg = v32.stop_arg;
> > > > > -	cmd->chanlist = compat_ptr(v32.chanlist);
> > > > > +	cmd->chanlist = (unsigned int __force *)compat_ptr(v32.chanlist);
> > > > >   	cmd->chanlist_len = v32.chanlist_len;
> > > > >   	cmd->data = compat_ptr(v32.data);
> > > > >   	cmd->data_len = v32.data_len;
> > > > > 
> > > > 
> > > > This patch and the other one in your series clash with commit 9d5d041eebe3
> > > > ("staging: comedi: comedi_fops.c: added casts to get rid of sparse
> > > > warnings") by B K Karthik.
> > > 
> > > Oh I see. Not sure if this is the right place to ask, but which tree and
> > > branch should one work with when messing with the code in staging/
> > > directory? (wanted to avoid such clashes in future)
> > 
> > staging-next is the best one to use from the staging.git tree.  But as
> > the above commit was merged in 5.9-rc1, way back in July of last year, I
> > have no idea what tree you are currently using to not hit that...
> 
> I'm using the staging tree alright, cloned it yesterday. Except I used the
> --depth parameter. I believe that is the culprit. How bad a mistake is
> that?
> 
> (Why depth? I'm currently staying in a remote area where internet
> download speeds are less than 100Kbps. I tried a normal git clone of
> the staging tree and it's estimated time was more than half a day. Not
> to mention, it fails due to loss of connection midway every time)

I live in Africa and used to have this problem before Africa got
connected to fibre optic.  Greg's suggestion of using `wget -c` to
download a git bundle is a good one.  However, in my experience
`wget -c` is not 100% accurate on super flakey internet.  Then if it
fails the verify will fail and you'll have to re-download the entire
thing.

If you want I have a different option.  What I made a clone of Linus's
tree.  Then I did:

tar cvvf linux.tar linux/.git
for i in $(seq 0 116) ; do dd if=linux.tar of=linux.tar.${i} ibs=1M count=20 skip=$((20 * $i)) ; done

Now I have put those on a private webserver I have.  You can download
them by doing:

for i in $(seq 0 116) ; do wget -c http://51.158.124.72/kernel_split/linux.tar.${i} ; done
md5sum * > my_md5s
wget http://51.158.124.72/kernel_split/md5sums
diff -u md5sum my_md5s

Re-download files which don't match

for i in $(seq 0 116) ; do cat linux.tar.${i} >> linux.tar ; done
cat linux.tar | tar xv
cd linux
git reset --hard

Let me know if this works for you.  I will leave the source up for a
week or two before I delete it.

regards,
dan carpenter

  parent reply	other threads:[~2021-02-18 18:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18  8:44 [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type Atul Gopinathan
2021-02-18  8:44 ` [PATCH v2 2/2] staging: comedi: cast function argument to expected type (void __user *) Atul Gopinathan
2021-02-18 10:31 ` [PATCH v2 1/2] staging: comedi: cast function output to assigned variable type Ian Abbott
2021-02-18 10:47   ` Atul Gopinathan
2021-02-18 12:21     ` Greg KH
2021-02-18 12:52       ` Atul Gopinathan
2021-02-18 13:46         ` Greg KH
2021-02-18 14:12           ` Atul Gopinathan
2021-02-18 15:51         ` Dan Carpenter [this message]
2021-02-18 16:41           ` Atul Gopinathan
2021-02-19  6:55             ` Dan Carpenter
2021-02-19  7:42               ` Atul Gopinathan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210218155159.GL2087@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=atulgopinathan@gmail.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.