linux-next: build failure after merge of the file-locks tree

linux-next: build failure after merge of the file-locks tree

[Stephen Rothwell]

Hi Jeff,

After merging the file-locks tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

fs/fcntl.c: In function 'SYSC_fcntl64':
fs/fcntl.c:414:30: error: 'argp' undeclared (first use in this function)
   if (copy_from_user(&flock, argp, sizeof(flock)))
                              ^
fs/fcntl.c:414:30: note: each undeclared identifier is reported only once for each function it appears in
fs/fcntl.c:416:23: error: 'filp' undeclared (first use in this function)
   err = fcntl_getlk64(filp, cmd, &flock);
                       ^

Caused by commit

  0416b792294c ("fs/locks: pass kernel struct flock to fcntl_getlk/setlk")

This build has BITS_PER_LONG == 32.

I have used the file-locks tree from next-20170516 for today.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the file-locks tree

[Jeff Layton]

On Wed, 2017-05-17 at 10:27 +1000, Stephen Rothwell wrote:
> Hi Jeff,
> 
> After merging the file-locks tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> fs/fcntl.c: In function 'SYSC_fcntl64':
> fs/fcntl.c:414:30: error: 'argp' undeclared (first use in this function)
>    if (copy_from_user(&flock, argp, sizeof(flock)))
>                               ^
> fs/fcntl.c:414:30: note: each undeclared identifier is reported only once for each function it appears in
> fs/fcntl.c:416:23: error: 'filp' undeclared (first use in this function)
>    err = fcntl_getlk64(filp, cmd, &flock);
>                        ^
> 
> Caused by commit
> 
>   0416b792294c ("fs/locks: pass kernel struct flock to fcntl_getlk/setlk")
> 
> This build has BITS_PER_LONG == 32.
> 
> I have used the file-locks tree from next-20170516 for today.
> 

I think this patch will probably fix it, but I don't have a 32-bit host
set up to build on just now. I'll go ahead and merge this into the
branch, and will plan to test it tomorrow (hopefully before the next
fetch).

------------------8<------------------

[PATCH] SQUASH: define argp properly in 32-bit fcntl64 syscall handler

...and use the right file pointer.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
 fs/fcntl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/fcntl.c b/fs/fcntl.c
index 9a9b25f12bd4..bbf80344c125 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -391,6 +391,7 @@ SYSCALL_DEFINE3(fcntl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
 SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int, cmd,
 		unsigned long, arg)
 {	
+	void __user *argp = (void __user *)arg;
 	struct fd f = fdget_raw(fd);
 	struct flock64 flock;
 	long err = -EBADF;
@@ -413,7 +414,7 @@ SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int, cmd,
 		err = -EFAULT;
 		if (copy_from_user(&flock, argp, sizeof(flock)))
 			break;
-		err = fcntl_getlk64(filp, cmd, &flock);
+		err = fcntl_getlk64(f.file, cmd, &flock);
 		if (!err && copy_to_user(argp, &flock, sizeof(flock)))
 			err = -EFAULT;
 		break;
-- 
2.9.4

Re: linux-next: build failure after merge of the file-locks tree

[Stephen Rothwell]

Hi Jeff,

On Tue, 16 May 2017 21:10:03 -0400 Jeff Layton <jlayton@poochiereds.net> wrote:
>
> I think this patch will probably fix it, but I don't have a 32-bit host
> set up to build on just now. I'll go ahead and merge this into the
> branch, and will plan to test it tomorrow (hopefully before the next
> fetch).

Thanks.  If you don't get around to testing, I will let you know if it
still fails tomorrow :-)

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the file-locks tree

[Jeff Layton]

On Wed, 2017-05-17 at 11:48 +1000, Stephen Rothwell wrote:
> Hi Jeff,
> 
> On Tue, 16 May 2017 21:10:03 -0400 Jeff Layton <jlayton@poochiereds.net> wrote:
> > 
> > I think this patch will probably fix it, but I don't have a 32-bit host
> > set up to build on just now. I'll go ahead and merge this into the
> > branch, and will plan to test it tomorrow (hopefully before the next
> > fetch).
> 
> Thanks.  If you don't get around to testing, I will let you know if it
> still fails tomorrow :-)
> 

Yep, that fixes it (at least on i386). I squashed it into patch 1 of
Christoph's series. Please let me know if you see further problems.

Thanks!
-- 
Jeff Layton <jlayton@poochiereds.net>

Re: linux-next: build failure after merge of the file-locks tree

[Stephen Rothwell]

Hi Jeff,

On Wed, 17 May 2017 08:32:46 -0400 Jeff Layton <jlayton@poochiereds.net> wrote:
>
> On Wed, 2017-05-17 at 11:48 +1000, Stephen Rothwell wrote:
> > 
> > On Tue, 16 May 2017 21:10:03 -0400 Jeff Layton <jlayton@poochiereds.net> wrote:  
> > > 
> > > I think this patch will probably fix it, but I don't have a 32-bit host
> > > set up to build on just now. I'll go ahead and merge this into the
> > > branch, and will plan to test it tomorrow (hopefully before the next
> > > fetch).  
> > 
> > Thanks.  If you don't get around to testing, I will let you know if it
> > still fails tomorrow :-)
> 
> Yep, that fixes it (at least on i386). I squashed it into patch 1 of
> Christoph's series. Please let me know if you see further problems.

Thanks, will do.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the file-locks tree

[Stephen Rothwell]

Hi Jeff,

On Wed, 17 May 2017 08:32:46 -0400 Jeff Layton <jlayton@poochiereds.net> wrote:
>
> On Wed, 2017-05-17 at 11:48 +1000, Stephen Rothwell wrote:
> > 
> > On Tue, 16 May 2017 21:10:03 -0400 Jeff Layton <jlayton@poochiereds.net> wrote:  
> > > 
> > > I think this patch will probably fix it, but I don't have a 32-bit host
> > > set up to build on just now. I'll go ahead and merge this into the
> > > branch, and will plan to test it tomorrow (hopefully before the next
> > > fetch).  
> > 
> > Thanks.  If you don't get around to testing, I will let you know if it
> > still fails tomorrow :-)
> 
> Yep, that fixes it (at least on i386). I squashed it into patch 1 of
> Christoph's series. Please let me know if you see further problems.

Looks good here as well.

-- 
Cheers,
Stephen Rothwell