* [PATCH] farsync: remove redundant variable txq_length
From: Colin King @ 2018-07-07 11:27 UTC (permalink / raw)
To: Kevin Curtis, David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable txq_length is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
warning: variable 'txq_length' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/farsync.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c
index bd46b2552980..2a3f0f1a2b0a 100644
--- a/drivers/net/wan/farsync.c
+++ b/drivers/net/wan/farsync.c
@@ -2134,7 +2134,6 @@ static void
fst_openport(struct fst_port_info *port)
{
int signals;
- int txq_length;
/* Only init things if card is actually running. This allows open to
* succeed for downloads etc.
@@ -2161,7 +2160,6 @@ fst_openport(struct fst_port_info *port)
else
netif_carrier_off(port_to_dev(port));
- txq_length = port->txqe - port->txqs;
port->txqe = 0;
port->txqs = 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Add a mlxsw-specific test for mirror-to-gretap
From: David Miller @ 2018-07-07 11:29 UTC (permalink / raw)
To: petrm; +Cc: netdev, linux-kselftest, jiri, idosch, shuah
In-Reply-To: <cover.1530816800.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Thu, 05 Jul 2018 21:10:53 +0200
> Some configurations of mirror-to-gretap are impossible for mlxsw to
> offload. Add a test that checks that these out-of-domain conditions are
> handled properly by mlxsw.
>
> In patch #1, fix mirror_gre_lib.sh and mirror_gre_topo_lib.sh so that
> they can be imported from directories other than forwarding/.
>
> In patch #2, add a test to check handling of several scenarios that
> mlxsw is expected to fail to offload.
Series applied, thanks.
^ permalink raw reply
* Re: linux-next: build warning after merge of the net-next tree
From: David Miller @ 2018-07-07 11:30 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, moshe, jiri
In-Reply-To: <20180706095633.676b0229@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 6 Jul 2018 09:56:33 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/net/dsa.h:24:0,
> from include/linux/platform_data/b53.h:23,
> from drivers/net/dsa/b53/b53_spi.c:25:
> include/net/devlink.h: In function 'devlink_param_value_changed':
> include/net/devlink.h:771:9: warning: 'return' with a value, in function returning void
> return -EOPNOTSUPP;
> ^
> include/net/devlink.h:769:1: note: declared here
> devlink_param_value_changed(struct devlink *devlink, u32 param_id)
...
> Introduced by commit
>
> ea601e170988 ("devlink: Add devlink notifications support for params")
Thanks Stephen, this should be fixes now.
^ permalink raw reply
* Re: [PATCH net-next v6 00/11] Modify action API for implementing lockless actions
From: David Miller @ 2018-07-07 11:41 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, ast, daniel, kliteyn
In-Reply-To: <1530800673-12280-1-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Thu, 5 Jul 2018 17:24:22 +0300
> Currently, all netlink protocol handlers for updating rules, actions and
> qdiscs are protected with single global rtnl lock which removes any
> possibility for parallelism. This patch set is a first step to remove
> rtnl lock dependency from TC rules update path.
I've reviewed this a few time but since this is a rather non-trivial
set of changes I'm going to let others have a chance to review and
give feedback as well.
Thanks.
^ permalink raw reply
* Re: [PATCH] farsync: remove redundant variable txq_length
From: David Miller @ 2018-07-07 11:49 UTC (permalink / raw)
To: colin.king; +Cc: kevin.curtis, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180707112730.21404-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 7 Jul 2018 12:27:30 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable txq_length is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> warning: variable 'txq_length' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/5] Introduce matching on double vlan/QinQ headers for TC flower
From: David Miller @ 2018-07-07 11:52 UTC (permalink / raw)
To: jianbol; +Cc: netdev, jiri
In-Reply-To: <20180706053817.17712-1-jianbol@mellanox.com>
From: Jianbo Liu <jianbol@mellanox.com>
Date: Fri, 6 Jul 2018 05:38:11 +0000
> Currently TC flower supports only one vlan tag, it doesn't match on both outer
> and inner vlan headers for QinQ. To do this, we add support to get both outer
> and inner vlan headers for flow dissector, and then TC flower do matching on
> those information.
>
> We also plan to extend TC command to support this feature. We add new
> cvlan_id/cvlan_prio/cvlan_ethtype keywords for inner vlan header. The existing
> vlan_id/vlan_prio/vlan_ethtype are for outer vlan header, and vlan_ethtype must
> be 802.1q or 802.1ad.
>
> The examples for command and output are as the following.
> # tc filter add dev ens1f1 parent ffff: protocol 802.1ad pref 33 \
> flower vlan_id 1000 vlan_ethtype 802.1q \
> cvlan_id 100 cvlan_ethtype ipv4 \
> action vlan pop \
> action vlan pop \
> action mirred egress redirect dev ens1f1_0
>
> # tc filter show dev ens1f1 ingress
> filter protocol 802.1ad pref 33 flower chain 0
> filter protocol 802.1ad pref 33 flower chain 0 handle 0x1
> vlan_id 1000
> vlan_ethtype 802.1Q
> cvlan_id 100
> cvlan_ethtype ip
> eth_type ipv4
> in_hw
> ...
>
> v2:
> fix sparse warning.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: macb: Free RX ring for all queues
From: David Miller @ 2018-07-07 11:55 UTC (permalink / raw)
To: harini.katakam
Cc: nicolas.ferre, claudiu.beznea, netdev, linux-kernel, michal.simek,
harinikatakamlinux
In-Reply-To: <1530859738-11802-1-git-send-email-harini.katakam@xilinx.com>
From: Harini Katakam <harini.katakam@xilinx.com>
Date: Fri, 6 Jul 2018 12:18:57 +0530
> rx ring is allocated for all queues in macb_alloc_consistent.
> Free the same for all queues instead of just Q0.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] net: macb: Allocate valid memory for TX and RX BD prefetch
From: David Miller @ 2018-07-07 11:55 UTC (permalink / raw)
To: harini.katakam
Cc: nicolas.ferre, claudiu.beznea, netdev, linux-kernel, michal.simek,
harinikatakamlinux
In-Reply-To: <1530859738-11802-2-git-send-email-harini.katakam@xilinx.com>
From: Harini Katakam <harini.katakam@xilinx.com>
Date: Fri, 6 Jul 2018 12:18:58 +0530
> GEM version in ZynqMP and most versions greater than r1p07 supports
> TX and RX BD prefetch. The number of BDs that can be prefetched is a
> HW configurable parameter. For ZynqMP, this parameter is 4.
>
> When GEM DMA is accessing the last BD in the ring, even before the
> BD is processed and the WRAP bit is noticed, it will have prefetched
> BDs outside the BD ring. These will not be processed but it is
> necessary to have accessible memory after the last BD. Especially
> in cases where SMMU is used, memory locations immediately after the
> last BD may not have translation tables triggering HRESP errors. Hence
> always allocate extra BDs to accommodate for prefetch.
> The value of tx/rx bd prefetch for any given SoC version is:
> 2 ^ (corresponding field in design config 10 register).
> (value of this field >= 1)
>
> Added a capability flag so that older IP versions that do not have
> DCFG10 or this prefetch capability are not affected.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Applied.
^ permalink raw reply
* Re: linux-next: build warning after merge of the net-next tree
From: Stephen Rothwell @ 2018-07-07 12:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, moshe, jiri, Arnd Bergmann
In-Reply-To: <20180707.203016.623173685153821356.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
Hi Dave,
On Sat, 07 Jul 2018 20:30:16 +0900 (KST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 6 Jul 2018 09:56:33 +1000
>
> > After merging the net-next tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> >
> > In file included from include/net/dsa.h:24:0,
> > from include/linux/platform_data/b53.h:23,
> > from drivers/net/dsa/b53/b53_spi.c:25:
> > include/net/devlink.h: In function 'devlink_param_value_changed':
> > include/net/devlink.h:771:9: warning: 'return' with a value, in function returning void
> > return -EOPNOTSUPP;
> > ^
> > include/net/devlink.h:769:1: note: declared here
> > devlink_param_value_changed(struct devlink *devlink, u32 param_id)
> ...
> > Introduced by commit
> >
> > ea601e170988 ("devlink: Add devlink notifications support for params")
>
> Thanks Stephen, this should be fixes now.
Great, thanks.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [net-next 1/1] tipc: extend link reset criteria for stale packet retransmission
From: David Miller @ 2018-07-07 12:16 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion, mohan.krishna.ghanta.krishnamurthy
In-Reply-To: <1530883356-22355-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Fri, 6 Jul 2018 15:22:36 +0200
> Currently a link is declared stale and reset if there has been 100
> repeated attempts to retransmit the same packet. However, in certain
> infrastructures we see that packet (NACK) duplicates and delays may
> cause such retransmit attempts to occur at a high rate, so that the
> peer doesn't have a reasonable chance to acknowledge the reception
> before the 100-limit is hit. This may take much less than the
> stipulated link tolerance time, and despite that probe/probe replies
> otherwise go through as normal.
>
> We now extend the criteria for link reset to also being time based.
> I.e., we don't reset the link until the link tolerance time is passed
> AND we have made 100 retransmissions attempts.
>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: [PATCH] ipv6: icmp: Updating pmtu for link local route
From: David Miller @ 2018-07-07 12:14 UTC (permalink / raw)
To: geokohma; +Cc: netdev
In-Reply-To: <52d524fe-5bc9-4c10-5ef1-9cae7ddb41ba@cisco.com>
From: Georg Kohmann <geokohma@cisco.com>
Date: Fri, 6 Jul 2018 14:59:56 +0200
> @@ -92,7 +92,7 @@ static void icmpv6_err(struct sk_buff *skb, struct
> inet6_skb_parm *opt,
> struct net *net = dev_net(skb->dev);
>
> if (type == ICMPV6_PKT_TOOBIG)
> - ip6_update_pmtu(skb, net, info, 0, 0, sock_net_uid(net,
> -NULL));
> + ip6_update_pmtu(skb, net, info, skb->dev->ifindex, 0,
This patch is pretty seriously mangled by your email client.
Fix this, then email a test patch to yourself.
Do not repost this patch to the mailing list until you can
successfully apply the patch you receive in your test email.
Thank you.
^ permalink raw reply
* Re: [PATCH 0/2] allow PTP 224.0.0.107 to be timestamped
From: David Miller @ 2018-07-07 12:23 UTC (permalink / raw)
To: ivan.khoronzhuk; +Cc: grygorii.strashko, linux-omap, netdev, linux-kernel
In-Reply-To: <20180706184445.29111-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Fri, 6 Jul 2018 21:44:43 +0300
> Allows packets with 224.0.0.107 mcas address for PTP packets to be timestamped.
> Only for cpsw version > v1.15.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] stmmac: fix signed 64-bit division
From: David Miller @ 2018-07-07 12:17 UTC (permalink / raw)
To: arnd
Cc: peppe.cavallaro, alexandre.torgue, joabreu, gustavo, netdev,
linux-kernel
In-Reply-To: <20180706133646.312427-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 6 Jul 2018 15:36:07 +0200
> I link error on 32-bit ARM points to yet another arithmetic bug:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_tc.o: In function `tc_setup_cbs':
> stmmac_tc.c:(.text+0x148): undefined reference to `__aeabi_uldivmod'
> stmmac_tc.c:(.text+0x1fc): undefined reference to `__aeabi_uldivmod'
> stmmac_tc.c:(.text+0x308): undefined reference to `__aeabi_uldivmod'
> stmmac_tc.c:(.text+0x320): undefined reference to `__aeabi_uldivmod'
> stmmac_tc.c:(.text+0x33c): undefined reference to `__aeabi_uldivmod'
> drivers/net/ethernet/stmicro/stmmac/stmmac_tc.o:stmmac_tc.c:(.text+0x3a4): more undefined references to `__aeabi_uldivmod' follow
>
> I observe that the last change to add the 'ul' prefix was incorrect,
> as it did not turn the result of the multiplication into a 64-bit
> expression on 32-bit architectures. Further, it seems that the
> do_div() macro gets confused by the fact that we pass a signed
> variable rather than unsigned into it.
>
> This changes the code to instead use the div_s64() helper that is
> meant for signed division, along with changing the constant suffix
> to 'll' to actually make it a 64-bit argument everywhere, fixing
> both of the issues I pointed out.
>
> I'm not completely convinced that this makes the code correct, but
> I'm fairly sure that we have two problems less than before.
>
> Fixes: 1f705bc61aee ("net: stmmac: Add support for CBS QDISC")
> Fixes: c18a9c096683 ("net: stmmac_tc: use 64-bit arithmetic instead of 32-bit")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
^ permalink raw reply
* [PATCH] drivers: net: lmc: remove redundant variable next_rx
From: Colin King @ 2018-07-07 12:47 UTC (permalink / raw)
To: David S . Miller, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable next_rx is being assigned but is never used hence it is
redundant and can be removed.
Cleans up clang warning:
warning: variable 'next_rx' set but not used [-Wunused-but-set-variable]
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wan/lmc/lmc_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 90a4ad9a2d08..093bd21f574d 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -1491,7 +1491,6 @@ static int lmc_rx(struct net_device *dev)
lmc_softc_t *sc = dev_to_sc(dev);
int i;
int rx_work_limit = LMC_RXDESCS;
- unsigned int next_rx;
int rxIntLoopCnt; /* debug -baz */
int localLengthErrCnt = 0;
long stat;
@@ -1505,7 +1504,6 @@ static int lmc_rx(struct net_device *dev)
rxIntLoopCnt = 0; /* debug -baz */
i = sc->lmc_next_rx % LMC_RXDESCS;
- next_rx = sc->lmc_next_rx;
while (((stat = sc->lmc_rxring[i].status) & LMC_RDES_OWN_BIT) != DESC_OWNED_BY_DC21X4)
{
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net 0/2] net/sched: fix NULL dereference in 'goto chain' control action
From: David Miller @ 2018-07-07 13:01 UTC (permalink / raw)
To: dcaratti; +Cc: jiri, amir, netdev
In-Reply-To: <cover.1530903047.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Fri, 6 Jul 2018 21:01:04 +0200
> in a couple of TC actions (i.e. csum and tunnel_key), the control action
> is stored together with the action-specific configuration data.
> This avoids a race condition (see [1]), but it causes a crash when 'goto
> chain' is used with the above actions. Since this race condition is
> tolerated on the other TC actions (it's present even on actions where the
> spinlock is still used), storing the control action in the common area
> should be acceptable for tunnel_key and csum as well.
>
> [1] https://www.spinics.net/lists/netdev/msg472047.html
Series applied and queued up for -stable, thanks Davide.
^ permalink raw reply
* Re: [PATCH] drivers: net: lmc: remove redundant variable next_rx
From: David Miller @ 2018-07-07 13:07 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180707124706.23344-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 7 Jul 2018 13:47:06 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Variable next_rx is being assigned but is never used hence it is
> redundant and can be removed.
>
> Cleans up clang warning:
> warning: variable 'next_rx' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next, thanks Colin.
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: David Miller @ 2018-07-07 13:11 UTC (permalink / raw)
To: lorenzo; +Cc: netdev, astrachan, subashab, eric.dumazet, dsa
In-Reply-To: <20180707073140.202004-1-lorenzo@google.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Sat, 7 Jul 2018 16:31:40 +0900
> Tested: passes Android sock_diag_test.py, which exercises this codepath
If this Android test case exercises this path, why didn't it trigger
the double free and thus cause this bug to be found much sooner?
Just curious.
^ permalink raw reply
* Re: [PATCH v4,net-next] vlan: implement vlan id and protocol changes
From: Ido Schimmel @ 2018-07-07 13:14 UTC (permalink / raw)
To: David Miller, 3chas3; +Cc: netdev
In-Reply-To: <20180707.201116.1526423963748651833.davem@davemloft.net>
On Sat, Jul 07, 2018 at 08:11:16PM +0900, David Miller wrote:
> Chas, it seems to me that you add the new notifier by not even one
> driver is listening for the event.
>
> Either it is necessary, and you should show at least one example
> use case, or it not necessary and therefore should not be added.
Chas, I'll take a look and send you a patch for mlxsw that you can fold
into your v5.
In the future, please Cc those who commented on earlier versions of your
patch.
Thanks!
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: Eric Dumazet @ 2018-07-07 13:28 UTC (permalink / raw)
To: Lorenzo Colitti, netdev
Cc: astrachan, subashab, eric.dumazet, davem, David Ahern
In-Reply-To: <20180707073140.202004-1-lorenzo@google.com>
On 07/07/2018 12:31 AM, Lorenzo Colitti wrote:
> When tcp_diag_destroy closes a TCP_NEW_SYN_RECV socket, it first
> frees it by calling inet_csk_reqsk_queue_drop_and_and_put in
> tcp_abort, and then frees it again by calling sock_gen_put.
>
> Since tcp_abort only has one caller, and all the other codepaths
> in tcp_abort don't free the socket, just remove the free in that
> function.
>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> Tested: passes Android sock_diag_test.py, which exercises this codepath
> Fixes: d7226c7a4dd1 ("net: diag: Fix refcnt leak in error path destroying socket")
> Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
> ---
Signed-off-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: Eric Dumazet @ 2018-07-07 13:29 UTC (permalink / raw)
To: David Miller, lorenzo; +Cc: netdev, astrachan, subashab, eric.dumazet, dsa
In-Reply-To: <20180707.221146.161981342461262899.davem@davemloft.net>
On 07/07/2018 06:11 AM, David Miller wrote:
> From: Lorenzo Colitti <lorenzo@google.com>
> Date: Sat, 7 Jul 2018 16:31:40 +0900
>
>> Tested: passes Android sock_diag_test.py, which exercises this codepath
>
> If this Android test case exercises this path, why didn't it trigger
> the double free and thus cause this bug to be found much sooner?
>
> Just curious.
>
Presumably android has not backported yet the refcount_t stuff in their kernels.
That is a guess though...
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/3] bpf: btf: add btf print functionality
From: Okash Khawaja @ 2018-07-07 13:30 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Jakub Kicinski, Daniel Borkmann, Alexei Starovoitov,
Yonghong Song, Quentin Monnet, David S. Miller, netdev,
kernel-team, linux-kernel
In-Reply-To: <20180703233350.aa33jyzrc6hmaelq@kafai-mbp.dhcp.thefacebook.com>
On Tue, Jul 03, 2018 at 04:33:50PM -0700, Martin KaFai Lau wrote:
> On Tue, Jul 03, 2018 at 03:38:43PM -0700, Jakub Kicinski wrote:
> > On Tue, 3 Jul 2018 15:23:31 -0700, Jakub Kicinski wrote:
> > > > > > + else
> > > > > > + jsonw_printf(jw, "%hhd", *((char *)data));
> > > > >
> > > > > ... I think you need to always print a string, and express it as
> > > > > \u00%02hhx for non-printable.
> > > > Okay that makes sense
> > >
> > > Yeah, IDK, char can be used as a byte as well as a string. In eBPF
> > > it may actually be more likely to just be used as a raw byte buffer...
> >
> > Actually, what is the definition/purpose of BTF_INT_CHAR? There seems
> > to be no BTF_INT_SHORT and BTF_INT_SIGNED can simply be of size 8...
> > Is normal int only used for bitfields of size 8 and BTF_INT_CHAR for
> > char variables?
> >
> > The kernel seems to be rejecting combinations of those flags, is
> > unsigned char going to not be marked as char then?
> BTF_INT_ENOCODING (CHAR/SIGNED/BOOL) is for formatting (e.g. pretty
> print). It is mainly how CTF is using it also. Hence, BTF_INT_ENCODINGs
> is not a 1:1 mapping to C integer types.
> The size of an interger is described by BTF_INT_BITS instead.
>
> >
> > > Either way I think it may be nice to keep it consistent, at least for
> > > the JSON output could we do either always ints or always characters?
> >
for !isprint() case, will "\x%02hhx" make more sense?
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: David Ahern @ 2018-07-07 13:33 UTC (permalink / raw)
To: David Miller, lorenzo; +Cc: netdev, astrachan, subashab, eric.dumazet
In-Reply-To: <20180707.221146.161981342461262899.davem@davemloft.net>
On 7/7/18 7:11 AM, David Miller wrote:
> From: Lorenzo Colitti <lorenzo@google.com>
> Date: Sat, 7 Jul 2018 16:31:40 +0900
>
>> Tested: passes Android sock_diag_test.py, which exercises this codepath
>
> If this Android test case exercises this path, why didn't it trigger
> the double free and thus cause this bug to be found much sooner?
>
wondering the same. How can I get access to sock_diag_test.py?
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: Eric Dumazet @ 2018-07-07 13:45 UTC (permalink / raw)
To: David Ahern, David Miller, lorenzo
Cc: netdev, astrachan, subashab, eric.dumazet
In-Reply-To: <248c63e2-6c6c-9c6e-37c2-4c7218f4899b@cumulusnetworks.com>
On 07/07/2018 06:33 AM, David Ahern wrote:
> On 7/7/18 7:11 AM, David Miller wrote:
>> From: Lorenzo Colitti <lorenzo@google.com>
>> Date: Sat, 7 Jul 2018 16:31:40 +0900
>>
>>> Tested: passes Android sock_diag_test.py, which exercises this codepath
>>
>> If this Android test case exercises this path, why didn't it trigger
>> the double free and thus cause this bug to be found much sooner?
>>
>
> wondering the same. How can I get access to sock_diag_test.py?
>
I would simply use ss -tKa src :443 command on a live web server ;)
Note to readers : Do not try that unless you want to kill your server.
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: Eric Dumazet @ 2018-07-07 13:51 UTC (permalink / raw)
To: David Ahern, David Miller, lorenzo; +Cc: netdev, astrachan, subashab
In-Reply-To: <b3b107e7-3ed9-e0c3-9c11-d91ac6f9f4e5@gmail.com>
On 07/07/2018 06:45 AM, Eric Dumazet wrote:
>
>
> On 07/07/2018 06:33 AM, David Ahern wrote:
>> On 7/7/18 7:11 AM, David Miller wrote:
>>> From: Lorenzo Colitti <lorenzo@google.com>
>>> Date: Sat, 7 Jul 2018 16:31:40 +0900
>>>
>>>> Tested: passes Android sock_diag_test.py, which exercises this codepath
>>>
>>> If this Android test case exercises this path, why didn't it trigger
>>> the double free and thus cause this bug to be found much sooner?
>>>
>>
>> wondering the same. How can I get access to sock_diag_test.py?
>>
>
> I would simply use ss -tKa src :443 command on a live web server ;)
>
> Note to readers : Do not try that unless you want to kill your server.
>
>
Here is a packetdrill test :
// Test SOCK_DESTROY on SYN_RECV request sockets
// We use the "ss" socket statistics tool, which uses inet_diag sockets.
// ss -K can be slow
--tolerance_usecs=15000
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 2>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
// ss -K is scary ! Do not mess with the filter or risk killing a lot of flows
+0 `ss -t -K -n state SYN-RECV src :8080 >/dev/null`
+.1 < . 1:1(0) ack 1 win 32890
+0 > R 1:1(0)
// The listener was not killed, but has no available child -> -1 EAGAIN
+0 accept(3, ..., ...) = -1 EAGAIN (Resource temporarily unavailable)
^ permalink raw reply
* Re: [PATCH net] net: diag: Don't double-free TCP_NEW_SYN_RECV sockets in tcp_abort
From: David Ahern @ 2018-07-07 13:56 UTC (permalink / raw)
To: Eric Dumazet, David Miller, lorenzo; +Cc: netdev, astrachan, subashab
In-Reply-To: <1017e0f1-e7eb-60d3-d6e6-914da1bc9962@gmail.com>
On 7/7/18 7:51 AM, Eric Dumazet wrote:
>
>
> On 07/07/2018 06:45 AM, Eric Dumazet wrote:
>>
>>
>> On 07/07/2018 06:33 AM, David Ahern wrote:
>>> On 7/7/18 7:11 AM, David Miller wrote:
>>>> From: Lorenzo Colitti <lorenzo@google.com>
>>>> Date: Sat, 7 Jul 2018 16:31:40 +0900
>>>>
>>>>> Tested: passes Android sock_diag_test.py, which exercises this codepath
>>>>
>>>> If this Android test case exercises this path, why didn't it trigger
>>>> the double free and thus cause this bug to be found much sooner?
>>>>
>>>
>>> wondering the same. How can I get access to sock_diag_test.py?
>>>
>>
>> I would simply use ss -tKa src :443 command on a live web server ;)
>>
>> Note to readers : Do not try that unless you want to kill your server.
>>
>>
>
> Here is a packetdrill test :
So I have to either learn how to use packetdrill or install a web server
and put load on it. If the Android tests are not publicly available then
the reference should be removed from the commit log.
>
> // Test SOCK_DESTROY on SYN_RECV request sockets
> // We use the "ss" socket statistics tool, which uses inet_diag sockets.
>
> // ss -K can be slow
> --tolerance_usecs=15000
>
>
> 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
> +0 bind(3, ..., ...) = 0
> +0 listen(3, 1) = 0
>
> +0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 2>
> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
>
> // ss -K is scary ! Do not mess with the filter or risk killing a lot of flows
> +0 `ss -t -K -n state SYN-RECV src :8080 >/dev/null`
>
> +.1 < . 1:1(0) ack 1 win 32890
> +0 > R 1:1(0)
>
> // The listener was not killed, but has no available child -> -1 EAGAIN
> +0 accept(3, ..., ...) = -1 EAGAIN (Resource temporarily unavailable)
>
I'll give this a try later. Thanks,
^ 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