On Wed, Jan 16, 2019 at 4:56 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Jan 15, 2019 at 9:24 PM Jan Kara <jack@xxxxxxx> wrote: > > > > What has happened to this pull request? It may be too late for this to be > > merged now but I'd like to understand why it was not merged or rejected... > > Sorry, initially I left if for later consideration after rc1, and then > I just forgot about it. > > I didn't see much point to the cleanup when it actually adds lots of > lines and no actual advantage. The whole dentry type translation > really is fs-specific and it might just happen to be shared. But why > share it if it only adds complexity and unnecessary abstraction? > Linus, I guess some of the reasoning got lost from the original patch series to the pull request. The pull request fails to mention this is an ext2 (very very old) bug fix. Jan has agreed to carry these 2 patches first to ease to herding all other filesystem patches in the series: https://marc.info/?l=linux-fsdevel&m=154060161813861&w=2 https://marc.info/?l=linux-fsdevel&m=154289087825040&w=2 The overall cleanup reduces ~100LOC and was acked by many filesystem maintainers as a welcome improvement (not as added complexity) Instead of fixing a potential out-of-bounds access bug that was copy&pasted from ext2 to many other filesystems, the approach taken was to create a single correct implementation and use it in all those filesystems. It is true, that this is filesystem specific code and new filesystem on-disk formats is not bound to use the same values. But the on-disk values used for all those filesystems formats are not going to change for eternity, so there is no meat on the fs-specific argument. The conversion is common de-facto forever for code that wants to read inodes from existing drives. If you pull these 2 patches now, other patches could be applied by fs maintainers for next cycle. Thanks, Amir.
