* Re: [PATCH] net: ethernet: broadcom: bcm63xx_enet: Remove unneeded memset
From: David Miller @ 2019-07-02 2:29 UTC (permalink / raw)
To: hariprasad.kelam
Cc: f.fainelli, bcm-kernel-feedback-list, andrew, gregkh, yuehaibing,
tglx, mcgrof, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20190630142949.GA7422@hari-Inspiron-1545>
From: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Date: Sun, 30 Jun 2019 19:59:49 +0530
> Remove unneeded memset as alloc_etherdev is using kvzalloc which uses
> __GFP_ZERO flag
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/7] net/rds: Wait for the FRMR_IS_FREE (or FRMR_IS_STALE) transition after posting IB_WR_LOCAL_INV
From: santosh.shilimkar @ 2019-07-02 2:28 UTC (permalink / raw)
To: Gerd Rausch, netdev; +Cc: David Miller
In-Reply-To: <14c34ac2-38ed-9d51-f27d-74120ff34c54@oracle.com>
On 7/1/19 2:06 PM, Gerd Rausch wrote:
> Hi Santosh,
>
> On 01/07/2019 14.00, santosh.shilimkar@oracle.com wrote:
>>>
>> Look for command timeout in CX3 sources. 60 second is upper bound in
>> CX3. Its not standard in specs(at least not that I know) though
>> and may vary from vendor to vendor.
>>
>
> I am not seeing it. Can you point me to the right place?
>
Below. All command timeouts are 60 seconds.
enum {
MLX4_CMD_TIME_CLASS_A = 60000,
MLX4_CMD_TIME_CLASS_B = 60000,
MLX4_CMD_TIME_CLASS_C = 60000,
};
But having said that, I re-looked the code you are patching
and thats actually only FRWR code which is purely work-request
based so this command timeout shouldn't matter.
If the work request fails, then it will lead to flush errors and
MRs will be marked as STALE. So this wait may not be necessary
There is a socket call RDS_GET_MR which needs to be synchronous
and that Avinash has actually fixed by making this MR registration
processes synchronous. Inline registration is still kept async.
RDS_GET_MR case is what actually showing the issue you saw
and the fix for that Avinash has it in production kernel.
I believe with that change, registration issue becomes non-issue
already.
And as far as invalidation concerned with proxy qp, it not longer
races with data path qp.
May be you can try those changes if not already to see if it
addresses the couple of cases where you ended up adding
timeouts.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH 0/3, net-next, v2] net: netsec: Add XDP Support
From: David Miller @ 2019-07-02 2:27 UTC (permalink / raw)
To: ilias.apalodimas
Cc: netdev, jaswinder.singh, ard.biesheuvel, bjorn.topel,
magnus.karlsson, brouer, daniel, ast, makita.toshiaki,
jakub.kicinski, john.fastabend, maciejromanfijalkowski
In-Reply-To: <1561785805-21647-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Sat, 29 Jun 2019 08:23:22 +0300
> This is a respin of https://www.spinics.net/lists/netdev/msg526066.html
> Since page_pool API fixes are merged into net-next we can now safely use
> it's DMA mapping capabilities.
>
> First patch changes the buffer allocation from napi/netdev_alloc_frag()
> to page_pool API. Although this will lead to slightly reduced performance
> (on raw packet drops only) we can use the API for XDP buffer recycling.
> Another side effect is a slight increase in memory usage, due to using a
> single page per packet.
>
> The second patch adds XDP support on the driver.
> There's a bunch of interesting options that come up due to the single
> Tx queue.
> Locking is needed(to avoid messing up the Tx queues since ndo_xdp_xmit
> and the normal stack can co-exist). We also need to track down the
> 'buffer type' for TX and properly free or recycle the packet depending
> on it's nature.
>
>
> Changes since RFC:
> - Bug fixes from Jesper and Maciej
> - Added page pool API to retrieve the DMA direction
>
> Changes since v1:
> - Use page_pool_free correctly if xdp_rxq_info_reg() failed
Series applied, thanks.
I realize from the discussion on patch #3 there will be follow-ups to this.
^ permalink raw reply
* Re: [PATCH net] net/tls: make sure offload also gets the keys wiped
From: David Miller @ 2019-07-02 2:23 UTC (permalink / raw)
To: jakub.kicinski
Cc: john.fastabend, netdev, oss-drivers, alexei.starovoitov, sd,
dirk.vandermerwe
In-Reply-To: <20190628231139.16842-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 28 Jun 2019 16:11:39 -0700
> Commit 86029d10af18 ("tls: zero the crypto information from tls_context
> before freeing") added memzero_explicit() calls to clear the key material
> before freeing struct tls_context, but it missed tls_device.c has its
> own way of freeing this structure. Replace the missing free.
>
> Fixes: 86029d10af18 ("tls: zero the crypto information from tls_context before freeing")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net/tls: reject offload of TLS 1.3
From: David Miller @ 2019-07-02 2:22 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, borisp, alexei.starovoitov, dirk.vandermerwe
In-Reply-To: <20190628230759.16360-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 28 Jun 2019 16:07:59 -0700
> Neither drivers nor the tls offload code currently supports TLS
> version 1.3. Check the TLS version when installing connection
> state. TLS 1.3 will just fallback to the kernel crypto for now.
>
> Fixes: 130b392c6cd6 ("net: tls: Add tls 1.3 support")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied and queued up for v5.1+ -stable.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: added tdc tests for prio qdisc
From: David Miller @ 2019-07-02 2:21 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1561757521-15439-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Fri, 28 Jun 2019 17:32:01 -0400
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Fix batched event generation for mirred action
From: David Miller @ 2019-07-02 2:18 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1561746618-29349-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Fri, 28 Jun 2019 14:30:16 -0400
> When adding or deleting a batch of entries, the kernel sends upto
> TCA_ACT_MAX_PRIO entries in an event to user space. However it does not
> consider that the action sizes may vary and require different skb sizes.
>
> For example :
>
> % cat tc-batch.sh
> TC="sudo /mnt/iproute2.git/tc/tc"
>
> $TC actions flush action mirred
> for i in `seq 1 $1`;
> do
> cmd="action mirred egress redirect dev lo index $i "
> args=$args$cmd
> done
> $TC actions add $args
> %
> % ./tc-batch.sh 32
> Error: Failed to fill netlink attributes while adding TC action.
> We have an error talking to the kernel
> %
>
> patch 1 adds callback in tc_action_ops of mirred action, which calculates
> the action size, and passes size to tcf_add_notify()/tcf_del_notify().
>
> patch 2 updates the TDC test suite with relevant test cases.
Series applied, thanks.
^ permalink raw reply
* Re: [Patch net 0/3] idr: fix overflow cases on 32-bit CPU
From: David Miller @ 2019-07-02 2:16 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, dcaratti, chrism, willy
In-Reply-To: <20190628180343.8230-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 28 Jun 2019 11:03:40 -0700
> idr_get_next_ul() is problematic by design, it can't handle
> the following overflow case well on 32-bit CPU:
>
> u32 id = UINT_MAX;
> idr_alloc_u32(&id);
> while (idr_get_next_ul(&id) != NULL)
> id++;
>
> when 'id' overflows and becomes 0 after UINT_MAX, the loop
> goes infinite.
>
> Fix this by eliminating external users of idr_get_next_ul()
> and migrating them to idr_for_each_entry_continue_ul(). And
> add an additional parameter for these iteration macros to detect
> overflow properly.
>
> Please merge this through networking tree, as all the users
> are in networking subsystem.
Series applied, thanks Cong.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-07-02 2:13 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Matteo Croce,
Florian Westphal
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/devinet.c
between commit:
2e6054636816 ("ipv4: don't set IPv6 only flags to IPv4 addresses")
from the net tree and commit:
2638eb8b50cf ("net: ipv4: provide __rcu annotation for ifa_list")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/devinet.c
index c5ebfa199794,137d1892395d..000000000000
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@@ -473,11 -482,10 +487,13 @@@ static int __inet_insert_ifa(struct in_
ifa->ifa_flags &= ~IFA_F_SECONDARY;
last_primary = &in_dev->ifa_list;
+ /* Don't set IPv6 only flags to IPv4 addresses */
+ ifa->ifa_flags &= ~IPV6ONLY_FLAGS;
+
- for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
- ifap = &ifa1->ifa_next) {
+ ifap = &in_dev->ifa_list;
+ ifa1 = rtnl_dereference(*ifap);
+
+ while (ifa1) {
if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
ifa->ifa_scope <= ifa1->ifa_scope)
last_primary = &ifa1->ifa_next;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next 1/1] tipc: embed jiffies in macro TIPC_BC_RETR_LIM
From: David Miller @ 2019-07-02 2:12 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1561734380-26868-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Fri, 28 Jun 2019 17:06:20 +0200
> The macro TIPC_BC_RETR_LIM is always used in combination with 'jiffies',
> so we can just as well perform the addition in the macro itself. This
> way, we get a few shorter code lines and one less line break.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] hinic: implement the statistical interface of ethtool
From: Jakub Kicinski @ 2019-07-02 2:12 UTC (permalink / raw)
To: Xue Chaojing
Cc: davem, linux-kernel, netdev, luoshaokai, cloud.wangxiaoyun,
chiqijun, wulike1, Stephen Hemminger
In-Reply-To: <20190624120519.4ec22e19@cakuba.netronome.com>
On Mon, 24 Jun 2019 12:05:19 -0700, Jakub Kicinski wrote:
> On Mon, 24 Jun 2019 03:50:12 +0000, Xue Chaojing wrote:
> > diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> > index be28a9a7f033..8d98f37c88a8 100644
> > --- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> > +++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> > @@ -438,6 +438,344 @@ static u32 hinic_get_rxfh_indir_size(struct net_device *netdev)
> > return HINIC_RSS_INDIR_SIZE;
> > }
> >
> > +#define ARRAY_LEN(arr) ((int)((int)sizeof(arr) / (int)sizeof(arr[0])))
> > +
> > +#define HINIC_NETDEV_STAT(_stat_item) { \
> > + .name = #_stat_item, \
> > + .size = FIELD_SIZEOF(struct rtnl_link_stats64, _stat_item), \
> > + .offset = offsetof(struct rtnl_link_stats64, _stat_item) \
> > +}
> > +
> > +static struct hinic_stats hinic_netdev_stats[] = {
> > + HINIC_NETDEV_STAT(rx_packets),
> > + HINIC_NETDEV_STAT(tx_packets),
> > + HINIC_NETDEV_STAT(rx_bytes),
> > + HINIC_NETDEV_STAT(tx_bytes),
> > + HINIC_NETDEV_STAT(rx_errors),
> > + HINIC_NETDEV_STAT(tx_errors),
> > + HINIC_NETDEV_STAT(rx_dropped),
> > + HINIC_NETDEV_STAT(tx_dropped),
> > + HINIC_NETDEV_STAT(multicast),
> > + HINIC_NETDEV_STAT(collisions),
> > + HINIC_NETDEV_STAT(rx_length_errors),
> > + HINIC_NETDEV_STAT(rx_over_errors),
> > + HINIC_NETDEV_STAT(rx_crc_errors),
> > + HINIC_NETDEV_STAT(rx_frame_errors),
> > + HINIC_NETDEV_STAT(rx_fifo_errors),
> > + HINIC_NETDEV_STAT(rx_missed_errors),
> > + HINIC_NETDEV_STAT(tx_aborted_errors),
> > + HINIC_NETDEV_STAT(tx_carrier_errors),
> > + HINIC_NETDEV_STAT(tx_fifo_errors),
> > + HINIC_NETDEV_STAT(tx_heartbeat_errors),
> > +};
>
> I think we wanted to stop duplicating standard netdev stats in ethtool
> -S. Chaojing please post a patch to remove this part, the other stats
> are good.
Please address this comment or I will send a revert of the entire patch.
^ permalink raw reply
* Re: [PATCH] netlink: use 48 byte ctx instead of 6 signed longs for callback
From: David Miller @ 2019-07-02 2:12 UTC (permalink / raw)
To: johannes; +Cc: Jason, netdev, linux-kernel
In-Reply-To: <0092b0b405e02ac7401ceaad2ea650abc44559ea.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 28 Jun 2019 16:42:26 +0200
> On Fri, 2019-06-28 at 16:40 +0200, Jason A. Donenfeld wrote:
>> People are inclined to stuff random things into cb->args[n] because it
>> looks like an array of integers. Sometimes people even put u64s in there
>> with comments noting that a certain member takes up two slots. The
>> horror! Really this should mirror the usage of skb->cb, which are just
>> 48 opaque bytes suitable for casting a struct. Then people can create
>> their usual casting macros for accessing strongly typed members of a
>> struct.
>>
>> As a plus, this also gives us the same amount of space on 32bit and 64bit.
>>
>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>> Cc: Johannes Berg <johannes@sipsolutions.net>
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net v3] vxlan: do not destroy fdb if register_netdevice() is failed
From: David Miller @ 2019-07-02 2:06 UTC (permalink / raw)
To: ap420073; +Cc: roopa, petrm, netdev
In-Reply-To: <20190628050725.9445-1-ap420073@gmail.com>
From: Taehee Yoo <ap420073@gmail.com>
Date: Fri, 28 Jun 2019 14:07:25 +0900
> __vxlan_dev_create() destroys FDB using specific pointer which indicates
> a fdb when error occurs.
> But that pointer should not be used when register_netdevice() fails because
> register_netdevice() internally destroys fdb when error occurs.
>
> This patch makes vxlan_fdb_create() to do not link fdb entry to vxlan dev
> internally.
> Instead, a new function vxlan_fdb_insert() is added to link fdb to vxlan
> dev.
>
> vxlan_fdb_insert() is called after calling register_netdevice().
> This routine can avoid situation that ->ndo_uninit() destroys fdb entry
> in error path of register_netdevice().
> Hence, error path of __vxlan_dev_create() routine can have an opportunity
> to destroy default fdb entry by hand.
>
> Test command
> ip link add bonding_masters type vxlan id 0 group 239.1.1.1 \
> dev enp0s9 dstport 4789
>
> Splat looks like:
...
> Fixes: 0241b836732f ("vxlan: fix default fdb entry netlink notify ordering during netdev create")
> Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net-next] net/ipv6: Fix misuse of proc_dointvec "flowlabel_reflect"
From: David Miller @ 2019-07-02 2:05 UTC (permalink / raw)
To: devel; +Cc: edumazet, kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <20190628023714.1923-1-devel@etsukata.com>
From: Eiichi Tsukata <devel@etsukata.com>
Date: Fri, 28 Jun 2019 11:37:14 +0900
> /proc/sys/net/ipv6/flowlabel_reflect assumes written value to be in the
> range of 0 to 3. Use proc_dointvec_minmax instead of proc_dointvec.
>
> Fixes: 323a53c41292 ("ipv6: tcp: enable flowlabel reflection in some RST packets")
> Signed-off-by: Eiichi Tsukata <devel@etsukata.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: link_watch: prevent starvation when processing linkwatch wq
From: David Miller @ 2019-07-02 2:03 UTC (permalink / raw)
To: linyunsheng
Cc: hkallweit1, gregkh, tglx, netdev, linux-kernel, pbonzini, rkrcmar,
kvm
In-Reply-To: <1561684399-235123-1-git-send-email-linyunsheng@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Fri, 28 Jun 2019 09:13:19 +0800
> When user has configured a large number of virtual netdev, such
> as 4K vlans, the carrier on/off operation of the real netdev
> will also cause it's virtual netdev's link state to be processed
> in linkwatch. Currently, the processing is done in a work queue,
> which may cause rtnl locking starvation problem and worker
> starvation problem for other work queue, such as irqfd_inject wq.
>
> This patch releases the cpu when link watch worker has processed
> a fixed number of netdev' link watch event, and schedule the
> work queue again when there is still link watch event remaining.
>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
> V2: use cond_resched and rtnl_unlock after processing a fixed
> number of events
> V3: fall back to v1 and change commit log to reflect that.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: fix error handling on stream scheduler initialization
From: David Miller @ 2019-07-02 2:02 UTC (permalink / raw)
To: marcelo.leitner; +Cc: netdev, lucien.xin, nhorman, linux-sctp, hdanton
In-Reply-To: <bcbc85604e53843a731a79df620d5f92b194d085.1561675505.git.marcelo.leitner@gmail.com>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Thu, 27 Jun 2019 19:48:10 -0300
> It allocates the extended area for outbound streams only on sendmsg
> calls, if they are not yet allocated. When using the priority
> stream scheduler, this initialization may imply into a subsequent
> allocation, which may fail. In this case, it was aborting the stream
> scheduler initialization but leaving the ->ext pointer (allocated) in
> there, thus in a partially initialized state. On a subsequent call to
> sendmsg, it would notice the ->ext pointer in there, and trip on
> uninitialized stuff when trying to schedule the data chunk.
>
> The fix is undo the ->ext initialization if the stream scheduler
> initialization fails and avoid the partially initialized state.
>
> Although syzkaller bisected this to commit 4ff40b86262b ("sctp: set
> chunk transport correctly when it's a new asoc"), this bug was actually
> introduced on the commit I marked below.
>
> Reported-by: syzbot+c1a380d42b190ad1e559@syzkaller.appspotmail.com
> Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
> Tested-by: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [Patch net] netrom: fix a memory leak in nr_rx_frame()
From: David Miller @ 2019-07-02 2:01 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, syzbot+d6636a36d3c34bd88938
In-Reply-To: <20190627213058.3028-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 27 Jun 2019 14:30:58 -0700
> When the skb is associated with a new sock, just assigning
> it to skb->sk is not sufficient, we have to set its destructor
> to free the sock properly too.
>
> Reported-by: syzbot+d6636a36d3c34bd88938@syzkaller.appspotmail.com
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 00/16] mlxsw: PTP timestamping support
From: David Miller @ 2019-07-02 1:59 UTC (permalink / raw)
To: idosch; +Cc: netdev, richardcochran, jiri, petrm, mlxsw, idosch
In-Reply-To: <20190630060500.7882-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Sun, 30 Jun 2019 09:04:44 +0300
> This is the second patchset adding PTP support in mlxsw. Next patchset
> will add PTP shapers which are required to maintain accuracy under rates
> lower than 40Gb/s, while subsequent patchsets will add tracepoints and
> selftests.
...
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Andy Lutomirski @ 2019-07-02 1:59 UTC (permalink / raw)
To: Song Liu
Cc: Andy Lutomirski, linux-security@vger.kernel.org, Networking, bpf,
Alexei Starovoitov, Daniel Borkmann, Kernel Team, Lorenz Bauer,
Jann Horn, Greg KH, Linux API, Kees Cook
In-Reply-To: <0DE7F23E-9CD2-4F03-82B5-835506B59056@fb.com>
On Mon, Jul 1, 2019 at 2:03 AM Song Liu <songliubraving@fb.com> wrote:
>
> Hi Andy,
>
> Thanks for these detailed analysis.
>
> > On Jun 30, 2019, at 8:12 AM, Andy Lutomirski <luto@kernel.org> wrote:
> >
> > On Fri, Jun 28, 2019 at 12:05 PM Song Liu <songliubraving@fb.com> wrote:
> >>
> >> Hi Andy,
> >>
> >>> On Jun 27, 2019, at 4:40 PM, Andy Lutomirski <luto@kernel.org> wrote:
> >>>
> >>> On 6/27/19 1:19 PM, Song Liu wrote:
> >>>> This patch introduce unprivileged BPF access. The access control is
> >>>> achieved via device /dev/bpf. Users with write access to /dev/bpf are able
> >>>> to call sys_bpf().
> >>>> Two ioctl command are added to /dev/bpf:
> >>>> The two commands enable/disable permission to call sys_bpf() for current
> >>>> task. This permission is noted by bpf_permitted in task_struct. This
> >>>> permission is inherited during clone(CLONE_THREAD).
> >>>> Helper function bpf_capable() is added to check whether the task has got
> >>>> permission via /dev/bpf.
> >>>
> >>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >>>> index 0e079b2298f8..79dc4d641cf3 100644
> >>>> --- a/kernel/bpf/verifier.c
> >>>> +++ b/kernel/bpf/verifier.c
> >>>> @@ -9134,7 +9134,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr,
> >>>> env->insn_aux_data[i].orig_idx = i;
> >>>> env->prog = *prog;
> >>>> env->ops = bpf_verifier_ops[env->prog->type];
> >>>> - is_priv = capable(CAP_SYS_ADMIN);
> >>>> + is_priv = bpf_capable(CAP_SYS_ADMIN);
> >>>
> >>> Huh? This isn't a hardening measure -- the "is_priv" verifier mode allows straight-up leaks of private kernel state to user mode.
> >>>
> >>> (For that matter, the pending lockdown stuff should possibly consider this a "confidentiality" issue.)
> >>>
> >>>
> >>> I have a bigger issue with this patch, though: it's a really awkward way to pretend to have capabilities. For bpf, it seems like you could make this be a *real* capability without too much pain since there's only one syscall there. Just find a way to pass an fd to /dev/bpf into the syscall. If this means you need a new bpf_with_cap() syscall that takes an extra argument, so be it. The old bpf() syscall can just translate to bpf_with_cap(..., -1).
> >>>
> >>> For a while, I've considered a scheme I call "implicit rights". There would be a directory in /dev called /dev/implicit_rights. This would either be part of devtmpfs or a whole new filesystem -- it would *not* be any other filesystem. The contents would be files that can't be read or written and exist only in memory. You create them with a privileged syscall. Certain actions that are sensitive but not at the level of CAP_SYS_ADMIN (use of large-attack-surface bpf stuff, creation of user namespaces, profiling the kernel, etc) could require an "implicit right". When you do them, if you don't have CAP_SYS_ADMIN, the kernel would do a path walk for, say, /dev/implicit_rights/bpf and, if the object exists, can be opened, and actually refers to the "bpf" rights object, then the action is allowed. Otherwise it's denied.
> >>>
> >>> This is extensible, and it doesn't require the rather ugly per-task state of whether it's enabled.
> >>>
> >>> For things like creation of user namespaces, there's an existing API, and the default is that it works without privilege. Switching it to an implicit right has the benefit of not requiring code changes to programs that already work as non-root.
> >>>
> >>> But, for BPF in particular, this type of compatibility issue doesn't exist now. You already can't use most eBPF functionality without privilege. New bpf-using programs meant to run without privilege are *new*, so they can use a new improved API. So, rather than adding this obnoxious ioctl, just make the API explicit, please.
> >>>
> >>> Also, please cc: linux-abi next time.
> >>
> >> Thanks for your inputs.
> >>
> >> I think we need to clarify the use case here. In this case, we are NOT
> >> thinking about creating new tools for unprivileged users. Instead, we
> >> would like to use existing tools without root.
> >
> > I read patch 4, and I interpret it very differently. Patches 2-4 are
> > creating a new version of libbpf and a new version of bpftool. Given
> > this, I see no real justification for adding a new in-kernel per-task
> > state instead of just pushing the complexity into libbpf.
>
> I am not sure whether we are on the same page. Let me try an example,
> say we have application A, which calls sys_bpf().
>
> Before the series: we have to run A with root;
> After the series: we add a special user with access to /dev/bpf, and
> run A with this special user.
>
> If we look at the whole system, I would say we are more secure after
> the series.
>
> I am not trying to make an extreme example here, because this use case
> is the motivation here.
>
> To stay safe, we have to properly manage the permission of /dev/bpf.
> This is just like we need to properly manage access to /etc/sudoers and
> /dev/mem.
>
> Does this make sense?
>
I think I'm understanding your motivation. You're not trying to make
bpf() generically usable without privilege -- you're trying to create
a way to allow certain users to access dangerous bpf functionality
within some limits.
That's a perfectly fine goal, but I think you're reinventing the
wheel, and the wheel you're reinventing is quite complicated and
already exists. I think you should teach bpftool to be secure when
installed setuid root or with fscaps enabled and put your policy in
bpftool. If you want to harden this a little bit, it would seem
entirely reasonable to add a new CAP_BPF_ADMIN and change some, but
not all, of the capable() checks to check CAP_BPF_ADMIN instead of the
capabilities that they currently check.
Your example of /etc/sudoers is apt, and it does not involve any
kernel support :)
^ permalink raw reply
* Re: [PATCH RESEND 4.9.y] net: check before dereferencing netdev_ops during busy poll
From: Josh Elsasser @ 2019-07-02 1:56 UTC (permalink / raw)
To: David Miller; +Cc: stable, gregkh, netdev, edumazet, mcroce
In-Reply-To: <20190701.185156.2142325894415755085.davem@davemloft.net>
On Jul 1, 2019, at 6:51 PM, David Miller <davem@davemloft.net> wrote:
> I just tried to apply this with "git am" to the current v4.19 -stable
> branch and it failed.
This is only needed for the v4.9 stable kernel, ndo_busy_poll (and this NPE)
went away in kernel 4.11.
Sorry, I probably should have called that out more explicitly.
^ permalink raw reply
* [PATCH v5] net: netfilter: Fix rpfilter dropping vrf packets by mistake
From: Miaohe Lin @ 2019-07-02 3:59 UTC (permalink / raw)
To: pablo, kadlec, fw, davem, kuznet, yoshfuji, netfilter-devel,
coreteam, netdev, linux-kernel
Cc: linmiaohe, mingfangsen
When firewalld is enabled with ipv4/ipv6 rpfilter, vrf
ipv4/ipv6 packets will be dropped. Vrf device will pass
through netfilter hook twice. One with enslaved device
and another one with l3 master device. So in device may
dismatch witch out device because out device is always
enslaved device.So failed with the check of the rpfilter
and drop the packets by mistake.
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
net/ipv4/netfilter/ipt_rpfilter.c | 1 +
net/ipv6/netfilter/ip6t_rpfilter.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index 59031670b16a..cc23f1ce239c 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -78,6 +78,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
flow.flowi4_tos = RT_TOS(iph->tos);
flow.flowi4_scope = RT_SCOPE_UNIVERSE;
+ flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par));
return rpfilter_lookup_reverse(xt_net(par), &flow, xt_in(par), info->flags) ^ invert;
}
diff --git a/net/ipv6/netfilter/ip6t_rpfilter.c b/net/ipv6/netfilter/ip6t_rpfilter.c
index 6bcaf7357183..d800801a5dd2 100644
--- a/net/ipv6/netfilter/ip6t_rpfilter.c
+++ b/net/ipv6/netfilter/ip6t_rpfilter.c
@@ -55,7 +55,9 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
if (rpfilter_addr_linklocal(&iph->saddr)) {
lookup_flags |= RT6_LOOKUP_F_IFACE;
fl6.flowi6_oif = dev->ifindex;
- } else if ((flags & XT_RPFILTER_LOOSE) == 0)
+ /* Set flowi6_oif for vrf devices to lookup route in l3mdev domain. */
+ } else if (netif_is_l3_master(dev) || netif_is_l3_slave(dev) ||
+ (flags & XT_RPFILTER_LOOSE) == 0)
fl6.flowi6_oif = dev->ifindex;
rt = (void *)ip6_route_lookup(net, &fl6, skb, lookup_flags);
@@ -70,7 +72,9 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
goto out;
}
- if (rt->rt6i_idev->dev == dev || (flags & XT_RPFILTER_LOOSE))
+ if (rt->rt6i_idev->dev == dev ||
+ l3mdev_master_ifindex_rcu(rt->rt6i_idev->dev) == dev->ifindex ||
+ (flags & XT_RPFILTER_LOOSE))
ret = true;
out:
ip6_rt_put(rt);
--
2.21.GIT
^ permalink raw reply related
* Re: [PATCH RESEND 4.9.y] net: check before dereferencing netdev_ops during busy poll
From: David Miller @ 2019-07-02 1:51 UTC (permalink / raw)
To: jelsasser; +Cc: stable, gregkh, netdev, edumazet, mcroce
In-Reply-To: <20190701234143.72631-1-jelsasser@appneta.com>
From: Josh Elsasser <jelsasser@appneta.com>
Date: Mon, 1 Jul 2019 16:41:43 -0700
> No changes since V2[1], resent as per discussiond on -stable[2]. I hope
> this is the correct way to send net fixes for older LTS releases, I'm
> going off of the latest netdev FAQ:
I just tried to apply this with "git am" to the current v4.19 -stable
branch and it failed.
[davem@localhost linux-stable]$ git am --signoff diff
Applying: net: check before dereferencing netdev_ops during busy poll
error: patch failed: net/core/dev.c:5083
error: net/core/dev.c: patch does not apply
Patch failed at 0001 net: check before dereferencing netdev_ops during busy poll
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
^ permalink raw reply
* [PATCH V4] can: flexcan: fix stop mode acknowledgment
From: Joakim Zhang @ 2019-07-02 1:45 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx,
Joakim Zhang
To enter stop mode, the CPU should manually assert a global Stop Mode
request and check the acknowledgment asserted by FlexCAN. The CPU must
only consider the FlexCAN in stop mode when both request and
acknowledgment conditions are satisfied.
Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
ChangeLog:
V1->V2:
* regmap_read()-->regmap_read_poll_timeout()
V2->V3:
* change the way of error return, it will make easy for function
extension.
V3->V4:
* rebase to linux-next/master, as this is a fix.
---
drivers/net/can/flexcan.c | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 1c66fb2ad76b..bf1bd6f5dbb1 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -400,9 +400,10 @@ static void flexcan_enable_wakeup_irq(struct flexcan_priv *priv, bool enable)
priv->write(reg_mcr, ®s->mcr);
}
-static inline void flexcan_enter_stop_mode(struct flexcan_priv *priv)
+static inline int flexcan_enter_stop_mode(struct flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
+ unsigned int ackval;
u32 reg_mcr;
reg_mcr = priv->read(®s->mcr);
@@ -412,20 +413,37 @@ static inline void flexcan_enter_stop_mode(struct flexcan_priv *priv)
/* enable stop request */
regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
+
+ /* get stop acknowledgment */
+ if (regmap_read_poll_timeout(priv->stm.gpr, priv->stm.ack_gpr,
+ ackval, ackval & (1 << priv->stm.ack_bit),
+ 0, FLEXCAN_TIMEOUT_US))
+ return -ETIMEDOUT;
+
+ return 0;
}
-static inline void flexcan_exit_stop_mode(struct flexcan_priv *priv)
+static inline int flexcan_exit_stop_mode(struct flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
+ unsigned int ackval;
u32 reg_mcr;
/* remove stop request */
regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
1 << priv->stm.req_bit, 0);
+ /* get stop acknowledgment */
+ if (regmap_read_poll_timeout(priv->stm.gpr, priv->stm.ack_gpr,
+ ackval, !(ackval & (1 << priv->stm.ack_bit)),
+ 0, FLEXCAN_TIMEOUT_US))
+ return -ETIMEDOUT;
+
reg_mcr = priv->read(®s->mcr);
reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
priv->write(reg_mcr, ®s->mcr);
+
+ return 0;
}
static inline void flexcan_error_irq_enable(const struct flexcan_priv *priv)
@@ -1615,7 +1633,9 @@ static int __maybe_unused flexcan_suspend(struct device *device)
*/
if (device_may_wakeup(device)) {
enable_irq_wake(dev->irq);
- flexcan_enter_stop_mode(priv);
+ err = flexcan_enter_stop_mode(priv);
+ if (err)
+ return err;
} else {
err = flexcan_chip_disable(priv);
if (err)
@@ -1665,10 +1685,13 @@ static int __maybe_unused flexcan_noirq_resume(struct device *device)
{
struct net_device *dev = dev_get_drvdata(device);
struct flexcan_priv *priv = netdev_priv(dev);
+ int err;
if (netif_running(dev) && device_may_wakeup(device)) {
flexcan_enable_wakeup_irq(priv, false);
- flexcan_exit_stop_mode(priv);
+ err = flexcan_exit_stop_mode(priv);
+ if (err)
+ return err;
}
return 0;
--
2.17.1
^ permalink raw reply related
* Re: Re: [PATCH v4] net: netfilter: Fix rpfilter dropping vrf packets by mistake
From: linmiaohe @ 2019-07-02 1:36 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Ahern, kadlec@blackhole.kfki.hu, fw@strlen.de,
davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mingfangsen
On Sat, July 2, 2019 at 02:02:59AM, Pablo wrote:
>
> Probably this?
>
> } else if (netif_is_l3_master(dev) || netif_is_l3_slave(dev) ||
> (flags & XT_RPFILTER_LOOSE) == 0) {
> fl6.flowi6_oif = dev->ifindex;
> }
>
> Thanks.
I would send patch v5 according to this. Many Thanks.
Have a nice day.
Best wishes.
^ permalink raw reply
* Re: [PATCH bpf-next] virtio_net: add XDP meta data support
From: Yuya Kusakabe @ 2019-07-02 1:00 UTC (permalink / raw)
To: Jason Wang, davem
Cc: Michael S. Tsirkin, Alexei Starovoitov, Daniel Borkmann,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Martin KaFai Lau, Song Liu, Yonghong Song, netdev
In-Reply-To: <fe3070db-ec3a-9c7c-e15e-93032811767f@redhat.com>
On 7/1/19 6:30 PM, Jason Wang wrote:
>
> On 2019/6/27 下午4:06, Yuya Kusakabe wrote:
>> This adds XDP meta data support to both receive_small() and
>> receive_mergeable().
>>
>> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
>> Signed-off-by: Yuya Kusakabe <yuya.kusakabe@gmail.com>
>> ---
>> drivers/net/virtio_net.c | 40 +++++++++++++++++++++++++++++-----------
>> 1 file changed, 29 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 4f3de0ac8b0b..e787657fc568 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -371,7 +371,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>> struct receive_queue *rq,
>> struct page *page, unsigned int offset,
>> unsigned int len, unsigned int truesize,
>> - bool hdr_valid)
>> + bool hdr_valid, unsigned int metasize)
>> {
>> struct sk_buff *skb;
>> struct virtio_net_hdr_mrg_rxbuf *hdr;
>> @@ -393,17 +393,25 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
>> else
>> hdr_padded_len = sizeof(struct padded_vnet_hdr);
>> - if (hdr_valid)
>> + if (hdr_valid && !metasize)
>> memcpy(hdr, p, hdr_len);
>> len -= hdr_len;
>> offset += hdr_padded_len;
>> p += hdr_padded_len;
>> - copy = len;
>> + copy = len + metasize;
>> if (copy > skb_tailroom(skb))
>> copy = skb_tailroom(skb);
>> - skb_put_data(skb, p, copy);
>> +
>> + if (metasize) {
>> + skb_put_data(skb, p - metasize, copy);
>
>
> I would rather keep copy untouched above, and use copy + metasize here, then you can save the following decrement as well. Or tweak the caller the count the meta in to offset, then we need only deal with skb_pull() and skb_metadata_set() here.
I think the latter is better, because copy + metasize must be smaller than skb tailroom size.
>
>> + __skb_pull(skb, metasize);
>> + skb_metadata_set(skb, metasize);
>> + copy -= metasize;
>> + } else {
>> + skb_put_data(skb, p, copy);
>> + }
>> len -= copy;
>> offset += copy;
>> @@ -644,6 +652,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
>> unsigned int delta = 0;
>> struct page *xdp_page;
>> int err;
>> + unsigned int metasize = 0;
>> len -= vi->hdr_len;
>> stats->bytes += len;
>> @@ -683,8 +692,8 @@ static struct sk_buff *receive_small(struct net_device *dev,
>> xdp.data_hard_start = buf + VIRTNET_RX_PAD + vi->hdr_len;
>> xdp.data = xdp.data_hard_start + xdp_headroom;
>> - xdp_set_data_meta_invalid(&xdp);
>> xdp.data_end = xdp.data + len;
>> + xdp.data_meta = xdp.data;
>> xdp.rxq = &rq->xdp_rxq;
>> orig_data = xdp.data;
>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> @@ -695,9 +704,11 @@ static struct sk_buff *receive_small(struct net_device *dev,
>> /* Recalculate length in case bpf program changed it */
>> delta = orig_data - xdp.data;
>> len = xdp.data_end - xdp.data;
>> + metasize = xdp.data - xdp.data_meta;
>> break;
>> case XDP_TX:
>> stats->xdp_tx++;
>> + xdp.data_meta = xdp.data;
>
>
> Why need this?
Because virtnet_xdp_xmit() doesn't support XDP meta data as below. And I suppose that we don't need to support XDP metadata for XDP_TX.
static int __virtnet_xdp_xmit_one(struct virtnet_info *vi,
struct send_queue *sq,
struct xdp_frame *xdpf)
{
struct virtio_net_hdr_mrg_rxbuf *hdr;
int err;
/* virtqueue want to use data area in-front of packet */
if (unlikely(xdpf->metasize > 0))
return -EOPNOTSUPP;
>
>> xdpf = convert_to_xdp_frame(&xdp);
>> if (unlikely(!xdpf))
>> goto err_xdp;
>> @@ -735,11 +746,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
>> }
>> skb_reserve(skb, headroom - delta);
>> skb_put(skb, len);
>> - if (!delta) {
>> + if (!delta && !metasize) {
>> buf += header_offset;
>> memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
>> } /* keep zeroed vnet hdr since packet was changed by bpf */
>
>
> Is there any method to preserve the vnet header here? We probably don't want to lose it for XDP_PASS when packet is not modified.
I'll try to keep the vnet header with moving the meta data to the front of the vnet header.
>
>> + if (metasize)
>> + skb_metadata_set(skb, metasize);
>> +
>> err:
>> return skb;
>> @@ -761,7 +775,7 @@ static struct sk_buff *receive_big(struct net_device *dev,
>> {
>> struct page *page = buf;
>> struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len,
>> - PAGE_SIZE, true);
>> + PAGE_SIZE, true, 0);
>> stats->bytes += len - vi->hdr_len;
>> if (unlikely(!skb))
>> @@ -793,6 +807,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>> unsigned int truesize;
>> unsigned int headroom = mergeable_ctx_to_headroom(ctx);
>> int err;
>> + unsigned int metasize = 0;
>> head_skb = NULL;
>> stats->bytes += len - vi->hdr_len;
>> @@ -839,8 +854,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>> data = page_address(xdp_page) + offset;
>> xdp.data_hard_start = data - VIRTIO_XDP_HEADROOM + vi->hdr_len;
>> xdp.data = data + vi->hdr_len;
>> - xdp_set_data_meta_invalid(&xdp);
>> xdp.data_end = xdp.data + (len - vi->hdr_len);
>> + xdp.data_meta = xdp.data;
>> xdp.rxq = &rq->xdp_rxq;
>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> @@ -859,18 +874,20 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>> * adjusted
>> */
>> len = xdp.data_end - xdp.data + vi->hdr_len;
>> + metasize = xdp.data - xdp.data_meta;
>> /* We can only create skb based on xdp_page. */
>> if (unlikely(xdp_page != page)) {
>> rcu_read_unlock();
>> put_page(page);
>> head_skb = page_to_skb(vi, rq, xdp_page,
>> - offset, len,
>> - PAGE_SIZE, false);
>> + offset, len,
>> + PAGE_SIZE, false, metasize);
>
>
> Indentation is wired.
Sorry. I'll fix it.
>
> Thanks
>
>
>> return head_skb;
>> }
>> break;
>> case XDP_TX:
>> stats->xdp_tx++;
>> + xdp.data_meta = xdp.data;
>> xdpf = convert_to_xdp_frame(&xdp);
>> if (unlikely(!xdpf))
>> goto err_xdp;
>> @@ -921,7 +938,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>> goto err_skb;
>> }
>> - head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog);
>> + head_skb = page_to_skb(vi, rq, page, offset, len, truesize, !xdp_prog,
>> + metasize);
>> curr_skb = head_skb;
>> if (unlikely(!curr_skb))
^ 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