lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <loom.20140213T180233-750@post.gmane.org> Date: Thu, 13 Feb 2014 17:05:03 +0000 (UTC) From: Ian Nartowicz <claws@...towicz.co.uk> To: linux-ext4@...r.kernel.org Subject: Re: [RFC][PATCH] ext4: handle fast symlink properly with inline_data Zheng Liu <gnehzuil.liu <at> gmail.com> writes: > > From: Zheng Liu <wenqing.lz <at> taobao.com> > > This commit tries to fix a bug that we can't read fast symlink properly. > The following script can hit the bug. > > Hi all, > > I am not sure whether or not we need to enable inline_data for a fast > symlink inode. Obviously, it brings a benefit that after enabling > inline_data feature for a fast symlink we can get more space to store > the path. But it seems that the original patch doesn't want to do this > Another solution for fixing this bug is to disable inline_data for a > fast symlink. Any comment? > > Thanks, > - Zheng I compiled a kernel with this patch and the long symlinks work OK now. fsck still complains, of course. Seems like a fairly rare case, but is there any real downside to supporting it? --ian -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists