With this patch, there is still a problem that lapb_unregister may run
concurrently with other LAPB API functions (such as
lapb_data_received). This other LAPB API function can get the
lapb->lock after lapb->lock is released by lapb_unregister, and
continue to do its work. This is not correct.
We
On Wed, Jan 20, 2021 at 12:42 PM Xie He wrote:
>
> With this patch, there is still a problem that lapb_unregister may run
> concurrently with other LAPB API functions (such as
> lapb_data_received). This other LAPB API function can get the
> lapb->lock after lapb
ot;.
3. Let lapb_unregister wait for other API functions and running timers
to stop.
4. The lapb_device_event function calls lapb_disconnect_request. In
order to avoid trying to hold the lock twice, add a new function named
"__lapb_disconnect_request" which assumes the lock is held, and make
it
;, to avoid trying to hold the
lock twice. When I do this, I removed "lapb_start_t1timer" because I
don't think it's necessary to start the timer when "NETDEV_GOING_DOWN".
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Martin Schiller
Signed-off-by: Xie He
---
include
On Tue, Jan 19, 2021 at 3:34 AM Martin Schiller wrote:
>
> > 4. In lapb_device_event, replace the "lapb_disconnect_request" call
> > with
> > the content of "lapb_disconnect_request", to avoid trying to hold the
> > lock twice. When I do this, I removed "lapb_start_t1timer" because I
> > don't
named
"__lapb_disconnect_request" which assumes the lock is held, and make
it called by lapb_disconnect_request and lapb_device_event.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Martin Schiller
Signed-off-by: Xie He
---
include/net/lapb.h| 2 ++
net/lapb/lapb_iface
On Wed, Jan 20, 2021 at 2:58 AM Martin Schiller wrote:
>
> Can you please add a Changelog. What was changed in v4?
Sorry, I forgot this. Here is the change log:
--- Changes from v3 to v4 ---
Only lapb_unregister has been changed.
v3 has a problem. When "del_timer_sync(>t1timer)" is called, if
2timer".
3. In lapb_unregister, add "del_timer_sync" calls to make sure all
running timers have exited.
4. The lapb_device_event function calls lapb_disconnect_request. In
order to avoid trying to hold the lock twice, add a new function named
"__lapb_disconnect_request" which assumes t
On Sat, Jan 23, 2021 at 8:45 PM Jakub Kicinski wrote:
>
> > > @@ -178,11 +182,23 @@ int lapb_unregister(struct net_device *dev)
> > > goto out;
> > > lapb_put(lapb);
> > >
> > > + /* Wait for other refs to "lapb" to drop */
> > > + while (refcount_read(>refcnt) > 2)
> > > +
t", to avoid trying to hold the
lock twice. When doing this, "lapb_start_t1timer" is removed because
I don't think it's necessary to start the timer when "NETDEV_GOING_DOWN".
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Martin Schiller
Signed-off-by: Xie He
---
i
On Mon, Aug 3, 2020 at 11:53 PM Martin Schiller wrote:
>
> I don't like the idea to get rid of the 1-byte header.
> This header is also used in userspace, for example when using a tun/tap
> interface for an XoT (X.25 over TCP) application. A change would
> therefore have very far-reaching
On Tue, Aug 4, 2020 at 12:06 AM Willem de Bruijn wrote:
>
> > BTW: The linux x25 mailing list does not seem to work anymore. I've been
> > on it for some time now, but haven't received a single email from it.
> > I've tried to contact owner-linux-...@vger.kernel.org, but only got an
> >
On Tue, Aug 4, 2020 at 3:07 AM Xie He wrote:
>
> Maybe we could contact . It seems to be the
> manager of VGER mail lists.
Oh. No. Majordomo seems to be a robot.
On Tue, Aug 4, 2020 at 5:43 AM Martin Schiller wrote:
>
> I'm not an expert in the field, but after reading the commit message and
> the previous comments, I'd say that makes sense.
Thanks!
> Shouldn't this kernel panic be intercepted by a skb_cow() before the
> skb_push() in
On Tue, Aug 4, 2020 at 10:23 PM Martin Schiller wrote:
>
> > Adding skb_cow before these skb_push calls would indeed help
> > preventing kernel panics, but that might not be the essential issue
> > here, and it might also prevent us from discovering the real issue. (I
> > guess this is also the
packet_parse_headers.isra.0+0xd2/0x110
[ 168.399297] dev_queue_xmit+0x10/0x20
[ 168.399298] packet_sendmsg+0xbf0/0x19b0
..
Cc: Willem de Bruijn
Cc: Martin Schiller
Cc: Brian Norris
Signed-off-by: Xie He
---
drivers/net/wan/lapbether.c | 10 +-
1 file changed, 9 insertions(+), 1 del
I'm sorry I forgot to include the "net" prefix again. I remembered
"PATCH" but not "net" this time. I'll try to remember both next time.
If requested I can resend the patch with the correct prefix. Sorry.
b" in error handling code.
"kfree_skb" is the correct function to call when dropping an skb due to
an error. "dev_kfree_skb", which is an alias of "consume_skb", is for
dropping skbs normally (not due to an error).
Cc: Krzysztof Halasa
On Sat, Oct 3, 2020 at 11:10 AM Stephen Hemminger
wrote:
>
> This code snippet is basically an version of skb_pad().
> Probably it is very old and pre-dates that.
> Could the code use skb_pad?
Oh! Yes! I looked at the skb_pad function and I think we can use it in
this code.
Since it doesn't do
andling code.
"kfree_skb" is the correct function to call when dropping an skb due to
an error. "dev_kfree_skb", which is an alias of "consume_skb", is for
dropping skbs normally (not due to an error).
Cc: Krzysztof Halasa
Cc: Stephen
ord "check" in the comments because pskb_may_pull may
do things other than simple checks in the case of non-linear skbs.)
Cc: Willem de Bruijn
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_x25.c | 4 ++--
drivers/net/wan/lapbether.c | 4 ++--
drivers/net/wan/x2
adroom
When this driver transmits data,
first this driver will remove a pseudo header of 1 byte,
then the lapb module will prepend the LAPB header of 2 or 3 bytes.
So the value of needed_headroom in this driver should be 3 - 1.
Cc: Willem de Bruijn
Cc: Martin Schiller
Signed-off-by:
On Sun, Aug 9, 2020 at 1:48 AM Willem de Bruijn
wrote:
>
> Does this solve an actual observed bug?
>
> In many ways lapbeth is similar to tunnel devices. This is not common.
Thank you for your comment!
This doesn't solve a bug observed by me. But I think this should be
necessary considering the
On Sun, Aug 9, 2020 at 2:13 AM Willem de Bruijn
wrote:
>
> The patch is analogous to commit c7ca03c216ac
> ("drivers/net/wan/lapbether: Added needed_headroom and a skb->len
> check").
>
> Seems to make sense based on call stack
>
> x25_asy_xmit // skb_pull(skb, 1)
>
On Mon, Aug 10, 2020 at 12:32 AM Willem de Bruijn
wrote:
>
> What happens when a tunnel device passes a packet to these devices?
> That will also not have allocated the extra tailroom. Does that cause
> a bug?
I looked at the code in net/ipv4/ip_tunnel.c. It indeed appeared to me
that it didn't
On Mon, Aug 10, 2020 at 12:21 AM Willem de Bruijn
wrote:
>
> Acked-by: Willem de Bruijn
Thank you so much!
> > 1) I hope to set needed_headroom properly for all three X.25 drivers
> > (lapbether, x25_asy, hdlc_x25) in the kernel. So that the upper layer
> > (net/x25) can be changed to use
ers (skb_p) because we no
longer need to replace the skb inside fr_hard_header.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/
ore
the LL header when header_ops != NULL.
Cc: Willem de Bruijn
Signed-off-by: Xie He
---
net/packet/af_packet.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2d5d5fbb435c..f59fa26d4826 100644
makes a
user listening on the Ethernet device with an AF_PACKET socket, to see
the same sll_protocol value for incoming and outgoing frames.
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/lapbether.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/n
rzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_cisco.c | 1 +
drivers/net/wan/hdlc_fr.c| 3 +++
drivers/net/wan/hdlc_ppp.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c
index 444130655d8e..cb5898f7d68c 1
On Thu, Sep 17, 2020 at 1:51 AM Willem de Bruijn
wrote:
>
> Acked-by: Willem de Bruijn
Thank you, Willem!
).
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_cisco.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c
index d8cba3625c18..444130655d8e 100644
--- a/drivers/net/wan/hdlc_cisco.c
+++ b/drivers/net/wan/hdlc_c
On Tue, Aug 11, 2020 at 3:50 AM Willem de Bruijn
wrote:
>
> > I became interested in X.25 when I was trying different address
> > families that Linux supported. I tried AF_X25 sockets. And then I
> > tried to use the X.25 link layer directly through AF_PACKET. I believe
> > both AF_X25 sockets
On Tue, Aug 11, 2020 at 10:32 AM David Miller wrote:
>
> Applied, thank you.
Thank you!
eader_len) to
the default values. We add needed_headroom here so that needed_headroom
will also be reset.
Cc: Willem de Bruijn
Cc: Martin Schiller
Cc: Andrew Hendry
Signed-off-by: Xie He
---
drivers/net/wan/hdlc.c | 1 +
drivers/net/wan/hdlc_x25.c | 17 -
2 files ch
der space internally needed by
setting needed_headroom. This means this usage is already adopted by
driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wang
Signed-off-by: Xie He
---
include/linux/netdevice.h | 4 ++--
net/packet/af_packet.c| 19 +--
der space internally needed by
setting needed_headroom. This means this usage is already adopted by
driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wang
Signed-off-by: Xie He
---
Change from v1:
Small change to the commit message.
---
include/linux/netdevice.h |
Thank you for your thorough review comment!
On Fri, Jul 31, 2020 at 7:13 AM Willem de Bruijn
wrote:
>
> Thanks for fixing a kernel panic. The existing line was added recently
> in commit 9dc829a135fb ("drivers/net/wan/lapbether: Fixed the value of
> hard_header_len"). I assume a kernel with that
On Fri, Jul 31, 2020 at 7:33 PM Willem de Bruijn
wrote:
>
> I quickly scanned the main x.25 datapath code. Specifically
> x25_establish_link, x25_terminate_link and x25_send_frame. These all
> write this 1 byte header. It appears to be an in-band communication
> means between the network and data
On Sat, Aug 1, 2020 at 6:31 AM Willem de Bruijn
wrote:
>
> The kernel interface cannot be changed. If packet sockets used to pass
> the first byte up to userspace, they have to continue to do so.
>
> So I think you can limit the header_ops to only dev_hard_header.
Actually if we want to keep the
packet_sendmsg+0xbf0/0x19b0
..
Additional change:
When sending, check skb->len to ensure the 1-byte pseudo header is
present before reading it.
Cc: Willem de Bruijn
Cc: Brian Norris
Signed-off-by: Xie He
---
Change from v2:
Added skb->len check when sending.
Change from v1:
None
Thanks!
On Mon, Aug 3, 2020 at 2:50 AM Willem de Bruijn
wrote:
>
> It's [PATCH net v3], not [net v3]
Sorry. My mistake. I'll pay attention next time.
I'm currently thinking about changing the subject to reflect that we
added a "skb->len" check. Should I number the new patch as v1 or
continue
The underlying Ethernet device may request necessary tailroom to be
allocated by setting needed_tailroom. This driver should also set
needed_tailroom to request the tailroom needed by the underlying
Ethernet device to be allocated.
Cc: Willem de Bruijn
Cc: Martin Schiller
Signed-off-by: Xie He
On Fri, Sep 11, 2020 at 2:41 PM David Miller wrote:
>
> From: Xie He
> Date: Thu, 10 Sep 2020 23:07:20 -0700
>
> > This header file is not actually used in this file. Let's remove it.
>
> How did you test this assertion? As Jakub showed, the
> dlci_ioctl_set() fu
On Fri, Sep 11, 2020 at 7:32 AM Willem de Bruijn
wrote:
>
> From a quick scan, a few device types that might trigger this
>
> net/atm/clip.c
> drivers/net/wan/hdlc_fr.c
> drivers/net/appletalk/ipddp.c
> drivers/net/ppp/ppp_generic.c
> drivers/net/net_failover.c
I have recently fixed this problem
On Fri, Sep 11, 2020 at 2:44 PM David Miller wrote:
>
> From: Xie He
> Date: Thu, 10 Sep 2020 23:35:03 -0700
>
> > The "SLF_OUTWAIT" flag defined in x25_asy.h is not actually used.
> > It is only cleared at one place in x25_asy.c but is never read or set.
>
is only called before netif_rx and not before lapb_data_received.
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/x25_asy.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wan/x25_asy.c b/drivers/net/wan/x25_asy.c
index 5a7cf8bf9d0d..ab56a5e6447a
On Sun, Sep 13, 2020 at 1:11 AM Willem de Bruijn
wrote:
>
> I am concerned about adding a WARN_ON_ONCE that we already expect to
> fire on some platforms.
>
> Probably better to add the documentation without the warning.
>
> I know I suggested the check before, sorry for the churn, but I hadn't
>
On Sun, Sep 13, 2020 at 10:26 PM Krzysztof Hałasa wrote:
>
> Xie He writes:
>
> > The HDLC device is not actually prepending any header when it is used
> > with this driver. When the PVC device has prepended its header and
> > handed over the skb to the HDLC device,
On Sun, Sep 13, 2020 at 10:32 PM Martin Schiller wrote:
>
> Acked-by: Martin Schiller
Thank you, Martin!
s this usage is already adopted by driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wang
Signed-off-by: Xie He
---
net/packet/af_packet.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_
OK. I'll make the changes you suggested and resubmit the patch. Thanks!
I'll drop the change to netdevice.h and the check for
dev_hard_header's return value. If there's still a need for something
similar to these, we can do them in a separate patch.
The author tried to set the WiFi driver's hard_header_len to the Ethernet
header length, and request additional header space internally needed by
setting needed_headroom.
This means this usage is already adopted by driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wan
net/wan/sdla.c
Note that the "Frame Relay" module is different from and unrelated to the
"HDLC Frame Relay" module at:
drivers/net/wan/hdlc_fr.c
I think maybe we can deprecate the "Frame Relay" module because we already
have the (newer) "HDLC Frame Relay" module.
Si
The "SLF_OUTWAIT" flag defined in x25_asy.h is not actually used.
It is only cleared at one place in x25_asy.c but is never read or set.
So we can remove it.
Signed-off-by: Xie He
---
drivers/net/wan/x25_asy.c | 2 --
drivers/net/wan/x25_asy.h | 1 -
2 files changed, 3 deletions(-)
On Tue, Oct 27, 2020 at 6:24 AM Arnd Bergmann wrote:
>
> Ah, of course. I had looked up the types but mixed up the memmap
> and HDW definitions, but then got confused trying to understand the
> logic in wr_mem() that operates on bytes but expands them into
> multiples of 4.
I think wr_mem()
devices) to upper layers. Because we don't use header_ops for normal
PVC devices, we should hide the header from upper layer code in this case.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 76 ++-
1 file changed, 51 insertions(+), 25
first make sure the pointer is not
NULL, then assign it directly to skb->dev. "dev" is no longer needed until
the end where we use it to update stats.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 37 -
1 file changed, 2
k to the initial checks in fr_fx. fh->ea2 == 1 means
the second address byte is the final address byte. We only support the
case where the address length is 2 bytes.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
several times, this
patch uses "goto rx_drop" to replace them so that the code looks cleaner.
Also add code to increase the stats.rx_dropped count whenever we drop a
frame.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 16 +++-
1 file changed, 7
several times, this
patch uses "goto rx_drop" to replace them so that the code looks cleaner.
Also add code to increase the stats.rx_dropped count whenever we drop a
frame.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 16 +++-
1 file changed, 7
devices) to upper layers. Because we don't use header_ops for normal
PVC devices, we should hide the header from upper layer code in this case.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 76 ++-
1 file changed, 51 insertions(+), 25
k to the initial checks in fr_rx. fh->ea2 == 1 means
the second address byte is the final address byte. We only support the
case where the address length is 2 bytes.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
nning and it can just
exit.
If we let ppp_timer continue running, it may call add_timer. This causes
kernel panic because add_timer can't be called with a timer pending.
This patch fixes this problem.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_ppp.c | 7 +++
1 file chan
nning and it can just
exit.
If we let ppp_timer continue running, it may call add_timer. This causes
kernel panic because add_timer can't be called with a timer pending.
This patch fixes this problem.
Fixes: e022c2f07ae5 ("WAN: new synchronous PPP implementation for generic
HDLC.")
Cc: Krz
On Mon, Dec 28, 2020 at 1:17 AM Hillf Danton wrote:
>
> On Sun, 27 Dec 2020 18:53:39 -0800 Xie He wrote:
> > ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
> > held. It may call mod_timer to add a new timer. However, at the same time
>
n Schiller
Signed-off-by: Xie He
---
net/x25/x25_link.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/net/x25/x25_link.c b/net/x25/x25_link.c
index f92073f3cb11..57a81100c5da 100644
--- a/net/x25/x25_link.c
+++ b/net/x25/x25_link.c
@@ -58,11 +58,6
On Wed, Nov 25, 2020 at 10:36 PM Martin Schiller wrote:
>
> We have to take the actual link state into account to handle
> restart requests/confirms well.
>
> @@ -214,8 +241,6 @@ void x25_link_established(struct x25_neigh *nb)
> {
> switch (nb->state) {
> case X25_LINK_STATE_0:
>
On Wed, Dec 9, 2020 at 1:01 AM Xie He wrote:
>
> On Wed, Nov 25, 2020 at 10:36 PM Martin Schiller wrote:
> >
> > switch (nb->state) {
> > case X25_LINK_STATE_0:
> > - nb->state = X25_LINK_STATE_2;
> > -
On Wed, Dec 9, 2020 at 1:41 AM Martin Schiller wrote:
>
> Right.
> By the way: A "Restart Collision" is in practice a very common event to
> establish the Layer 3.
Oh, I see. Thanks!
On Wed, Dec 9, 2020 at 2:31 AM Martin Schiller wrote:
>
> >> 1. When the x25 module gets loaded, layer 2 may already be running and
> >> connected. In this case, although we are in X25_LINK_STATE_0, we still
> >> need to handle the Restart Request received, rather than ignore it.
> >
> > Hmm...
On Wed, Dec 9, 2020 at 1:47 AM Xie He wrote:
>
> On Wed, Dec 9, 2020 at 1:41 AM Martin Schiller wrote:
> >
> > Right.
> > By the way: A "Restart Collision" is in practice a very common event to
> > establish the Layer 3.
>
> Oh, I see. Thanks!
H
On Wed, Dec 9, 2020 at 1:21 PM David Laight wrote:
>
> I always wondered about running Class 2 transport directly over LLC2
> (rather than Class 4 over LLC1).
> But the only LLC2 user was netbios - and microsoft's LLC2 was broken.
> Not to mention the window probing needed to handle systems that
On Wed, Dec 9, 2020 at 10:27 PM Martin Schiller wrote:
>
> > Hi Martin,
> >
> > When you submit future patch series, can you try ensuring the code to
> > be in a completely working state after each patch in the series? This
> > makes reviewing the patches easier. After the patches get applied,
>
On Wed, Dec 9, 2020 at 10:35 PM Martin Schiller wrote:
>
> Yes, that's also the reason why I already acked this patch. We can
> solve this later a little bit cleaner if necessary.
>
> My patch that takes care of the orphaned packets in x25_receive_data()
> has again a dependency on other patches,
On Thu, Dec 10, 2020 at 1:14 AM David Laight wrote:
>
> > To me, LLC1 and LLC2 are to Ethernet what UDP and TCP are to IP
> > networks. I think we can use LLC1 and LLC2 wherever UDP and TCP can be
> > used, as long as we are in the same LAN and are willing to use MAC
> > addresses as the
> From: Martin Schiller
>
> [ Upstream commit 62480b992ba3fb1d7260b11293aed9d6557831c7 ]
>
> 1. DTE interface changes immediately to LAPB_STATE_1 and start sending
>SABM(E).
>
> 2. DCE interface sends N2-times DM and changes to LAPB_STATE_1
>afterwards if there is no response in the
On Wed, Dec 23, 2020 at 9:01 AM Xie He wrote:
>
> I don't think this patch is suitable for stable branches. This patch is
> part of a patch series that changes the lapb module from "establishing the
> L2 connection only when needed by L3", to "establishing the L2
On Tue, Dec 29, 2020 at 12:10 AM Hillf Danton wrote:
>
> >The code path that calls add_timer is for sending keep-alive packets
> >when operating in the OPENED state. If we have just changed to the
> >OPENED state in ppp_cp_event, we should wait for the amount of time
> >set by the (2nd) mod_timer
is
problem.
Fixes: a4989fa91110 ("net/lapb: support netdev events")
Cc: Martin Schiller
Signed-off-by: Xie He
---
net/lapb/lapb_iface.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/lapb/lapb_iface.c b/net/lapb/lapb_iface.c
index 213ea7abc9ab..40961889e9c0 100644
--- a/net/lapb/la
> In tty layer, it use tty->ldisc_sem to proect tty_ldisc_ops.
> So I think tty->ldisc_sem can also protect tty->disc_data;
It might help by CC'ing TTY people, so that we could get this reviewed by
people who are familiar with TTY code.
Greg Kroah-Hartman (supporter:TTY LAYER)
Jiri Slaby
On Thu, Oct 22, 2020 at 8:22 AM Jakub Kicinski wrote:
>
> Are most of these drivers using skb_padto()? Is that the reason they
> can't be sharing the SKB?
Yes, I think if a driver calls skb_pad / skb_padto / skb_put_padto /
eth_skb_pad, the driver can't accept shared skbs because it may modify
On Thu, Oct 22, 2020 at 5:44 PM Jakub Kicinski wrote:
>
> On Thu, 22 Oct 2020 12:59:45 -0700 Xie He wrote:
> >
> > But I also see some drivers that want to pad the skb to a strange
> > length, and don't set their special min_mtu to match this length. For
> > example
On Thu, Oct 22, 2020 at 6:56 PM Xie He wrote:
>
> My patch isn't complete. Because there are so many drivers with this
> problem, I feel it's hard to solve them all at once. So I only grepped
> "skb_padto" under "drivers/net/ethernet". There are other drivers
&
> This fixes a regression for blocking connects introduced by commit
> 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect").
> The x25->neighbour is already set to "NULL" by x25_disconnect() now,
> while a blocking connect is waiting in
>
ck);
> x25_neigh_put(x25->neighbour);
> x25->neighbour = NULL;
Thanks! It's amazing to see we are trying to fix the same issue.
Reviewed-by: Xie He
On Wed, Nov 11, 2020 at 3:41 AM Martin Schiller wrote:
>
> > 1) When we receive a connection, the x25_rx_call_request function in
> > af_x25.c does not increase the refcount when it assigns the pointer.
> > When we disconnect, x25_disconnect is called and the struct's refcount
> > is decreased
Hendry) has stopped
sending emails to the netdev mail list since 2013. So there is practically
no maintainer for X.25 code currently.
Cc: Martin Schiller
Cc: Andrew Hendry
Signed-off-by: Xie He
---
MAINTAINERS | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
On Wed, Nov 11, 2020 at 11:06 PM Martin Schiller wrote:
>
> About 1 year ago I was asked by Arnd Bergmann if I would like to become
> the maintainer for the X.25 stack:
>
> https://patchwork.ozlabs.org/project/netdev/patch/20191209151256.2497534-4-a...@arndb.de/#2320767
>
> Yes, I would agree to
refcount when
it assigns the pointer.
Fix this issue by increasing the refcount of "struct x25_neigh" in
x25_rx_call_request.
This patch fixes frequent kernel crashes when using AF_X25 sockets.
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Cc: Marti
en
it assigns the pointer.
Fix this issue by increasing the refcount of "struct x25_neigh" in
x25_rx_call_request.
This patch fixes frequent kernel crashes when using AF_X25 sockets.
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Cc: Marti
email in the archive was in 2009. It's likely that this
mail list has stopped working since 2009.
Can you please help fix this mail list. Thanks!
Xie He
On Wed, Nov 18, 2020 at 11:02 PM Martin Schiller wrote:
>
> On 2020-11-18 15:47, Xie He wrote:
> >
> > But... Won't it be better to handle L2 connections in L2 code?
> >
> > For example, if we are running X.25 over XOT, we can decide in the XOT
> > layer w
to the netdev mail list since 2013. So he is probably
inactive now.
Cc: Martin Schiller
Cc: Andrew Hendry
Signed-off-by: Xie He
---
MAINTAINERS | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a0fde12b650..5adb78cb0d92 100644
On Thu, Nov 12, 2020 at 9:28 PM Martin Schiller wrote:
>
> On 2020-11-13 03:17, John 'Warthog9' Hawley wrote:
> > Give it a try now, there was a little wonkiness with the alias setup
> > for it, and I have no historical context for a 'why', but I adjusted a
> > couple of things and I was able to
25_device_event()")
Cc: Martin Schiller
Signed-off-by: Xie He
---
net/x25/af_x25.c | 12
net/x25/x25_subr.c | 2 --
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index a10487e7574c..50f043f0c1d0 100644
--- a/net/x25/af_
to the netdev mail list since 2013. So he is probably
inactive now.
Cc: Martin Schiller
Cc: Andrew Hendry
Signed-off-by: Xie He
---
MAINTAINERS | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index af9f6a3ab100..ab8b2c9ad00e 100644
WANPIPE
driver instead.
(The WANPIPE driver was even once in the kernel, but was deleted in
commit 8db60bcf3021 ("[WAN]: Remove broken and unmaintained Sangoma
drivers.") because the vendor no longer updated the in-kernel WANPIPE
driver.)
Cc: Mike McLagan
Signed-off-by: Xie He
--
On Sat, Nov 14, 2020 at 2:36 AM Xie He wrote:
>
> This patch adds correct locking for x25_kill_by_device and
> x25_kill_by_neigh, and removes the incorrect locking in x25_connect and
> x25_disconnect.
I see if I do this change, I need to make sure the sock lock is not
held
(dlci_conf and frad_conf). According to the
comments, these two structs are specially crafted for sdla.c (the only
hardware driver dlci.c supports). I think this makes dlci.c not generic
enough to support other hardware drivers.
Cc: Lee Jones
Cc: Gustavo A. R. Silva
Cc: Krzysztof Kozlowski
Signed-o
1 - 100 of 323 matches
Mail list logo
