* Re: [PATCH net] net/sched: fix refcnt leak in the error path of tcf_vlan_init()
From: David Miller @ 2018-05-16 18:42 UTC (permalink / raw)
To: dcaratti; +Cc: netdev, jiri, jhs, mrv
In-Reply-To: <b2e7cfab172461a824959d683d8c868fe04119a3.1526467698.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 16 May 2018 12:54:29 +0200
> Similarly to what was done with commit a52956dfc503 ("net sched actions:
> fix refcnt leak in skbmod"), fix the error path of tcf_vlan_init() to avoid
> refcnt leaks when wrong value of TCA_VLAN_PUSH_VLAN_PROTOCOL is given.
>
> Fixes: 5026c9b1bafc ("net sched: vlan action fix late binding")
> CC: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: 8390: ne: Fix accidentally removed RBTX4927 support
From: David Miller @ 2018-05-16 18:40 UTC (permalink / raw)
To: geert; +Cc: arnd, linux, anemo, netdev, linux-mips, linux-kernel
In-Reply-To: <1526462281-20772-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 16 May 2018 11:18:01 +0200
> The configuration settings for RBTX4927 were accidentally removed,
> leading to a silently broken network interface.
>
> Re-add the missing settings to fix this.
>
> Fixes: 8eb97ff5a4ec941d ("net: 8390: remove m32r specific bits")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Bisected between v4.9-rc2 (doh) and v4.17-rc5.
>
> Note to myself: I should do more boot testing on RBTX4927.
> Fortunately I caught it before it ends up in a point release ;-)
Better to go on a wild bisect ride than not be able to find the
bug at all :-)
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] ipv4: support sport, dport and ip_proto in RTM_GETROUTE
From: David Miller @ 2018-05-16 18:37 UTC (permalink / raw)
To: roopa; +Cc: netdev, dsa, nikolay, idosch
In-Reply-To: <1526442908-13183-2-git-send-email-roopa@cumulusnetworks.com>
From: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Tue, 15 May 2018 20:55:06 -0700
> +static int inet_rtm_getroute_reply(struct sk_buff *in_skb, struct nlmsghdr *nlh,
> + __be32 dst, __be32 src, struct flowi4 *fl4,
> + struct rtable *rt, struct fib_result *res)
> +{
> + struct net *net = sock_net(in_skb->sk);
> + struct rtmsg *rtm = nlmsg_data(nlh);
> + u32 table_id = RT_TABLE_MAIN;
> + struct sk_buff *skb;
> + int err = 0;
> +
> + skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
> + if (!skb)
> + return -ENOMEM;
If the caller can use GFP_KERNEL, so can this allocation.
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-16 18:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, cake
In-Reply-To: <20180516.140203.2185491961233997679.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Toke Høiland-Jørgensen <toke@toke.dk>
> Date: Tue, 15 May 2018 17:12:44 +0200
>
>> +typedef u64 cobalt_time_t;
>> +typedef s64 cobalt_tdiff_t;
> ...
>> +static cobalt_time_t cobalt_get_time(void)
>> +{
>> + return ktime_get_ns();
>> +}
>> +
>> +static u32 cobalt_time_to_us(cobalt_time_t val)
>> +{
>> + do_div(val, NSEC_PER_USEC);
>> + return (u32)val;
>> +}
>
> If fundamentally you are working with ktime_t values, please use that type
> and the associated helpers.
>
> This is a valid argument that using custom typedefs provide documentation
> and an aid to understanding, but I think it doesn't serve that purpose
> very well here.
>
> So please just use ktime_t throughout instead of this cobalt_time_t
> and cobalt_tdiff_t. And then use helpers like ktime_to_us() which
> properly optimize for 64-bit vs. 32-bit hosts.
Can do :)
-Toke
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Encapsulate sgmii ops under one structure
From: David Miller @ 2018-05-16 18:33 UTC (permalink / raw)
To: hpuranik; +Cc: netdev, linux-kernel, timur
In-Reply-To: <1526433053-16308-1-git-send-email-hpuranik@codeaurora.org>
From: Hemanth Puranik <hpuranik@codeaurora.org>
Date: Wed, 16 May 2018 06:40:53 +0530
> This patch introduces ops structure for sgmii, This by ensures that
> we do not need dummy functions in case of emulation platforms.
>
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node
From: Geert Uytterhoeven @ 2018-05-16 18:32 UTC (permalink / raw)
To: David Miller
Cc: Florian Fainelli, netdev, Andrew Lunn, Vivien Didelot,
Nicolas Ferre, Fugang Duan, Sergei Shtylyov, Giuseppe Cavallaro,
Alexandre Torgue, Jose Abreu, Grygorii Strashko, Woojung Huh,
Microchip Linux Driver Support, Rob Herring, Frank Rowand,
Antoine Ténart, Tobias Jordan
In-Reply-To: <20180516.142102.1650229402143291732.davem@davemloft.net>
Hi David,
On Wed, May 16, 2018 at 8:21 PM, David Miller <davem@davemloft.net> wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 15 May 2018 16:56:17 -0700
>
>> This patch series updates of_mdiobus_register() such that when the device_node
>> argument is NULL, it calls mdiobus_register() directly. This is consistent with
>> the behavior of of_mdiobus_register() when CONFIG_OF=n.
>>
>> I only converted the most obvious drivers, there are others that have a much
>> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
>>
>> Changes in v2:
>>
>> - fixed build error in davincin_mdio.c (Grygorii)
>> - reworked first patch a bit: commit message, subject and removed useless
>> code comment
>
> Based upon Andrew's response to Geert's feedback, I'm applying this series.
Thanks, his feedback made perfect sense.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [BUG] net: stmmac: dwmac-sun8i broken in linux-next
From: Corentin Labbe @ 2018-05-16 18:32 UTC (permalink / raw)
To: Jose.Abreu-HKixBCOQz3hWk0Htik3J/w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hello
The dwmac-sun8i driver is broken in next-20180515, symptom are no RX and TX errors as shown by ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.204 netmask 255.255.255.0 broadcast 192.168.1.255
ether 96:75:ff:0d:f6:d8 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 4956 (4.8 KiB)
TX errors 118 dropped 0 overruns 0 carrier 0 collisions 0
Reverting the following commit made the driver working:
4dbbe8dde8485b89bce8bbbe7564337fd7eed69f ("net: stmmac: Add support for U32 TC filter using Flexible RX Parser")
5f0456b43140af9413397cc11d03d18b9f2fc2fc ("net: stmmac: Implement logic to automatically select HW Interface")
Note that reverting only 4dbbe8dde8485b89bce8bbbe7564337fd7eed69f lead to crash:
[ 31.385110] Backtrace:
[ 31.387576] [<c0510cd4>] (stmmac_open) from [<c062cf48>] (__dev_open+0xe4/0x180)
[ 31.394972] r10:ed447d04 r9:edc5d010 r8:ef02002c r7:c08670a4 r6:00000000 r5:c0c08488
[ 31.402793] r4:ef020000
[ 31.405335] [<c062ce64>] (__dev_open) from [<c062d374>] (__dev_change_flags+0x190/0x1e8)
[ 31.413421] r8:00001002 r7:c0c08488 r6:00001003 r5:00000001 r4:ef020000
[ 31.420122] [<c062d1e4>] (__dev_change_flags) from [<c062d3ec>] (dev_change_flags+0x20/0x50)
[ 31.428555] r9:edc5d010 r8:ed447c18 r7:ef020134 r6:00000000 r5:00001002 r4:ef020000
[ 31.436300] [<c062d3cc>] (dev_change_flags) from [<c0646ef0>] (do_setlink+0x28c/0xbdc)
[ 31.444213] r9:edc5d010 r8:ed447c18 r7:00000000 r6:c0c08488 r5:ed447b50 r4:ef020000
[ 31.451955] [<c0646c64>] (do_setlink) from [<c0648064>] (rtnl_newlink+0x54c/0x7a8)
[ 31.459522] r10:ed447d04 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:00000000
[ 31.467343] r4:ef020000
[ 31.469885] [<c0647b18>] (rtnl_newlink) from [<c06449f8>] (rtnetlink_rcv_msg+0x38c/0x544)
[ 31.478058] r10:ed447d04 r9:00000000 r8:ee242840 r7:00000000 r6:edc5d000 r5:c0c08488
[ 31.485879] r4:00000000
[ 31.488422] [<c064466c>] (rtnetlink_rcv_msg) from [<c066e458>] (netlink_rcv_skb+0xc0/0x118)
[ 31.496768] r10:c0c08488 r9:00000000 r8:00000020 r7:edc5d000 r6:c064466c r5:c0c08488
[ 31.504589] r4:ee242840
[ 31.507129] [<c066e398>] (netlink_rcv_skb) from [<c0644668>] (rtnetlink_rcv+0x18/0x1c)
[ 31.515042] r8:ed447d60 r7:ee242840 r6:00000020 r5:ee37d800 r4:ee5fac00
[ 31.521742] [<c0644650>] (rtnetlink_rcv) from [<c066db98>] (netlink_unicast+0x190/0x1fc)
[ 31.529829] [<c066da08>] (netlink_unicast) from [<c066e098>] (netlink_sendmsg+0x3cc/0x410)
[ 31.538089] r10:00000000 r9:00000020 r8:014000c0 r7:ee242840 r6:ee37d800 r5:c0c08488
[ 31.545910] r4:ed447f44
[ 31.548452] [<c066dccc>] (netlink_sendmsg) from [<c0604460>] (sock_sendmsg+0x1c/0x2c)
[ 31.556279] r10:00000000 r9:ed447edc r8:00000000 r7:eefce640 r6:00000000 r5:c0c08488
[ 31.564100] r4:ed447f44
[ 31.566640] [<c0604444>] (sock_sendmsg) from [<c0604d9c>] (___sys_sendmsg+0x250/0x264)
[ 31.574555] [<c0604b4c>] (___sys_sendmsg) from [<c0605e98>] (__sys_sendmsg+0x58/0x94)
[ 31.582382] r10:00000000 r9:ed446000 r8:c01011c4 r7:eefce640 r6:00000000 r5:bec25150
[ 31.590203] r4:c0c08488
[ 31.592743] [<c0605e40>] (__sys_sendmsg) from [<c0605ee8>] (sys_sendmsg+0x14/0x18)
[ 31.600307] r7:00000128 r6:bec2d17c r5:bec25144 r4:00093ee0
[ 31.605969] [<c0605ed4>] (sys_sendmsg) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[ 31.613704] Exception stack(0xed447fa8 to 0xed447ff0)
[ 31.618756] 7fa0: 00093ee0 bec25144 00000003 bec25150 00000000 85ce0000
[ 31.626929] 7fc0: 00093ee0 bec25144 bec2d17c 00000128 000942a8 5afc783a 00094000 bec25150
[ 31.635099] 7fe0: 00000000 bec250f0 0000012c b6e10b5c
[ 31.640152] Code: e59a261c e59a013c e50b306c e592300c (e593300c)
[ 31.646632] ---[ end trace 407964b7deb937bf ]---
For the moment, I stil didnt find the issue.
What to we do now ? do you want that I send revert patchs ?
Regards
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: qualcomm: rmnet: Updates 2018-05-14
From: David Miller @ 2018-05-16 18:23 UTC (permalink / raw)
To: subashab; +Cc: netdev, fengguang.wu
In-Reply-To: <1526431922-4132-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Tue, 15 May 2018 18:51:59 -0600
> Patch 1 adds tx_drops counter to more places.
> Patch 2 adds ethtool private stats support to make it easy to debug
> the checksum offload path.
> Patch 3 is a cleanup in command packet processing path.
>
> v1->v2: Fix the incorrect if / else statement in
> rmnet_map_checksum_downlink_packet() and define rmnet_ethtool_ops
> as static as mentioned by kbuild test robot.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node
From: David Miller @ 2018-05-16 18:21 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, andrew, vivien.didelot, nicolas.ferre, fugang.duan,
sergei.shtylyov, peppe.cavallaro, alexandre.torgue, joabreu,
grygorii.strashko, woojung.huh, UNGLinuxDriver, robh+dt,
frowand.list, antoine.tenart, Tobias.Jordan, rmk+kernel,
geert+renesas, thomas.petazzoni, niklas.soderlund+renesas,
horms+renesas, muvarov, nsekhar, linux-kernel, linux-renesas-soc,
linux-omap, linux-usb, devicetree
In-Reply-To: <20180515235619.27773-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 May 2018 16:56:17 -0700
> This patch series updates of_mdiobus_register() such that when the device_node
> argument is NULL, it calls mdiobus_register() directly. This is consistent with
> the behavior of of_mdiobus_register() when CONFIG_OF=n.
>
> I only converted the most obvious drivers, there are others that have a much
> less obvious behavior and specifically attempt to deal with CONFIG_ACPI.
>
> Changes in v2:
>
> - fixed build error in davincin_mdio.c (Grygorii)
> - reworked first patch a bit: commit message, subject and removed useless
> code comment
Based upon Andrew's response to Geert's feedback, I'm applying this series.
Thanks.
^ permalink raw reply
* [PATCH net] net/ipv4: Initialize proto and ports in flow struct
From: David Ahern @ 2018-05-16 18:18 UTC (permalink / raw)
To: netdev; +Cc: roopa, David Ahern
Updating the FIB tracepoint for the recent change to allow rules using
the protocol and ports exposed a few places where the entries in the flow
struct are not initialized.
For __fib_validate_source add the call to fib4_rules_early_flow_dissect
since it is invoked for the input path. For netfilter, add the memset on
the flow struct to avoid future problems like this.
Fixes: bfff4862653b ("net: fib_rules: support for match on ip_proto, sport and dport")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv4/fib_frontend.c | 10 +++++++---
net/ipv4/netfilter/ipt_rpfilter.c | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index f05afaf3235c..58696b829065 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -326,10 +326,11 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
u8 tos, int oif, struct net_device *dev,
int rpf, struct in_device *idev, u32 *itag)
{
+ struct net *net = dev_net(dev);
+ struct flow_keys flkeys;
int ret, no_addr;
struct fib_result res;
struct flowi4 fl4;
- struct net *net = dev_net(dev);
bool dev_match;
fl4.flowi4_oif = 0;
@@ -347,8 +348,11 @@ static int __fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
no_addr = idev->ifa_list == NULL;
fl4.flowi4_mark = IN_DEV_SRC_VMARK(idev) ? skb->mark : 0;
-
- trace_fib_validate_source(dev, &fl4);
+ if (!fib4_rules_early_flow_dissect(net, skb, &fl4, &flkeys)) {
+ fl4.flowi4_proto = 0;
+ fl4.fl4_sport = 0;
+ fl4.fl4_dport = 0;
+ }
if (fib_lookup(net, &fl4, &res, 0))
goto last_resort;
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index fd01f13c896a..12843c9ef142 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -89,10 +89,10 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
return true ^ invert;
}
+ memset(&flow, 0, sizeof(flow));
flow.flowi4_iif = LOOPBACK_IFINDEX;
flow.daddr = iph->saddr;
flow.saddr = rpfilter_get_saddr(iph->daddr);
- flow.flowi4_oif = 0;
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;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: Allow more drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180516.141738.494765267490482500.davem@davemloft.net>
On 05/16/2018 11:17 AM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 16 May 2018 14:15:14 -0400 (EDT)
>
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue, 15 May 2018 16:48:22 -0700
>>
>>> This patch series includes more drivers to be build tested with COMPILE_TEST
>>> enabled. This helps cover some of the issues I just ran into with missing
>>> a driver *sigh*.
>>
>> Thank you for doing this.
>>
>> Series applied.
>
> Actually, I have to revert.
>
> The FEC driver cannot be built tested without the appropriate platform
> specific register set defines and x86-64 for example won't provide that.
Ah, yes, it built okay for ARM 32-bit, let me fix that.
>
> drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_restart’:
> drivers/net/ethernet/freescale/fec_main.c:959:26: error: ‘FEC_RACC’ undeclared (first use in this function); did you mean ‘FEC_RXIC0’?
> val = readl(fep->hwp + FEC_RACC);
> ^~~~~~~~
> FEC_RXIC0
> drivers/net/ethernet/freescale/fec_main.c:959:26: note: each undeclared identifier is reported only once for each function it appears in
> drivers/net/ethernet/freescale/fec_main.c:968:38: error: ‘FEC_FTRL’ undeclared (first use in this function); did you mean ‘FEC_ECNTRL’?
> writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
> ^~~~~~~~
> FEC_ECNTRL
> ...
>
--
Florian
^ permalink raw reply
* Re: [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: David Miller @ 2018-05-16 18:18 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel, opendmb
In-Reply-To: <e88ff455-2072-c885-e64b-0f2bf91420a4@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 16 May 2018 11:15:37 -0700
> On 05/16/2018 11:12 AM, David Miller wrote:
>> Queue up for -stable?
>
> Yes please!
Done.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: Allow more drivers with COMPILE_TEST
From: David Miller @ 2018-05-16 18:17 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180516.141514.1102545495330180859.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 16 May 2018 14:15:14 -0400 (EDT)
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 15 May 2018 16:48:22 -0700
>
>> This patch series includes more drivers to be build tested with COMPILE_TEST
>> enabled. This helps cover some of the issues I just ran into with missing
>> a driver *sigh*.
>
> Thank you for doing this.
>
> Series applied.
Actually, I have to revert.
The FEC driver cannot be built tested without the appropriate platform
specific register set defines and x86-64 for example won't provide that.
drivers/net/ethernet/freescale/fec_main.c: In function ‘fec_restart’:
drivers/net/ethernet/freescale/fec_main.c:959:26: error: ‘FEC_RACC’ undeclared (first use in this function); did you mean ‘FEC_RXIC0’?
val = readl(fep->hwp + FEC_RACC);
^~~~~~~~
FEC_RXIC0
drivers/net/ethernet/freescale/fec_main.c:959:26: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/freescale/fec_main.c:968:38: error: ‘FEC_FTRL’ undeclared (first use in this function); did you mean ‘FEC_ECNTRL’?
writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
^~~~~~~~
FEC_ECNTRL
...
^ permalink raw reply
* Re: [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: Florian Fainelli @ 2018-05-16 18:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, andrew, vivien.didelot, linux-kernel, opendmb
In-Reply-To: <20180516.141218.827550466386531999.davem@davemloft.net>
On 05/16/2018 11:12 AM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue, 15 May 2018 16:01:22 -0700
>
>> This patch series fixes a number of usability issues with the SF2 Compact Field
>> Processor code:
>>
>> - we would not be properly bound checking the location when we let the kernel
>> automatically place rules with RX_CLS_LOC_ANY
>>
>> - when using IPv6 rules and user space specifies a location identifier we
>> would be off by one in what the chain ID (within the Broadcom tag) indicates
>>
>> - it would be possible to delete one of the two slices of an IPv6 while leaving
>> the other one programming leading to various problems
>
> Series applied, thanks.
>
> Queue up for -stable?
Yes please!
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: Allow more drivers with COMPILE_TEST
From: David Miller @ 2018-05-16 18:15 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <20180515234825.11240-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 May 2018 16:48:22 -0700
> This patch series includes more drivers to be build tested with COMPILE_TEST
> enabled. This helps cover some of the issues I just ran into with missing
> a driver *sigh*.
Thank you for doing this.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: ethernet: ti: cpsw-phy-sel: check bus_find_device() ret value
From: David Miller @ 2018-05-16 18:13 UTC (permalink / raw)
To: grygorii.strashko; +Cc: netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <20180515233725.11882-1-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 15 May 2018 18:37:25 -0500
> This fixes klockworks warnings: Pointer 'dev' returned from call to
> function 'bus_find_device' at line 179 may be NULL and will be dereferenced
> at line 181.
>
> cpsw-phy-sel.c:179: 'dev' is assigned the return value from function 'bus_find_device'.
> bus.c:342: 'bus_find_device' explicitly returns a NULL value.
> cpsw-phy-sel.c:181: 'dev' is dereferenced by passing argument 1 to function 'dev_get_drvdata'.
> device.h:1024: 'dev' is passed to function 'dev_get_drvdata'.
> device.h:1026: 'dev' is explicitly dereferenced.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> [nsekhar@ti.com: add an error message, fix return path]
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> v2: use %pOF
Applied, thank you.
^ permalink raw reply
* Re: [Intel-wired-lan] [RFC PATCH bpf-next 00/12] AF_XDP, zero-copy support
From: Jeff Kirsher @ 2018-05-16 18:14 UTC (permalink / raw)
To: Alexei Starovoitov, Björn Töpel
Cc: willemdebruijn.kernel, daniel, ast, netdev, qi.z.zhang, mst,
michael.lundkvist, intel-wired-lan, brouer, Björn Töpel,
magnus.karlsson, magnus.karlsson
In-Reply-To: <20180516170427.7jq74odw62myg55x@ast-mbp>
[-- Attachment #1: Type: text/plain, Size: 3398 bytes --]
On Wed, 2018-05-16 at 10:04 -0700, Alexei Starovoitov wrote:
> On Tue, May 15, 2018 at 09:06:03PM +0200, Björn Töpel wrote:
> >
> > Alexei had two concerns in conjunction with adding ZC support to
> > AF_XDP: show that the user interface holds and can deliver good
> > performance for ZC and that the driver interfaces for ZC are good.
> > We
> > think that this patch set shows that we have addressed the first
> > issue: performance is good and there is no change to the uapi. But
> > please take a look at the code and see if you like the ZC
> > interfaces
> > that was the second concern.
>
> Looks like we're not on the same page with definition of 'uapi'.
> Here you're saying that patches demonstrate performance without
> a change to uapi, whereas patch 1 does remove rebind support
> which _is_ a change to uapi.
> That was exactly my concern with the previous set.
>
> The other restrictions that are introduced in this patch set
> are actually ok:
> - like in patch 12: 'no redirect to an AF_XDP enabled XDP Tx ring'
> this is fine, since this restriction can be lifted later without
> breaking uapi
> - patch 11: 'No passing to the stack via XDP_PASS'
> also fine, since can be addressed later.
>
> > To do for this RFC to become a patch set:
> >
> > * Implement dynamic creation and deletion of queues in the i40e
> > driver
>
> can be deferred, no?
>
> > * Properly splitting up the i40e changes
>
> Imo patch 11 and 12 are reasonable in terms of size
> and reviewable as-is. I don't think they have to be split.
> Would be nice though.
>
> > * Have the Intel NIC team review the i40e changes from at least an
> > architecture point of view
>
> As Alexander pointed out in patch 11, if you split it into
> separate file the changes to i40e core become pretty small and
> I think Intel folks (Jeff, Alexander, ...) will be ok if we merge
> this set via bpf-next tree asap and clean up, refactor, share
> more code with i40e core later.
I am fine with the i40e changes in this series go through the BPF tree,
since majority of the series is BPF changes. We just need to address
Alex's comments on patch 11 & 12.
I only have 1-2 patches currently in my queue against i40e and they are
not affected by the changes in this series, so Dave should not have any
merge issues when pulling.
> > * Implement a more fair scheduling policy for multiple XSKs that
> > share
> > an umem for TX. This can be combined with a batching API for
> > xsk_umem_consume_tx.
>
> can be deferred too?
>
> I think the first 10 patches in this set is a hard dependency on i40e
> patches, so the whole thing have to reviewed and landed together.
> May be the first 5 patches can be applied already.
>
> Anyway at this point I still think that removing AF_XDP and bpf
> xskmap
> from uapi is necessary before the merge window, unless this patch set
> (including i40e changes can land right now).
> Also I'd like to see another NIC vendor demonstrating RFC for ZC as
> well.
> The allocator api looks good and I don't anticipate issues, but still
> I think it's necessary to make sure that we're not adding i40e-only
> feature.
>
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 0/3] net: dsa: bcm_sf2: CFP fixes
From: David Miller @ 2018-05-16 18:12 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel, opendmb
In-Reply-To: <20180515230125.25886-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 15 May 2018 16:01:22 -0700
> This patch series fixes a number of usability issues with the SF2 Compact Field
> Processor code:
>
> - we would not be properly bound checking the location when we let the kernel
> automatically place rules with RX_CLS_LOC_ANY
>
> - when using IPv6 rules and user space specifies a location identifier we
> would be off by one in what the chain ID (within the Broadcom tag) indicates
>
> - it would be possible to delete one of the two slices of an IPv6 while leaving
> the other one programming leading to various problems
Series applied, thanks.
Queue up for -stable?
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Davide Caratti @ 2018-05-16 18:10 UTC (permalink / raw)
To: Roman Mashak, Vlad Buslov
Cc: Jamal Hadi Salim, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <85efib33kr.fsf@mojatatu.com>
On Wed, 2018-05-16 at 13:36 -0400, Roman Mashak wrote:
> Vlad Buslov <vladbu@mellanox.com> writes:
>
> > On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
> > > On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
> > > > > > > > I'm trying to run tdc, but keep getting following error even on clean
> > > > > > > > branch without my patches:
> > > > > > >
> > > > > > > Vlad, not sure if you saw my email:
> > > > > > > Apply Roman's patch and try again
> > > > > > >
> > > > > > > https://marc.info/?l=linux-netdev&m=152639369112020&w=2
> > > > > > >
> > > > > > > cheers,
> > > > > > > jamal
> > > > > >
> > > > > > With patch applied I get following error:
> > > > > >
> > > > > > Test 7d50: Add skbmod action to set destination mac
> > > > > > exit: 255 0
> > > > > > dst MAC address <11:22:33:44:55:66>
> > > > > > RTNETLINK answers: No such file or directory
> > > > > > We have an error talking to the kernel
> > > > > >
> > > > >
> > > > > You may actually have broken something with your patches in this case.
> > > >
> > > > Results is for net-next without my patches.
> > >
> > > Do you have skbmod compiled in kernel or as a module?
> >
> > Thanks, already figured out that default config has some actions
> > disabled.
> > Have more errors now. Everything related to ife:
> >
> > Test 7682: Create valid ife encode action with mark and pass control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No such file or directory
> > We have an error talking to the kernel
> >
> > Test ef47: Create valid ife encode action with mark and pipe control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> >
> > Test df43: Create valid ife encode action with mark and continue control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> >
> > Test e4cf: Create valid ife encode action with mark and drop control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> >
> > Test ccba: Create valid ife encode action with mark and reclassify control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> >
> > Test a1cf: Create valid ife encode action with mark and jump control
> > exit: 255 0
> > IFE type 0xED3E
> > RTNETLINK answers: No space left on device
> > We have an error talking to the kernel
> >
> > ...
> >
> >
>
> Please make sure you have these in your kernel config:
>
> CONFIG_NET_ACT_IFE=y
> CONFIG_NET_IFE_SKBMARK=m
> CONFIG_NET_IFE_SKBPRIO=m
> CONFIG_NET_IFE_SKBTCINDEX=m
>
> For tdc to run all the tests, it is assumed that all the supported tc
> actions/filters are enabled and compiled.
hello,
looking at ife.json, it seems that we have at least 4 typos in
'teardown'.
It does
$TC actions flush action skbedit
in place of
$TC actions flush action ife
On my fedora28 (with fedora28 kernel), fixing them made test 7682 return
'ok' (and all others in ife category, except ee94, 7ee0 and 0a7d).
regards,
--
davide
^ permalink raw reply
* Re: [PATCH net-next] Revert "bonding: allow carrier and link status to determine link state"
From: David Miller @ 2018-05-16 18:04 UTC (permalink / raw)
To: dbanerje; +Cc: netdev, j.vosburgh, vfalico, andy
In-Reply-To: <20180516180213.15940-1-dbanerje@akamai.com>
From: Debabrata Banerjee <dbanerje@akamai.com>
Date: Wed, 16 May 2018 14:02:13 -0400
> This reverts commit 1386c36b30388f46a95100924bfcae75160db715.
>
> We don't want to encourage drivers to not report carrier status
> correctly, therefore remove this commit.
>
> Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
Applied, thanks for following up so quickly.
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: updated mirred and vlan with more tests
From: David Miller @ 2018-05-16 18:03 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1526409074-20135-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Tue, 15 May 2018 14:31:14 -0400
> Added extra test cases for different control actions (reclassify, pipe
> etc.), cookies, max values & exceeding maximum, and replace existing
> actions unit tests.
>
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Applied, thank you.
^ permalink raw reply
* [PATCH net-next] Revert "bonding: allow carrier and link status to determine link state"
From: Debabrata Banerjee @ 2018-05-16 18:02 UTC (permalink / raw)
To: David S . Miller, netdev, Jay Vosburgh
Cc: Veaceslav Falico, Andy Gospodarek, dbanerje
This reverts commit 1386c36b30388f46a95100924bfcae75160db715.
We don't want to encourage drivers to not report carrier status
correctly, therefore remove this commit.
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
Documentation/networking/bonding.txt | 4 ++--
drivers/net/bonding/bond_main.c | 12 ++++--------
drivers/net/bonding/bond_options.c | 7 +++----
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 86d07fbb592d..c13214d073a4 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -828,8 +828,8 @@ use_carrier
MII / ETHTOOL ioctl method to determine the link state.
A value of 1 enables the use of netif_carrier_ok(), a value of
- 0 will use the deprecated MII / ETHTOOL ioctls. A value of 2
- will check both. The default value is 1.
+ 0 will use the deprecated MII / ETHTOOL ioctls. The default
+ value is 1.
xmit_hash_policy
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e4c253dc7dfb..a4cd7f6bfd4d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -132,7 +132,7 @@ MODULE_PARM_DESC(downdelay, "Delay before considering link down, "
"in milliseconds");
module_param(use_carrier, int, 0);
MODULE_PARM_DESC(use_carrier, "Use netif_carrier_ok (vs MII ioctls) in miimon; "
- "0 for off, 1 for on (default), 2 for carrier then legacy checks");
+ "0 for off, 1 for on (default)");
module_param(mode, charp, 0);
MODULE_PARM_DESC(mode, "Mode of operation; 0 for balance-rr, "
"1 for active-backup, 2 for balance-xor, "
@@ -434,16 +434,12 @@ static int bond_check_dev_link(struct bonding *bond,
int (*ioctl)(struct net_device *, struct ifreq *, int);
struct ifreq ifr;
struct mii_ioctl_data *mii;
- bool carrier = true;
if (!reporting && !netif_running(slave_dev))
return 0;
if (bond->params.use_carrier)
- carrier = netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
-
- if (!carrier)
- return carrier;
+ return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
/* Try to get link status using Ethtool first. */
if (slave_dev->ethtool_ops->get_link)
@@ -4407,8 +4403,8 @@ static int bond_check_params(struct bond_params *params)
downdelay = 0;
}
- if (use_carrier < 0 || use_carrier > 2) {
- pr_warn("Warning: use_carrier module parameter (%d), not of valid value (0-2), so it was set to 1\n",
+ if ((use_carrier != 0) && (use_carrier != 1)) {
+ pr_warn("Warning: use_carrier module parameter (%d), not of valid value (0/1), so it was set to 1\n",
use_carrier);
use_carrier = 1;
}
diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
index dba6cef05134..8a945c9341d6 100644
--- a/drivers/net/bonding/bond_options.c
+++ b/drivers/net/bonding/bond_options.c
@@ -164,10 +164,9 @@ static const struct bond_opt_value bond_primary_reselect_tbl[] = {
};
static const struct bond_opt_value bond_use_carrier_tbl[] = {
- { "off", 0, 0},
- { "on", 1, BOND_VALFLAG_DEFAULT},
- { "both", 2, 0},
- { NULL, -1, 0}
+ { "off", 0, 0},
+ { "on", 1, BOND_VALFLAG_DEFAULT},
+ { NULL, -1, 0}
};
static const struct bond_opt_value bond_all_slaves_active_tbl[] = {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next v11 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: David Miller @ 2018-05-16 18:02 UTC (permalink / raw)
To: toke; +Cc: netdev, cake
In-Reply-To: <152639716493.2525.13568513738420279599.stgit@alrua-kau>
From: Toke Høiland-Jørgensen <toke@toke.dk>
Date: Tue, 15 May 2018 17:12:44 +0200
> +typedef u64 cobalt_time_t;
> +typedef s64 cobalt_tdiff_t;
...
> +static cobalt_time_t cobalt_get_time(void)
> +{
> + return ktime_get_ns();
> +}
> +
> +static u32 cobalt_time_to_us(cobalt_time_t val)
> +{
> + do_div(val, NSEC_PER_USEC);
> + return (u32)val;
> +}
If fundamentally you are working with ktime_t values, please use that type
and the associated helpers.
This is a valid argument that using custom typedefs provide documentation
and an aid to understanding, but I think it doesn't serve that purpose
very well here.
So please just use ktime_t throughout instead of this cobalt_time_t
and cobalt_tdiff_t. And then use helpers like ktime_to_us() which
properly optimize for 64-bit vs. 32-bit hosts.
Thank you.
^ permalink raw reply
* Re: [RFC PATCH bpf-next 00/12] AF_XDP, zero-copy support
From: Björn Töpel @ 2018-05-16 17:49 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Magnus Karlsson, Karlsson, Magnus, Duyck, Alexander H,
Alexander Duyck, John Fastabend, Alexei Starovoitov,
Jesper Dangaard Brouer, Willem de Bruijn, Daniel Borkmann,
Michael S. Tsirkin, Netdev, Björn Töpel,
michael.lundkvist, Brandeburg, Jesse, Singhai, Anjali,
Zhang, Qi Z, intel-wired-lan
In-Reply-To: <20180516170427.7jq74odw62myg55x@ast-mbp>
2018-05-16 19:04 GMT+02:00 Alexei Starovoitov <alexei.starovoitov@gmail.com>:
> On Tue, May 15, 2018 at 09:06:03PM +0200, Björn Töpel wrote:
>>
>> Alexei had two concerns in conjunction with adding ZC support to
>> AF_XDP: show that the user interface holds and can deliver good
>> performance for ZC and that the driver interfaces for ZC are good. We
>> think that this patch set shows that we have addressed the first
>> issue: performance is good and there is no change to the uapi. But
>> please take a look at the code and see if you like the ZC interfaces
>> that was the second concern.
>
> Looks like we're not on the same page with definition of 'uapi'.
> Here you're saying that patches demonstrate performance without
> a change to uapi, whereas patch 1 does remove rebind support
> which _is_ a change to uapi.
> That was exactly my concern with the previous set.
>
Good point. We did realize it was an UAPI break, and intended to add
the "disable rebind" as a follow up in this merge window (honestly!
;-)), but still -- this proves your point that the ZC patches should
be done back-to-back to the non-ZC ones.
> The other restrictions that are introduced in this patch set
> are actually ok:
> - like in patch 12: 'no redirect to an AF_XDP enabled XDP Tx ring'
> this is fine, since this restriction can be lifted later without
> breaking uapi
> - patch 11: 'No passing to the stack via XDP_PASS'
> also fine, since can be addressed later.
>
>> To do for this RFC to become a patch set:
>>
>> * Implement dynamic creation and deletion of queues in the i40e driver
>
> can be deferred, no?
>
Well it *could*, but that combined with the whole "bolted on Rx path"
isn't something I'd like to be upstream. It needs more work, and is
too messy and fragile IMO.
>> * Properly splitting up the i40e changes
>
> Imo patch 11 and 12 are reasonable in terms of size
> and reviewable as-is. I don't think they have to be split.
> Would be nice though.
>
>> * Have the Intel NIC team review the i40e changes from at least an
>> architecture point of view
>
> As Alexander pointed out in patch 11, if you split it into
> separate file the changes to i40e core become pretty small and
> I think Intel folks (Jeff, Alexander, ...) will be ok if we merge
> this set via bpf-next tree asap and clean up, refactor, share
> more code with i40e core later.
>
Hmm...
>> * Implement a more fair scheduling policy for multiple XSKs that share
>> an umem for TX. This can be combined with a batching API for
>> xsk_umem_consume_tx.
>
> can be deferred too?
>
Yes.
> I think the first 10 patches in this set is a hard dependency on i40e
> patches, so the whole thing have to reviewed and landed together.
> May be the first 5 patches can be applied already.
>
> Anyway at this point I still think that removing AF_XDP and bpf xskmap
> from uapi is necessary before the merge window, unless this patch set
> (including i40e changes can land right now).
> Also I'd like to see another NIC vendor demonstrating RFC for ZC as well.
> The allocator api looks good and I don't anticipate issues, but still
> I think it's necessary to make sure that we're not adding i40e-only feature.
>
Again, fair point. We think the copy-path is generic enough (with the
follow-ups you and Daniel suggested and the rebind state removed) --
but hey, we're that one vendor. ;-) More seriously -- having at least
two ZC implementations at the introduction of AF_XDP would make us
happier as well.
Thanks,
Björn
^ permalink raw reply
* [PATCH net] tls: don't use stack memory in a scatterlist
From: Matt Mullins @ 2018-05-16 17:48 UTC (permalink / raw)
To: David S. Miller
Cc: Matt Mullins, Ilya Lesokhin, Aviad Yehezkel, Dave Watson, netdev,
linux-kernel
scatterlist code expects virt_to_page() to work, which fails with
CONFIG_VMAP_STACK=y.
Fixes: c46234ebb4d1e ("tls: RX path for ktls")
Signed-off-by: Matt Mullins <mmullins@fb.com>
---
include/net/tls.h | 3 +++
net/tls/tls_sw.c | 9 ++++-----
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index b400d0bb7448..f5fb16da3860 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -97,6 +97,9 @@ struct tls_sw_context {
u8 control;
bool decrypted;
+ char rx_aad_ciphertext[TLS_AAD_SPACE_SIZE];
+ char rx_aad_plaintext[TLS_AAD_SPACE_SIZE];
+
/* Sending context */
char aad_space[TLS_AAD_SPACE_SIZE];
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 71e79597f940..e1c93ce74e0f 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -680,7 +680,6 @@ static int decrypt_skb(struct sock *sk, struct sk_buff *skb,
struct scatterlist *sgin = &sgin_arr[0];
struct strp_msg *rxm = strp_msg(skb);
int ret, nsg = ARRAY_SIZE(sgin_arr);
- char aad_recv[TLS_AAD_SPACE_SIZE];
struct sk_buff *unused;
ret = skb_copy_bits(skb, rxm->offset + TLS_HEADER_SIZE,
@@ -698,13 +697,13 @@ static int decrypt_skb(struct sock *sk, struct sk_buff *skb,
}
sg_init_table(sgin, nsg);
- sg_set_buf(&sgin[0], aad_recv, sizeof(aad_recv));
+ sg_set_buf(&sgin[0], ctx->rx_aad_ciphertext, TLS_AAD_SPACE_SIZE);
nsg = skb_to_sgvec(skb, &sgin[1],
rxm->offset + tls_ctx->rx.prepend_size,
rxm->full_len - tls_ctx->rx.prepend_size);
- tls_make_aad(aad_recv,
+ tls_make_aad(ctx->rx_aad_ciphertext,
rxm->full_len - tls_ctx->rx.overhead_size,
tls_ctx->rx.rec_seq,
tls_ctx->rx.rec_seq_size,
@@ -803,12 +802,12 @@ int tls_sw_recvmsg(struct sock *sk,
if (to_copy <= len && page_count < MAX_SKB_FRAGS &&
likely(!(flags & MSG_PEEK))) {
struct scatterlist sgin[MAX_SKB_FRAGS + 1];
- char unused[21];
int pages = 0;
zc = true;
sg_init_table(sgin, MAX_SKB_FRAGS + 1);
- sg_set_buf(&sgin[0], unused, 13);
+ sg_set_buf(&sgin[0], ctx->rx_aad_plaintext,
+ TLS_AAD_SPACE_SIZE);
err = zerocopy_from_iter(sk, &msg->msg_iter,
to_copy, &pages,
--
2.14.1
^ permalink raw reply related
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