Hi Greg, > On 12 Oct 2017, at 13:49, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Oct 12, 2017 at 12:30:09PM +0000, Anton Altaparmakov wrote: >> Hi Greg, >> >> Thanks a lot for the quick reply! >> >>> On 12 Oct 2017, at 13:11, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>> On Thu, Oct 12, 2017 at 11:59:03AM +0000, Anton Altaparmakov wrote: >>>> Hi Greg, >>>> >>>> As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4. Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself... Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)... >>>> >>>> What do you think? Would you accept a backported fscrypt into the stable 4.4 tree? >>> >>> The LTS rules are still the same, no matter if I maintain it for a few >>> months, or a few years/decades. So how does adding a bunch of new code >>> for no in-kernel users fit into the existing rules? >> >> ext4/f2fs are in-kernel users. > > But it's just moving code around for those users, not fixing any bugs, > right? Probably true, yes. I admit I had forgotten they already had that code in 4.4 and it was moved out to fscrypt afterwards... >>> If a device manufacture wants the fscrypt feature, great, use a newer >>> kernel (like 4.9 or better yet, 4.14.) It's always best to use newer >>> kernels, right?. >>> >>>> Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block. (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.) >>> >>> You should convince your customers to use a more modern kernel :) >> >> In fact one of our customers were moving to a more recent kernel and >> cancelled the move when the announcement about the longer 4.4 kernel >> life time was made!!! > > Um, that's not really very wise. You should council them about that... > >> Now that 4.4 has a longer supported time than any newer kernel we will >> probably see a lot of devices get stuck on 4.4 kernel for the next >> decade at least... This was one of those small announcements that are >> going to affect the entire embedded world for years to come! > > Those devices were stuck on 4.4 anyway, the SoC vendors were not > updating their kernel version, which is why I'm doing this longer term > support, to keep those devices secure. Otherwise they would all be in > big trouble... > > Note, I will say that if I do not see these devices get new kernel > updates, then I'll figure that the work I'm doing here doesn't even > matter to anyone, and then I'll just stop the support... Ok, that is good to know. > Anyway, that's a side note, I don't really understand why you need/want > fscrypt, if the only in-kernel filesystems that need it, already have > this support? Ah, sorry for not explaining better - we have our own flash friendly file system (TFFS), which is not in the tree so we have a vested interest in fscrypto being part of the mainline kernel rather than maintaining it separately. Best regards, Anton > thanks, > > greg k-h -- Anton Altaparmakov <anton at tuxera.com> (replace at with @) Lead in File System Development, Tuxera Inc., http://www.tuxera.com/ Linux NTFS maintainer