* Re: [PATCH net] net/flow: fix fc->percpu NULL pointer dereference
From: Xin Long @ 2017-06-09 9:49 UTC (permalink / raw)
To: Hangbin Liu; +Cc: Steffen Klassert, David Miller, network dev
In-Reply-To: <CAPwn2JR8MUauO44qAeb3tw93PuQHEbO_8Tocs-ZW8Y9ZK+Ln8A@mail.gmail.com>
On Fri, Jun 9, 2017 at 5:06 PM, Hangbin Liu <liuhangbin@gmail.com> wrote:
> 2017-06-09 16:43 GMT+08:00 Xin Long <lucien.xin@gmail.com>:
>> On Fri, Jun 9, 2017 at 4:32 PM, Steffen Klassert
>> <steffen.klassert@secunet.com> wrote:
>>> On Fri, Jun 09, 2017 at 04:23:01PM +0800, Hangbin Liu wrote:
>>>> Hi Steffen,
>>>>
>>>> BTW, If we put the check in xfrm_policy_flush(), we can prevent it earlier.
>>>> But If we put the check in flow_cache_percpu_empty(), we can prevent
>>>> other functions set fc->percpu to NULL, although not much possible : )
>>>>
>>>> So I'm not quite sure whether we should put the check in
>>>> flow_cache_percpu_empty() or in xfrm_policy_flush().
>>>
>>> Can't we just call xfrm_policy_fini() first and then flow_cache_fini()?
>
> Yes, that would be easy fix. I have been thinking about that. But if we change
> the order in xfrm_net_exit(), do we also need to change the order in
> xfrm_net_init()? That would change a lot.
>
> If no need, that would be good.
>
>>>
>> That would be a better fix. seems safe as what flow_cache_fini does
>> is only to free fcp->hash_table and stop timer, I didn't see it has
>> any dependence on xfrm_policy stuff.
>
> I'm not familiar about this part. So not sure about the influence if we free
> the flow cache after xfrm_policy_fini(). I need do some test first.
>
> I would also be appreciate if you or some one could make sure if it doesn't
> influence anything.
>
another fix is to move xfrm_garbage_collect out of xfrm_policy_flush.
I could only see two places need to call it.
something like:
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2755,6 +2755,8 @@ static int pfkey_spdflush(struct sock *sk,
struct sk_buff *skb, const struct sad
int err, err2;
err = xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, true);
+ if (!err)
+ xfrm_garbage_collect(net);
err2 = unicast_flush_resp(sk, hdr);
if (err || err2) {
if (err == -ESRCH) /* empty table - old silent behavior */
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index ed4e52d..89343a3 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1007,9 +1007,6 @@ int xfrm_policy_flush(struct net *net, u8 type,
bool task_valid)
out:
spin_unlock_bh(&net->xfrm.xfrm_policy_lock);
- if (cnt)
- xfrm_garbage_collect(net);
-
return err;
}
EXPORT_SYMBOL(xfrm_policy_flush);
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 38614df..86116e9 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2027,6 +2027,7 @@ static int xfrm_flush_policy(struct sk_buff
*skb, struct nlmsghdr *nlh,
return 0;
return err;
}
+ xfrm_garbage_collect(net);
^ permalink raw reply related
* Re: [PATCH net-next 1/2] bpf: Fix test_bpf_obj_id() when the bpf_jit_enable sysctl is diabled
From: Daniel Borkmann @ 2017-06-09 10:06 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Yonghong Song, kernel-team
In-Reply-To: <20170609053017.2909855-1-kafai@fb.com>
On 06/09/2017 07:30 AM, Martin KaFai Lau wrote:
> test_bpf_obj_id() should not expect a non zero jited_prog_len
> to be returned by bpf_obj_get_info_by_fd() when
> net.core.bpf_jit_enable is 0.
>
> The patch checks for net.core.bpf_jit_enable and
> has different expectation on jited_prog_len.
>
> This patch also removes the pwd.h header which I forgot
> to remove after making changes.
>
> Fixes: 95b9afd3987f ("bpf: Test for bpf ID")
> Reported-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 2/2] bpf: Fix test_obj_id.c for llvm 5.0
From: Daniel Borkmann @ 2017-06-09 10:06 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Yonghong Song, kernel-team
In-Reply-To: <20170609053017.2909855-2-kafai@fb.com>
On 06/09/2017 07:30 AM, Martin KaFai Lau wrote:
> llvm 5.0 does not like the section name and the function name
> to be the same:
>
> clang -I. -I./include/uapi -I../../../include/uapi \
> -I../../../../samples/bpf/ \
> -Wno-compare-distinct-pointer-types \
> -O2 -target bpf -c \
> linux/tools/testing/selftests/bpf/test_obj_id.c -o \
> linux/tools/testing/selftests/bpf/test_obj_id.o
> fatal error: error in backend: 'test_prog_id' label emitted multiple times to
> assembly file
> clang-5.0: error: clang frontend command failed with exit code 70 (use -v to
> see invocation)
> clang version 5.0.0 (trunk 304326) (llvm/trunk 304329)
>
> This patch makes changes to the section name and the function name.
>
> Fixes: 95b9afd3987f ("bpf: Test for bpf ID")
> Reported-by: Alexei Starovoitov <ast@fb.com>
> Reported-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* Re: [PATCH net-next 3/6] netvsc: use typed pointer for internal state
From: Sergei Shtylyov @ 2017-06-09 10:24 UTC (permalink / raw)
To: Stephen Hemminger, kys, haiyangz, sthemmin; +Cc: devel, netdev
In-Reply-To: <20170608232123.28366-4-sthemmin@microsoft.com>
Hello.
On 6/9/2017 2:21 AM, Stephen Hemminger wrote:
> The element netvsc_device:extension is always a point to RNDIS
Pointer, maybe?
> information.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
> ---
> drivers/net/hyperv/hyperv_net.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index 262b2ea576a3..f82d54e0208c 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -763,8 +763,7 @@ struct netvsc_device {
>
> refcount_t sc_offered;
>
> - /* Holds rndis device info */
> - void *extension;
> + struct rndis_device *extension;
>
> int ring_size;
>
MBR, Sergei
^ permalink raw reply
* Re: [Intel-wired-lan] [i40e] regression on TCP stream and TCP maerts, kernel-4.12.0-0.rc2
From: Adrian Tomasov @ 2017-06-09 10:34 UTC (permalink / raw)
To: Duyck, Alexander H, alexander.duyck@gmail.com
Cc: osabart@redhat.com, netdev@vger.kernel.org, aokuliar@redhat.com,
intel-wired-lan@lists.osuosl.org, jhladky@redhat.com
In-Reply-To: <1496344683.27073.306.camel@intel.com>
On Thu, 2017-06-01 at 19:18 +0000, Duyck, Alexander H wrote:
> On Thu, 2017-06-01 at 12:14 +0200, Adrian Tomasov wrote:
> >
> > On Wed, 2017-05-31 at 14:42 -0700, Alexander Duyck wrote:
> > >
> > >
> > > On Wed, May 31, 2017 at 6:48 AM, Adrian Tomasov <atomasov@redhat.
> > > com>
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Tue, 2017-05-30 at 18:27 -0700, Alexander Duyck wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Tue, May 30, 2017 at 8:41 AM, Alexander Duyck
> > > > > <alexander.duyck@gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, May 30, 2017 at 6:43 AM, Adam Okuliar <aokuliar@red
> > > > > > hat.
> > > > > > com>
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > we found regression on intel card(XL710) with i40e
> > > > > > > driver.
> > > > > > > Regression is
> > > > > > > about ~45%
> > > > > > > on TCP_STREAM and TCP_MAERTS test for IPv4 and IPv6.
> > > > > > > Regression
> > > > > > > was first
> > > > > > > visible in kernel-4.12.0-0.rc1.
> > > > > > >
> > > > > > > More details about results you can see in uploaded images
> > > > > > > in
> > > > > > > bugzilla. [0]
> > > > > > >
> > > > > > >
> > > > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=195923
> > > > > > >
> > > > > > >
> > > > > > > Best regards, / S pozdravom,
> > > > > > >
> > > > > > > Adrián Tomašov
> > > > > > > Kernel Performance QE
> > > > > > > atomasov@redhat.com
> > > > > >
> > > > > > I have added the i40e driver maintainer and the intel-
> > > > > > wired-lan
> > > > > > mailing list so that we can make are developers aware of
> > > > > > the
> > > > > > issue.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > - Alex
> > > > >
> > > > > Adam,
> > > > >
> > > > > We are having some issues trying to reproduce what you
> > > > > reported.
> > > > >
> > > > > Can you provide some additional data. Specifically we would
> > > > > be
> > > > > looking
> > > > > for an "ethtool -i", and an "ethtool -S" for the port before
> > > > > and
> > > > > after
> > > > > the test. If you can attach it to the bugzilla that would be
> > > > > appreciated.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > - Alex
> > > >
> > > > Hello Alex,
> > > >
> > > > requested files are updated in bugzilla.
> > > >
> > > > If you have any questions about testing feel free to ask.
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Adrian
> > >
> > > So looking at the data I wonder if we don't have an MTU mismatch
> > > in
> > > the network config. I notice the "after" has rx_length_errors
> > > being
> > > reported. Recent changes made it so that i40e doesn't support
> > > jumbo
> > > frames by default, whereas before we could. You might want to
> > > check
> > > for that as that could cause the kind of performance issues you
> > > are
> > > seeing.
> > >
> > > - Alex
> >
> > There isn't MTU mismatch. Traffic path is : server -> switch ->
> > server.
> >
> >
> > Output from switch:
> >
> > > show interfaces et-0/0/18
> > Physical interface: et-0/0/18, Enabled, Physical link is Up
> > Interface index: 644, SNMP ifIndex: 538
> > Link-level type: Ethernet, MTU: 1514, Speed: 40Gbps, BPDU
> > Error:
> > None, MAC-REWRITE Error: None, Loopback: Disabled, Source
> > filtering:
> > Disabled, Flow control: Disabled, Media type: Fiber
> > Device flags : Present Running
> > Interface flags: SNMP-Traps Internal: 0x4000
> > Link flags : None
> > CoS queues : 12 supported, 12 maximum usable queues
> > Current address: d4:04:ff:90:5a:4b, Hardware address:
> > d4:04:ff:90:5a:4b
> > Last flapped : 2017-06-01 10:09:32 CEST (01:21:29 ago)
> > Input rate : 432 bps (0 pps)
> > Output rate : 8336 bps (11 pps)
> > Active alarms : None
> > Active defects : None
> > Interface transmit statistics: Disabled
> >
> > Logical interface et-0/0/18.0 (Index 552) (SNMP ifIndex 539)
> > Flags: SNMP-Traps 0x24024000 Encapsulation: Ethernet-Bridge
> > Input packets : 464041
> > Output packets: 209210
> > Protocol eth-switch, MTU: 1514
> > Flags: Is-Primary, Trunk-Mode
> >
> >
> > MTU is same for all et-0/0/x interfaces.
> >
> > - Adrian
>
> One thing you might try try doing is toggling the legacy-rx flag
> using
> the "ethtool --show-priv-flags/--set-priv-flags" command to see if
> that
> has any impact. That will help to rule things out as the most
> significant change I can think of is the recent update of the Rx path
> to support XDP.
>
> Also one other thing you might try would be to use a fixed interrupt
> moderation rate by locking things down using "ethtool -C" to disable
> adaptive interrupt moderation and lock the Rx usecs and Tx usecs at
> some predefined values. I seem to recall there have been some
> interrupt
> moderation changes made recently that might be impacting the
> performance.
>
> Beyond that is there any chance you would be able to bisect the
> issue?
> Unfortunately we haven't be able to reproduce it internally so
> anything
> that would help us to narrow down the problem would be useful.
>
> Thanks.
>
> - Alex
Hello Alex,
I updated firmware in NIC and it didn't make any changes. Current
firmware version is "firmware-version: 5.05 0x800028a6 1.1568.0".
I tried bisect this issue with new firmware and successfully found
first bad commit. Log from bisecting is pasted in the end. For testing
of kernel builds I used clear distribution install of RHEL7 and turn
of irqbalance. Test run between 2 servers with same HW an SW
configuration. NIC was put into different IPv4 subnet to avoid
undesirable communication.
testing command : netperf -L 192.168.0.1 -H 192.168.0.2 -T 0,0 -t
TCP_STREAM -l 30 -- -m 4096
[root@vales1 linux]# git bisect good
47994c119a36e28e1779efabc92d6ab5329a6f75 is the first bad commit
commit 47994c119a36e28e1779efabc92d6ab5329a6f75
Author: Jacob Keller <jacob.e.keller@intel.com>
Date: Wed Apr 19 09:25:57 2017 -0400
i40e: remove hw_disabled_flags in favor of using separate flag bits
The hw_disabled_flags field was added as a way of signifying that
a feature was automatically or temporarily disabled. However, we
actually only use this for FDir features. Replace its use with new
_AUTO_DISABLED flags instead. This is more readable, because you
aren't
setting an *_ENABLED flag to *disable* the feature.
Additionally, clean up a few areas where we used these bits. First,
we
don't really need to set the auto-disable flag for ATR if we're
fully
disabling the feature via ethtool.
Second, we should always clear the auto-disable bits in case they
somehow
got set when the feature was disabled. However, avoid displaying
a message that we've re-enabled the feature.
Third, we shouldn't be re-enabling ATR in the SB ntuple add flow,
because it might have been disabled due to space constraints.
Instead,
we should just wait for the fdir_check_and_reenable to be called by
the
watchdog.
Overall, this change allows us to simplify some code by removing an
extra field we didn't need, and the result should make it more
clear as
to what we're actually doing with these flags.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
:040000 040000 e2f7724e0e857b902ebfeb7104ac18ecf6b90e36
524e5f2381a64fb152ec00638d738a4f28968455 M drivers
[root@vales1 linux]# git bisect log
git bisect start
# good: [5a7ad1146caa895ad718a534399e38bd2ba721b7] Linux 4.11-rc8
git bisect good 5a7ad1146caa895ad718a534399e38bd2ba721b7
# bad: [2ea659a9ef488125eb46da6eb571de5eae5c43f6] Linux 4.12-rc1
git bisect bad 2ea659a9ef488125eb46da6eb571de5eae5c43f6
# bad: [221656e7c4ce342b99c31eca96c1cbb6d1dce45f] Merge tag 'sound-
4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect bad 221656e7c4ce342b99c31eca96c1cbb6d1dce45f
# bad: [8d65b08debc7e62b2c6032d7fe7389d895b92cbc] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad 8d65b08debc7e62b2c6032d7fe7389d895b92cbc
# good: [2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf] rhashtable: Do not
lower max_elems when max_size is zero
git bisect good 2d2ab658d2debcb4c0e29c9e6f18e5683f3077bf
# good: [6dc2cce9321198172cd96f955a5fc798a4cc35a6] Merge branch 'x86-
process-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 6dc2cce9321198172cd96f955a5fc798a4cc35a6
# good: [b68e7e952f24527de62f4768b1cead91f92f5f6e] Merge branch 'for-
linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
git bisect good b68e7e952f24527de62f4768b1cead91f92f5f6e
# bad: [773225388dae15e72790d6f573e2e70e96292b6b] net: thunderx:
Optimize page recycling for XDP
git bisect bad 773225388dae15e72790d6f573e2e70e96292b6b
# bad: [edd7f4efa8111efc279582290acc4d54d405748a] Merge branch 'bpf-
samples-skb_mode-bug-fixes'
git bisect bad edd7f4efa8111efc279582290acc4d54d405748a
# good: [0da36b9774cc24bac4bff446edf49f31aa98a282] i40e: use
DECLARE_BITMAP for state fields
git bisect good 0da36b9774cc24bac4bff446edf49f31aa98a282
# bad: [1d11e732e7d501c4a231f0b32cf8b81990592689] virtio-net: use
netif_tx_napi_add for tx napi
git bisect bad 1d11e732e7d501c4a231f0b32cf8b81990592689
# bad: [d1f496fd8f34a40458d0eda6be0655926559e546] bpf: restore skb->sk
before pskb_trim() call
git bisect bad d1f496fd8f34a40458d0eda6be0655926559e546
# bad: [3dfc3eb581645bc503c7940861f494a0d75615da] i40evf: hide unused
variable
git bisect bad 3dfc3eb581645bc503c7940861f494a0d75615da
# bad: [47994c119a36e28e1779efabc92d6ab5329a6f75] i40e: remove
hw_disabled_flags in favor of using separate flag bits
git bisect bad 47994c119a36e28e1779efabc92d6ab5329a6f75
# good: [789f38ca70e0b2848472aaf5f278aa3deabd4a4e] i40evf: remove
needless min_t() on num_online_cpus()*2
git bisect good 789f38ca70e0b2848472aaf5f278aa3deabd4a4e
# first bad commit: [47994c119a36e28e1779efabc92d6ab5329a6f75] i40e:
remove hw_disabled_flags in favor of using separate flag bits
[root@vales1 linux]# ethtool -i ens1f0
driver: i40e
version: 2.1.14-k
firmware-version: 5.05 0x800028a6 1.1568.0
expansion-rom-version:
bus-info: 0000:04:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
- Adrian
^ permalink raw reply
* [PATCH net-next] qed: add qed_int_sb_init() stub function
From: Arnd Bergmann @ 2017-06-09 10:37 UTC (permalink / raw)
To: Yuval Mintz, Ariel Elior, everest-linux-l2
Cc: Arnd Bergmann, David S. Miller, Chopra, Manish, netdev,
linux-kernel
When CONFIG_QED_SRIOV is disabled, we get a build error:
drivers/net/ethernet/qlogic/qed/qed_int.c: In function 'qed_int_sb_init':
drivers/net/ethernet/qlogic/qed/qed_int.c:1499:4: error: implicit declaration of function 'qed_vf_set_sb_info'; did you mean 'qed_mcp_get_resc_info'? [-Werror=implicit-function-declaration]
All the other declarations have a 'static inline' stub as an alternative
here, so this adds one more for qed_int_sb_init.
Fixes: 50a207147fce ("qed: Hold a single array for SBs")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/qlogic/qed/qed_vf.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.h b/drivers/net/ethernet/qlogic/qed/qed_vf.h
index b65bbc54a097..34d9b882a780 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.h
@@ -1105,6 +1105,11 @@ static inline u16 qed_vf_get_igu_sb_id(struct qed_hwfn *p_hwfn, u16 sb_id)
return 0;
}
+static inline void qed_vf_set_sb_info(struct qed_hwfn *p_hwfn, u16 sb_id,
+ struct qed_sb_info *p_sb)
+{
+}
+
static inline int qed_vf_pf_vport_start(struct qed_hwfn *p_hwfn,
u8 vport_id,
u16 mtu,
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] net: vrf: Make add_fib_rules per network namespace flag
From: Petr Machata @ 2017-06-09 11:09 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <20170608173111.22831-1-dsahern@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> Commit 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
> adds the l3mdev FIB rule the first time a VRF device is created. However,
> it only creates the rule once and only in the namespace the first device
> is created - which may not be init_net. Fix by using the net_generic
> capability to make the add_fib_rules flag per network namespace.
Works per my testing.
Thanks!
Petr
^ permalink raw reply
* Re: [PATCH] af_unix: Add sockaddr length checks before accessing sa_family in bind and connect handlers
From: Mateusz Jurczyk @ 2017-06-09 11:15 UTC (permalink / raw)
To: David Miller
Cc: WANG Cong, Hannes Frederic Sowa, Al Viro, Kees Cook,
Miklos Szeredi, Isaac Boukris, Andrey Vagin, netdev, linux-kernel
In-Reply-To: <20170608.160425.3981801836671654.davem@davemloft.net>
On Thu, Jun 8, 2017 at 10:04 PM, David Miller <davem@davemloft.net> wrote:
> From: Mateusz Jurczyk <mjurczyk@google.com>
> Date: Thu, 8 Jun 2017 11:13:36 +0200
>
>> Verify that the caller-provided sockaddr structure is large enough to
>> contain the sa_family field, before accessing it in bind() and connect()
>> handlers of the AF_UNIX socket. Since neither syscall enforces a minimum
>> size of the corresponding memory region, very short sockaddrs (zero or
>> one byte long) result in operating on uninitialized memory while
>> referencing .sa_family.
>>
>> Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
>
> The sockaddr comes from a structure on the caller's kernel stack, even
> if the user gives a smaller length, it is legal to access that memory.
It is legal to access it, but since it's uninitialized kernel stack
memory, the results of comparisons against AF_UNIX or AF_UNSPEC are
indeterminate. In practice a user-mode program could likely use timing
measurement to infer the evaluation of these comparisons, and hence
determine if a garbage 16-bit variable on the kernel stack is equal to
0x0000 or 0x0001, or a garbage byte is equal to 0x00 (if the first
byte is provided).
This is of course not very bad. However, my project for finding use of
uninitialized memory flagged it, and I thought it was worth fixing, at
least to avoid having this construct detected in the future (e.g. by
KMSAN).
There are a few more instances of this behavior in other socket types,
which I was going to report with separate patches. If you decide this
kind of issues indeed deserves a fix, please let me know if further
separate patches are the right approach.
Thanks,
Mateusz
^ permalink raw reply
* [PATCH] mwifiex: fixes the trivial print
From: Caesar Wang @ 2017-06-09 11:40 UTC (permalink / raw)
To: amitkarwar, huxm
Cc: nishants, gbhat, kvalo, linux-wireless, netdev, linux-kernel,
briannorris, jeffy.chen, Caesar Wang
We have always met the unused log be printed as following.
...
[23193.523182] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2 & channel=13 freq=0
[23378.633684] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp:
cannot find cfp by band 2 & channel=13 freq=0
Maybe that's related to wifi regdom, since wifi default area
was US and didn't support 12~14 channels.
As Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
drivers/net/wireless/marvell/mwifiex/cfp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 1ff2205..6e29943 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -350,7 +350,7 @@ mwifiex_get_cfp(struct mwifiex_private *priv, u8 band, u16 channel, u32 freq)
}
}
if (i == sband->n_channels) {
- mwifiex_dbg(priv->adapter, ERROR,
+ mwifiex_dbg(priv->adapter, WARN,
"%s: cannot find cfp by band %d\t"
"& channel=%d freq=%d\n",
__func__, band, channel, freq);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 33/44] openrisc: remove arch-specific dma_supported implementation
From: Geert Uytterhoeven @ 2017-06-09 12:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: the arch/x86 maintainers, linux-arm-kernel@lists.infradead.org,
xen-devel, linux-c6x-dev, open list:QUALCOMM HEXAGON...,
linux-ia64@vger.kernel.org, Linux MIPS Mailing List, openrisc,
linuxppc-dev@lists.ozlabs.org, linux-s390, Linux-sh list,
sparclinux, linux-xtensa@linux-xtensa.org, dmaengine, linux-tegra,
DRI Development, "linux-samsung-soc@vg
In-Reply-To: <20170608132609.32662-34-hch@lst.de>
Hi Christoph,
On Thu, Jun 8, 2017 at 3:25 PM, Christoph Hellwig <hch@lst.de> wrote:
> This implementation is simply bogus - hexagon only has a simple
openrisc?
> direct mapped DMA implementation and thus doesn't care about the
> address.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/openrisc/include/asm/dma-mapping.h | 7 -------
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net] net/flow: fix fc->percpu NULL pointer dereference
From: Hangbin Liu @ 2017-06-09 12:29 UTC (permalink / raw)
To: Xin Long; +Cc: Steffen Klassert, David Miller, network dev
In-Reply-To: <CADvbK_c=ZrFAKeaTvM2PBGbAOO4_38v4S4QB93QChUO0nK2zHw@mail.gmail.com>
On Fri, Jun 09, 2017 at 05:49:50PM +0800, Xin Long wrote:
> another fix is to move xfrm_garbage_collect out of xfrm_policy_flush.
> I could only see two places need to call it.
> something like:
>
> --- a/net/key/af_key.c
> +++ b/net/key/af_key.c
> @@ -2755,6 +2755,8 @@ static int pfkey_spdflush(struct sock *sk,
> struct sk_buff *skb, const struct sad
> int err, err2;
>
> err = xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, true);
> + if (!err)
> + xfrm_garbage_collect(net);
> err2 = unicast_flush_resp(sk, hdr);
> if (err || err2) {
> if (err == -ESRCH) /* empty table - old silent behavior */
Hmm, that would be better, just the xfrm_garbage_collect() need to be after
err || err2 check
+ xfrm_garbage_collect(net);
I will send v2 patch.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH net] net/flow: fix fc->percpu NULL pointer dereference
From: Hangbin Liu @ 2017-06-09 12:43 UTC (permalink / raw)
To: Xin Long; +Cc: Steffen Klassert, David Miller, network dev
In-Reply-To: <20170609122906.GD12974@leo.usersys.redhat.com>
2017-06-09 20:29 GMT+08:00 Hangbin Liu <liuhangbin@gmail.com>:
> On Fri, Jun 09, 2017 at 05:49:50PM +0800, Xin Long wrote:
>> another fix is to move xfrm_garbage_collect out of xfrm_policy_flush.
>> I could only see two places need to call it.
>> something like:
>>
>> --- a/net/key/af_key.c
>> +++ b/net/key/af_key.c
>> @@ -2755,6 +2755,8 @@ static int pfkey_spdflush(struct sock *sk,
>> struct sk_buff *skb, const struct sad
>> int err, err2;
>>
>> err = xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, true);
>> + if (!err)
>> + xfrm_garbage_collect(net);
>> err2 = unicast_flush_resp(sk, hdr);
>> if (err || err2) {
>> if (err == -ESRCH) /* empty table - old silent behavior */
>
> Hmm, that would be better, just the xfrm_garbage_collect() need to be after
> err || err2 check
>
> + xfrm_garbage_collect(net);
Ah, my mistake. we should check err first. Sorry.
>
> I will send v2 patch.
>
> Thanks
> Hangbin
^ permalink raw reply
* Re: [PATCH] net: Fix inconsistent teardown and release of private netdev state.
From: Johannes Berg @ 2017-06-09 12:45 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20170607.155411.201795978436906426.davem@davemloft.net>
Hi Dave,
I hope you don't mind a question or two for my understanding here.
Actually, this got pretty long... but I think there's a bug in here.
(For background, I'm looking into this because I'm interested in what
to do about backporting this to older kernels, or better, how to deal
with it in the backports project that tries to use the normal code as
is, backporting helper functions etc., which won't be possible here)
Under drivers/ in general, I count more than 400 calls to
register_netdev[ice](), but only 39 that set the new needs_free_netdev.
Some will overlap and have the same ops, but still, that's a rather
small portion of them. The logic means those that don't set
needs_free_netdev can't really use the new priv_destructor (previously
destructor), I think? It seems to me that priv_destructor should imply
needs_free_netdev (though not necessarily the other way around).
I guess this must mean that that all others are dealing with the
problem "manually", right? Perhaps needs_free_netdev isn't all that
necessary then?
So then the changes to net/mac80211/iface.c are just because you now
invoke priv_destructor in failure paths in register_netdevice, and that
would now double-free everything, since this was invoked already in the
failure paths - hence the change to only free the netdev in the failure
path.
I think you introduced a bug though - isn't this needed?
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1816,6 +1816,7 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
ret = dev_alloc_name(ndev, ndev->name);
if (ret < 0) {
ieee80211_if_free(ndev);
+ free_netdev(ndev);
return ret;
}
There was another caller of ieee80211_if_free() which you modified, and
thus needs the free_netdev() that you removed from it.
Would an alternative have been to not use (priv_)destructor here, and
just free all the data after unregister_netdevice(_many)? This sets the
reg_state to NETREG_UNREGISTERING, so sysfs can no longer look at the
stats afterwards, and it's been unlisted (unlist_netdevice) so can't be
reached through any other means either.
IOW, this would also work and fix the bug above along the way?
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 915d7e1b4545..23df973d5181 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1213,6 +1213,7 @@ static const struct net_device_ops ieee80211_monitorif_ops = {
static void ieee80211_if_free(struct net_device *dev)
{
free_percpu(dev->tstats);
+ free_netdev(dev);
}
static void ieee80211_if_setup(struct net_device *dev)
@@ -1220,8 +1221,6 @@ static void ieee80211_if_setup(struct net_device *dev)
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->netdev_ops = &ieee80211_dataif_ops;
- dev->needs_free_netdev = true;
- dev->priv_destructor = ieee80211_if_free;
}
static void ieee80211_if_setup_no_queue(struct net_device *dev)
@@ -1905,7 +1904,7 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
ret = register_netdevice(ndev);
if (ret) {
- free_netdev(ndev);
+ ieee80211_if_free(ndev);
return ret;
}
}
@@ -1932,6 +1931,7 @@ void ieee80211_if_remove(struct ieee80211_sub_if_data *sdata)
if (sdata->dev) {
unregister_netdevice(sdata->dev);
+ ieee80211_if_free(sdata->dev);
} else {
cfg80211_unregister_wdev(&sdata->wdev);
ieee80211_teardown_sdata(sdata);
@@ -1950,7 +1950,6 @@ void ieee80211_remove_interfaces(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata, *tmp;
LIST_HEAD(unreg_list);
- LIST_HEAD(wdev_list);
ASSERT_RTNL();
@@ -1971,21 +1970,22 @@ void ieee80211_remove_interfaces(struct ieee80211_local *local)
wiphy_name(local->hw.wiphy), local->open_count);
mutex_lock(&local->iflist_mtx);
- list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
- list_del(&sdata->list);
-
+ list_for_each_entry(sdata, &local->interfaces, list) {
if (sdata->dev)
unregister_netdevice_queue(sdata->dev, &unreg_list);
- else
- list_add(&sdata->list, &wdev_list);
}
mutex_unlock(&local->iflist_mtx);
unregister_netdevice_many(&unreg_list);
- list_for_each_entry_safe(sdata, tmp, &wdev_list, list) {
+ list_for_each_entry(sdata, &local->interfaces, list) {
list_del(&sdata->list);
- cfg80211_unregister_wdev(&sdata->wdev);
- kfree(sdata);
+
+ if (sdata->dev) {
+ ieee80211_if_free(sdata->dev);
+ } else {
+ cfg80211_unregister_wdev(&sdata->wdev);
+ kfree(sdata);
+ }
}
}
(I might be tempted to put that in to ease the backporting)
Thanks,
johannes
^ permalink raw reply related
* Re: [PATCH v6 00/21] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Maxime Ripard @ 2017-06-09 12:50 UTC (permalink / raw)
To: David Miller
Cc: clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170602222422.2elv6snjp3ahrhbi-ZC1Zs529Oq4@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Sat, Jun 03, 2017 at 12:24:22AM +0200, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jun 02, 2017 at 10:22:05AM -0400, David Miller wrote:
> > From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Date: Fri, 2 Jun 2017 11:13:20 +0200
> >
> > > On Fri, Jun 02, 2017 at 08:37:52AM +0200, Maxime Ripard wrote:
> > >> On Thu, Jun 01, 2017 at 02:58:19PM -0400, David Miller wrote:
> > >> > From: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >> > Date: Wed, 31 May 2017 09:18:31 +0200
> > >> >
> > >> > > This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> > > present on Allwinner H3/H5/A83T/A64 SoCs.
> > >> >
> > >> > Series applied, but wow that's a lot of DT file changes :-(
> > >>
> > >> The DT patches should not go through your tree, but arm-soc, so I
> > >> guess this is not an issue for you?
> > >
> > > Ok, so I saw that you actually merged them. Can you revert or drop
> > > that merge for the DT part?
> > >
> > > This will generate a lot of conflicts with our tree, and I'm not sure
> > > this would be efficient to make you take all the entirely unrelated to
> > > next patches.
> >
> > Please tell me which specific changes to revert.
> >
> > Thank you.
>
> Ideally everything from 2c0cba482e79 ("arm: sun8i: sunxi-h3-h5: Add dt
> node for the syscon control module") to 2428fd0fe550 ("arm64:
> defconfig: Enable dwmac-sun8i driver on defconfig")
Ping?
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* pull-request: can 2017-06-09
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request of 6 patches for net/master.
There's a patch by Stephane Grosjean that fixes an uninitialized symbol warning
in the peak_canfd driver. A patch by Johan Hovold to fix the product-id
endianness in an error message in the the peak_usb driver. A patch by Oliver
Hartkopp to enable CAN FD for virtual CAN devices by default. Three patches by
me, one makes the helper function can_change_state() robust to be called with
cf == NULL. The next patch fixes a memory leak in the gs_usb driver. And the
last one fixes a lockdep splat by properly initialize the per-net
can_rcvlists_lock spin_lock.
The following changes since commit 097d3c9508dc58286344e4a22b300098cf0c1566:
net: vrf: Make add_fib_rules per network namespace flag (2017-06-08 19:27:42 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.12-20170609
for you to fetch changes up to 97edec3a11cf6f73f2e45c3035b5ff8e4c3543dd:
can: enable CAN FD for virtual CAN devices by default (2017-06-09 14:39:02 +0200)
----------------------------------------------------------------
linux-can-fixes-for-4.12-20170609
----------------------------------------------------------------
Johan Hovold (1):
can: peak_usb: fix product-id endianness in error message
Marc Kleine-Budde (3):
can: dev: make can_change_state() robust to be called with cf == NULL
can: gs_usb: fix memory leak in gs_cmd_reset()
can: af_can: namespace support: fix lockdep splat: properly initialize spin_lock
Oliver Hartkopp (1):
can: enable CAN FD for virtual CAN devices by default
Stephane Grosjean (1):
can: peak_canfd: fix uninitialized symbol warnings
drivers/net/can/dev.c | 3 +++
drivers/net/can/peak_canfd/peak_canfd.c | 2 +-
drivers/net/can/usb/gs_usb.c | 2 ++
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 +---
drivers/net/can/vcan.c | 2 +-
drivers/net/can/vxcan.c | 2 +-
net/can/af_can.c | 3 +--
7 files changed, 10 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 2/6] can: peak_canfd: fix uninitialized symbol warnings
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Stephane Grosjean, Marc Kleine-Budde
In-Reply-To: <20170609125513.24436-1-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
This patch fixes two uninitialized symbol warnings in the new code adding
support of the PEAK-System PCAN-PCI Express FD boards, in the socket-CAN
network protocol family.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/peak_canfd/peak_canfd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/peak_canfd/peak_canfd.c b/drivers/net/can/peak_canfd/peak_canfd.c
index 0d57be5ea97b..85268be0c913 100644
--- a/drivers/net/can/peak_canfd/peak_canfd.c
+++ b/drivers/net/can/peak_canfd/peak_canfd.c
@@ -489,7 +489,7 @@ int peak_canfd_handle_msgs_list(struct peak_canfd_priv *priv,
struct pucan_rx_msg *msg_list, int msg_count)
{
void *msg_ptr = msg_list;
- int i, msg_size;
+ int i, msg_size = 0;
for (i = 0; i < msg_count; i++) {
msg_size = peak_canfd_handle_msg(priv, msg_ptr);
--
2.11.0
^ permalink raw reply related
* [PATCH 4/6] can: gs_usb: fix memory leak in gs_cmd_reset()
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Marc Kleine-Budde, linux-stable,
Maximilian Schneider
In-Reply-To: <20170609125513.24436-1-mkl@pengutronix.de>
This patch adds the missing kfree() in gs_cmd_reset() to free the
memory that is not used anymore after usb_control_msg().
Cc: linux-stable <stable@vger.kernel.org>
Cc: Maximilian Schneider <max@schneidersoft.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/gs_usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
index eecee7f8dfb7..afcc1312dbaf 100644
--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -265,6 +265,8 @@ static int gs_cmd_reset(struct gs_usb *gsusb, struct gs_can *gsdev)
sizeof(*dm),
1000);
+ kfree(dm);
+
return rc;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 1/6] can: dev: make can_change_state() robust to be called with cf == NULL
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde
In-Reply-To: <20170609125513.24436-1-mkl@pengutronix.de>
In OOM situations where no skb can be allocated, can_change_state() may
be called with cf == NULL. As this function updates the state and error
statistics it's not an option to skip the call to can_change_state() in
OOM situations.
This patch makes can_change_state() robust, so that it can be called
with cf == NULL.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 611d16a7061d..ae4ed03dc642 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -391,6 +391,9 @@ void can_change_state(struct net_device *dev, struct can_frame *cf,
can_update_state_error_stats(dev, new_state);
priv->state = new_state;
+ if (!cf)
+ return;
+
if (unlikely(new_state == CAN_STATE_BUS_OFF)) {
cf->can_id |= CAN_ERR_BUSOFF;
return;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/6] can: peak_usb: fix product-id endianness in error message
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Johan Hovold, Marc Kleine-Budde
In-Reply-To: <20170609125513.24436-1-mkl@pengutronix.de>
From: Johan Hovold <johan@kernel.org>
Make sure to use the USB device product-id stored in host-byte order in
a probe error message.
Also remove a redundant reassignment of the local usb_dev variable which
had already been used to retrieve the product id.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
index 57913dbbae0a..1ca76e03e965 100644
--- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
+++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
@@ -908,8 +908,6 @@ static int peak_usb_probe(struct usb_interface *intf,
const struct peak_usb_adapter *peak_usb_adapter = NULL;
int i, err = -ENOMEM;
- usb_dev = interface_to_usbdev(intf);
-
/* get corresponding PCAN-USB adapter */
for (i = 0; i < ARRAY_SIZE(peak_usb_adapters_list); i++)
if (peak_usb_adapters_list[i]->device_id == usb_id_product) {
@@ -920,7 +918,7 @@ static int peak_usb_probe(struct usb_interface *intf,
if (!peak_usb_adapter) {
/* should never come except device_id bad usage in this file */
pr_err("%s: didn't find device id. 0x%x in devices list\n",
- PCAN_USB_DRIVER_NAME, usb_dev->descriptor.idProduct);
+ PCAN_USB_DRIVER_NAME, usb_id_product);
return -ENODEV;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 5/6] can: af_can: namespace support: fix lockdep splat: properly initialize spin_lock
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Marc Kleine-Budde, Mario Kicherer
In-Reply-To: <20170609125513.24436-1-mkl@pengutronix.de>
This patch uses spin_lock_init() instead of __SPIN_LOCK_UNLOCKED() to
initialize the per namespace net->can.can_rcvlists_lock lock to fix this
lockdep warning:
| INFO: trying to register non-static key.
| the code is fine but needs lockdep annotation.
| turning off the locking correctness validator.
| CPU: 0 PID: 186 Comm: candump Not tainted 4.12.0-rc3+ #47
| Hardware name: Marvell Kirkwood (Flattened Device Tree)
| [<c0016644>] (unwind_backtrace) from [<c00139a8>] (show_stack+0x18/0x1c)
| [<c00139a8>] (show_stack) from [<c0058c8c>] (register_lock_class+0x1e4/0x55c)
| [<c0058c8c>] (register_lock_class) from [<c005bdfc>] (__lock_acquire+0x148/0x1990)
| [<c005bdfc>] (__lock_acquire) from [<c005deec>] (lock_acquire+0x174/0x210)
| [<c005deec>] (lock_acquire) from [<c04a6780>] (_raw_spin_lock+0x50/0x88)
| [<c04a6780>] (_raw_spin_lock) from [<bf02116c>] (can_rx_register+0x94/0x15c [can])
| [<bf02116c>] (can_rx_register [can]) from [<bf02a868>] (raw_enable_filters+0x60/0xc0 [can_raw])
| [<bf02a868>] (raw_enable_filters [can_raw]) from [<bf02ac14>] (raw_enable_allfilters+0x2c/0xa0 [can_raw])
| [<bf02ac14>] (raw_enable_allfilters [can_raw]) from [<bf02ad38>] (raw_bind+0xb0/0x250 [can_raw])
| [<bf02ad38>] (raw_bind [can_raw]) from [<c03b5fb8>] (SyS_bind+0x70/0xac)
| [<c03b5fb8>] (SyS_bind) from [<c000f8c0>] (ret_fast_syscall+0x0/0x1c)
Cc: Mario Kicherer <dev@kicherer.org>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/af_can.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/can/af_can.c b/net/can/af_can.c
index b6406fe33c76..88edac0f3e36 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -872,8 +872,7 @@ static int can_notifier(struct notifier_block *nb, unsigned long msg,
static int can_pernet_init(struct net *net)
{
- net->can.can_rcvlists_lock =
- __SPIN_LOCK_UNLOCKED(net->can.can_rcvlists_lock);
+ spin_lock_init(&net->can.can_rcvlists_lock);
net->can.can_rx_alldev_list =
kzalloc(sizeof(struct dev_rcv_lists), GFP_KERNEL);
--
2.11.0
^ permalink raw reply related
* [PATCH 6/6] can: enable CAN FD for virtual CAN devices by default
From: Marc Kleine-Budde @ 2017-06-09 12:55 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Oliver Hartkopp, Marc Kleine-Budde
In-Reply-To: <20170609125513.24436-1-mkl@pengutronix.de>
From: Oliver Hartkopp <socketcan@hartkopp.net>
CAN FD capable CAN interfaces can handle (classic) CAN 2.0 frames too.
New users usually fail at their first attempt to explore CAN FD on
virtual CAN interfaces due to the current CAN_MTU default.
Set the MTU to CANFD_MTU by default to reduce this confusion.
If someone *really* needs a 'classic CAN'-only device this can be set
with the 'ip' tool with e.g. 'ip link set vcan0 mtu 16' as before.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/vcan.c | 2 +-
drivers/net/can/vxcan.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 0eda1b308583..a8cb33264ff1 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -152,7 +152,7 @@ static const struct net_device_ops vcan_netdev_ops = {
static void vcan_setup(struct net_device *dev)
{
dev->type = ARPHRD_CAN;
- dev->mtu = CAN_MTU;
+ dev->mtu = CANFD_MTU;
dev->hard_header_len = 0;
dev->addr_len = 0;
dev->tx_queue_len = 0;
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 30cf2368becf..cfe889e8f172 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -150,7 +150,7 @@ static const struct net_device_ops vxcan_netdev_ops = {
static void vxcan_setup(struct net_device *dev)
{
dev->type = ARPHRD_CAN;
- dev->mtu = CAN_MTU;
+ dev->mtu = CANFD_MTU;
dev->hard_header_len = 0;
dev->addr_len = 0;
dev->tx_queue_len = 0;
--
2.11.0
^ permalink raw reply related
* [PATCHv2 net] net/flow: fix fc->percpu NULL pointer dereference
From: Hangbin Liu @ 2017-06-09 13:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Xin Long, Steffen Klassert, Hangbin Liu
In-Reply-To: <1496996036-22077-1-git-send-email-liuhangbin@gmail.com>
Now we will force to do garbage collection if any policy removed in
xfrm_policy_flush(). But during xfrm_net_exit(). We call flow_cache_fini()
first and set set fc->percpu to NULL. Then after we call xfrm_policy_fini()
-> frxm_policy_flush() -> flow_cache_flush(), we will get NULL pointer
dereference when check percpu_empty. The code path looks like:
flow_cache_fini()
- fc->percpu = NULL
xfrm_policy_fini()
- xfrm_policy_flush()
- xfrm_garbage_collect()
- flow_cache_flush()
- flow_cache_percpu_empty()
- fcp = per_cpu_ptr(fc->percpu, cpu)
To reproduce, just add ipsec in netns and then remove the netns.
v2:
As Xin Long suggested, since only two other places need to call it. move
xfrm_garbage_collect() outside xfrm_policy_flush().
Fixes: 35db06912189 ("xfrm: do the garbage collection after flushing policy")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/key/af_key.c | 2 ++
net/xfrm/xfrm_policy.c | 4 ----
net/xfrm/xfrm_user.c | 1 +
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 512dc43..5103f92 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2755,6 +2755,8 @@ static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, const struct sad
int err, err2;
err = xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, true);
+ if (!err)
+ xfrm_garbage_collect(net);
err2 = unicast_flush_resp(sk, hdr);
if (err || err2) {
if (err == -ESRCH) /* empty table - old silent behavior */
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index ed4e52d..643a18f 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1006,10 +1006,6 @@ int xfrm_policy_flush(struct net *net, u8 type, bool task_valid)
err = -ESRCH;
out:
spin_unlock_bh(&net->xfrm.xfrm_policy_lock);
-
- if (cnt)
- xfrm_garbage_collect(net);
-
return err;
}
EXPORT_SYMBOL(xfrm_policy_flush);
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 38614df..86116e9 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2027,6 +2027,7 @@ static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
return 0;
return err;
}
+ xfrm_garbage_collect(net);
c.data.type = type;
c.event = nlh->nlmsg_type;
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net-next v2 1/7] net: dsa: mv888e6xxx: do not use netdev printing
From: Andrew Lunn @ 2017-06-09 13:16 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20170608223414.594-2-vivien.didelot@savoirfairelinux.com>
On Thu, Jun 08, 2017 at 06:34:08PM -0400, Vivien Didelot wrote:
> The mv888e6xxx driver accesses a port's netdev mostly for printing.
>
> This is bad for 2 reasons: DSA and CPU ports do not have a netdev
> pointer; it doesn't give us a correct picture of why a DSA driver might
> need to access a port's netdev.
>
> Instead simply use dev_* printing functions with chip->dev (or ds->dev
> depending on the scope, both guaranteed to exist), with a p%d prefix for
> the target port.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/7] net: dsa: mv88e6xxx: use bridge state values
From: Andrew Lunn @ 2017-06-09 13:17 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20170608223414.594-4-vivien.didelot@savoirfairelinux.com>
On Thu, Jun 08, 2017 at 06:34:10PM -0400, Vivien Didelot wrote:
> Reuse the BR_STATE_* values to abstract a port STP state value.
>
> This provides shorter names and better control over the DSA switch
> operation call.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 04/13] net: dsa: lan9303: Added adjust_link() method
From: Egil Hjelmeland @ 2017-06-09 13:18 UTC (permalink / raw)
To: corbet, andrew, vivien.didelot, f.fainelli, davem, kernel,
linux-doc, linux-kernel, netdev
Cc: egil.hjelmeland
This makes the driver react to device tree "fixed-link" declaration
on CPU port.
- turn off autonegotiation
- force speed 10 or 100 mb/s
- force duplex mode
Signed-off-by: Egil Hjelmeland <egil.hjelmeland@zenitel.com>
---
drivers/net/dsa/lan9303-core.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 0806a0684d55..be6d78f45a5f 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -17,6 +17,7 @@
#include <linux/regmap.h>
#include <linux/mutex.h>
#include <linux/mii.h>
+#include <linux/phy.h>
#include "lan9303.h"
@@ -746,6 +747,37 @@ static int lan9303_phy_write(struct dsa_switch *ds, int phy, int regnum,
return chip->ops->phy_write(chip, phy, regnum, val);
}
+static void lan9303_adjust_link(struct dsa_switch *ds, int port,
+ struct phy_device *phydev)
+{
+ struct lan9303 *chip = ds->priv;
+
+ int ctl, res;
+
+ ctl = lan9303_phy_read(ds, port, MII_BMCR);
+
+ if (!phy_is_pseudo_fixed_link(phydev))
+ return;
+
+ ctl &= ~BMCR_ANENABLE;
+ if (phydev->speed == SPEED_100)
+ ctl |= BMCR_SPEED100;
+
+ if (phydev->duplex == DUPLEX_FULL)
+ ctl |= BMCR_FULLDPLX;
+
+ res = lan9303_phy_write(ds, port, MII_BMCR, ctl);
+
+ if (port == chip->phy_addr_sel_strap) {
+ /* Virtual Phy: Remove Turbo 200Mbit mode */
+ lan9303_read(chip->regmap, LAN9303_VIRT_SPECIAL_CTRL, &ctl);
+
+ ctl &= ~(1 << 10); // TURBO BIT
+ res = regmap_write(chip->regmap,
+ LAN9303_VIRT_SPECIAL_CTRL, ctl);
+ }
+}
+
static int lan9303_port_enable(struct dsa_switch *ds, int port,
struct phy_device *phy)
{
@@ -789,6 +821,7 @@ static struct dsa_switch_ops lan9303_switch_ops = {
.get_strings = lan9303_get_strings,
.phy_read = lan9303_phy_read,
.phy_write = lan9303_phy_write,
+ .adjust_link = lan9303_adjust_link,
.get_ethtool_stats = lan9303_get_ethtool_stats,
.get_sset_count = lan9303_get_sset_count,
.port_enable = lan9303_port_enable,
--
2.11.0
DISCLAIMER:
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.
^ 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