Re: cvs commit: src/sys/kern kern_lockf.c
:> off_t is a signed value. The last commit caused the kernel to fail with
:> a end < start panic.
:>
:> Revision Changes Path
:> 1.23 +1 -1 src/sys/kern/kern_lockf.c
:>
:> http://www.dragonflybsd.org/cvsweb/src/sys/kern/kern_lockf.c.diff?r1=1.22&r2=1.23&f=u
:>
:
:This was found by me while porting this change over to FreeBSD. In
:FreeBSD, there was a case where
:
: start = 0xffffffff
: end = 0x7fffffff
:
:Thus, my FreeBSD 6-CURRENT kernel was panicking with start > end.
:
:Joerg suggested that this might be a macro error. Patching the tree with
:ULLONG_MAX seemed to fix the error, but now I'm getting it again. I'll
:switch the commit back in my Perforce branch and re-report. This is very
:odd.
:
:--Devon
I don't know what the standard says but off_t is definitely signed,
and I was fairly certain that lockf allows a signed range, including
negative numbers.
sys/_types.h:typedef __int64_t __off_t; /* file offset */
These are also be 64 bit ints. Are you sure the values you
saw where:
: start = 0xffffffff
: end = 0x7fffffff
And not:
start = 0xffffffffffffffff
end = 0x7fffffffffffffff
I the values you saw were truncated to 32 bits, then perhaps there is
a bug in the code somewhere which is truncating parts of the range to
a 32 bit integer and causing 'start' to be 0xffffffff (which is 4GB)
instead of 0xffffffffffffffff (which is -1).
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 6 之 8 篇)：