Re: [PATCH] openvswitch: allow management from inside user namespaces

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

Re: [PATCH net] ipv4: early demux should be aware of fragments

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

Re: [PATCH net] net: dsa: mv88e6xxx: fix port VLAN maps

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

Re: [RFC PATCH net-next 0/3] sctp: add GSO support

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 >

[PATCH v2 1/7] net: moxart: use correct accessors for DMA memory

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:

Re: [PATCH net v2 2/2] ipv6/udp: use sticky pktinfo egress ifindex on connect()

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

Re: [PATCH net v2 1/2] ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()

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

Yours Truely Mrs Machiko Kumiko

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

[PATCH net v2 0/2] pv6: fix sticky pktinfo behaviour

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

[PATCH net v2 2/2] ipv6/udp: use sticky pktinfo egress ifindex on connect()

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

[PATCH net v2 1/2] ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()

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

[PATCH v2 0/7] network driver fixes

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",

Re: [RFC PATCH net-next 0/3] sctp: add GSO support

> 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

[PATCH] openvswitch: allow management from inside user namespaces

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

[PATCH v2 3/7] net: hp100: remove unnecessary #ifdefs

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:

[PATCH v2 4/7] net: bgmac: clarify CONFIG_BCMA dependency

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):

[PATCH v2 2/7] net: davinci_cpdma: use dma_addr_t for DMA address

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:

[PATCH v2 7/7] net: tg3: avoid uninitialized variable warning

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

[PATCH v2 5/7] net: vxge: avoid unused function warnings

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:

Re: [PATCH] mac80211: minstrel_ht: fix out-of-bound in minstrel_ht_set_best_prob_rate

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 >

Re: [RFC PATCH net-next 0/3] sctp: add GSO support

> 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

[PATCH v2 6/7] net: nb8800: avoid uninitialized variable warning

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

Re: [PATCH net v2 0/2] pv6: fix sticky pktinfo behaviour

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

Re: [PATCH 0/9] network driver fixes

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

Re: [PATCH net 2/2] net/mlx5e: Use a private copy of netdev ops

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

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

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

pull-request: wireless-drivers 2016-01-29

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

[PATCH] mac80211: fix memory leak

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

[PATCH] mac80211: minstrel_ht: fix out-of-bound in minstrel_ht_set_best_prob_rate

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:

Re: wlcore: fix error handling in wlcore_event_fw_logger

> 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 >

[PATCH net 4/6] net: mvneta: Modify the queue related fields from each cpu

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]."

[PATCH net 6/6] net: mvneta: Fix race condition during stopping

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

RE: [RFC PATCH net-next 0/3] sctp: add GSO support

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

Re: [PATCH net v2 1/2] ipv6: enforce flowi6_oif usage in ip6_dst_lookup_tail()

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

RE: [RFC PATCH net-next 0/3] sctp: add GSO support

> 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

[PATCH net 1/6] net: mvneta: Fix for_each_present_cpu usage

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

RE: [RFC PATCH net-next 0/3] sctp: add GSO support

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

Re: [PATCH] openvswitch: allow management from inside user namespaces

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

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

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

[PATCH net 5/6] net: mvneta: The mvneta_percpu_elect function should be atomic

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

[PATCH net 0/6] mvneta fixes for SMP

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,

[PATCH net 3/6] net: mvneta: Remove unused code

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

[PATCH net 2/6] net: mvneta: Use on_each_cpu when possible

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:

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

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.

Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver

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

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

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: ---

[RFC] Kernel unaligned access at __skb_flow_dissect

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,

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

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

Re: [PATCH] net_sched: drr: check for NULL pointer in drr_dequeue

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

Re: [v2 PATCH 9/26] eCryptfs: Use skcipher and shash

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

Re: [PATCH net-next 08/40] net: fec: move cbd_bufaddr assignment closer to the mapping function

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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.

Re: [PATCH] vxlan: fix a out of bounds access in __vxlan_find_mac

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: > > >

Re: [PATCH] vxlan: fix a out of bounds access in __vxlan_find_mac

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: i40e: Kernel unaligned access due to 'struct i40e_dma_mem' being 'packed'

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)

[Intel-wired-lan] [next] igb: allow setting MAC address on i211 using a device tree blob

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]

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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. > >

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: [PATCH] net_sched: drr: check for NULL pointer in drr_dequeue

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 >

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: [PATCH net 0/3] bnxt_en: Bug fixes.

From: Michael Chan Date: Thu, 28 Jan 2016 03:11:19 -0500 > 3 small bug fix patches for net. Series applied, thanks Michael.

Re: [PATCH v2 net] nfc: use GFP_USER for user-controlled kmalloc

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

Re: [PATCH] vxlan: fix a out of bounds access in __vxlan_find_mac

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.

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

[PATCH] bgmac: add helper checking for BCM4707 / BCM53018 chip id

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

Re: [PATCH] ipv6: release idev lock before calling ipv6_ifa_notify()

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(>lock); > - if

Re: [net PATCH] flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen

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

Re: xfrm: UFO + ESP = double fragmentation

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

Re: bonding (IEEE 802.3ad) not working with qemu/virtio

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

Re: [PATCH net] irda: fix a potential use-after-free in ircomm_param_request

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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

Re: [net PATCH] flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen

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

Re: [PATCHv2] ipv4: ipconfig: avoid unused ic_proto_used symbol

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:

Re: [PATCHv2] net: moxart: use correct accessors for DMA memory

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 >

Re: [PATCH net 5/6] net: mvneta: The mvneta_percpu_elect function should be atomic

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; > >

Re: [PATCH net v2 0/4] net: add and use rx_nohandler stat counter

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

Re: [PATCH net v2 0/2] pv6: fix sticky pktinfo behaviour

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

Re: [PATCH net] net: dsa: mv88e6xxx: fix port VLAN maps

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.

Re: [net PATCH] fib_trie: Fix shift by 32 in fib_table_lookup

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

Re: [PATCH] vxlan: fix a out of bounds access in __vxlan_find_mac

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,

Re: [PATCH] bgmac: add helper checking for BCM4707 / BCM53018 chip id

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ł

Re: [PATCH net] netlink: not trim skb for mmaped socket when dump

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

Re: [PATCH v2 0/7] network driver fixes

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 >

[net PATCH] flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen

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

Re: pull-request: wireless-drivers 2016-01-29

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.

Re: [net PATCH] flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get_headlen

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 >>>

Re: [PATCH net] tcp: avoid cwnd undo after receiving ECN

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

[PATCH net] tcp: avoid cwnd undo after receiving ECN

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:

xfrm: UFO + ESP = double fragmentation

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

Re: bonding (IEEE 802.3ad) not working with qemu/virtio

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

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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. > >

Re: [RFC] Kernel unaligned access at __skb_flow_dissect

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. > >

Re: [PATCH] vxlan: fix a out of bounds access in __vxlan_find_mac

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

Re: bonding (IEEE 802.3ad) not working with qemu/virtio

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. >>

Re: bonding (IEEE 802.3ad) not working with qemu/virtio

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

Re: WARNING at net/mac80211/rate.c:513 ieee80211_get_tx_rates [mac80211]

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,

  1   2   >