From: Yuchung Cheng
Date: Fri, 29 Jan 2016 15:11:50 -0800
> RFC 4015 section 3.4 says the TCP sender MUST refrain from
> reversing the congestion control state when the ACK signals
> congestion through the ECN-Echo flag. Currently we may not
> always do that when prior_ssthresh is reset upon rece
From: Rafał Miłecki
Date: Sat, 30 Jan 2016 00:41:07 +0100
> Chipsets with BCM4707 / BCM53018 ID require special handling at a few
> places in the code. It's likely there will be more IDs to check in the
> future. To simplify it add this trivial helper.
>
> Signed-off-by: Rafał Miłecki
The net-
From: Cong Wang
Date: Fri, 29 Jan 2016 11:58:03 -0800
> self->ctrl_skb is protected by self->spinlock, we should not
> access it out of the lock. Move the debugging printk inside.
>
> Reported-by: Dmitry Vyukov
> Cc: Samuel Ortiz
> Signed-off-by: Cong Wang
Applied, thanks.
From: Nikolay Aleksandrov
Date: Fri, 29 Jan 2016 22:48:26 +0100
> On 01/29/2016 10:45 PM, Jay Vosburgh wrote:
>> Nikolay Aleksandrov wrote:
>>
>>> On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
As subject says, 802.3ad bonding is not working with virtio network model.
The only error
On Fri, Jan 29, 2016 at 7:35 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 29 Jan 2016 19:23:54 -0800
>
>> On Fri, 2016-01-29 at 18:49 -0800, Alexander Duyck wrote:
>>> This patch fixes an issue with unaligned accesses when using
>>> eth_get_headlen on a page that was DMA aligned inst
From: Gregory CLEMENT
Date: Fri, 29 Jan 2016 17:26:06 +0100
> @@ -370,6 +370,8 @@ struct mvneta_port {
> struct net_device *dev;
> struct notifier_block cpu_notifier;
> int rxq_def;
> + /* protect */
> + spinlock_t lock;
>
> /* Core clock */
> struct clk *
From: Arnd Bergmann
Date: Fri, 29 Jan 2016 12:39:08 +0100
> This is an updated series of fixes for the network device drivers
> that showed warnings in ARM randconfig.
>
> Changes since v1 are:
>
> dropped "net: macb: avoid uninitialized variables", already fixed in net-next
>
> dropped "net:
From: Paolo Abeni
Date: Fri, 29 Jan 2016 12:30:18 +0100
> Currently:
>
> ip addr add dev eth0 2001:0010::1/64
> ip addr add dev eth1 2001:0020::1/64
> ping6 -I eth0 2001:0020::2
>
> do not lead to the expected results, i.e. eth1 is used as the
> egress interface.
>
> This is due to two related
From: Kalle Valo
Date: Fri, 29 Jan 2016 10:47:19 +0200
> few fixes for 4.5. Nothing really standing out, see the tag for
> more info. Please let me know if you have any problems.
Pulled, thanks Kalle.
From: Ken-ichirou MATSUZAWA
Date: Fri, 29 Jan 2016 10:45:50 +0900
> We should not trim skb for mmaped socket since its buf size is fixed
> and userspace will read as frame which data equals head. mmaped
> socket will not call recvmsg, means max_recvmsg_len is 0,
> skb_reserve was not called befor
On Sat, Jan 30, 2016 at 12:44:24AM +0100, Jiri Bohac wrote:
>
> Is there a situation when xfrm_output_gso() does the right thing?
Yes because you've just broken TSO over IPsec.
In fact you're remarkably close to the right solution which is
to avoid xfrm_output_gso for SKB_GSO_UDP packets.
You sh
From: roy.qing...@gmail.com
Date: Fri, 29 Jan 2016 09:43:47 +0800
> From: Li RongQing
>
> The size of all_zeros_mac is 6 byte, but eth_hash() will access the
> 8 byte, and KASan reported the below bug:
...
> it can be fixed by enlarging the all_zeros_mac to 8 byte, although it is
> harmless; et
From: Jay Vosburgh
Date: Thu, 28 Jan 2016 17:33:08 -0800
> + else if (curr_arp_slave && (arp->ar_op == htons(ARPOP_REPLY)) &&
> + bond_time_in_interval(bond,
> +dev_trans_start(curr_arp_slave->dev), 1))
> + bond_validate_arp(bond, s
On Fri, Jan 29, 2016 at 11:42 AM, Marcelo Ricardo Leitner
wrote:
> On Fri, Jan 29, 2016 at 11:15:54AM -0800, Alexander Duyck wrote:
>> On Wed, Jan 27, 2016 at 9:06 AM, Marcelo Ricardo Leitner
>> wrote:
>> > This patch enables SCTP to do GSO.
>> >
>> > SCTP has this pecualiarty that its packets ca
From: Vivien Didelot
Date: Thu, 28 Jan 2016 16:54:37 -0500
> Currently the port based VLAN maps should be configured to allow every
> port to egress frames on all other ports, except themselves.
>
> The debugfs interface shows that they are misconfigured. For instance, a
> 7-port switch has the
From: Alexander Duyck
Date: Thu, 28 Jan 2016 13:42:24 -0800
> The fib_table_lookup function had a shift by 32 that triggered a UBSAN
> warning. This was due to the fact that I had placed the shift first and
> then followed it with the check for the suffix length to ignore the
> undefined behavio
From: Arnd Bergmann
Date: Thu, 28 Jan 2016 17:54:33 +0100
> The moxart ethernet driver confuses coherent DMA buffers with
> MMIO registers.
>
> moxart_ether.c: In function 'moxart_mac_setup_desc_ring':
> moxart_ether.c:146:428: error: passing argument 1 of '__fswab32' makes
> integer from point
From: Arnd Bergmann
Date: Thu, 28 Jan 2016 17:39:24 +0100
> When CONFIG_PROC_FS, CONFIG_IP_PNP_BOOTP, CONFIG_IP_PNP_DHCP and
> CONFIG_IP_PNP_RARP are all disabled, we get a warning about the
> ic_proto_used variable being unused:
>
> net/ipv4/ipconfig.c:146:12: error: 'ic_proto_used' defined but
From: Jarod Wilson
Date: Thu, 28 Jan 2016 10:49:44 -0500
> The network core tries to keep track of dropped packets, but some packets
> you wouldn't really call dropped, so much as intentionally ignored, under
> certain circumstances. One such case is that of bonding and team device
> slaves that
From: Eric Dumazet
Date: Fri, 29 Jan 2016 19:23:54 -0800
> On Fri, 2016-01-29 at 18:49 -0800, Alexander Duyck wrote:
>> This patch fixes an issue with unaligned accesses when using
>> eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
>> The fact is when trying to check t
On Fri, 2016-01-29 at 18:49 -0800, Alexander Duyck wrote:
> This patch fixes an issue with unaligned accesses when using
> eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
> The fact is when trying to check the length we don't need to be looking at
> the flow label so we
This patch fixes an issue with unaligned accesses when using
eth_get_headlen on a page that was DMA aligned instead of being IP aligned.
The fact is when trying to check the length we don't need to be looking at
the flow label so we can reorder the checks to first check if we are
supposed to gather
On Fri, 2016-01-29 at 16:47 -0800, Tom Herbert wrote:
> Hmm, thanks for pointing that out. It looks like this is called by a
> couple drivers as part of pulling up the data to get alignment. I am
> actually surprised they are doing this. Flow dissector is not the
> cheapest function in the world a
From: Gregory Herrero
Date: Thu, 28 Jan 2016 09:34:52 +0100
> @@ -2302,8 +2302,11 @@ static void manage_tempaddrs(struct inet6_dev *idev,
> ift->flags &= ~IFA_F_DEPRECATED;
>
> spin_unlock(&ift->lock);
> - if (!(flags&IFA_F_TENTATIVE))
> +
From: Michael Chan
Date: Thu, 28 Jan 2016 03:11:19 -0500
> 3 small bug fix patches for net.
Series applied, thanks Michael.
From: Bernie Harris
Date: Thu, 28 Jan 2016 16:30:51 +1300
> There are cases where qdisc_dequeue_peeked can return NULL, and the result
> is dereferenced later on in the function.
>
> Similarly to the other qdisc dequeue functions, check whether the skb
> pointer is NULL and if it is, goto out.
>
From: Tom Herbert
Date: Fri, 29 Jan 2016 16:47:46 -0800
> Seems like it might be just as well to pull up a fixed number of
> bytes (ixgbe want min of 60 bytes),
This is precisely what we were trying to move away from, please
don't regress back to that.
On Fri, Jan 29, 2016 at 3:58 PM, Sowmini Varadhan
wrote:
> On (01/29/16 15:31), Tom Herbert wrote:
>> But even within flow dissector, to be completely correct, we need to
>> replace all 32-bit accesses with the mempy (flow_label, mpls label,
>> keyid) and be vigilant about new ones coming in. For
On (01/29/16 15:31), Tom Herbert wrote:
> But even within flow dissector, to be completely correct, we need to
> replace all 32-bit accesses with the mempy (flow_label, mpls label,
> keyid) and be vigilant about new ones coming in. For that matter, ..
well, one question that came to my mind when I
Hi,
I'm seeing wrong fragmentation on locally generated UDPv6 packets
going out over ESP (transport mode):
UFO is turned on on the outgoing interface and MTU is 1500.
When 8 kB is written to a UDP socket, udpv6_sendmsg() calls
ip_append_data() which generates a single 8 kB GSO skb.
Through ip6_s
Chipsets with BCM4707 / BCM53018 ID require special handling at a few
places in the code. It's likely there will be more IDs to check in the
future. To simplify it add this trivial helper.
Signed-off-by: Rafał Miłecki
---
drivers/net/ethernet/broadcom/bgmac.c | 30 --
On Fri, Jan 29, 2016 at 3:04 PM, Sowmini Varadhan
wrote:
> On (01/29/16 15:00), Tom Herbert wrote:
>
>> The sparc documentation is pretty clear
>> http://docs.oracle.com/cd/E19253-01/816-4854/hwovr-2/index.html, seems
>> like unaligned accesses are not allowed in the architecture.
>
> yes, but loo
RFC 4015 section 3.4 says the TCP sender MUST refrain from
reversing the congestion control state when the ACK signals
congestion through the ECN-Echo flag. Currently we may not
always do that when prior_ssthresh is reset upon receiving
ACKs with ECE marks. This patch fixes that.
Signed-off-by: Yu
On (01/29/16 15:00), Tom Herbert wrote:
> The sparc documentation is pretty clear
> http://docs.oracle.com/cd/E19253-01/816-4854/hwovr-2/index.html, seems
> like unaligned accesses are not allowed in the architecture.
yes, but looks like you can paper over some of this with
memcpy (as was happen
On Fri, Jan 29, 2016 at 1:09 PM, Sowmini Varadhan
wrote:
> On (01/29/16 13:00), Tom Herbert wrote:
>> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't
>> those create alignment issues (like when stack looks at addresses)?
>
> They do.
>
> http://comments.gmane.org/gmane.linux.ne
On Fri, Jan 29, 2016 at 2:28 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 14:08 -0800, Alexander Duyck wrote:
>
>> It also means DMA becomes dramatically slower as it introduces a
>> partial write access for the start of every frame. It is why we had
>> set NET_IP_ALIGN to 0 on x86 since DMA w
On 01/27/2016 10:56 PM, David Miller wrote:
From: tndave
Date: Wed, 27 Jan 2016 17:50:14 -0800
Hi,
i40e driver has 'struct i40e_dma_mem' defined with 'packed' directive
causing kernel unaligned errors on sparc (when
40e_allocate_dma_mem_d()
is being called)
log_unaligned: 1031 callbacks su
On Fri, 2016-01-29 at 14:17 -0800, Cong Wang wrote:
> Because we have to fix all the cases that don't
Sure, lets do that without removing the optimizations.
macvlan control path seems to need a fix, as you pointed out.
On Fri, 2016-01-29 at 14:08 -0800, Alexander Duyck wrote:
> It also means DMA becomes dramatically slower as it introduces a
> partial write access for the start of every frame. It is why we had
> set NET_IP_ALIGN to 0 on x86 since DMA was becoming more expensive
> when unaligned then reading IP
On Fri, Jan 29, 2016 at 2:01 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 13:41 -0800, Cong Wang wrote:
>> On Thu, Jan 28, 2016 at 5:43 PM, wrote:
>> > From: Li RongQing
>> >
>> > The size of all_zeros_mac is 6 byte, but eth_hash() will access the
>> > 8 byte, and KASan reported the below bu
The Intel i211 LOM pcie ethernet controllers' iNVM operates as an OTP
and has no externel EEPROM interface [1]. The following allows the
driver to pickup the MAC address from a device tree blob when CONFIG_OF
has been enabled.
[1]
http://www.intel.com/content/www/us/en/embedded/products/netwo
On Fri, Jan 29, 2016 at 1:33 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 13:16 -0800, Alexander Duyck wrote:
>
>> It has to be something recent. I know back when I wrote the code I
>> tested it on a few different architectures and had to add a few bits
>> in __skb_get_poff so that it would re
Hi Cong
On Sat, Jan 30, 2016 at 6:46 AM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 11:24 -0800, Cong Wang wrote:
>> These two functions are called in sendmsg path, and the
>> 'len' is passed from user-space, so we should not allow
>> malicious users to OOM kernel on purpose.
>>
>> Reported-by:
On Fri, 2016-01-29 at 13:41 -0800, Cong Wang wrote:
> On Thu, Jan 28, 2016 at 5:43 PM, wrote:
> > From: Li RongQing
> >
> > The size of all_zeros_mac is 6 byte, but eth_hash() will access the
> > 8 byte, and KASan reported the below bug:
>
>
> Sounds like we should fix eth_hash() (macvlan has
On 01/29/2016 10:45 PM, Jay Vosburgh wrote:
> Nikolay Aleksandrov wrote:
>
>> On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
>>> As subject says, 802.3ad bonding is not working with virtio network model.
>>>
>>> The only errors I see is:
>>>
>>> No 802.3ad response from the link partner for any adap
Nikolay Aleksandrov wrote:
>On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
>> As subject says, 802.3ad bonding is not working with virtio network model.
>>
>> The only errors I see is:
>>
>> No 802.3ad response from the link partner for any adapters in the bond.
>>
>> Dumping the network traffic
On Thu, Jan 28, 2016 at 5:43 PM, wrote:
> From: Li RongQing
>
> The size of all_zeros_mac is 6 byte, but eth_hash() will access the
> 8 byte, and KASan reported the below bug:
Sounds like we should fix eth_hash() (macvlan has a same function),
it should not read beyond 6 bytes.
On Fri, 2016-01-29 at 13:16 -0800, Alexander Duyck wrote:
> It has to be something recent. I know back when I wrote the code I
> tested it on a few different architectures and had to add a few bits
> in __skb_get_poff so that it would read doff as a u8 instead of
> bitfield in a u32.
>
> Looking
On Fri, Jan 29, 2016 at 1:09 PM, Sowmini Varadhan
wrote:
> On (01/29/16 13:00), Tom Herbert wrote:
>> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't
>> those create alignment issues (like when stack looks at addresses)?
>
> They do.
>
> http://comments.gmane.org/gmane.linux.ne
On 01/25/2016 05:24 PM, Bjørnar Ness wrote:
> As subject says, 802.3ad bonding is not working with virtio network model.
>
> The only errors I see is:
>
> No 802.3ad response from the link partner for any adapters in the bond.
>
> Dumping the network traffic shows that no LACP packets are sent f
On Fri, Jan 29, 2016 at 12:01 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 14:44 -0500, Sowmini Varadhan wrote:
>> On (01/29/16 11:37), Eric Dumazet wrote:
>> >
>> > I have no idea why reading iph->saddr or iph->daddr would not hit the
>> > problem, but accessing the 32bit ipv6 flow label would
On (01/29/16 13:00), Tom Herbert wrote:
> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't
> those create alignment issues (like when stack looks at addresses)?
They do.
http://comments.gmane.org/gmane.linux.network/370672
some of it was fixed in https://lkml.org/lkml/2015/7/2
On Fri, Jan 29, 2016 at 10:54 AM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 10:33 -0800, Eric Dumazet wrote:
>> On Fri, 2016-01-29 at 13:06 -0500, Sowmini Varadhan wrote:
>> > There is an unaligned access at __skb_flow_dissect when it calls
>> > ip6_flowlabel() with the call stack
>> >
>> > __
On Fri, 2016-01-29 at 12:24 -0800, David Miller wrote:
>
> This should be fixed now, thanks for letting me know.
Perfect, thanks !
From: Kefeng Wang
Date: Thu, 28 Jan 2016 10:27:19 +0800
> Convert the driver to use ns_to_timespec64() and timespec64_to_ns()
> instead of open coding the same logic.
>
> Signed-off-by: Kefeng Wang
Applied, thanks.
Rob Herring wrote:
The emac is present on a lot of Qualcomm SOCs, and there are only a few
variations of it. It's not really SOC-specific, and the hardware version
can be queried by the driver.
Can the integration bugs be queried, too?
Come on, you know how compatible strings work.
Fine. I
From: Eric Dumazet
Date: Fri, 29 Jan 2016 07:22:06 -0800
> On Wed, 2016-01-27 at 17:02 -0500, David Miller wrote:
>> From: Eric Dumazet
>> Date: Tue, 26 Jan 2016 16:59:42 -0800
>>
>> > From: Eric Dumazet
>> >
>> > We should not assume a valid protocol header is present,
>> > as this is not th
From: Jörg Thalheim
Date: Wed, 27 Jan 2016 22:54:06 +0100
> Signed-off-by: Jörg Thalheim
Applied, thanks.
On Fri, Jan 29, 2016 at 12:22 PM, Timur Tabi wrote:
> Gilad is no longer working for Qualcomm, so I'm taking over (as best as I
> can) this driver. Let's just say it's going to be a learning experience.
Lucky you.
> Rob Herring wrote:
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/q
From: Nikolay Aleksandrov
Date: Wed, 27 Jan 2016 17:50:43 +0100
> From: Nikolay Aleksandrov
>
> Currently when a macvlan is being initialized and the lower device is
> netif_carrier_ok(), the macvlan device doesn't run through
> rfc2863_policy() and is left with UNKNOWN operstate. Fix it by add
On Fri, 2016-01-29 at 12:01 -0800, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 14:44 -0500, Sowmini Varadhan wrote:
> > On (01/29/16 11:37), Eric Dumazet wrote:
> > >
> > > I have no idea why reading iph->saddr or iph->daddr would not hit the
> > > problem, but accessing the 32bit ipv6 flow label
On Fri, Jan 29, 2016 at 11:42 AM, Larry Finger
wrote:
>
> Thanks for testing.
>
> Upon reflection, it really should check the other WIRELESS_MODE_AC_x bits.
> Johannes' patch was indeed correct.
I just retested with this incremental (and whitespace-damaged) patch:
@@ -139,7 +139,9 @@ static vo
On Fri, 2016-01-29 at 14:44 -0500, Sowmini Varadhan wrote:
> On (01/29/16 11:37), Eric Dumazet wrote:
> >
> > I have no idea why reading iph->saddr or iph->daddr would not hit the
> > problem, but accessing the 32bit ipv6 flow label would be an issue.
> >
> > Something is fishy.
>
> I was wonder
self->ctrl_skb is protected by self->spinlock, we should not
access it out of the lock. Move the debugging printk inside.
Reported-by: Dmitry Vyukov
Cc: Samuel Ortiz
Signed-off-by: Cong Wang
---
net/irda/ircomm/ircomm_param.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Fri, 2016-01-29 at 11:24 -0800, Cong Wang wrote:
> These two functions are called in sendmsg path, and the
> 'len' is passed from user-space, so we should not allow
> malicious users to OOM kernel on purpose.
>
> Reported-by: Dmitry Vyukov
> Cc: Lauro Ramos Venancio
> Cc: Aloisio Almeida Jr
On (01/29/16 11:37), Eric Dumazet wrote:
>
> I have no idea why reading iph->saddr or iph->daddr would not hit the
> problem, but accessing the 32bit ipv6 flow label would be an issue.
>
> Something is fishy.
I was wondering about this myself. Even on sparc, I only first
ran into the errors for
On 01/29/2016 12:39 PM, Linus Torvalds wrote:
On Fri, Jan 29, 2016 at 9:54 AM, Larry Finger wrote:
The test patch that Johannes sent earlier was close. The section needed to
add VHT rates is:
Hmm. This looks pretty much exactly like what I already tried (I had
fixed Johannes' patch to use "v
On Fri, Jan 29, 2016 at 11:15:54AM -0800, Alexander Duyck wrote:
> On Wed, Jan 27, 2016 at 9:06 AM, Marcelo Ricardo Leitner
> wrote:
> > This patch enables SCTP to do GSO.
> >
> > SCTP has this pecualiarty that its packets cannot be just segmented to
> > (P)MTU. Its chunks must be contained in IP
From: Eric Dumazet
Date: Fri, 29 Jan 2016 11:37:30 -0800
> But really adding unaligned() accesses in flow dissector would slow it
> quite a lot on MIPS and others.
Agreed, the fix definitely belongs in the callers of these interfaces,
which in this case is the driver.
On Fri, 2016-01-29 at 11:08 -0800, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 29 Jan 2016 10:40:10 -0800
>
> > I would try following ixgbe fix (sorry, totally untested, but you get
> > the idea...)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > b/drivers/net/e
llcp_sock_getname() checks llcp_sock->dev to make sure
llcp_sock is already connected or bound, however, we could
be in the middle of llcp_sock_bind() where llcp_sock->dev
is bound and llcp_sock->service_name_len is set,
but llcp_sock->service_name is not, in this case we would
lead to copy some by
On Fri, 2016-01-29 at 11:06 -0800, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 29 Jan 2016 10:33:48 -0800
>
> > Why ipv6 stack itself does not trigger the issue ?
> >
> > Maybe the driver itself does not properly align IP headers on sparc ?
> >
> > Make sure NET_IP_ALIGN is 2 on your
These two functions are called in sendmsg path, and the
'len' is passed from user-space, so we should not allow
malicious users to OOM kernel on purpose.
Reported-by: Dmitry Vyukov
Cc: Lauro Ramos Venancio
Cc: Aloisio Almeida Jr
Cc: Samuel Ortiz
Signed-off-by: Cong Wang
---
net/nfc/llcp_comm
On (01/29/16 10:54), Eric Dumazet wrote:
> > Why ipv6 stack itself does not trigger the issue ?
> > Maybe the driver itself does not properly align IP headers on sparc ?
> > Make sure NET_IP_ALIGN is 2 on your build.
> > Note that x86 does not care, but a driver should always align Ethernet
> > hea
On Wed, Jan 27, 2016 at 9:06 AM, Marcelo Ricardo Leitner
wrote:
> This patch enables SCTP to do GSO.
>
> SCTP has this pecualiarty that its packets cannot be just segmented to
> (P)MTU. Its chunks must be contained in IP segments, padding respected.
> So we can't just generate a big skb, set gso_s
From: Eric Dumazet
Date: Fri, 29 Jan 2016 10:40:10 -0800
> I would try following ixgbe fix (sorry, totally untested, but you get
> the idea...)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index c4003a88bbf6..7ba64ed463a6 100
From: Eric Dumazet
Date: Fri, 29 Jan 2016 10:33:48 -0800
> Why ipv6 stack itself does not trigger the issue ?
>
> Maybe the driver itself does not properly align IP headers on sparc ?
>
> Make sure NET_IP_ALIGN is 2 on your build.
>
> Note that x86 does not care, but a driver should always ali
From: Sowmini Varadhan
Date: Fri, 29 Jan 2016 13:06:51 -0500
> @@ -102,6 +102,17 @@ __be32 __skb_flow_get_ports(const struct sk_buff *skb,
> int
> }
> EXPORT_SYMBOL(__skb_flow_get_ports);
>
> +static inline __be32 ip6_flowlabel_align(const u8 *hdr)
> +{
> + union {
> + _
On Fri, 2016-01-29 at 10:33 -0800, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 13:06 -0500, Sowmini Varadhan wrote:
> > There is an unaligned access at __skb_flow_dissect when it calls
> > ip6_flowlabel() with the call stack
> >
> > __skb_flow_dissect+0x2a8/0x87c
> > eth_get_headlen+0x5c/0xaxa
On Fri, Jan 29, 2016 at 03:51:52PM +, David Laight wrote:
> From: 'Marcelo Ricardo Leitner'
> > Sent: 28 January 2016 20:56
> > On Thu, Jan 28, 2016 at 05:30:24PM +, David Laight wrote:
> > > From: 'Marcelo Ricardo Leitner'
> > > > Sent: 28 January 2016 15:53
> > > > On Thu, Jan 28, 2016 at
On Fri, 2016-01-29 at 10:33 -0800, Eric Dumazet wrote:
>
> Why ipv6 stack itself does not trigger the issue ?
>
> Maybe the driver itself does not properly align IP headers on sparc ?
>
> Make sure NET_IP_ALIGN is 2 on your build.
>
> Note that x86 does not care, but a driver should always ali
On Fri, Jan 29, 2016 at 9:54 AM, Larry Finger wrote:
>
> The test patch that Johannes sent earlier was close. The section needed to
> add VHT rates is:
Hmm. This looks pretty much exactly like what I already tried (I had
fixed Johannes' patch to use "vht_cap" already, since it didn't
compile othe
Hi Florian,
thanks for your review!
On mer., janv. 27 2016, Florian Fainelli wrote:
> On 12/01/16 11:10, Gregory CLEMENT wrote:
>> This basic implementation allows to share code between driver using
>> hardware buffer management. As the code is hardware agnostic, there is
>> few helpers, most
On Fri, 2016-01-29 at 13:06 -0500, Sowmini Varadhan wrote:
> There is an unaligned access at __skb_flow_dissect when it calls
> ip6_flowlabel() with the call stack
>
> __skb_flow_dissect+0x2a8/0x87c
> eth_get_headlen+0x5c/0xaxa4
> ixgbe_clean_rx_irq+0x5cc/0xb20 [ixgbe]
> ixgbe_poll+0x5a4/0
Gilad is no longer working for Qualcomm, so I'm taking over (as best as
I can) this driver. Let's just say it's going to be a learning experience.
Rob Herring wrote:
diff --git a/Documentation/devicetree/bindings/net/qcom-emac.txt
b/Documentation/devicetree/bindings/net/qcom-emac.txt
new file
On Wed, Jan 27, 2016 at 1:05 PM, Eric Dumazet wrote:
> On Wed, 2016-01-27 at 11:50 -0800, Cong Wang wrote:
>
>> Hmm? I think nfc_llcp_send_ui_frame() needs to do some fragmention
>> with this temporary memory, or you are saying msg_iter has some
>> API available to seek the pointer? Even if so, it
On Wed, Jan 27, 2016 at 7:30 PM, Bernie Harris
wrote:
> There are cases where qdisc_dequeue_peeked can return NULL, and the result
> is dereferenced later on in the function.
>
> Similarly to the other qdisc dequeue functions, check whether the skb
> pointer is NULL and if it is, goto out.
>
> Sig
There is an unaligned access at __skb_flow_dissect when it calls
ip6_flowlabel() with the call stack
__skb_flow_dissect+0x2a8/0x87c
eth_get_headlen+0x5c/0xaxa4
ixgbe_clean_rx_irq+0x5cc/0xb20 [ixgbe]
ixgbe_poll+0x5a4/0x760 [ixgbe]
net_rx_action+0x13c/0x354
:
Essentially, ixgbe_pull_
Linus,
Attached is a trial patch that fixes the problem on my system. As I told
Johannes earlier, my AP was not configured to use VHT, thus I did not see the
problem.
The test patch that Johannes sent earlier was close. The section needed to add
VHT rates is:
--- a/drivers/net/wireless/rea
On 1/28/2016 3:02 PM, Arnd Bergmann wrote:
> On Thursday 28 January 2016 14:25:32 Troy Kisky wrote:
>> Signed-off-by: Troy Kisky
>> ---
>> drivers/net/ethernet/freescale/fec_main.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> [note: missing changelog?]
>
>> diff --git a/driv
On 2016-01-25 10:29:33, Herbert Xu wrote:
> On Sun, Jan 24, 2016 at 07:10:50PM +0100, Julia Lawall wrote:
> > Maybe the goto on line 1726 needs a preceding mutex_unlock?
>
> Good catch! Thanks.
>
> ---8<---
> This patch replaces uses of ablkcipher and blkcipher with skcipher,
> and the long obsol
On 01/29/2016 10:15 AM, Johannes Berg wrote:
On Fri, 2016-01-29 at 10:12 -0600, Larry Finger wrote:
Upon further inspection, my log has the line "rtl8821ae :02:00.0
wlp2s0: disabling HT/VHT due to WEP/TKIP use". I need to fix that
first.
Likely TKIP; enable only WPA2 (CCMP) on the AP.
I
Hi Eric,
Thanks for the review.
On Fri, Jan 29, 2016 at 08:29:55AM -0600, Eric W. Biederman wrote:
> Tycho Andersen writes:
>
> > Operations with the GENL_ADMIN_PERM flag fail permissions checks because
> > this flag means we call netlink_capable, which uses the init user ns.
> >
> > Instead, l
Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
each CPU") all the percpu irq are used and unmask at initialization, so
there is no point to unmask them first.
Signed-off-by: Gregory CLEMENT
---
drivers/net/ethernet/marvell/mvneta.c | 8
1 file changed, 8 deletions
Instead of using a for_each_* loop in which we just call the
smp_call_function_single macro, it is more simple to directly use the
on_each_cpu macro. Moreover, this macro ensures that the calls will be
done all at once.
Suggested-by: Russell King
Signed-off-by: Gregory CLEMENT
---
drivers/net/e
Electing a CPU must be done in an atomic way: it should be done after or
before the removal/insertion of a CPU and this function is not reentrant.
During the loop of mvneta_percpu_elect we associates the queues to the
CPUs, if there is a topology change during this loop, then the mapping
between t
Hi,
Following this bug report:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173 and the
suggestions from Russell King, I reviewed all the code involving
multi-CPU. It ended with this series of patches which should improve
the stability of the driver.
The first patch fix a real bug, the
When stopping the port, the CPU notifier are still there whereas the
mvneta_stop_dev function calls mvneta_percpu_disable() on each CPUs.
It was possible to have a new CPU coming at this point which could be
racy.
This patch adds a flag preventing executing the code notifier for a new CPU
when the
In the MVNETA_INTR_* registers, the queues related fields are per cpu,
according to the datasheet (comment in [] are added by me):
"In a multi-CPU system, bits of RX[or TX] queues for which the access by
the reading[or writing] CPU is disabled are read as 0, and cannot be
cleared[or written]."
Tha
This patch convert the for_each_present in on_each_cpu, instead of
applying on the present cpus it will be applied only on the online cpus.
This fix a bug reported on
http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173.
Using the macro on_each_cpu (instead of a for_each_* loop) also ensure
1 - 100 of 136 matches
Mail list logo
