Bug 3715 - samba 64 bit locking problems
samba 64 bit locking problems
Status: CLOSED DUPLICATE of bug 2982
Product: Red Hat Linux
Classification: Retired
Component: samba (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Depends On:
  Show dependency treegraph
Reported: 1999-06-24 17:19 EDT by Cristian Gafton
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-06-24 18:05:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Cristian Gafton 1999-06-24 17:19:23 EDT
> To any one who is using Red Hat Linux 6.0 (or, presumably,
any glibc2.1
> system)
> I recently installed a new RH 6.0 system on Intel.  After
installing my
> samba and my network application I noticed that I was
experiencing oplock
> problems that were not present with the same version of
Samba on my RH 5.2
> systems and caused my application to not function.  Since
the problem
> seems to be with oplocks I don't know if this could cause
> corruption/inconsistency or not but I would assume so.  I
have tested this
> both with Samba 2.0.3 (that ships with RH) and also Samba
2.0.4b.  I have
> also tried compiling Samba fresh (as opposed to using the
binary RPMs).
> Evidence of the problem are log entries like the following
(gotten at
> debug level=3 and higher)
> [1999/05/22 14:42:06, 3] lib/util.c:fcntl_lock(2658)
>   fcntl lock gave errno 11 (Resource temporarily
> It seems that I only see "fcntl" when this error occurs so
that may be a
> safe expression to grep for if you want to look for it.  I
had quite a few
> of these lines.  Presumably my application trying to get
to it's files
> before it died a horrible death.
> There are two fixes I've found for this so far:
> 1 - set oplocks = false for the system.  The downside of
this is that with
> oplocks disabled you will have anywhere from a minor to a
> performance hit.
> 2 - The better fix, IMHO, is to do the following
> rpm -Uvh
> edit /etc/rc.d/init.d/smb
> In the "start)" case add
> LD_LIBRARY_PATH=/usr/i386-glibc20-linux/lib
> before the "daemon smbd -D" line
> and then add
> after the "daemon nmbd -D" line
> (note: I haven't tried the above in a script yet, just
manually with
> manually executing smbd/nmbd but I see no reason why it
would be any
> different in a script)
> As best I understand this, this points the dynamic linker
to look in the
> old glibc2.0 directory first to resolve objects.  In this
case it makes
> Samba run as if it were still on a glibc2.0 (ie: RH 5.2)
system and things
> work fine again.  It seems to run just fine like that and
you can leave
> oplocks enabled so your users/clients/self stop yelling at
you :)
> I don't know if this is a Samba bug for not following some
new glibc2.1
> API change or just a glibc2.1 bug.  But Samba is the only
application I've
> had problems with so far so I'm starting here.
> samba-bugs has been cc'd and I am also reporting this as a
bug to Red Hat.
> I consider this a pretty severe problem.
> If anyone has any questions please feel free to ask me.

Ok, I'm pretty sure what's going on here. I'm also CC:ingThe
problem is that WinNT has a bug in which it sends 64
bit lock range requests to systems that only have 32 bit
lock ranges available, despite being told via the protocol
not to do so (just another area they never tested I guess).

Samba is fully 64-bit clean on a 64 bit system and will
work fine on these systems. Unfortunately x86 linux is only
a 32 bit system. Samba 2.0.4 has a fix in it in that if it
detects it is running on a 32-bit system it will 'fold' the
64 bit lock range into 32 bits as best it can. It needs to
do this as applications like Word and Excel need byte range
locks to conflict correctly in order to detect multiple
on a file. This works all well and good on glibc2.0 systems
(which Samba detects as 32 bit lock aware).

But glibc2.1 lies on a Linux x86 system :-). It tells Samba
that it can do 64 bit lock reqests. It can't. What glibc2.1
does is just drop the top 32 bits of any range request. This
causes the bottom half of the lock ranges to collide with
earlier lock ranges - hence the messages you are getting.

Now Samba has the code to work correctly with glibc2.1, it
just needs to stop believing that glibc2.1 is a 64 bit lock
aware library on a 32 bit system. Personally I think this is
a glibc2.1 bug on x86 Linux. As Samba already contains the
correct code (as evidenced by the fact it works with the
glibc2.0 libraries) we need to find a way for the Samba
autoconf scripts to detect lying libc libraries and turn
on the 32-bit workaround automatically on Linux x86


        Jeremy Allison,
        Samba Team.

this to Ulich Drepper who is the maintainer of the glibc
library at Cygnus & also Erik Troan at RedHat.
Comment 1 Bill Nottingham 1999-06-24 18:05:59 EDT
*** This bug has been marked as a duplicate of 2982 ***

Note You need to log in before you can comment on or make changes to this bug.