Hi
When implement multiproc support on network modules or template to
migrate all modules on multiproc task?
On Thu, 2016-01-28 at 19:54 -0600, Larry Finger wrote:
>
> I have been running an RTL8821AE since kernel 3.18 without hitting
> this problem
> using a TRENDnet AC1750 dual-band AP. The UniFi may be doing
> something that the
> driver is not expecting.
Are you quite sure you're actually using VH
Patch fixes this splat
BUG: KASAN: slab-out-of-bounds in minstrel_ht_update_stats.isra.7+0x6e1/0x9e0
[mac80211] at addr 8800cee640f4 Read of size 4 by task swapper/3/0
Signed-off-by: Konstantin Khlebnikov
Link:
http://lkml.kernel.org/r/calygninyjhsavne35qs6ucgasb2dx1_i5hcravuox14otz2...@mai
Hi Dave,
few fixes for 4.5. Nothing really standing out, see the tag for
more info. Please let me know if you have any problems.
Kalle
The following changes since commit a200dcb34693084e56496960d855afdeaaf9578f:
Merge tag 'for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
> wlcore_read/wlcore_write can return negative values so it should
> be assigned to signed variable.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2120705
>
>
On error we jumped to the error label and returned the error code but we
missed releasing sinfo.
Signed-off-by: Sudip Mukherjee
---
net/mac80211/sta_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 6c198e6..36e75c4 100644
--- a/ne
> On 29 Jan 2016, at 02:18, Marcelo Ricardo Leitner
> wrote:
>
> On Fri, Jan 29, 2016 at 12:36:05AM +0100, Michael Tuexen wrote:
>>
>>> On 28 Jan 2016, at 22:03, Marcelo Ricardo Leitner
>>> wrote:
>>>
>>> On Thu, Jan 28, 2016 at 06:54:06PM +0100, Michael Tuexen wrote:
> On 28 Jan 2016, a
On Fri, Jan 29, 2016 at 11:57:46AM +0100, Michael Tuexen wrote:
> > On 29 Jan 2016, at 02:18, Marcelo Ricardo Leitner
> > wrote:
> >
> > On Fri, Jan 29, 2016 at 12:36:05AM +0100, Michael Tuexen wrote:
> >>
> >>> On 28 Jan 2016, at 22:03, Marcelo Ricardo Leitner
> >>> wrote:
> >>>
> >>> On Th
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 issues in handling sticky pktinfo,
used by ping6 to enforce the device bindin
Currently, the egress interface index specified via IPV6_PKTINFO
is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
can be subverted when the user space application calls connect()
before sendmsg().
Fix it by initializing properly flowi6_oif in connect() before
performing the rout
The current implementation of ip6_dst_lookup_tail basically
ignore the egress ifindex match: if the saddr is set,
ip6_route_output() purposefully ignores flowi6_oif, due
to the commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE
flag if saddr set"), if the saddr is 'any' the first route lo
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: fddi/defxx: avoid warning about uninitialized variable
use", already
The nb8800_poll() function initializes the 'next' variable in the
loop looking for new input data. We know this will be called at
least once because 'budget' is a guaranteed to be a positive number
when we enter the function, but the compiler doesn't know that
and warns when the variable is used la
The tg3_set_eeprom() function correctly initializes the 'start' variable,
but gcc generates a false warning:
drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom':
drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used
uninitialized in this function [-Wmaybe-uniniti
When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
in the vxge driver:
drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning:
'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning:
The bgmac driver depends on BCMA_HOST_SOC, which is only used
when CONFIG_BCMA is enabled. However, it is a bool option and can
be set when CONFIG_BCMA=m, and then bgmac can be built-in, leading
to an obvious link error:
drivers/built-in.o: In function `bgmac_init':
:(.init.text+0x7f2c): undefined
The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:
ethernet/t
Building the hp100 ethernet driver causes warnings when both the PCI
and EISA drivers are disabled:
ethernet/hp/hp100.c: In function 'hp100_module_init':
ethernet/hp/hp100.c:3047:2: warning: label 'out3' defined but not used
[-Wunused-label]
ethernet/hp/hp100.c: At top level:
ethernet/hp/hp100.c:
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 pointer without a cast [-Werror=int-conversion]
moxart_ether.c:74:39: warning
On 2016-01-29 09:35, Konstantin Khlebnikov wrote:
> Patch fixes this splat
>
> BUG: KASAN: slab-out-of-bounds in minstrel_ht_update_stats.isra.7+0x6e1/0x9e0
> [mac80211] at addr 8800cee640f4 Read of size 4 by task swapper/3/0
>
> Signed-off-by: Konstantin Khlebnikov
> Link:
> http://lkml.ke
> On 29 Jan 2016, at 12:26, Marcelo Ricardo Leitner
> wrote:
>
> On Fri, Jan 29, 2016 at 11:57:46AM +0100, Michael Tuexen wrote:
>>> On 29 Jan 2016, at 02:18, Marcelo Ricardo Leitner
>>> wrote:
>>>
>>> On Fri, Jan 29, 2016 at 12:36:05AM +0100, Michael Tuexen wrote:
> On 28 Jan 2016
On 29.01.2016 12:30, Paolo Abeni wrote:
The current implementation of ip6_dst_lookup_tail basically
ignore the egress ifindex match: if the saddr is set,
ip6_route_output() purposefully ignores flowi6_oif, due
to the commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE
flag if saddr set")
On 29.01.2016 12:30, Paolo Abeni wrote:
Currently, the egress interface index specified via IPV6_PKTINFO
is ignored by __ip6_datagram_connect(), so that RFC 3542 section 6.7
can be subverted when the user space application calls connect()
before sendmsg().
Fix it by initializing properly flowi6_o
On 29.01.2016 12:30, Paolo Abeni wrote:
The kernel has never enforced the egress interface specified
via the sticky pktinfo, except briefly between the commits
741a11d9e410 ("net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set")
and
d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE flag if s
Hi Dear,
I am Mrs Machiko Kumiko, from Japan, I Have Been Diagnosed with esophageal
Cancer.
I Have Chosen you to distribute my Funds to Charities homes in your Country,
so if you wish to Carry out this humanitarian Work kindly Get back to me for
FURTHER details.
Yours Truely Mrs Machiko Kum
On Thursday 28 January 2016 16:14:13 David Miller wrote:
> From: Arnd Bergmann
> Date: Wed, 27 Jan 2016 15:04:50 +0100
>
> > These are all fixes for relatively harmless bugs that showed up
> > in my randconfig testing, so they should not be needed for v4.5
> > but get merged into net-next.
> >
>
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, let's do permissions checks in each function, but use the netlink
socket's user ns instead of the initial one, to allow management of
openvswitch
On Fri, Jan 29, 2016 at 6:00 AM, David Miller wrote:
> This is not the canonical way to fix this. Please look at how
> other drivers handle this situation before inventing your own
> way of solving the problem.
Dave, I was aware that other drivers do that differently, but the
maintainer here pr
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, let's do permissions checks in each function, but use the netlink
> socket's user ns instead of the initial one, t
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 the case for IPv4 fragments.
> >
> > Lets avoid extra cache line miss
On 01/28/2016 08:18 PM, Andrew Lunn wrote:
> On Thu, Jan 28, 2016 at 04:54:37PM -0500, Vivien Didelot wrote:
>> 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 misc
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 01:51:02PM +, David Laight wrote:
...
> > > > With Nagle disabled (an
On 1/29/16 4:30 AM, Paolo Abeni wrote:
The current implementation of ip6_dst_lookup_tail basically
ignore the egress ifindex match: if the saddr is set,
ip6_route_output() purposefully ignores flowi6_oif, due
to the commit d46a9d678e4c ("net: ipv6: Dont add RT6_LOOKUP_F_IFACE
flag if saddr set"),
From: 'Marcelo Ricardo Leitner'
> Sent: 28 January 2016 20:56
...
> > > > I did wonder whether the queued data could actually be picked up
> > > > be a Heartbeat chunk that is probing a different remote address
> > > > (which would be bad news).
> > >
> > > I don't follow. You mean if a heartbeat m
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.
johannes
> From: 'Marcelo Ricardo Leitner' [mailto:marcelo.leit...@gmail.com]
> Sent: 28 January 2016 20:56
...
> > > But yes, agreed, MSG_MORE is at least a welcomed compliment here,
> > > specially for applications generating a train of chunks. Will put that in
> > > my ToDo here, thanks.
> >
> > I've pos
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
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
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
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
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
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
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
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 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
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
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_
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
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
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 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
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, 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
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 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:
> 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
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 {
> + _
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: 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
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
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
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 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
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: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
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, 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
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 (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 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
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 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
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 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
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, 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: Jörg Thalheim
Date: Wed, 27 Jan 2016 22:54:06 +0100
> Signed-off-by: Jörg Thalheim
Applied, thanks.
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
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: 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.
On Fri, 2016-01-29 at 12:24 -0800, David Miller wrote:
>
> This should be fixed now, thanks for letting me know.
Perfect, thanks !
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 (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 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/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, 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 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.
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 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
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
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, 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
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 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
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, 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 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
1 - 100 of 136 matches
Mail list logo
