* Re: [PATCH net,stable 1/1] net: fec: don't dump RX FIFO register when not available
From: David Miller @ 2018-10-16 5:53 UTC (permalink / raw)
Cc: netdev, tremyfr
In-Reply-To: <1539580359-26732-1-git-send-email-fugang.duan@nxp.com>
From: Andy Duan <fugang.duan@nxp.com>
Date: Mon, 15 Oct 2018 05:19:00 +0000
> From: Fugang Duan <fugang.duan@nxp.com>
>
> Commit db65f35f50e0 ("net: fec: add support of ethtool get_regs") introduce
> ethool "--register-dump" interface to dump all FEC registers.
>
> But not all silicon implementations of the Freescale FEC hardware module
> have the FRBR (FIFO Receive Bound Register) and FRSR (FIFO Receive Start
> Register) register, so we should not be trying to dump them on those that
> don't.
>
> To fix it we create a quirk flag, FEC_QUIRK_HAS_RFREG, and check it before
> dump those RX FIFO registers.
>
> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH][net-next][v2] net: bridge: fix a possible memory leak in __vlan_add
From: David Miller @ 2018-10-16 5:55 UTC (permalink / raw)
To: lirongqing; +Cc: netdev, bridge, nikolay, roopa
In-Reply-To: <1539601231-32755-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Mon, 15 Oct 2018 19:00:31 +0800
> After per-port vlan stats, vlan stats should be released
> when fail to add vlan
>
> Fixes: 9163a0fc1f0c0 ("net: bridge: add support for per-port vlan stats")
> CC: bridge@lists.linux-foundation.org
> cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> CC: Roopa Prabhu <roopa@cumulusnetworks.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] sctp: use the pmtu from the icmp packet to update transport pathmtu
From: David Miller @ 2018-10-16 5:55 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <de1ad572beb97767e535b7cf60da7b1de6cbfd4f.1539604709.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 15 Oct 2018 19:58:29 +0800
> Other than asoc pmtu sync from all transports, sctp_assoc_sync_pmtu
> is also processing transport pmtu_pending by icmp packets. But it's
> meaningless to use sctp_dst_mtu(t->dst) as new pmtu for a transport.
>
> The right pmtu value should come from the icmp packet, and it would
> be saved into transport->mtu_info in this patch and used later when
> the pmtu sync happens in sctp_sendmsg_to_asoc or sctp_packet_config.
>
> Besides, without this patch, as pmtu can only be updated correctly
> when receiving a icmp packet and no place is holding sock lock, it
> will take long time if the sock is busy with sending packets.
>
> Note that it doesn't process transport->mtu_info in .release_cb(),
> as there is no enough information for pmtu update, like for which
> asoc or transport. It is not worth traversing all asocs to check
> pmtu_pending. So unlike tcp, sctp does this in tx path, for which
> mtu_info needs to be atomic_t.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_id2assoc
From: Marcelo Ricardo Leitner @ 2018-10-16 13:46 UTC (permalink / raw)
To: Neil Horman
Cc: Dmitry Vyukov, syzbot, David Miller, LKML, linux-sctp, netdev,
syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <20181015112330.GA31030@hmswarspite.think-freely.org>
On Tue, Oct 16, 2018 at 07:28:17AM -0400, Neil Horman wrote:
> On Wed, Oct 10, 2018 at 03:40:11PM -0300, Marcelo Ricardo Leitner wrote:
> > On Wed, Oct 10, 2018 at 08:28:22PM +0200, Dmitry Vyukov wrote:
> > > On Wed, Oct 10, 2018 at 8:13 PM, Marcelo Ricardo Leitner
> > > <marcelo.leitner@gmail.com> wrote:
> > > > On Wed, Oct 10, 2018 at 05:28:12PM +0200, Dmitry Vyukov wrote:
> > > >> On Fri, Oct 5, 2018 at 4:58 PM, Marcelo Ricardo Leitner
> > > >> <marcelo.leitner@gmail.com> wrote:
> > > >> > On Thu, Oct 04, 2018 at 01:48:03AM -0700, syzbot wrote:
> > > >> >> Hello,
> > > >> >>
> > > >> >> syzbot found the following crash on:
> > > >> >>
> > > >> >> HEAD commit: 4e6d47206c32 tls: Add support for inplace records encryption
> > > >> >> git tree: net-next
> > > >> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13834b81400000
> > > >> >> kernel config: https://syzkaller.appspot.com/x/.config?x=e569aa5632ebd436
> > > >> >> dashboard link: https://syzkaller.appspot.com/bug?extid=c7dd55d7aec49d48e49a
> > > >> >> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> > > >> >>
> > > >> >> Unfortunately, I don't have any reproducer for this crash yet.
> > > >> >>
> > > >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > >> >> Reported-by: syzbot+c7dd55d7aec49d48e49a@syzkaller.appspotmail.com
> > > >> >>
> > > >> >> netlink: 'syz-executor1': attribute type 1 has an invalid length.
> > > >> >> ==================================================================
> > > >> >> BUG: KASAN: use-after-free in sctp_id2assoc+0x3a7/0x3e0
> > > >> >> net/sctp/socket.c:276
> > > >> >> Read of size 8 at addr ffff880195b3eb20 by task syz-executor2/15454
> > > >> >>
> > > >> >> CPU: 1 PID: 15454 Comm: syz-executor2 Not tainted 4.19.0-rc5+ #242
> > > >> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > >> >> Google 01/01/2011
> > > >> >> Call Trace:
> > > >> >> __dump_stack lib/dump_stack.c:77 [inline]
> > > >> >> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> > > >> >> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> > > >> >> kasan_report_error mm/kasan/report.c:354 [inline]
> > > >> >> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> > > >> >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> > > >> >> sctp_id2assoc+0x3a7/0x3e0 net/sctp/socket.c:276
> > > >> >
> > > >> > I'm not seeing yet how this could happen.
> > > >> > All sockopts here are serialized by sock_lock.
> > > >> > do_peeloff here would create another socket, but the issue was
> > > >> > triggered before that.
> > > >> > The same function that freed this memory, also removes the entry from
> > > >> > idr mapping, so this entry shouldn't be there anymore.
> > > >> >
> > > >> > I have only two theories so far:
> > > >> > - an issue with IDR/RCU.
> > > >> > - something else happened that just the call stacks are not revealing.
> > > >>
> > > >> The "asoc->base.sk != sk" check after idr_find suggests that we don't
> > > >> actually know what sock it belongs to. And if we don't know then
> > > >
> > > > Right. The check is more because the IDR is global and not per socket
> > > > (and we don't want sockets accessing asocs from other sockets), and not
> > > > that the asoc may move to another socket in between, but it also
> > > > protects from such cases, yes.
> > > >
> > > >> locking this sock can't help keeping another sock association alive.
> > > >> Am I missing something obvious here? Should we take assoc ref while we
> > > >
> > > > Not sure. Maybe I am. Thanks for looking into this, btw.
> > > >
> > > >> are still holding sctp_assocs_id_lock?
> > > >
> > > > Shouldn't be needed.
> > > >
> > > > Solely by the call stacks:
> > > > - we tried to establish a new asoc from a sctp_connect() call,
> > > > blocking one.
> > > > - it slept waiting for the connect
> > > > - (something closed the asoc in between the sleeps, because it freed
> > > > the asoc right when waking up on sctp_wait_for_connect())
> > > > - it freed the asoc after sleeping on it on sctp_wait_for_connect [A]
> > > > - another thread tried to peeloff that asoc [B]
> > > >
> > > > For [B] to access the asoc in question, it had to take the same sock
> > > > lock [A] had taken, and then the idr should not return an asoc in
> > > > sctp_i2asoc(). Note that we can't peeloff an asoc twice, thus why
> > > > the certainty here.
> > > >
> > > > If [B] actually kicked in before the sleep resumed, that should have
> > > > been fine because it took the same sock lock [A] would have to
> > > > re-take. In this case an asoc would have been returned by
> > > > sctp_id2asoc(), the asoc would have been moved to a new socket, but
> > > > all while holding the original socket sock lock.
> > >
> > > But why A and B use the same lock?
> > >
> > > sctp_assocs_id is global, so it contains asocs from all sockets, right?
> > > assoc id comes straight from userspaces.
> > > So isn't it possible that B uses completely different sock but passes
> > > assoc id from the A sock? Then B should find assoc in sctp_assocs_id,
> > > and at the point of "asoc->base.sk != sk" check the assoc can be
> > > already freed.
> >
> > That explains it. Somehow I was thinking the issue was for reading
> > ->dead instead. Now it's pretty clear. Then this should be the patch
> > we want. Can you please give it a spin? (only compile tested)
> >
> > While holding the spinlock, an entry cannot be removed from the idr
> > and thus it cannot be freed. So even if the app uses an id from
> > another socket, it will still be there.
> >
> > ---8<---
> >
> > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > index f73e9d38d5ba..a7722f43aa69 100644
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -271,11 +271,10 @@ struct sctp_association *sctp_id2assoc(struct sock *sk, sctp_assoc_t id)
> >
> > spin_lock_bh(&sctp_assocs_id_lock);
> > asoc = (struct sctp_association *)idr_find(&sctp_assocs_id, (int)id);
> > + if (asoc && (asoc->base.sk != sk || asoc->base.dead))
> > + asoc = NULL;
> > spin_unlock_bh(&sctp_assocs_id_lock);
> >
> > - if (!asoc || (asoc->base.sk != sk) || asoc->base.dead)
> > - return NULL;
> > -
> > return asoc;
> > }
> >
> >
> Marcello, can you post this with a proper changelog commit please? Based on the
> bug report, and description of the problem, I think we can all agree this is a
> sane fix
Yes, in a few. The patch should be ready, but ahm.. I had destroyed by
test environment (disk failures). I'm seizing the moment to bring it
up.
Thanks,
Marcelo
>
>
> Thanks
> Neil
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] tcp: second round for EDT conversion
From: David Miller @ 2018-10-16 5:58 UTC (permalink / raw)
To: edumazet; +Cc: ncardwell, ycheng, soheil, zelo.zejn, netdev, eric.dumazet
In-Reply-To: <20181015163758.232436-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 15 Oct 2018 09:37:51 -0700
> First round of EDT patches left TCP stack in a non optimal state.
>
> - High speed flows suffered from loss of performance, addressed
> by the first patch of this series.
>
> - Second patch brings pacing to the current state of networking,
> since we now reach ~100 Gbit on a single TCP flow.
>
> - Third patch implements a mitigation for scheduling delays,
> like the one we did in sch_fq in the past.
>
> - Fourth patch removes one special case in sch_fq for ACK packets.
>
> - Fifth patch removes a serious perfomance cost for TCP internal
> pacing. We should setup the high resolution timer only if
> really needed.
>
> - Sixth patch fixes a typo in BBR.
>
> - Last patch is one minor change in cdg congestion control.
>
> Neal Cardwell also has a patch series fixing BBR after
> EDT adoption.
Series applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next V2 6/8] vhost: packed ring support
From: Maxime Coquelin @ 2018-10-16 13:58 UTC (permalink / raw)
To: Jason Wang, Michael S. Tsirkin, Tiwei Bie
Cc: kvm, virtualization, netdev, linux-kernel, wexu, jfreimann
In-Reply-To: <447f47fa-32dd-a408-dd81-13a9839e0748@redhat.com>
On 10/15/2018 04:22 AM, Jason Wang wrote:
>
>
> On 2018年10月13日 01:23, Michael S. Tsirkin wrote:
>> On Fri, Oct 12, 2018 at 10:32:44PM +0800, Tiwei Bie wrote:
>>> On Mon, Jul 16, 2018 at 11:28:09AM +0800, Jason Wang wrote:
>>> [...]
>>>> @@ -1367,10 +1397,48 @@ long vhost_vring_ioctl(struct vhost_dev *d,
>>>> unsigned int ioctl, void __user *arg
>>>> vq->last_avail_idx = s.num;
>>>> /* Forget the cached index value. */
>>>> vq->avail_idx = vq->last_avail_idx;
>>>> + if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED)) {
>>>> + vq->last_avail_wrap_counter = wrap_counter;
>>>> + vq->avail_wrap_counter = vq->last_avail_wrap_counter;
>>>> + }
>>>> break;
>>>> case VHOST_GET_VRING_BASE:
>>>> s.index = idx;
>>>> s.num = vq->last_avail_idx;
>>>> + if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED))
>>>> + s.num |= vq->last_avail_wrap_counter << 31;
>>>> + if (copy_to_user(argp, &s, sizeof(s)))
>>>> + r = -EFAULT;
>>>> + break;
>>>> + case VHOST_SET_VRING_USED_BASE:
>>>> + /* Moving base with an active backend?
>>>> + * You don't want to do that.
>>>> + */
>>>> + if (vq->private_data) {
>>>> + r = -EBUSY;
>>>> + break;
>>>> + }
>>>> + if (copy_from_user(&s, argp, sizeof(s))) {
>>>> + r = -EFAULT;
>>>> + break;
>>>> + }
>>>> + if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED)) {
>>>> + wrap_counter = s.num >> 31;
>>>> + s.num &= ~(1 << 31);
>>>> + }
>>>> + if (s.num > 0xffff) {
>>>> + r = -EINVAL;
>>>> + break;
>>>> + }
>>> Do we want to put wrap_counter at bit 15?
>> I think I second that - seems to be consistent with
>> e.g. event suppression structure and the proposed
>> extension to driver notifications.
>
> Ok, I assumes packed virtqueue support 64K but looks not. I can change
> it to bit 15 and GET_VRING_BASE need to be changed as well.
>
>>
>>
>>> If put wrap_counter at bit 31, the check (s.num > 0xffff)
>>> won't be able to catch the illegal index 0x8000~0xffff for
>>> packed ring.
>>>
>
> Do we need to clarify this in the spec?
>
>>>> + vq->last_used_idx = s.num;
>>>> + if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED))
>>>> + vq->last_used_wrap_counter = wrap_counter;
>>>> + break;
>>>> + case VHOST_GET_VRING_USED_BASE:
>>> Do we need the new VHOST_GET_VRING_USED_BASE and
>>> VHOST_SET_VRING_USED_BASE ops?
>>>
>>> We are going to merge below series in DPDK:
>>>
>>> http://patches.dpdk.org/patch/45874/
>>>
>>> We may need to reach an agreement first.
>
> If we agree that 64K virtqueue won't be supported, I'm ok with either.
I'm fine to put wrap_counter at bit 15.
I will post a new version of the DPDK series soon.
> Btw the code assumes used_wrap_counter is equal to avail_wrap_counter
> which looks wrong?
For split ring, we used to set the last_used_idx to the same value as
last_avail_idx as VHOST_USER_GET_VRING_BASE cannot be called while the
ring is being processed, so their value is always the same at the time
the request is handled.
I kept the same behavior for packed ring, and so the wrap counter have
to be the same.
Regards,
Maxime
> Thanks
>
>>>
>>>> + s.index = idx;
>>>> + s.num = vq->last_used_idx;
>>>> + if (vhost_has_feature(vq, VIRTIO_F_RING_PACKED))
>>>> + s.num |= vq->last_used_wrap_counter << 31;
>>>> if (copy_to_user(argp, &s, sizeof s))
>>>> r = -EFAULT;
>>>> break;
>>> [...]
>
^ permalink raw reply
* Re: [PATCH net-next] net: phy: merge phy_start_aneg and phy_start_aneg_priv
From: David Miller @ 2018-10-16 6:14 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <65124b7b-1038-d9d3-b383-66d850333be7@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 15 Oct 2018 21:25:13 +0200
> After commit 9f2959b6b52d ("net: phy: improve handling delayed work")
> the sync parameter isn't needed any longer in phy_start_aneg_priv().
> This allows to merge phy_start_aneg() and phy_start_aneg_priv().
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/3] nfp: fix pedit set action offloads
From: David Miller @ 2018-10-16 6:17 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20181015235225.17574-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 15 Oct 2018 16:52:22 -0700
> Pieter says:
>
> This set fixes set actions when using multiple pedit actions with
> partial masks and with multiple keys per pedit action. Additionally
> it fixes set ipv6 pedit action offloads when using it in combination
> with other header keys.
>
> The problem would only trigger if one combines multiple pedit actions
> of the same type with partial masks, e.g.:
>
> $ tc filter add dev netdev protocol ip parent ffff: \
> flower indev netdev \
> ip_proto tcp \
> action pedit ex munge \
> ip src set 11.11.11.11 retain 65535 munge \
> ip src set 22.22.22.22 retain 4294901760 pipe \
> csum ip and tcp pipe \
> mirred egress redirect dev netdev
Series applied.
^ permalink raw reply
* Re: pull-request: bpf-next 2018-10-16
From: David Miller @ 2018-10-16 6:21 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20181016003328.13601-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 16 Oct 2018 02:33:28 +0200
> The following pull-request contains BPF updates for your *net-next* tree.
>
> The main changes are:
...
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Pulled, thanks Daniel.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/11] net: Kernel side filtering for route dumps
From: David Miller @ 2018-10-16 6:30 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20181016015651.22696-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Mon, 15 Oct 2018 18:56:40 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Implement kernel side filtering of route dumps by protocol (e.g., which
> routing daemon installed the route), route type (e.g., unicast), table
> id and nexthop device.
>
> iproute2 has been doing this filtering in userspace for years; pushing
> the filters to the kernel side reduces the amount of data the kernel
> sends and reduces wasted cycles on both sides processing unwanted data.
> These initial options provide a huge improvement for efficiently
> examining routes on large scale systems.
>
> v2
> - better handling of requests for a specific table. Rather than walking
> the hash of all tables, lookup the specific table and dump it
> - refactor mr_rtm_dumproute moving the loop over the table into a
> helper that can be invoked directly
> - add hook to return NLM_F_DUMP_FILTERED in DONE message to ensure
> it is returned even when the dump returns nothing
Looks great David, I'll push this out to net-next after my build tests
finish.
Thanks.
^ permalink raw reply
* Re: Fw: [Bug 201423] New: eth0: hw csum failure
From: Andre Tomt @ 2018-10-16 6:30 UTC (permalink / raw)
To: Eric Dumazet, Stephen Hemminger; +Cc: netdev, rossi.f
In-Reply-To: <CANn89iLA+rdFNXXdzogLHF1FqYg3CjpwXJbscWTJ8Bk8bN2Scw@mail.gmail.com>
On 15.10.2018 17:41, Eric Dumazet wrote:
> On Mon, Oct 15, 2018 at 8:15 AM Stephen Hemminger
>> Something is changed between 4.17.12 and 4.18, after bisecting the problem I
>> got the following first bad commit:
>>
>> commit 88078d98d1bb085d72af8437707279e203524fa5
>> Author: Eric Dumazet <edumazet@google.com>
>> Date: Wed Apr 18 11:43:15 2018 -0700
>>
>> net: pskb_trim_rcsum() and CHECKSUM_COMPLETE are friends
>>
>> After working on IP defragmentation lately, I found that some large
>> packets defeat CHECKSUM_COMPLETE optimization because of NIC adding
>> zero paddings on the last (small) fragment.
>>
>> While removing the padding with pskb_trim_rcsum(), we set skb->ip_summed
>> to CHECKSUM_NONE, forcing a full csum validation, even if all prior
>> fragments had CHECKSUM_COMPLETE set.
>>
>> We can instead compute the checksum of the part we are trimming,
>> usually smaller than the part we keep.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>
> Thanks for bisecting !
>
> This commit is known to expose some NIC/driver bugs.
>
> Look at commit 12b03558cef6d655d0d394f5e98a6fd07c1f6c0f
> ("net: sungem: fix rx checksum support") for one driver needing a fix.
>
> I assume SKY2_HW_NEW_LE is not set on your NIC ?
>
I've seen similar on several systems with mlx4 cards when using 4.18.x -
that is hw csum failure followed by some backtrace.
Only seems to happen on systems dealing with quite a bit of UDP.
Example from 4.18.10:
> [635607.740574] p0xe0: hw csum failure
> [635607.740598] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.18.0-1 #1
> [635607.740599] Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017
> [635607.740599] Call Trace:
> [635607.740602] <IRQ>
> [635607.740611] dump_stack+0x5c/0x7b
> [635607.740617] __skb_gro_checksum_complete+0x9a/0xa0
> [635607.740621] udp6_gro_receive+0x211/0x290
> [635607.740624] ipv6_gro_receive+0x1a8/0x390
> [635607.740627] dev_gro_receive+0x33e/0x550
> [635607.740628] napi_gro_frags+0xa2/0x210
> [635607.740635] mlx4_en_process_rx_cq+0xa01/0xb40 [mlx4_en]
> [635607.740648] ? mlx4_cq_completion+0x23/0x70 [mlx4_core]
> [635607.740654] ? mlx4_eq_int+0x373/0xc80 [mlx4_core]
> [635607.740657] mlx4_en_poll_rx_cq+0x55/0xf0 [mlx4_en]
> [635607.740658] net_rx_action+0xe0/0x2e0
> [635607.740662] __do_softirq+0xd8/0x2e5
> [635607.740666] irq_exit+0xb4/0xc0
> [635607.740667] do_IRQ+0x85/0xd0
> [635607.740670] common_interrupt+0xf/0xf
> [635607.740671] </IRQ>
> [635607.740675] RIP: 0010:cpuidle_enter_state+0xb4/0x2a0
> [635607.740675] Code: 31 ff e8 df a6 ba ff 45 84 f6 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 d8 01 00 00 31 ff e8 13 81 bf ff fb 66 0f 1f 44 00 00 <4c> 29 fb 48 ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7
> [635607.740701] RSP: 0018:ffffa5c206353ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd9
> [635607.740703] RAX: ffff8d72ffd20f00 RBX: 00024214f597c5b0 RCX: 000000000000001f
> [635607.740703] RDX: 00024214f597c5b0 RSI: 0000000000020780 RDI: 0000000000000000
> [635607.740704] RBP: 0000000000000004 R08: 002542bfbefa99fa R09: 00000000ffffffff
> [635607.740705] R10: ffffa5c206353e88 R11: 00000000000000c5 R12: ffffffffaf0aaf78
> [635607.740706] R13: ffff8d72ffd297d8 R14: 0000000000000000 R15: 00024214f58c2ed5
> [635607.740709] ? cpuidle_enter_state+0x91/0x2a0
> [635607.740712] do_idle+0x1d0/0x240
> [635607.740715] cpu_startup_entry+0x5f/0x70
> [635607.740719] start_secondary+0x185/0x1a0
> [635607.740722] secondary_startup_64+0xa5/0xb0
> [635607.740731] p0xe0: hw csum failure
> [635607.740745] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.18.0-1 #1
> [635607.740746] Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0b 05/02/2017
> [635607.740746] Call Trace:
> [635607.740747] <IRQ>
> [635607.740750] dump_stack+0x5c/0x7b
> [635607.740755] __skb_checksum_complete+0xb8/0xd0
> [635607.740760] __udp6_lib_rcv+0xa6b/0xa70
> [635607.740767] ? nft_do_chain_inet+0x7a/0xd0 [nf_tables]
> [635607.740770] ? nft_do_chain_inet+0x7a/0xd0 [nf_tables]
> [635607.740774] ip6_input_finish+0xc0/0x460
> [635607.740776] ip6_input+0x2b/0x90
> [635607.740778] ? ip6_rcv_finish+0x110/0x110
> [635607.740780] ipv6_rcv+0x2cd/0x4b0
> [635607.740783] ? udp6_lib_lookup_skb+0x59/0x80
> [635607.740785] __netif_receive_skb_core+0x455/0xb30
> [635607.740788] ? ipv6_gro_receive+0x1a8/0x390
> [635607.740790] ? netif_receive_skb_internal+0x24/0xb0
> [635607.740792] netif_receive_skb_internal+0x24/0xb0
> [635607.740793] napi_gro_frags+0x165/0x210
> [635607.740796] mlx4_en_process_rx_cq+0xa01/0xb40 [mlx4_en]
> [635607.740802] ? mlx4_cq_completion+0x23/0x70 [mlx4_core]
> [635607.740807] ? mlx4_eq_int+0x373/0xc80 [mlx4_core]
> [635607.740810] mlx4_en_poll_rx_cq+0x55/0xf0 [mlx4_en]
> [635607.740811] net_rx_action+0xe0/0x2e0
> [635607.740813] __do_softirq+0xd8/0x2e5
> [635607.740816] irq_exit+0xb4/0xc0
> [635607.740817] do_IRQ+0x85/0xd0
> [635607.740820] common_interrupt+0xf/0xf
> [635607.740821] </IRQ>
> [635607.740823] RIP: 0010:cpuidle_enter_state+0xb4/0x2a0
> [635607.740823] Code: 31 ff e8 df a6 ba ff 45 84 f6 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 d8 01 00 00 31 ff e8 13 81 bf ff fb 66 0f 1f 44 00 00 <4c> 29 fb 48 ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7
> [635607.740848] RSP: 0018:ffffa5c206353ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd9
> [635607.740849] RAX: ffff8d72ffd20f00 RBX: 00024214f597c5b0 RCX: 000000000000001f
> [635607.740850] RDX: 00024214f597c5b0 RSI: 0000000000020780 RDI: 0000000000000000
> [635607.740851] RBP: 0000000000000004 R08: 002542bfbefa99fa R09: 00000000ffffffff
> [635607.740852] R10: ffffa5c206353e88 R11: 00000000000000c5 R12: ffffffffaf0aaf78
> [635607.740853] R13: ffff8d72ffd297d8 R14: 0000000000000000 R15: 00024214f58c2ed5
> [635607.740855] ? cpuidle_enter_state+0x91/0x2a0
> [635607.740857] do_idle+0x1d0/0x240
> [635607.740859] cpu_startup_entry+0x5f/0x70
> [635607.740861] start_secondary+0x185/0x1a0
> [635607.740863] secondary_startup_64+0xa5/0xb0
^ permalink raw reply
* Re: [PATCH] ptp: fix Spectre v1 vulnerability
From: Richard Cochran @ 2018-10-16 15:15 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <20181016130641.GA603@embeddedor.com>
On Tue, Oct 16, 2018 at 03:06:41PM +0200, Gustavo A. R. Silva wrote:
> pin_index can be indirectly controlled by user-space, hence leading
> to a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue
> 'ops->pin_config' [r] (local cap)
>
> Fix this by sanitizing pin_index before using it to index
> ops->pin_config, and before passing it as an argument to
> function ptp_set_pinfunc(), in which it is used to index
> info->pin_config.
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [PATCH net] sctp: get pr_assoc and pr_stream all status with SCTP_PR_SCTP_ALL instead
From: Xin Long @ 2018-10-16 7:52 UTC (permalink / raw)
To: network dev, linux-sctp; +Cc: davem, Marcelo Ricardo Leitner, Neil Horman
According to rfc7496 section 4.3 or 4.4:
sprstat_policy: This parameter indicates for which PR-SCTP policy
the user wants the information. It is an error to use
SCTP_PR_SCTP_NONE in sprstat_policy. If SCTP_PR_SCTP_ALL is used,
the counters provided are aggregated over all supported policies.
We change to dump pr_assoc and pr_stream all status by SCTP_PR_SCTP_ALL
instead, and return error for SCTP_PR_SCTP_NONE, as it also said "It is
an error to use SCTP_PR_SCTP_NONE in sprstat_policy. "
Fixes: 826d253d57b1 ("sctp: add SCTP_PR_ASSOC_STATUS on sctp sockopt")
Fixes: d229d48d183f ("sctp: add SCTP_PR_STREAM_STATUS sockopt for prsctp")
Reported-by: Ying Xu <yinxu@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/uapi/linux/sctp.h | 1 +
net/sctp/socket.c | 8 ++++----
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
index b479db5..34dd3d4 100644
--- a/include/uapi/linux/sctp.h
+++ b/include/uapi/linux/sctp.h
@@ -301,6 +301,7 @@ enum sctp_sinfo_flags {
SCTP_SACK_IMMEDIATELY = (1 << 3), /* SACK should be sent without delay. */
/* 2 bits here have been used by SCTP_PR_SCTP_MASK */
SCTP_SENDALL = (1 << 6),
+ SCTP_PR_SCTP_ALL = (1 << 7),
SCTP_NOTIFICATION = MSG_NOTIFICATION, /* Next message is not user msg but notification. */
SCTP_EOF = MSG_FIN, /* Initiate graceful shutdown process. */
};
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index f73e9d3..e25a20f 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -7100,14 +7100,14 @@ static int sctp_getsockopt_pr_assocstatus(struct sock *sk, int len,
}
policy = params.sprstat_policy;
- if (policy & ~SCTP_PR_SCTP_MASK)
+ if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
goto out;
asoc = sctp_id2assoc(sk, params.sprstat_assoc_id);
if (!asoc)
goto out;
- if (policy == SCTP_PR_SCTP_NONE) {
+ if (policy & SCTP_PR_SCTP_ALL) {
params.sprstat_abandoned_unsent = 0;
params.sprstat_abandoned_sent = 0;
for (policy = 0; policy <= SCTP_PR_INDEX(MAX); policy++) {
@@ -7159,7 +7159,7 @@ static int sctp_getsockopt_pr_streamstatus(struct sock *sk, int len,
}
policy = params.sprstat_policy;
- if (policy & ~SCTP_PR_SCTP_MASK)
+ if (!policy || (policy & ~(SCTP_PR_SCTP_MASK | SCTP_PR_SCTP_ALL)))
goto out;
asoc = sctp_id2assoc(sk, params.sprstat_assoc_id);
@@ -7175,7 +7175,7 @@ static int sctp_getsockopt_pr_streamstatus(struct sock *sk, int len,
goto out;
}
- if (policy == SCTP_PR_SCTP_NONE) {
+ if (policy == SCTP_PR_SCTP_ALL) {
params.sprstat_abandoned_unsent = 0;
params.sprstat_abandoned_sent = 0;
for (policy = 0; policy <= SCTP_PR_INDEX(MAX); policy++) {
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] ip_tunnel: specify tunnel type via template
From: Pablo Neira Ayuso @ 2018-10-16 8:03 UTC (permalink / raw)
To: David Miller
Cc: netfilter-devel, netdev, roopa, amir, pshelar, u9012063, daniel,
jakub.kicinski
In-Reply-To: <20181015.214320.807689629924469586.davem@davemloft.net>
On Mon, Oct 15, 2018 at 09:43:20PM -0700, David Miller wrote:
> From: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Wed, 10 Oct 2018 00:24:36 +0200
>
> > The following patchset adds a new field to the tunnel metadata template.
> > This new field allows us to restrict the configuration to a given tunnel
> > driver in order to catch incorrect configuration that may result in
> > packets going to the wrong tunnel driver.
> >
> > Changes with regards to initial RFC [1] are:
> >
> > 1) Explicit tunnel type initialization to TUNNEL_TYPE_UNSPEC in existing
> > clients for this code, as requested by Daniel.
> >
> > 2) Add TUNNEL_TYPE_* definition through enum tunnel_type in
> > uapi/linux/if_tunnel.h, so we don't need to redefine this in every
> > client of this infrastructure.
> >
> > 3) Add TUNNEL_TYPE_IPIP, TUNNEL_TYPE_IPIP6 and TUNNEL_TYPE_IP6IP6, which
> > were missing in the original RFC.
> >
> > Let me know if you any more comments, thanks.
> >
> > [1] https://marc.info/?l=netfilter-devel&m=153861145204094&w=2
>
> People don't need to update a core common UAPI header to add a new
> ethernet driver.
>
> They shouldn't have to do so to add a new tunneling driver either.
>
> But that requirement is created by this patch set.
No, you can keep using TUNNEL_TYPE_UNSPEC in such scenario.
It is entirely optional and backward compatible.
^ permalink raw reply
* [PATCH] net-xfrm: add build time cfg option to PF_KEY SHA256 to use RFC4868-compliant truncation
From: Maciej Żenczykowski @ 2018-10-16 8:06 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller, Steffen Klassert,
Herbert Xu
Cc: netdev, Lorenzo Colitti
From: Maciej Żenczykowski <maze@google.com>
When using the PF_KEY interface, SHA-256 hashes are hardcoded to
use 96-bit truncation. This is a violation of RFC4868, which
specifies 128-bit truncation.
We cannot fix this without introducing backwards compatibility
concerns unless we make it an optional build time setting
(defaulting to no). Android will default to yes instead
of carrying an Android specific one line patch.
While the PF_KEY interface is deprecated in favour of netlink XFRM
(which allows the app to specify an arbitrary truncation length),
changing the PF_KEY truncation length from 96 to 128 allows PF_KEY
apps such as racoon to work with standards-compliant VPN servers.
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
---
net/xfrm/Kconfig | 10 ++++++++++
net/xfrm/xfrm_algo.c | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
index 4a9ee2d83158..0ede7e81a5d3 100644
--- a/net/xfrm/Kconfig
+++ b/net/xfrm/Kconfig
@@ -15,6 +15,16 @@ config XFRM_ALGO
select XFRM
select CRYPTO
+config XFRM_HMAC_SHA256_RFC4868
+ bool "Strict RFC4868 hmac(sha256) 128-bit truncation"
+ depends on XFRM_ALGO
+ default n
+ ---help---
+ Support strict RFC4868 hmac(sha256) 128-bit truncation
+ (default on Android) instead of the default 96-bit Linux truncation.
+
+ If unsure, say N.
+
config XFRM_USER
tristate "Transformation user configuration interface"
depends on INET
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 44ac85fe2bc9..a70391fb2c1e 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -241,7 +241,11 @@ static struct xfrm_algo_desc aalg_list[] = {
.uinfo = {
.auth = {
+#if IS_ENABLED(CONFIG_XFRM_HMAC_SHA256_RFC4868)
+ .icv_truncbits = 128,
+#else
.icv_truncbits = 96,
+#endif
.icv_fullbits = 256,
}
},
--
2.19.1.331.ge82ca0e54c-goog
^ permalink raw reply related
* Re: [PATCH] net-xfrm: add build time cfg option to PF_KEY SHA256 to use RFC4868-compliant truncation
From: Maciej Żenczykowski @ 2018-10-16 8:08 UTC (permalink / raw)
To: David Miller, steffen.klassert, Herbert Xu; +Cc: Linux NetDev, Lorenzo Colitti
In-Reply-To: <20181016080634.139776-1-zenczykowski@gmail.com>
Yes, I realize there's been similar submits in the past,
but we're trying to get rid of or upstream android kernel networking
divergences...
maybe this approach will be more palatable?
Thanks,
Maciej
^ permalink raw reply
* Re: crash in xt_policy due to skb_dst_drop() in nf_ct_frag6_gather()
From: Florian Westphal @ 2018-10-16 8:11 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Lorenzo Colitti, Eric Dumazet, Florian Westphal, Linux NetDev,
Maciej Zenczykowski
In-Reply-To: <CANP3RGeX5=c=Lb+Pkg89zD7zQ_Z1T8oPJRCkorNCdghmofYXxg@mail.gmail.com>
Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
I am currently travelling and not able to investigate
until next week.
> commit ad8b1ffc3efae2f65080bdb11145c87d299b8f9a
> Author: Florian Westphal <fw@strlen.de>
> netfilter: ipv6: nf_defrag: drop skb dst before queueing
>
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -618,6 +618,8 @@ int nf_ct_frag6_gather(struct net *net, struct
> sk_buff *skb, u32 user)
> fq->q.meat == fq->q.len &&
> nf_ct_frag6_reasm(fq, skb, dev))
> ret = 0;
> + else
> + skb_dst_drop(skb);
This is only supposed to drop dst of skbs that are enqueued,
i.e. frag6_gather returns NF_STOLEN.
In case skb completes the queue, then that skbs dst_entry
is supposed to be kept, so skb_dst() does NOT return NULL.
Its not supposed to be any different than ipv4 defrag.
> const struct dst_entry *dst = skb_dst(skb); // returns NULL
That is not supposed to happen.
^ permalink raw reply
* Re: [PATCH] net-xfrm: add build time cfg option to PF_KEY SHA256 to use RFC4868-compliant truncation
From: Lorenzo Colitti @ 2018-10-16 8:14 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, David Miller, Steffen Klassert,
Herbert Xu, netdev
In-Reply-To: <20181016080634.139776-1-zenczykowski@gmail.com>
On Tue, Oct 16, 2018 at 5:06 PM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
> +config XFRM_HMAC_SHA256_RFC4868
> + bool "Strict RFC4868 hmac(sha256) 128-bit truncation"
> + depends on XFRM_ALGO
> + default n
> + ---help---
> + Support strict RFC4868 hmac(sha256) 128-bit truncation
> + (default on Android) instead of the default 96-bit Linux truncation.
Not sure it's worth mentioning Android here, given that other
contributors from other organizations have attempted to change this as
well.
> .uinfo = {
> .auth = {
> +#if IS_ENABLED(CONFIG_XFRM_HMAC_SHA256_RFC4868)
> + .icv_truncbits = 128,
> +#else
> .icv_truncbits = 96,
> +#endif
Also, consider adding a Tested: line saying that this allows
pf_key_test.py to pass on upstream kernels.
Other than that,
Acked-By: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [PATCH stable 4.9 v2 00/29] backport of IP fragmentation fixes
From: Greg Kroah-Hartman @ 2018-10-16 16:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Fainelli, netdev, David Miller, stable, sthemmin
In-Reply-To: <CANn89i++MZky_skYMHdBe1J-whLQjtdiHG77rUA0C=MnXLt9dw@mail.gmail.com>
On Mon, Oct 15, 2018 at 10:53:02AM -0700, Eric Dumazet wrote:
> On Mon, Oct 15, 2018 at 10:47 AM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >
> >
> > On 10/10/2018 12:29 PM, Florian Fainelli wrote:
> > > This is based on Stephen's v4.14 patches, with the necessary merge
> > > conflicts, and the lack of timer_setup() on the 4.9 baseline.
> > >
> > > Perf results on a gigabit capable system, before and after are below.
> > >
> > > Series can also be found here:
> > >
> > > https://github.com/ffainelli/linux/commits/fragment-stack-v4.9-v2
> > >
> > > Changes in v2:
> > >
> > > - drop "net: sk_buff rbnode reorg"
> > > - added original "ip: use rb trees for IP frag queue." commit
> >
> > Eric, does this look reasonable to you?
>
> Yes, thanks a lot Florian.
Wonderful, all now queued up, thanks!
greg k-h
^ permalink raw reply
* Re: [PATCH net-next] ixgbe: fix XFRM_ALGO dependency
From: Shannon Nelson @ 2018-10-16 16:35 UTC (permalink / raw)
To: Arnd Bergmann, Jeff Kirsher, David S. Miller, Steffen Klassert,
Herbert Xu
Cc: Jesse Brandeburg, Björn Töpel, Alexander Duyck,
intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20181016100848.1329843-1-arnd@arndb.de>
On 10/16/2018 3:03 AM, Arnd Bergmann wrote:
> When XFRM_ALGO is not enabled, the new igxge ipsec code produces a
> link error:
s/igxge/ixgbe/
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.o: In function `ixgbe_ipsec_vf_add_sa':
> ixgbe_ipsec.c:(.text+0x1266): undefined reference to `xfrm_aead_get_byname'
>
> Simply selectin XFRM_ALGO from here causes circular dependencies, so
s/selectin/selecting/
> to fix it, we probably want this slightly more complex solution that is
> similar to what other drivers with XFRM offload do:
>
> A separate Kconfig symbol now controls whether we include the ipsec
> offload code. To keep the old behavior, this is left as 'default y'. The
> dependency in XFRM_OFFLOAD still causes a circular dependency but is
> not actually needed because this symbol is not user visible, so removing
> that dependency on top makes it all work.
>
> Fixes: eda0333ac293 ("ixgbe: add VF IPsec management")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/ethernet/intel/Kconfig | 10 ++++++++++
> drivers/net/ethernet/intel/ixgbe/Makefile | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 8 ++++----
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +++---
> net/xfrm/Kconfig | 1 -
> 5 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/Kconfig b/drivers/net/ethernet/intel/Kconfig
> index b542aba6f0e8..d1db382d8299 100644
> --- a/drivers/net/ethernet/intel/Kconfig
> +++ b/drivers/net/ethernet/intel/Kconfig
> @@ -194,6 +194,16 @@ config IXGBE_DCB
>
> If unsure, say N.
>
> +config IXGBE_IPSEC
> + bool "IPSec XFRM cryptography-offload accelaration"
> + default n
remove this "default n" line?
> + depends on IXGBE
> + depends on XFRM_OFFLOAD
> + default y
> + select XFRM_ALGO
> + ---help---
> + Enable support for IPSec offload in ixgbe.ko
> +
> config IXGBEVF
> tristate "Intel(R) 10GbE PCI Express Virtual Function Ethernet support"
> depends on PCI_MSI
> diff --git a/drivers/net/ethernet/intel/ixgbe/Makefile b/drivers/net/ethernet/intel/ixgbe/Makefile
> index ca6b0c458e4a..4fb0d9e3f2da 100644
> --- a/drivers/net/ethernet/intel/ixgbe/Makefile
> +++ b/drivers/net/ethernet/intel/ixgbe/Makefile
> @@ -17,4 +17,4 @@ ixgbe-$(CONFIG_IXGBE_DCB) += ixgbe_dcb.o ixgbe_dcb_82598.o \
> ixgbe-$(CONFIG_IXGBE_HWMON) += ixgbe_sysfs.o
> ixgbe-$(CONFIG_DEBUG_FS) += ixgbe_debugfs.o
> ixgbe-$(CONFIG_FCOE:m=y) += ixgbe_fcoe.o
> -ixgbe-$(CONFIG_XFRM_OFFLOAD) += ixgbe_ipsec.o
> +ixgbe-$(CONFIG_IXGBE_IPSEC) += ixgbe_ipsec.o
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> index 7a7679e7be84..1d5d66436eac 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> @@ -770,9 +770,9 @@ struct ixgbe_adapter {
> #define IXGBE_RSS_KEY_SIZE 40 /* size of RSS Hash Key in bytes */
> u32 *rss_key;
>
> -#ifdef CONFIG_XFRM_OFFLOAD
> +#ifdef CONFIG_IXGBE_IPSEC
> struct ixgbe_ipsec *ipsec;
> -#endif /* CONFIG_XFRM_OFFLOAD */
> +#endif /* CONFIG_IXGBE_IPSEC */
You'll probably want to apply these changes to the ixgbevf code as well.
Cheers,
sln
>
> /* AF_XDP zero-copy */
> struct xdp_umem **xsk_umems;
> @@ -1009,7 +1009,7 @@ void ixgbe_store_key(struct ixgbe_adapter *adapter);
> void ixgbe_store_reta(struct ixgbe_adapter *adapter);
> s32 ixgbe_negotiate_fc(struct ixgbe_hw *hw, u32 adv_reg, u32 lp_reg,
> u32 adv_sym, u32 adv_asm, u32 lp_sym, u32 lp_asm);
> -#ifdef CONFIG_XFRM_OFFLOAD
> +#ifdef CONFIG_IXGBE_IPSEC
> void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter);
> void ixgbe_stop_ipsec_offload(struct ixgbe_adapter *adapter);
> void ixgbe_ipsec_restore(struct ixgbe_adapter *adapter);
> @@ -1037,5 +1037,5 @@ static inline int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter,
> u32 *mbuf, u32 vf) { return -EACCES; }
> static inline int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter,
> u32 *mbuf, u32 vf) { return -EACCES; }
> -#endif /* CONFIG_XFRM_OFFLOAD */
> +#endif /* CONFIG_IXGBE_IPSEC */
> #endif /* _IXGBE_H_ */
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index 0049a2becd7e..113b38e0defb 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -8694,7 +8694,7 @@ netdev_tx_t ixgbe_xmit_frame_ring(struct sk_buff *skb,
>
> #endif /* IXGBE_FCOE */
>
> -#ifdef CONFIG_XFRM_OFFLOAD
> +#ifdef CONFIG_IXGBE_IPSEC
> if (skb->sp && !ixgbe_ipsec_tx(tx_ring, first, &ipsec_tx))
> goto out_drop;
> #endif
> @@ -10190,7 +10190,7 @@ ixgbe_features_check(struct sk_buff *skb, struct net_device *dev,
> * the TSO, so it's the exception.
> */
> if (skb->encapsulation && !(features & NETIF_F_TSO_MANGLEID)) {
> -#ifdef CONFIG_XFRM_OFFLOAD
> +#ifdef CONFIG_IXGBE_IPSEC
> if (!skb->sp)
> #endif
> features &= ~NETIF_F_TSO;
> @@ -10883,7 +10883,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (hw->mac.type >= ixgbe_mac_82599EB)
> netdev->features |= NETIF_F_SCTP_CRC;
>
> -#ifdef CONFIG_XFRM_OFFLOAD
> +#ifdef CONFIG_IXGBE_IPSEC
> #define IXGBE_ESP_FEATURES (NETIF_F_HW_ESP | \
> NETIF_F_HW_ESP_TX_CSUM | \
> NETIF_F_GSO_ESP)
> diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig
> index 4a9ee2d83158..140270a13d54 100644
> --- a/net/xfrm/Kconfig
> +++ b/net/xfrm/Kconfig
> @@ -8,7 +8,6 @@ config XFRM
>
> config XFRM_OFFLOAD
> bool
> - depends on XFRM
>
> config XFRM_ALGO
> tristate
>
^ permalink raw reply
* Re: [PATCH net-next] net: aquantia: make function aq_fw2x_update_stats static
From: David Miller @ 2018-10-16 17:00 UTC (permalink / raw)
To: yuehaibing
Cc: igor.russkikh, nikita.danilov, linux-kernel, netdev, yana.esina,
andrew
In-Reply-To: <20181016105056.16452-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 16 Oct 2018 18:50:56 +0800
> Fixes the following sparse warning:
>
> drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c:282:5: warning:
> symbol 'aq_fw2x_update_stats' was not declared. Should it be static?
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* [PATCH 4.9 43/71] inet: frags: change inet_frags_init_net() return value
From: Greg Kroah-Hartman @ 2018-10-16 17:09 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, David S. Miller
In-Reply-To: <20181016170539.315587743@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
We will soon initialize one rhashtable per struct netns_frags
in inet_frags_init_net().
This patch changes the return value to eventually propagate an
error.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 787bea7748a76130566f881c2342a0be4127d182)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/inet_frag.h | 3 ++-
net/ieee802154/6lowpan/reassembly.c | 11 ++++++++---
net/ipv4/ip_fragment.c | 12 +++++++++---
net/ipv6/netfilter/nf_conntrack_reasm.c | 12 +++++++++---
net/ipv6/reassembly.c | 11 +++++++++--
5 files changed, 37 insertions(+), 12 deletions(-)
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -103,9 +103,10 @@ struct inet_frags {
int inet_frags_init(struct inet_frags *);
void inet_frags_fini(struct inet_frags *);
-static inline void inet_frags_init_net(struct netns_frags *nf)
+static inline int inet_frags_init_net(struct netns_frags *nf)
{
atomic_set(&nf->mem, 0);
+ return 0;
}
void inet_frags_exit_net(struct netns_frags *nf, struct inet_frags *f);
--- a/net/ieee802154/6lowpan/reassembly.c
+++ b/net/ieee802154/6lowpan/reassembly.c
@@ -580,14 +580,19 @@ static int __net_init lowpan_frags_init_
{
struct netns_ieee802154_lowpan *ieee802154_lowpan =
net_ieee802154_lowpan(net);
+ int res;
ieee802154_lowpan->frags.high_thresh = IPV6_FRAG_HIGH_THRESH;
ieee802154_lowpan->frags.low_thresh = IPV6_FRAG_LOW_THRESH;
ieee802154_lowpan->frags.timeout = IPV6_FRAG_TIMEOUT;
- inet_frags_init_net(&ieee802154_lowpan->frags);
-
- return lowpan_frags_ns_sysctl_register(net);
+ res = inet_frags_init_net(&ieee802154_lowpan->frags);
+ if (res < 0)
+ return res;
+ res = lowpan_frags_ns_sysctl_register(net);
+ if (res < 0)
+ inet_frags_exit_net(&ieee802154_lowpan->frags, &lowpan_frags);
+ return res;
}
static void __net_exit lowpan_frags_exit_net(struct net *net)
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -849,6 +849,8 @@ static void __init ip4_frags_ctl_registe
static int __net_init ipv4_frags_init_net(struct net *net)
{
+ int res;
+
/* Fragment cache limits.
*
* The fragment memory accounting code, (tries to) account for
@@ -874,9 +876,13 @@ static int __net_init ipv4_frags_init_ne
net->ipv4.frags.max_dist = 64;
- inet_frags_init_net(&net->ipv4.frags);
-
- return ip4_frags_ns_ctl_register(net);
+ res = inet_frags_init_net(&net->ipv4.frags);
+ if (res < 0)
+ return res;
+ res = ip4_frags_ns_ctl_register(net);
+ if (res < 0)
+ inet_frags_exit_net(&net->ipv4.frags, &ip4_frags);
+ return res;
}
static void __net_exit ipv4_frags_exit_net(struct net *net)
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -630,12 +630,18 @@ EXPORT_SYMBOL_GPL(nf_ct_frag6_gather);
static int nf_ct_net_init(struct net *net)
{
+ int res;
+
net->nf_frag.frags.high_thresh = IPV6_FRAG_HIGH_THRESH;
net->nf_frag.frags.low_thresh = IPV6_FRAG_LOW_THRESH;
net->nf_frag.frags.timeout = IPV6_FRAG_TIMEOUT;
- inet_frags_init_net(&net->nf_frag.frags);
-
- return nf_ct_frag6_sysctl_register(net);
+ res = inet_frags_init_net(&net->nf_frag.frags);
+ if (res < 0)
+ return res;
+ res = nf_ct_frag6_sysctl_register(net);
+ if (res < 0)
+ inet_frags_exit_net(&net->nf_frag.frags, &nf_frags);
+ return res;
}
static void nf_ct_net_exit(struct net *net)
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -709,13 +709,20 @@ static void ip6_frags_sysctl_unregister(
static int __net_init ipv6_frags_init_net(struct net *net)
{
+ int res;
+
net->ipv6.frags.high_thresh = IPV6_FRAG_HIGH_THRESH;
net->ipv6.frags.low_thresh = IPV6_FRAG_LOW_THRESH;
net->ipv6.frags.timeout = IPV6_FRAG_TIMEOUT;
- inet_frags_init_net(&net->ipv6.frags);
+ res = inet_frags_init_net(&net->ipv6.frags);
+ if (res < 0)
+ return res;
- return ip6_frags_ns_sysctl_register(net);
+ res = ip6_frags_ns_sysctl_register(net);
+ if (res < 0)
+ inet_frags_exit_net(&net->ipv6.frags, &ip6_frags);
+ return res;
}
static void __net_exit ipv6_frags_exit_net(struct net *net)
^ permalink raw reply
* [PATCH 4.9 45/71] inet: frags: refactor ipfrag_init()
From: Greg Kroah-Hartman @ 2018-10-16 17:09 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, David S. Miller
In-Reply-To: <20181016170539.315587743@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
We need to call inet_frags_init() before register_pernet_subsys(),
as a prereq for following patch ("inet: frags: use rhashtables for reassembly units")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 483a6e4fa055123142d8956866fe2aa9c98d546d)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ip_fragment.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -899,8 +899,6 @@ static struct pernet_operations ip4_frag
void __init ipfrag_init(void)
{
- ip4_frags_ctl_register();
- register_pernet_subsys(&ip4_frags_ops);
ip4_frags.hashfn = ip4_hashfn;
ip4_frags.constructor = ip4_frag_init;
ip4_frags.destructor = ip4_frag_free;
@@ -910,4 +908,6 @@ void __init ipfrag_init(void)
ip4_frags.frags_cache_name = ip_frag_cache_name;
if (inet_frags_init(&ip4_frags))
panic("IP: failed to allocate ip4_frags cache\n");
+ ip4_frags_ctl_register();
+ register_pernet_subsys(&ip4_frags_ops);
}
^ permalink raw reply
* [PATCH 4.9 46/71] inet: frags: refactor ipv6_frag_init()
From: Greg Kroah-Hartman @ 2018-10-16 17:09 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, David S. Miller
In-Reply-To: <20181016170539.315587743@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
We want to call inet_frags_init() earlier.
This is a prereq to "inet: frags: use rhashtables for reassembly units"
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5b975bab23615cd0fdf67af6c9298eb01c4b9f61)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/reassembly.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -740,10 +740,21 @@ int __init ipv6_frag_init(void)
{
int ret;
- ret = inet6_add_protocol(&frag_protocol, IPPROTO_FRAGMENT);
+ ip6_frags.hashfn = ip6_hashfn;
+ ip6_frags.constructor = ip6_frag_init;
+ ip6_frags.destructor = NULL;
+ ip6_frags.qsize = sizeof(struct frag_queue);
+ ip6_frags.match = ip6_frag_match;
+ ip6_frags.frag_expire = ip6_frag_expire;
+ ip6_frags.frags_cache_name = ip6_frag_cache_name;
+ ret = inet_frags_init(&ip6_frags);
if (ret)
goto out;
+ ret = inet6_add_protocol(&frag_protocol, IPPROTO_FRAGMENT);
+ if (ret)
+ goto err_protocol;
+
ret = ip6_frags_sysctl_register();
if (ret)
goto err_sysctl;
@@ -752,16 +763,6 @@ int __init ipv6_frag_init(void)
if (ret)
goto err_pernet;
- ip6_frags.hashfn = ip6_hashfn;
- ip6_frags.constructor = ip6_frag_init;
- ip6_frags.destructor = NULL;
- ip6_frags.qsize = sizeof(struct frag_queue);
- ip6_frags.match = ip6_frag_match;
- ip6_frags.frag_expire = ip6_frag_expire;
- ip6_frags.frags_cache_name = ip6_frag_cache_name;
- ret = inet_frags_init(&ip6_frags);
- if (ret)
- goto err_pernet;
out:
return ret;
@@ -769,6 +770,8 @@ err_pernet:
ip6_frags_sysctl_unregister();
err_sysctl:
inet6_del_protocol(&frag_protocol, IPPROTO_FRAGMENT);
+err_protocol:
+ inet_frags_fini(&ip6_frags);
goto out;
}
^ permalink raw reply
* [PATCH 4.9 47/71] inet: frags: refactor lowpan_net_frag_init()
From: Greg Kroah-Hartman @ 2018-10-16 17:09 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, David S. Miller
In-Reply-To: <20181016170539.315587743@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
We want to call lowpan_net_frag_init() earlier.
Similar to commit "inet: frags: refactor ipv6_frag_init()"
This is a prereq to "inet: frags: use rhashtables for reassembly units"
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 807f1844df4ac23594268fa9f41902d0549e92aa)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ieee802154/6lowpan/reassembly.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- a/net/ieee802154/6lowpan/reassembly.c
+++ b/net/ieee802154/6lowpan/reassembly.c
@@ -614,14 +614,6 @@ int __init lowpan_net_frag_init(void)
{
int ret;
- ret = lowpan_frags_sysctl_register();
- if (ret)
- return ret;
-
- ret = register_pernet_subsys(&lowpan_frags_ops);
- if (ret)
- goto err_pernet;
-
lowpan_frags.hashfn = lowpan_hashfn;
lowpan_frags.constructor = lowpan_frag_init;
lowpan_frags.destructor = NULL;
@@ -631,11 +623,21 @@ int __init lowpan_net_frag_init(void)
lowpan_frags.frags_cache_name = lowpan_frags_cache_name;
ret = inet_frags_init(&lowpan_frags);
if (ret)
- goto err_pernet;
+ goto out;
+
+ ret = lowpan_frags_sysctl_register();
+ if (ret)
+ goto err_sysctl;
+ ret = register_pernet_subsys(&lowpan_frags_ops);
+ if (ret)
+ goto err_pernet;
+out:
return ret;
err_pernet:
lowpan_frags_sysctl_unregister();
+err_sysctl:
+ inet_frags_fini(&lowpan_frags);
return ret;
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox