| 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: <20140218015231.GF26580@thunk.org> Date: Mon, 17 Feb 2014 20:52:31 -0500 From: Theodore Ts'o <tytso@....edu> To: Zheng Liu <gnehzuil.liu@...il.com> Cc: linux-ext4@...r.kernel.org, Ian Nartowicz <claws@...towicz.co.uk>, Tao Ma <tm@....ma>, Andreas Dilger <adilger.kernel@...ger.ca>, Zheng Liu <wenqing.lz@...bao.com> Subject: Re: [RFC][PATCH] ext4: handle fast symlink properly with inline_data On Thu, Feb 13, 2014 at 03:07:17PM +0800, Zheng Liu wrote: > > 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? Well, if we are using inline data, and we have a symlink which is longer than 60 bytes, but less than extra space available for an inline data, it seems like a good thing to support. The downside is that it is a bit more complication to add the kernel's code in both the kernel as well as e2fsprogs, but it doesn't seem that bad. So I don't have any objections to adding this functionality. What do other folks think? - Ted -- 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