locking bug

locking bug

[Ara.T.Howard]

is this a known bug?


~/eg/c here is an NFS mounted dir...


   jib:~/eg/c > uname -a
   Linux jib.ngdc.noaa.gov 2.4.21-20.0.1.ELsmp #1 SMP Wed Nov 24 20:34:01 EST 2004 i686 i686 i386 GNU/Linux

   jib:~/eg/c > ./a.out
   fd <3>
   locking <foobar> => ret <0>
   (sleeping...)



   carp:~/eg/c > uname -a
   Linux carp.ngdc.noaa.gov 2.4.21-20.0.1.ELsmp #1 SMP Wed Nov 24 20:34:01 EST 2004 i686 i686 i386 GNU/Linux

   carp:~/eg/c > ./a.out
   fd <3>
   locking <foobar> => ret <0>
   (sleeping...)



   carp:~/eg/c > cat a.c
   #include <stdlib.h>
   #include <stdio.h>
   #include <sys/types.h>
   #include <sys/stat.h>
   #include <fcntl.h>
   int
   main (argc, argv)
        int argc;
        char **argv;
   {
     struct flock flock;
     char *path;
     int fd, fd2;
     int ret;

     path = argv[1] == NULL ? "foobar" : argv[1];

   /* open file, creating if does not exist, and lock it */
     fd = open (path, O_RDWR);
     if (fd == -1)
       {
         fd = open (path, O_RDWR | O_CREAT);
       }
     printf ("fd <%d>\n", fd);

     flock.l_type = F_WRLCK;
     flock.l_whence = SEEK_SET;
     flock.l_start = 0;
     flock.l_len = 0;

     ret = fcntl (fd, F_SETLK, &flock);
     printf ("locking <%s> => ret <%d>\n", path, ret);

   /* slurp file - this causes the bug */
     fd2 = open (path, O_RDONLY);
     while (read (fd2, &ret, sizeof (int)));
     close (fd2);

   /* getch */
     (void) getc (stdin);
     return (EXIT_SUCCESS);
   }


summary:

   * process on host 0 opens file, locks it, and read it in using separate file
     handle.  it then sleeps holding lock.

   * process on host 1 attempting the exact same sequence (and so expecting to
     find the file locked) is able to obtain the lock.

   * if the file is not slurped this code acts as it's supposed to - process on
     host 1 cannot obtain lock


is this known?  if not should i report here or to redhat?

kind regards.

-a
-- 
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself.  --Shunryu Suzuki
===============================================================================


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: locking bug

[J. Bruce Fields]

On Fri, Dec 10, 2004 at 02:34:32PM -0700, Ara.T.Howard wrote:
> summary:
> 
>   * process on host 0 opens file, locks it, and read it in using separate 
>   file
>     handle.  it then sleeps holding lock.
> 
>   * process on host 1 attempting the exact same sequence (and so expecting 
>   to
>     find the file locked) is able to obtain the lock.
> 
>   * if the file is not slurped this code acts as it's supposed to - process 
>   on
>     host 1 cannot obtain lock
> 
> 
> is this known?  if not should i report here or to redhat?

You understand that the close releases the lock?  From "man fcntl":

"As well as being removed by an explicit F_UNLCK, record locks are auto-
matically released when the process terminates or if it closes any file
descriptor referring to a file on which locks are held."

--b.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: locking bug

[Ara.T.Howard]

On Fri, 10 Dec 2004, J. Bruce Fields wrote:

> On Fri, Dec 10, 2004 at 02:34:32PM -0700, Ara.T.Howard wrote:
>> summary:
>>
>>   * process on host 0 opens file, locks it, and read it in using separate
>>   file
>>     handle.  it then sleeps holding lock.
>>
>>   * process on host 1 attempting the exact same sequence (and so expecting
>>   to
>>     find the file locked) is able to obtain the lock.
>>
>>   * if the file is not slurped this code acts as it's supposed to - process
>>   on
>>     host 1 cannot obtain lock
>>
>>
>> is this known?  if not should i report here or to redhat?
>
> You understand that the close releases the lock?  From "man fcntl":
>
> "As well as being removed by an explicit F_UNLCK, record locks are auto-
> matically released when the process terminates or if it closes any file
> descriptor referring to a file on which locks are held."
>
> --b.

gaah.

yes i once knew that ;-)  we upgraded to a new kernel this week and i've
already reported two (confirmed) bugs to redhat.  my mind was making too many
assumptions - i forgot about this (horrible) behaviour.

thanks for the soft landing.

regards.

-a
-- 
===============================================================================
| EMAIL   :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE   :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself.  --Shunryu Suzuki
===============================================================================


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

(no subject)

[Robert F. Merrill]

------------[ cut here ]------------
kernel BUG at fs/locks.c:1932!
invalid operand: 0000 [#8]
SMP 
Modules linked in: thermal fan button processor ac battery nfs lockd nfs_acl sunrpc ipv6 quota_v1 ide_cd cdrom generic joydev evdev e1000 mousedev piix psmouse i2c_i801 serio_raw pcspkr i2c_core ide_core floppy rtc uhci_hcd ehci_hcd usbcore parport_pc parport shpchp pci_hotplug
CPU:    0
EIP:    0060:[<c015fe6a>]    Not tainted VLI
EFLAGS: 00010246   (2.6.15.7-soda0) 
EIP is at locks_remove_flock+0xbb/0xd7
eax: d87f0cfc   ebx: ca0b0ebc   ecx: 00000000   edx: 00000000
esi: cf340900   edi: ca0b0e18   ebp: c5d75834   esp: cb585efc
ds: 007b   es: 007b   ss: 0068
Process mutt (pid: 2295, threadinfo=cb585000 task=e29f2030)
Stack: 00000000 00000000 00000000 00000000 00000000 cf340900 000008f7 00000000 
       00000000 00000000 cf340900 00000202 00000000 00000000 ffffffff 7fffffff 
       00000000 00000000 00000000 00000000 00000000 00000000 f6cb0b40 00000008 
Call Trace:
 [<c014da9d>] __fput+0x6d/0x125
 [<c014c5ca>] filp_close+0x4e/0x57
 [<c014c63b>] sys_close+0x68/0x7c
 [<c01027b1>] syscall_call+0x7/0xb

locking bug

[Jiri Slaby]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert F. Merrill napsal(a):
> ------------[ cut here ]------------
> kernel BUG at fs/locks.c:1932!
> invalid operand: 0000 [#8]
> SMP 
> Modules linked in: thermal fan button processor ac battery nfs lockd nfs_acl sunrpc ipv6 quota_v1 ide_cd cdrom generic joydev evdev e1000 mousedev piix psmouse i2c_i801 serio_raw pcspkr i2c_core ide_core floppy rtc uhci_hcd ehci_hcd usbcore parport_pc parport shpchp pci_hotplug
> CPU:    0
> EIP:    0060:[<c015fe6a>]    Not tainted VLI
> EFLAGS: 00010246   (2.6.15.7-soda0) 
Is is possible to reproduce this in 2.6.16.latest kernel?
> EIP is at locks_remove_flock+0xbb/0xd7
> eax: d87f0cfc   ebx: ca0b0ebc   ecx: 00000000   edx: 00000000
> esi: cf340900   edi: ca0b0e18   ebp: c5d75834   esp: cb585efc
> ds: 007b   es: 007b   ss: 0068
> Process mutt (pid: 2295, threadinfo=cb585000 task=e29f2030)
> Stack: 00000000 00000000 00000000 00000000 00000000 cf340900 000008f7 00000000 
>        00000000 00000000 cf340900 00000202 00000000 00000000 ffffffff 7fffffff 
>        00000000 00000000 00000000 00000000 00000000 00000000 f6cb0b40 00000008 
> Call Trace:
>  [<c014da9d>] __fput+0x6d/0x125
>  [<c014c5ca>] filp_close+0x4e/0x57
>  [<c014c63b>] sys_close+0x68/0x7c
>  [<c01027b1>] syscall_call+0x7/0xb

regards,
- --
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEVy1eMsxVwznUen4RAmA9AKC4xe12APAaHOsFBMr5VqNt2s9YlACdHDbM
jaczIRplTICXzfJ/CGCu6J4=
=WrrO
-----END PGP SIGNATURE-----