Re: [GIT 4.9] LSM,security,selinux,smack: Backport of LSM changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jul 10, 2022 at 02:38:15PM +0200, Alexander Grund wrote:
> On 10.07.22 13:06, Greg KH wrote:
> > Make sure the patches you are submitting follows those rules on what is
> > able to be accepted.
> 
> Looks like I have to exclude a couple of patches especially due to the 100-lines rule.
> That especially hits the last one replacing 350 lines initialization code by 6 lines doing the same but avoiding potential errors by missing some initialization.

Submit them and we can see.  Deleting code is always good.

Also, please wrap your email lines...

> >> The Civil Infrastructure Platform (CIP) e.g. maintains LTS kernel trees which are now End of Life but still used.
> >> They call that SLTS ("Super Long Term Support") and there is e.g. a 4.4.y branch with backports from the 4.9.y LTS branch.
> >> That kernel is e.g. used in many Android phones.
> > 
> > What 4.4.y Android devices are still supported by their vendors?  And
> > are they still getting kernel updates?
> 
> Actually the issue is that those devices are not supported by their vendors anymore, so they may only get updates through LineageOS.
> That is a third-party Android build where maintainers rely on proprietary binaries from the original phone which are tied to a specific kernel.
> Hence when the device falls out of support having a 4.4 kernel in the last release there is no way for those maintainers to switch to a newer kernel.
> That's the situation e.g. I am in right now: Providing (mostly) security updates for a good phone that fell out of vendor support
> by using LineageOS for an updated Android system and e.g. the CIP maintained SLTS 4.4 kernel.
> And I know of at least 2 other devices using the same kernel as they share the platform.

All of those devices that wish to keep working should just forward port
their tree to newer kernel versions so that they can stay secure and
working properly.  It is far easier to do that than to attempt to keep
older kernel trees alive over time.  I've done both in the past and it's
always simpler to move forward.

So why not just do that instead of attempting to keep these old kernels
alive?  Do the effort once and then you can rely on the community's
help.  Otherwise you are stuck on your own for forever.

thanks,

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux