* [PATCH] staging: irda: Remove typedef struct
From: Haneen Mohammed @ 2017-09-14 4:55 UTC (permalink / raw)
To: outreachy-kernel
Cc: Samuel Ortiz, Greg Kroah-Hartman, netdev, devel, linux-kernel
This patch remove typedef from a structure with all its ocurrences
since using typedefs for structures is discouraged.
Issue found using Coccinelle:
@r1@
type T;
@@
typedef struct { ... } T;
@script:python c1@
T2;
T << r1.T;
@@
if T[-2:] =="_t" or T[-2:] == "_T":
coccinelle.T2 = T[:-2];
else:
coccinelle.T2 = T;
print T, coccinelle.T2
@r2@
type r1.T;
identifier c1.T2;
@@
-typedef
struct
+ T2
{ ... }
-T
;
@r3@
type r1.T;
identifier c1.T2;
@@
-T
+struct T2
Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
---
drivers/staging/irda/include/net/irda/qos.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/irda/include/net/irda/qos.h b/drivers/staging/irda/include/net/irda/qos.h
index 05a5a24..a0315b5 100644
--- a/drivers/staging/irda/include/net/irda/qos.h
+++ b/drivers/staging/irda/include/net/irda/qos.h
@@ -58,23 +58,23 @@
#define IR_16000000 0x02
/* Quality of Service information */
-typedef struct {
+struct qos_value {
__u32 value;
__u16 bits; /* LSB is first byte, MSB is second byte */
-} qos_value_t;
+};
struct qos_info {
magic_t magic;
- qos_value_t baud_rate; /* IR_11520O | ... */
- qos_value_t max_turn_time;
- qos_value_t data_size;
- qos_value_t window_size;
- qos_value_t additional_bofs;
- qos_value_t min_turn_time;
- qos_value_t link_disc_time;
+ struct qos_value baud_rate; /* IR_11520O | ... */
+ struct qos_value max_turn_time;
+ struct qos_value data_size;
+ struct qos_value window_size;
+ struct qos_value additional_bofs;
+ struct qos_value min_turn_time;
+ struct qos_value link_disc_time;
- qos_value_t power;
+ struct qos_value power;
};
extern int sysctl_max_baud_rate;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 01/10] arch:powerpc: return -ENOMEM on failed allocation
From: Allen @ 2017-09-14 4:43 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kernel, nouveau, linux-crypto, dri-devel,
MPT-FusionLinux.pdl, linux-scsi, netdev, megaraidlinux.pdl,
target-devel, linux-fbdev, linux-btrfs
In-Reply-To: <1505314401.8969.11.camel@perches.com>
> I think the changelog for this series of conversions
> should show that you've validated the change by
> inspecting the return call chain at each modified line.
>
> Also, it seems you've cc'd the same mailing lists for
> all of the patches modified by this series.
>
> It would be better to individually address each patch
> in the series only cc'ing the appropriate maintainers
> and mailing lists.
>
> A cover letter would be good too.
Point noted. Thanks.
- Allen
^ permalink raw reply
* Re: Regression in throughput between kvm guests over virtual bridge
From: Jason Wang @ 2017-09-14 4:21 UTC (permalink / raw)
To: Matthew Rosato, netdev; +Cc: davem, mst
In-Reply-To: <627d0c7a-dce5-3094-d5d4-c1507fcb8080@linux.vnet.ibm.com>
On 2017年09月14日 00:59, Matthew Rosato wrote:
> On 09/13/2017 04:13 AM, Jason Wang wrote:
>>
>> On 2017年09月13日 09:16, Jason Wang wrote:
>>>
>>> On 2017年09月13日 01:56, Matthew Rosato wrote:
>>>> We are seeing a regression for a subset of workloads across KVM guests
>>>> over a virtual bridge between host kernel 4.12 and 4.13. Bisecting
>>>> points to c67df11f "vhost_net: try batch dequing from skb array"
>>>>
>>>> In the regressed environment, we are running 4 kvm guests, 2 running as
>>>> uperf servers and 2 running as uperf clients, all on a single host.
>>>> They are connected via a virtual bridge. The uperf client profile looks
>>>> like:
>>>>
>>>> <?xml version="1.0"?>
>>>> <profile name="TCP_STREAM">
>>>> <group nprocs="1">
>>>> <transaction iterations="1">
>>>> <flowop type="connect" options="remotehost=192.168.122.103
>>>> protocol=tcp"/>
>>>> </transaction>
>>>> <transaction duration="300">
>>>> <flowop type="write" options="count=16 size=30000"/>
>>>> </transaction>
>>>> <transaction iterations="1">
>>>> <flowop type="disconnect"/>
>>>> </transaction>
>>>> </group>
>>>> </profile>
>>>>
>>>> So, 1 tcp streaming instance per client. When upgrading the host kernel
>>>> from 4.12->4.13, we see about a 30% drop in throughput for this
>>>> scenario. After the bisect, I further verified that reverting c67df11f
>>>> on 4.13 "fixes" the throughput for this scenario.
>>>>
>>>> On the other hand, if we increase the load by upping the number of
>>>> streaming instances to 50 (nprocs="50") or even 10, we see instead a
>>>> ~10% increase in throughput when upgrading host from 4.12->4.13.
>>>>
>>>> So it may be the issue is specific to "light load" scenarios. I would
>>>> expect some overhead for the batching, but 30% seems significant... Any
>>>> thoughts on what might be happening here?
>>>>
>>> Hi, thanks for the bisecting. Will try to see if I can reproduce.
>>> Various factors could have impact on stream performance. If possible,
>>> could you collect the #pkts and average packet size during the test?
>>> And if you guest version is above 4.12, could you please retry with
>>> napi_tx=true?
> Original runs were done with guest kernel 4.4 (from ubuntu 16.04.3 -
> 4.4.0-93-generic specifically). Here's a throughput report (uperf) and
> #pkts and average packet size (tcpstat) for one of the uperf clients:
>
> host 4.12 / guest 4.4:
> throughput: 29.98Gb/s
> #pkts=33465571 avg packet size=33755.70
>
> host 4.13 / guest 4.4:
> throughput: 20.36Gb/s
> #pkts=21233399 avg packet size=36130.69
I test guest 4.4 on Intel machine, still can reproduce :(
>
> I ran the test again using net-next.git as guest kernel, with and
> without napi_tx=true. napi_tx did not seem to have any significant
> impact on throughput. However, the guest kernel shift from
> 4.4->net-next improved things. I can still see a regression between
> host 4.12 and 4.13, but it's more on the order of 10-15% - another sample:
>
> host 4.12 / guest net-next (without napi_tx):
> throughput: 28.88Gb/s
> #pkts=31743116 avg packet size=33779.78
>
> host 4.13 / guest net-next (without napi_tx):
> throughput: 24.34Gb/s
> #pkts=25532724 avg packet size=35963.20
Thanks for the numbers. I originally suspect batching will lead more
pkts but less size, but looks not. The less packets is also a hint that
there's delay somewhere.
>
>>> Thanks
>> Unfortunately, I could not reproduce it locally. I'm using net-next.git
>> as guest. I can get ~42Gb/s on Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
>> for both before and after the commit. I use 1 vcpu and 1 queue, and pin
>> vcpu and vhost threads into separate cpu on host manually (in same numa
>> node).
> The environment is quite a bit different -- I'm running in an LPAR on a
> z13 (s390x). We've seen the issue in various configurations, the
> smallest thus far was a host partition w/ 40G and 20 CPUs defined (the
> numbers above were gathered w/ this configuration). Each guest has 4GB
> and 4 vcpus. No pinning / affinity configured.
Unfortunately, I don't have s390x on hand. Will try to get one.
>
>> Can you hit this regression constantly and what's you qemu command line
> Yes, the regression seems consistent. I can try tweaking some of the
> host and guest definitions to see if it makes a difference.
Is the issue gone if you reduce VHOST_RX_BATCH to 1? And it would be
also helpful to collect perf diff to see if anything interesting.
(Consider 4.4 shows more obvious regression, please use 4.4).
>
> The guests are instantiated from libvirt - Here's one of the resulting
> qemu command lines:
>
> /usr/bin/qemu-system-s390x -name guest=mjrs34g1,debug-threads=on -S
> -object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-mjrs34g1/master-key.aes
> -machine s390-ccw-virtio-2.10,accel=kvm,usb=off,dump-guest-core=off -m
> 4096 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid
> 44710587-e783-4bd8-8590-55ff421431b1 -display none -no-user-config
> -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-mjrs34g1/monitor.sock,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
> -no-shutdown -boot strict=on -drive
> file=/dev/disk/by-id/scsi-3600507630bffc0380000000000001803,format=raw,if=none,id=drive-virtio-disk0
> -device
> virtio-blk-ccw,scsi=off,devno=fe.0.0000,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=27 -device
> virtio-net-ccw,netdev=hostnet0,id=net0,mac=02:de:26:53:14:01,devno=fe.0.0001
> -netdev tap,fd=28,id=hostnet1,vhost=on,vhostfd=29 -device
> virtio-net-ccw,netdev=hostnet1,id=net1,mac=02:54:00:89:d4:01,devno=fe.0.00a1
> -chardev pty,id=charconsole0 -device
> sclpconsole,chardev=charconsole0,id=console0 -device
> virtio-balloon-ccw,id=balloon0,devno=fe.0.0002 -msg timestamp=on
>
> In the above, net0 is used for a macvtap connection (not used in the
> experiment, just for a reliable ssh connection - can remove if needed).
> net1 is the bridge connection used for the uperf tests.
>
>
>> and #cpus on host? Is zerocopy enabled?
> Host info provided above.
>
> cat /sys/module/vhost_net/parameters/experimental_zcopytx
> 1
May worth to try disable zerocopy or do the test form host to guest
instead of guest to guest to exclude the possible issue of sender.
Thanks
^ permalink raw reply
* Re: [PATCH RFC v1 0/3] Support for tap user-space access with veth interfaces
From: Jason Wang @ 2017-09-14 4:12 UTC (permalink / raw)
To: sainath.grandhi, netdev; +Cc: davem
In-Reply-To: <1504744467-79590-1-git-send-email-sainath.grandhi@intel.com>
On 2017年09月07日 08:34, sainath.grandhi@intel.com wrote:
> From: Sainath Grandhi <sainath.grandhi@intel.com>
>
> This patchset adds a tap device driver for veth virtual network interface.
> With this implementation, tap character interface can be added only to the
> peer veth interface. Adding tap interface to veth is for usecases that forwards
> packets between host and VMs. This eliminates the need for an additional
> software bridge. This can be extended to create both the peer interfaces as
> tap interfaces. These patches are a step in that direction.
>
> Sainath Grandhi (3):
> net: Adding API to parse IFLA_LINKINFO attribute
> net: Abstracting out common routines from veth for use by vethtap
> vethtap: veth based tap driver
>
> drivers/net/Kconfig | 1 +
> drivers/net/Makefile | 2 +
> drivers/net/{veth.c => veth_main.c} | 80 ++++++++++---
> drivers/net/vethtap.c | 216 ++++++++++++++++++++++++++++++++++++
> include/linux/if_veth.h | 13 +++
> include/net/rtnetlink.h | 3 +
> net/core/rtnetlink.c | 8 ++
> 7 files changed, 308 insertions(+), 15 deletions(-)
> rename drivers/net/{veth.c => veth_main.c} (89%)
> create mode 100644 drivers/net/vethtap.c
> create mode 100644 include/linux/if_veth.h
>
Interesting, plan to add vhost support for this? And we can enable
zerocopy without any worries I think.
Thanks
^ permalink raw reply
* [PATCH net] tcp: update skb->skb_mstamp more carefully
From: Eric Dumazet @ 2017-09-14 3:30 UTC (permalink / raw)
To: liujian, David Miller
Cc: edumazet, ycheng, hkchu, netdev, weiyongjun1, wangkefeng 00227729
In-Reply-To: <1505313647.15310.165.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <edumazet@googl.com>
liujian reported a problem in TCP_USER_TIMEOUT processing with a patch
in tcp_probe_timer() :
https://www.spinics.net/lists/netdev/msg454496.html
After investigations, the root cause of the problem is that we update
skb->skb_mstamp of skbs in write queue, even if the attempt to send a
clone or copy of it failed. One reason being a routing problem.
This patch prevents this, solving liujian issue.
It also removes a potential RTT miscalculation, since
__tcp_retransmit_skb() is not OR-ing TCP_SKB_CB(skb)->sacked with
TCPCB_EVER_RETRANS if a failure happens, but skb->skb_mstamp has
been changed.
A future ACK would then lead to a very small RTT sample and min_rtt
would then be lowered to this too small value.
Tested:
# cat user_timeout.pkt
--local_ip=192.168.102.64
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 `ifconfig tun0 192.168.102.64/16; ip ro add 192.0.2.1 dev tun0`
+0 < S 0:0(0) win 0 <mss 1460>
+0 > S. 0:0(0) ack 1 <mss 1460>
+.1 < . 1:1(0) ack 1 win 65530
+0 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_TCP, TCP_USER_TIMEOUT, [3000], 4) = 0
+0 write(4, ..., 24) = 24
+0 > P. 1:25(24) ack 1 win 29200
+.1 < . 1:1(0) ack 25 win 65530
//change the ipaddress
+1 `ifconfig tun0 192.168.0.10/16`
+1 write(4, ..., 24) = 24
+1 write(4, ..., 24) = 24
+1 write(4, ..., 24) = 24
+1 write(4, ..., 24) = 24
+0 `ifconfig tun0 192.168.102.64/16`
+0 < . 1:2(1) ack 25 win 65530
+0 `ifconfig tun0 192.168.0.10/16`
+3 write(4, ..., 24) = -1
# ./packetdrill user_timeout.pkt
Signed-off-by: Eric Dumazet <edumazet@googl.com>
Reported-by: liujian <liujian56@huawei.com>
---
net/ipv4/tcp_output.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5b6690d05abb98884adfa1693f97d896dd202893..a85a8c2948e54b931f8cd956aa7938f7efd355bd 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -991,6 +991,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
struct tcp_skb_cb *tcb;
struct tcp_out_options opts;
unsigned int tcp_options_size, tcp_header_size;
+ struct sk_buff *oskb = NULL;
struct tcp_md5sig_key *md5;
struct tcphdr *th;
int err;
@@ -998,12 +999,12 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
BUG_ON(!skb || !tcp_skb_pcount(skb));
tp = tcp_sk(sk);
- skb->skb_mstamp = tp->tcp_mstamp;
if (clone_it) {
TCP_SKB_CB(skb)->tx.in_flight = TCP_SKB_CB(skb)->end_seq
- tp->snd_una;
tcp_rate_skb_sent(sk, skb);
+ oskb = skb;
if (unlikely(skb_cloned(skb)))
skb = pskb_copy(skb, gfp_mask);
else
@@ -1011,6 +1012,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
if (unlikely(!skb))
return -ENOBUFS;
}
+ skb->skb_mstamp = tp->tcp_mstamp;
inet = inet_sk(sk);
tcb = TCP_SKB_CB(skb);
@@ -1122,12 +1124,14 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
err = icsk->icsk_af_ops->queue_xmit(sk, skb, &inet->cork.fl);
- if (likely(err <= 0))
- return err;
-
- tcp_enter_cwr(sk);
+ if (unlikely(err > 0)) {
+ tcp_enter_cwr(sk);
+ err = net_xmit_eval(err);
+ }
+ if (!err && oskb)
+ oskb->skb_mstamp = tp->tcp_mstamp;
- return net_xmit_eval(err);
+ return err;
}
/* This routine just queues the buffer for sending.
@@ -2869,10 +2873,11 @@ int __tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb, int segs)
skb_headroom(skb) >= 0xFFFF)) {
struct sk_buff *nskb;
- skb->skb_mstamp = tp->tcp_mstamp;
nskb = __pskb_copy(skb, MAX_TCP_HEADER, GFP_ATOMIC);
err = nskb ? tcp_transmit_skb(sk, nskb, 0, GFP_ATOMIC) :
-ENOBUFS;
+ if (!err)
+ skb->skb_mstamp = tp->tcp_mstamp;
} else {
err = tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC);
}
^ permalink raw reply related
* [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
From: nixiaoming @ 2017-09-14 2:44 UTC (permalink / raw)
To: davem, edumazet, waltje, gw4pts, andreyknvl, tklauser,
philip.pettersson, glider
Cc: netdev, linux-kernel, nixiaoming, dede.wu
If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
or add spin_lock(&po->bind_lock) before po-> fanout = match
test on linux 4.1.12:
./trinity -c setsockopt -C 2 -X &
BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[<ffffffc000209414>] dump_backtrace+0x0/0xf8
[<ffffffc00020952c>] show_stack+0x20/0x28
[<ffffffc000635574>] dump_stack+0xac/0xe4
[<ffffffc000633fb8>] panic+0xf8/0x268
[<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
[<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
[<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
[<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Tested-by: wudesheng <dede.wu@huawei.com>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
po->running = 0;
+ mutex_lock(&fanout_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(&po->prot_hook);
+ mutex_unlock(&fanout_mutex);
__sock_put(sk);
--
2.11.0.1
^ permalink raw reply related
* [PATCH] net/packet: fix race condition between fanout_add and __unregister_prot_hook
From: nixiaoming @ 2017-09-14 2:40 UTC (permalink / raw)
To: davem, edumazet, waltje, gw4pts, andreyknvl, tklauser,
philip.pettersson, glider
Cc: netdev, linux-kernel, nixiaoming, dede.wu
If fanout_add is preempted after running po-> fanout = match
and before running __fanout_link,
it will cause BUG_ON when __unregister_prot_hook call __fanout_unlink
so, we need add mutex_lock(&fanout_mutex) to __unregister_prot_hook
or add spin_lock(&po->bind_lock) before po-> fanout = match
test on linux 4.1.42:
./trinity -c setsockopt -C 2 -X &
BUG: failure at net/packet/af_packet.c:1414/__fanout_unlink()!
Kernel panic - not syncing: BUG!
CPU: 2 PID: 2271 Comm: trinity-c0 Tainted: G W O 4.1.12 #1
Hardware name: Hisilicon PhosphorHi1382 FPGA (DT)
Call trace:
[<ffffffc000209414>] dump_backtrace+0x0/0xf8
[<ffffffc00020952c>] show_stack+0x20/0x28
[<ffffffc000635574>] dump_stack+0xac/0xe4
[<ffffffc000633fb8>] panic+0xf8/0x268
[<ffffffc0005fa778>] __unregister_prot_hook+0xa0/0x144
[<ffffffc0005fba48>] packet_set_ring+0x280/0x5b4
[<ffffffc0005fc33c>] packet_setsockopt+0x320/0x950
[<ffffffc000554a04>] SyS_setsockopt+0xa4/0xd4
Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Tested-by: wudesheng <dede.wu@huawei.com>
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 008a45c..0300146 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -365,10 +365,12 @@ static void __unregister_prot_hook(struct sock *sk, bool sync)
po->running = 0;
+ mutex_lock(&fanout_mutex);
if (po->fanout)
__fanout_unlink(sk, po);
else
__dev_remove_pack(&po->prot_hook);
+ mutex_unlock(&fanout_mutex);
__sock_put(sk);
--
2.11.0.1
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
From: Brown, Aaron F @ 2017-09-14 2:24 UTC (permalink / raw)
To: Christophe JAILLET, Waskiewicz Jr, Peter, Kirsher, Jeffrey T
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <95a0bc80-8b41-d74f-8059-ae7181493120@wanadoo.fr>
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@osuosl.org] On Behalf
> Of Christophe JAILLET
> Sent: Monday, August 28, 2017 10:13 AM
> To: Waskiewicz Jr, Peter <peter.waskiewicz.jr@intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>
> Cc: netdev@vger.kernel.org; kernel-janitors@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org; linux-kernel@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure
>
> Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit :
> > On 8/27/17 2:42 AM, Christophe JAILLET wrote:
> >> Check memory allocation failures and return -ENOMEM in such cases, as
> >> already done for other memory allocations in this function.
> >>
> >> This avoids NULL pointers dereference.
> >>
> >> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> >> ---
> >> drivers/net/ethernet/intel/igb/igb_main.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
This seems to be fine from a "it does not break in testing" perspective, so...
Tested-by: Aaron Brown <aaron.f.brown@intel.com
> > -PJ
> >
> Hi,
>
> in fact, there is no leak because the only caller of 'igb_sw_init()'
> (i.e. 'igb_probe()'), already frees these resources in case of error,
> see [1]
>
> These resources are also freed in 'igb_remove()'.
>
> Best reagrds,
> CJ
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
> next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775
But is PJ's comment saying that it is not really necessary? If so I tend to lean towards the don't touch it if it's not broken perspective.
^ permalink raw reply
* [PATCH net] udpv6: Fix the checksum computation when HW checksum does not apply
From: Subash Abhinov Kasiviswanathan @ 2017-09-14 1:30 UTC (permalink / raw)
To: netdev, vyasevic; +Cc: Subash Abhinov Kasiviswanathan
While trying an ESP transport mode encryption for UDPv6 packets of
datagram size 1436 with MTU 1500, checksum error was observed in
the secondary fragment.
This error occurs due to the UDP payload checksum being missed out
when computing the full checksum for these packets in
udp6_hwcsum_outgoing().
Fixes: d39d938c8228 ("ipv6: Introduce udpv6_send_skb()")
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
net/ipv6/udp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index e2ecfb1..40d7234 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1015,6 +1015,7 @@ static void udp6_hwcsum_outgoing(struct sock *sk, struct sk_buff *skb,
*/
offset = skb_transport_offset(skb);
skb->csum = skb_checksum(skb, offset, skb->len - offset, 0);
+ csum = skb->csum;
skb->ip_summed = CHECKSUM_NONE;
--
1.9.1
^ permalink raw reply related
* Re: [RFC net-next 2/5] net/sched: Introduce Credit Based Shaper (CBS) qdisc
From: Vinicius Costa Gomes @ 2017-09-14 0:39 UTC (permalink / raw)
To: Henrik Austad
Cc: netdev, jhs, xiyou.wangcong, jiri, intel-wired-lan, andre.guedes,
ivan.briano, jesus.sanchez-palencia, boon.leong.ong,
richardcochran
In-Reply-To: <20170908134332.GD9064@sisyphus.home.austad.us>
Hi Henrik,
Henrik Austad <henrik@austad.us> writes:
> On Thu, Aug 31, 2017 at 06:26:22PM -0700, Vinicius Costa Gomes wrote:
>> This queueing discipline implements the shaper algorithm defined by
>> the 802.1Q-2014 Section 8.6.8.2 and detailed in Annex L.
>>
>> It's primary usage is to apply some bandwidth reservation to user
>> defined traffic classes, which are mapped to different queues via the
>> mqprio qdisc.
>>
>> Initially, it only supports offloading the traffic shaping work to
>> supporting controllers.
>>
>> Later, when a software implementation is added, the current dependency
>> on being installed "under" mqprio can be lifted.
>>
>> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
>> Signed-off-by: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
>
> So, I started testing this in my VM to make sure I didn't do anything silly
> and it exploded spectacularly as it used the underlying e1000 driver which
> does not have a ndo_setup_tc present.
>
> I commented inline below, but as a tl;dr
>
> The cbs_init() would call into cbs_change() that would correctly detect
> that ndo_setup_tc is missing and abort. However, at this stage it would try
> to desroy the qdisc and in cbs_destroy() there's no such guard leading to a
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
>
> Fixing that, another NULL would be found when the code walks into
> qdisc_destroy(q->qdisc).
>
> Apart from this, it loaded fine after some wrestling with tc :)
>
> Awesome! :D
>
>> ---
>> include/linux/netdevice.h | 1 +
>> net/sched/Kconfig | 11 ++
>> net/sched/Makefile | 1 +
>> net/sched/sch_cbs.c | 286 ++++++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 299 insertions(+)
>> create mode 100644 net/sched/sch_cbs.c
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 35de8312e0b5..dd9a2ecd0c03 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -775,6 +775,7 @@ enum tc_setup_type {
>> TC_SETUP_CLSFLOWER,
>> TC_SETUP_CLSMATCHALL,
>> TC_SETUP_CLSBPF,
>> + TC_SETUP_CBS,
>> };
>>
>> /* These structures hold the attributes of xdp state that are being passed
>> diff --git a/net/sched/Kconfig b/net/sched/Kconfig
>> index e70ed26485a2..c03d86a7775e 100644
>> --- a/net/sched/Kconfig
>> +++ b/net/sched/Kconfig
>> @@ -172,6 +172,17 @@ config NET_SCH_TBF
>> To compile this code as a module, choose M here: the
>> module will be called sch_tbf.
>>
>> +config NET_SCH_CBS
>
> Shouldn't this depend on NET_SCH_MQPRIO as it is supposed to hook into
> that?
Right now, the CBS shaper only makes sense with mqprio, later it may use
some other qdisc (like "taprio" mentioned in the cover letter) to hook
into, so, yes, you are right, there's a dependency here, better make it
clear. Will fix.
>
> @@ -173,6 +173,7 @@ config NET_SCH_TBF
> module will be called sch_tbf.
>
> config NET_SCH_CBS
> + depends on NET_SCH_MQPRIO
> tristate "Credit Based Shaper (CBS)"
> ---help---
> Say Y here if you want to use the Credit Based Shaper (CBS) packet
>
>> + tristate "Credit Based Shaper (CBS)"
>> + ---help---
>> + Say Y here if you want to use the Credit Based Shaper (CBS) packet
>> + scheduling algorithm.
>> +
>> + See the top of <file:net/sched/sch_cbs.c> for more details.
>> +
>> + To compile this code as a module, choose M here: the
>> + module will be called sch_cbs.
>> +
>> config NET_SCH_GRED
>> tristate "Generic Random Early Detection (GRED)"
>> ---help---
>> diff --git a/net/sched/Makefile b/net/sched/Makefile
>> index 7b915d226de7..80c8f92d162d 100644
>> --- a/net/sched/Makefile
>> +++ b/net/sched/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_NET_SCH_FQ_CODEL) += sch_fq_codel.o
>> obj-$(CONFIG_NET_SCH_FQ) += sch_fq.o
>> obj-$(CONFIG_NET_SCH_HHF) += sch_hhf.o
>> obj-$(CONFIG_NET_SCH_PIE) += sch_pie.o
>> +obj-$(CONFIG_NET_SCH_CBS) += sch_cbs.o
>>
>> obj-$(CONFIG_NET_CLS_U32) += cls_u32.o
>> obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o
>> diff --git a/net/sched/sch_cbs.c b/net/sched/sch_cbs.c
>> new file mode 100644
>> index 000000000000..1c86a9e14150
>> --- /dev/null
>> +++ b/net/sched/sch_cbs.c
>> @@ -0,0 +1,286 @@
>> +/*
>> + * net/sched/sch_cbs.c Credit Based Shaper
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + *
>> + * Authors: Vininicius Costa Gomes <vinicius.gomes@intel.com>
>> + *
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <linux/kernel.h>
>> +#include <linux/string.h>
>> +#include <linux/errno.h>
>> +#include <linux/skbuff.h>
>> +#include <net/netlink.h>
>> +#include <net/sch_generic.h>
>> +#include <net/pkt_sched.h>
>> +
>> +struct cbs_sched_data {
>> + struct Qdisc *qdisc; /* Inner qdisc, default - pfifo queue */
>> + s32 queue;
>> + s32 locredit;
>> + s32 hicredit;
>> + s32 sendslope;
>> + s32 idleslope;
>> +};
>> +
>> +static int cbs_enqueue(struct sk_buff *skb, struct Qdisc *sch,
>> + struct sk_buff **to_free)
>> +{
>> + struct cbs_sched_data *q = qdisc_priv(sch);
>> + int ret;
>> +
>> + ret = qdisc_enqueue(skb, q->qdisc, to_free);
>> + if (ret != NET_XMIT_SUCCESS) {
>> + if (net_xmit_drop_count(ret))
>> + qdisc_qstats_drop(sch);
>> + return ret;
>> + }
>> +
>> + qdisc_qstats_backlog_inc(sch, skb);
>> + sch->q.qlen++;
>> + return NET_XMIT_SUCCESS;
>> +}
>> +
>> +static struct sk_buff *cbs_dequeue(struct Qdisc *sch)
>> +{
>> + struct cbs_sched_data *q = qdisc_priv(sch);
>> + struct sk_buff *skb;
>> +
>> + skb = q->qdisc->ops->peek(q->qdisc);
>> + if (skb) {
>> + skb = qdisc_dequeue_peeked(q->qdisc);
>> + if (unlikely(!skb))
>> + return NULL;
>> +
>> + qdisc_qstats_backlog_dec(sch, skb);
>> + sch->q.qlen--;
>> + qdisc_bstats_update(sch, skb);
>> +
>> + return skb;
>> + }
>> + return NULL;
>> +}
>> +
>> +static void cbs_reset(struct Qdisc *sch)
>> +{
>> + struct cbs_sched_data *q = qdisc_priv(sch);
>> +
>> + qdisc_reset(q->qdisc);
>> +}
>> +
>> +static const struct nla_policy cbs_policy[TCA_CBS_MAX + 1] = {
>> + [TCA_CBS_PARMS] = { .len = sizeof(struct tc_cbs_qopt) },
>> +};
>> +
>> +static int cbs_change(struct Qdisc *sch, struct nlattr *opt)
>> +{
>> + struct cbs_sched_data *q = qdisc_priv(sch);
>> + struct tc_cbs_qopt_offload cbs = { };
>> + struct nlattr *tb[TCA_CBS_MAX + 1];
>> + const struct net_device_ops *ops;
>> + struct tc_cbs_qopt *qopt;
>> + struct net_device *dev;
>> + int err;
>> +
>> + err = nla_parse_nested(tb, TCA_CBS_MAX, opt, cbs_policy, NULL);
>> + if (err < 0)
>> + return err;
>> +
>> + err = -EINVAL;
>> + if (!tb[TCA_CBS_PARMS])
>> + goto done;
>> +
>> + qopt = nla_data(tb[TCA_CBS_PARMS]);
>> +
>> + dev = qdisc_dev(sch);
>> + ops = dev->netdev_ops;
>> +
>> + /* FIXME: this means that we can only install this qdisc
>> + * "under" mqprio. Do we need a more generic way to retrieve
>> + * the queue, or do we pass the netdev_queue to the driver?
>> + */
>> + cbs.queue = TC_H_MIN(sch->parent) - 1 - netdev_get_num_tc(dev);
>> +
>> + cbs.enable = 1;
>> + cbs.hicredit = qopt->hicredit;
>> + cbs.locredit = qopt->locredit;
>> + cbs.idleslope = qopt->idleslope;
>> + cbs.sendslope = qopt->sendslope;
>> +
>> + err = -ENOTSUPP;
>> + if (!ops->ndo_setup_tc)
>> + goto done;
>
> This confuses tc a bit, and looking at other qdisc schedulers, it seems
> like EOPNOTSUPP is an alternative, this changes the output from
>
> RTNETLINK answers: Unknown error 524
> - to
> RTNETLINK answers: Operation not supported
>
Yeah, I missed this. Thanks for catching this.
> which perhaps is more informative.
>
>> +
>> + err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_CBS, &cbs);
>> + if (err < 0)
>> + goto done;
>> +
>> + q->queue = cbs.queue;
>> + q->hicredit = cbs.hicredit;
>> + q->locredit = cbs.locredit;
>> + q->idleslope = cbs.idleslope;
>> + q->sendslope = cbs.sendslope;
>> +
>> +done:
>> + return err;
>> +}
>> +
>> +static int cbs_init(struct Qdisc *sch, struct nlattr *opt)
>> +{
>> + struct cbs_sched_data *q = qdisc_priv(sch);
>> +
>> + if (!opt)
>> + return -EINVAL;
>> +
>> + q->qdisc = fifo_create_dflt(sch, &pfifo_qdisc_ops, 1024);
>> + qdisc_hash_add(q->qdisc, true);
>> +
>> + return cbs_change(sch, opt);
>> +}
>> +
>> +static void cbs_destroy(struct Qdisc *sch)
>> +{
>> + struct cbs_sched_data *q = qdisc_priv(sch);
>> + struct tc_cbs_qopt_offload cbs = { };
>> + struct net_device *dev;
>> + int err;
>> +
>> + q->hicredit = 0;
>> + q->locredit = 0;
>> + q->idleslope = 0;
>> + q->sendslope = 0;
>> +
>> + dev = qdisc_dev(sch);
>> +
>> + cbs.queue = q->queue;
>> + cbs.enable = 0;
>> +
>> + err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_CBS, &cbs);
>
> This can lead to NULL pointer deref if it is not set (tested for in
> cbs_change and error there leads us here, which then explodes).
Fixed.
>
>> + if (err < 0)
>> + pr_warn("Couldn't reset queue %d to default values\n",
>> + cbs.queue);
>> +
>> + qdisc_destroy(q->qdisc);
>
> Same, q->qdisc was NULL when cbs_init() failed.
>
Fixed the error path, thanks.
Cheers,
^ permalink raw reply
* [PATCH] net: ipv4: fix l3slave check for index returned in IP_PKTINFO
From: David Ahern @ 2017-09-14 0:11 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
rt_iif is only set to the actual egress device for the output path. The
recent change to consider the l3slave flag when returning IP_PKTINFO
works for local traffic (the correct device index is returned), but it
broke the more typical use case of packets received from a remote host
always returning the VRF index rather than the original ingress device.
Update the fixup to consider l3slave and rt_iif actually getting set.
Fixes: 1dfa76390bf05 ("net: ipv4: add check for l3slave for index returned in IP_PKTINFO")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv4/ip_sockglue.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index e558e4f9597b..a599aa83fdad 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -1207,7 +1207,6 @@ static int do_ip_setsockopt(struct sock *sk, int level,
void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
{
struct in_pktinfo *pktinfo = PKTINFO_SKB_CB(skb);
- bool l3slave = ipv4_l3mdev_skb(IPCB(skb)->flags);
bool prepare = (inet_sk(sk)->cmsg_flags & IP_CMSG_PKTINFO) ||
ipv6_sk_rxinfo(sk);
@@ -1221,8 +1220,13 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb)
* (e.g., process binds socket to eth0 for Tx which is
* redirected to loopback in the rtable/dst).
*/
- if (pktinfo->ipi_ifindex == LOOPBACK_IFINDEX || l3slave)
+ struct rtable *rt = skb_rtable(skb);
+ bool l3slave = ipv4_l3mdev_skb(IPCB(skb)->flags);
+
+ if (pktinfo->ipi_ifindex == LOOPBACK_IFINDEX)
pktinfo->ipi_ifindex = inet_iif(skb);
+ else if (l3slave && rt && rt->rt_iif)
+ pktinfo->ipi_ifindex = rt->rt_iif;
pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb);
} else {
--
2.1.4
^ permalink raw reply related
* RE: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
From: Yoshihiro Shimoda @ 2017-09-14 0:11 UTC (permalink / raw)
To: Sergei Shtylyov, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1f4763ea-9f8a-03a6-1215-69b96c404590-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1568 bytes --]
Hello!
> From: Sergei Shtylyov
> Sent: Thursday, September 14, 2017 1:02 AM
>
> Hello!
>
> On 09/13/2017 03:17 PM, Yoshihiro Shimoda wrote:
>
> > Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > ---
> > Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > index 1672353..ae2213f 100644
> > --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > @@ -17,6 +17,7 @@ Required properties:
> >
> > - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
> > - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
> > + - "renesas,etheravb-r8a77995" for the R8A77995 SoC.
>
> That would conflict with the R8A77970 bindings patch posted by me
> yesterday. Please respin atop of it.
Yes, I submitted v2 patch now.
> > - "renesas,etheravb-rcar-gen3" as a fallback for the above
> > R-Car Gen3 devices.
> >
>
> One more fragment is needed here, about the mandatory 'interrupt-names"
> prop. My patch makes this change unnecessary, however...
I understood it.
Best regards,
Yoshihiro Shimoda
> MBR, Sergei
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
From: Yoshihiro Shimoda @ 2017-09-14 0:06 UTC (permalink / raw)
To: davem, robh+dt, mark.rutland
Cc: netdev, linux-renesas-soc, devicetree, Yoshihiro Shimoda
Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
Changes from v1:
- Based on r8a77970 patch.
https://marc.info/?l=linux-renesas-soc&m=150524655515476
- Add Acked-by (Thanks Geert-san!).
Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index 2689211..c902261 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -18,6 +18,7 @@ Required properties:
- "renesas,etheravb-r8a7795" for the R8A7795 SoC.
- "renesas,etheravb-r8a7796" for the R8A7796 SoC.
- "renesas,etheravb-r8a77970" for the R8A77970 SoC.
+ - "renesas,etheravb-r8a77995" for the R8A77995 SoC.
- "renesas,etheravb-rcar-gen3" as a fallback for the above
R-Car Gen3 devices.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 net] sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
From: David Miller @ 2017-09-14 0:00 UTC (permalink / raw)
To: dan.carpenter; +Cc: vyasevich, nhorman, linux-sctp, netdev, kernel-janitors
In-Reply-To: <20170913230054.fmtidvfi2swvy2mm@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 14 Sep 2017 02:00:54 +0300
> This code causes a static checker warning because Smatch doesn't trust
> anything that comes from skb->data. I've reviewed this code and I do
> think skb->data can be controlled by the user here.
>
> The sctp_event_subscribe struct has 13 __u8 fields and we want to see
> if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range.
> We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read
> either before the start of the struct or after the end.
>
> This is a very old bug and it's surprising that it would go undetected
> for so long but my theory is that it just doesn't have a big impact so
> it would be hard to notice.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: Use reverse-christmas-tree local variable ordering.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Job Offer In USA
From: Valero Energy Recruitment @ 2017-09-13 16:24 UTC (permalink / raw)
To: Recipients
Valero Energy Oil & Gas Company USA
Employment Opportunity in Texas, USA.
Oil & Gas Sector ( NEW PLANT RIG )
Salary Range $7,000 USD - $11,700 Per Month
Kindly send your CV/RESUME for more details regarding our Job Program, Employment offers for all Offices.
CC: Forward All Documents/Certificates & Resume to: valeroenergy.recruit@gmail.com
^ permalink raw reply
* Re: [PATCH v2] net: smsc911x: Quieten netif during suspend
From: Florian Fainelli @ 2017-09-13 23:28 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller, Steve Glendinning
Cc: Andrew Lunn, netdev, linux-pm, linux-renesas-soc, linux-kernel
In-Reply-To: <1505324525-9998-1-git-send-email-geert+renesas@glider.be>
On 09/13/2017 10:42 AM, Geert Uytterhoeven wrote:
> If the network interface is kept running during suspend, the net core
> may call net_device_ops.ndo_start_xmit() while the Ethernet device is
> still suspended, which may lead to a system crash.
>
> E.g. on sh73a0/kzm9g and r8a73a4/ape6evm, the external Ethernet chip is
> driven by a PM controlled clock. If the Ethernet registers are accessed
> while the clock is not running, the system will crash with an imprecise
> external abort.
>
> As this is a race condition with a small time window, it is not so easy
> to trigger at will. Using pm_test may increase your chances:
>
> # echo 0 > /sys/module/printk/parameters/console_suspend
> # echo platform > /sys/power/pm_test
> # echo mem > /sys/power/state
>
> To fix this, make sure the network interface is quietened during
> suspend.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
You may want to take the opportunity to suspend the PHY device
(conversely resume it) if WoL is not enabled on this device.
Thanks!
> ---
> This is v2 of the series "[PATCH 0/2] net: Fix crashes due to activity
> during suspend", which degenerated into a single patch after commit
> ebc8254aeae34226 ("Revert "net: phy: Correctly process PHY_HALTED in
> phy_stop_machine()"") made "[PATCH 1/2] net: phy: Freeze PHY polling before
> suspending devices" no longer needed.
>
> v2:
> - Spelling s/quit/quiet/g.
>
> No stacktrace is provided, as the imprecise external abort is usually
> reported from an innocent looking and unrelated function like
> __loop_delay(), cpu_idle_poll(), or arch_timer_read_counter_long().
> ---
> drivers/net/ethernet/smsc/smsc911x.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> index 0b6a39b003a4e188..012fb66eed8dd618 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -2595,6 +2595,11 @@ static int smsc911x_suspend(struct device *dev)
> struct net_device *ndev = dev_get_drvdata(dev);
> struct smsc911x_data *pdata = netdev_priv(ndev);
>
> + if (netif_running(ndev)) {
> + netif_stop_queue(ndev);
> + netif_device_detach(ndev);
> + }
> +
> /* enable wake on LAN, energy detection and the external PME
> * signal. */
> smsc911x_reg_write(pdata, PMT_CTRL,
> @@ -2628,7 +2633,15 @@ static int smsc911x_resume(struct device *dev)
> while (!(smsc911x_reg_read(pdata, PMT_CTRL) & PMT_CTRL_READY_) && --to)
> udelay(1000);
>
> - return (to == 0) ? -EIO : 0;
> + if (to == 0)
> + return -EIO;
> +
> + if (netif_running(ndev)) {
> + netif_device_attach(ndev);
> + netif_start_queue(ndev);
> + }
> +
> + return 0;
> }
>
> static const struct dev_pm_ops smsc911x_pm_ops = {
>
--
Florian
^ permalink raw reply
* [PATCH v2 net] sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
From: Dan Carpenter @ 2017-09-13 23:00 UTC (permalink / raw)
To: Vlad Yasevich
Cc: Neil Horman, David S. Miller, linux-sctp, netdev, kernel-janitors
In-Reply-To: <20170913.092522.934509429497822082.davem@davemloft.net>
This code causes a static checker warning because Smatch doesn't trust
anything that comes from skb->data. I've reviewed this code and I do
think skb->data can be controlled by the user here.
The sctp_event_subscribe struct has 13 __u8 fields and we want to see
if ours is non-zero. sn_type can be any value in the 0-USHRT_MAX range.
We're subtracting SCTP_SN_TYPE_BASE which is 1 << 15 so we could read
either before the start of the struct or after the end.
This is a very old bug and it's surprising that it would go undetected
for so long but my theory is that it just doesn't have a big impact so
it would be hard to notice.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: Use reverse-christmas-tree local variable ordering.
diff --git a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h
index 1060494ac230..b8c86ec1a8f5 100644
--- a/include/net/sctp/ulpevent.h
+++ b/include/net/sctp/ulpevent.h
@@ -153,8 +153,12 @@ __u16 sctp_ulpevent_get_notification_type(const struct sctp_ulpevent *event);
static inline int sctp_ulpevent_type_enabled(__u16 sn_type,
struct sctp_event_subscribe *mask)
{
+ int offset = sn_type - SCTP_SN_TYPE_BASE;
char *amask = (char *) mask;
- return amask[sn_type - SCTP_SN_TYPE_BASE];
+
+ if (offset >= sizeof(struct sctp_event_subscribe))
+ return 0;
+ return amask[offset];
}
/* Given an event subscription, is this event enabled? */
^ permalink raw reply related
* Re: [PATCH] net: Convert int functions to bool
From: Joe Perches @ 2017-09-13 22:55 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: netdev
In-Reply-To: <20170913223158.GA7860@avx2>
On Thu, 2017-09-14 at 01:31 +0300, Alexey Dobriyan wrote:
> > Global function ipv6_rcv_saddr_equal and static functions
> > ipv6_rcv_saddr_equal and ipv4_rcv_saddr_equal currently return int.
> >
> > bool is slightly more descriptive for these functions so change
> > their return type from int to bool.
>
> From code generation POV "int" is better for non-inlined functions
> especially on non-x86.
I don't agree with you here. For instance:
$ size net/ipv4/*.o*
text data bss dec hex filename
9832 26 0 9858 2682 net/ipv4/inet_connection_sock.o.arm.defconfig.new
9860 26 0 9886 269e net/ipv4/inet_connection_sock.o.arm.defconfig.old
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Cole Robinson @ 2017-09-13 22:49 UTC (permalink / raw)
To: Josef Bacik, Laura Abbott, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <E068C58A-DC80-4D98-ADE6-8F05304EC7ED@fb.com>
On 09/13/2017 03:44 PM, Josef Bacik wrote:
> Alright thanks, this should fix it.
>
Still no luck with all three patches applied to fedora 4.12.8-300 RPM. Pretty
sure I didn't mess up the testing but since I rarely do kernel builds it's not
impossible...
Thanks,
Cole
^ permalink raw reply
* Re: [PATCH] net: Convert int functions to bool
From: Alexey Dobriyan @ 2017-09-13 22:31 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
> Global function ipv6_rcv_saddr_equal and static functions
> ipv6_rcv_saddr_equal and ipv4_rcv_saddr_equal currently return int.
>
> bool is slightly more descriptive for these functions so change
> their return type from int to bool.
>From code generation POV "int" is better for non-inlined functions
especially on non-x86.
Patch bloats even x86_64:
$ ./scripts/bloat-o-meter ../vmlinux-002-do-while ../obj/vmlinux
add/remove: 0/0 grow/shrink: 2/0 up/down: 3/0 (3)
function old new delta
inet_rcv_saddr_equal 38 40 +2
inet_csk_get_port 1300 1301 +1
Total: Before=6084708, After=6084711, chg +0.00%
^ permalink raw reply
* Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
From: Franklin S Cooper Jr @ 2017-09-13 21:58 UTC (permalink / raw)
To: wg, mkl, mario.huettel, socketcan, quentin.schulz, edumazet,
linux-can, netdev, linux-kernel, Nori, Sekhar
In-Reply-To: <20170818193947.27862-1-fcooper@ti.com>
On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:
> During test transmitting using CAN-FD at high bitrates (4 Mbps) only
> resulted in errors. Scoping the signals I noticed that only a single bit
> was being transmitted and with a bit more investigation realized the actual
> MCAN IP would go back to initialization mode automatically.
>
> It appears this issue is due to the MCAN needing to use the Transmitter
> Delay Compensation Mode as defined in the MCAN User's Guide. When this
> mode is used the User's Guide indicates that the Transmitter Delay
> Compensation Offset register should be set. The document mentions that this
> register should be set to (1/dbitrate)/2*(Func Clk Freq).
>
> Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
> that this TDC mode is only needed for data bit rates above 2.5 Mbps.
> Therefore, only enable this mode and only set TDCO when the data bit rate
> is above 2.5 Mbps.
>
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> ---
> I'm pretty surprised that this hasn't been implemented already since
> the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
> supports up to 10 Mbps.
>
> So it will be nice to get comments from users of this driver to understand
> if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
> If they haven't what did they do to get around it if they needed higher
> speeds.
>
> Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
> everything still works at 5 Mbps which is the max speed of my CAN
> transceiver.
ping. Anyone has any thoughts on this?
>
> drivers/net/can/m_can/m_can.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index f4947a7..720e073 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -126,6 +126,12 @@ enum m_can_mram_cfg {
> #define DBTP_DSJW_SHIFT 0
> #define DBTP_DSJW_MASK (0xf << DBTP_DSJW_SHIFT)
>
> +/* Transmitter Delay Compensation Register (TDCR) */
> +#define TDCR_TDCO_SHIFT 8
> +#define TDCR_TDCO_MASK (0x7F << TDCR_TDCO_SHIFT)
> +#define TDCR_TDCF_SHIFT 0
> +#define TDCR_TDCF_MASK (0x7F << TDCR_TDCO_SHIFT)
> +
> /* Test Register (TEST) */
> #define TEST_LBCK BIT(4)
>
> @@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)
> const struct can_bittiming *dbt = &priv->can.data_bittiming;
> u16 brp, sjw, tseg1, tseg2;
> u32 reg_btp;
> + u32 enable_tdc = 0;
> + u32 tdco;
>
> brp = bt->brp - 1;
> sjw = bt->sjw - 1;
> @@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
> sjw = dbt->sjw - 1;
> tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
> tseg2 = dbt->phase_seg2 - 1;
> +
> + /* TDC is only needed for bitrates beyond 2.5 MBit/s
> + * Specified in the "Bit Time Requirements for CAN FD" document
> + */
> + if (dbt->bitrate > 2500000) {
> + enable_tdc = DBTP_TDC;
> + /* Equation based on Bosch's M_CAN User Manual's
> + * Transmitter Delay Compensation Section
> + */
> + tdco = priv->can.clock.freq / (dbt->bitrate * 2);
> + m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
> + }
> +
> reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
> (tseg1 << DBTP_DTSEG1_SHIFT) |
> - (tseg2 << DBTP_DTSEG2_SHIFT);
> + (tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
> +
> m_can_write(priv, M_CAN_DBTP, reg_btp);
> }
>
>
^ permalink raw reply
* Re: [patch net] net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker
From: David Miller @ 2017-09-13 20:59 UTC (permalink / raw)
To: jiri; +Cc: netdev, jhs, xiyou.wangcong, kubakici, mlxsw
In-Reply-To: <20170913205006.GD1981@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 13 Sep 2017 22:50:06 +0200
> Wed, Sep 13, 2017 at 06:34:28PM CEST, davem@davemloft.net wrote:
>>From: Jiri Pirko <jiri@resnulli.us>
>>Date: Wed, 13 Sep 2017 17:32:37 +0200
>>
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed
>>> freeing in call_rcu, which changed already existing hard-to-hit
>>> race condition into 100% hit:
>>>
>>> [ 598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>>> [ 598.607782] IP: tcf_action_destroy+0xc0/0x140
>>>
>>> Or:
>>>
>>> [ 40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>>> [ 40.862840] IP: tcf_generic_walker+0x534/0x820
>>>
>>> Fix this by storing the ops and use them directly for module_put call.
>>>
>>> Fixes: a85a970af265 ("net_sched: move tc_action into tcf_common")
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>
>>Applied, thanks Jiri.
>
> Oh, I forgot to mention, this would be nice to push to stable.
Ok, queued up.
^ permalink raw reply
* [PATCH] net: Convert int functions to bool
From: Joe Perches @ 2017-09-13 20:58 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI; +Cc: netdev, linux-kernel
Global function ipv6_rcv_saddr_equal and static functions
ipv6_rcv_saddr_equal and ipv4_rcv_saddr_equal currently return int.
bool is slightly more descriptive for these functions so change
their return type from int to bool.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/net/addrconf.h | 4 ++--
net/ipv4/inet_connection_sock.c | 36 ++++++++++++++++++------------------
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index f44ff2476758..87981cd63180 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -94,8 +94,8 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct in6_addr *addr,
u32 banned_flags);
int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
u32 banned_flags);
-int inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
- bool match_wildcard);
+bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
+ bool match_wildcard);
void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr);
void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr *addr);
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4089c013cb03..054b26295638 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -39,11 +39,11 @@ EXPORT_SYMBOL(inet_csk_timer_bug_msg);
* IPV6_ADDR_ANY only equals to IPV6_ADDR_ANY,
* and 0.0.0.0 equals to 0.0.0.0 only
*/
-static int ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
- const struct in6_addr *sk2_rcv_saddr6,
- __be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
- bool sk1_ipv6only, bool sk2_ipv6only,
- bool match_wildcard)
+static bool ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
+ const struct in6_addr *sk2_rcv_saddr6,
+ __be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
+ bool sk1_ipv6only, bool sk2_ipv6only,
+ bool match_wildcard)
{
int addr_type = ipv6_addr_type(sk1_rcv_saddr6);
int addr_type2 = sk2_rcv_saddr6 ? ipv6_addr_type(sk2_rcv_saddr6) : IPV6_ADDR_MAPPED;
@@ -52,29 +52,29 @@ static int ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
if (addr_type == IPV6_ADDR_MAPPED && addr_type2 == IPV6_ADDR_MAPPED) {
if (!sk2_ipv6only) {
if (sk1_rcv_saddr == sk2_rcv_saddr)
- return 1;
+ return true;
if (!sk1_rcv_saddr || !sk2_rcv_saddr)
return match_wildcard;
}
- return 0;
+ return false;
}
if (addr_type == IPV6_ADDR_ANY && addr_type2 == IPV6_ADDR_ANY)
- return 1;
+ return true;
if (addr_type2 == IPV6_ADDR_ANY && match_wildcard &&
!(sk2_ipv6only && addr_type == IPV6_ADDR_MAPPED))
- return 1;
+ return true;
if (addr_type == IPV6_ADDR_ANY && match_wildcard &&
!(sk1_ipv6only && addr_type2 == IPV6_ADDR_MAPPED))
- return 1;
+ return true;
if (sk2_rcv_saddr6 &&
ipv6_addr_equal(sk1_rcv_saddr6, sk2_rcv_saddr6))
- return 1;
+ return true;
- return 0;
+ return false;
}
#endif
@@ -82,20 +82,20 @@ static int ipv6_rcv_saddr_equal(const struct in6_addr *sk1_rcv_saddr6,
* match_wildcard == false: addresses must be exactly the same, i.e.
* 0.0.0.0 only equals to 0.0.0.0
*/
-static int ipv4_rcv_saddr_equal(__be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
- bool sk2_ipv6only, bool match_wildcard)
+static bool ipv4_rcv_saddr_equal(__be32 sk1_rcv_saddr, __be32 sk2_rcv_saddr,
+ bool sk2_ipv6only, bool match_wildcard)
{
if (!sk2_ipv6only) {
if (sk1_rcv_saddr == sk2_rcv_saddr)
- return 1;
+ return true;
if (!sk1_rcv_saddr || !sk2_rcv_saddr)
return match_wildcard;
}
- return 0;
+ return false;
}
-int inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
- bool match_wildcard)
+bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
+ bool match_wildcard)
{
#if IS_ENABLED(CONFIG_IPV6)
if (sk->sk_family == AF_INET6)
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: [patch net] net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker
From: Jiri Pirko @ 2017-09-13 20:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jhs, xiyou.wangcong, kubakici, mlxsw
In-Reply-To: <20170913.093428.806129519464331602.davem@davemloft.net>
Wed, Sep 13, 2017 at 06:34:28PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 13 Sep 2017 17:32:37 +0200
>
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed
>> freeing in call_rcu, which changed already existing hard-to-hit
>> race condition into 100% hit:
>>
>> [ 598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>> [ 598.607782] IP: tcf_action_destroy+0xc0/0x140
>>
>> Or:
>>
>> [ 40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
>> [ 40.862840] IP: tcf_generic_walker+0x534/0x820
>>
>> Fix this by storing the ops and use them directly for module_put call.
>>
>> Fixes: a85a970af265 ("net_sched: move tc_action into tcf_common")
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>
>Applied, thanks Jiri.
Oh, I forgot to mention, this would be nice to push to stable.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: review Renesas DT bindings as well
From: David Miller @ 2017-09-13 20:41 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <20170913192913.138491844@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Wed, 13 Sep 2017 22:28:53 +0300
> When adding myself as a reviewer for the Renesas Ethernet drivers
> I somehow forgot about the bindings -- I want to review them as well.
>
> Fixes: 8e6569af3a1b ("MAINTAINERS: add myself as Renesas Ethernet drivers reviewer")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox