Re: Merging backported fscrypt to 4.4?

[Greg KH <gregkh@linuxfoundation.org>]

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@linuxfoundation.org> 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?

> > 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...

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?

thanks,

greg k-h