* [BUG] Alpha (EV56), lseek64, and /dev/kmem
@ 2003-10-04 0:42 Kelledin
2003-10-04 1:08 ` Måns Rullgård
0 siblings, 1 reply; 4+ messages in thread
From: Kelledin @ 2003-10-04 0:42 UTC (permalink / raw)
To: linux-kernel
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?"
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] Alpha (EV56), lseek64, and /dev/kmem
2003-10-04 0:42 [BUG] Alpha (EV56), lseek64, and /dev/kmem Kelledin
@ 2003-10-04 1:08 ` Måns Rullgård
2003-10-04 1:36 ` Kelledin
0 siblings, 1 reply; 4+ messages in thread
From: Måns Rullgård @ 2003-10-04 1:08 UTC (permalink / raw)
To: linux-kernel
Kelledin <kelledin+LKML@skarpsey.dyndns.org> writes:
> 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
/dev/kmem hasn't anything to do with filesystems, right?
> 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!
You could create a sparse file, but I don't think any filesystem
support that big files.
--
Måns Rullgård
mru@users.sf.net
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] Alpha (EV56), lseek64, and /dev/kmem
2003-10-04 1:08 ` Måns Rullgård
@ 2003-10-04 1:36 ` Kelledin
2003-10-04 17:13 ` [PATCH] sysklogd: use up-to-date query_module() routine Kelledin
0 siblings, 1 reply; 4+ messages in thread
From: Kelledin @ 2003-10-04 1:36 UTC (permalink / raw)
To: linux-kernel; +Cc: Måns Rullgård
On Friday 03 October 2003 08:08 pm, Måns Rullgård wrote:
> /dev/kmem hasn't anything to do with filesystems, right?
I suspected as much.
After a bit of consideration and some poking around the kernel
source, I'm guessing the vfs layer interprets any negative value
from an llseek vfsop as an error condition (even if it's just a
very large 64-bit offset). Obviously this wouldn't be a problem
for most stuff--as you say, I doubt any fs (virtual or
non-virtual) was intended to support such large files. This
situation with /dev/kmem on 64-bit machines is just an
exceptional (and exceptionally annoying) corner case.
So far I see three possibilities:
1) fix the VFS layer so it accepts certain very large 64-bit
quantities as valid quantities. This would probably be a
significant kernel rework...and I hate that, especially on an
already-released stable branch (i.e. 2.4) or a branch very close
to pre-release (i.e. 2.5/2.6). I'd say save this for 2.7 and
take care of it then.
2) migrate klogd to use query_module() rather than stepping
through /dev/kmem. query_module() should provide everything
that klogd normally pokes around /dev/kmem for. Does it rely
indirectly on being able to step through kmem? I hope not...
3) switch to a system/kernel logger that already supports
query_module(). is there such a beast? is there, perhaps, a
patch for the de facto sysklogd?
Who maintains sysklogd-1.4.1, anyways? It seems to be a fairly
antiquated hunk of junk...
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] sysklogd: use up-to-date query_module() routine
2003-10-04 1:36 ` Kelledin
@ 2003-10-04 17:13 ` Kelledin
0 siblings, 0 replies; 4+ messages in thread
From: Kelledin @ 2003-10-04 17:13 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On Friday 03 October 2003 08:36 pm, Kelledin wrote:
> 2) migrate klogd to use query_module() rather than stepping
> through /dev/kmem. query_module() should provide everything
> that klogd normally pokes around /dev/kmem for. Does it rely
> indirectly on being able to step through kmem? I hope not...
Well, I settled on this option, and I've got something that seems
to work. The kmem walker hack is no longer needed, the llseek()
VFS limitations are now a pretty moot point, and an
obsolete/dangerous syscall got nudged further towards oblivion.
(Oh, and klogd no longer segv's on my EV56 box, which was really
the point of this exercise to begin with. ;)
I've attached the patch below in case anyone is interested; I
also sent it off to the sysklogd maintainers (finally found
them). Testing and constructive criticism is encouraged.
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
[-- Attachment #2: sysklogd-1.4.1-querymodules.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 3142 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-10-04 17:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-04 0:42 [BUG] Alpha (EV56), lseek64, and /dev/kmem Kelledin
2003-10-04 1:08 ` Måns Rullgård
2003-10-04 1:36 ` Kelledin
2003-10-04 17:13 ` [PATCH] sysklogd: use up-to-date query_module() routine Kelledin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).