Bug 28523 - llseek has inconsistent semantics between smp and enterprise 2.2.16 kernels
llseek has inconsistent semantics between smp and enterprise 2.2.16 kernels
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-20 19:09 EST by Georg Nikodym
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-20 19:09:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Georg Nikodym 2001-02-20 19:09:17 EST
llseek has inconsistent semantics between smp and enterprise 2.2.16 kernels

Running /usr/bin/nm on ARM cross-compiled binaries works fine on the
2.2.16-smp kernel (or any other kernel) and a fully updated RH7.0 system.

Using the -enterprise kernel, nm fails with:

/usr/bin/nm: conftest.o: Value too large for defined data type

Using strace, I see that it's because _llseek() returned EOVERFLOW.  Fair
enough.

On the other kernels, this same _llseek() returned EINVAL and nm itself
went on to
complete successfully.

While it may be argued that nm has a bug, the semantics of a system call
probably shouldn't
be variable...
Comment 1 Michael K. Johnson 2001-02-21 13:53:31 EST
The semantics are more strictly specified by the LFS standard, which
is implemented only in the enterprise kernel.

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