lkml.org 
[lkml]   [2003]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[BUG] Alpha (EV56), lseek64, and /dev/kmem
Date
I just found that on my Alpha box, lseek64() has a bit of 
difficulty seeking through /dev/kmem to extremely high
values--specifically, any value >=0x8000000000000000 (the 64th
bit set). Whenever it's supposed to seek to (and return) such a
value, lseek64() returns -1 instead and sets errno to a
seemingly random garbage value. Userspace has no real choice
except to interpret this as an error.

So far it's doing this on both xfs and ext2/3, so I'm betting
it's fs-independent. I suppose it could be the kmem driver
itself deciding to be quirky? I have no way of knowing if
lseek64() will stumble like this on a real file, as I'd probably
need more drive space than God to test that!

This wouldn't be a problem, except for stuff like klogd that
seeks through /dev/kmem to discover module symbols. This little
quirk tends to make klogd segfault, it seems. :(

In case it matters:

Kernel: 2.4.21+SGI XFS 1.3.0
gcc: 3.2.3
glibc: 2.3.2
binutils: 2.14
modutils: 2.4.25
sysklogd: 1.4.1
distro: generic from-scratch build

--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.045 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site