* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2017-05-22 3:14 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, mlichvar, willemb
In-Reply-To: <20170522111605.14f93676@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 May 2017 11:16:05 +1000
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>
> This probably broke every architecture that has its own
> arch/<arch>/include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
>
> I have used the net-next tree from next-20170519 for today.
I've just pushed the following, thanks for the report:
====================
net: Define SCM_TIMESTAMPING_PKTINFO on all architectures.
A definition was only provided for asm-generic/socket.h
using platforms, define it for the others as well
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
11 files changed, 22 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 148d7a3..0926de6 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 1ccf456..e491ff0 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b4..8693724 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index ae6548d..5d97890 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 3418ec9..365ff51 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92..d013c0d 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 5147018..784b871 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_COOKIE 0x4032
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0..bc4ca72 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf..fb9769d 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19..5d67330 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
#define SO_COOKIE 0x003b
+#define SCM_TIMESTAMPING_PKTINFO 0x003c
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 1eb6d2f..982c253 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -109,4 +109,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _XTENSA_SOCKET_H */
--
2.7.4
^ permalink raw reply related
* [PATCH] Accept packets that the H.245 ALG can't process
From: Blair Steven @ 2017-05-22 2:07 UTC (permalink / raw)
To: netdev; +Cc: Blair Steven
In-Reply-To: <20170522020753.16712-1-blair.steven@alliedtelesis.co.nz>
When two VoIP end points are configured differently (fast connect /
not fast connect) the ALG was failing to find a matching expectation
and dropping packets in one direction.
Dropping packets not the job of an ALG, and as such the behaviour
has been changed to allow the packet to be send to the forwarding
engine.
Signed-off-by: Blair Steven <blair.steven@alliedtelesis.co.nz>
---
net/netfilter/nf_conntrack_h323_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c
index 3bcdc71..6161375 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -625,7 +625,7 @@ static int h245_help(struct sk_buff *skb, unsigned int protoff,
drop:
spin_unlock_bh(&nf_h323_lock);
nf_ct_helper_log(skb, ct, "cannot process H.245 message");
- return NF_DROP;
+ return NF_ACCEPT;
}
/****************************************************************************/
@@ -1200,7 +1200,7 @@ static int q931_help(struct sk_buff *skb, unsigned int protoff,
drop:
spin_unlock_bh(&nf_h323_lock);
nf_ct_helper_log(skb, ct, "cannot process Q.931 message");
- return NF_DROP;
+ return NF_ACCEPT;
}
/****************************************************************************/
@@ -1785,7 +1785,7 @@ static int ras_help(struct sk_buff *skb, unsigned int protoff,
drop:
spin_unlock_bh(&nf_h323_lock);
nf_ct_helper_log(skb, ct, "cannot process RAS message");
- return NF_DROP;
+ return NF_ACCEPT;
}
/****************************************************************************/
--
2.9.3
^ permalink raw reply related
* [PATCH] H.245 ALG dropping packets
From: Blair Steven @ 2017-05-22 2:07 UTC (permalink / raw)
To: netdev; +Cc: Blair Steven
We have a setup where two VoIP phones are communicating through a
router on a trusted LAN where the H.245 ALG is dropping some of the
traffic, so far as I can tell without good cause. These two devices
are configured differently, one with Fast Connect and one without -
this might be the reason, but from my (limited) understanding of ALGs
this isn't a good enough reason.
Does it ever make sense to drop packets in an ALG?
Blair Steven (1):
Accept packets that the H.245 ALG can't process
net/netfilter/nf_conntrack_h323_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2017-05-22 1:16 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Miroslav Lichvar, Willem de Bruijn
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
net/socket.c: In function 'put_ts_pktinfo':
net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
^
Caused by commit
aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
This probably broke every architecture that has its own
arch/<arch>/include/uapi/asm/socket.h that does not include
include/uapi/asm-generic/socket.h :-(
I have used the net-next tree from next-20170519 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* (unknown),
From: mari.kayhko @ 2017-05-22 0:57 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 58679201840822.zip --]
[-- Type: application/zip, Size: 3176 bytes --]
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio
From: Alexander Duyck @ 2017-05-21 22:35 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Amritha Nambiar, intel-wired-lan, Linux Netdev List
In-Reply-To: <CAJ3xEMjTDW7sQ5CFmTyR5xMpin_WFFQg-S8imWMBpXWuS1zvVw@mail.gmail.com>
On Sat, May 20, 2017 at 2:15 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Sat, May 20, 2017 at 3:58 AM, Amritha Nambiar
> <amritha.nambiar@intel.com> wrote:
>> The following series introduces a new harware offload mode in tc/mqprio
>
> Wait, we have already a HW QoS model introduced by John F and Co
> couple of years ago, right?
I assume you are referring to the ETS portion of DCBX? If so then yes
we have something there, but there is a fairly high level of
complexity and dependencies in order to enable that. What we have in
mind doesn't really fit with DCBX and the problem is the spec calls
out that you really have to have support for DCBX in order to make use
of ETS. What we are trying to do here is provide a lightweight way of
doing this configuration similar to how mqprio was already providing a
lightweight way of enabling multiple traffic classes.
> Please elaborate in few sentence if you are extending it/replacing it,
> why we want to do that and what are the implications on existing
> applications UAPI wise.
This is meant to be an extension of the existing structure. It can be
ignored by the driver and instead only have the basic hw offload
supported. In such a case the command will still return success but
any rate limits and queue configuration can be ignored. In the case of
the current implementation the queue configuration was already being
ignored so we opted to re-purpose the "hw" flag so that if you pass a
value greater than 1 and the driver doesn't recognize the value it has
the option to just ignore the extra bits it doesn't recognize and
return 1 as it did before for the hw flag in mqprio.
> Below you just say in the new mode Qos is configured with knobs XYZ --
> this is way not enough
Can you clarify what you are asking for here? Amritha included an
example in patch 1 of a command line that enabled 2 traffic classes
with rate limits. Is there something more specific you are looking
for?
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter/IPVS fixes for net
From: Pablo Neira Ayuso @ 2017-05-21 22:25 UTC (permalink / raw)
To: David Miller; +Cc: netfilter-devel, netdev
In-Reply-To: <20170521.130033.1427773613973278051.davem@davemloft.net>
On Sun, May 21, 2017 at 01:00:33PM -0400, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Fri, 19 May 2017 10:33:41 +0200
>
> > The following patchset contains Netfilter/IPVS fixes for your net tree,
> > they are:
> ...
> > You can pull these changes from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
>
> Pulled, thanks Pablo.
Thanks David!
Could you merge net into net-next as well? I have several patches for
net-next that need to apply on these fixes. No rush BTW.
^ permalink raw reply
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: Tom Herbert @ 2017-05-21 22:10 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov,
Linux Kernel Network Developers
In-Reply-To: <20170521180435.56dcd76b@redhat.com>
On Sun, May 21, 2017 at 9:04 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Sat, 20 May 2017 09:16:09 -0700
> Tom Herbert <tom@herbertland.com> wrote:
>
>> > +/* XDP rxhash have an associated type, which is related to the RSS
>> > + * (Receive Side Scaling) standard, but NIC HW have different mapping
>> > + * and support. Thus, create mapping that is interesting for XDP. XDP
>> > + * would primarly want insight into L3 and L4 protocol info.
>> > + *
>> > + * TODO: Likely need to get extended with "L3_IPV6_EX" due RSS standard
>> > + *
>> > + * The HASH_TYPE will be returned from bpf helper as the top 32-bit of
>> > + * the 64-bit rxhash (internally type stored in xdp_buff->flags).
>> > + */
>> > +#define XDP_HASH(x) ((x) & ((1ULL << 32)-1))
>> > +#define XDP_HASH_TYPE(x) ((x) >> 32)
>> > +
>> > +#define XDP_HASH_TYPE_L3_SHIFT 0
>> > +#define XDP_HASH_TYPE_L3_BITS 3
>> > +#define XDP_HASH_TYPE_L3_MASK ((1ULL << XDP_HASH_TYPE_L3_BITS)-1)
>> > +#define XDP_HASH_TYPE_L3(x) ((x) & XDP_HASH_TYPE_L3_MASK)
>> > +enum {
>> > + XDP_HASH_TYPE_L3_IPV4 = 1,
>> > + XDP_HASH_TYPE_L3_IPV6,
>> > +};
>> > +
>> > +#define XDP_HASH_TYPE_L4_SHIFT XDP_HASH_TYPE_L3_BITS
>> > +#define XDP_HASH_TYPE_L4_BITS 5
>> > +#define XDP_HASH_TYPE_L4_MASK \
>> > + (((1ULL << XDP_HASH_TYPE_L4_BITS)-1) << XDP_HASH_TYPE_L4_SHIFT)
>> > +#define XDP_HASH_TYPE_L4(x) ((x) & XDP_HASH_TYPE_L4_MASK)
>> > +enum {
>> > + _XDP_HASH_TYPE_L4_TCP = 1,
>> > + _XDP_HASH_TYPE_L4_UDP,
>> > +};
>> > +#define XDP_HASH_TYPE_L4_TCP (_XDP_HASH_TYPE_L4_TCP << XDP_HASH_TYPE_L4_SHIFT)
>> > +#define XDP_HASH_TYPE_L4_UDP (_XDP_HASH_TYPE_L4_UDP << XDP_HASH_TYPE_L4_SHIFT)
>> > +
>> Hi Jesper,
>>
>> Why do we need these indicators for protocol specific hash? It seems
>> like L4 and L3 is useful differentiation and protocol agnostic (I'm
>> still holding out hope that SCTP will be deployed some day ;-) )
>
> I'm not sure I understood the question fully, but let me try to answer
> anyway. To me it seems obvious that you would want to know the
> protocol/L4 type, as this helps avoid hash collisions between UDP and
> TCP flows. I can easily imagine someone constructing an UDP packet
> that could hash collide with a given TCP flow.
>
> And yes, i40 support matching SCTP, and we will create a
> XDP_HASH_TYPE_L4_SCTP when adding XDP rxhash support for that driver.
>
But where would this information be used? We don't save it in skbuff,
don't use it in RPS, RFS. RSS doesn't use it for packet steering so
the hash collision problem already exists at the device level. If
there is a collision problem between two protocols then maybe hash
should be over 5-tuple instead...
Tom
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Viable partnership request.
From: Mr Albert Yang @ 2017-05-18 22:12 UTC (permalink / raw)
To: netdev
Compliment of the day,
I have access to very vital information that can be used to move a huge amount of money.
I have done my homework very well and i have the machineries in place to get it done.
Ultimately I need an honest person to play an important role in the completion of this business transaction.
Regards,
Albert.
^ permalink raw reply
* Re: [PATCH net-next v5] net: ipv6: fix code style error and warning of ndisc.c
From: Joe Perches @ 2017-05-21 21:14 UTC (permalink / raw)
To: David Miller, dsahern; +Cc: cugyly, netdev, Linyu.Yuan
In-Reply-To: <20170521.125404.420857788471820007.davem@davemloft.net>
On Sun, 2017-05-21 at 12:54 -0400, David Miller wrote:
> From: David Ahern <dsahern@gmail.com> Date: Sun, 21 May 2017 10:17:47 -0600
> > On 5/21/17 10:05 AM, Joe Perches wrote:
> >> But really, why bother?
> >>
> >> Just because checkpatch bleats some message doesn't
> >> mean it _has_ to be fixed.
> >>
> >> Please strive to make the code more readable and
> >> intelligible for _humans_. Compilers don't care.
> >
> > +1
> >
> > broad cleanups like this make 'git blame' harder to use to find root causes.
I don't have any issue with broad cleanups and I think
the git blame argument is overblown.
If and when broad cleanups are done, it's best if there
is some other concurrent desire to improve logic, reduce
object code size, and/or other code refactoring other
than mere whitespace changes.
^ permalink raw reply
* [PATCH 5/5] atm: Use seq_putc() in lec_info()
From: SF Markus Elfring @ 2017-05-21 20:18 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:50:44 +0200
A single space character should be put into a sequence.
Thus use the corresponding function "seq_putc".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 752891434074..1d4edf093987 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -796,7 +796,7 @@ static void lec_info(struct seq_file *seq, struct lec_arp_table *entry)
for (i = 0; i < ETH_ALEN; i++)
seq_printf(seq, "%2.2x", entry->mac_addr[i] & 0xff);
- seq_printf(seq, " ");
+ seq_putc(seq, ' ');
for (i = 0; i < ATM_ESA_LEN; i++)
seq_printf(seq, "%2.2x", entry->atm_addr[i] & 0xff);
seq_printf(seq, " %s %4.4x", lec_arp_get_status_string(entry->status),
--
2.13.0
^ permalink raw reply related
* [PATCH 4/5] atm: Use seq_puts() in lec_info()
From: SF Markus Elfring @ 2017-05-21 20:17 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:49:10 +0200
A string which did not contain a data format specification should be put
into a sequence. Thus use the corresponding function "seq_puts".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index ca3aec0c0743..752891434074 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -804,7 +804,7 @@ static void lec_info(struct seq_file *seq, struct lec_arp_table *entry)
if (entry->vcc)
seq_printf(seq, "%3d %3d ", entry->vcc->vpi, entry->vcc->vci);
else
- seq_printf(seq, " ");
+ seq_puts(seq, " ");
if (entry->recv_vcc) {
seq_printf(seq, " %3d %3d", entry->recv_vcc->vpi,
entry->recv_vcc->vci);
--
2.13.0
^ permalink raw reply related
* [PATCH 3/5] atm: Adjust 19 checks for null pointers
From: SF Markus Elfring @ 2017-05-21 20:16 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:34:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The script “checkpatch.pl” pointed information out like the following.
Comparison to NULL could be written …
Thus fix the affected source code places.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index a11dbd3a5119..ca3aec0c0743 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -139,7 +139,7 @@ static void lec_handle_bridge(struct sk_buff *skb, struct net_device *dev)
struct atmlec_msg *mesg;
skb2 = alloc_skb(sizeof(struct atmlec_msg), GFP_ATOMIC);
- if (skb2 == NULL)
+ if (!skb2)
return;
skb2->len = sizeof(struct atmlec_msg);
mesg = (struct atmlec_msg *)skb2->data;
@@ -264,7 +264,7 @@ static netdev_tx_t lec_start_xmit(struct sk_buff *skb,
min_frame_size - skb->truesize,
GFP_ATOMIC);
dev_kfree_skb(skb);
- if (skb2 == NULL) {
+ if (!skb2) {
dev->stats.tx_dropped++;
return NETDEV_TX_OK;
}
@@ -431,7 +431,7 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
pr_debug("%s: bridge zeppelin asks about %pM\n",
dev->name, mesg->content.proxy.mac_addr);
- if (br_fdb_test_addr_hook == NULL)
+ if (!br_fdb_test_addr_hook)
break;
if (br_fdb_test_addr_hook(dev, mesg->content.proxy.mac_addr)) {
@@ -442,7 +442,7 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
pr_debug("%s: entry found, responding to zeppelin\n",
dev->name);
skb2 = alloc_skb(sizeof(struct atmlec_msg), GFP_ATOMIC);
- if (skb2 == NULL)
+ if (!skb2)
break;
skb2->len = sizeof(struct atmlec_msg);
skb_copy_to_linear_data(skb2, mesg, sizeof(*mesg));
@@ -520,7 +520,7 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type,
mesg = (struct atmlec_msg *)skb->data;
memset(mesg, 0, sizeof(*mesg));
mesg->type = type;
- if (data != NULL)
+ if (data)
mesg->sizeoftlvs = data->len;
if (mac_addr)
ether_addr_copy(mesg->content.normal.mac_addr, mac_addr);
@@ -534,7 +534,7 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type,
skb_queue_tail(&sk->sk_receive_queue, skb);
sk->sk_data_ready(sk);
- if (data != NULL) {
+ if (data) {
pr_debug("about to send %d bytes of data\n", data->len);
atm_force_charge(priv->lecd, data->truesize);
skb_queue_tail(&sk->sk_receive_queue, data);
@@ -663,7 +663,7 @@ static void lec_pop(struct atm_vcc *vcc, struct sk_buff *skb)
struct lec_vcc_priv *vpriv = LEC_VCC_PRIV(vcc);
struct net_device *dev = skb->dev;
- if (vpriv == NULL) {
+ if (!vpriv) {
pr_info("vpriv = NULL!?!?!?\n");
return;
}
@@ -1066,7 +1066,7 @@ static void __exit lane_module_cleanup(void)
deregister_atm_ioctl(&lane_ioctl_ops);
for (i = 0; i < MAX_LEC_ITF; i++) {
- if (dev_lec[i] != NULL) {
+ if (dev_lec[i]) {
unregister_netdev(dev_lec[i]);
free_netdev(dev_lec[i]);
dev_lec[i] = NULL;
@@ -1097,11 +1097,11 @@ static int lane2_resolve(struct net_device *dev, const u8 *dst_mac, int force,
spin_lock_irqsave(&priv->lec_arp_lock, flags);
table = lec_arp_find(priv, dst_mac);
spin_unlock_irqrestore(&priv->lec_arp_lock, flags);
- if (table == NULL)
+ if (!table)
return -1;
*tlvs = kmemdup(table->tlvs, table->sizeoftlvs, GFP_ATOMIC);
- if (*tlvs == NULL)
+ if (!*tlvs)
return -1;
*sizeoftlvs = table->sizeoftlvs;
@@ -1109,12 +1109,12 @@ static int lane2_resolve(struct net_device *dev, const u8 *dst_mac, int force,
return 0;
}
- if (sizeoftlvs == NULL)
+ if (!sizeoftlvs)
retval = send_to_lecd(priv, l_arp_xmt, dst_mac, NULL, NULL);
else {
skb = alloc_skb(*sizeoftlvs, GFP_ATOMIC);
- if (skb == NULL)
+ if (!skb)
return -1;
skb->len = *sizeoftlvs;
skb_copy_to_linear_data(skb, *tlvs, *sizeoftlvs);
@@ -1143,12 +1143,12 @@ static int lane2_associate_req(struct net_device *dev, const u8 *lan_dst,
kfree(priv->tlvs); /* NULL if there was no previous association */
priv->tlvs = kmemdup(tlvs, sizeoftlvs, GFP_KERNEL);
- if (priv->tlvs == NULL)
+ if (!priv->tlvs)
return 0;
priv->sizeoftlvs = sizeoftlvs;
skb = alloc_skb(sizeoftlvs, GFP_ATOMIC);
- if (skb == NULL)
+ if (!skb)
return 0;
skb->len = sizeoftlvs;
skb_copy_to_linear_data(skb, tlvs, sizeoftlvs);
@@ -1181,13 +1181,13 @@ static void lane2_associate_ind(struct net_device *dev, const u8 *mac_addr,
*/
struct lec_arp_table *entry = lec_arp_find(priv, mac_addr);
- if (entry == NULL)
+ if (!entry)
return; /* should not happen */
kfree(entry->tlvs);
entry->tlvs = kmemdup(tlvs, sizeoftlvs, GFP_KERNEL);
- if (entry->tlvs == NULL)
+ if (!entry->tlvs)
return;
entry->sizeoftlvs = sizeoftlvs;
#endif
@@ -1854,7 +1854,7 @@ lec_arp_update(struct lec_priv *priv, const unsigned char *mac_addr,
spin_lock_irqsave(&priv->lec_arp_lock, flags);
entry = lec_arp_find(priv, mac_addr);
- if (entry == NULL && targetless_le_arp)
+ if (!entry && targetless_le_arp)
goto out; /*
* LANE2: ignore targetless LE_ARPs for which
* we have no entry in the cache. 7.1.30
@@ -1965,7 +1965,7 @@ lec_vcc_added(struct lec_priv *priv, const struct atmlec_ioc *ioc_data,
entry->old_recv_push = old_push;
#endif
entry = make_entry(priv, bus_mac);
- if (entry == NULL)
+ if (!entry)
goto out;
del_timer(&entry->timer);
memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN);
@@ -1990,7 +1990,7 @@ lec_vcc_added(struct lec_priv *priv, const struct atmlec_ioc *ioc_data,
ioc_data->atm_addr[16], ioc_data->atm_addr[17],
ioc_data->atm_addr[18], ioc_data->atm_addr[19]);
entry = make_entry(priv, bus_mac);
- if (entry == NULL)
+ if (!entry)
goto out;
memcpy(entry->atm_addr, ioc_data->atm_addr, ATM_ESA_LEN);
eth_zero_addr(entry->mac_addr);
--
2.13.0
^ permalink raw reply related
* [PATCH 2/5] atm: Delete an error message for a failed memory allocation in make_entry()
From: SF Markus Elfring @ 2017-05-21 20:15 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:24:45 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 6ad3ca625a44..a11dbd3a5119 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -1556,7 +1556,6 @@ static struct lec_arp_table *make_entry(struct lec_priv *priv,
- if (!to_return) {
- pr_info("LEC: Arp entry kmalloc failed\n");
+ if (!to_return)
return NULL;
- }
+
ether_addr_copy(to_return->mac_addr, mac_addr);
INIT_HLIST_NODE(&to_return->next);
setup_timer(&to_return->timer, lec_arp_expire_arp,
--
2.13.0
^ permalink raw reply related
* [PATCH 1/5] atm: Improve a size determination in four functions
From: SF Markus Elfring @ 2017-05-21 20:14 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
In-Reply-To: <49543220-93e4-781c-877b-381277837152@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 21:20:44 +0200
Replace the specification of four data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/atm/lec.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/atm/lec.c b/net/atm/lec.c
index 09cfe87f0a44..6ad3ca625a44 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -518,5 +518,5 @@ send_to_lecd(struct lec_priv *priv, atmlec_msg_type type,
return -1;
skb->len = sizeof(struct atmlec_msg);
mesg = (struct atmlec_msg *)skb->data;
- memset(mesg, 0, sizeof(struct atmlec_msg));
+ memset(mesg, 0, sizeof(*mesg));
mesg->type = type;
@@ -690,5 +690,5 @@ static int lec_vcc_attach(struct atm_vcc *vcc, void __user *arg)
if (ioc_data.dev_num < 0 || ioc_data.dev_num >= MAX_LEC_ITF ||
!dev_lec[ioc_data.dev_num])
return -EINVAL;
- vpriv = kmalloc(sizeof(struct lec_vcc_priv), GFP_KERNEL);
+ vpriv = kmalloc(sizeof(*vpriv), GFP_KERNEL);
if (!vpriv)
@@ -1552,5 +1552,5 @@ static struct lec_arp_table *make_entry(struct lec_priv *priv,
{
struct lec_arp_table *to_return;
- to_return = kzalloc(sizeof(struct lec_arp_table), GFP_ATOMIC);
+ to_return = kzalloc(sizeof(*to_return), GFP_ATOMIC);
if (!to_return) {
@@ -2156,5 +2156,5 @@ static int lec_mcast_make(struct lec_priv *priv, struct atm_vcc *vcc)
struct lec_vcc_priv *vpriv;
int err = 0;
- vpriv = kmalloc(sizeof(struct lec_vcc_priv), GFP_KERNEL);
+ vpriv = kmalloc(sizeof(*vpriv), GFP_KERNEL);
if (!vpriv)
--
2.13.0
^ permalink raw reply related
* [PATCH 0/5] atm: Adjustments for some function implementations
From: SF Markus Elfring @ 2017-05-21 20:12 UTC (permalink / raw)
To: netdev, Augusto Mecking Caringi, David S. Miller, Jarod Wilson,
Javier Martinez Canillas, Kees Cook
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 21 May 2017 22:09:11 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (5):
Improve a size determination in four functions
Delete an error message for a failed memory allocation in make_entry()
Adjust 19 checks for null pointers
Use seq_puts() in lec_info()
Use seq_putc() in lec_info()
net/atm/lec.c | 55 +++++++++++++++++++++++++++----------------------------
1 file changed, 27 insertions(+), 28 deletions(-)
--
2.13.0
^ permalink raw reply
* Re: [patch net-next 2/2] net/sched: fix filter flushing
From: Jiri Pirko @ 2017-05-21 19:19 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Eric Dumazet, Daniel Borkmann, Simon Horman, mlxsw, Colin King
In-Reply-To: <CAM_iQpVPuC-FQ3R4QNDCBWxrX5s7Q4bENxMU7+1LooCdHdMZhw@mail.gmail.com>
Sun, May 21, 2017 at 08:27:21PM CEST, xiyou.wangcong@gmail.com wrote:
>On Sat, May 20, 2017 at 10:54 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Sun, May 21, 2017 at 02:16:45AM CEST, xiyou.wangcong@gmail.com wrote:
>>>On Sat, May 20, 2017 at 6:01 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> +static void tcf_chain_destroy(struct tcf_chain *chain)
>>>> +{
>>>> + list_del(&chain->list);
>>>> + tcf_chain_flush(chain);
>>>> kfree(chain);
>>>> }
>>>>
>>>> @@ -510,7 +517,7 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
>>>>
>>>> if (n->nlmsg_type == RTM_DELTFILTER && prio == 0) {
>>>> tfilter_notify_chain(net, skb, n, chain, RTM_DELTFILTER);
>>>> - tcf_chain_destroy(chain);
>>>> + tcf_chain_flush(chain);
>>>
>>>
>>>I wonder if we should return EBUSY and do nothing in case of busy?
>>>The chain is no longer visual to new actions after your list_del(), but
>>>the old one could still use and see it.
>>
>> No. User request to flush the chain, that is what happens in the past
>> and that is what should happen now.
>> If there is still a reference, the chain_put will keep the empty chain.
>
>But if you dump the actions, this chain is still shown "goto chain"?
Yes, it will be shown there.
>You can't claim you really delete it as long as actions can still
>see it and dump it.
No, user just wants to delete all the filters. That is done. User does
not care if the actual chain structure is there or not.
^ permalink raw reply
* [PATCH net-next] net: socket: fix a typo in sockfd_lookup().
From: Rami Rosen @ 2017-05-21 19:12 UTC (permalink / raw)
To: davem; +Cc: netdev, Rami Rosen
This patch fixes a typo in sockfd_lookup() in net/socket.c.
Signed-off-by: Rami Rosen <rami.rosen@intel.com>
---
net/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/socket.c b/net/socket.c
index cb355a7..8f9dab3 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -461,7 +461,7 @@ EXPORT_SYMBOL(sock_from_file);
* @err: pointer to an error code return
*
* The file handle passed in is locked and the socket it is bound
- * too is returned. If an error occurs the err pointer is overwritten
+ * to is returned. If an error occurs the err pointer is overwritten
* with a negative errno code and NULL is returned. The function checks
* for both invalid handles and passing a handle which is not a socket.
*
--
2.7.4
^ permalink raw reply related
* Re: [patch net-next 2/2] net/sched: fix filter flushing
From: Cong Wang @ 2017-05-21 18:27 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Eric Dumazet, Daniel Borkmann, Simon Horman, mlxsw, Colin King
In-Reply-To: <20170521055416.GA1848@nanopsycho>
On Sat, May 20, 2017 at 10:54 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Sun, May 21, 2017 at 02:16:45AM CEST, xiyou.wangcong@gmail.com wrote:
>>On Sat, May 20, 2017 at 6:01 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> +static void tcf_chain_destroy(struct tcf_chain *chain)
>>> +{
>>> + list_del(&chain->list);
>>> + tcf_chain_flush(chain);
>>> kfree(chain);
>>> }
>>>
>>> @@ -510,7 +517,7 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n,
>>>
>>> if (n->nlmsg_type == RTM_DELTFILTER && prio == 0) {
>>> tfilter_notify_chain(net, skb, n, chain, RTM_DELTFILTER);
>>> - tcf_chain_destroy(chain);
>>> + tcf_chain_flush(chain);
>>
>>
>>I wonder if we should return EBUSY and do nothing in case of busy?
>>The chain is no longer visual to new actions after your list_del(), but
>>the old one could still use and see it.
>
> No. User request to flush the chain, that is what happens in the past
> and that is what should happen now.
> If there is still a reference, the chain_put will keep the empty chain.
But if you dump the actions, this chain is still shown "goto chain"?
You can't claim you really delete it as long as actions can still
see it and dump it.
^ permalink raw reply
* Re: [PATCH net-next] tcp: fix tcp_probe_timer() for TCP_USER_TIMEOUT
From: Eric Dumazet @ 2017-05-21 18:01 UTC (permalink / raw)
To: Soheil Hassas Yeganeh; +Cc: David Miller, netdev
In-Reply-To: <CACSApvaY+fBwG5dGM-hiYF-51vLzn2D8V-PM5JP_=Pa8hru3xw@mail.gmail.com>
On Sun, 2017-05-21 at 13:46 -0400, Soheil Hassas Yeganeh wrote:
> On Sun, May 21, 2017 at 1:39 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > TCP_USER_TIMEOUT is still converted to jiffies value in
> > icsk_user_timeout
> >
> > So we need to make a conversion for the cases HZ != 1000
> >
> > Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
>
> Thank you for the fix, Eric!
Thanks for reviewing !
^ permalink raw reply
* Re: [PATCH net-next] tcp: fix tcp_probe_timer() for TCP_USER_TIMEOUT
From: Eric Dumazet @ 2017-05-21 18:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, soheil
In-Reply-To: <20170521.135111.1511992009561369461.davem@davemloft.net>
On Sun, 2017-05-21 at 13:51 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sun, 21 May 2017 10:39:00 -0700
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > TCP_USER_TIMEOUT is still converted to jiffies value in
> > icsk_user_timeout
> >
> > So we need to make a conversion for the cases HZ != 1000
> >
> > Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> Applied, thank Eric.
>
> I kinda expected a few pieces of fallout from the 1ms changes :)
Absolutely ;)
One last piece is in TCP_SYNCNT support.
I saw that retransmits_timed_out() could have a rounding error :
tcp_time_stamp(tcp_sk(sk)) - start_ts) ends up to 999 ms,
while the timeout is/was 1000 ms (And timer _was_ progammed with 1000
jiffies for HZ=1000 kernel)
So if user setup TCP_SYNCNT = 1 socket option, we sometime sends one
extra SYN packet.
I will send a fix later.
^ permalink raw reply
* Re: [PATCH net-next] tcp: fix tcp_probe_timer() for TCP_USER_TIMEOUT
From: David Miller @ 2017-05-21 17:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, soheil
In-Reply-To: <1495388340.6465.50.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 21 May 2017 10:39:00 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP_USER_TIMEOUT is still converted to jiffies value in
> icsk_user_timeout
>
> So we need to make a conversion for the cases HZ != 1000
>
> Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thank Eric.
I kinda expected a few pieces of fallout from the 1ms changes :)
^ permalink raw reply
* Re: [PATCH net-next] tcp: fix tcp_probe_timer() for TCP_USER_TIMEOUT
From: Soheil Hassas Yeganeh @ 2017-05-21 17:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1495388340.6465.50.camel@edumazet-glaptop3.roam.corp.google.com>
On Sun, May 21, 2017 at 1:39 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> TCP_USER_TIMEOUT is still converted to jiffies value in
> icsk_user_timeout
>
> So we need to make a conversion for the cases HZ != 1000
>
> Fixes: 9a568de4818d ("tcp: switch TCP TS option (RFC 7323) to 1ms clock")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Thank you for the fix, Eric!
^ permalink raw reply
* Re: [PATCH net-next 9/9] ipv6: remove unused variables in esp6
From: David Miller @ 2017-05-21 17:44 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin, steffen.klassert
In-Reply-To: <20170519165556.483-10-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 19 May 2017 09:55:56 -0700
> Resolves warnings:
> net/ipv6/esp6.c: In function ‘esp_ssg_unref’:
> net/ipv6/esp6.c:121:10: warning: variable ‘seqhi’ set but not used [-Wunused-but-set-variable]
> net/ipv6/esp6.c: In function ‘esp6_output_head’:
> net/ipv6/esp6.c:227:21: warning: variable ‘esph’ set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Stephen please always CC: the IPSEC maintainer for IPSEC implementation
fixes.
Steffen, please consider taking this into your tree.
> ---
> net/ipv6/esp6.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
> index 1fe99ba8066c..53b6b870b935 100644
> --- a/net/ipv6/esp6.c
> +++ b/net/ipv6/esp6.c
> @@ -118,7 +118,6 @@ static inline struct scatterlist *esp_req_sg(struct crypto_aead *aead,
>
> static void esp_ssg_unref(struct xfrm_state *x, void *tmp)
> {
> - __be32 *seqhi;
> struct crypto_aead *aead = x->data;
> int seqhilen = 0;
> u8 *iv;
> @@ -128,7 +127,6 @@ static void esp_ssg_unref(struct xfrm_state *x, void *tmp)
> if (x->props.flags & XFRM_STATE_ESN)
> seqhilen += sizeof(__be32);
>
> - seqhi = esp_tmp_seqhi(tmp);
> iv = esp_tmp_iv(aead, tmp, seqhilen);
> req = esp_tmp_req(aead, iv);
>
> @@ -224,12 +222,9 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info
> u8 *vaddr;
> int nfrags;
> struct page *page;
> - struct ip_esp_hdr *esph;
> struct sk_buff *trailer;
> int tailen = esp->tailen;
>
> - esph = ip_esp_hdr(skb);
> -
> if (!skb_cloned(skb)) {
> if (tailen <= skb_availroom(skb)) {
> nfrags = 1;
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH net-next 8/9] ipv6: drop unused variables in seg6_genl_dumphac
From: David Miller @ 2017-05-21 17:43 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20170519165556.483-9-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 19 May 2017 09:55:55 -0700
> THe seg6_pernet_data variable was set but never used.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox