Netdev List
 help / color / mirror / Atom feed
* Re: [RFC v2] virtio: support packed ring
From: Tiwei Bie @ 2018-04-18  1:17 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20180417184810-mutt-send-email-mst@kernel.org>

On Tue, Apr 17, 2018 at 06:54:51PM +0300, Michael S. Tsirkin wrote:
> On Tue, Apr 17, 2018 at 10:56:26PM +0800, Tiwei Bie wrote:
> > On Tue, Apr 17, 2018 at 05:04:59PM +0300, Michael S. Tsirkin wrote:
> > > On Tue, Apr 17, 2018 at 08:47:16PM +0800, Tiwei Bie wrote:
> > > > On Tue, Apr 17, 2018 at 03:17:41PM +0300, Michael S. Tsirkin wrote:
> > > > > On Tue, Apr 17, 2018 at 10:51:33AM +0800, Tiwei Bie wrote:
> > > > > > On Tue, Apr 17, 2018 at 10:11:58AM +0800, Jason Wang wrote:
> > > > > > > On 2018年04月13日 15:15, Tiwei Bie wrote:
> > > > > > > > On Fri, Apr 13, 2018 at 12:30:24PM +0800, Jason Wang wrote:
> > > > > > > > > On 2018年04月01日 22:12, Tiwei Bie wrote:
> > > > > > [...]
> > > > > > > > > > +static int detach_buf_packed(struct vring_virtqueue *vq, unsigned int head,
> > > > > > > > > > +			      void **ctx)
> > > > > > > > > > +{
> > > > > > > > > > +	struct vring_packed_desc *desc;
> > > > > > > > > > +	unsigned int i, j;
> > > > > > > > > > +
> > > > > > > > > > +	/* Clear data ptr. */
> > > > > > > > > > +	vq->desc_state[head].data = NULL;
> > > > > > > > > > +
> > > > > > > > > > +	i = head;
> > > > > > > > > > +
> > > > > > > > > > +	for (j = 0; j < vq->desc_state[head].num; j++) {
> > > > > > > > > > +		desc = &vq->vring_packed.desc[i];
> > > > > > > > > > +		vring_unmap_one_packed(vq, desc);
> > > > > > > > > > +		desc->flags = 0x0;
> > > > > > > > > Looks like this is unnecessary.
> > > > > > > > It's safer to zero it. If we don't zero it, after we
> > > > > > > > call virtqueue_detach_unused_buf_packed() which calls
> > > > > > > > this function, the desc is still available to the
> > > > > > > > device.
> > > > > > > 
> > > > > > > Well detach_unused_buf_packed() should be called after device is stopped,
> > > > > > > otherwise even if you try to clear, there will still be a window that device
> > > > > > > may use it.
> > > > > > 
> > > > > > This is not about whether the device has been stopped or
> > > > > > not. We don't have other places to re-initialize the ring
> > > > > > descriptors and wrap_counter. So they need to be set to
> > > > > > the correct values when doing detach_unused_buf.
> > > > > > 
> > > > > > Best regards,
> > > > > > Tiwei Bie
> > > > > 
> > > > > find vqs is the time to do it.
> > > > 
> > > > The .find_vqs() will call .setup_vq() which will eventually
> > > > call vring_create_virtqueue(). It's a different case. Here
> > > > we're talking about re-initializing the descs and updating
> > > > the wrap counter when detaching the unused descs (In this
> > > > case, split ring just needs to decrease vring.avail->idx).
> > > > 
> > > > Best regards,
> > > > Tiwei Bie
> > > 
> > > There's no requirement that  virtqueue_detach_unused_buf re-initializes
> > > the descs. It happens on cleanup path just before drivers delete the
> > > vqs.
> > 
> > Cool, I wasn't aware of it. I saw split ring decrease
> > vring.avail->idx after detaching an unused desc, so I
> > thought detaching unused desc also needs to make sure
> > that the ring state will be updated correspondingly.
> 
> 
> Hmm. You are right. Seems to be out console driver being out of spec.
> Will have to look at how to fix that :(
> 
> It was done here:
> 
> Commit b3258ff1d6086bd2b9eeb556844a868ad7d49bc8
> Author: Amit Shah <amit.shah@redhat.com>
> Date:   Wed Mar 16 19:12:10 2011 +0530
> 
>     virtio: Decrement avail idx on buffer detach
>     
>     When detaching a buffer from a vq, the avail.idx value should be
>     decremented as well.
>     
>     This was noticed by hot-unplugging a virtio console port and then
>     plugging in a new one on the same number (re-using the vqs which were
>     just 'disowned').  qemu reported
>     
>        'Guest moved used index from 0 to 256'
>     
>     when any IO was attempted on the new port.
>     
>     CC: stable@kernel.org
>     Reported-by: juzhang <juzhang@redhat.com>
>     Signed-off-by: Amit Shah <amit.shah@redhat.com>
>     Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> 
> The spec is quite explicit though:
> 	A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose”
> 	buffers).
> 

Hmm.. Got it. Thanks!

Best regards,
Tiwei Bie


> 
> 
> 
> 
> > If there is no such requirement, do you think it's OK
> > to remove below two lines:
> > 
> > vq->avail_idx_shadow--;
> > vq->vring.avail->idx = cpu_to_virtio16(_vq->vdev, vq->avail_idx_shadow);
> > 
> > from virtqueue_detach_unused_buf(), and we could have
> > one generic function to handle both rings:
> > 
> > void *virtqueue_detach_unused_buf(struct virtqueue *_vq)
> > {
> > 	struct vring_virtqueue *vq = to_vvq(_vq);
> > 	unsigned int num, i;
> > 	void *buf;
> > 
> > 	START_USE(vq);
> > 
> > 	num = vq->packed ? vq->vring_packed.num : vq->vring.num;
> > 
> > 	for (i = 0; i < num; i++) {
> > 		if (!vq->desc_state[i].data)
> > 			continue;
> > 		/* detach_buf clears data, so grab it now. */
> > 		buf = vq->desc_state[i].data;
> > 		detach_buf(vq, i, NULL);
> > 		END_USE(vq);
> > 		return buf;
> > 	}
> > 	/* That should have freed everything. */
> > 	BUG_ON(vq->vq.num_free != num);
> > 
> > 	END_USE(vq);
> > 	return NULL;
> > }
> > 
> > Best regards,
> > Tiwei Bie
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

^ permalink raw reply

* Re: [PATCH 04/10] net: ax88796: Add block_input/output hooks to ax_plat_data
From: Andrew Lunn @ 2018-04-18  1:19 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: kbuild test robot, kbuild-all, netdev, Linux/m68k,
	Michael Karcher, Michael Karcher
In-Reply-To: <CAOmrzkKSmp5phhLYvs14N13tPCuAYCOi-2eBrRqnOgB6+Q6Nyw@mail.gmail.com>

On Wed, Apr 18, 2018 at 12:53:21PM +1200, Michael Schmitz wrote:
> I think this is a false positive - we're encouraged to provide the
> full parameter list for functions, so the sreuct sk_buff* can't be
> avoided.

Hi Michael

How is <linux/skbuff.h> being included?

You probably want to build using the .config file and see.

    Andrew

^ permalink raw reply

* [PATCH v3] net: change the comment of dev_mc_init
From: sunlianwen @ 2018-04-18  1:22 UTC (permalink / raw)
  To: netdev

The comment of dev_mc_init() is wrong. which use dev_mc_flush
instead of dev_mc_init.

Signed-off-by: Lianwen Sun <sunlw.fnst@cn.fujitsu.com
---
 net/core/dev_addr_lists.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
index e3e6a3e2ca22..d884d8f5f0e5 100644
--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -839,7 +839,7 @@ void dev_mc_flush(struct net_device *dev)
 EXPORT_SYMBOL(dev_mc_flush);
 
 /**
- *	dev_mc_flush - Init multicast address list
+ *	dev_mc_init - Init multicast address list
  *	@dev: device
  *
  *	Init multicast address list.
-- 
2.17.0

^ permalink raw reply related

* Re: [PATCH 04/10] net: ax88796: Add block_input/output hooks to ax_plat_data
From: Finn Thain @ 2018-04-18  1:23 UTC (permalink / raw)
  To: Michael Schmitz
  Cc: kbuild test robot, kbuild-all, netdev, Linux/m68k,
	Michael Karcher, Michael Karcher
In-Reply-To: <CAOmrzkKSmp5phhLYvs14N13tPCuAYCOi-2eBrRqnOgB6+Q6Nyw@mail.gmail.com>

On Wed, 18 Apr 2018, Michael Schmitz wrote:

> I think this is a false positive - we're encouraged to provide the
> full parameter list for functions, so the sreuct sk_buff* can't be
> avoided.
> 

I don't think it's a false positive. I think ax88796.h would need to 
#include <linux/skbuff.h>.

You may be able to get away with a forward declaration, as in,
struct skbuff;
but I'm not sure about that. I would have to build mach-anubis.c to check.

But why do you need to pass an skbuff pointer here? xs100_block_input() 
only accesses skb->data.

BTW, this patch has an unrelated whitespace change.

-- 

> Cheers,
> 
>   Michael
> 
> 
> On Wed, Apr 18, 2018 at 6:46 AM, kbuild test robot <lkp@intel.com> wrote:
> > Hi Michael,
> >
> > I love your patch! Perhaps something to improve:
> >
> > [auto build test WARNING on v4.16]
> > [cannot apply to net-next/master net/master v4.17-rc1 next-20180417]
> > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> >
> > url:    https://github.com/0day-ci/linux/commits/Michael-Schmitz/New-network-driver-for-Amiga-X-Surf-100-m68k/20180417-141150
> > config: arm-samsung (attached as .config)
> > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> > reproduce:
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # save the attached .config to linux build tree
> >         make.cross ARCH=arm
> >
> > All warnings (new ones prefixed by >>):
> >
> >    In file included from arch/arm/mach-s3c24xx/mach-anubis.c:42:0:
> >>> include/net/ax88796.h:35:11: warning: 'struct sk_buff' declared inside parameter list will not be visible outside of this definition or declaration
> >        struct sk_buff *skb, int ring_offset);
> >               ^~~~~~~
> >
> > vim +35 include/net/ax88796.h
> >
> >     20
> >     21  struct ax_plat_data {
> >     22          unsigned int     flags;
> >     23          unsigned char    wordlength;    /* 1 or 2 */
> >     24          unsigned char    dcr_val;       /* default value for DCR */
> >     25          unsigned char    rcr_val;       /* default value for RCR */
> >     26          unsigned char    gpoc_val;      /* default value for GPOC */
> >     27          u32             *reg_offsets;   /* register offsets */
> >     28          u8              *mac_addr;      /* MAC addr (only used when
> >     29                                             AXFLG_MAC_FROMPLATFORM is used */
> >     30
> >     31          /* uses default ax88796 buffer if set to NULL */
> >     32          void (*block_output)(struct net_device *dev, int count,
> >     33                          const unsigned char *buf, int star_page);
> >     34          void (*block_input)(struct net_device *dev, int count,
> >   > 35                          struct sk_buff *skb, int ring_offset);
> >     36  };
> >     37
> >
> > ---
> > 0-DAY kernel test infrastructure                Open Source Technology Center
> > https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re:Re: [PATCH net] net: Fix one possible memleak in ip_setup_cork
From: Gao Feng @ 2018-04-18  1:33 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, netdev@vger.kernel.org
In-Reply-To: <e6c20036-4b68-560a-636f-f949e483d07a@gmail.com>

At 2018-04-17 05:18:25, "Eric Dumazet" <eric.dumazet@gmail.com> wrote:
>
>
>On 04/16/2018 09:58 AM, David Miller wrote:
>> From: gfree.wind@vip.163.com
>> Date: Mon, 16 Apr 2018 10:16:45 +0800
>> 
>>> From: Gao Feng <gfree.wind@vip.163.com>
>>>
>>> It would allocate memory in this function when the cork->opt is NULL. But
>>> the memory isn't freed if failed in the latter rt check, and return error
>>> directly. It causes the memleak if its caller is ip_make_skb which also
>>> doesn't free the cork->opt when meet a error.
>>>
>>> Now move the rt check ahead to avoid the memleak.
>>>
>>> Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
>> 
>> Looks good, applied and queued up for -stable.
>> 
>> I guess in the other code paths, ip_flush_pending_frames() or similar
>> would clean up the in-sock cork information.
>> 
>
>I am not sure ip_make_skb() can be called with a NULL rt.
>
>Patch makes no harm, but does not seem to fix a bug.
>

Thanks Eric.

I just look up current all callers of ip_make_skb and ip_append_data, they check
if the rt is valid ahead. So current codes won't pass one NULL rt to ip_setup_cork indeed.

Then this patch is just as an enhancement, not a fix. 
As the programming rule, the function should free the mem which is allocated by itself when
it failed.

Best Regards
Feng

^ permalink raw reply

* [Regression] net/phy/micrel.c v4.9.94
From: Chris Ruehl @ 2018-04-18  1:34 UTC (permalink / raw)
  To: f.fainelli, netdev

Hello,

I like to get your heads up at a regression introduced in 4.9.94
commitment lead to a kernel ops and make the network unusable on my MX6DL 
customized board.

Race condition resume is called on startup and the phy not yet initialized.

[    7.313366] Unable to handle kernel NULL pointer dereference at virtual 
address 00000008 

[    7.321602] pgd = ecfc0000 
 

[    7.324950] [00000008] *pgd=8e901831 
 

[    7.328652] Internal error: Oops: 17 [#1] PREEMPT SMP ARM 
 

[    7.334061] Modules linked in: 
 

[    7.337146] CPU: 0 PID: 269 Comm: ip Not tainted 4.9.94 #11 
 

[    7.342725] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) 
 

[    7.349259] task: ece59900 task.stack: ec9ea000 
 

[    7.353809] PC is at kszphy_config_reset+0x14/0x148 
 

[    7.358703] LR is at kszphy_resume+0x1c/0x6c 
 

[    7.362983] pc : [<c056a24c>]    lr : [<c056a4fc>]    psr: 60030013 
 

[    7.362983] sp : ec9eb918  ip : ec9eb938  fp : ec9eb934 
 

[    7.374467] r10: 00000007  r9 : 00000000  r8 : ee693c00 
 

[    7.379700] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : ee6fc000 
 

[    7.386234] r3 : 00000001  r2 : 00000000  r1 : 00000110  r0 : ee6fc000 
 

[    7.392768] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none 
 

[    7.399911] Control: 10c5387d  Table: 3cfc004a  DAC: 00000051 
 

[    7.405663] Process ip (pid: 269, stack limit = 0xec9ea210) 
 

[    7.411244] Stack: (0xec9eb918 to 0xec9ec000) 
 

[    7.415611] b900: 
ee6fc000 00000000 

[    7.423800] b920: ee031000 00000000 ec9eb94c ec9eb938 c056a4fc c056a244 
ee6fc000 00000000 

[    7.431988] b940: ec9eb97c ec9eb950 c05681e4 c056a4ec 00000007 ee6fc000 
ee6fc000 c056ce7c 

[    7.440174] b960: c056ce7c ee031000 ee55c818 00000000 ec9eb99c ec9eb980 
c05683cc c0568134 

[    7.448364] b980: 00000007 ec9eba10 ee6fc000 00000007 ec9eb9c4 ec9eb9a0 
c0568450 c05683bc 

[    7.456550] b9a0: 00000007 00000005 ee031000 ec9eb9d3 00000200 c1508da4 
ec9eba6c ec9eb9c8 

[    7.464736] b9c0: c056ce24 c0568410 00000005 ee03162c 32000001 30383831 
652e3030 72656874 

[    7.472921] b9e0: 2d74656e 00000031 000003e8 000000c8 c01732ec c0172adc 
000003e8 000000c8 

[    7.481109] ba00: 024000c0 ee55c000 c150e454 024000c0 38383132 2e303030 
65687465 74656e72 

[    7.489296] ba20: 303a312d ee000035 ec9eba6c ec9eba38 c0224b50 c0175eb8 
ec9eba6c c056eb44 

[    7.497482] ba40: c056bbe0 f0c16000 ee031000 ee55c000 00000200 f0c16000 
ee031000 ee55c000 

[    7.505667] ba60: ec9ebaa4 ec9eba70 c056eba4 c056cd1c 00000001 ee03162c 
ec9ebaa4 ee031000 

[    7.513855] ba80: 00000000 c09566ec ee031030 00000000 ec9ccd10 ecb39900 
ec9ebacc ec9ebaa8 

[    7.522043] baa0: c06ad6e0 c056e92c ec9ebacc ee031000 ee031000 00000001 
00001003 00001002 

[    7.530229] bac0: ec9ebaf4 ec9ebad0 c06ad99c c06ad63c 00001002 ee031000 
ee031148 00001002 

[    7.538414] bae0: 00000000 00000000 ec9ebb1c ec9ebaf8 c06ada6c c06ad90c 
00001002 00000000 

[    7.546601] bb00: ee031000 ec9ebc28 00000000 c09566ec ec9ebb94 ec9ebb20 
c06c1034 c06ada58 

[    7.554787] bb20: c0c50df8 2e184000 ec9ebb44 ec9ebb38 c0173528 c0173320 
ec9ebbd4 c0e82b6c 

[    7.562972] bb40: 00000000 ece59dc8 ebb4e9d0 c9eae3f3 ece59900 00000003 
ece59900 0000005e 

[    7.571157] bb60: c14e30ec c0d1e51c ece59900 00000000 ee031000 ec9ccd00 
00000000 00000000 

[    7.579346] bb80: ec9ebb98 00000000 ec9ebd04 ec9ebb98 c06c30cc c06c0d68 
ec9ebbc4 00000000 

[    7.587531] bba0: c01758bc ecb39900 c09eb3a0 ec9ccd20 00000000 ec9ccd10 
00000001 ece59900 

[    7.595715] bbc0: c01e0e64 00000000 00000000 00000001 ec9ebbfc 00000000 
00000000 00000000 

[    7.603900] bbe0: 00000000 00000000 00000000 ffffff00 ec9ebc0c ec9ebc00 
c0173528 c0173320 

[    7.612084] bc00: ec9ebc9c ec9ebc10 c01e0e64 c0173520 00000000 0000000e 
ece59900 00000096 

[    7.620269] bc20: c14e30ec c0d1e51c 00000000 00000000 00000000 00000000 
00000000 00000000 

[    7.628452] bc40: 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 

[    7.636636] bc60: 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 

[    7.644819] bc80: 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 

[    7.653003] bca0: 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 

[    7.661186] bcc0: 00000000 00000000 00000000 00000000 00000000 00000000 
c06d3870 00000000 

[    7.669372] bce0: ec9ccd00 ecb39900 c15226e4 00000000 00000000 ecb39900 
ec9ebd44 ec9ebd08 

[    7.677556] bd00: c06c343c c06c2bdc c0869c2c c0173520 00000001 00000000 
c06c06e4 00000000 

[    7.685741] bd20: 00000000 ec9ccd00 c06c32b8 ecb39900 ecb39900 00000000 
ec9ebd64 ec9ebd48 

[    7.693926] bd40: c06d86cc c06c32c4 00000000 ecb39900 00000020 ec970400 
ec9ebd7c ec9ebd68 

[    7.702110] bd60: c06c06f4 c06d8630 c06c06c4 ee15f400 ec9ebdac ec9ebd80 
c06d802c c06c06d0 

[    7.710294] bd80: ec9ebf50 7fffffff ec970400 ec9ebf48 ec970400 00000000 
00000020 00000000 

[    7.718477] bda0: ec9ebe0c ec9ebdb0 c06d84e8 c06d7ec8 0000000c ec9ebe48 
0000000c 00000000 

[    7.726661] bdc0: beee97bc 00000008 00000000 ee0cbd80 00000000 0000010d 
00000000 00000000 

[    7.734845] bde0: ec9ebe24 ec9ebf48 00000000 eda478c0 00000128 00000000 
00000000 ec9ebe28 

[    7.743029] be00: ec9ebe1c ec9ebe10 c068b124 c06d8180 ec9ebf34 ec9ebe20 
c068bcac c068b114 

[    7.751213] be20: ec9ebe8c 00000000 c01759cc c01704b0 ec9ebea4 ec9ebe40 
c0209960 c01187ac 

[    7.759396] be40: 00000000 00000000 beeed828 00000020 00000000 00000000 
600f0113 ec98ce70 

[    7.767580] be60: beee9000 ed7ac714 ece59900 ed7ac6c0 00000817 beee977c 
ed7ac714 00000055 

[    7.775764] be80: ec9ebea4 ec9ebe90 00000010 00000000 00000000 ec9ebfb0 
ec9ebefc ec9ebea8 

[    7.783948] bea0: c0115b74 c016ec18 00000000 c0d55a61 c025e178 ffffffea 
ee022f10 00000000 

[    7.792131] bec0: 00000000 00000000 00000800 00000000 c025ddc0 c0d0a44c 
00000817 c0115990 

[    7.800315] bee0: beee977c ec9ebfb0 00054694 beeedec0 ec9ebfac ec9ebf00 
c0101368 c011599c 

[    7.808500] bf00: ec9ebf1c ec9ebf10 c025a578 eda478c0 00000000 beee97a4 
00000128 c0107ee4 

[    7.816685] bf20: ec9ea000 00000000 ec9ebf94 ec9ebf38 c068ca54 c068bad4 
00000000 00000000 

[    7.824868] bf40: 00000000 fffffff7 ec9ebe88 0000000c 00000001 00000000 
00000000 ec9ebe50 

[    7.833052] bf60: 00000000 00000001 00000000 00000000 00000000 00000000 
ec9ebf94 0000000c 

[    7.841235] bf80: 00000010 beee9790 ec9ebfa4 ec9ebf98 c068ca94 c068ca18 
00000000 ec9ebfa8 

[    7.849419] bfa0: c0107d20 c068ca90 0000000c 00000010 00000003 beee97a4 
00000000 00000005 

[    7.857604] bfc0: 0000000c 00000010 beee9790 00000128 00000000 00054694 
beee97a4 beee97c0 

[    7.865789] bfe0: 00000000 beee9774 00034d1d b6eaaf16 400f0030 00000003 
3fffd861 3fffdc61 

[    7.873968] Backtrace: 
 

[    7.876450] [<c056a238>] (kszphy_config_reset) from [<c056a4fc>] 
(kszphy_resume+0x1c/0x6c) 

[    7.884723]  r7:00000000 r6:ee031000 r5:00000000 r4:ee6fc000 
 

[    7.890392] [<c056a4e0>] (kszphy_resume) from [<c05681e4>] 
(phy_attach_direct+0xbc/0x1bc) 

[    7.898575]  r5:00000000 r4:ee6fc000 
 

[    7.902158] [<c0568128>] (phy_attach_direct) from [<c05683cc>] 
(phy_connect_direct+0x1c/0x54) 

[    7.910691]  r10:00000000 r9:ee55c818 r8:ee031000 r7:c056ce7c r6:c056ce7c 
r5:ee6fc000 

[    7.918525]  r4:ee6fc000 r3:00000007 
 

[    7.922108] [<c05683b0>] (phy_connect_direct) from [<c0568450>] 
(phy_connect+0x4c/0x80) 

[    7.930117]  r6:00000007 r5:ee6fc000 r4:ec9eba10 r3:00000007 
 

[    7.935785] [<c0568404>] (phy_connect) from [<c056ce24>] 
(fec_enet_mii_probe+0x114/0x16c) 

[    7.943969]  r8:c1508da4 r7:00000200 r6:ec9eb9d3 r5:ee031000 r4:00000005 
r3:00000007 

[    7.951720] [<c056cd10>] (fec_enet_mii_probe) from [<c056eba4>] 
(fec_enet_open+0x284/0x320) 

[    7.960076]  r6:ee55c000 r5:ee031000 r4:f0c16000 
 

[    7.964704] [<c056e920>] (fec_enet_open) from [<c06ad6e0>] 
(__dev_open+0xb0/0x114) 

[    7.972281]  r10:ecb39900 r9:ec9ccd10 r8:00000000 r7:ee031030 r6:c09566ec 
r5:00000000 

[    7.980113]  r4:ee031000 
 

[    7.982655] [<c06ad630>] (__dev_open) from [<c06ad99c>] 
(__dev_change_flags+0x9c/0x14c) 

[    7.990665]  r7:00001002 r6:00001003 r5:00000001 r4:ee031000 
 

[    7.996333] [<c06ad900>] (__dev_change_flags) from [<c06ada6c>] 
(dev_change_flags+0x20/0x50) 

[    8.004777]  r8:00000000 r7:00000000 r6:00001002 r5:ee031148 r4:ee031000 
r3:00001002 

[    8.012533] [<c06ada4c>] (dev_change_flags) from [<c06c1034>] 
(do_setlink+0x2d8/0x838) 

[    8.020456]  r8:c09566ec r7:00000000 r6:ec9ebc28 r5:ee031000 r4:00000000 
r3:00001002 

[    8.028207] [<c06c0d5c>] (do_setlink) from [<c06c30cc>] 
(rtnl_newlink+0x4fc/0x6e8) 

[    8.035784]  r10:00000000 r9:ec9ebb98 r8:00000000 r7:00000000 r6:ec9ccd00 
r5:ee031000 

[    8.043616]  r4:00000000 
 

[    8.046159] [<c06c2bd0>] (rtnl_newlink) from [<c06c343c>] 
(rtnetlink_rcv_msg+0x184/0x234) 

[    8.054343]  r10:ecb39900 r9:00000000 r8:00000000 r7:c15226e4 r6:ecb39900 
r5:ec9ccd00 

[    8.062175]  r4:00000000 
 

[    8.064720] [<c06c32b8>] (rtnetlink_rcv_msg) from [<c06d86cc>] 
(netlink_rcv_skb+0xa8/0xc4) 

[    8.072990]  r8:00000000 r7:ecb39900 r6:ecb39900 r5:c06c32b8 r4:ec9ccd00
[    8.079701] [<c06d8624>] (netlink_rcv_skb) from [<c06c06f4>] 
(rtnetlink_rcv+0x30/0x38)
[    8.087622]  r6:ec970400 r5:00000020 r4:ecb39900 r3:00000000
[    8.093291] [<c06c06c4>] (rtnetlink_rcv) from [<c06d802c>] 
(netlink_unicast+0x170/0x1f8)
[    8.101384]  r4:ee15f400 r3:c06c06c4
[    8.104968] [<c06d7ebc>] (netlink_unicast) from [<c06d84e8>] 
(netlink_sendmsg+0x374/0x388)
[    8.113238]  r8:00000000 r7:00000020 r6:00000000 r5:ec970400 r4:ec9ebf48
[    8.119952] [<c06d8174>] (netlink_sendmsg) from [<c068b124>] 
(sock_sendmsg+0x1c/0x2c)
[    8.127789]  r10:ec9ebe28 r9:00000000 r8:00000000 r7:00000128 r6:eda478c0 
r5:00000000
[    8.135621]  r4:ec9ebf48
[    8.138167] [<c068b108>] (sock_sendmsg) from [<c068bcac>] 
(___sys_sendmsg+0x1e4/0x20c)
[    8.146095] [<c068bac8>] (___sys_sendmsg) from [<c068ca54>] 
(__sys_sendmsg+0x48/0x78)
[    8.153932]  r10:00000000 r9:ec9ea000 r8:c0107ee4 r7:00000128 r6:beee97a4 
r5:00000000
[    8.161764]  r4:eda478c0
[    8.164304] [<c068ca0c>] (__sys_sendmsg) from [<c068ca94>] 
(SyS_sendmsg+0x10/0x14)
[    8.171880]  r6:beee9790 r5:00000010 r4:0000000c
[    8.176510] [<c068ca84>] (SyS_sendmsg) from [<c0107d20>] 
(ret_fast_syscall+0x0/0x1c)
[    8.184261] Code: e92dd8f0 e24cb004 e590628c e1a04000 (e5d63008)
[    8.192713] ---[ end trace 07c02ee14784bc48 ]---

Kind regards
Chris


-- 
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521

Disclaimer: https://www.gtsys.com.hk/email/classified.html

^ permalink raw reply

* Re: [PATCH net-next 0/5] virtio-net: Add SCTP checksum offload support
From: Marcelo Ricardo Leitner @ 2018-04-18  1:33 UTC (permalink / raw)
  To: Vlad Yasevich
  Cc: Vladislav Yasevich, netdev, linux-sctp, virtualization, mst,
	jasowang, nhorman, Xin Long
In-Reply-To: <6bc762f6-d6fb-5471-2893-a888cce199f9@redhat.com>

On Tue, Apr 17, 2018 at 04:35:18PM -0400, Vlad Yasevich wrote:
> On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote:
> > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote:
> >> Now that we have SCTP offload capabilities in the kernel, we can add
> >> them to virtio as well.  First step is SCTP checksum.
> >
> > Thanks.
> >
> >> As for GSO, the way sctp GSO is currently implemented buys us nothing
> >> in added support to virtio.  To add true GSO, would require a lot of
> >> re-work inside of SCTP and would require extensions to the virtio
> >> net header to carry extra sctp data.
> >
> > Can you please elaborate more on this? Is this because SCTP GSO relies
> > on the gso skb format for knowing how to segment it instead of having
> > a list of sizes?
> >
>
> it's mainly because all the true segmentation, placing data into chunks,
> has already happened.  All that GSO does is allow for higher bundling
> rate between VMs. If that is all SCTP GSO ever going to do, that fine,
> but the goal is to do real GSO eventually and potentially reduce the
> amount of memory copying we are doing.
> If we do that, any current attempt at GSO in virtio would have to be
> depricated and we'd need GSO2 or something like that.
>
> This is why, after doing the GSO support, I decided not to include it.

Gotcha. I don't think it will ever go further than what we have now.
Placing data into chunks later is not really feasible/wanted,
especially now with stream schedulers and idata chunks. Doesn't seem
worth the hassle... we would have to support things like, "segment
half of this message plus a third of this other one from that other
stream." (in case it's round robin).

  Marcelo

^ permalink raw reply

* Re: [PATCH v3 net,stable] tun: fix vlan packet truncation
From: Jason Wang @ 2018-04-18  1:43 UTC (permalink / raw)
  To: Bjørn Mork, netdev
In-Reply-To: <20180417204638.11800-1-bjorn@mork.no>



On 2018年04月18日 04:46, Bjørn Mork wrote:
> Bogus trimming in tun_net_xmit() causes truncated vlan packets.
>
> skb->len is correct whether or not skb_vlan_tag_present() is true. There
> is no more reason to adjust the skb length on xmit in this driver than
> any other driver. tun_put_user() adds 4 bytes to the total for tagged
> packets because it transmits the tag inline to userspace.  This is
> similar to a nic transmitting the tag inline on the wire.
>
> Reproducing the bug by sending any tagged packet through back-to-back
> connected tap interfaces:
>
>   socat TUN,tun-type=tap,iff-up,tun-name=in TUN,tun-type=tap,iff-up,tun-name=out &
>   ip link add link in name in.20 type vlan id 20
>   ip addr add 10.9.9.9/24 dev in.20
>   ip link set in.20 up
>   tshark -nxxi in -f arp -c1 2>/dev/null &
>   tshark -nxxi out -f arp -c1 2>/dev/null &
>   ping -c 1 10.9.9.5 >/dev/null 2>&1
>
> The output from the 'in' and 'out' interfaces are different when the
> bug is present:
>
>   Capturing on 'in'
>   0000  ff ff ff ff ff ff 76 cf 76 37 d5 0a 81 00 00 14   ......v.v7......
>   0010  08 06 00 01 08 00 06 04 00 01 76 cf 76 37 d5 0a   ..........v.v7..
>   0020  0a 09 09 09 00 00 00 00 00 00 0a 09 09 05         ..............
>
>   Capturing on 'out'
>   0000  ff ff ff ff ff ff 76 cf 76 37 d5 0a 81 00 00 14   ......v.v7......
>   0010  08 06 00 01 08 00 06 04 00 01 76 cf 76 37 d5 0a   ..........v.v7..
>   0020  0a 09 09 09 00 00 00 00 00 00                     ..........
>
> Fixes: aff3d70a07ff ("tun: allow to attach ebpf socket filter")
> Cc: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> v2:
>   - Must still call pskb_trim() after running the filter, as pointed out by
>     Jason and David. But no need to check if len < 0 anymore, since
>     run_ebpf_filter() returns insigned ints.
>
> v3:
>   - actually change the len <= 0 test as mentioned above
>
>
>   drivers/net/tun.c | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 28583aa0c17d..ef33950a45d9 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1102,12 +1102,7 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
>   		goto drop;
>   
>   	len = run_ebpf_filter(tun, skb, len);
> -
> -	/* Trim extra bytes since we may insert vlan proto & TCI
> -	 * in tun_put_user().
> -	 */
> -	len -= skb_vlan_tag_present(skb) ? sizeof(struct veth) : 0;
> -	if (len <= 0 || pskb_trim(skb, len))
> +	if (len == 0 || pskb_trim(skb, len))
>   		goto drop;
>   
>   	if (unlikely(skb_orphan_frags_rx(skb, GFP_ATOMIC)))

Acked-by: Jason Wang <jasowang@redhat.com>

Thanks

^ permalink raw reply

* [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.
From: greearb-my8/4N5VtI7c+919tysfdA @ 2018-04-18  1:49 UTC (permalink / raw)
  To: netdev-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ben Greear

From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>

This is similar to ETHTOOL_GSTATS, but it allows you to specify
flags.  These flags can be used by the driver to decrease the
amount of stats refreshed.  In particular, this helps with ath10k
since getting the firmware stats can be slow.

Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
---
 include/linux/ethtool.h      | 12 ++++++++++++
 include/uapi/linux/ethtool.h | 10 ++++++++++
 net/core/ethtool.c           | 40 +++++++++++++++++++++++++++++++++++-----
 3 files changed, 57 insertions(+), 5 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index ebe4181..a4aa11f 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -243,6 +243,15 @@ bool ethtool_convert_link_mode_to_legacy_u32(u32 *legacy_u32,
  * @get_ethtool_stats: Return extended statistics about the device.
  *	This is only useful if the device maintains statistics not
  *	included in &struct rtnl_link_stats64.
+ * @get_ethtool_stats2: Return extended statistics about the device.
+ *	This is only useful if the device maintains statistics not
+ *	included in &struct rtnl_link_stats64.
+ *      Takes a flags argument:  0 means all (same as get_ethtool_stats),
+ *      0x1 (ETHTOOL_GS2_SKIP_FW) means skip firmware stats.
+ *      Other flags are reserved for now.
+ *      Same number of stats will be returned, but some of them might
+ *      not be as accurate/refreshed.  This is to allow not querying
+ *      firmware or other expensive-to-read stats, for instance.
  * @begin: Function to be called before any other operation.  Returns a
  *	negative error code or zero.
  * @complete: Function to be called after any other operation except
@@ -355,6 +364,9 @@ struct ethtool_ops {
 	int	(*set_phys_id)(struct net_device *, enum ethtool_phys_id_state);
 	void	(*get_ethtool_stats)(struct net_device *,
 				     struct ethtool_stats *, u64 *);
+	void	(*get_ethtool_stats2)(struct net_device *dev,
+				      struct ethtool_stats *gstats, u64 *data,
+				      u32 flags);
 	int	(*begin)(struct net_device *);
 	void	(*complete)(struct net_device *);
 	u32	(*get_priv_flags)(struct net_device *);
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 4ca65b5..1c74f3e 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1396,11 +1396,21 @@ enum ethtool_fec_config_bits {
 #define ETHTOOL_PHY_STUNABLE	0x0000004f /* Set PHY tunable configuration */
 #define ETHTOOL_GFECPARAM	0x00000050 /* Get FEC settings */
 #define ETHTOOL_SFECPARAM	0x00000051 /* Set FEC settings */
+#define ETHTOOL_GSTATS2		0x00000052 /* get NIC-specific statistics
+					    * with ability to specify flags.
+					    * See ETHTOOL_GS2* below.
+					    */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET		ETHTOOL_GSET
 #define SPARC_ETH_SSET		ETHTOOL_SSET
 
+/* GSTATS2 flags */
+#define ETHTOOL_GS2_SKIP_NONE (0)    /* default is to update all stats */
+#define ETHTOOL_GS2_SKIP_FW   (1<<0) /* Skip reading stats that probe firmware,
+				      * and thus are slow/expensive.
+				      */
+
 /* Link mode bit indices */
 enum ethtool_link_mode_bit_indices {
 	ETHTOOL_LINK_MODE_10baseT_Half_BIT	= 0,
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 03416e6..6ec3413 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1952,16 +1952,14 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
 	return rc;
 }
 
-static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)
+static int _ethtool_get_stats(struct net_device *dev, void __user *useraddr,
+			      u32 flags)
 {
 	struct ethtool_stats stats;
 	const struct ethtool_ops *ops = dev->ethtool_ops;
 	u64 *data;
 	int ret, n_stats;
 
-	if (!ops->get_ethtool_stats || !ops->get_sset_count)
-		return -EOPNOTSUPP;
-
 	n_stats = ops->get_sset_count(dev, ETH_SS_STATS);
 	if (n_stats < 0)
 		return n_stats;
@@ -1976,7 +1974,10 @@ static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)
 	if (n_stats && !data)
 		return -ENOMEM;
 
-	ops->get_ethtool_stats(dev, &stats, data);
+	if (flags != ETHTOOL_GS2_SKIP_NONE)
+		ops->get_ethtool_stats2(dev, &stats, data, flags);
+	else
+		ops->get_ethtool_stats(dev, &stats, data);
 
 	ret = -EFAULT;
 	if (copy_to_user(useraddr, &stats, sizeof(stats)))
@@ -1991,6 +1992,31 @@ static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)
 	return ret;
 }
 
+static int ethtool_get_stats(struct net_device *dev, void __user *useraddr)
+{
+	const struct ethtool_ops *ops = dev->ethtool_ops;
+
+	if (!ops->get_ethtool_stats || !ops->get_sset_count)
+		return -EOPNOTSUPP;
+	return _ethtool_get_stats(dev, useraddr, ETHTOOL_GS2_SKIP_NONE);
+}
+
+static int ethtool_get_stats2(struct net_device *dev, void __user *useraddr)
+{
+	struct ethtool_stats stats;
+	const struct ethtool_ops *ops = dev->ethtool_ops;
+	u32 flags = 0;
+
+	if (!ops->get_ethtool_stats2 || !ops->get_sset_count)
+		return -EOPNOTSUPP;
+
+	if (copy_from_user(&stats, useraddr, sizeof(stats)))
+		return -EFAULT;
+
+	flags = stats.n_stats;
+	return _ethtool_get_stats(dev, useraddr, flags);
+}
+
 static int ethtool_get_phy_stats(struct net_device *dev, void __user *useraddr)
 {
 	struct ethtool_stats stats;
@@ -2632,6 +2658,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
 	case ETHTOOL_GSSET_INFO:
 	case ETHTOOL_GSTRINGS:
 	case ETHTOOL_GSTATS:
+	case ETHTOOL_GSTATS2:
 	case ETHTOOL_GPHYSTATS:
 	case ETHTOOL_GTSO:
 	case ETHTOOL_GPERMADDR:
@@ -2742,6 +2769,9 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
 	case ETHTOOL_GSTATS:
 		rc = ethtool_get_stats(dev, useraddr);
 		break;
+	case ETHTOOL_GSTATS2:
+		rc = ethtool_get_stats2(dev, useraddr);
+		break;
 	case ETHTOOL_GPERMADDR:
 		rc = ethtool_get_perm_addr(dev, useraddr);
 		break;
-- 
2.4.11

^ permalink raw reply related

* [PATCH 2/3] mac80211:  Add support for ethtool gstats2 API.
From: greearb @ 2018-04-18  1:49 UTC (permalink / raw)
  To: netdev; +Cc: linux-wireless, ath10k, Ben Greear
In-Reply-To: <1524016176-3881-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb@candelatech.com>

This enables users to request fewer stats to be refreshed
in cases where firmware does not need to be probed.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
 include/net/mac80211.h    |  6 ++++++
 net/mac80211/driver-ops.h |  9 +++++++--
 net/mac80211/ethtool.c    | 18 +++++++++++++-----
 3 files changed, 26 insertions(+), 7 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d2279b2..4854f33 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3361,6 +3361,8 @@ enum ieee80211_reconfig_type {
  *
  * @get_et_stats:  Ethtool API to get a set of u64 stats.
  *
+ * @get_et_stats2:  Ethtool API to get a set of u64 stats, with flags.
+ *
  * @get_et_strings:  Ethtool API to get a set of strings to describe stats
  *	and perhaps other supported types of ethtool data-sets.
  *
@@ -3692,6 +3694,10 @@ struct ieee80211_ops {
 	void	(*get_et_stats)(struct ieee80211_hw *hw,
 				struct ieee80211_vif *vif,
 				struct ethtool_stats *stats, u64 *data);
+	void	(*get_et_stats2)(struct ieee80211_hw *hw,
+				 struct ieee80211_vif *vif,
+				 struct ethtool_stats *stats, u64 *data,
+				 u32 flags);
 	void	(*get_et_strings)(struct ieee80211_hw *hw,
 				  struct ieee80211_vif *vif,
 				  u32 sset, u8 *data);
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 4d82fe7..519d2db 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -58,10 +58,15 @@ static inline void drv_get_et_strings(struct ieee80211_sub_if_data *sdata,
 
 static inline void drv_get_et_stats(struct ieee80211_sub_if_data *sdata,
 				    struct ethtool_stats *stats,
-				    u64 *data)
+				    u64 *data, u32 flags)
 {
 	struct ieee80211_local *local = sdata->local;
-	if (local->ops->get_et_stats) {
+	if (local->ops->get_et_stats2) {
+		trace_drv_get_et_stats(local);
+		local->ops->get_et_stats2(&local->hw, &sdata->vif, stats, data,
+					  flags);
+		trace_drv_return_void(local);
+	} else if (local->ops->get_et_stats) {
 		trace_drv_get_et_stats(local);
 		local->ops->get_et_stats(&local->hw, &sdata->vif, stats, data);
 		trace_drv_return_void(local);
diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 9cc986d..b67520e 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -61,9 +61,9 @@ static int ieee80211_get_sset_count(struct net_device *dev, int sset)
 	return rv;
 }
 
-static void ieee80211_get_stats(struct net_device *dev,
-				struct ethtool_stats *stats,
-				u64 *data)
+static void ieee80211_get_stats2(struct net_device *dev,
+				 struct ethtool_stats *stats,
+				 u64 *data, u32 flags)
 {
 	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 	struct ieee80211_chanctx_conf *chanctx_conf;
@@ -199,7 +199,14 @@ static void ieee80211_get_stats(struct net_device *dev,
 	if (WARN_ON(i != STA_STATS_LEN))
 		return;
 
-	drv_get_et_stats(sdata, stats, &(data[STA_STATS_LEN]));
+	drv_get_et_stats(sdata, stats, &data[STA_STATS_LEN], flags);
+}
+
+static void ieee80211_get_stats(struct net_device *dev,
+				struct ethtool_stats *stats,
+				u64 *data)
+{
+	ieee80211_get_stats2(dev, stats, data, 0);
 }
 
 static void ieee80211_get_strings(struct net_device *dev, u32 sset, u8 *data)
@@ -211,7 +218,7 @@ static void ieee80211_get_strings(struct net_device *dev, u32 sset, u8 *data)
 		sz_sta_stats = sizeof(ieee80211_gstrings_sta_stats);
 		memcpy(data, ieee80211_gstrings_sta_stats, sz_sta_stats);
 	}
-	drv_get_et_strings(sdata, sset, &(data[sz_sta_stats]));
+	drv_get_et_strings(sdata, sset, &data[sz_sta_stats]);
 }
 
 static int ieee80211_get_regs_len(struct net_device *dev)
@@ -238,5 +245,6 @@ const struct ethtool_ops ieee80211_ethtool_ops = {
 	.set_ringparam = ieee80211_set_ringparam,
 	.get_strings = ieee80211_get_strings,
 	.get_ethtool_stats = ieee80211_get_stats,
+	.get_ethtool_stats2 = ieee80211_get_stats2,
 	.get_sset_count = ieee80211_get_sset_count,
 };
-- 
2.4.11

^ permalink raw reply related

* [PATCH 3/3] ath10k:  Support ethtool gstats2 API.
From: greearb @ 2018-04-18  1:49 UTC (permalink / raw)
  To: netdev; +Cc: linux-wireless, ath10k, Ben Greear
In-Reply-To: <1524016176-3881-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb@candelatech.com>

Skip a firmware stats update when calling
code indicates the stats refresh is not needed.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
 drivers/net/wireless/ath/ath10k/debug.c | 18 +++++++++++++++---
 drivers/net/wireless/ath/ath10k/debug.h |  4 ++++
 drivers/net/wireless/ath/ath10k/mac.c   |  1 +
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index bac832c..d559a3f 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1159,9 +1159,10 @@ int ath10k_debug_get_et_sset_count(struct ieee80211_hw *hw,
 	return 0;
 }
 
-void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
-			       struct ieee80211_vif *vif,
-			       struct ethtool_stats *stats, u64 *data)
+void ath10k_debug_get_et_stats2(struct ieee80211_hw *hw,
+				struct ieee80211_vif *vif,
+				struct ethtool_stats *stats, u64 *data,
+				u32 flags)
 {
 	struct ath10k *ar = hw->priv;
 	static const struct ath10k_fw_stats_pdev zero_stats = {};
@@ -1170,6 +1171,9 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
 
 	mutex_lock(&ar->conf_mutex);
 
+	if (flags & ETHTOOL_GS2_SKIP_FW)
+		goto skip_query_fw_stats;
+
 	if (ar->state == ATH10K_STATE_ON) {
 		ret = ath10k_debug_fw_stats_request(ar);
 		if (ret) {
@@ -1180,6 +1184,7 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
 		}
 	}
 
+skip_query_fw_stats:
 	pdev_stats = list_first_entry_or_null(&ar->debug.fw_stats.pdevs,
 					      struct ath10k_fw_stats_pdev,
 					      list);
@@ -1244,6 +1249,13 @@ void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
 	WARN_ON(i != ATH10K_SSTATS_LEN);
 }
 
+void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
+			       struct ieee80211_vif *vif,
+			       struct ethtool_stats *stats, u64 *data)
+{
+	ath10k_debug_get_et_stats2(hw, vif, stats, data, 0);
+}
+
 static const struct file_operations fops_fw_dbglog = {
 	.read = ath10k_read_fw_dbglog,
 	.write = ath10k_write_fw_dbglog,
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 0afca5c..595d964 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -117,6 +117,10 @@ int ath10k_debug_get_et_sset_count(struct ieee80211_hw *hw,
 void ath10k_debug_get_et_stats(struct ieee80211_hw *hw,
 			       struct ieee80211_vif *vif,
 			       struct ethtool_stats *stats, u64 *data);
+void ath10k_debug_get_et_stats2(struct ieee80211_hw *hw,
+				struct ieee80211_vif *vif,
+				struct ethtool_stats *stats, u64 *data,
+				u32 level);
 
 static inline u64 ath10k_debug_get_fw_dbglog_mask(struct ath10k *ar)
 {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index bf05a36..27b793c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7734,6 +7734,7 @@ static const struct ieee80211_ops ath10k_ops = {
 	.ampdu_action			= ath10k_ampdu_action,
 	.get_et_sset_count		= ath10k_debug_get_et_sset_count,
 	.get_et_stats			= ath10k_debug_get_et_stats,
+	.get_et_stats2			= ath10k_debug_get_et_stats2,
 	.get_et_strings			= ath10k_debug_get_et_strings,
 	.add_chanctx			= ath10k_mac_op_add_chanctx,
 	.remove_chanctx			= ath10k_mac_op_remove_chanctx,
-- 
2.4.11

^ permalink raw reply related

* [PATCH] ethtool:  Support ETHTOOL_GSTATS2 API.
From: greearb @ 2018-04-18  1:50 UTC (permalink / raw)
  To: netdev; +Cc: Ben Greear

From: Ben Greear <greearb@candelatech.com>

This allows users to specify flags to the get-stats
API, potentially saving expensive stats queries when
they are not desired.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
 ethtool-copy.h |  9 +++++++++
 ethtool.c      | 25 ++++++++++++++++++++-----
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/ethtool-copy.h b/ethtool-copy.h
index 8cc61e9..11ce456 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -1390,11 +1390,20 @@ enum ethtool_fec_config_bits {
 #define ETHTOOL_PHY_STUNABLE	0x0000004f /* Set PHY tunable configuration */
 #define ETHTOOL_GFECPARAM	0x00000050 /* Get FEC settings */
 #define ETHTOOL_SFECPARAM	0x00000051 /* Set FEC settings */
+#define ETHTOOL_GSTATS2		0x00000052 /* get NIC-specific statistics
+					    * with ability to specify flags.
+					    * See ETHTOOL_GS2* below.
+					    */
 
 /* compatibility with older code */
 #define SPARC_ETH_GSET		ETHTOOL_GSET
 #define SPARC_ETH_SSET		ETHTOOL_SSET
 
+/* GSTATS2 flags */
+#define ETHTOOL_GS2_SKIP_NONE (0)    /* default is to update all stats */
+#define ETHTOOL_GS2_SKIP_FW   (1<<0) /* Skip reading stats that probe firmware,
+				      * and thus are slow/expensive.
+				      */
 /* Link mode bit indices */
 enum ethtool_link_mode_bit_indices {
 	ETHTOOL_LINK_MODE_10baseT_Half_BIT	= 0,
diff --git a/ethtool.c b/ethtool.c
index 3289e0f..6a11077 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -3440,14 +3440,14 @@ static int do_phys_id(struct cmd_context *ctx)
 }
 
 static int do_gstats(struct cmd_context *ctx, int cmd, int stringset,
-		    const char *name)
+		     const char *name, u32 flags)
 {
 	struct ethtool_gstrings *strings;
 	struct ethtool_stats *stats;
 	unsigned int n_stats, sz_stats, i;
 	int err;
 
-	if (ctx->argc != 0)
+	if ((ctx->argc != 0) && (flags == ETHTOOL_GS2_SKIP_NONE))
 		exit_bad_args();
 
 	strings = get_stringset(ctx, stringset,
@@ -3475,7 +3475,10 @@ static int do_gstats(struct cmd_context *ctx, int cmd, int stringset,
 	}
 
 	stats->cmd = cmd;
-	stats->n_stats = n_stats;
+	if (cmd == ETHTOOL_GSTATS2)
+		stats->n_stats = flags;
+	else
+		stats->n_stats = n_stats;
 	err = send_ioctl(ctx, stats);
 	if (err < 0) {
 		perror("Cannot get stats information");
@@ -3500,12 +3503,22 @@ static int do_gstats(struct cmd_context *ctx, int cmd, int stringset,
 
 static int do_gnicstats(struct cmd_context *ctx)
 {
-	return do_gstats(ctx, ETHTOOL_GSTATS, ETH_SS_STATS, "NIC");
+	return do_gstats(ctx, ETHTOOL_GSTATS, ETH_SS_STATS, "NIC", ETHTOOL_GS2_SKIP_NONE);
+}
+
+static int do_gnicstats2(struct cmd_context *ctx)
+{
+	u32 flags = ETHTOOL_GS2_SKIP_NONE;
+	if (ctx->argc >= 1)
+		if (strcmp(ctx->argp[0], "nofw") == 0)
+			flags |= ETHTOOL_GS2_SKIP_FW;
+	return do_gstats(ctx, ETHTOOL_GSTATS2, ETH_SS_STATS, "NIC", flags);
 }
 
 static int do_gphystats(struct cmd_context *ctx)
 {
-	return do_gstats(ctx, ETHTOOL_GPHYSTATS, ETH_SS_PHY_STATS, "PHY");
+	return do_gstats(ctx, ETHTOOL_GPHYSTATS, ETH_SS_PHY_STATS, "PHY",
+			 ETHTOOL_GS2_SKIP_NONE);
 }
 
 static int do_srxntuple(struct cmd_context *ctx,
@@ -5118,6 +5131,8 @@ static const struct option {
 	{ "-t|--test", 1, do_test, "Execute adapter self test",
 	  "               [ online | offline | external_lb ]\n" },
 	{ "-S|--statistics", 1, do_gnicstats, "Show adapter statistics" },
+	{ "-2|--S2", 1, do_gnicstats2, "Show adapter statistics with flags",
+	  "               [ nofw ]\n" },
 	{ "--phy-statistics", 1, do_gphystats,
 	  "Show phy statistics" },
 	{ "-n|-u|--show-nfc|--show-ntuple", 1, do_grxclass,
-- 
2.4.11

^ permalink raw reply related

* Re: [PATCHv2 net-next] vxlan: add ttl inherit support
From: Hangbin Liu @ 2018-04-18  2:15 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, jbenc, lucien.xin, sbrivio
In-Reply-To: <20180417.151627.1849186462841531455.davem@davemloft.net>

On Tue, Apr 17, 2018 at 03:16:27PM -0400, David Miller wrote:
> From: Hangbin Liu <liuhangbin@gmail.com>
> Date: Tue, 17 Apr 2018 20:52:54 +0800
> 
> > Like tos inherit, ttl inherit should also means inherit the inner protocol's
> > ttl values, which actually not implemented in vxlan yet.
> > 
> > But we could not treat ttl == 0 as "use the inner TTL", because that would be
> > used also when the "ttl" option is not specified and that would be a behavior
> > change, and breaking real use cases.
> > 
> > So add a different attribute IFLA_VXLAN_TTL_INHERIT when "ttl inherit" is
> > specified.
> > 
> > ---
> > v2: As suggested by Stefano, clean up function ip_tunnel_get_ttl().
> > 
> > Suggested-by: Jiri Benc <jbenc@redhat.com>
> > Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
> 
> I already applied V1 of your patch.
> 
> Furthermore, this commit message would cause your signoffs and other tags
> to be removed due to the "---" deliminator.
> 
> I generally encourage people to leave the change history text _in_ the
> commit message anyways.  It is useful information for the future.

Thanks for the reminding. I will keep this in mind.

Cheers
Hangbin

^ permalink raw reply

* Re: [PATCH bpf-next 09/10] [bpf]: make tun compatible w/ bpf_xdp_adjust_tail
From: Jason Wang @ 2018-04-18  2:16 UTC (permalink / raw)
  To: Nikita V. Shirokov, Alexei Starovoitov, Daniel Borkmann, mst; +Cc: netdev
In-Reply-To: <20180417065131.3632-10-tehnerd@tehnerd.com>



On 2018年04月17日 14:51, Nikita V. Shirokov wrote:
> w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
> well (only "decrease" of pointer's location is going to be supported).
> changing of this pointer will change packet's size.
> for tun driver we need to adjust XDP_PASS handling by recalculating
> length of the packet if it was passed to the TCP/IP stack
> (in case if after xdp's prog run data_end pointer was adjusted)
>
> Signed-off-by: Nikita V. Shirokov <tehnerd@tehnerd.com>
> ---
>   drivers/net/tun.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 28583aa0c17d..0b488a958076 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1688,6 +1688,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>   			return NULL;
>   		case XDP_PASS:
>   			delta = orig_data - xdp.data;
> +			len = xdp.data_end - xdp.data;
>   			break;
>   		default:
>   			bpf_warn_invalid_xdp_action(act);
> @@ -1708,7 +1709,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
>   	}
>   
>   	skb_reserve(skb, pad - delta);
> -	skb_put(skb, len + delta);
> +	skb_put(skb, len);
>   	get_page(alloc_frag->page);
>   	alloc_frag->offset += buflen;
>   

Reviewed-by: Jason Wang <jasowang@redhat.com>

^ permalink raw reply

* Re: [PATCH bpf-next 10/10] [bpf]: make virtio compatible w/ bpf_xdp_adjust_tail
From: Jason Wang @ 2018-04-18  2:16 UTC (permalink / raw)
  To: Nikita V. Shirokov, Alexei Starovoitov, Daniel Borkmann; +Cc: netdev
In-Reply-To: <20180417065131.3632-11-tehnerd@tehnerd.com>



On 2018年04月17日 14:51, Nikita V. Shirokov wrote:
> w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as
> well (only "decrease" of pointer's location is going to be supported).
> changing of this pointer will change packet's size.
> for virtio driver we need to adjust XDP_PASS handling by recalculating
> length of the packet if it was passed to the TCP/IP stack
>
> Signed-off-by: Nikita V. Shirokov <tehnerd@tehnerd.com>
> ---
>   drivers/net/virtio_net.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 7b187ec7411e..115d85f7360a 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -604,6 +604,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
>   		case XDP_PASS:
>   			/* Recalculate length in case bpf program changed it */
>   			delta = orig_data - xdp.data;
> +			len = xdp.data_end - xdp.data;
>   			break;
>   		case XDP_TX:
>   			sent = __virtnet_xdp_xmit(vi, &xdp);
> @@ -637,7 +638,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
>   		goto err;
>   	}
>   	skb_reserve(skb, headroom - delta);
> -	skb_put(skb, len + delta);
> +	skb_put(skb, len);
>   	if (!delta) {
>   		buf += header_offset;
>   		memcpy(skb_vnet_hdr(skb), buf, vi->hdr_len);
> @@ -752,6 +753,10 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>   			offset = xdp.data -
>   					page_address(xdp_page) - vi->hdr_len;
>   
> +			/* recalculate len if xdp.data or xdp.data_end were
> +			 * adjusted
> +			 */
> +			len = xdp.data_end - xdp.data;
>   			/* We can only create skb based on xdp_page. */
>   			if (unlikely(xdp_page != page)) {
>   				rcu_read_unlock();

Reviewed-by: Jason Wang <jasowang@redhat.com>

^ permalink raw reply

* Re: [PATCH RFC net-next 00/11] udp gso
From: Samudrala, Sridhar @ 2018-04-18  2:25 UTC (permalink / raw)
  To: Willem de Bruijn, Sowmini Varadhan; +Cc: Network Development, Willem de Bruijn
In-Reply-To: <CAF=yD-+psRcT+666fCgh8f2r8Raq_D4yCsEycKrNpW-tan1-Yw@mail.gmail.com>


On 4/17/2018 2:07 PM, Willem de Bruijn wrote:
> On Tue, Apr 17, 2018 at 4:48 PM, Sowmini Varadhan
> <sowmini.varadhan@oracle.com> wrote:
>> On (04/17/18 16:23), Willem de Bruijn wrote:
>>> Assuming IPv4 with an MTU of 1500 and the maximum segment
>>> size of 1472, the receiver will see three datagrams with MSS of
>>> 1472B, 528B and 512B.
>> so the recvmsg will also pass up 1472, 526, 512, right?
> That's right.
>
>> If yes, how will the recvmsg differentiate between the case
>> (2000 byte message followed by 512 byte message) and
>> (1472 byte message, 526 byte message, then 512 byte message),
>> in other words, how are UDP message boundary semantics preserved?
> They aren't. This is purely an optimization to amortize the cost of
> repeated tx stack traversal. Unlike UFO, which would preserve the
> boundaries of the original larger than MTU datagram.

Doesn't this break UDP applications that expect message boundary
preservation semantics? Is it possible to negotiate this feature?

>
> A prime use case is bulk transfer of data. Think video streaming
> with QUIC. It must send MTU sized or smaller packets, but has
> no application-layer requirement to reconstruct large packets on
> the peer.
>
> That said, for negotiated flows an inverse GRO feature could
> conceivably be implemented to reduce rx stack traversal, too.
> Though due to interleaving of packets on the wire, it aggregation
> would be best effort, similar to TCP TSO and GRO using the
> PSH bit as packetization signal.

^ permalink raw reply

* Re: [PATCH] PCI: Add PCIe to pcie_print_link_status() messages
From: Jakub Kicinski @ 2018-04-18  2:33 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: oss-drivers, Tal Gilboa, Tariq Toukan, Jacob Keller,
	Ganesh Goudar, Jeff Kirsher, intel-wired-lan, netdev,
	linux-kernel, linux-pci
In-Reply-To: <20180413181638.6424-1-jakub.kicinski@netronome.com>

On Fri, 13 Apr 2018 11:16:38 -0700, Jakub Kicinski wrote:
> Currently the pcie_print_link_status() will print PCIe bandwidth
> and link width information but does not mention it is pertaining
> to the PCIe.  Since this and related functions are used exclusively
> by networking drivers today users may get confused into thinking
> that it's the NIC bandwidth that is being talked about.  Insert a
> "PCIe" into the messages.
> 
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>

Hi Bjorn!

Could this small change still make it into 4.17 or are you planning to
apply it in 4.18 cycle?  IMHO the message clarification may be worth
considering for 4.17..

>  drivers/pci/pci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index aa86e904f93c..73a0a4993f6a 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5273,11 +5273,11 @@ void pcie_print_link_status(struct pci_dev *dev)
>  	bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed, &width);
>  
>  	if (bw_avail >= bw_cap)
> -		pci_info(dev, "%u.%03u Gb/s available bandwidth (%s x%d link)\n",
> +		pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s x%d link)\n",
>  			 bw_cap / 1000, bw_cap % 1000,
>  			 PCIE_SPEED2STR(speed_cap), width_cap);
>  	else
> -		pci_info(dev, "%u.%03u Gb/s available bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
> +		pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth, limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d link)\n",
>  			 bw_avail / 1000, bw_avail % 1000,
>  			 PCIE_SPEED2STR(speed), width,
>  			 limiting_dev ? pci_name(limiting_dev) : "<unknown>",

^ permalink raw reply

* Re: [PATCH net-next 3/5] ipv4: support sport, dport and ip protocol in RTM_GETROUTE
From: Roopa Prabhu @ 2018-04-18  2:41 UTC (permalink / raw)
  To: Ido Schimmel; +Cc: David Miller, netdev, David Ahern
In-Reply-To: <20180417081052.GA30335@splinter>

On Tue, Apr 17, 2018 at 1:10 AM, Ido Schimmel <idosch@idosch.org> wrote:
> On Mon, Apr 16, 2018 at 01:41:36PM -0700, Roopa Prabhu wrote:
>> @@ -2757,6 +2796,12 @@ static int inet_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
>>       fl4.flowi4_oif = tb[RTA_OIF] ? nla_get_u32(tb[RTA_OIF]) : 0;
>>       fl4.flowi4_mark = mark;
>>       fl4.flowi4_uid = uid;
>> +     if (sport)
>> +             fl4.fl4_sport = sport;
>> +     if (dport)
>> +             fl4.fl4_dport = dport;
>> +     if (ip_proto)
>> +             fl4.flowi4_proto = ip_proto;
>
> Hi Roopa,
>
> This info isn't set in the synthesized skb, but only in the flow info
> and therefore not used for input routes. I see you added a test case,
> but it's only for output routes. I believe an input route test case will
> fail.

yep. I made a note for myself to work thru the input case and missed before
i sent the series.

>
> Also, note that the skb as synthesized now is invalid - iph->ihl is 0
> for example - so the flow dissector will spit it out. It effectively
> means that route get is broken when L4 hashing is used. It also affects
> output routes because since commit 3765d35ed8b9 ("net: ipv4: Convert
> inet_rtm_getroute to rcu versions of route lookup") the skb is used to
> calculate the multipath hash.

yep, remember that. will look. thanks Ido.

^ permalink raw reply

* [PATCH bpf-next] tools: bpftool: make it easier to feed hex bytes to bpftool
From: Jakub Kicinski @ 2018-04-18  2:46 UTC (permalink / raw)
  To: alexei.starovoitov, daniel; +Cc: oss-drivers, netdev, Quentin Monnet

From: Quentin Monnet <quentin.monnet@netronome.com>

bpftool uses hexadecimal values when it dumps map contents:

    # bpftool map dump id 1337
    key: ff 13 37 ff  value: a1 b2 c3 d4 ff ff ff ff
    Found 1 element

In order to lookup or update values with bpftool, the natural reflex is
then to copy and paste the values to the command line, and to try to run
something like:

    # bpftool map update id 1337 key ff 13 37 ff \
            value 00 00 00 00 00 00 1a 2b
    Error: error parsing byte: ff

bpftool complains, because it uses strtoul() with a 0 base to parse the
bytes, and that without a "0x" prefix, the bytes are considered as
decimal values (or even octal if they start with "0").

To feed hexadecimal values instead, one needs to add "0x" prefixes
everywhere necessary:

    # bpftool map update id 1337 key 0xff 0x13 0x37 0xff \
            value 0 0 0 0 0 0 0x1a 0x2b

To make it easier to use hexadecimal values, add an optional "hex"
keyword to put after "key" or "value" to tell bpftool to consider the
digits as hexadecimal. We can now do:

    # bpftool map update id 1337 key hex ff 13 37 ff \
            value hex 0 0 0 0 0 0 1a 2b

Without the "hex" keyword, the bytes are still parsed according to
normal integer notation (decimal if no prefix, or hexadecimal or octal
if "0x" or "0" prefix is used, respectively).

The patch also add related documentation and bash completion for the
"hex" keyword.

Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Suggested-by: David Beckett <david.beckett@netronome.com>
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
 tools/bpf/bpftool/Documentation/bpftool-map.rst | 29 +++++++++++++++++--------
 tools/bpf/bpftool/bash-completion/bpftool       |  8 ++++---
 tools/bpf/bpftool/map.c                         | 17 ++++++++++-----
 3 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/tools/bpf/bpftool/Documentation/bpftool-map.rst b/tools/bpf/bpftool/Documentation/bpftool-map.rst
index 457e868bd32f..5f512b14bff9 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-map.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-map.rst
@@ -23,10 +23,10 @@ MAP COMMANDS
 
 |	**bpftool** **map { show | list }**   [*MAP*]
 |	**bpftool** **map dump**    *MAP*
-|	**bpftool** **map update**  *MAP*  **key** *BYTES*   **value** *VALUE* [*UPDATE_FLAGS*]
-|	**bpftool** **map lookup**  *MAP*  **key** *BYTES*
-|	**bpftool** **map getnext** *MAP* [**key** *BYTES*]
-|	**bpftool** **map delete**  *MAP*  **key** *BYTES*
+|	**bpftool** **map update**  *MAP*  **key** [**hex**] *BYTES*   **value** [**hex**] *VALUE* [*UPDATE_FLAGS*]
+|	**bpftool** **map lookup**  *MAP*  **key** [**hex**] *BYTES*
+|	**bpftool** **map getnext** *MAP* [**key** [**hex**] *BYTES*]
+|	**bpftool** **map delete**  *MAP*  **key** [**hex**] *BYTES*
 |	**bpftool** **map pin**     *MAP*  *FILE*
 |	**bpftool** **map help**
 |
@@ -48,20 +48,26 @@ DESCRIPTION
 	**bpftool map dump**    *MAP*
 		  Dump all entries in a given *MAP*.
 
-	**bpftool map update**  *MAP*  **key** *BYTES*   **value** *VALUE* [*UPDATE_FLAGS*]
+	**bpftool map update**  *MAP*  **key** [**hex**] *BYTES*   **value** [**hex**] *VALUE* [*UPDATE_FLAGS*]
 		  Update map entry for a given *KEY*.
 
 		  *UPDATE_FLAGS* can be one of: **any** update existing entry
 		  or add if doesn't exit; **exist** update only if entry already
 		  exists; **noexist** update only if entry doesn't exist.
 
-	**bpftool map lookup**  *MAP*  **key** *BYTES*
+		  If the **hex** keyword is provided in front of the bytes
+		  sequence, the bytes are parsed as hexadeximal values, even if
+		  no "0x" prefix is added. If the keyword is not provided, then
+		  the bytes are parsed as decimal values, unless a "0x" prefix
+		  (for hexadecimal) or a "0" prefix (for octal) is provided.
+
+	**bpftool map lookup**  *MAP*  **key** [**hex**] *BYTES*
 		  Lookup **key** in the map.
 
-	**bpftool map getnext** *MAP* [**key** *BYTES*]
+	**bpftool map getnext** *MAP* [**key** [**hex**] *BYTES*]
 		  Get next key.  If *key* is not specified, get first key.
 
-	**bpftool map delete**  *MAP*  **key** *BYTES*
+	**bpftool map delete**  *MAP*  **key** [**hex**] *BYTES*
 		  Remove entry from the map.
 
 	**bpftool map pin**     *MAP*  *FILE*
@@ -98,7 +104,12 @@ EXAMPLES
   10: hash  name some_map  flags 0x0
 	key 4B  value 8B  max_entries 2048  memlock 167936B
 
-**# bpftool map update id 10 key 13 00 07 00 value 02 00 00 00 01 02 03 04**
+The following three commands are equivalent:
+
+|
+| **# bpftool map update id 10 key hex   20   c4   b7   00 value hex   0f   ff   ff   ab   01   02   03   4c**
+| **# bpftool map update id 10 key     0x20 0xc4 0xb7 0x00 value     0x0f 0xff 0xff 0xab 0x01 0x02 0x03 0x4c**
+| **# bpftool map update id 10 key       32  196  183    0 value       15  255  255  171    1    2    3   76**
 
 **# bpftool map lookup id 10 key 0 1 2 3**
 
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index 490811b45fa7..71cc5dec3685 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -147,7 +147,7 @@ _bpftool()
 
     # Deal with simplest keywords
     case $prev in
-        help|key|opcodes|visual)
+        help|hex|opcodes|visual)
             return 0
             ;;
         tag)
@@ -283,7 +283,7 @@ _bpftool()
                             return 0
                             ;;
                         key)
-                            return 0
+                            COMPREPLY+=( $( compgen -W 'hex' -- "$cur" ) )
                             ;;
                         *)
                             _bpftool_once_attr 'key'
@@ -302,7 +302,7 @@ _bpftool()
                             return 0
                             ;;
                         key)
-                            return 0
+                            COMPREPLY+=( $( compgen -W 'hex' -- "$cur" ) )
                             ;;
                         value)
                             # We can have bytes, or references to a prog or a
@@ -321,6 +321,8 @@ _bpftool()
                                     return 0
                                     ;;
                                 *)
+                                    COMPREPLY+=( $( compgen -W 'hex' \
+                                        -- "$cur" ) )
                                     return 0
                                     ;;
                             esac
diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
index f509c86faede..a6cdb640a0d7 100644
--- a/tools/bpf/bpftool/map.c
+++ b/tools/bpf/bpftool/map.c
@@ -283,11 +283,16 @@ static void print_entry_plain(struct bpf_map_info *info, unsigned char *key,
 static char **parse_bytes(char **argv, const char *name, unsigned char *val,
 			  unsigned int n)
 {
-	unsigned int i = 0;
+	unsigned int i = 0, base = 0;
 	char *endptr;
 
+	if (is_prefix(*argv, "hex")) {
+		base = 16;
+		argv++;
+	}
+
 	while (i < n && argv[i]) {
-		val[i] = strtoul(argv[i], &endptr, 0);
+		val[i] = strtoul(argv[i], &endptr, base);
 		if (*endptr) {
 			p_err("error parsing byte: %s", argv[i]);
 			return NULL;
@@ -869,10 +874,10 @@ static int do_help(int argc, char **argv)
 	fprintf(stderr,
 		"Usage: %s %s { show | list }   [MAP]\n"
 		"       %s %s dump    MAP\n"
-		"       %s %s update  MAP  key BYTES value VALUE [UPDATE_FLAGS]\n"
-		"       %s %s lookup  MAP  key BYTES\n"
-		"       %s %s getnext MAP [key BYTES]\n"
-		"       %s %s delete  MAP  key BYTES\n"
+		"       %s %s update  MAP  key [hex] BYTES value [hex] VALUE [UPDATE_FLAGS]\n"
+		"       %s %s lookup  MAP  key [hex] BYTES\n"
+		"       %s %s getnext MAP [key [hex] BYTES]\n"
+		"       %s %s delete  MAP  key [hex] BYTES\n"
 		"       %s %s pin     MAP  FILE\n"
 		"       %s %s help\n"
 		"\n"
-- 
2.16.2

^ permalink raw reply related

* Fw: [Bug 199429] New: smc_shutdown(net/smc/af_smc.c) has a UAF causing null pointer vulnerability.
From: Stephen Hemminger @ 2018-04-18  2:56 UTC (permalink / raw)
  To: Ursula Braun; +Cc: netdev

This may already be fixed.

Begin forwarded message:

Date: Wed, 18 Apr 2018 01:52:59 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 199429] New: smc_shutdown(net/smc/af_smc.c) has a UAF causing null pointer vulnerability.


https://bugzilla.kernel.org/show_bug.cgi?id=199429

            Bug ID: 199429
           Summary: smc_shutdown(net/smc/af_smc.c) has a UAF causing null
                    pointer vulnerability.
           Product: Networking
           Version: 2.5
    Kernel Version: 4.16.0-rc7
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
          Assignee: stephen@networkplumber.org
          Reporter: 1773876454@qq.com
        Regression: No

Created attachment 275431
  --> https://bugzilla.kernel.org/attachment.cgi?id=275431&action=edit  
POC

Syzkaller hit 'general protection fault in kernel_sock_shutdown' bug.

NET: Registered protocol family 43
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in: smc ib_core binfmt_misc joydev hid_generic snd_pcm snd_timer
snd usbmouse usbhid soundcore psmouse e1000 hid pcspkr parport_pc input_leds
i2c_piix4 parport serio_raw floppy qemu_fw_cfg evbug mac_hid
CPU: 1 PID: 1751 Comm: syzkaller252340 Not tainted 4.16.0-rc7+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1
04/01/2014
RIP: 0010:kernel_sock_shutdown+0x29/0x70 net/socket.c:3255
RSP: 0018:ffff88000666fcf8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff829206e4
RDX: 0000000000000005 RSI: 0000000000000000 RDI: 0000000000000028
RBP: ffff88003b43a0d2 R08: 0000000000000003 R09: 000000000002b3c0
R10: 0000000000000ae7 R11: 00000000000000eb R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  000000000225b880(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5b85800000 CR3: 000000003bcde004 CR4: 00000000001606e0
Call Trace:
 smc_shutdown+0x431/0x4a0 [smc]
 SYSC_shutdown net/socket.c:1901 [inline]
 SyS_shutdown+0x140/0x250 net/socket.c:1892
 do_syscall_64+0x2ee/0x580 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x4431a9
RSP: 002b:00007ffcccb77758 EFLAGS: 00000217 ORIG_RAX: 0000000000000030
RAX: ffffffffffffffda RBX: 00000000004003d0 RCX: 00000000004431a9
RDX: 00000000004431a9 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000401800 R08: 00000000004003d0 R09: 00000000004003d0
R10: 00000000004003d0 R11: 0000000000000217 R12: 0000000000401890
R13: 0000000000000000 R14: 00000000006b1018 R15: 0000000000000000
Code: 00 00 0f 1f 44 00 00 41 54 55 41 89 f4 53 48 89 fb e8 4c bd ad fe 48 8d
7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 74 05 e8
7c 62 e0 fe 48 8b 6b 28 48 b8 00 00 00 00 
RIP: kernel_sock_shutdown+0x29/0x70 net/socket.c:3255 RSP: ffff88000666fcf8
---[ end trace ac1ba3c5e5bfa977 ]---

0xffffffffa02d1a82      1258                            rc =
smc_close_active(smc);
Dump of assembler code from 0xffffffffa02d1a82 to 0xffffffffa02d1a8c:
=> 0xffffffffa02d1a82 <smc_shutdown+1010>:      call   0xffffffffa02f3c50  
<smc_close_active>
   0xffffffffa02d1a87 <smc_shutdown+1015>:      mov    r13d,eax
   0xffffffffa02d1a8a <smc_shutdown+1018>:      call   0xffffffff813fc430
End of assembler dump.
rax            0xffff88005a6217c0       -131939878955072
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a7f       -1607656833
rdx            0x0      0
rsi            0xfffffe01       4294966785
rdi            0xffff88005be55b40       -131939853575360
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0xffff88005f9d0258       -131939791207848
r9             0xffff880060e2bc00       -131939769861120
r10            0xffff88005f9e7340       -131939791113408
r11            0xb9ed   47597
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1a82       0xffffffffa02d1a82 <smc_shutdown+1010>
eflags         0x293    [ CF AF SF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) b *0xffffffffa02d1a87
Breakpoint 36 at 0xffffffffa02d1a87: file ../net/smc/af_smc.c, line 1258.
(gdb) c
Continuing.
[Switching to Thread 4]

Thread 4 hit Hardware watchpoint 34: ((struct smc_sock*)
0xffff88005be55b40)->clcsock

Old value = (struct socket *) 0xffff880058fa5100
New value = (struct socket *) 0x0
smc_tcp_listen_work (work=0xffff88005be55f90) at ../net/smc/af_smc.c:980
980             release_sock(lsk);
(gdb) bt
#0  smc_tcp_listen_work (work=0xffff88005be55f90) at ../net/smc/af_smc.c:980
#1  0xffffffff811dd957 in ?? ()
#2  0xffff880060faf300 in ?? ()
#3  0x000000000be15ecf in ?? ()
#4  0xffff88005f7f5990 in ?? ()
#5  0x1ffff1000be15ed7 in ?? ()
#6  0xffff88005f7f5998 in ?? ()
#7  0xffff88005f7f59a8 in ?? ()
#8  0xffffffff00000000 in ?? ()
#9  0xffff88005f7f59d0 in ?? ()
#10 0xffffffff83000194 in ?? ()
#11 0xffffffff830001a0 in ?? ()
#12 0xffffffff83000194 in ?? ()
#13 0x0000000041b58ab3 in ?? ()
#14 0xffffffff83a0dee0 in ?? ()
#15 0xffffffff811dce50 in ?? ()
#16 0xffffffff83000194 in ?? ()
#17 0xffffffff00000000 in ?? ()
#18 0xffffffff83000194 in ?? ()
#19 0xffffffff830001a0 in ?? ()
#20 0xffffffff83000194 in ?? ()
#21 0xffffffff830001a0 in ?? ()
#22 0xffffffff83000194 in ?? ()
#23 0xffffffff830001a0 in ?? ()
#24 0xcc8f7df19c7e2900 in ?? ()
#25 0xffff880060faf305 in ?? ()
#26 0xffff88005fb88040 in ?? ()
#27 0xffff880057c60040 in ?? ()
#28 0x0000000000000000 in ?? ()
(gdb) file vmlinux
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Load new symbol table from "vmlinux"? (y or n) y
Reading symbols from vmlinux...done.
warning: File "/home/sdk/linux/scripts/gdb/vmlinux-gdb.py" auto-loading has
been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
(gdb) bt
#0  smc_tcp_listen_work (work=0xffff88005be55f90) at ../net/smc/af_smc.c:980
#1  0xffffffff811dd957 in process_one_work (worker=0xffff88005f7f5988,
work=0xffff88005be55f90) at ../kernel/workqueue.c:2113
#2  0xffffffff811def0d in worker_thread (__worker=0xffff88005f7f5988) at
../kernel/workqueue.c:2247
#3  0xffffffff811f4f5f in kthread (_create=<optimized out>) at
../kernel/kthread.c:238
#4  0xffffffff83000205 in ret_from_fork () at ../arch/x86/entry/entry_64.S:406
#5  0x0000000000000000 in ?? ()
(gdb) bt
#0  smc_tcp_listen_work (work=0xffff88005be55f90) at ../net/smc/af_smc.c:980
#1  0xffffffff811dd957 in process_one_work (worker=0xffff88005f7f5988,
work=0xffff88005be55f90) at ../kernel/workqueue.c:2113
#2  0xffffffff811def0d in worker_thread (__worker=0xffff88005f7f5988) at
../kernel/workqueue.c:2247
#3  0xffffffff811f4f5f in kthread (_create=<optimized out>) at
../kernel/kthread.c:238
#4  0xffffffff83000205 in ret_from_fork () at ../arch/x86/entry/entry_64.S:406
#5  0x0000000000000000 in ?? ()
(gdb) disas $rip,+0x10
Dump of assembler code from 0xffffffffa02d4304 to 0xffffffffa02d4314:
=> 0xffffffffa02d4304 <smc_tcp_listen_work+2724>:       call    
0xffffffff813fc430 <__sanitizer_cov_trace_pc>
   0xffffffffa02d4309 <smc_tcp_listen_work+2729>:       mov    rdi,r12
   0xffffffffa02d430c <smc_tcp_listen_work+2732>:       call  
0xffffffff82937820 <release_sock>
   0xffffffffa02d4311 <smc_tcp_listen_work+2737>:       lock dec DWORD PTR
[rbp-0x3d0]
End of assembler dump.
(gdb) c
Continuing.
[Switching to Thread 3]

Thread 3 hit Breakpoint 36, 0xffffffffa02d1a87 in smc_shutdown (sock=<optimized
out>, how=0) at ../net/smc/af_smc.c:1258  
1258                            rc = smc_close_active(smc);
(gdb) disas $rip,+0x10
Dump of assembler code from 0xffffffffa02d1a87 to 0xffffffffa02d1a97:
=> 0xffffffffa02d1a87 <smc_shutdown+1015>:      mov    r13d,eax  
   0xffffffffa02d1a8a <smc_shutdown+1018>:      call   0xffffffff813fc430
<__sanitizer_cov_trace_pc>
   0xffffffffa02d1a8f <smc_shutdown+1023>:      lea    rdi,[rbx+0x2c8]
   0xffffffffa02d1a96 <smc_shutdown+1030>:      movabs rax,0xdffffc0000000000
End of assembler dump.
(gdb) so ni
1264            rc1 = kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1a8a to 0xffffffffa02d1a94:
=> 0xffffffffa02d1a8a <smc_shutdown+1018>:      call   0xffffffff813fc430  
<__sanitizer_cov_trace_pc>
   0xffffffffa02d1a8f <smc_shutdown+1023>:      lea    rdi,[rbx+0x2c8]
End of assembler dump.
rax            0x0      0
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02f482b       -1607514069
rdx            0x0      0
rsi            0x0      0
rdi            0xffff88005be55c50       -131939853575088
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1a8a       0xffffffffa02d1a8a <smc_shutdown+1018>
eflags         0x282    [ SF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1a8f      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1a8f to 0xffffffffa02d1a99:
=> 0xffffffffa02d1a8f <smc_shutdown+1023>:      lea    rdi,[rbx+0x2c8]  
   0xffffffffa02d1a96 <smc_shutdown+1030>:      movabs rax,0xdffffc0000000000
End of assembler dump.
rax            0xffff88005a6217c0       -131939878955072
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x0      0
rsi            0x0      0
rdi            0xffff88005be55c50       -131939853575088
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1a8f       0xffffffffa02d1a8f <smc_shutdown+1023>
eflags         0x293    [ CF AF SF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1a96      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1a96 to 0xffffffffa02d1aa0:
=> 0xffffffffa02d1a96 <smc_shutdown+1030>:      movabs rax,0xdffffc0000000000  
End of assembler dump.
rax            0xffff88005a6217c0       -131939878955072
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x0      0
rsi            0x0      0
rdi            0xffff88005be55e08       -131939853574648
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1a96       0xffffffffa02d1a96 <smc_shutdown+1030>
eflags         0x293    [ CF AF SF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1aa0      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1aa0 to 0xffffffffa02d1aaa:
=> 0xffffffffa02d1aa0 <smc_shutdown+1040>:      mov    rdx,rdi  
   0xffffffffa02d1aa3 <smc_shutdown+1043>:      shr    rdx,0x3
   0xffffffffa02d1aa7 <smc_shutdown+1047>:      cmp    BYTE PTR [rdx+rax*1],0x0
End of assembler dump.
rax            0xdffffc0000000000       -2305847407260205056
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x0      0
rsi            0x0      0
rdi            0xffff88005be55e08       -131939853574648
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1aa0       0xffffffffa02d1aa0 <smc_shutdown+1040>
eflags         0x293    [ CF AF SF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1aa3      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1aa3 to 0xffffffffa02d1aad:
=> 0xffffffffa02d1aa3 <smc_shutdown+1043>:      shr    rdx,0x3  
   0xffffffffa02d1aa7 <smc_shutdown+1047>:      cmp    BYTE PTR [rdx+rax*1],0x0
   0xffffffffa02d1aab <smc_shutdown+1051>:      je     0xffffffffa02d1ab2
<smc_shutdown+1058>
End of assembler dump.
rax            0xdffffc0000000000       -2305847407260205056
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0xffff88005be55e08       -131939853574648
rsi            0x0      0
rdi            0xffff88005be55e08       -131939853574648
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1aa3       0xffffffffa02d1aa3 <smc_shutdown+1043>
eflags         0x293    [ CF AF SF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1aa7      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1aa7 to 0xffffffffa02d1ab1:
=> 0xffffffffa02d1aa7 <smc_shutdown+1047>:      cmp    BYTE PTR [rdx+rax*1],0x0  
   0xffffffffa02d1aab <smc_shutdown+1051>:      je     0xffffffffa02d1ab2
<smc_shutdown+1058>
   0xffffffffa02d1aad <smc_shutdown+1053>:      call   0xffffffff81726980
<__asan_report_load8_noabort>
End of assembler dump.
rax            0xdffffc0000000000       -2305847407260205056
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x1ffff1000b7cabc1       2305826516731997121
rsi            0x0      0
rdi            0xffff88005be55e08       -131939853574648
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1aa7       0xffffffffa02d1aa7 <smc_shutdown+1047>
eflags         0x202    [ IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1aab      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1aab to 0xffffffffa02d1ab5:
=> 0xffffffffa02d1aab <smc_shutdown+1051>:      je     0xffffffffa02d1ab2  
<smc_shutdown+1058>
   0xffffffffa02d1aad <smc_shutdown+1053>:      call   0xffffffff81726980
<__asan_report_load8_noabort>
   0xffffffffa02d1ab2 <smc_shutdown+1058>:      mov    rdi,QWORD PTR
[rbx+0x2c8]
End of assembler dump.
rax            0xdffffc0000000000       -2305847407260205056
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x1ffff1000b7cabc1       2305826516731997121
rsi            0x0      0
rdi            0xffff88005be55e08       -131939853574648
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1aab       0xffffffffa02d1aab <smc_shutdown+1051>
eflags         0x246    [ PF ZF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 

Thread 3 hit Breakpoint 32, 0xffffffffa02d1ab2 in smc_shutdown (sock=<optimized
out>, how=0) at ../net/smc/af_smc.c:1264  
1264            rc1 = kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1ab2 to 0xffffffffa02d1abc:
=> 0xffffffffa02d1ab2 <smc_shutdown+1058>:      mov    rdi,QWORD PTR  
[rbx+0x2c8]
   0xffffffffa02d1ab9 <smc_shutdown+1065>:      mov    esi,r12d
End of assembler dump.
rax            0xdffffc0000000000       -2305847407260205056
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x1ffff1000b7cabc1       2305826516731997121
rsi            0x0      0
rdi            0xffff88005be55e08       -131939853574648
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1ab2       0xffffffffa02d1ab2 <smc_shutdown+1058>
eflags         0x246    [ PF ZF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb) 
0xffffffffa02d1ab9      1264            rc1 =
kernel_sock_shutdown(smc->clcsock, how);
Dump of assembler code from 0xffffffffa02d1ab9 to 0xffffffffa02d1ac3:
=> 0xffffffffa02d1ab9 <smc_shutdown+1065>:      mov    esi,r12d  
   0xffffffffa02d1abc <smc_shutdown+1068>:      call   0xffffffff829206d0
<kernel_sock_shutdown>
   0xffffffffa02d1ac1 <smc_shutdown+1073>:      lea    rdi,[rbx+0x24a]
End of assembler dump.
rax            0xdffffc0000000000       -2305847407260205056
rbx            0xffff88005be55b40       -131939853575360
rcx            0xffffffffa02d1a8f       -1607656817
rdx            0x1ffff1000b7cabc1       2305826516731997121
rsi            0x0      0
rdi            0x0      0
rbp            0xffff88005be55b52       0xffff88005be55b52
rsp            0xffff88005e887d18       0xffff88005e887d18
r8             0x88     136
r9             0xffff880060f2bc00       -131939768812544
r10            0xffff88005e17f2f8       -131939816705288
r11            0xb839   47161
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0xffffffffa02d1ab9       0xffffffffa02d1ab9 <smc_shutdown+1065>
eflags         0x246    [ PF ZF IF ]
cs             0x10     16
ss             0x18     24
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ni:3: Error in sourced command file:
Could not fetch register "fs_base"; remote failure reply 'E14'
(gdb)

-- 
You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply

* Re: [PATCH RFC net-next 06/11] udp: add gso support to virtual devices
From: Willem de Bruijn @ 2018-04-18  3:27 UTC (permalink / raw)
  To: Dimitris Michailidis; +Cc: netdev, Willem de Bruijn
In-Reply-To: <CAG76SjaKJZj8gPnc=u02fBjEs-E-bRX8AQuGFpG+2+YYqep_hQ@mail.gmail.com>

On Tue, Apr 17, 2018 at 8:43 PM, Dimitris Michailidis
<dmichail@google.com> wrote:
> On Tue, Apr 17, 2018 at 1:00 PM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> From: Willem de Bruijn <willemb@google.com>
>>
>> Virtual devices such as tunnels and bonding can handle large packets.
>> Only segment packets when reaching a physical or loopback device.
>>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>> ---
>>  include/linux/netdev_features.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> index 35b79f47a13d..1e4883bb02a7 100644
>> --- a/include/linux/netdev_features.h
>> +++ b/include/linux/netdev_features.h
>> @@ -80,6 +80,7 @@ enum {
>>
>>         NETIF_F_GRO_HW_BIT,             /* Hardware Generic receive offload */
>>         NETIF_F_HW_TLS_RECORD_BIT,      /* Offload TLS record */
>> +       NETIF_F_GSO_UDP_L4_BIT,         /* UDP payload GSO (not UFO) */
>
> Please add an entry for the new flag to
> net/core/ethtool.c:netdev_features_strings
> and a description to Documentation/networking/netdev-features.txt.

Will do. I initially wrote this as a transparent kernel-internal feature,
but indeed it should be observable and configurable.

^ permalink raw reply

* Re: [PATCH RFC net-next 00/11] udp gso
From: Willem de Bruijn @ 2018-04-18  3:33 UTC (permalink / raw)
  To: Samudrala, Sridhar
  Cc: Sowmini Varadhan, Network Development, Willem de Bruijn
In-Reply-To: <74f0b490-de65-f05a-6332-6deaeb0fac2a@intel.com>

On Tue, Apr 17, 2018 at 10:25 PM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
>
> On 4/17/2018 2:07 PM, Willem de Bruijn wrote:
>>
>> On Tue, Apr 17, 2018 at 4:48 PM, Sowmini Varadhan
>> <sowmini.varadhan@oracle.com> wrote:
>>>
>>> On (04/17/18 16:23), Willem de Bruijn wrote:
>>>>
>>>> Assuming IPv4 with an MTU of 1500 and the maximum segment
>>>> size of 1472, the receiver will see three datagrams with MSS of
>>>> 1472B, 528B and 512B.
>>>
>>> so the recvmsg will also pass up 1472, 526, 512, right?
>>
>> That's right.
>>
>>> If yes, how will the recvmsg differentiate between the case
>>> (2000 byte message followed by 512 byte message) and
>>> (1472 byte message, 526 byte message, then 512 byte message),
>>> in other words, how are UDP message boundary semantics preserved?
>>
>> They aren't. This is purely an optimization to amortize the cost of
>> repeated tx stack traversal. Unlike UFO, which would preserve the
>> boundaries of the original larger than MTU datagram.
>
>
> Doesn't this break UDP applications that expect message boundary
> preservation semantics? Is it possible to negotiate this feature?

A process has to explicitly request the feature with socket option
or cmsg UDP_SEGMENT. By setting that to gso size is signals
its intent to send multiple datagrams in one call.

Or were you responding to the hypothetical GRO example below?
Yes, that clearly would have to be limited to negotiated flows, not
unlike how foo-over-udp tunneling is detected. It is also not a serious
suggestion at this point.

>> A prime use case is bulk transfer of data. Think video streaming
>> with QUIC. It must send MTU sized or smaller packets, but has
>> no application-layer requirement to reconstruct large packets on
>> the peer.
>>
>> That said, for negotiated flows an inverse GRO feature could
>> conceivably be implemented to reduce rx stack traversal, too.
>> Though due to interleaving of packets on the wire, it aggregation
>> would be best effort, similar to TCP TSO and GRO using the
>> PSH bit as packetization signal.

^ permalink raw reply

* Re: [PATCH v2] net: change the comment of dev_mc_init
From: David Miller @ 2018-04-18  3:39 UTC (permalink / raw)
  To: sunlw.fnst; +Cc: netdev
In-Reply-To: <111096cf-2afc-4d81-78e6-0a3ca53403f4@cn.fujitsu.com>

From: sunlianwen <sunlw.fnst@cn.fujitsu.com>
Date: Wed, 18 Apr 2018 08:29:52 +0800

> The comment of dev_mc_init() is wrong. which use dev_mc_flush
> instead of dev_mc_init.
> 
> Signed-off-by: Lianwen Sun <sunlw.fnst@cn.fujitsu.com>

Patch is still corrupted by your email client.

> - *     dev_mc_flush - Init multicast address list
> + *     dev_mc_init - Init multicast address list

The character after "*" is a TAB yet it is a sequence of SPACES
in your patch.

Your email client is doing this.

Please do not resend this patch to the mailing list until you can
successfully email the patch to yourself and apply the patch cleanly.

^ permalink raw reply

* Re: [PATCH 04/10] net: ax88796: Add block_input/output hooks to ax_plat_data
From: Michael Schmitz @ 2018-04-18  3:39 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: kbuild test robot, kbuild-all, netdev, Linux/m68k,
	Michael Karcher, Michael Karcher
In-Reply-To: <20180418011901.GC22103@lunn.ch>

Hi Andrew,

ax88796 includes it via linux/netdevice.h. mac-anubis.c doesn't.

Michael Karcher's patches have added forward derclarations for struct
netdevice and struct platform_data already - I'll add struct sk_buff
as suggested by Finn.

Cheers,

  Michael


On Wed, Apr 18, 2018 at 1:19 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Wed, Apr 18, 2018 at 12:53:21PM +1200, Michael Schmitz wrote:
>> I think this is a false positive - we're encouraged to provide the
>> full parameter list for functions, so the sreuct sk_buff* can't be
>> avoided.
>
> Hi Michael
>
> How is <linux/skbuff.h> being included?
>
> You probably want to build using the .config file and see.
>
>     Andrew

^ permalink raw reply

* Re: [PATCH net-next v2 00/21] net/ipv6: Separate data structures for FIB and data path
From: David Miller @ 2018-04-18  3:45 UTC (permalink / raw)
  To: dsahern; +Cc: netdev, idosch, roopa, eric.dumazet, weiwan, kafai, yoshfuji
In-Reply-To: <20180418003327.19992-1-dsahern@gmail.com>

From: David Ahern <dsahern@gmail.com>
Date: Tue, 17 Apr 2018 17:33:06 -0700

> IPv6 uses the same data struct for both control plane (FIB entries) and
> data path (dst entries). This struct has elements needed for both paths
> adding memory overhead and complexity (taking a dst hold in most places
> but an additional reference on rt6i_ref in a few). Furthermore, because
> of the dst_alloc tie, all FIB entries are allocated with GFP_ATOMIC.
> 
> This patch set separates FIB entries from dst entries, better aligning
> IPv6 code with IPv4, simplifying the reference counting and allowing
> FIB entries added by userspace (not autoconf) to use GFP_KERNEL. It is
> first step to a number of performance and scalability changes.
> 
> The end result of this patch set:
>   - FIB entries (fib6_info):
>         /* size: 208, cachelines: 4, members: 25 */
>         /* sum members: 207, holes: 1, sum holes: 1 */
> 
>   - dst entries (rt6_info)
>        /* size: 240, cachelines: 4, members: 11 */
> 
> Versus the the single rt6_info struct today for both paths:
>       /* size: 320, cachelines: 5, members: 28 */
> 
> This amounts to a 35% reduction in memory use for FIB entries and a
> 25% reduction for dst entries.

Looks great, series applied, thanks David!

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox