and sets it
> conditionally when initializing the tunnel in NBMA mode. When
> header_ops->create is used, dev->hard_header_len should reflect the
> length of the header created. Otherwise, when not used,
> dev->needed_headroom should be used.
>
> Fixes: eb95f52fc72d (&quo
/core/skbuff.c:109!
Call Trace:
skb_push+0x10/0x10
ip6gre_header+0x47/0x1b0
neigh_connected_output+0xae/0xf0
ip6gre tunnel provides its own header_ops->create, and sets it
conditionally when initializing the tunnel in NBMA mode. When
header_ops->create is used, dev->hard_header_l
On Tue, 3 Nov 2020 11:41:33 +0100 Oliver Herms wrote:
> Due to the legacy usage of hard_header_len for SIT tunnels while
> already using infrastructure from net/ipv4/ip_tunnel.c the
> calculation of the path MTU in tnl_update_pmtu is incorrect.
> This leads to unnecessary cre
On Mon, Nov 9, 2020 at 4:05 AM Oliver Herms
wrote:
>
>
> On 04.11.20 20:52, Willem de Bruijn wrote:
> >>>> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> >>>
> >>> How did you arrive at this SHA1?
> >> I thin
On 04.11.20 20:52, Willem de Bruijn wrote:
>>>> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
>>>
>>> How did you arrive at this SHA1?
>> I think the legacy usage of hard_header_len in ipv6/sit.c was overseen in
>> c54419321455.
On Wed, Nov 4, 2020 at 2:30 PM Oliver Herms
wrote:
>
> On 03.11.20 19:42, Willem de Bruijn wrote:
> > Thanks. Yes, this is long overdue.
> >
> > The hard_header_len issue was also recently discussed in the context
> > of GRE in commit fdafed459998 ("ip_gre: s
On 03.11.20 19:42, Willem de Bruijn wrote:
> Thanks. Yes, this is long overdue.
>
> The hard_header_len issue was also recently discussed in the context
> of GRE in commit fdafed459998 ("ip_gre: set dev->hard_header_len and
> dev->needed_headroom properly").
>
On Tue, Nov 3, 2020 at 5:41 AM Oliver Herms
wrote:
>
> Due to the legacy usage of hard_header_len for SIT tunnels while
> already using infrastructure from net/ipv4/ip_tunnel.c the
> calculation of the path MTU in tnl_update_pmtu is incorrect.
> This leads to unnecessary
Due to the legacy usage of hard_header_len for SIT tunnels while
already using infrastructure from net/ipv4/ip_tunnel.c the
calculation of the path MTU in tnl_update_pmtu is incorrect.
This leads to unnecessary creation of MTU exceptions for any
flow going over a SIT tunnel.
As SIT tunnels do not
raw packet socket,
where L2 headers are supposed to be constructed by user. Packet
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Simi
raw packet socket,
where L2 headers are supposed to be constructed by user. Packet
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Simi
raw packet socket,
where L2 headers are supposed to be constructed by user. Packet
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Simi
raw packet socket,
where L2 headers are supposed to be constructed by user. Packet
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Simi
On Thu, Oct 15, 2020 at 3:19 PM Xie He wrote:
>
> On Thu, Oct 15, 2020 at 6:42 AM Willem de Bruijn
> wrote:
> >
> > On Wed, Oct 14, 2020 at 10:25 PM Xie He wrote:
> > >
> > > Actually I think dev->type can be seen from user space. For example,
> > > when you type "ip link", it will display the l
On Thu, Oct 15, 2020 at 6:42 AM Willem de Bruijn
wrote:
>
> On Wed, Oct 14, 2020 at 10:25 PM Xie He wrote:
> >
> > Actually I think dev->type can be seen from user space. For example,
> > when you type "ip link", it will display the link type for you. So I
> > think it is useful to keep different
; > > I thought we agreed that ideally GRE devices would not have
> > > > header_ops. Currently GRE devices (in normal situations) indeed do not
> > > > use header_ops (and use ARHPHRD_IPGRE as dev->type). I think we should
> > > > keep this behavior.
&
ops. Currently GRE devices (in normal situations) indeed do not
> > > use header_ops (and use ARHPHRD_IPGRE as dev->type). I think we should
> > > keep this behavior.
> > >
> > > To solve the problem of the same dev->type having different
> &
_ops (and use ARHPHRD_IPGRE as dev->type). I think we should
> > keep this behavior.
> >
> > To solve the problem of the same dev->type having different
> > hard_header_len values which you mentioned. I think we should create a
> > new dev->type (ARPHRD_IPGR
On Wed, Oct 14, 2020 at 3:48 PM Xie He wrote:
>
> On Wed, Oct 14, 2020 at 8:12 AM Willem de Bruijn
> wrote:
> >
> > On Wed, Oct 14, 2020 at 4:52 AM Xie He wrote:
> > >
> > > On Sun, Oct 11, 2020 at 2:01 PM Willem de Bruijn
> > > wrote:
> &g
On Wed, Oct 14, 2020 at 8:12 AM Willem de Bruijn
wrote:
>
> On Wed, Oct 14, 2020 at 4:52 AM Xie He wrote:
> >
> > On Sun, Oct 11, 2020 at 2:01 PM Willem de Bruijn
> > wrote:
> > >
> > > There is agreement that hard_header_len should be the length of lin
On Wed, Oct 14, 2020 at 4:52 AM Xie He wrote:
>
> On Sun, Oct 11, 2020 at 2:01 PM Willem de Bruijn
> wrote:
> >
> > There is agreement that hard_header_len should be the length of link
> > layer headers visible to the upper layers, needed_headroom the
> > add
On Sun, Oct 11, 2020 at 2:01 PM Willem de Bruijn
wrote:
>
> There is agreement that hard_header_len should be the length of link
> layer headers visible to the upper layers, needed_headroom the
> additional room required for headers that are not exposed, i.e., those
> pushed inside
w packet socket,
> where L2 headers are supposed to be constructed by user. Packet
> socket calls dev_validate_header() to validate the header. But
> GRE tunnel does not set dev->hard_header_len, so that check can
> be simply bypassed, therefore uninit memory could be passed down
>
raw packet socket,
> where L2 headers are supposed to be constructed by user. Packet
> socket calls dev_validate_header() to validate the header. But
> GRE tunnel does not set dev->hard_header_len, so that check can
> be simply bypassed, therefore uninit memory could be passed down
&
On Mon, Oct 12, 2020 at 4:17 PM Cong Wang wrote:
>
> Note, there are some other suspicious use of dev->hard_header_len in
> the same file, but let's leave them to a separate patch if really
> needed.
I looked at the file (before this patch). There are 4 occurrences of
hard_
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Similar for dev->needed_headroom.
dev->hard_header_len is supposed to be the
r new headers */
> > - if (skb_cow_head(skb, dev->needed_headroom -
> > - (tunnel->hlen + sizeof(struct
> > iphdr
> > + if (skb_cow_head(skb, dev->hard_header_len))
> >
dev->needed_headroom -
> - (tunnel->hlen + sizeof(struct iphdr
> + if (skb_cow_head(skb, dev->hard_header_len))
> goto free_skb;
>
> tnl_params = (const struct iphdr *)skb->data;
As I understand, the
On Sun, Oct 11, 2020 at 2:01 PM Willem de Bruijn
wrote:
>
> There is agreement that hard_header_len should be the length of link
> layer headers visible to the upper layers, needed_headroom the
> additional room required for headers that are not exposed, i.e., those
> pushed inside
in a separate patch?
> >
> > Removing header_ops->create would simplify the fixing of the issue you
> > are trying to fix, too, because that way we would no longer need to
> > use header_ops or hard_header_len. Also, I'm worried that changing
> > hard_header_
eady created before ipgre_xmit().
> >
> > This is not true when we send packets through a raw packet socket,
> > where L2 headers are supposed to be constructed by user. Packet
> > socket calls dev_validate_header() to validate the header. But
> > GRE tunnel does not set de
ore ipgre_xmit().
> >
> > This is not true when we send packets through a raw packet socket,
> > where L2 headers are supposed to be constructed by user. Packet
> > socket calls dev_validate_header() to validate the header. But
> > GRE tunnel does not set dev->hard_
raw packet socket,
> where L2 headers are supposed to be constructed by user. Packet
> socket calls dev_validate_header() to validate the header. But
> GRE tunnel does not set dev->hard_header_len, so that check can
> be simply bypassed, therefore uninit memory could be passed down
&
raw packet socket,
> where L2 headers are supposed to be constructed by user. Packet
> socket calls dev_validate_header() to validate the header. But
> GRE tunnel does not set dev->hard_header_len, so that check can
> be simply bypassed, therefore uninit memory could be passed down
&
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Similar for dev->needed_headroom.
dev->hard_header_len is supposed to be the
On Sat, Oct 10, 2020 at 11:58 AM Cong Wang wrote:
>
> Well, AF_PACKET RAW socket is supposed to construct L2 headers
> from the user buffer, and for a tunnel device these headers are indeed its
> L2. If users do not want to do this, they can switch to DGRAM anyway.
>
> I know how inconvenient it i
On Sat, Oct 10, 2020 at 2:49 PM Xie He wrote:
>
> Another reason why tunnel devices usually don't provide
> header_ops->create might be to keep consistency with TAP devices. TAP
> devices are just like tunnel (TUN) devices except that they use an
> additional Ethernet header after the tunnel heade
On Fri, Oct 9, 2020 at 8:10 PM Xie He wrote:
>
> On Fri, Oct 9, 2020 at 6:07 PM Cong Wang wrote:
> >
> > Looking a bit deeper, I doubt the ipgre_header_ops->create is necessary,
> > because 1) all other tunnels devices do not have it (ip_tunnel_header_ops
> > only contains ->parse_protocol); 2) G
On Sat, Oct 10, 2020 at 11:58 AM Cong Wang wrote:
>
> On Fri, Oct 9, 2020 at 8:10 PM Xie He wrote:
> >
> > This seems so weird to me. If a user is using an AF_PACKET/RAW socket,
> > the user is supposed to do what the header_ops->create function does
> > (that is, creating two headers and leaving
On Fri, Oct 9, 2020 at 6:07 PM Cong Wang wrote:
>
> Looking a bit deeper, I doubt the ipgre_header_ops->create is necessary,
> because 1) all other tunnels devices do not have it (ip_tunnel_header_ops
> only contains ->parse_protocol); 2) GRE headers are pushed in xmit
> anyway, so at least SOCK_D
ead_len because for GRE tunnel
> those are its link-layer header. What makes it more complicated
> is that header_ops is actually set conditionally, so should be
> hard_header_len/needed_head_room accordingly.
Looking a bit deeper, I doubt the ipgre_header_ops->create is necessary,
b
On Fri, Oct 9, 2020 at 12:51 PM Xie He wrote:
>
> On Fri, Oct 9, 2020 at 12:41 PM Xie He wrote:
> >
> > Thanks. But there is still something that I don't understand. What is
> > needed_headroom used for? If we are requesting space for t->encap_hlen
> > and
On Fri, Oct 9, 2020 at 12:41 PM Xie He wrote:
>
> Thanks. But there is still something that I don't understand. What is
> needed_headroom used for? If we are requesting space for t->encap_hlen
> and t->tun_hlen in hard_header_len. Do we still need to use
> needed_head
On Fri, Oct 9, 2020 at 10:44 AM Cong Wang wrote:
>
> On Thu, Oct 8, 2020 at 4:40 PM Xie He wrote:
> >
> > I found another possible issue. Shouldn't we update hard_header_len
> > every time t->tun_hlen and t->hlen are updated in ipgre_link_update?
>
> Go
On Thu, Oct 8, 2020 at 4:40 PM Xie He wrote:
>
> I found another possible issue. Shouldn't we update hard_header_len
> every time t->tun_hlen and t->hlen are updated in ipgre_link_update?
Good catch. It should be updated there like ->needed_headroom.
I will update my patch.
Thanks.
after the GRE header.
I found another possible issue. Shouldn't we update hard_header_len
every time t->tun_hlen and t->hlen are updated in ipgre_link_update?
On Thu, Oct 8, 2020 at 2:48 PM Willem de Bruijn
wrote:
>
> > I see the ipgre_xmit function would pull the header our header_ops
> > creates, and then call __gre_xmit. __gre_xmit will call
> > gre_build_header to complete the GRE header. gre_build_header expects
> > to find the base GRE header afte
On Thu, Oct 8, 2020 at 5:36 PM Xie He wrote:
>
> On Thu, Oct 8, 2020 at 1:32 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 4:11 PM Xie He wrote:
> > >
> > > OK. I understand that t->tun_hlen is the GRE header length. What is
> > > t->encap_hlen?
> >
> > I've looked at that closely
On Thu, Oct 8, 2020 at 1:32 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 4:11 PM Xie He wrote:
> >
> > OK. I understand that t->tun_hlen is the GRE header length. What is
> > t->encap_hlen?
>
> I've looked at that closely either.
>
> Appears to be to account for additional FOU/GUE encap:
On Thu, Oct 8, 2020 at 4:11 PM Xie He wrote:
>
> On Thu, Oct 8, 2020 at 12:20 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 3:17 PM Xie He wrote:
> > >
> > > However, there's something I don't understand in the GRE code. The
> > > ipgre_header function only creates an IP header (20
raw packet socket,
> where L2 headers are supposed to be constructed by user. Packet
> socket calls dev_validate_header() to validate the header. But
> GRE tunnel does not set dev->hard_header_len, so that check can
> be simply bypassed, therefore uninit memory could be passed down
&
On Thu, Oct 8, 2020 at 12:20 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 3:17 PM Xie He wrote:
> >
> > However, there's something I don't understand in the GRE code. The
> > ipgre_header function only creates an IP header (20 bytes) + a GRE
> > base header (4 bytes), but pushes and retu
r IP header is
> > > > > already created before ipgre_xmit().
> > > > >
> > > > > This is not true when we send packets through a raw packet socket,
> > > > > where L2 headers are supposed to be constructed by user. Packet
> > > &g
On Thu, Oct 8, 2020 at 3:17 PM Xie He wrote:
>
> On Thu, Oct 8, 2020 at 12:04 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> > >
> > > The uninit data is allocated by packet_alloc_skb(), if
> > > dev-&
send packets through a raw packet socket,
> > > > where L2 headers are supposed to be constructed by user. Packet
> > > > socket calls dev_validate_header() to validate the header. But
> > > > GRE tunnel does not set dev->hard_header_len, so that check can
> &g
On Thu, Oct 8, 2020 at 12:04 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> >
> > The uninit data is allocated by packet_alloc_skb(), if dev->hard_header_len
> > is 0 and 'len' is anything between [0, tunnel->hlen + sizeof
gt; > socket calls dev_validate_header() to validate the header. But
> > > GRE tunnel does not set dev->hard_header_len, so that check can
> > > be simply bypassed, therefore uninit memory could be passed down
> > > to ipgre_xmit().
> >
> > If dev
eady created before ipgre_xmit().
> >
> > This is not true when we send packets through a raw packet socket,
> > where L2 headers are supposed to be constructed by user. Packet
> > socket calls dev_validate_header() to validate the header. But
> > GRE tunnel does not set de
raw packet socket,
> where L2 headers are supposed to be constructed by user. Packet
> socket calls dev_validate_header() to validate the header. But
> GRE tunnel does not set dev->hard_header_len, so that check can
> be simply bypassed, therefore uninit memory could be passe
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit().
Fix this by setting dev->hard_header_len whenever sets header_ops,
From: Xie He
Date: Mon, 14 Sep 2020 00:41:54 -0700
> This comment is outdated and no longer reflects the actual implementation
> of af_packet.c.
>
> Reasons for the new comment:
>
> 1.
>
> In af_packet.c, the function packet_snd first reserves a headroom of
> l
On Mon, Sep 14, 2020 at 9:42 AM Xie He wrote:
>
> This comment is outdated and no longer reflects the actual implementation
> of af_packet.c.
>
> Reasons for the new comment:
>
> 1.
>
> In af_packet.c, the function packet_snd first reserves a headroom of
> leng
This comment is outdated and no longer reflects the actual implementation
of af_packet.c.
Reasons for the new comment:
1.
In af_packet.c, the function packet_snd first reserves a headroom of
length (dev->hard_header_len + dev->needed_headroom).
Then if the socket is a SOCK_DGRAM sock
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 Sat, Sep 12, 2020 at 1:37 AM Xie He wrote:
>
> 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.
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 7:04 AM Xie He wrote:
>
> This patch tries to clarify the difference between hard_header_len and
> needed_headroom by fixing an outdated comment and adding a WARN_ON_ONCE
> warning for hard_header_len.
>
> The difference between hard_header_len and
This patch tries to clarify the difference between hard_header_len and
needed_headroom by fixing an outdated comment and adding a WARN_ON_ONCE
warning for hard_header_len.
The difference between hard_header_len and needed_headroom as understood
by this patch is based on the following reasons:
1
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.
On Thu, Sep 10, 2020 at 7:44 AM Xie He wrote:
>
> The difference between hard_header_len and needed_headroom has long been
> confusing to driver developers. Let's clarify it.
>
> The understanding on this issue in this patch is based on the following
> reasons:
>
&g
The difference between hard_header_len and needed_headroom has long been
confusing to driver developers. Let's clarify it.
The understanding on this issue in this patch is based on the following
reasons:
1.
In af_packet.c, the function packet_snd first reserves a headroom of
length
The difference between hard_header_len and needed_headroom has long been
confusing to driver developers. Let's clarify it.
The understanding of the difference in this patch is based on the
following reasons:
1.
In this file, the function packet_snd first reserves a headroom of
length
> > > > More about the older comment, but if reusing: it's not entirely clear
> > > > to me what "outside of the device" means. The upper layers that
> > > > receive data from the device and send data to it, including
> > > > packet_snd, I suppose? Not the lower layers, clearly. Maybe that can
> >
lf. In this case ll header is invisible outside of
> > > > device,
> > > > - but higher levels still should reserve dev->hard_header_len.
> > > > - Some devices are enough clever to reallocate skb, when header
> > > > - will not fit to reserved space
r reflects the actual implementation
> > > of af_packet.c.
> >
> > If it was previously true, can you point to a commit that changes the
> > behavior?
>
> This is my understanding about the history of "af_packet.c":
>
> 1. Pre git history
>
> At first, b
can you point to a commit that changes the
> behavior?
This is my understanding about the history of "af_packet.c":
1. Pre git history
At first, before "needed_headroom" was introduced, "hard_header_len"
was the only way for a driver to request headroom
From: Xie He
[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a h
From: Xie He
[ Upstream commit 2b7bcd967a0f5b7ac9bb0c37b92de36e073dd119 ]
Change the default value of hard_header_len in hdlc.c from 16 to 0.
Currently there are 6 HDLC protocol drivers, among them:
hdlc_raw_eth, hdlc_cisco, hdlc_ppp, hdlc_x25 set hard_header_len when
attaching the protocol
From: Xie He
[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a h
From: Xie He
[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a h
From: Xie He
[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a h
From: Xie He
[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a h
From: Xie He
[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a h
In this file, the function packet_snd first reserves a headroom of
> length (dev->hard_header_len + dev->needed_headroom).
> Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
> which calls dev->header_ops->create, to create the link layer header.
> If
This comment is outdated and no longer reflects the actual implementation
of af_packet.c.
Reasons for the new comment:
1.
In this file, the function packet_snd first reserves a headroom of
length (dev->hard_header_len + dev->needed_headroom).
Then if the socket is a SOCK_DGRAM socket, it
From: Xie He
Date: Wed, 2 Sep 2020 05:07:06 -0700
> Change the default value of hard_header_len in hdlc.c from 16 to 0.
>
> Currently there are 6 HDLC protocol drivers, among them:
>
> hdlc_raw_eth, hdlc_cisco, hdlc_ppp, hdlc_x25 set hard_header_len when
> attaching the pr
Change the default value of hard_header_len in hdlc.c from 16 to 0.
Currently there are 6 HDLC protocol drivers. Among them:
hdlc_raw_eth, hdlc_cisco, hdlc_ppp, hdlc_x25 set hard_header_len when
attaching the protocol, overriding the default. So this patch does not
affect them.
hdlc_raw and
Change the default value of hard_header_len in hdlc.c from 16 to 0.
Currently there are 6 HDLC protocol drivers, among them:
hdlc_raw_eth, hdlc_cisco, hdlc_ppp, hdlc_x25 set hard_header_len when
attaching the protocol, overriding the default. So this patch does not
affect them.
hdlc_raw and
From: Xie He
Date: Fri, 28 Aug 2020 00:07:52 -0700
> This driver didn't set hard_header_len. This patch sets hard_header_len
> for it according to its header_ops->create function.
>
> This driver's header_ops->create function (cisco_hard_header) creates
> a hea
On Fri, Aug 28, 2020 at 3:37 AM Krzysztof Hałasa wrote:
>
> OTOH hdlc_setup_dev() initializes hard_header_len to 16,
> but in this case I guess 4 bytes are better.
>
> Acked-by: Krzysztof Halasa
Thank you, Krzysztof!
Actually I'm thinking about changing the default value
Hello Xie,
Xie He writes:
> This driver didn't set hard_header_len. This patch sets hard_header_len
> for it according to its header_ops->create function.
BTW it's 4 bytes long:
struct hdlc_header {
u8 address;
u8 control;
__be16 protoco
This driver didn't set hard_header_len. This patch sets hard_header_len
for it according to its header_ops->create function.
This driver's header_ops->create function (cisco_hard_header) creates
a header of (struct hdlc_header), so hard_header_len should be set to
sizeof(struct h
On Wed, Aug 5, 2020 at 10:57 AM Xie He wrote:
>
> 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 d
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 re
On 2020-08-04 21:20, Xie He wrote:
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
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 lapbeth_data_transm
On 2020-08-02 21:50, Xie He wrote:
In net/packet/af_packet.c, the function packet_snd first reserves a
headroom of length (dev->hard_header_len + dev->needed_headroom).
Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
which calls dev->header_ops->create, to cre
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 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
> > "undeliver
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 conseque
1 - 100 of 206 matches
Mail list logo
