Netdev List
 help / color / mirror / Atom feed
* Re: [RFC v5 3/5] virtio_ring: add packed ring support
From: Tiwei Bie @ 2018-05-29  5:11 UTC (permalink / raw)
  To: Jason Wang; +Cc: mst, virtualization, linux-kernel, netdev, wexu, jfreimann
In-Reply-To: <30bd7505-0ded-8584-e9ab-152756a667d6@redhat.com>

On Tue, May 29, 2018 at 11:18:57AM +0800, Jason Wang wrote:
> On 2018年05月22日 16:16, Tiwei Bie wrote:
[...]
> > +static void detach_buf_packed(struct vring_virtqueue *vq,
> > +			      unsigned int id, void **ctx)
> > +{
> > +	struct vring_desc_state_packed *state;
> > +	struct vring_packed_desc *desc;
> > +	unsigned int i;
> > +	int *next;
> > +
> > +	/* Clear data ptr. */
> > +	vq->desc_state_packed[id].data = NULL;
> > +
> > +	next = &id;
> > +	for (i = 0; i < vq->desc_state_packed[id].num; i++) {
> > +		state = &vq->desc_state_packed[*next];
> > +		vring_unmap_state_packed(vq, state);
> > +		next = &vq->desc_state_packed[*next].next;
> 
> Have a short discussion with Michael. It looks like the only thing we care
> is DMA address and length here.

The length tracked by desc_state_packed[] is also necessary
when INDIRECT is used and the buffers are writable.

> 
> So a thought is to avoid using desc_state_packed() is vring_use_dma_api() is
> false? Probably need another id allocator or just use desc_state_packed for
> free id list.

I think it's a good suggestion. Thanks!

I won't track the addr/len/flags for non-indirect descs
when vring_use_dma_api() returns false.

> 
> > +	}
> > +
> > +	vq->vq.num_free += vq->desc_state_packed[id].num;
> > +	*next = vq->free_head;
> 
> Using pointer seems not elegant and unnecessary here. You can just track
> next in integer I think?

It's possible to use integer, but will need one more var
to track `prev` (desc_state_packed[prev].next == next in
this case).

> 
> > +	vq->free_head = id;
> > +
> > +	if (vq->indirect) {
> > +		u32 len;
> > +
> > +		/* Free the indirect table, if any, now that it's unmapped. */
> > +		desc = vq->desc_state_packed[id].indir_desc;
> > +		if (!desc)
> > +			return;
> > +
> > +		len = vq->desc_state_packed[id].len;
> > +		for (i = 0; i < len / sizeof(struct vring_packed_desc); i++)
> > +			vring_unmap_desc_packed(vq, &desc[i]);
> > +
> > +		kfree(desc);
> > +		vq->desc_state_packed[id].indir_desc = NULL;
> > +	} else if (ctx) {
> > +		*ctx = vq->desc_state_packed[id].indir_desc;
> > +	}
> >   }
> >   static inline bool more_used_packed(const struct vring_virtqueue *vq)
> >   {
> > -	return false;
> > +	u16 last_used, flags;
> > +	u8 avail, used;
> > +
> > +	last_used = vq->last_used_idx;
> > +	flags = virtio16_to_cpu(vq->vq.vdev,
> > +				vq->vring_packed.desc[last_used].flags);
> > +	avail = !!(flags & VRING_DESC_F_AVAIL(1));
> > +	used = !!(flags & VRING_DESC_F_USED(1));
> > +
> > +	return avail == used && used == vq->used_wrap_counter;
> 
> Spec does not check avail == used? So there's probably a bug in either of
> the two places.
> 
> In what condition that avail != used but used == vq_used_wrap_counter? A
> buggy device or device set the two bits in two writes?

Currently, spec doesn't forbid devices to set the status
bits as: avail != used but used == vq_used_wrap_counter.
So I think driver cannot assume this won't happen.

> 
> >   }
[...]
> >   static unsigned virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
> >   {
> > -	return 0;
> > +	struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > +	START_USE(vq);
> > +
> > +	/* We optimistically turn back on interrupts, then check if there was
> > +	 * more to do. */
> > +
> > +	if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > +		virtio_wmb(vq->weak_barriers);
> 
> Missing comments for the barrier.

Will add some comments.

> 
> > +		vq->event_flags_shadow = VRING_EVENT_F_ENABLE;
> > +		vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> > +							vq->event_flags_shadow);
> > +	}
> > +
> > +	END_USE(vq);
> > +	return vq->last_used_idx;
> >   }
> >   static bool virtqueue_poll_packed(struct virtqueue *_vq, unsigned last_used_idx)
> >   {
> > -	return false;
> > +	struct vring_virtqueue *vq = to_vvq(_vq);
> > +	u8 avail, used;
> > +	u16 flags;
> > +
> > +	virtio_mb(vq->weak_barriers);
> > +	flags = virtio16_to_cpu(vq->vq.vdev,
> > +			vq->vring_packed.desc[last_used_idx].flags);
> > +	avail = !!(flags & VRING_DESC_F_AVAIL(1));
> > +	used = !!(flags & VRING_DESC_F_USED(1));
> > +
> > +	return avail == used && used == vq->used_wrap_counter;
> >   }
> >   static bool virtqueue_enable_cb_delayed_packed(struct virtqueue *_vq)
> >   {
> > -	return false;
> > +	struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > +	START_USE(vq);
> > +
> > +	/* We optimistically turn back on interrupts, then check if there was
> > +	 * more to do. */
> > +
> > +	if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > +		virtio_wmb(vq->weak_barriers);
> 
> Need comments for the barrier.

Will add some comments.

Best regards,
Tiwei Bie

^ permalink raw reply

* Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path
From: Eric Dumazet @ 2018-05-29  4:53 UTC (permalink / raw)
  To: Yafang Shao, Eric Dumazet; +Cc: Song Liu, David Miller, netdev, LKML
In-Reply-To: <CALOAHbAbw6nXggT4ZF-=L_tQqsm-EQ==Qd9aeLys2mwQizFnkw@mail.gmail.com>



On 05/28/2018 05:41 PM, Yafang Shao wrote:

> OK.
> 
> And what about introducing a new helper tcp_hdr_fast() ?
> 
> /* use it when tcp header has not been pulled yet */
> static inline struct tcphdr *tcp_hdr_fast(const struct sk_buff *skb)
> 
> {
> 
>         return (const struct tcphdr *)skb->data;
> 
> }
> 
> 
> That could help us to use this optimized one instead of the original
> one if possilbe.


I would rather not add such macro...

The call site needs to know what is going on, so having a macro like that would not help.

^ permalink raw reply

* Re: [PATCH net-next v12 1/5] net: Introduce generic failover module
From: Stephen Hemminger @ 2018-05-25 23:29 UTC (permalink / raw)
  To: Samudrala, Sridhar
  Cc: mst, davem, netdev, virtualization, virtio-dev, jesse.brandeburg,
	alexander.h.duyck, kubakici, jasowang, loseweigh, jiri,
	aaron.f.brown, anjali.singhai
In-Reply-To: <00d34f67-f26f-0b20-af3f-2add24ae8a5c@intel.com>

On Fri, 25 May 2018 16:06:58 -0700
"Samudrala, Sridhar" <sridhar.samudrala@intel.com> wrote:

> On 5/25/2018 3:38 PM, Stephen Hemminger wrote:
> > On Thu, 24 May 2018 09:55:13 -0700
> > Sridhar Samudrala <sridhar.samudrala@intel.com> wrote:
> >  
> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> index 03ed492c4e14..0f4ba52b641d 100644
> >> --- a/include/linux/netdevice.h
> >> +++ b/include/linux/netdevice.h
> >> @@ -1421,6 +1421,8 @@ struct net_device_ops {
> >>    *	entity (i.e. the master device for bridged veth)
> >>    * @IFF_MACSEC: device is a MACsec device
> >>    * @IFF_NO_RX_HANDLER: device doesn't support the rx_handler hook
> >> + * @IFF_FAILOVER: device is a failover master device
> >> + * @IFF_FAILOVER_SLAVE: device is lower dev of a failover master device
> >>    */
> >>   enum netdev_priv_flags {
> >>   	IFF_802_1Q_VLAN			= 1<<0,
> >> @@ -1450,6 +1452,8 @@ enum netdev_priv_flags {
> >>   	IFF_PHONY_HEADROOM		= 1<<24,
> >>   	IFF_MACSEC			= 1<<25,
> >>   	IFF_NO_RX_HANDLER		= 1<<26,
> >> +	IFF_FAILOVER			= 1<<27,
> >> +	IFF_FAILOVER_SLAVE		= 1<<28,
> >>   };  
> > Why is FAILOVER any different than other master/slave relationships.
> > I don't think you need to take up precious netdev flag bits for this.  
> 
> These are netdev priv flags.
> Jiri says that IFF_MASTER/IFF_SLAVE are bonding specific flags and cannot be used
> with other failover mechanisms. Team also doesn't use this flags and it has its own
> priv_flags.
> 

They are already used by bonding and team.
I don't see why this can't reuse them.

^ permalink raw reply

* Re: [PATCH v3 00/11] Modify action API for implementing lockless actions
From: Cong Wang @ 2018-05-29  4:26 UTC (permalink / raw)
  To: Vlad Buslov
  Cc: Jiri Pirko, Linux Kernel Network Developers, Jamal Hadi Salim,
	David Miller, Alexei Starovoitov, Daniel Borkmann, kliteyn
In-Reply-To: <1527455849-22327-1-git-send-email-vladbu@mellanox.com>

On Sun, May 27, 2018 at 2:17 PM, Vlad Buslov <vladbu@mellanox.com> wrote:
> Currently, all netlink protocol handlers for updating rules, actions and
> qdiscs are protected with single global rtnl lock which removes any
> possibility for parallelism. This patch set is a first step to remove
> rtnl lock dependency from TC rules update path.
>
> Recently, new rtnl registration flag RTNL_FLAG_DOIT_UNLOCKED was added.
> Handlers registered with this flag are called without RTNL taken. End
> goal is to have rule update handlers(RTM_NEWTFILTER, RTM_DELTFILTER,
> etc.) to be registered with UNLOCKED flag to allow parallel execution.
> However, there is no intention to completely remove or split rtnl lock
> itself. This patch set addresses specific problems in action API that
> prevents it from being executed concurrently.


Great, your goal is much clear now! So can I expect this patchset is to
_completely_ get rid of RTNL lock from action update paths, correct?

I ask because this is your first step, RTNL is still acquired on upper layer,
that is, filter update paths.


>
> As a preparation for executing TC rules update handlers without rtnl
> lock, action API code was audited to determine areas that assume
> external synchronization with rtnl lock and must be changed to allow
> safe concurrent access with following results:
>
> 1. Action idr is already protected with spinlock. However, some code
>    paths assume that idr state is not changes between several
>    consecutive tcf_idr_* function calls.
> 2. tc_action reference and bind counters are implemented as plain
>    integers. They purpose was to allow single actions to be shared
>    between multiple filters, not to provide means for concurrent
>    modification.
> 3. tc_action 'cookie' pointer field is not protected against
>    modification.
> 4. Action API functions, that work with set of actions, use intrusive
>    linked list, which cannot be used concurrently without additional
>    synchronization.
> 5. Action API functions don't take reference to actions while using
>    them, assuming external synchronization with rtnl lock.


Fair enough, thanks for the details, but some high-level things are still
missing:

1. What lock protects action updates with your patches? Since you remove
RTNL from these paths, I assume no lock at all except the existing spinlock?
Please state here in your cover letter.


2. Assume 1) is correct, how do you guarantee an action update is atomic?
Let's say I have action foo:

struct act_foo
{
  int a;
  int b;
};

With RTNL:

rtnl_lock();
act_foo->a = a;
if (a == X)
  act_foo->b = b;
rtnl_unlock();

Without any lock (as I assumed):


act_foo->a = a;
// fast path now reads new ->a but old ->b
if (act_foo->a == X)
// Other slow path may be changing ->a too
  act_foo->b = b;

If my assumption is correct, please explain the above question in your
cover letter, it is very important for understanding your 11 patches.

If my assumption is wrong, please be specific on which lock protects
which paths here.


3. How are actions like act_mirred and act_ipt updated w/o RTNL?

act_mirred requires to hold a refcnt for target device:

        if (dev != NULL) {
                if (ret != ACT_P_CREATED)
                        dev_put(rcu_dereference_protected(m->tcfm_dev, 1));
                dev_hold(dev);
                rcu_assign_pointer(m->tcfm_dev, dev);
                m->tcfm_mac_header_xmit = mac_header_xmit;
        }

Without RTNL, how is dev_put()+dev_hold() be atomic in !CREATED case?

act_ipt calls xt_request_find_target() and xt_check_target(), I guess both
assumes RTNL?

Or you just leave these exceptions as they are but make the rest actions
lockless? If so, please list all of them here and describe why are they
special.


Last, since your end goal is to remove RTNL from filter update paths,
how does it work if a tc filter block shared among different qdiscs?
Assume a tc filter block can be shared by different qdiscs on different
devs.


Thanks!

^ permalink raw reply

* Re: [PATCH net-next 00/12] Misc. bug fixes & some minor additions to HNS3 driver
From: David Miller @ 2018-05-29  4:04 UTC (permalink / raw)
  To: salil.mehta
  Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
	linuxarm
In-Reply-To: <20180525184307.36288-1-salil.mehta@huawei.com>

From: Salil Mehta <salil.mehta@huawei.com>
Date: Fri, 25 May 2018 19:42:55 +0100

> This patch-set provides some bug fixes figured out during testing
> and review. It also provides some additions due to running of the
> existing code on the new revision of the HNS3 hardware.

Series applied.

^ permalink raw reply

* RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
From: Y.b. Lu @ 2018-05-29  3:57 UTC (permalink / raw)
  To: David Miller
  Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, richardcochran@gmail.com,
	Claudiu Manoil, robh+dt@kernel.org
In-Reply-To: <20180528.230631.1400838711386498433.davem@davemloft.net>

Hi David,

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, May 29, 2018 11:07 AM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; richardcochran@gmail.com; Claudiu Manoil
> <claudiu.manoil@nxp.com>; robh+dt@kernel.org
> Subject: Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ
> PTP clock driver
> 
> From: Yangbo Lu <yangbo.lu@nxp.com>
> Date: Fri, 25 May 2018 12:40:38 +0800
> 
> > Added myself as maintainer for QorIQ PTP clock driver.
> > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it
> > under QorIQ PTP clock driver.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> 
> Because of the dependency on the staging tree changes, this doesn't apply
> cleanly to net-next.
> 
> You'll have to figure out how you want to sort this out.

[Y.b. Lu] I sent out a v2 MAINTAINERS patch. I think it also makes sense to drop dpaa2 rtc drivers in the entry.
Thanks a lot.

^ permalink raw reply

* [v2] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
From: Yangbo Lu @ 2018-05-29  3:47 UTC (permalink / raw)
  To: netdev, devicetree, linux-kernel, Richard Cochran, claudiu.manoil,
	Rob Herring
  Cc: Yangbo Lu

Added myself as maintainer for QorIQ PTP clock driver.
Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's
maintain it under QorIQ PTP clock driver.

Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
---
Changes for v2:
	- Dropped dpaa2/rtc part.
---
 MAINTAINERS |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f492431..c16340c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5620,7 +5620,6 @@ M:	Claudiu Manoil <claudiu.manoil@nxp.com>
 L:	netdev@vger.kernel.org
 S:	Maintained
 F:	drivers/net/ethernet/freescale/gianfar*
-X:	drivers/net/ethernet/freescale/gianfar_ptp.c
 F:	Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
 
 FREESCALE GPMI NAND DRIVER
@@ -5667,6 +5666,14 @@ S:	Maintained
 F:	drivers/net/ethernet/freescale/fman
 F:	Documentation/devicetree/bindings/powerpc/fsl/fman.txt
 
+FREESCALE QORIQ PTP CLOCK DRIVER
+M:	Yangbo Lu <yangbo.lu@nxp.com>
+L:	netdev@vger.kernel.org
+S:	Maintained
+F:	drivers/ptp/ptp_qoriq.c
+F:	include/linux/fsl/ptp_qoriq.h
+F:	Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
+
 FREESCALE QUAD SPI DRIVER
 M:	Han Xu <han.xu@nxp.com>
 L:	linux-mtd@lists.infradead.org
@@ -11405,7 +11412,6 @@ S:	Maintained
 W:	http://linuxptp.sourceforge.net/
 F:	Documentation/ABI/testing/sysfs-ptp
 F:	Documentation/ptp/*
-F:	drivers/net/ethernet/freescale/gianfar_ptp.c
 F:	drivers/net/phy/dp83640*
 F:	drivers/ptp/*
 F:	include/linux/ptp_cl*
-- 
1.7.1

^ permalink raw reply related

* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2018-05-29  3:42 UTC (permalink / raw)
  To: David Miller, Networking, Al Viro
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Björn Töpel, Alexei Starovoitov, Christoph Hellwig

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

net/xdp/xsk.c: In function 'xsk_poll':
net/xdp/xsk.c:207:22: error: implicit declaration of function 'datagram_poll'; did you mean 'datagram_poll_mask'? [-Werror=implicit-function-declaration]
  unsigned int mask = datagram_poll(file, sock, wait);
                      ^~~~~~~~~~~~~ 
                      datagram_poll_mask

Caused by commit

  c497176cb2e4 ("xsk: add Rx receive functions and poll support")

interacting with commit

  db5051ead64a ("net: convert datagram_poll users tp ->poll_mask")

from the vfs tree.

[Christoph, I noticed that the comment above datagram_poll in
net/core/datagram.c needs the function name updated]

I have added the following merge fix patch for today:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 May 2018 13:34:25 +1000
Subject: [PATCH] xsk: update for "net: convert datagram_poll users tp->poll_mask"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 net/xdp/xsk.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index cce0e4f8a536..4ee140afbc61 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -201,10 +201,9 @@ static int xsk_sendmsg(struct socket *sock, struct msghdr *m, size_t total_len)
 	return xsk_generic_xmit(sk, m, total_len);
 }
 
-static unsigned int xsk_poll(struct file *file, struct socket *sock,
-			     struct poll_table_struct *wait)
+static __poll_t xsk_poll_mask(struct socket *sock, __poll_t events)
 {
-	unsigned int mask = datagram_poll(file, sock, wait);
+	__poll_t mask = datagram_poll_mask(sock, events);
 	struct sock *sk = sock->sk;
 	struct xdp_sock *xs = xdp_sk(sk);
 
@@ -580,7 +579,7 @@ static const struct proto_ops xsk_proto_ops = {
 	.socketpair	= sock_no_socketpair,
 	.accept		= sock_no_accept,
 	.getname	= sock_no_getname,
-	.poll		= xsk_poll,
+	.poll_mask	= xsk_poll_mask,
 	.ioctl		= sock_no_ioctl,
 	.listen		= sock_no_listen,
 	.shutdown	= sock_no_shutdown,
-- 
2.17.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply related

* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2018-05-29  3:25 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

Hi all,

After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:

x86_64-linux-ld: unknown architecture of input file `net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output

Caused by commit

  d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")

In my builds, the host is PowerPC 64 LE ...

I have reverted that commit along with

  61a552eb487f ("bpfilter: fix build dependency")
  13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug")

for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: [RFC v5 3/5] virtio_ring: add packed ring support
From: Jason Wang @ 2018-05-29  3:18 UTC (permalink / raw)
  To: Tiwei Bie, mst, virtualization, linux-kernel, netdev; +Cc: wexu, jfreimann
In-Reply-To: <20180522081648.14768-4-tiwei.bie@intel.com>



On 2018年05月22日 16:16, Tiwei Bie wrote:
> This commit introduces the support (without EVENT_IDX) for
> packed ring.
>
> Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> ---
>   drivers/virtio/virtio_ring.c | 474 ++++++++++++++++++++++++++++++++++-
>   1 file changed, 468 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index f5ef5f42a7cf..eb9fd5207a68 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -62,6 +62,12 @@ struct vring_desc_state {
>   };
>   
>   struct vring_desc_state_packed {
> +	void *data;			/* Data for callback. */
> +	struct vring_packed_desc *indir_desc; /* Indirect descriptor, if any. */
> +	int num;			/* Descriptor list length. */
> +	dma_addr_t addr;		/* Buffer DMA addr. */
> +	u32 len;			/* Buffer length. */
> +	u16 flags;			/* Descriptor flags. */
>   	int next;			/* The next desc state. */
>   };
>   
> @@ -758,6 +764,72 @@ static inline unsigned vring_size_packed(unsigned int num, unsigned long align)
>   		& ~(align - 1)) + sizeof(struct vring_packed_desc_event) * 2;
>   }
>   
> +static void vring_unmap_state_packed(const struct vring_virtqueue *vq,
> +				     struct vring_desc_state_packed *state)
> +{
> +	u16 flags;
> +
> +	if (!vring_use_dma_api(vq->vq.vdev))
> +		return;
> +
> +	flags = state->flags;
> +
> +	if (flags & VRING_DESC_F_INDIRECT) {
> +		dma_unmap_single(vring_dma_dev(vq),
> +				 state->addr, state->len,
> +				 (flags & VRING_DESC_F_WRITE) ?
> +				 DMA_FROM_DEVICE : DMA_TO_DEVICE);
> +	} else {
> +		dma_unmap_page(vring_dma_dev(vq),
> +			       state->addr, state->len,
> +			       (flags & VRING_DESC_F_WRITE) ?
> +			       DMA_FROM_DEVICE : DMA_TO_DEVICE);
> +	}
> +}
> +
> +static void vring_unmap_desc_packed(const struct vring_virtqueue *vq,
> +				   struct vring_packed_desc *desc)
> +{
> +	u16 flags;
> +
> +	if (!vring_use_dma_api(vq->vq.vdev))
> +		return;
> +
> +	flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
> +
> +	if (flags & VRING_DESC_F_INDIRECT) {
> +		dma_unmap_single(vring_dma_dev(vq),
> +				 virtio64_to_cpu(vq->vq.vdev, desc->addr),
> +				 virtio32_to_cpu(vq->vq.vdev, desc->len),
> +				 (flags & VRING_DESC_F_WRITE) ?
> +				 DMA_FROM_DEVICE : DMA_TO_DEVICE);
> +	} else {
> +		dma_unmap_page(vring_dma_dev(vq),
> +			       virtio64_to_cpu(vq->vq.vdev, desc->addr),
> +			       virtio32_to_cpu(vq->vq.vdev, desc->len),
> +			       (flags & VRING_DESC_F_WRITE) ?
> +			       DMA_FROM_DEVICE : DMA_TO_DEVICE);
> +	}
> +}
> +
> +static struct vring_packed_desc *alloc_indirect_packed(struct virtqueue *_vq,
> +						       unsigned int total_sg,
> +						       gfp_t gfp)
> +{
> +	struct vring_packed_desc *desc;
> +
> +	/*
> +	 * We require lowmem mappings for the descriptors because
> +	 * otherwise virt_to_phys will give us bogus addresses in the
> +	 * virtqueue.
> +	 */
> +	gfp &= ~__GFP_HIGHMEM;
> +
> +	desc = kmalloc(total_sg * sizeof(struct vring_packed_desc), gfp);
> +
> +	return desc;
> +}
> +
>   static inline int virtqueue_add_packed(struct virtqueue *_vq,
>   				       struct scatterlist *sgs[],
>   				       unsigned int total_sg,
> @@ -767,47 +839,437 @@ static inline int virtqueue_add_packed(struct virtqueue *_vq,
>   				       void *ctx,
>   				       gfp_t gfp)
>   {
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +	struct vring_packed_desc *desc;
> +	struct scatterlist *sg;
> +	unsigned int i, n, descs_used, uninitialized_var(prev), err_idx;
> +	__virtio16 uninitialized_var(head_flags), flags;
> +	u16 head, avail_wrap_counter, id, cur;
> +	bool indirect;
> +
> +	START_USE(vq);
> +
> +	BUG_ON(data == NULL);
> +	BUG_ON(ctx && vq->indirect);
> +
> +	if (unlikely(vq->broken)) {
> +		END_USE(vq);
> +		return -EIO;
> +	}
> +
> +#ifdef DEBUG
> +	{
> +		ktime_t now = ktime_get();
> +
> +		/* No kick or get, with .1 second between?  Warn. */
> +		if (vq->last_add_time_valid)
> +			WARN_ON(ktime_to_ms(ktime_sub(now, vq->last_add_time))
> +					    > 100);
> +		vq->last_add_time = now;
> +		vq->last_add_time_valid = true;
> +	}
> +#endif
> +
> +	BUG_ON(total_sg == 0);
> +
> +	head = vq->next_avail_idx;
> +	avail_wrap_counter = vq->avail_wrap_counter;
> +
> +	if (virtqueue_use_indirect(_vq, total_sg))
> +		desc = alloc_indirect_packed(_vq, total_sg, gfp);
> +	else {
> +		desc = NULL;
> +		WARN_ON_ONCE(total_sg > vq->vring_packed.num && !vq->indirect);
> +	}
> +
> +	if (desc) {
> +		/* Use a single buffer which doesn't continue */
> +		indirect = true;
> +		/* Set up rest to use this indirect table. */
> +		i = 0;
> +		descs_used = 1;
> +	} else {
> +		indirect = false;
> +		desc = vq->vring_packed.desc;
> +		i = head;
> +		descs_used = total_sg;
> +	}
> +
> +	if (vq->vq.num_free < descs_used) {
> +		pr_debug("Can't add buf len %i - avail = %i\n",
> +			 descs_used, vq->vq.num_free);
> +		/* FIXME: for historical reasons, we force a notify here if
> +		 * there are outgoing parts to the buffer.  Presumably the
> +		 * host should service the ring ASAP. */
> +		if (out_sgs)
> +			vq->notify(&vq->vq);
> +		if (indirect)
> +			kfree(desc);
> +		END_USE(vq);
> +		return -ENOSPC;
> +	}
> +
> +	id = vq->free_head;
> +	BUG_ON(id == vq->vring_packed.num);
> +
> +	cur = id;
> +	for (n = 0; n < out_sgs + in_sgs; n++) {
> +		for (sg = sgs[n]; sg; sg = sg_next(sg)) {
> +			dma_addr_t addr = vring_map_one_sg(vq, sg, n < out_sgs ?
> +					       DMA_TO_DEVICE : DMA_FROM_DEVICE);
> +			if (vring_mapping_error(vq, addr))
> +				goto unmap_release;
> +
> +			flags = cpu_to_virtio16(_vq->vdev, VRING_DESC_F_NEXT |
> +				  (n < out_sgs ? 0 : VRING_DESC_F_WRITE) |
> +				  VRING_DESC_F_AVAIL(vq->avail_wrap_counter) |
> +				  VRING_DESC_F_USED(!vq->avail_wrap_counter));
> +			if (!indirect && i == head)
> +				head_flags = flags;
> +			else
> +				desc[i].flags = flags;
> +
> +			desc[i].addr = cpu_to_virtio64(_vq->vdev, addr);
> +			desc[i].len = cpu_to_virtio32(_vq->vdev, sg->length);
> +			i++;
> +			if (!indirect) {
> +				vq->desc_state_packed[cur].addr = addr;
> +				vq->desc_state_packed[cur].len = sg->length;
> +				vq->desc_state_packed[cur].flags =
> +					virtio16_to_cpu(_vq->vdev, flags);
> +				cur = vq->desc_state_packed[cur].next;
> +
> +				if (i >= vq->vring_packed.num) {
> +					i = 0;
> +					vq->avail_wrap_counter ^= 1;
> +				}
> +			}
> +		}
> +	}
> +
> +	prev = (i > 0 ? i : vq->vring_packed.num) - 1;
> +	desc[prev].id = cpu_to_virtio16(_vq->vdev, id);
> +
> +	/* Last one doesn't continue. */
> +	if (total_sg == 1)
> +		head_flags &= cpu_to_virtio16(_vq->vdev, ~VRING_DESC_F_NEXT);
> +	else
> +		desc[prev].flags &= cpu_to_virtio16(_vq->vdev,
> +						~VRING_DESC_F_NEXT);
> +
> +	if (indirect) {
> +		/* Now that the indirect table is filled in, map it. */
> +		dma_addr_t addr = vring_map_single(
> +			vq, desc, total_sg * sizeof(struct vring_packed_desc),
> +			DMA_TO_DEVICE);
> +		if (vring_mapping_error(vq, addr))
> +			goto unmap_release;
> +
> +		head_flags = cpu_to_virtio16(_vq->vdev, VRING_DESC_F_INDIRECT |
> +				       VRING_DESC_F_AVAIL(avail_wrap_counter) |
> +				       VRING_DESC_F_USED(!avail_wrap_counter));
> +		vq->vring_packed.desc[head].addr = cpu_to_virtio64(_vq->vdev,
> +								   addr);
> +		vq->vring_packed.desc[head].len = cpu_to_virtio32(_vq->vdev,
> +				total_sg * sizeof(struct vring_packed_desc));
> +		vq->vring_packed.desc[head].id = cpu_to_virtio16(_vq->vdev, id);
> +
> +		vq->desc_state_packed[id].addr = addr;
> +		vq->desc_state_packed[id].len = total_sg *
> +				sizeof(struct vring_packed_desc);
> +		vq->desc_state_packed[id].flags =
> +				virtio16_to_cpu(_vq->vdev, head_flags);
> +	}
> +
> +	/* We're using some buffers from the free list. */
> +	vq->vq.num_free -= descs_used;
> +
> +	/* Update free pointer */
> +	if (indirect) {
> +		n = head + 1;
> +		if (n >= vq->vring_packed.num) {
> +			n = 0;
> +			vq->avail_wrap_counter ^= 1;
> +		}
> +		vq->next_avail_idx = n;
> +		vq->free_head = vq->desc_state_packed[id].next;
> +	} else {
> +		vq->next_avail_idx = i;
> +		vq->free_head = cur;
> +	}
> +
> +	/* Store token and indirect buffer state. */
> +	vq->desc_state_packed[id].num = descs_used;
> +	vq->desc_state_packed[id].data = data;
> +	if (indirect)
> +		vq->desc_state_packed[id].indir_desc = desc;
> +	else
> +		vq->desc_state_packed[id].indir_desc = ctx;
> +
> +	/* A driver MUST NOT make the first descriptor in the list
> +	 * available before all subsequent descriptors comprising
> +	 * the list are made available. */
> +	virtio_wmb(vq->weak_barriers);
> +	vq->vring_packed.desc[head].flags = head_flags;
> +	vq->num_added += descs_used;
> +
> +	pr_debug("Added buffer head %i to %p\n", head, vq);
> +	END_USE(vq);
> +
> +	return 0;
> +
> +unmap_release:
> +	err_idx = i;
> +	i = head;
> +
> +	for (n = 0; n < total_sg; n++) {
> +		if (i == err_idx)
> +			break;
> +		vring_unmap_desc_packed(vq, &desc[i]);
> +		i++;
> +		if (!indirect && i >= vq->vring_packed.num)
> +			i = 0;
> +	}
> +
> +	vq->avail_wrap_counter = avail_wrap_counter;
> +
> +	if (indirect)
> +		kfree(desc);
> +
> +	END_USE(vq);
>   	return -EIO;
>   }
>   
>   static bool virtqueue_kick_prepare_packed(struct virtqueue *_vq)
>   {
> -	return false;
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +	u16 flags;
> +	bool needs_kick;
> +	u32 snapshot;
> +
> +	START_USE(vq);
> +	/* We need to expose the new flags value before checking notification
> +	 * suppressions. */
> +	virtio_mb(vq->weak_barriers);
> +
> +	snapshot = *(u32 *)vq->vring_packed.device;
> +	flags = virtio16_to_cpu(_vq->vdev, (__virtio16)(snapshot >> 16)) & 0x3;
> +
> +#ifdef DEBUG
> +	if (vq->last_add_time_valid) {
> +		WARN_ON(ktime_to_ms(ktime_sub(ktime_get(),
> +					      vq->last_add_time)) > 100);
> +	}
> +	vq->last_add_time_valid = false;
> +#endif
> +
> +	needs_kick = (flags != VRING_EVENT_F_DISABLE);
> +	END_USE(vq);
> +	return needs_kick;
> +}
> +
> +static void detach_buf_packed(struct vring_virtqueue *vq,
> +			      unsigned int id, void **ctx)
> +{
> +	struct vring_desc_state_packed *state;
> +	struct vring_packed_desc *desc;
> +	unsigned int i;
> +	int *next;
> +
> +	/* Clear data ptr. */
> +	vq->desc_state_packed[id].data = NULL;
> +
> +	next = &id;
> +	for (i = 0; i < vq->desc_state_packed[id].num; i++) {
> +		state = &vq->desc_state_packed[*next];
> +		vring_unmap_state_packed(vq, state);
> +		next = &vq->desc_state_packed[*next].next;

Have a short discussion with Michael. It looks like the only thing we 
care is DMA address and length here.

So a thought is to avoid using desc_state_packed() is 
vring_use_dma_api() is false? Probably need another id allocator or just 
use desc_state_packed for free id list.

> +	}
> +
> +	vq->vq.num_free += vq->desc_state_packed[id].num;
> +	*next = vq->free_head;

Using pointer seems not elegant and unnecessary here. You can just track 
next in integer I think?

> +	vq->free_head = id;
> +
> +	if (vq->indirect) {
> +		u32 len;
> +
> +		/* Free the indirect table, if any, now that it's unmapped. */
> +		desc = vq->desc_state_packed[id].indir_desc;
> +		if (!desc)
> +			return;
> +
> +		len = vq->desc_state_packed[id].len;
> +		for (i = 0; i < len / sizeof(struct vring_packed_desc); i++)
> +			vring_unmap_desc_packed(vq, &desc[i]);
> +
> +		kfree(desc);
> +		vq->desc_state_packed[id].indir_desc = NULL;
> +	} else if (ctx) {
> +		*ctx = vq->desc_state_packed[id].indir_desc;
> +	}
>   }
>   
>   static inline bool more_used_packed(const struct vring_virtqueue *vq)
>   {
> -	return false;
> +	u16 last_used, flags;
> +	u8 avail, used;
> +
> +	last_used = vq->last_used_idx;
> +	flags = virtio16_to_cpu(vq->vq.vdev,
> +				vq->vring_packed.desc[last_used].flags);
> +	avail = !!(flags & VRING_DESC_F_AVAIL(1));
> +	used = !!(flags & VRING_DESC_F_USED(1));
> +
> +	return avail == used && used == vq->used_wrap_counter;

Spec does not check avail == used? So there's probably a bug in either 
of the two places.

In what condition that avail != used but used == vq_used_wrap_counter? A 
buggy device or device set the two bits in two writes?

>   }
>   
>   static void *virtqueue_get_buf_ctx_packed(struct virtqueue *_vq,
>   					  unsigned int *len,
>   					  void **ctx)
>   {
> -	return NULL;
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +	u16 last_used, id;
> +	void *ret;
> +
> +	START_USE(vq);
> +
> +	if (unlikely(vq->broken)) {
> +		END_USE(vq);
> +		return NULL;
> +	}
> +
> +	if (!more_used_packed(vq)) {
> +		pr_debug("No more buffers in queue\n");
> +		END_USE(vq);
> +		return NULL;
> +	}
> +
> +	/* Only get used elements after they have been exposed by host. */
> +	virtio_rmb(vq->weak_barriers);
> +
> +	last_used = vq->last_used_idx;
> +	id = virtio16_to_cpu(_vq->vdev, vq->vring_packed.desc[last_used].id);
> +	*len = virtio32_to_cpu(_vq->vdev, vq->vring_packed.desc[last_used].len);
> +
> +	if (unlikely(id >= vq->vring_packed.num)) {
> +		BAD_RING(vq, "id %u out of range\n", id);
> +		return NULL;
> +	}
> +	if (unlikely(!vq->desc_state_packed[id].data)) {
> +		BAD_RING(vq, "id %u is not a head!\n", id);
> +		return NULL;
> +	}
> +
> +	vq->last_used_idx += vq->desc_state_packed[id].num;
> +	if (vq->last_used_idx >= vq->vring_packed.num) {
> +		vq->last_used_idx -= vq->vring_packed.num;
> +		vq->used_wrap_counter ^= 1;
> +	}
> +
> +	/* detach_buf_packed clears data, so grab it now. */
> +	ret = vq->desc_state_packed[id].data;
> +	detach_buf_packed(vq, id, ctx);
> +
> +#ifdef DEBUG
> +	vq->last_add_time_valid = false;
> +#endif
> +
> +	END_USE(vq);
> +	return ret;
>   }
>   
>   static void virtqueue_disable_cb_packed(struct virtqueue *_vq)
>   {
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +
> +	if (vq->event_flags_shadow != VRING_EVENT_F_DISABLE) {
> +		vq->event_flags_shadow = VRING_EVENT_F_DISABLE;
> +		vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> +							vq->event_flags_shadow);
> +	}
>   }
>   
>   static unsigned virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
>   {
> -	return 0;
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +
> +	START_USE(vq);
> +
> +	/* We optimistically turn back on interrupts, then check if there was
> +	 * more to do. */
> +
> +	if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> +		virtio_wmb(vq->weak_barriers);

Missing comments for the barrier.

> +		vq->event_flags_shadow = VRING_EVENT_F_ENABLE;
> +		vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> +							vq->event_flags_shadow);
> +	}
> +
> +	END_USE(vq);
> +	return vq->last_used_idx;
>   }
>   
>   static bool virtqueue_poll_packed(struct virtqueue *_vq, unsigned last_used_idx)
>   {
> -	return false;
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +	u8 avail, used;
> +	u16 flags;
> +
> +	virtio_mb(vq->weak_barriers);
> +	flags = virtio16_to_cpu(vq->vq.vdev,
> +			vq->vring_packed.desc[last_used_idx].flags);
> +	avail = !!(flags & VRING_DESC_F_AVAIL(1));
> +	used = !!(flags & VRING_DESC_F_USED(1));
> +
> +	return avail == used && used == vq->used_wrap_counter;
>   }
>   
>   static bool virtqueue_enable_cb_delayed_packed(struct virtqueue *_vq)
>   {
> -	return false;
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +
> +	START_USE(vq);
> +
> +	/* We optimistically turn back on interrupts, then check if there was
> +	 * more to do. */
> +
> +	if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> +		virtio_wmb(vq->weak_barriers);


Need comments for the barrier.

> +		vq->event_flags_shadow = VRING_EVENT_F_ENABLE;
> +		vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> +							vq->event_flags_shadow);
> +	}
> +
> +	if (more_used_packed(vq)) {
> +		END_USE(vq);
> +		return false;
> +	}
> +
> +	END_USE(vq);
> +	return true;
>   }
>   
>   static void *virtqueue_detach_unused_buf_packed(struct virtqueue *_vq)
>   {
> +	struct vring_virtqueue *vq = to_vvq(_vq);
> +	unsigned int i;
> +	void *buf;
> +
> +	START_USE(vq);
> +
> +	for (i = 0; i < vq->vring_packed.num; i++) {
> +		if (!vq->desc_state_packed[i].data)
> +			continue;
> +		/* detach_buf clears data, so grab it now. */
> +		buf = vq->desc_state_packed[i].data;
> +		detach_buf_packed(vq, i, NULL);
> +		END_USE(vq);
> +		return buf;
> +	}
> +	/* That should have freed everything. */
> +	BUG_ON(vq->vq.num_free != vq->vring_packed.num);
> +
> +	END_USE(vq);
>   	return NULL;
>   }
>   

^ permalink raw reply

* Re: [PATCH net-next] net: sched: shrink struct Qdisc
From: David Miller @ 2018-05-29  3:13 UTC (permalink / raw)
  To: pabeni; +Cc: netdev, jhs, xiyou.wangcong, jiri
In-Reply-To: <607936fe39bf1e78ca8b520e2ef25b7b326a767f.1527258390.git.pabeni@redhat.com>

From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 25 May 2018 16:28:44 +0200

> The struct Qdisc has a lot of holes, especially after commit
> a53851e2c321 ("net: sched: explicit locking in gso_cpu fallback"),
> which as a side effect, moved the fields just after 'busylock'
> on a new cacheline.
> 
> Since both 'padded' and 'refcnt' are not updated frequently, and
> there is a hole before 'gso_skb', we can move such fields there,
> saving a cacheline without any performance side effect.
> 
> Before this commit:
> 
> pahole -C Qdisc net/sche/sch_generic.o
> 	# ...
>         /* size: 384, cachelines: 6, members: 25 */
>         /* sum members: 236, holes: 3, sum holes: 92 */
>         /* padding: 56 */
> 
> After this commit:
> pahole -C Qdisc net/sche/sch_generic.o
> 	# ...
> 	/* size: 320, cachelines: 5, members: 25 */
> 	/* sum members: 236, holes: 2, sum holes: 28 */
> 	/* padding: 56 */
> 
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] qmi_wwan: apply SET_DTR quirk to the SIMCOM shared device ID
From: David Miller @ 2018-05-29  3:13 UTC (permalink / raw)
  To: bjorn; +Cc: netdev, linux-usb, rspmn
In-Reply-To: <20180525130020.28847-1-bjorn@mork.no>

From: Bjørn Mork <bjorn@mork.no>
Date: Fri, 25 May 2018 15:00:20 +0200

> SIMCOM are reusing a single device ID for many (all of their?)
> different modems, based on different chipsets and firmwares. Newer
> Qualcomm chipset generations require setting DTR to wake the QMI
> function.  The SIM7600E modem is using such a chipset, making it
> fail to work with this driver despite the device ID match.
> 
> Fix by unconditionally enabling the SET_DTR quirk for all SIMCOM
> modems using this specific device ID.  This is similar to what
> we already have done for another case of device IDs recycled over
> multiple chipset generations: 14cf4a771b30 ("drivers: net: usb:
> qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201")
> 
> Initial testing on an older SIM7100 modem shows no immediate side
> effects.
> 
> Reported-by: Sebastian Sjoholm <sebastian.sjoholm@gmail.com>
> Cc: Reinhard Speyerer <rspmn@arcor.de>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>

Applied.

^ permalink raw reply

* Re: [PATCH] net: netsec: reduce DMA mask to 40 bits
From: David Miller @ 2018-05-29  3:12 UTC (permalink / raw)
  To: ard.biesheuvel
  Cc: netdev, robin.murphy, jaswinder.singh, masahisa.kojima,
	ilias.apalodimas
In-Reply-To: <20180525125037.779-1-ard.biesheuvel@linaro.org>

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date: Fri, 25 May 2018 14:50:37 +0200

> The netsec network controller IP can drive 64 address bits for DMA, and
> the DMA mask is set accordingly in the driver. However, the SynQuacer
> SoC, which is the only silicon incorporating this IP at the moment,
> integrates this IP in a manner that leaves address bits [63:40]
> unconnected.
> 
> Up until now, this has not resulted in any problems, given that the DDR
> controller doesn't decode those bits to begin with. However, recent
> firmware updates for platforms incorporating this SoC allow the IOMMU
> to be enabled, which does decode address bits [47:40], and allocates
> top down from the IOVA space, producing DMA addresses that have bits
> set that have been left unconnected.
> 
> Both the DT and ACPI (IORT) descriptions of the platform take this into
> account, and only describe a DMA address space of 40 bits (using either
> dma-ranges DT properties, or DMA address limits in IORT named component
> nodes). However, even though our IOMMU and bus layers may take such
> limitations into account by setting a narrower DMA mask when creating
> the platform device, the netsec probe() entrypoint follows the common
> practice of setting the DMA mask uncondionally, according to the
> capabilities of the IP block itself rather than to its integration into
> the chip.
> 
> It is currently unclear what the correct fix is here. We could hack around
> it by only setting the DMA mask if it deviates from its default value of
> DMA_BIT_MASK(32). However, this makes it impossible for the bus layer to
> use DMA_BIT_MASK(32) as the bus limit, and so it appears that a more
> comprehensive approach is required to take DMA limits imposed by the
> SoC as a whole into account.
> 
> In the mean time, let's limit the DMA mask to 40 bits. Given that there
> is currently only one SoC that incorporates this IP, this is a reasonable
> approach that can be backported to -stable and buys us some time to come
> up with a proper fix going forward.
> 
> Fixes: 533dd11a12f6 ("net: socionext: Add Synquacer NetSec driver")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Applied and queued up for -stable.

^ permalink raw reply

* linux-next: build warning after merge of the net-next tree
From: Stephen Rothwell @ 2018-05-29  3:10 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Daniel Borkmann, John Fastabend

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

Hi all,

After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

net/core/filter.c: In function 'sk_msg_convert_ctx_access':
net/core/filter.c:6450:6: warning: unused variable 'off' [-Wunused-variable]
  int off;
      ^~~

Introduced by commit

  303def35f64e ("bpf: allow sk_msg programs to read sock fields")

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: [PATCH net] ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline
From: David Miller @ 2018-05-29  3:10 UTC (permalink / raw)
  To: m.xhonneux; +Cc: netdev, dlebrun
In-Reply-To: <20180525122941.21851-1-m.xhonneux@gmail.com>

From: Mathieu Xhonneux <m.xhonneux@gmail.com>
Date: Fri, 25 May 2018 13:29:41 +0100

> seg6_do_srh_encap and seg6_do_srh_inline can possibly do an
> out-of-bounds access when adding the SRH to the packet. This no longer
> happen when expanding the skb not only by the size of the SRH (+
> outer IPv6 header), but also by skb->mac_len.
 ...
> Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
> Signed-off-by: David Lebrun <dlebrun@google.com>
> Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [PATCH V0:net-next 0/4] net: ethernet: stmmac: add support for stm32mp1
From: David Miller @ 2018-05-29  3:08 UTC (permalink / raw)
  To: christophe.roullier
  Cc: joabreu, mcoquelin.stm32, alexandre.torgue, peppe.cavallaro,
	linux-kernel, linux-arm-kernel, netdev, robh
In-Reply-To: <1527234401-15812-1-git-send-email-christophe.roullier@st.com>

From: Christophe Roullier <christophe.roullier@st.com>
Date: Fri, 25 May 2018 09:46:37 +0200

> Patches to have Ethernet support on stm32mp1

Series applied.

^ permalink raw reply

* Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
From: David Miller @ 2018-05-29  3:06 UTC (permalink / raw)
  To: yangbo.lu
  Cc: netdev, devicetree, linux-kernel, richardcochran, claudiu.manoil,
	robh+dt
In-Reply-To: <20180525044038.37756-5-yangbo.lu@nxp.com>

From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Fri, 25 May 2018 12:40:38 +0800

> Added myself as maintainer for QorIQ PTP clock driver.
> Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's
> also maintain it under QorIQ PTP clock driver.
> 
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Because of the dependency on the staging tree changes, this
doesn't apply cleanly to net-next.

You'll have to figure out how you want to sort this out.

^ permalink raw reply

* Re: [PATCH 4/5] dt-bindings: ptp: add ptp-qoriq.txt
From: David Miller @ 2018-05-29  3:06 UTC (permalink / raw)
  To: yangbo.lu
  Cc: netdev, devicetree, linux-kernel, richardcochran, claudiu.manoil,
	robh+dt
In-Reply-To: <20180525044038.37756-4-yangbo.lu@nxp.com>

From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Fri, 25 May 2018 12:40:37 +0800

> This patch is to add a documentation for ptp_qoriq dt-bindings.
> The description for ptp_qoriq dt-bindings was actually moved
> from Documentation/devicetree/bindings/net/fsl-tsec-phy.txt,
> since gianfar_ptp driver was moved to ptp_qoriq driver.
> 
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Applied.

^ permalink raw reply

* Re: [PATCH 3/5] net: ethernet: gianfar_ethtool: get phc index through drvdata
From: David Miller @ 2018-05-29  3:06 UTC (permalink / raw)
  To: yangbo.lu
  Cc: netdev, devicetree, linux-kernel, richardcochran, claudiu.manoil,
	robh+dt
In-Reply-To: <20180525044038.37756-3-yangbo.lu@nxp.com>

From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Fri, 25 May 2018 12:40:36 +0800

> Global variable gfar_phc_index was used to get and store
> phc index through gianfar_ptp driver. However gianfar_ptp
> had been renamed as ptp_qoriq for QorIQ common PTP driver.
> This gfar_phc_index doesn't work any more, and the phc index
> is stored in drvdata now. This patch is to support getting
> phc index through ptp_qoriq drvdata.
> 
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/5] ptp_qoriq: move some definitions to header file
From: David Miller @ 2018-05-29  3:05 UTC (permalink / raw)
  To: yangbo.lu
  Cc: netdev, devicetree, linux-kernel, richardcochran, claudiu.manoil,
	robh+dt
In-Reply-To: <20180525044038.37756-2-yangbo.lu@nxp.com>

From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Fri, 25 May 2018 12:40:35 +0800

> This patch is to move some definitions in ptp_qoriq.c
> to the header file.
> 
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Applied.

^ permalink raw reply

* Re: [PATCH 1/5] ptp: rework gianfar_ptp as QorIQ common PTP driver
From: David Miller @ 2018-05-29  3:05 UTC (permalink / raw)
  To: yangbo.lu
  Cc: netdev, devicetree, linux-kernel, richardcochran, claudiu.manoil,
	robh+dt
In-Reply-To: <20180525044038.37756-1-yangbo.lu@nxp.com>

From: Yangbo Lu <yangbo.lu@nxp.com>
Date: Fri, 25 May 2018 12:40:34 +0800

> gianfar_ptp was the PTP clock driver for 1588 timer
> module of Freescale QorIQ eTSEC (Enhanced Three-Speed
> Ethernet Controllers) platforms. Actually QorIQ DPAA
> (Data Path Acceleration Architecture) platforms is
> also using the same 1588 timer module in hardware.
> 
> This patch is to rework gianfar_ptp as QorIQ common
> PTP driver to support both DPAA and eTSEC. Moved
> gianfar_ptp.c to drivers/ptp/, renamed it as
> ptp_qoriq.c, and renamed many variables. There were
> not any function changes.
> 
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] ifb: fix packets checksum
From: David Miller @ 2018-05-29  3:02 UTC (permalink / raw)
  To: jmaxwell37
  Cc: dsahern, mschiffer, zhangshengju, ktkhai, netdev, linux-kernel,
	jmaxwell
In-Reply-To: <20180524213829.15208-1-jmaxwell37@gmail.com>

From: Jon Maxwell <jmaxwell37@gmail.com>
Date: Fri, 25 May 2018 07:38:29 +1000

> Fixup the checksum for CHECKSUM_COMPLETE when pulling skbs on RX path. 
> Otherwise we get splats when tc mirred is used to redirect packets to ifb.
> 
> Before fix:
> 
> nic: hw csum failure
> 
> Signed-off-by: Jon Maxwell <jmaxwell37@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] net: phy: realtek: add suspend/resume callbacks for RTL8211B
From: David Miller @ 2018-05-29  3:02 UTC (permalink / raw)
  To: hkallweit1; +Cc: nic_swsd, hau, f.fainelli, andrew, netdev, haokexin
In-Reply-To: <c6bcb091-1602-0ae9-8112-c4a6284b9c35@gmail.com>

From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 24 May 2018 22:40:12 +0200

> Add RTL8211B suspend / resume callbacks.
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next v12 0/5] Enable virtio_net to act as a standby for a passthru device
From: David Miller @ 2018-05-29  3:00 UTC (permalink / raw)
  To: sridhar.samudrala
  Cc: mst, stephen, netdev, virtualization, virtio-dev,
	jesse.brandeburg, alexander.h.duyck, kubakici, jasowang,
	loseweigh, jiri, aaron.f.brown, anjali.singhai
In-Reply-To: <1527180917-39737-1-git-send-email-sridhar.samudrala@intel.com>

From: Sridhar Samudrala <sridhar.samudrala@intel.com>
Date: Thu, 24 May 2018 09:55:12 -0700

> The main motivation for this patch is to enable cloud service providers
> to provide an accelerated datapath to virtio-net enabled VMs in a 
> transparent manner with no/minimal guest userspace changes. This also
> enables hypervisor controlled live migration to be supported with VMs that
> have direct attached SR-IOV VF devices.
 ...

Series applied, thank you.

^ permalink raw reply

* linux-next: manual merge of the net-next tree with the s390 tree
From: Stephen Rothwell @ 2018-05-29  3:00 UTC (permalink / raw)
  To: David Miller, Networking, Martin Schwidefsky, Heiko Carstens
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Ursula Braun,
	Daniel Borkmann, Alexei Starovoitov

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  arch/s390/net/Makefile

between commit:

  866f4c8e0e26 ("s390/net: add pnetid support")

from the s390 tree and commit:

  e1cf4befa297 ("bpf, s390x: remove ld_abs/ld_ind")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/net/Makefile
index e2b85ffdbb0c,d4663b4bf509..000000000000
--- a/arch/s390/net/Makefile
+++ b/arch/s390/net/Makefile
@@@ -2,5 -2,4 +2,5 @@@
  #
  # Arch-specific network modules
  #
- obj-$(CONFIG_BPF_JIT) += bpf_jit.o bpf_jit_comp.o
+ obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o
 +obj-$(CONFIG_HAVE_PNETID) += pnet.o

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ 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