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
;, 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
--
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 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 thi
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 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(&lapb->t1timer)" is calle
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
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
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-&g
On Fri, Jan 22, 2021 at 1:07 AM Martin Schiller wrote:
>
> I don't have the opportunity to test this at the moment, but code looks
> reasonable so far. Have you tested this at runtime?
Thanks! Yes, I have tested this using hdlc_x25.c, lapbether.c and (the
deleted) x25_asy.c drivers.
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 addresses
> 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 meanti
ned-off-by: Xie He
---
drivers/net/wan/lapbether.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
index b6be2454b8bd..605fe555e157 100644
--- a/drivers/net/wan/lapbether.c
+++ b/drivers/net/wan/lapbether.
,
called by __netif_receive_skb, called by process_backlog). So we don't
need to call skb_reset_network_header by ourselves.
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_x25.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/
,
called by __netif_receive_skb, called by process_backlog). So we don't
need to call skb_reset_network_header by ourselves.
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_x25.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/
,
called by __netif_receive_skb, called by process_backlog). So we don't
need to call skb_reset_network_header by ourselves.
Cc: Martin Schiller
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_x25.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
in
clear that this is not a ongoing
plan anymore. Change words like "will" to "could", "would", etc.
Cc: Martin Schiller
Signed-off-by: Xie He
---
Documentation/networking/x25.rst | 12 +---
net/x25/af_x25.c | 6 +-
net/x25/x25_dev.c
Martin 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
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... I'
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
>
commit f73659192b0b ("net: wan: Delete the DLCI / SDLA drivers")
deleted "Documentation/networking/framerelay.rst". However, it is still
referenced in "Documentation/networking/index.rst". We need to remove the
reference, too.
Reported-by: Stephen R
On Tue, Nov 17, 2020 at 9:20 PM Stephen Rothwell wrote:
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/networking/index.rst:6: WARNING: toctree contains reference to
> nonexisting document 'networking/framerelay'
>
> Introduced
On Wed, Nov 18, 2020 at 12:49 AM Martin Schiller wrote:
>
> Ah, ok. Now I see what you mean.
> Yes, we should check the lapb->mode in lapb_connect_request().
...
> I also have a patch here that implements an "on demand" link feature,
> which we used for ISDN dialing connections.
> As ISDN is de fa
On Wed, Nov 18, 2020 at 5:03 AM Xie He wrote:
>
> On Wed, Nov 18, 2020 at 12:49 AM Martin Schiller wrote:
> >
> > I also have a patch here that implements an "on demand" link feature,
> > which we used for ISDN dialing connections.
> > As ISDN is de facto
On Wed, Nov 18, 2020 at 5:59 AM Martin Schiller wrote:
>
> ---
> Changes to v2:
> o restructure complete patch-set
> o keep netdev event handling in layer3 (X.25)
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
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
On Thu, Nov 19, 2020 at 9:40 PM Martin Schiller wrote:
>
> Changes to v3:
> o another complete rework of the patch-set to split event handling
> for layer2 (LAPB) and layer3 (X.25)
Thanks for your work!!
Should we also handle the NETDEV_UP event here? In previous versions
of this patch series you seemed to want to establish the L2 connection
on device-up. But in this patch, you didn't handle NETDEV_UP.
Maybe on device-up, we need to check if the carrier is up, and if it
is, we do the same thing as
On Fri, Nov 20, 2020 at 3:11 PM Xie He wrote:
>
> Should we also handle the NETDEV_UP event here? In previous versions
> of this patch series you seemed to want to establish the L2 connection
> on device-up. But in this patch, you didn't handle NETDEV_UP.
>
> Maybe on devi
On Sun, Nov 22, 2020 at 10:55 PM Martin Schiller wrote:
>
> No, they aren't independent. The carrier can only be up if the device /
> interface is UP. And as far as I can see a NETDEV_CHANGE event will also
> only be generated on interfaces that are UP.
>
> So you can be sure, that if there is a N
On Mon, Nov 23, 2020 at 1:00 AM Martin Schiller wrote:
>
> AFAIK the carrier can't be up before the device is up. Therefore, there
> will be a NETDEV_CHANGE event after the NETDEV_UP event.
>
> This is what I can see in my tests (with the HDLC interface).
>
> Is the behaviour different for e.g. la
On Mon, Nov 23, 2020 at 1:36 AM Xie He wrote:
>
> Some drivers don't support carrier status and will never change it.
> Their carrier status will always be UP. There will not be a
> NETDEV_CHANGE event.
>
> lapbether doesn't change carrier status. I also have my own vi
On Mon, Nov 23, 2020 at 2:38 AM Martin Schiller wrote:
>
> Well, one could argue that we would have to repair these drivers, but I
> don't think that will get us anywhere.
Yeah... One problem I see with the Linux project is the lack of
docs/specs. Often we don't know what is right and what is wro
On Mon, Nov 23, 2020 at 11:36 AM Jakub Kicinski wrote:
>
> > > From this point of view it will be the best to handle the NETDEV_UP in
> > > the lapb event handler and establish the link analog to the
> > > NETDEV_CHANGE event if the carrier is UP.
> >
> > Thanks! This way we can make sure LAPB wo
ATE_1 and start
> sending SABM(E).
>
> Signed-off-by: Martin Schiller
Acked-by: Xie He
Thanks!
Hi Martin,
Since we are going to assume lapb->state would remain in LAPB_STATE_0 when
the carrier is down (as understood by me. Right?), could we add a check in
lapb_connect_request to reject the upper layer's "connect" instruction when
the carrier is down? Like this:
diff --git a/include/linux/l
Acked-by: Xie He
kernel every time a connection is refused by the remote
side.
Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect")
Cc: Martin Schiller
Signed-off-by: Xie He
---
net/x25/af_x25.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git
> 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
> x25_wait_for_connection_establishment().
t_lock);
> 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 wit
ndrew 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
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 b
count 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
e the last 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
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
--- a
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 s
in x25_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/x2
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
--- a
vided 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 H
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
Hi Martin,
Thanks for the series. To get the series applied faster, could you
address the warnings and failures shown on this page?
https://patchwork.kernel.org/project/netdevbpf/list/?submitter=174539
Thanks!
To let the netdev robot know which tree this series should be applied,
we can use [PATC
On Sat, Nov 14, 2020 at 3:10 AM Xie He wrote:
>
> Martin Schiller is an active developer and reviewer for the X.25 code.
> His company is providing products based on the Linux X.25 stack.
> So he is a good candidate for maintainers of the X.25 code.
Hi Martin,
Could you ack to i
On Mon, Nov 16, 2020 at 6:01 AM Martin Schiller wrote:
>
> This makes it possible to handle carrier loss and detection.
> In case of Carrier Loss, layer 2 is terminated
> In case of Carrier Detection, we start timer t1 on a DCE interface,
> and on a DTE interface we change to state LAPB_STATE_1 an
On Tue, Nov 17, 2020 at 1:53 AM Martin Schiller wrote:
>
> On 2020-11-16 21:16, Xie He wrote:
> > Do you mean we will now automatically establish LAPB connections
> > without upper layers instructing us to do so?
>
> Yes, as soon as the physical link is established, the L2
On Mon, Nov 16, 2020 at 6:00 AM Martin Schiller wrote:
>
> This makes it possible to handle carrier lost and detection.
> In case of carrier lost, we shutdown layer 3 and flush all sessions.
>
> @@ -275,6 +275,19 @@ static int x25_device_event(struct notifier_block *this,
> unsigned long event,
>
On Tue, Nov 17, 2020 at 5:26 AM Martin Schiller wrote:
>
> On 2020-11-17 12:32, Xie He wrote:
> >
> > I think for a DCE, it doesn't need to initiate the L2
> > connection on device-up. It just needs to wait for a connection to
> > come. But L3 seems to be stil
On Mon, Nov 16, 2020 at 6:00 AM Martin Schiller wrote:
>
> Remove unnecessary function x25_kill_by_device.
> -/*
> - * Kill all bound sockets on a dropped device.
> - */
> -static void x25_kill_by_device(struct net_device *dev)
> -{
> - struct sock *s;
> -
> - write_lock_bh(&x25_l
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 t
On Fri, Nov 20, 2020 at 10:28 PM Eyal Birger wrote:
>
> Fix by changing af_packet RX ll visibility criteria to include the
> existence of a '.create()' header operation, which is used when creating
> a device hard header - via dev_hard_header() - by upper layers, and does
> not exist in these L3 d
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
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."
es this
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/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 (suppo
On Sun, Oct 18, 2020 at 3:05 PM Jakub Kicinski wrote:
>
> Whenever you make a list like that it's a strong indication that
> each of these should be a separate commit. That makes things easier
> to review.
>
>
> We have already sent a pull request for 5.10 and therefore net-next
> is closed for ne
_xmit to this).
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wan/hdlc.c b/drivers/net/wan/hdlc.c
index 9b00708676cf..0a392fb9aff8 100644
--- a/drivers/net/wan/hdlc.c
+++ b/drivers/ne
On Mon, Oct 19, 2020 at 2:22 PM Jakub Kicinski wrote:
>
> Looks correct to me. I spotted there is also IFF_WAN_HDLC added by
> 7cdc15f5f9db ("WAN: Generic HDLC now uses IFF_WAN_HDLC private flag.")
> would using that flag also be correct and cleaner potentially?
>
> Up to you, just wanted to make
On Mon, Oct 19, 2020 at 3:49 PM Jakub Kicinski wrote:
>
> Cool! FWIW when you resend you can also trim the subject to just say:
>
> net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device
>
> There's no need for the full file path.
OK. I'll do that. Thanks!
ore starting its
processing. This patch adds this check to hdlc_rcv.
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wan/hdlc.c b/drivers/net/wan/hdlc.c
index 9b00708676cf..1bdd3df08
transmission, so the skb may be modified.
Cc: Neil Horman
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_raw_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wan/hdlc_raw_eth.c b/drivers/net/wan/hdlc_raw_eth.c
index 08e0a46501de..c70a518b8b47 100644
--- a
i_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
On Wed, Oct 21, 2020 at 6:02 PM Jakub Kicinski wrote:
>
> Applied, thank you.
>
> In the future please try to provide a Fixes: tag.
OK. Thanks! I'll remember this in the future!
ic function, it cannot be used anywhere else.
Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing
IFF_TX_SKB_SHARING cleared")
Cc: Neil Horman
Cc: Jakub Kicinski
Cc: David S. Miller
Signed-off-by: Xie He
---
drivers/net/ethernet/adaptec/starfire.c | 2 ++
drivers/
Sorry. I spotted some errors in this patch. Some drivers use "ndev" as
the variable name but I mistakenly used "dev".
It was very hard for me to attempt fixing. There are too many drivers
that need to be fixed. Fixing them is very time-consuming and may also
be error-prone. So I think it may be be
ic function, it cannot be used anywhere else.
Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing
IFF_TX_SKB_SHARING cleared")
Cc: Neil Horman
Cc: Jakub Kicinski
Cc: David S. Miller
Signed-off-by: Xie He
---
drivers/net/ethernet/adaptec/starfire.c | 2 ++
drivers/
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
th
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
> > ex
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
> - for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> + for (mem = (HDW *) memmap; mem < (HDW *) ((uintptr_t)memmap + 1); ++mem)
Note that these two lines are semantically different. In the first line,
"+ 1" moves the pointer by (sizeof memmap) bytes. However in the second
line, "+
On Mon, Oct 26, 2020 at 8:56 PM Xie He wrote:
>
> > - for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> > + for (mem = (HDW *) memmap; mem < (HDW *) ((uintptr_t)memmap + 1); ++mem)
>
> Note that these two lines are semantically different. In the fi
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() doesn
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(+
: 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 chang
check 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 d
eated 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 change
eated 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 change
check 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 d
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(+
zes a few known Ethertypes when receiving and drops
skbs with other Ethertypes.
However, the standard document RFC 2427 allows Frame Relay to support any
Ethertype values. This series adds support for this.
Change from v1:
Small fix to the commit message of the second patch
Xie He (4):
net: hd
: 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 chang
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(+
check 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 d
eated 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 change
1 - 100 of 346 matches
Mail list logo
