linux-kernel - RE: [PATCH v3 6/9] tty: n_gsm: fix deadlock and link starvation in outgoing data path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Jun 2022 09:41:17 +0000
From:   "Starke, Daniel" <daniel.starke@...mens.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "jirislaby@...nel.org" <jirislaby@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 6/9] tty: n_gsm: fix deadlock and link starvation in
 outgoing data path

> Please read the stable kernel rules for what is, and is not allowed.
> Generally a patch that does:
>  drivers/tty/n_gsm.c | 410 ++++++++++++++++++++++++++++++--------------
> is not allowed.
> 
> Please sort by what is stable fixes, and what is not.  Given that you
> don't seem to want to backport patches to older stable kernels when they
> fail to apply, why are any of these needed in stable kernels if the older
> ones are not also going to be merged there?

Indeed, the documentation disallows such big backports as I have just found
out.
Initially, I added the stable backport remark as suggested by you for my
very first patch.
We have split our complete change set in small patches, re-ordered the
changes to submit bug fixes first and documented all changes pedantically.
Supporting all the backports turns out to come with much higher effort as
we have anticipated. We do not have the resources to support this.
For us it is sufficient to keep all our changes on the n_gsm driver in the
mainline branch. Also for all upcoming patches.
We have already done various integration tests with the final version of
the n_gsm driver with Triorail and Funkwerk mobiles. It is part of our
commercial product which has an official approval. The quality and feature
level (3GPP standard conformance) of the n_gsm driver has been
significantly improved by our changes. And we would like to share this with
the community. This would bring the n_gsm driver out of its experimental
state.
Hence, I would like to resubmit this patch series without any stable
backport remark to avoid unmanageable effort.

Best regards,
Daniel Starke