[1/4,net-next] wan: remove stale Kconfig entries

Message ID 20191209151256.2497534-1-arnd@arndb.de
State New
Headers show
Series
  • [1/4,net-next] wan: remove stale Kconfig entries
Related show

Commit Message

Arnd Bergmann Dec. 9, 2019, 3:12 p.m.
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

Comments

Greg Kroah-Hartman Dec. 9, 2019, 3:41 p.m. | #1
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>
David Miller Dec. 9, 2019, 6:29 p.m. | #2
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.
Arnd Bergmann Dec. 9, 2019, 7:26 p.m. | #3
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/
Martin Schiller Dec. 10, 2019, 8:59 a.m. | #4
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/
Arnd Bergmann Dec. 10, 2019, 1:51 p.m. | #5
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
Martin Schiller Dec. 11, 2019, 5:58 a.m. | #6
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
Krzysztof =?utf-8?Q?Ha=C5=82asa?= Dec. 11, 2019, 7:10 a.m. | #7
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
Andrew Lunn Dec. 11, 2019, 1:34 p.m. | #8
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

Patch

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