Acked-by: Xie He
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
ATE_1 and start
> sending SABM(E).
>
> Signed-off-by: Martin Schiller
Acked-by: Xie He
Thanks!
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
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 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 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 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 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
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 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!!
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 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 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 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 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
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 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 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:
>
> 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 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: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 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
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 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
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
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
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
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
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
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
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
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
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
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 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
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
> 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().
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
On Sat, Oct 31, 2020 at 3:04 PM Jakub Kicinski wrote:
>
> On Sat, 31 Oct 2020 22:41:30 +0100 Arnd Bergmann wrote:
> >
> > I think it can just go in the bin directly.
>
> Ack, fine by me.
>
> > I actually submitted a couple of patches to clean up drivers/net/wan
> > last year but didn't follow up w
On Tue, Nov 3, 2020 at 6:03 PM Xie He wrote:
>
> On Tue, Nov 3, 2020 at 3:22 PM Jakub Kicinski wrote:
> >
> > Applied, but going forward please limit any refactoring and extensions
> > to the HDLC code. I thought you are actually using it. If that's not
> > the
On Fri, Nov 6, 2020 at 1:03 AM David Laight wrote:
>
> Hmmm LAPB would expect to have an X.25 level 3 and maybe ISO
> transport (class 0, 2 or 3) sat on top of it.
I actually used AF_PACKET sockets to transport data directly over LAPB
and it worked.
LAPB doesn't need anything from layer 3. I
On Thu, Nov 5, 2020 at 12:40 PM Arnd Bergmann wrote:
>
> > I think this driver never worked. Looking at the original code in
> > Linux 2.1.31, it already has the problems I fixed in commit
> > 8fdcabeac398.
> >
> > I guess when people (or bots) say they "tested", they have not
> > necessarily used
On Thu, Nov 5, 2020 at 7:07 AM Arnd Bergmann wrote:
>
> Adding Martin Schiller and Andrew Hendry, plus the linux-x25 mailing
> list to Cc.
The linux-x25 mail list has stopped working for a long time.
> When I last looked at the wan drivers, I think I concluded
> that this should still be kept ar
On Thu, Nov 5, 2020 at 1:10 AM David Laight wrote:
>
> > This driver transports LAPB (X.25 link layer) frames over TTY links.
>
> I don't remember any requests to run LAPB over anything other
> than synchronous links when I was writing LAPB implementation(s)
> back in the mid 1980's.
>
> If you ne
completely received.
And there may also be other problems.
I was planning to fix these problems but after recent discussions about
deleting other old networking code, I think we may just delete this
driver, too.
Signed-off-by: Xie He
---
Documentation/process/magic-number.rst| 1 -
On Tue, Nov 3, 2020 at 3:22 PM Jakub Kicinski wrote:
>
> Applied, but going forward please limit any refactoring and extensions
> to the HDLC code. I thought you are actually using it. If that's not
> the case let's leave the code be, it's likely going to be removed in
> a few years time.
OK. I u
On Sat, Oct 31, 2020 at 2:41 PM Arnd Bergmann wrote:
>
> I think it can just go in the bin directly. I actually submitted a couple of
> patches to clean up drivers/net/wan last year but didn't follow up
> with a new version after we decided that x.25 is still needed, see
> https://lore.kernel.org/
On Sat, Oct 31, 2020 at 12:48 PM Willem de Bruijn
wrote:
>
> Returning code in branches vs an error jump label seems more of a
> personal preference, and to me does not pass the benefit/cost threshold.
This patch is necessary for the 2nd and 5th patch in this series,
because the 2nd and 5th patch
recognizes a few Ethertype values and drops frames with other
Ethertype values. This patch replaces this code to make fr_rx support
any Ethertype. This patch also creates a new function fr_snap_parse as
part of the new code.
Cc: Krzysztof Halasa
Cc: Willem de Bruijn
Signed-off-by: Xie He
---
drivers
tches.
Improve the commit message about the stats.rx_dropped count.
Change from v2:
Small fix to the commit messages.
Change from v1:
Small fix to the commit messages.
Xie He (5):
net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
net: hdlc_fr: Change the use of &q
: 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
Cc: Willem de Bruijn
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 37 --
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
Cc: Willem de Bruijn
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 2 +-
1 file changed, 1 i
't be visible to upper layer code when receiving, either.
Cc: Krzysztof Halasa
Cc: Willem de Bruijn
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 71ee9b60d91b..eb83116aa
eated several times, this
patch uses "goto rx_drop" to replace them so that the code looks cleaner.
Cc: Krzysztof Halasa
Cc: Willem de Bruijn
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/ne
On Sat, Oct 31, 2020 at 9:51 AM Jakub Kicinski wrote:
>
> > > The usual way of getting rid of old code is to move it to staging/
> > > for a few releases then delete it, like Arnd just did with wimax.
> >
> > Oh. OK. But I see "include/linux/if_frad.h" is included in
> > "net/socket.c", and there'
On Fri, Oct 30, 2020 at 5:49 PM Xie He wrote:
>
> Add an fh->ea2 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. If the address length is not
> 2 byt
On Sat, Oct 31, 2020 at 8:18 AM Xie He wrote:
>
> > Especially without that, I'm not sure this and the follow-on patch add
> > much value. Minor code cleanups complicate backports of fixes.
>
> To me this is necessary, because I feel hard to do any development on
>
On Sat, Oct 31, 2020 at 7:33 AM Willem de Bruijn
wrote:
>
> > - rx_error:
> > +rx_error:
> > frad->stats.rx_errors++; /* Mark error */
> > +rx_drop:
> > dev_kfree_skb_any(skb);
> > return NET_RX_DROP;
>
> I meant that I don't think errors should be double counted in rx_erro
On Fri, Oct 30, 2020 at 8:07 PM Jakub Kicinski wrote:
>
> This code has only seen cleanup patches since the git era begun -
> do you think that it may still have users? Or is it completely unused?
I don't think it is still used. But I don't have solid evidence. So I
asked people in the warning me
-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 75 +--
1 file changed, 49 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 98444f1d8cc3..0720f5f92caa 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net
t the
stats.rx_dropped count is also increased after "goto rx_error".
Change from v2:
Small fix to the commit messages.
Change from v1:
Small fix to the commit messages.
Xie He (5):
net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
net: hdlc_fr: Change the use of &
: 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: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 37 --
't be visible to upper layer code when receiving, either.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Acked-by: Willem de Bruijn
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_
ay it is 3 bytes, then the control field
and the protocol field would be the 4th and 5th byte instead.)
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/hdl
eated several times, this
patch uses "goto rx_drop" to replace them so that the code looks cleaner.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/ne
't be visible to upper layer code when receiving, either.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Acked-by: Willem de Bruijn
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_
eated several times, this
patch uses "goto rx_drop" to replace them so that the code looks cleaner.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/ne
: 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: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 37 --
-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 75 +--
1 file changed, 49 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 98444f1d8cc3..0720f5f92caa 100644
--- a/drivers/net/wan/hdlc_fr.c
+++ b/drivers/net
o rx_error".
Change from v2:
Small fix to the commit messages.
Change from v1:
Small fix to the commit messages.
Xie He (5):
net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
net: hdlc_fr: Change the use of "dev" in fr_rx to make the
(Say if it is 3 bytes, then the control field
and the protocol field would be the 4th and 5th byte instead.)
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/hdl
On Fri, Oct 30, 2020 at 3:22 PM Willem de Bruijn
wrote:
>
> It's indirect:
>
> skb_reset_network_header(skb);
> if (!skb_transport_header_was_set(skb))
> skb_reset_transport_header(skb);
> skb_reset_mac_len(skb);
Oh. I see. skb_reset_mac_len would set skb->
On Fri, Oct 30, 2020 at 2:28 PM Willem de Bruijn
wrote:
>
> Yes, it might require holding off the other patches until net is
> merged into net-next.
>
> Packet sockets are likely not the only way these packets are received?
> It changes mac_len as computed in __netif_receive_skb_core.
I looked at
On Fri, Oct 30, 2020 at 2:20 PM Willem de Bruijn
wrote:
>
> Thanks for that context. If it's not captured in the code, it would be
> great to include in the commit message.
OK. I'll update the commit message.
> From a quick scan, RFC 2427 does not appear to actually define the
> Q.922 address. F
On Fri, Oct 30, 2020 at 2:12 PM Willem de Bruijn
wrote:
>
> Jakub recently made stats behavior less ambiguous, in commit
> 0db0c34cfbc9 ("net: tighten the definition of interface statistics").
>
> That said, it's not entirely clear whether rx_dropped would be allowed
> to include rx_errors.
>
> My
On Fri, Oct 30, 2020 at 9:30 AM Willem de Bruijn
wrote:
>
> Acked-by: Willem de Bruijn
Thanks for your ack!
> Should this go to net if a bugfix though?
Yes, this should theoretically be a bug fix. But I didn't think this
was an important fix, because af_packet.c already had workarounds for
thi
On Fri, Oct 30, 2020 at 9:35 AM Willem de Bruijn
wrote:
>
> In general we try to avoid changing counter behavior like that, as
> existing users
> may depend on current behavior, e.g., in dashboards or automated monitoring.
>
> I don't know how realistic that is in this specific case, no strong
> o
On Fri, Oct 30, 2020 at 9:33 AM Willem de Bruijn
wrote:
>
> Should this still check data[5] == FR_PAD?
No, the 6th byte (data[5]) is not a padding field. It is the first
byte of the SNAP header. The original code is misleading. That is part
of the reasons why I want to fix it with this patch.
Th
On Fri, Oct 30, 2020 at 9:31 AM Willem de Bruijn
wrote:
>
> > Add an fh->ea2 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.
>
> Can you elaborate a bit for readers not
> Fix the following coccinelle warnings:
>
> ./drivers/net/wan/sdla.c:841:38-39: WARNING: sum of probable bitmasks,
> consider |
>
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/net/wan/sdla.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers
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: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 2 +-
1 file changed, 1 i
recognizes a few Ethertype values and drops frames with other
Ethertype values. This patch replaces this code to make fr_rx support
any Ethertype. This patch also creates a new function fr_snap_parse as
part of the new code.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers
't be visible to upper layer code when receiving, either.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
index 3639c2bfb141..9a3757568
: 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: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 37 --
use I think we should increase this value whenever an
skb is dropped.
Cc: Willem de Bruijn
Cc: Krzysztof Halasa
Signed-off-by: Xie He
---
drivers/net/wan/hdlc_fr.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/n
e 1st patch to explicitly state that the
stats.rx_dropped count is also increased after "goto rx_error".
Change from v2:
Small fix to the commit message of the 2nd and 3rd patch
Change from v1:
Small fix to the commit message of the 2nd patch
Xie He (5):
net: hdlc_fr: Simpify fr_rx
On Thu, Oct 29, 2020 at 4:53 PM Xie He wrote:
>
> > Does it make sense to define a struct snap_hdr instead of manually
> > casting all these bytes?
>
> > And macros or constant integers to self document these kinds of fields.
>
> Yes, we can define a struct s
On Thu, Oct 29, 2020 at 10:24 AM Willem de Bruijn
wrote:
>
> > Also add skb_reset_mac_header before we pass an skb (received on normal
> > PVC 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.
>
> Thi
On Thu, Oct 29, 2020 at 9:58 AM Willem de Bruijn
wrote:
>
> No need for dev at all then?
Right, there's no need for "dev" at all actually. I kept "dev" just to
keep the code for updating "dev->stats" simpler, because otherwise we
need to write "skb->dev->stats" instead, and there are 3 lines wher
On Thu, Oct 29, 2020 at 10:00 AM Willem de Bruijn
wrote:
>
> This does change rx_dropped count on errors. Not sure how important
> that is. But perhaps good to call out in the commit explicitly if it's
> intentional.
Yes, this is intentional, because I think we need to count it as a
"drop" whenev
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.
Signed-off-by: Xie He
---
Documentation/networking/framerelay.rst | 3 ++
e to: 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
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_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
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
l fix to the commit message of the 2nd patch
Xie He (4):
net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
net: hdlc_fr: Change the use of "dev" in fr_rx to make the code
cleaner
net: hdlc_fr: Improve the initial checks when we receive an skb
net:
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
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.
Xie He (4):
net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames
101 - 200 of 323 matches
Mail list logo
