From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F940C433EF for ; Sun, 10 Jul 2022 12:48:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229505AbiGJMs3 (ORCPT ); Sun, 10 Jul 2022 08:48:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229469AbiGJMs3 (ORCPT ); Sun, 10 Jul 2022 08:48:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CB051144C for ; Sun, 10 Jul 2022 05:48:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 78D2AB80885 for ; Sun, 10 Jul 2022 12:48:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FD73C3411E; Sun, 10 Jul 2022 12:48:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1657457305; bh=t6nTzXZAEjmfg84Dtgh102IANpAVEQiXm3VTaKwRAzg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZmbQkpciYshO/EFIjDGNjyqbkHmXhvZTM8XTsOh51b1rzFU8vVATQHmKvQor6XqLs lntI8Jm+qa3m5AxCmxv9Y94CcyLCzwgbNDHQRES14BtgN0OXpmdIl6eck2Fgnb/IKD 6bc/NuLXZirkkOUD/uSbnctZl8Ozavoglk54E41I= Date: Sun, 10 Jul 2022 14:48:20 +0200 From: Greg KH To: Alexander Grund Cc: stable@vger.kernel.org Subject: Re: [GIT 4.9] LSM,security,selinux,smack: Backport of LSM changes Message-ID: References: <4230dd79-b64f-14e6-3614-02e4acb3f284@gmail.com> <81f96354-cbed-26e4-9f3f-5287095ccece@gmail.com> <1c9e8498-0621-4466-bfbc-4f166c633727@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c9e8498-0621-4466-bfbc-4f166c633727@gmail.com> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org 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