| Message ID | 20191209151256.2497534-1-arnd@arndb.de |
|---|---|
| State | Accepted |
| Commit | db3db1f417544c334dd1bf9cb7005753c29e9dfc |
| Headers | show |
| Series | [1/4,net-next] wan: remove stale Kconfig entries | expand |
On Mon, Dec 09, 2019 at 04:12:56PM +0100, Arnd Bergmann wrote: > syzbot keeps finding issues in the X.25 implementation that nobody is > interested in fixing. Given that all the x25 patches of the past years > that are not global cleanups tend to fix user-triggered oopses, is it > time to just retire the subsystem? > > I looked a bit closer and found: > > - we used to support x25 hardware in linux, but with WAN_ROUTER > removed in linux-3.9 and isdn4linux removed in 5.3, there is only hdlc, > ethernet and the N_X25 tty ldisc left. Out of these, only HDLC_X25 made > it beyond the experimental stage, so this is probably what everyone > uses if there are users at all. > > - The most common hdlc hardware that people seem to be using are > the "farsync" PCIe and USB adapters. Linux only has drivers for the > older PCI devices from that series, but no hardware that works on > modern systems. > > - The manufacturer still updates their own kernel drivers and provides > support, but ships that with a fork or rewrite of the subsystem > code now. Kevin Curtis is also listed as maintainer, but appears to > have given up in 2013 after [1]. > > - The most popular software implementation appears to be X25 over TCP > (XOT), which is supported by Farsite and other out-of-tree stacks but > never had an implementation in mainline. > > - Most other supported HDLC hardware that we supoprt is for the ISA or > PCI buses. There are newer PCIe or USB devices, but those all require > a custom device driver and often a custom subsystem, none of which got > submitted for mainline inclusion. This includes hardware from Microgate > (SyncLink), Comtrol (RocketPort Express) and Sealevel (SeaMAC). > > - The X.25 subsystem is listed as "odd fixes", but the last reply on > the netdev mailing list from the maintainer was also in 2013[2]. > > - The HDLC subsystem itself is listed as maintained by Krzysztof Halasa, > and there were new drivers merged for SoC based devices as late as > 2016 by Zhao Qiang: Freescale/NXP QUICC Engine and Maxim ds26522. > There has not been much work on HDLC or drivers/net/wan recently, > but both developers are still responsive on the mailing list and > work on other parts of the kernel. > > Based on the above, I would conclude that X.25 can probably get moved > to staging as keeping it in the kernel seems to do more harm than good, > but HDLC below it should probably stay as there it seems there are still > users of a small subset of the mainline drivers. > > Move all of X.25 into drivers/staging for now, with a projected removal > date set for Linux-5.8. > > Cc: Eric Biggers <ebiggers@kernel.org> > Cc: Andrew Hendry <andrew.hendry@gmail.com> > Cc: linux-x25@vger.kernel.org > Cc: Kevin Curtis <kevin.curtis@farsite.com> > Cc: "R.J.Dunlop" <bob.dunlop@farsite.com> > Cc: Zhao Qiang <qiang.zhao@nxp.com> > Cc: Krzysztof Halasa <khc@pm.waw.pl> > Reported-by: syzbot+429c200ffc8772bfe070@syzkaller.appspotmail.com > Reported-by: syzbot+eec0c87f31a7c3b66f7b@syzkaller.appspotmail.com > Link: https://syzkaller.appspot.com/bug?id=5b0ecf0386f56be7fe7210a14d0f62df765c0c39 > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > ---- > > If anyone has different views or additional information, let us know. > > If you agree with the above, please Ack. ACK! Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
From: Arnd Bergmann <arnd@arndb.de> Date: Mon, 9 Dec 2019 16:12:56 +0100 > syzbot keeps finding issues in the X.25 implementation that nobody is > interested in fixing. Given that all the x25 patches of the past years > that are not global cleanups tend to fix user-triggered oopses, is it > time to just retire the subsystem? I have a bug fix that I'm currently applying to 'net' right now actually: https://patchwork.ozlabs.org/patch/1205973/ So your proposal might be a bit premature.
On Mon, Dec 9, 2019 at 7:29 PM David Miller <davem@davemloft.net> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > Date: Mon, 9 Dec 2019 16:12:56 +0100 > > > syzbot keeps finding issues in the X.25 implementation that nobody is > > interested in fixing. Given that all the x25 patches of the past years > > that are not global cleanups tend to fix user-triggered oopses, is it > > time to just retire the subsystem? > > I have a bug fix that I'm currently applying to 'net' right now actually: > > https://patchwork.ozlabs.org/patch/1205973/ > > So your proposal might be a bit premature. Ok, makes sense. Looking back in the history, I also see other bugfixes from the same author. Adding Martin Schiller to Cc: for a few questions: - What hardware are you using for X.25? - Would you be available to be listed in the MAINTAINERS file as a contact for net/x25? - Does your bug fix address the latest issue found by syzbot[1], or do you have an idea to fix it if not? Arnd [1] https://lore.kernel.org/netdev/CAK8P3a0LdF+aQ1hnZrVKkNBQaum0WqW1jyR7_Eb+JRiwyHWr6Q@mail.gmail.com/
On 2019-12-09 20:26, Arnd Bergmann wrote: > On Mon, Dec 9, 2019 at 7:29 PM David Miller <davem@davemloft.net> > wrote: >> >> From: Arnd Bergmann <arnd@arndb.de> >> Date: Mon, 9 Dec 2019 16:12:56 +0100 >> >> > syzbot keeps finding issues in the X.25 implementation that nobody is >> > interested in fixing. Given that all the x25 patches of the past years >> > that are not global cleanups tend to fix user-triggered oopses, is it >> > time to just retire the subsystem? >> >> I have a bug fix that I'm currently applying to 'net' right now >> actually: >> >> https://patchwork.ozlabs.org/patch/1205973/ >> >> So your proposal might be a bit premature. > > Ok, makes sense. Looking back in the history, I also see other bugfixes > from the same author. > > Adding Martin Schiller to Cc: for a few questions: > > - What hardware are you using for X.25? I would say that X.25 is (at least in Germany) not dead yet. For example, it is still used in the railway network of the Deutsche Bahn AG in many different areas. [1] We deliver products for this and use the Linux X.25 stack with some bugfixes and extensions that I would like to get upstream. As hardware/interfaces we use X.21bis/G.703 adapters, which are connected via HDLC_X25 and LAPB. Also for this there are extensions and bugfixes, which I would like to include in the kernel. > - Would you be available to be listed in the MAINTAINERS file > as a contact for net/x25? Yes, you can add me to the MAINTAINERS file. I have only limited time, but I will try to follow all requests concerning this subsystem. > - Does your bug fix address the latest issue found by syzbot[1], > or do you have an idea to fix it if not? I don't have a direct solution for the concrete problem mentioned above, but at first sight I would say that the commit 95d6ebd53c79 ("net/x25: fix use-after-free in x25_device_event()") holds the wrong lock (&x25_list_lock). Shouldn't this be the lock &x25_neigh_list_lock as in x25_get_neigh(), where x25_neigh_hold() is called? > > Arnd > > [1] > https://lore.kernel.org/netdev/CAK8P3a0LdF+aQ1hnZrVKkNBQaum0WqW1jyR7_Eb+JRiwyHWr6Q@mail.gmail.com/
On Tue, Dec 10, 2019 at 9:59 AM Martin Schiller <ms@dev.tdt.de> wrote: > On 2019-12-09 20:26, Arnd Bergmann wrote: > > On Mon, Dec 9, 2019 at 7:29 PM David Miller <davem@davemloft.net> > > wrote: > >> > >> From: Arnd Bergmann <arnd@arndb.de> > >> Date: Mon, 9 Dec 2019 16:12:56 +0100 > >> > >> > syzbot keeps finding issues in the X.25 implementation that nobody is > >> > interested in fixing. Given that all the x25 patches of the past years > >> > that are not global cleanups tend to fix user-triggered oopses, is it > >> > time to just retire the subsystem? > >> > >> I have a bug fix that I'm currently applying to 'net' right now > >> actually: > >> > >> https://patchwork.ozlabs.org/patch/1205973/ > >> > >> So your proposal might be a bit premature. > > > > Ok, makes sense. Looking back in the history, I also see other bugfixes > > from the same author. > > > > Adding Martin Schiller to Cc: for a few questions: > > > > - What hardware are you using for X.25? > > I would say that X.25 is (at least in Germany) not dead yet. For > example, it is still used in the railway network of the Deutsche Bahn AG > in many different areas. [1] > > We deliver products for this and use the Linux X.25 stack with some > bugfixes and extensions that I would like to get upstream. Right, when I looked for possible users, I found several examples where X.25 is still relevant, my impression was just that none of those were using the mainline Linux network stack. Thank you for clarifying that. > As hardware/interfaces we use X.21bis/G.703 adapters, which are > connected via > HDLC_X25 and LAPB. Also for this there are extensions and bugfixes, > which I would like to include in the kernel. > > - Would you be available to be listed in the MAINTAINERS file > > as a contact for net/x25? > > Yes, you can add me to the MAINTAINERS file. > I have only limited time, but I will try to follow all requests > concerning this subsystem. Great! I don't expect there to be a lot of work, but it definitely helps to have someone who can look at the occasional build failure or code cleanup patch. If this works for everyone, I'd submit the following patch: commit b63caa9a8d86a5bfc64052bf9aab9b22181120fd (HEAD) Author: Arnd Bergmann <arnd@arndb.de> Date: Tue Dec 10 14:28:39 2019 +0100 MAINTAINERS: add new X.25 maintainer Martin Schiller is using the Linux X.25 stack on top of HDLC and X.21 networks. He agreed to be listed as a maintainer to take care of odd fixes. Add him as the primary contact for net/x25 and net/lapb, as well as a reviewer for drivers/net/wan, which contains the HDLC code. Cc: Martin Schiller <ms@dev.tdt.de> Cc: Andrew Hendry <andrew.hendry@gmail.com> Cc: Krzysztof Halasa <khc@pm.waw.pl> Link: https://lore.kernel.org/netdev/407acd92c92c3ba04578da89b1a0f191@dev.tdt.de/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> diff --git a/MAINTAINERS b/MAINTAINERS index 8e58410a799a..00b624b96103 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6889,6 +6889,7 @@ F: Documentation/i2c/muxes/i2c-mux-gpio.rst GENERIC HDLC (WAN) DRIVERS M: Krzysztof Halasa <khc@pm.waw.pl> +R: Martin Schiller <ms@dev.tdt.de> W: http://www.kernel.org/pub/linux/utils/net/hdlc/ S: Maintained F: drivers/net/wan/c101.c @@ -9255,13 +9256,6 @@ S: Maintained F: arch/mips/lantiq F: drivers/soc/lantiq -LAPB module -L: linux-x25@vger.kernel.org -S: Orphan -F: Documentation/networking/lapb-module.txt -F: include/*/lapb.h -F: net/lapb/ - LASI 53c700 driver for PARISC M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> L: linux-scsi@vger.kernel.org @@ -17911,11 +17905,16 @@ S: Maintained N: axp[128] X.25 NETWORK LAYER +M: Martin Schiller <ms@dev.tdt.de> M: Andrew Hendry <andrew.hendry@gmail.com> L: linux-x25@vger.kernel.org S: Odd Fixes F: Documentation/networking/x25* +F: Documentation/networking/lapb-module.txt +F: include/linux/lapb.h F: include/net/x25* +F: include/uapi/linux/x25.h +F: net/lapb/ F: net/x25/ X86 ARCHITECTURE (32-BIT AND 64-BIT) ----- > > - Does your bug fix address the latest issue found by syzbot[1], > > or do you have an idea to fix it if not? > > I don't have a direct solution for the concrete problem mentioned above, > but at > first sight I would say that the commit 95d6ebd53c79 ("net/x25: fix > use-after-free in x25_device_event()") holds the wrong lock > (&x25_list_lock). > Shouldn't this be the lock &x25_neigh_list_lock as in x25_get_neigh(), > where x25_neigh_hold() is called? After looking at it again, my best guess is something else: x25_wait_for_connection_establishment() calls release_sock()/lock_sock() while waiting. At this point, a concurrent x25_connect() can overwrite the x25->neighbour variable, which needs to be checked again before calling x25_neigh_put(). Arnd
On 2019-12-10 14:51, Arnd Bergmann wrote: > On Tue, Dec 10, 2019 at 9:59 AM Martin Schiller <ms@dev.tdt.de> wrote: >> On 2019-12-09 20:26, Arnd Bergmann wrote: >> > On Mon, Dec 9, 2019 at 7:29 PM David Miller <davem@davemloft.net> >> > wrote: >> >> >> >> From: Arnd Bergmann <arnd@arndb.de> >> >> Date: Mon, 9 Dec 2019 16:12:56 +0100 >> >> >> >> > syzbot keeps finding issues in the X.25 implementation that nobody is >> >> > interested in fixing. Given that all the x25 patches of the past years >> >> > that are not global cleanups tend to fix user-triggered oopses, is it >> >> > time to just retire the subsystem? >> >> >> >> I have a bug fix that I'm currently applying to 'net' right now >> >> actually: >> >> >> >> https://patchwork.ozlabs.org/patch/1205973/ >> >> >> >> So your proposal might be a bit premature. >> > >> > Ok, makes sense. Looking back in the history, I also see other bugfixes >> > from the same author. >> > >> > Adding Martin Schiller to Cc: for a few questions: >> > >> > - What hardware are you using for X.25? >> >> I would say that X.25 is (at least in Germany) not dead yet. For >> example, it is still used in the railway network of the Deutsche Bahn >> AG >> in many different areas. [1] >> >> We deliver products for this and use the Linux X.25 stack with some >> bugfixes and extensions that I would like to get upstream. > > Right, when I looked for possible users, I found several examples > where X.25 is still relevant, my impression was just that none of those > were using the mainline Linux network stack. > > Thank you for clarifying that. > >> As hardware/interfaces we use X.21bis/G.703 adapters, which are >> connected via >> HDLC_X25 and LAPB. Also for this there are extensions and bugfixes, >> which I would like to include in the kernel. > >> > - Would you be available to be listed in the MAINTAINERS file >> > as a contact for net/x25? >> >> Yes, you can add me to the MAINTAINERS file. >> I have only limited time, but I will try to follow all requests >> concerning this subsystem. > > Great! I don't expect there to be a lot of work, but it definitely > helps > to have someone who can look at the occasional build failure or > code cleanup patch. > > If this works for everyone, I'd submit the following patch: > > commit b63caa9a8d86a5bfc64052bf9aab9b22181120fd (HEAD) > Author: Arnd Bergmann <arnd@arndb.de> > Date: Tue Dec 10 14:28:39 2019 +0100 > > MAINTAINERS: add new X.25 maintainer > > Martin Schiller is using the Linux X.25 stack on top of HDLC and > X.21 networks. He agreed to be listed as a maintainer to take > care of odd fixes. > > Add him as the primary contact for net/x25 and net/lapb, as well > as a reviewer for drivers/net/wan, which contains the HDLC code. > > Cc: Martin Schiller <ms@dev.tdt.de> > Cc: Andrew Hendry <andrew.hendry@gmail.com> > Cc: Krzysztof Halasa <khc@pm.waw.pl> > Link: > https://lore.kernel.org/netdev/407acd92c92c3ba04578da89b1a0f191@dev.tdt.de/ > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > ACK! Acked-by: Martin Schiller <ms@dev.tdt.de> > diff --git a/MAINTAINERS b/MAINTAINERS > index 8e58410a799a..00b624b96103 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6889,6 +6889,7 @@ F: > Documentation/i2c/muxes/i2c-mux-gpio.rst > > GENERIC HDLC (WAN) DRIVERS > M: Krzysztof Halasa <khc@pm.waw.pl> > +R: Martin Schiller <ms@dev.tdt.de> > W: http://www.kernel.org/pub/linux/utils/net/hdlc/ > S: Maintained > F: drivers/net/wan/c101.c > @@ -9255,13 +9256,6 @@ S: Maintained > F: arch/mips/lantiq > F: drivers/soc/lantiq > > -LAPB module > -L: linux-x25@vger.kernel.org > -S: Orphan > -F: Documentation/networking/lapb-module.txt > -F: include/*/lapb.h > -F: net/lapb/ > - > LASI 53c700 driver for PARISC > M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> > L: linux-scsi@vger.kernel.org > @@ -17911,11 +17905,16 @@ S: Maintained > N: axp[128] > > X.25 NETWORK LAYER > +M: Martin Schiller <ms@dev.tdt.de> > M: Andrew Hendry <andrew.hendry@gmail.com> > L: linux-x25@vger.kernel.org > S: Odd Fixes > F: Documentation/networking/x25* > +F: Documentation/networking/lapb-module.txt > +F: include/linux/lapb.h > F: include/net/x25* > +F: include/uapi/linux/x25.h > +F: net/lapb/ > F: net/x25/ > > X86 ARCHITECTURE (32-BIT AND 64-BIT) > > ----- >> > - Does your bug fix address the latest issue found by syzbot[1], >> > or do you have an idea to fix it if not? >> >> I don't have a direct solution for the concrete problem mentioned >> above, >> but at >> first sight I would say that the commit 95d6ebd53c79 ("net/x25: fix >> use-after-free in x25_device_event()") holds the wrong lock >> (&x25_list_lock). >> Shouldn't this be the lock &x25_neigh_list_lock as in x25_get_neigh(), >> where x25_neigh_hold() is called? > > After looking at it again, my best guess is something else: > x25_wait_for_connection_establishment() calls > release_sock()/lock_sock() > while waiting. At this point, a concurrent x25_connect() can > overwrite the x25->neighbour variable, which needs to be checked > again before calling x25_neigh_put(). > That's a good point. I wonder why any further call to x25_connect() on the same socket isn't simply returning (EALREADY) as long as sock->state == SS_CONNECTING? Martin
Arnd, Arnd Bergmann <arnd@arndb.de> writes: > - Most other supported HDLC hardware that we supoprt is for the ISA or > PCI buses. I would be surprised if there is anybody left with ISA sync serial stuff, but the PCI hardware still has some users - these machines don't need to be upgraded yearly. Most people have migrated away, though. -- Krzysztof Halasa ŁUKASIEWICZ Research Network Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
On Wed, Dec 11, 2019 at 08:10:34AM +0100, Krzysztof Hałasa wrote: > Arnd, > > Arnd Bergmann <arnd@arndb.de> writes: > > > - Most other supported HDLC hardware that we supoprt is for the ISA or > > PCI buses. > > I would be surprised if there is anybody left with ISA sync serial > stuff, but the PCI hardware still has some users - these machines don't > need to be upgraded yearly. Most people have migrated away, though. Hi Krzysztof, Arnd I have a use case for hdlc_cisco and hdlc_raw_eth. But it uses a lot of out of tree code, the DAHDI driver framework for E1 cards, and an E1 card which is not part of DAHDI. Given how much of this is out of tree, i would understand if you eventually decide to remove this HDLC code. Andrew
diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig index bf2fe1d602ea..59b25d7e13e8 100644 --- a/drivers/net/wan/Kconfig +++ b/drivers/net/wan/Kconfig @@ -289,30 +289,6 @@ config SLIC_DS26522 To compile this driver as a module, choose M here: the module will be called slic_ds26522. -config DSCC4_PCISYNC - bool "Etinc PCISYNC features" - depends on DSCC4 - help - Due to Etinc's design choice for its PCISYNC cards, some operations - are only allowed on specific ports of the DSCC4. This option is the - only way for the driver to know that it shouldn't return a success - code for these operations. - - Please say Y if your card is an Etinc's PCISYNC. - -config DSCC4_PCI_RST - bool "Hard reset support" - depends on DSCC4 - help - Various DSCC4 bugs forbid any reliable software reset of the ASIC. - As a replacement, some vendors provide a way to assert the PCI #RST - pin of DSCC4 through the GPIO port of the card. If you choose Y, - the driver will make use of this feature before module removal - (i.e. rmmod). The feature is known to be available on Commtech's - cards. Contact your manufacturer for details. - - Say Y if your card supports this feature. - config IXP4XX_HSS tristate "Intel IXP4xx HSS (synchronous serial port) support" depends on HDLC && IXP4XX_NPE && IXP4XX_QMGR
The dscc4 driver was recently removed, but these Kconfig entries remain, so remove them as well. Fixes: 28c9eb9042a9 ("net/wan: dscc4: remove broken dscc4 driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/net/wan/Kconfig | 24 ------------------------ 1 file changed, 24 deletions(-) -- 2.20.0