* New Coverity defect in BPF verifier
From: Stephen Hemminger @ 2017-05-22 16:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Date: Mon, 22 May 2017 04:40:24 -0700
From: scan-admin@coverity.com
To: stephen@networkplumber.org
Subject: New Defects reported by Coverity Scan for Linux
Hi,
Please find the latest report on new defect(s) introduced to Linux found with Coverity Scan.
1 new defect(s) introduced to Linux found with Coverity Scan.
17 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1409762: Control flow issues (DEADCODE)
/kernel/bpf/verifier.c: 815 in check_pkt_ptr_alignment()
________________________________________________________________________________________________________
*** CID 1409762: Control flow issues (DEADCODE)
/kernel/bpf/verifier.c: 815 in check_pkt_ptr_alignment()
809 }
810
811 /* skb->data is NET_IP_ALIGN-ed, but for strict alignment checking
812 * we force this to 2 which is universally what architectures use
813 * when they don't set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
814 */
>>> CID 1409762: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "0" inside this statement: "ip_align = (strict ? 2 : 0);".
815 ip_align = strict ? 2 : NET_IP_ALIGN;
816 if ((ip_align + reg_off + off) % size != 0) {
817 verbose("misaligned packet access off %d+%d+%d size %d\n",
818 ip_align, reg_off, off, size);
819 return -EACCES;
820 }
^ permalink raw reply
* Re: [PATCH] net: atheros: atl2: don't return zero on failure path in atl2_probe()
From: David Miller @ 2017-05-22 16:05 UTC (permalink / raw)
To: khoroshilov; +Cc: jcliburn, chris.snook, netdev, linux-kernel, ldv-project
In-Reply-To: <1495234331-27615-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Sat, 20 May 2017 01:52:11 +0300
> If dma mask checks fail in atl2_probe(), it breaks off initialization,
> deallocates all resources, but returns zero.
>
> The patch adds proper error code return value and
> make error code setup unified.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] bonding: fix accounting of active ports in 3ad
From: David Miller @ 2017-05-22 16:06 UTC (permalink / raw)
To: jarod; +Cc: linux-kernel, j.vosburgh, vfalico, andy, netdev
In-Reply-To: <20170519234345.44721-1-jarod@redhat.com>
From: Jarod Wilson <jarod@redhat.com>
Date: Fri, 19 May 2017 19:43:45 -0400
> As of 7bb11dc9f59d and 0622cab0341c, bond slaves in a 3ad bond are not
> removed from the aggregator when they are down, and the active slave count
> is NOT equal to number of ports in the aggregator, but rather the number
> of ports in the aggregator that are still enabled. The sysfs spew for
> bonding_show_ad_num_ports() has a comment that says "Show number of active
> 802.3ad ports.", but it's currently showing total number of ports, both
> active and inactive. Remedy it by using the same logic introduced in
> 0622cab0341c in __bond_3ad_get_active_agg_info(), so sysfs, procfs and
> netlink all report the number of active ports. Note that this means that
> IFLA_BOND_AD_INFO_NUM_PORTS really means NUM_ACTIVE_PORTS instead of
> NUM_PORTS, and thus perhaps should be renamed for clarity.
>
> Lightly tested on a dual i40e lacp bond, simulating link downs with an ip
> link set dev <slave2> down, was able to produce the state where I could
> see both in the same aggregator, but a number of ports count of 1.
...
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
> ---
> v2: fix incorrect git sha reference, add more testing data
Applied and queued up for -stable, thanks Jarod!
^ permalink raw reply
* Re: [PATCH net] sctp: fix ICMP processing if skb is non-linear
From: Davide Caratti @ 2017-05-22 16:09 UTC (permalink / raw)
To: Xin Long, Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, David S. Miller
In-Reply-To: <CADvbK_c81ju-D6h4TLm5_Lxvkaiw69Lt9TXR3Z_8gOJpQdXpXQ@mail.gmail.com>
hello Xin Long,
On Sat, 2017-05-20 at 02:40 +0800, Xin Long wrote:
> On Fri, May 19, 2017 at 11:34 PM, Davide Caratti <dcaratti@redhat.com> wrote:
> > @@ -515,14 +515,23 @@ struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
> > * or the chunk type or the Initiate Tag does not match, silently
> > * discard the packet.
> > */
> > + offset = skb_transport_offset(skb);
> > + sctphdr = skb_header_pointer(skb, offset, sizeof(_sctphdr), &_sctphdr);
> > + if (unlikely(!sctphdr))
> > + goto out;
> > +
> > + vtag = ntohl(sctphdr->vtag);
> > if (vtag == 0) {
> > - chunkhdr = (void *)sctphdr + sizeof(struct sctphdr);
> > - if (len < sizeof(struct sctphdr) + sizeof(sctp_chunkhdr_t)
> > - + sizeof(__be32) ||
> > + offset += sizeof(_sctphdr);
>
> will be nice to delete this line, and use
> > + /* chunk header + first 4 octects of init header */
> > + chunkhdr = skb_header_pointer(skb, offset,
>
> chunkhdr = skb_header_pointer(skb, offset + sizeof(_sctphdr), ;)
> wdyt?
that's right, 'offset' does not need the re-assignment: I will post the v2
soon. Thanks!
^ permalink raw reply
* [PATCH] cfg80211: Be able to set bss expire time at config stage.
From: Enric Balletbo i Serra @ 2017-05-22 16:09 UTC (permalink / raw)
To: Johannes Berg, David S . Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Shmidt,
helmut.schaa-gM/Ye1E23mwN+BqQ9rBEUg
The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in the
past. Initially was set at 10 seconds (2a51931192), then increased at 15
seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover the
use case when a station is having heavy uplink traffic. On some devices,
like Chromebooks, this value is decreased to 7 seconds to avoid stall
results, and other devices prefer set to 15 seconds.
This simple patch tries to make the selection of this value a bit more
flexible by being able to set the expire time at config stage. Most users
can leave the default value set as 30 seconds, others can modify the value
at config stage if they want lower or bigger values.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
---
net/wireless/Kconfig | 11 +++++++++++
net/wireless/core.c | 2 ++
net/wireless/core.h | 1 +
net/wireless/scan.c | 6 ++----
4 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 6c60612..2a54e28 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -29,6 +29,17 @@ config CFG80211
When built as a module it will be called cfg80211.
+config CFG80211_SCAN_RESULT_EXPIRE
+ int "Scan completion time" if CFG80211
+ default 30
+ ---help---
+ This value is the time in seconds the mac80211 scan method needs
+ to finish. An expiration time to 30 seconds should be sufficient
+ for most cases but for some other cases we might be interested in
+ tweak this value.
+
+ If unsure, leave the default of 30.
+
config NL80211_TESTMODE
bool "nl80211 testmode command"
depends on CFG80211
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 83ea164..2a5742c 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -499,6 +499,8 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
init_waitqueue_head(&rdev->dev_wait);
+ rdev->scan_result_expire = CONFIG_CFG80211_SCAN_RESULT_EXPIRE;
+
/*
* Initialize wiphy parameters to IEEE 802.11 MIB default values.
* Fragmentation and RTS threshold are disabled by default with the
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 6e809325..6a8a164 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -72,6 +72,7 @@ struct cfg80211_registered_device {
struct rb_root bss_tree;
u32 bss_generation;
u32 bss_entries;
+ unsigned int scan_result_expire;
struct cfg80211_scan_request *scan_req; /* protected by RTNL */
struct sk_buff *scan_msg;
struct list_head sched_scan_req_list;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 14d5f0c..f0b55a9 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -70,8 +70,6 @@ module_param(bss_entries_limit, int, 0644);
MODULE_PARM_DESC(bss_entries_limit,
"limit to number of scan BSS entries (per wiphy, default 1000)");
-#define IEEE80211_SCAN_RESULT_EXPIRE (30 * HZ)
^ permalink raw reply related
* Re: [PATCHv4] wlcore: add wl1285 compatible
From: Rob Herring @ 2017-05-22 16:11 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Kalle Valo, David Miller, Tony Lindgren, Marcel Holtmann,
linux-wireless, linux-omap, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <20170522152112.634mnsv65lryrmkp@earth>
On Mon, May 22, 2017 at 10:21 AM, Sebastian Reichel
<sebastian.reichel@collabora.co.uk> wrote:
> Hi,
>
> On Mon, May 22, 2017 at 05:44:24PM +0300, Kalle Valo wrote:
>> David Miller <davem@davemloft.net> writes:
>> > From: Kalle Valo <kvalo@codeaurora.org>
>> > Date: Mon, 22 May 2017 12:28:20 +0300
>> >
>> >> Sebastian Reichel <sebastian.reichel@collabora.co.uk> writes:
>> >>
>> >>> Motorola Droid 4 uses a WL1285C. With differences between the
>> >>> chips not being public let's add explicit binding for wl1285
>> >>> instead of relying on wl1283 being very similar.
>> >>>
>> >>> Reviewed-by: Rob Herring <robh@kernel.org>
>> >>> Acked-by: Kalle Valo <kvalo@codeaurora.org>
>> >>> Acked-by: Tony Lindgren <tony@atomide.com>
>> >>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
>> >>> ---
>> >>> Hi Dave,
>> >>>
>> >>> I previously send this in two patches, but its hard to apply without
>> >>> requiring multiple kernel releases (the driver must be updated before
>> >>> the DTS change). Since the actual change is not very complex Marcel
>> >>> Holtmann & Tony Lindgren suggested, that I send this directly to you
>> >>> in a single patch for inclusion into 4.12. This also means, that the
>> >>> remaining series can be queued normally for 4.13.
>> >>
>> >> I noticed that Dave set this patch to Awaiting Upstream state on his
>> >> patchwork:
>> >>
>> >> https://patchwork.ozlabs.org/patch/759042/
>> >>
>> >> Which makes me suspect that he is waiting me to apply this (as I
>> >> normally apply wlcore patches). Dave, should I actually take this patch?
>> >> What do you prefer?
>> >
>> > Anything that touches wireless drivers I defer to you, yes.
>>
>> Thanks, I'll take it then. Not sure why Sebastian was suggested to
>> submit this patch via your tree in the first place.
>>
>> https://patchwork.kernel.org/patch/9713645/
>
> Thanks. The idea was to get into early 4.12-rc to avoid merge
> conflicts in the droid 4 *.dts during 4.13 cycle. This strategy
> obviously failed :)
First, I'm not sure why you combined everything. A maintainer can just
as easily take a series as a single patch and we prefer binding doc,
dts and driver changes all separate.
Second, the dts changes could go thru arm-soc and the driver change
thru netdev. The binding doc can be thru either. There's no bisecting
dependency and things shouldn't break. It just won't all work until
you have both branches.
Rob
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: Add extack for route add/delete failures
From: David Miller @ 2017-05-22 16:12 UTC (permalink / raw)
To: dsahern; +Cc: netdev
In-Reply-To: <20170521161205.36720-1-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Sun, 21 May 2017 10:12:01 -0600
> Use the extack feature to improve error messages to user on route
> add and delete failures.
Looks good, series applied.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: socket: fix a typo in sockfd_lookup().
From: David Miller @ 2017-05-22 16:14 UTC (permalink / raw)
To: rami.rosen; +Cc: netdev
In-Reply-To: <1495393958-9304-1-git-send-email-rami.rosen@intel.com>
From: Rami Rosen <rami.rosen@intel.com>
Date: Sun, 21 May 2017 22:12:38 +0300
> This patch fixes a typo in sockfd_lookup() in net/socket.c.
>
> Signed-off-by: Rami Rosen <rami.rosen@intel.com>
Applied, thank you.
^ permalink raw reply
* Re: New Coverity defect in BPF verifier
From: David Miller @ 2017-05-22 16:16 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20170522090512.38dbcefa@xeon-e3>
Stephen, if you had even lightly scanned netdev today, you can see
that we are discussing this already and there are at least two
patches proposed.
Thank you.
^ permalink raw reply
* Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.
From: Johannes Berg @ 2017-05-22 16:19 UTC (permalink / raw)
To: Enric Balletbo i Serra, David S . Miller, linux-wireless
Cc: netdev, linux-kernel, Dmitry Shmidt, helmut.schaa
In-Reply-To: <20170522160946.2057-1-enric.balletbo@collabora.com>
On Mon, 2017-05-22 at 18:09 +0200, Enric Balletbo i Serra wrote:
> The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in
> the
> past. Initially was set at 10 seconds (2a51931192), then increased at
> 15
> seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover
> the
> use case when a station is having heavy uplink traffic. On some
> devices,
> like Chromebooks, this value is decreased to 7 seconds to avoid stall
> results, and other devices prefer set to 15 seconds.
>
> This simple patch tries to make the selection of this value a bit
> more
> flexible by being able to set the expire time at config stage. Most
> users
> can leave the default value set as 30 seconds, others can modify the
> value
> at config stage if they want lower or bigger values.
I'm not really all that convinced that we really need this - userspace
should just be using the flush thing more often, and then it doesn't
really matter.
However, maybe that doesn't really matter all that much.
But,
> +config CFG80211_SCAN_RESULT_EXPIRE
> + int "Scan completion time" if CFG80211
That should have "if CFG80211 && EXPERT" or something like that - no
need to prompt everyone for it.
> + rdev->scan_result_expire =
> CONFIG_CFG80211_SCAN_RESULT_EXPIRE;
This is completely pointless - no need to go through runtime like that.
> -#define IEEE80211_SCAN_RESULT_EXPIRE (30 * HZ)
You can just use CONFIG_CFG80211_SCAN_RESULT_EXPIRE * HZ here.
> + __cfg80211_bss_expire(rdev, jiffies - rdev-
> >scan_result_expire);
You also completely messed this up because it now depends on HZ.
johannes
^ permalink raw reply
* Re: [PATCHv4] wlcore: add wl1285 compatible
From: Sebastian Reichel @ 2017-05-22 16:21 UTC (permalink / raw)
To: Rob Herring
Cc: Kalle Valo, David Miller, Tony Lindgren, Marcel Holtmann,
linux-wireless, linux-omap,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev
In-Reply-To: <CAL_JsqL91sruKNaWmVEqT+L_OCh5xFkkGY07mBBUmqkKHc5fQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]
Hi,
On Mon, May 22, 2017 at 11:11:49AM -0500, Rob Herring wrote:
> On Mon, May 22, 2017 at 10:21 AM, Sebastian Reichel
> <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> > Hi,
> >
> > On Mon, May 22, 2017 at 05:44:24PM +0300, Kalle Valo wrote:
> >> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> >> > From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> > Date: Mon, 22 May 2017 12:28:20 +0300
> >> >
> >> >> Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> writes:
> >> >>
> >> >>> Motorola Droid 4 uses a WL1285C. With differences between the
> >> >>> chips not being public let's add explicit binding for wl1285
> >> >>> instead of relying on wl1283 being very similar.
> >> >>>
> >> >>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> >>> Acked-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> >>> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> >> >>> Signed-off-by: Sebastian Reichel <sebastian.reichel-ZGY8ohtN/8oXa1LcwEujcA@public.gmane.orgk>
> >> >>> ---
> >> >>> Hi Dave,
> >> >>>
> >> >>> I previously send this in two patches, but its hard to apply without
> >> >>> requiring multiple kernel releases (the driver must be updated before
> >> >>> the DTS change). Since the actual change is not very complex Marcel
> >> >>> Holtmann & Tony Lindgren suggested, that I send this directly to you
> >> >>> in a single patch for inclusion into 4.12. This also means, that the
> >> >>> remaining series can be queued normally for 4.13.
> >> >>
> >> >> I noticed that Dave set this patch to Awaiting Upstream state on his
> >> >> patchwork:
> >> >>
> >> >> https://patchwork.ozlabs.org/patch/759042/
> >> >>
> >> >> Which makes me suspect that he is waiting me to apply this (as I
> >> >> normally apply wlcore patches). Dave, should I actually take this patch?
> >> >> What do you prefer?
> >> >
> >> > Anything that touches wireless drivers I defer to you, yes.
> >>
> >> Thanks, I'll take it then. Not sure why Sebastian was suggested to
> >> submit this patch via your tree in the first place.
> >>
> >> https://patchwork.kernel.org/patch/9713645/
> >
> > Thanks. The idea was to get into early 4.12-rc to avoid merge
> > conflicts in the droid 4 *.dts during 4.13 cycle. This strategy
> > obviously failed :)
>
> First, I'm not sure why you combined everything. A maintainer can just
> as easily take a series as a single patch and we prefer binding doc,
> dts and driver changes all separate.
>
> Second, the dts changes could go thru arm-soc and the driver change
> thru netdev. The binding doc can be thru either. There's no bisecting
> dependency and things shouldn't break. It just won't all work until
> you have both branches.
This is only true for new devices. WLAN for droid4 works at the
moment using incorrect compatible string. If *.dts is updated and
driver is not yet updated WLAN does not work. IMHO that is a
bisecting dependency.
It would have been fine to sneak the driver change into 4.12 and
queue the *.dts change in 4.13, though. IIRC Tony suggest to make
it one patch.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.
From: Dan Williams @ 2017-05-22 16:21 UTC (permalink / raw)
To: Enric Balletbo i Serra, Johannes Berg, David S . Miller,
linux-wireless
Cc: netdev, linux-kernel, Dmitry Shmidt, helmut.schaa
In-Reply-To: <20170522160946.2057-1-enric.balletbo@collabora.com>
On Mon, 2017-05-22 at 18:09 +0200, Enric Balletbo i Serra wrote:
> The IEEE80211_SCAN_RESULT_EXPIRE value was modified several times in
> the
> past. Initially was set at 10 seconds (2a51931192), then increased at
> 15
> seconds (09f97e0fc4) and finally to 30 seconds (f9616e0f88) to cover
> the
> use case when a station is having heavy uplink traffic. On some
> devices,
> like Chromebooks, this value is decreased to 7 seconds to avoid stall
> results, and other devices prefer set to 15 seconds.
Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
create its own list? Given that the kernel provides the information
userspace needs to figure out the age of a particular BSS, it doesn't
seem like there needs to be a kernel tunable for this. Userspace can
already avoid stale results.
Also, different runtime situations might want different result ages,
which wouldn't be possible if the kernel had a hardcoded maximum.
Furthermore, different userspace apps might be reading the same scan
list, and they might have different ideas about staleness.
Or perhaps I misunderstand the problem, which could well be the case.
Dan
> This simple patch tries to make the selection of this value a bit
> more
> flexible by being able to set the expire time at config stage. Most
> users
> can leave the default value set as 30 seconds, others can modify the
> value
> at config stage if they want lower or bigger values.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> net/wireless/Kconfig | 11 +++++++++++
> net/wireless/core.c | 2 ++
> net/wireless/core.h | 1 +
> net/wireless/scan.c | 6 ++----
> 4 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 6c60612..2a54e28 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -29,6 +29,17 @@ config CFG80211
>
> When built as a module it will be called cfg80211.
>
> +config CFG80211_SCAN_RESULT_EXPIRE
> + int "Scan completion time" if CFG80211
> + default 30
> + ---help---
> + This value is the time in seconds the mac80211 scan method
> needs
> + to finish. An expiration time to 30 seconds should be
> sufficient
> + for most cases but for some other cases we might be
> interested in
> + tweak this value.
> +
> + If unsure, leave the default of 30.
> +
> config NL80211_TESTMODE
> bool "nl80211 testmode command"
> depends on CFG80211
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index 83ea164..2a5742c 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -499,6 +499,8 @@ struct wiphy *wiphy_new_nm(const struct
> cfg80211_ops *ops, int sizeof_priv,
>
> init_waitqueue_head(&rdev->dev_wait);
>
> + rdev->scan_result_expire =
> CONFIG_CFG80211_SCAN_RESULT_EXPIRE;
> +
> /*
> * Initialize wiphy parameters to IEEE 802.11 MIB default
> values.
> * Fragmentation and RTS threshold are disabled by default
> with the
> diff --git a/net/wireless/core.h b/net/wireless/core.h
> index 6e809325..6a8a164 100644
> --- a/net/wireless/core.h
> +++ b/net/wireless/core.h
> @@ -72,6 +72,7 @@ struct cfg80211_registered_device {
> struct rb_root bss_tree;
> u32 bss_generation;
> u32 bss_entries;
> + unsigned int scan_result_expire;
> struct cfg80211_scan_request *scan_req; /* protected by RTNL
> */
> struct sk_buff *scan_msg;
> struct list_head sched_scan_req_list;
> diff --git a/net/wireless/scan.c b/net/wireless/scan.c
> index 14d5f0c..f0b55a9 100644
> --- a/net/wireless/scan.c
> +++ b/net/wireless/scan.c
> @@ -70,8 +70,6 @@ module_param(bss_entries_limit, int, 0644);
> MODULE_PARM_DESC(bss_entries_limit,
> "limit to number of scan BSS entries (per wiphy,
> default 1000)");
>
> -#define IEEE80211_SCAN_RESULT_EXPIRE (30 * HZ)
> -
> static void bss_free(struct cfg80211_internal_bss *bss)
> {
> struct cfg80211_bss_ies *ies;
> @@ -476,7 +474,7 @@ void cfg80211_bss_age(struct
> cfg80211_registered_device *rdev,
>
> void cfg80211_bss_expire(struct cfg80211_registered_device *rdev)
> {
> - __cfg80211_bss_expire(rdev, jiffies -
> IEEE80211_SCAN_RESULT_EXPIRE);
> + __cfg80211_bss_expire(rdev, jiffies - rdev-
> >scan_result_expire);
> }
>
> const u8 *cfg80211_find_ie_match(u8 eid, const u8 *ies, int len,
> @@ -737,7 +735,7 @@ struct cfg80211_bss *cfg80211_get_bss(struct
> wiphy *wiphy,
> if (!is_valid_ether_addr(bss->pub.bssid))
> continue;
> /* Don't get expired BSS structs */
> - if (time_after(now, bss->ts +
> IEEE80211_SCAN_RESULT_EXPIRE) &&
> + if (time_after(now, bss->ts + rdev-
> >scan_result_expire) &&
> !atomic_read(&bss->hold))
> continue;
> if (is_bss(&bss->pub, bssid, ssid, ssid_len)) {
^ permalink raw reply
* Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.
From: Johannes Berg @ 2017-05-22 16:24 UTC (permalink / raw)
To: Dan Williams, Enric Balletbo i Serra, David S . Miller,
linux-wireless
Cc: netdev, linux-kernel, Dmitry Shmidt, helmut.schaa
In-Reply-To: <1495470111.25557.9.camel@redhat.com>
> Couldn't userspace just look at NL80211_BSS_SEEN_MS_AGO to filter and
> create its own list? Given that the kernel provides the information
> userspace needs to figure out the age of a particular BSS, it doesn't
> seem like there needs to be a kernel tunable for this. Userspace can
> already avoid stale results.
Yeah, I agree. It can also ask for a flush, so that old results are
gone by the time the next scan returns. We don't have a flush operation
without requesting a new scan, but I guess that could be added.
> Also, different runtime situations might want different result ages,
> which wouldn't be possible if the kernel had a hardcoded maximum.
> Furthermore, different userspace apps might be reading the same scan
> list, and they might have different ideas about staleness.
>
> Or perhaps I misunderstand the problem, which could well be the case.
No, I think this is perfectly right - userspace should be able to deal
with this given the tools we gave it, or if not, we should probably
just give it more tools instead of hardcoding the kernel configuration.
This value really just kinda needed to be an upper bound so that we
don't start expiring entries while we're still scanning.
johannes
^ permalink raw reply
* Re: [PATCH] kernel: bpf: remove dead code
From: David Miller @ 2017-05-22 16:27 UTC (permalink / raw)
To: daniel; +Cc: garsilva, ast, netdev, linux-kernel
In-Reply-To: <5922FB28.5070303@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Mon, 22 May 2017 16:52:24 +0200
> On 05/22/2017 04:38 PM, David Miller wrote:
>> From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
>> Date: Mon, 22 May 2017 09:07:46 -0500
>>
>>> Execution cannot reach NET_IP_ALIGN inside the following statement:
>>> ip_align = strict ? 2 : NET_IP_ALIGN
>>>
>>> Addresses-Coverity-ID: 1409762
>>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>>> ---
>>> NOTE: variable ip_align could also be removed and use value 2
>>> directly.
>>
>> Incorrect.
>>
>> Some platforms define NET_IP_ALIGN to zero, so the code must remain
>> as is.
>
> In the check_pkt_ptr_alignment(), when !strict you would already
> return earlier from that function.
>
> So, above test in ip_align will always give 2, meaning technically
> the patch is correct, although hard-coded value less clean.
>
> Perhaps something like the below to keep intentions more clear (and
> it will get resolved during compile time anyway ...):
Ok I understand the issue now. Thanks for explaining.
I guess a hard-coded value of 2 and an adjusted comment above the
assignment of ip_align is the way to go.
I'll push the following, thanks everyone:
====================
net: Make IP alignment calulations clearer.
The assignmnet:
ip_align = strict ? 2 : NET_IP_ALIGN;
in compare_pkt_ptr_alignment() trips up Coverity because we can only
get to this code when strict is true, therefore ip_align will always
be 2 regardless of NET_IP_ALIGN's value.
So just assign directly to '2' and explain the situation in the
comment above.
Reported-by: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
kernel/bpf/verifier.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 1eddb71..c72cd41 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -808,11 +808,15 @@ static int check_pkt_ptr_alignment(const struct bpf_reg_state *reg,
reg_off += reg->aux_off;
}
- /* skb->data is NET_IP_ALIGN-ed, but for strict alignment checking
- * we force this to 2 which is universally what architectures use
- * when they don't set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS.
+ /* For platforms that do not have a Kconfig enabling
+ * CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS the value of
+ * NET_IP_ALIGN is universally set to '2'. And on platforms
+ * that do set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, we get
+ * to this code only in strict mode where we want to emulate
+ * the NET_IP_ALIGN==2 checking. Therefore use an
+ * unconditional IP align value of '2'.
*/
- ip_align = strict ? 2 : NET_IP_ALIGN;
+ ip_align = 2;
if ((ip_align + reg_off + off) % size != 0) {
verbose("misaligned packet access off %d+%d+%d size %d\n",
ip_align, reg_off, off, size);
--
2.4.11
^ permalink raw reply related
* Re: [PATCH net-next] net/wan/fsl_ucc_hdlc: fix muram allocation error
From: David Miller @ 2017-05-22 16:29 UTC (permalink / raw)
To: holger.brunck; +Cc: netdev, qiang.zhao
In-Reply-To: <20170522073115.16393-1-holger.brunck@keymile.com>
From: Holger Brunck <holger.brunck@keymile.com>
Date: Mon, 22 May 2017 09:31:15 +0200
> sizeof(priv->ucc_pram) is 4 as it is the size of a pointer, but we want
> to reserve space for the struct ucc_hdlc_param.
>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Applied.
^ permalink raw reply
* Re: [PATCH] cfg80211: Be able to set bss expire time at config stage.
From: Johannes Berg @ 2017-05-22 16:34 UTC (permalink / raw)
To: Enric Balletbo i Serra, David S . Miller, linux-wireless
Cc: netdev, linux-kernel, Dmitry Shmidt, helmut.schaa
In-Reply-To: <1495469954.26008.1.camel@sipsolutions.net>
On Mon, 2017-05-22 at 18:19 +0200, Johannes Berg wrote:
>
> I'm not really all that convinced that we really need this -
> userspace should just be using the flush thing more often, and then
> it doesn't really matter.
>
> However, maybe that doesn't really matter all that much.
Actually, I changed my mind based on the discussion with Dan. This
makes no sense, and since you've obviously never even tested this
patch, you probably haven't thought about alternatives either.
johannes
^ permalink raw reply
* [PATCH 0/5] net-SCTP: Adjustments for three function implementations
From: SF Markus Elfring @ 2017-05-22 16:35 UTC (permalink / raw)
To: linux-sctp, netdev, David S. Miller, Neil Horman, Vlad Yasevich
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 18:30:45 +0200
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (5):
Use kmalloc_array() in sctp_init()
Delete an error message for a failed memory allocation in sctp_init()
Fix a typo in a comment line in sctp_init()
Improve a size determination in sctp_inetaddr_event()
Adjust one function call together with a variable assignment
net/sctp/protocol.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--
2.13.0
^ permalink raw reply
* Re: [PATCH 0/3] stmmac: pci: Refactor DMI probing
From: David Miller @ 2017-05-22 16:35 UTC (permalink / raw)
To: jan.kiszka
Cc: peppe.cavallaro, alexandre.torgue, netdev, linux-kernel,
andy.shevchenko
In-Reply-To: <cover.1495451529.git.jan.kiszka@siemens.com>
From: Jan Kiszka <jan.kiszka@siemens.com>
Date: Mon, 22 May 2017 13:12:06 +0200
> Some cleanups of the way we probe DMI platforms in the driver. Reduces
> a bit of open-coding and makes the logic easier reusable for any
> potential DMI platform != Quark.
>
> Tested on IOT2000 and Galileo Gen2.
This doesn't compile:
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:285:3: error: initializer element is not computable at load time
(kernel_ulong_t)&stmmac_default_setup,
^
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:285:3: note: (near initialization for ‘stmmac_id_table[0].class’)
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:289:3: error: initializer element is not computable at load time
(kernel_ulong_t)&stmmac_default_setup,
^
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:289:3: note: (near initialization for ‘stmmac_id_table[1].class’)
scripts/Makefile.build:302: recipe for target 'drivers/net/ethernet/stmicro/stmmac/stmmac_pci.o' failed
make[5]: *** [drivers/net/ethernet/stmicro/stmmac/stmmac_pci.o] Error 1
^ permalink raw reply
* [PATCH 1/5] sctp: Use kmalloc_array() in sctp_init()
From: SF Markus Elfring @ 2017-05-22 16:37 UTC (permalink / raw)
To: linux-sctp, netdev, David S. Miller, Neil Horman, Vlad Yasevich
Cc: LKML, kernel-janitors
In-Reply-To: <2845df67-d35d-536a-0a53-b2eb83fe1ba5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 17:20:11 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
* Replace the specification of a data structure by a pointer dereference
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/sctp/protocol.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 989a900383b5..2b1a6215bd2f 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1442,6 +1442,6 @@ static __init int sctp_init(void)
/* Allocate and initialize the endpoint hash table. */
sctp_ep_hashsize = 64;
- sctp_ep_hashtable =
- kmalloc(64 * sizeof(struct sctp_hashbucket), GFP_KERNEL);
+ sctp_ep_hashtable = kmalloc_array(64, sizeof(*sctp_ep_hashtable),
+ GFP_KERNEL);
if (!sctp_ep_hashtable) {
--
2.13.0
^ permalink raw reply related
* Re: [PATCH net-next 01/11] qede: Fix sparse warnings
From: David Miller @ 2017-05-22 16:38 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, Manish.Chopra
In-Reply-To: <1495452731-27171-2-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Mon, 22 May 2017 14:32:01 +0300
> From: Manish Chopra <Manish.Chopra@cavium.com>
>
> Signed-off-by: Manish Chopra <Manish.Chopra@cavium.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
> ---
> drivers/net/ethernet/qlogic/qede/qede_dcbnl.c | 1 -
> drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 10 ++++++----
> drivers/net/ethernet/qlogic/qede/qede_fp.c | 25 ++++++++++++++-----------
> drivers/net/ethernet/qlogic/qede/qede_roce.c | 4 ++--
> 4 files changed, 22 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qede/qede_dcbnl.c b/drivers/net/ethernet/qlogic/qede/qede_dcbnl.c
> index a9e7379..6e7747b 100644
> --- a/drivers/net/ethernet/qlogic/qede/qede_dcbnl.c
> +++ b/drivers/net/ethernet/qlogic/qede/qede_dcbnl.c
> @@ -313,7 +313,6 @@ static int qede_dcbnl_ieee_peer_getets(struct net_device *netdev,
> .ieee_setets = qede_dcbnl_ieee_setets,
> .ieee_getapp = qede_dcbnl_ieee_getapp,
> .ieee_setapp = qede_dcbnl_ieee_setapp,
> - .getdcbx = qede_dcbnl_getdcbx,
> .ieee_peer_getpfc = qede_dcbnl_ieee_peer_getpfc,
> .ieee_peer_getets = qede_dcbnl_ieee_peer_getets,
> .getstate = qede_dcbnl_getstate,
Please.
This is exactly the problem when such a terse commit message, or lack
of any message at all as is the case here, occurs.
I have no idea what removing this method assignment has to do with
fixing sparse warnings.
^ permalink raw reply
* [PATCH 2/5] sctp: Delete an error message for a failed memory allocation in sctp_init()
From: SF Markus Elfring @ 2017-05-22 16:38 UTC (permalink / raw)
To: linux-sctp, netdev, David S. Miller, Neil Horman, Vlad Yasevich
Cc: LKML, kernel-janitors
In-Reply-To: <2845df67-d35d-536a-0a53-b2eb83fe1ba5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 17:28:14 +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/sctp/protocol.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 2b1a6215bd2f..5e7c8a344770 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1447,5 +1447,4 @@ static __init int sctp_init(void)
if (!sctp_ep_hashtable) {
- pr_err("Failed endpoint_hash alloc\n");
status = -ENOMEM;
goto err_ehash_alloc;
}
--
2.13.0
^ permalink raw reply related
* [PATCH 3/5] sctp: Fix a typo in a comment line in sctp_init()
From: SF Markus Elfring @ 2017-05-22 16:39 UTC (permalink / raw)
To: linux-sctp, netdev, David S. Miller, Neil Horman, Vlad Yasevich
Cc: LKML, kernel-janitors
In-Reply-To: <2845df67-d35d-536a-0a53-b2eb83fe1ba5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 17:43:44 +0200
Add a missing character in this description.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/sctp/protocol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 5e7c8a344770..64756c42cec9 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -1454,7 +1454,7 @@ static __init int sctp_init(void)
}
/* Allocate and initialize the SCTP port hash table.
- * Note that order is initalized to start at the max sized
+ * Note that order is initialized to start at the max sized
* table we want to support. If we can't get that many pages
* reduce the order and try again
*/
--
2.13.0
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio
From: Duyck, Alexander H @ 2017-05-22 16:40 UTC (permalink / raw)
To: gerlitz.or@gmail.com, alexander.duyck@gmail.com
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <CAJ3xEMhtgt4==-GbAWjT8fGMQhoRAzHhFbaVgrfWgJhSaxXr9g@mail.gmail.com>
On Mon, 2017-05-22 at 06:25 +0300, Or Gerlitz wrote:
> On Mon, May 22, 2017 at 1:35 AM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
> >
> > 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.
>
> UAPI wise, we are talking on DCB, not DCBX, right? the X-portion comes
> into play if some user-space entity run LLDP traffic and calls into
> the kernel to configure (say) ETS. If there are some issues to use the
> existing user-space tool (lldpad tool/daemon) to do DCB without X, one
> can/should fix them or introduce another/simpler tool that in a
> lightweight manner only configures things w.o exchanging.
>
> So to clarify, the essence of this series is introducing a 2nd way to
> configure ETS and rate limit?
Sort of. Basically the idea is we can use several different approaches
to enable queue configuration and rate limits. So we are adding two
pieces of functionality.
The first block allows for configuring queue counts and layout.
Historically DCB/DCBX hasn't allowed us to specify that.
The second bit is that we added support for rate limiting. I am
actually basing it on what we had for SR-IOV rate limiting as that is
how this is working in i40e. However the basic attributes we are adding
should work for most ETS type use cases though it might need to use the
min rates instead of the max rates as we do in i40e.
> >
> > >
> > > 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.
>
> So the user asked to configure something and the kernel returned
> success but the config was not plugged to the hw? sounds to me like
> possible (probable) source of troubles and complaints.
That is possible, however the issue already existed. The queue
configuration could be specified with the mqprio configuration and be
totally ignored. I opted for just maintaining the existing behavior and
moving forward and providing some input via the ability to report what
"version" of the hardware offload we are supporting.
The plan is that legacy devices can fall back into the setup where they
support mode 1, however if they support hw mode 2 then we will fail to
initialize if we don't support something that is being requested.
> >
> > >
> > > 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?
>
> you were referring to the questions I posted, so we can continue the
> discussion from here.
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
^ permalink raw reply
* [PATCH 4/5] sctp: Improve a size determination in sctp_inetaddr_event()
From: SF Markus Elfring @ 2017-05-22 16:40 UTC (permalink / raw)
To: linux-sctp, netdev, David S. Miller, Neil Horman, Vlad Yasevich
Cc: LKML, kernel-janitors
In-Reply-To: <2845df67-d35d-536a-0a53-b2eb83fe1ba5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 18:08:24 +0200
Replace the specification of a data structure by a pointer dereference
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/sctp/protocol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 64756c42cec9..057479b7bd72 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -784,7 +784,7 @@ static int sctp_inetaddr_event(struct notifier_block *this, unsigned long ev,
switch (ev) {
case NETDEV_UP:
- addr = kmalloc(sizeof(struct sctp_sockaddr_entry), GFP_ATOMIC);
+ addr = kmalloc(sizeof(*addr), GFP_ATOMIC);
if (addr) {
addr->a.v4.sin_family = AF_INET;
addr->a.v4.sin_port = 0;
--
2.13.0
^ permalink raw reply related
* [PATCH 5/5] sctp: Adjust one function call together with a variable assignment
From: SF Markus Elfring @ 2017-05-22 16:41 UTC (permalink / raw)
To: linux-sctp, netdev, David S. Miller, Neil Horman, Vlad Yasevich
Cc: LKML, kernel-janitors
In-Reply-To: <2845df67-d35d-536a-0a53-b2eb83fe1ba5@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 18:15:12 +0200
The script "checkpatch.pl" pointed information out like the following.
ERROR: do not use assignment in if condition
Thus fix the affected source code place.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/sctp/protocol.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 057479b7bd72..be2fe3ebae78 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -141,7 +141,8 @@ static void sctp_v4_copy_addrlist(struct list_head *addrlist,
struct sctp_sockaddr_entry *addr;
rcu_read_lock();
- if ((in_dev = __in_dev_get_rcu(dev)) == NULL) {
+ in_dev = __in_dev_get_rcu(dev);
+ if (!in_dev) {
rcu_read_unlock();
return;
}
--
2.13.0
^ permalink raw reply related
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