This series contains some minor updates for rmnet driver.
Patch 1 contains fixes for sparse warnings.
Patch 2 updates the copyright date to 2018.
Patch 3 is a cleanup in receive path.
Patch 4 has the implementation of the fill_info operation.
Subash Abhinov Kasiviswanathan (4):
net: qualcomm: r
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.h | 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c| 2 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.h
This is needed to query the mux_id and flags of a rmnet device.
Signed-off-by: Subash Abhinov Kasiviswanathan
---
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c
b/d
Return error code -EINVAL in the address len check error handling
case since 'err' can be overwrite to 0 by 'err = sctp_verify_addr()'
in the for loop.
Fixes: 2c0dbaa0c43d ("sctp: add support for SCTP_DSTADDRV4/6 Information for
sendmsg")
Signed-off-by: Wei Yongjun
Acked-by: Neil Horman
---
v1
On Monday 12 March 2018 10:59 PM, Richard Weinberger wrote:
On Mon, Mar 12, 2018 at 5:27 PM, arvindY wrote:
On Monday 12 March 2018 08:13 PM, David Miller wrote:
From: Arvind Yadav
Date: Fri, 9 Mar 2018 16:11:17 +0530
if device_register() returned an error! Always use put_device()
to gi
In preparation to enabling -Wvla, remove VLA and replace it
with dynamic memory allocation.
>From a security viewpoint, the use of Variable Length Arrays can be
a vector for stack overflow attacks. Also, in general, as the code
evolves it is easy to lose track of how big a VLA can get. Thus, we
ca
Hi Brad,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Brad-Mouring/net-macb-Reorganize-macb_mii-bringup
On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
wrote:
> On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> wrote:
>>
>> Replacing the __builtin_choose_expr() with ?: works of course.
>
> Hmm. That sounds like the right thing to do. We were so myopically
> staring at the __builtin_choose_expr() pro
On Mon, 12 Mar 2018 09:56:30 -0700, Jeff Kirsher wrote:
> On Fri, 2018-03-09 at 14:16 -0800, Jakub Kicinski wrote:
> > On Fri, 9 Mar 2018 09:21:22 -0800, Anirudh Venkataramanan wrote:
> > > diff --git a/Documentation/networking/ice.txt
> > > b/Documentation/networking/ice.txt
> > > new file mode
On Mon, Mar 12, 2018 at 4:17 PM, Cong Wang wrote:
> On Sun, Mar 11, 2018 at 12:22 PM, Josh Elsasser wrote:
>> init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
>> to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
>> wireless adapter and checks napi->dev->
V2: just check napi->dev->netdev_ops instead of getting clever with the
netdev registration state.
Original cover letter:
Hi Dave,
I stumbled across a reproducible kernel panic while playing around with
busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction
between init_dummy_net
init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
Avoid this by ensuring napi->dev->netdev_ops is valid before following
the pointer, avoidi
Hi,
One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
net-next function skb_segment, line 3667.
3472 struct sk_buff *skb_segment(struct sk_buff *head_skb,
3473 netdev_features_t features)
3474 {
3475 struct sk_buff *segs = NULL;
3476
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, March 12, 2018 4:37 PM
> To: Razvan Stefanescu
> Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; netdev@vger.kernel.org; Alexander Graf
> ; a...@arndb.de; Alexand
On 03/12/2018 10:32 PM, Josh Elsasser wrote:
init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
Avoid this by ensuring napi->dev->netdev_
When we have a bridge with vlan_filtering on and a vlan device on top of
it, packets would be corrupted in skb_vlan_untag() called from
br_dev_xmit().
The problem sits in skb_reorder_vlan_header() used in skb_vlan_untag(),
which makes use of skb->mac_len. In this function mac_len is meant for
hand
On 03/12/2018 10:45 PM, Yonghong Song wrote:
Hi,
One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
net-next function skb_segment, line 3667.
3472 struct sk_buff *skb_segment(struct sk_buff *head_skb,
3473 netdev_features_t features)
3474 {
3475
On 3/12/18 11:04 PM, Eric Dumazet wrote:
On 03/12/2018 10:45 PM, Yonghong Song wrote:
Hi,
One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
net-next function skb_segment, line 3667.
3472 struct sk_buff *skb_segment(struct sk_buff *head_skb,
3473
Hi all,
After merging the net-next tree, today's linux-next build (sparc
defconfig) produced this warning:
net/core/pktgen.c: In function 'pktgen_if_write':
net/core/pktgen.c:1710:1: warning: the frame size of 1048 bytes is larger than
1024 bytes [-Wframe-larger-than=]
}
^
Introduced by commi
Hi, Song
On 2018/3/13 13:45, Yonghong Song wrote:
> Hi,
>
> One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
> net-next function skb_segment, line 3667.
>
> 3472 struct sk_buff *skb_segment(struct sk_buff *head_skb,
> 3473 netdev_features_t feature
On 03/13/2018 12:01 AM, Stephen Hemminger wrote:
On Mon, 12 Mar 2018 23:42:48 +0100
Rafał Miłecki wrote:
2) Blame bridge + mcast-to-ucast + hairpin for 802.11f incompatibility
If we agree that 802.11f support in FullMAC firmware is acceptable, then
we have to make sure Linux's bridge doesn't
On 03/12/2018 11:08 PM, Yonghong Song wrote:
On 3/12/18 11:04 PM, Eric Dumazet wrote:
On 03/12/2018 10:45 PM, Yonghong Song wrote:
Hi,
One of our in-house projects, bpf-based NAT, hits a kernel BUG_ON at
net-next function skb_segment, line 3667.
3472 struct sk_buff *skb_segment(struct s
With reorder header off, received packets are untagged in skb_vlan_untag()
called from within __netif_receive_skb_core(), and later the tag will be
inserted back in vlan_do_receive().
This caused out of order vlan headers when we create a vlan device on top
of another vlan device, because vlan_do_
As Brandon Carpenter reported[1], sending non-vlan-offloaded packets from
bridge devices ends up with corrupted packets. He narrowed down this problem
and found that the root cause is in skb_reorder_vlan_header().
While I was working on fixing this problem, I found that the function does
not work
On Wed, Mar 07, 2018 at 02:42:53PM -0800, Greg Hackmann wrote:
> f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
> __this_cpu_read() call inside ipcomp_alloc_tfms().
>
> At the time, __this_cpu_read() required the caller to either not care
> about races or to handle preempti
On Tue, Mar 13, 2018 at 11:03 AM, Wei Yongjun wrote:
> Return error code -EINVAL in the address len check error handling
> case since 'err' can be overwrite to 0 by 'err = sctp_verify_addr()'
> in the for loop.
>
> Fixes: 2c0dbaa0c43d ("sctp: add support for SCTP_DSTADDRV4/6 Information for
> sen
301 - 326 of 326 matches
Mail list logo
