Jonathan Nieder <jrnieder@gmail.com> 2012-10-08 21:09:
Hi again, Jonathan Nieder wrote:Hi kernel team,[...]Please consider the attached patch for the sid branch of the packaging repo. It applies the five aforementioned patches from upstream: 6a8a13e03861 fs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash d1f5273e9adb ext4: return 32/64-bit dir name hash according to usage type 999448a8c020 nfsd: rename 'int access' to 'int may_flags' in nfsd_open 06effdbb49af nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes) d7dab39b6e16 ext3: return 32/64-bit dir name hash according to usage type which make NFSv3/4 use 64-bit hashes as readdir cookies instead of crippling itself for the sake of NFSv2 which only supports 32-bit cookies. The most interesting of these (patches #2 and #5) are unfortunately a bit too big for the letter of the upstream stable rules, but the patches are straightforward, make sense, and are well tested.Ping. Do you think these could work for stable@? If not, could they make sense for wheezy anyway? Even if I cheat by stripping out some comments and such, patch #2 is 257 lines including context and diff headers, but semantically the patches are very clear and seem safe and sensible. Thanks, Jonathan
I think these are a must for wheezy. It's a fairly major flaw in my opinion.
I would also really like to see this in stable, since wheezy felt a long way off the last time I tried it, and there's some nice benefits from the backports kernel that we like, though we can probably continue to limp along on the original 2.6.32 kernel on those affected machines for a bit.
</cent></cent> Brian
Attachment:
signature.asc
Description: Digital signature