https://bugzilla.novell.com/show_bug.cgi?id=880599
https://bugzilla.novell.com/show_bug.cgi?id=880599#c6
James Carter changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
InfoProvider|jimc@math.ucla.edu |
--- Comment #6 from James Carter 2014-06-09 20:11:16 UTC ---
Sorry to be slow testing the patched kernel, but we had to respond to
CVE-2014-0224, and then the issues came up described in bug 881912, which
may or may not be related to this one.
The production and test servers are set up as i686 (vs. x86_64).
I installed the patched iernel (kernel-default-3.11.10-0.x86_64.rpm)
on a x86_64 test machine and got different results, plus I re-did my
tests on the i686 server and got similar but not identical results.
By the way, I'm not concerned if the user succeeds in writing
significantly beyond his quota, but it seems like a useful piece of
data for analysing the problem, so I report it when it happens. I'm
still using "dd if=/dev/zero of=$dir/oinkage.dat bs=1M", executing on
the client as the user (mathtest), to try to set off the bug(s).
In this table, Kernel = what the server uses (11-0 = Jack's test
kernel, 11-10 = distro's updated standard kernel), and NFSv = the
NFS version that the client is using. For the first 8 tests, both
the servers and the clients were x86_64. For the last 2 the server
was i686, clients were x86_64.
Kernel NFSv Fsys Outcome
10-0 4 ext4 EDQUOT (good), cut at 750Mb, very little overage
10-11 4 ext4 No signal (bad), had to kill writer
10-0 3 ext4 EDQUOT (good), "quota -v -l mathtest" claims to be
using 750000 blocks, but the file is 1180467200 bytes
or 1.18Gb. After I ran quotacheck, says 750004 blocks.
10-11 3 ext4 EDQUOT (good), "quota -v -l mathtest" claims to be
using 750000 blocks, but the file is 888827904 bytes
or 889Mb. After quotacheck, still says 750000 blocks.
10-0 3 ext3 EDQUOT (good), cut off at 1.4Gb, quota says 750Mb
10-11 3 ext3 EDQUOT (good), cut off at 750Mb, very little over
Repetitions: ***** 5 all the same exc. overage
10-0 4 ext3 EDQUOT (good), cut off at 750Mb, very little over
Repetitions: ***** 5 all the same exc. overage
10-11 3 i686 ext3 EDQUOT (good), cut at 1.1Gb (from 10-11 x86_64)
More repetitions: EDQUOT EDQUOT
10-11 3 i686 ext3 EDQUOT (good), cut at 750Mb+ (from 10-0 x86_64)
More repetitions: EIO EIO
The client that gets EDQUOT is about 1.3x faster than the one getting EIO.
All 3 machines are connected by a gigabit hub with little competing
traffic, so network speed likely does not affect the results.
Conclusion: The originally reported scenario on i686 has not
self-healed, but instead of failing "every" time, it fails "most of
the time" on the original client but never on a different client.
When testing on x86_64 and ext3 I got no failures at all,
either on the patched kernel or the standard kernel, but I got one
failure (no EDQUOT, no EIO, no signal at all) with the combination of
ext4, NFSv4, standard kernel, neither of which had failed before.
Odysseus successfully squeezed information out of the god Proteus, and
I think we need to learn from him to solve this bug.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.