* Re: linux-next: build failures after merge of the vfs tree
From: Al Viro @ 2020-06-16 15:14 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, netdev
In-Reply-To: <20200616143807.GA1359@gondor.apana.org.au>
On Wed, Jun 17, 2020 at 12:38:07AM +1000, Herbert Xu wrote:
> On Tue, Jun 16, 2020 at 04:38:49AM +0100, Al Viro wrote:
> >
> > Folded and pushed
>
> Thanks Al. Here's another one that I just got, could you add this
> one too?
Done...
^ permalink raw reply
* Re: [PATCH net 2/2] dpaa_eth: fix usage as DSA master, try 4
From: Vladimir Oltean @ 2020-06-16 15:12 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: andrew@lunn.ch, davem@davemloft.net, fido_max@inbox.ru,
vivien.didelot@gmail.com, linux-kernel@vger.kernel.org,
f.fainelli@gmail.com, madalin.bucur@oss.nxp.com,
netdev@vger.kernel.org
In-Reply-To: <CA+h21hqyV5RMip8etVvSWpQU0scPpXDNbMJgP9piXrn1maSMbw@mail.gmail.com>
On Tue, 16 Jun 2020 at 18:08, Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Tue, 16 Jun 2020 at 18:04, Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com> wrote:
> >
> > On Tue, 2020-06-16 at 17:56 +0300, Vladimir Oltean wrote:
> > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> > >
> > >
> > > Hi Joakim,
> > >
> > > On Tue, 16 Jun 2020 at 17:51, Joakim Tjernlund
> > > <Joakim.Tjernlund@infinera.com> wrote:
> > > > On Tue, 2020-06-16 at 17:41 +0300, Vladimir Oltean wrote:
> > > > > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > > >
> > > > > The dpaa-eth driver probes on compatible string for the MAC node, and
> > > > > the fman/mac.c driver allocates a dpaa-ethernet platform device that
> > > > > triggers the probing of the dpaa-eth net device driver.
> > > > >
> > > > > All of this is fine, but the problem is that the struct device of the
> > > > > dpaa_eth net_device is 2 parents away from the MAC which can be
> > > > > referenced via of_node. So of_find_net_device_by_node can't find it, and
> > > > > DSA switches won't be able to probe on top of FMan ports.
> > > > >
> > > > > It would be a bit silly to modify a core function
> > > > > (of_find_net_device_by_node) to look for dev->parent->parent->of_node
> > > > > just for one driver. We're just 1 step away from implementing full
> > > > > recursion.
> > > > >
> > > > > On T1040, the /sys/class/net/eth0 symlink currently points to:
> > > > >
> > > > > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> > > >
> > > > Just want to point out that on 4.19.x, the above patch still exists:
> > > > cd /sys
> > > > find -name eth0
> > > > ./devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> > > > ./class/net/eth
> > > >
> > >
> > > By 'current' I mean 'the net tree just before this patch is applied',
> > > i.e. a v5.7 tree with "dpaa_eth: fix usage as DSA master, try 3"
> > > reverted.
> >
> > Confused, with patch reverted(and DSA working) in 4.19, I have
> > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> > Is that the wanted path? Because I figured you wanted to change it to the path further down in this email?
> >
> > Jocke
> > >
>
> Yes, this is the wanted path.
> The path is fine for anything below commit 060ad66f9795 ("dpaa_eth:
> change DMA device"), including your v4.19.y, that's the point. By
> specifying that commit in the Fixes: tag, people who deal with
> backporting to stable trees know to not backport it below that commit.
> So your stable tree will only get the revert patch.
>
> -Vladimir
Oh, sorry, now I see what you were saying. The paths are reversed in
the commit description. It should be:
Good:
../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
Bad:
../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0
So I need to spin another version.
Sorry for the confusion.
-Vladimir
^ permalink raw reply
* Re: [PATCH bpf] xdp: handle frame_sz in xdp_convert_zc_to_xdp_frame()
From: Jesper Dangaard Brouer @ 2020-06-16 15:12 UTC (permalink / raw)
To: Hangbin Liu
Cc: netdev, bpf, Toke Høiland-Jørgensen, Daniel Borkmann,
Alexei Starovoitov, brouer
In-Reply-To: <20200616103518.2963410-1-liuhangbin@gmail.com>
On Tue, 16 Jun 2020 18:35:18 +0800
Hangbin Liu <liuhangbin@gmail.com> wrote:
> In commit 34cc0b338a61 we only handled the frame_sz in convert_to_xdp_frame().
> This patch will also handle frame_sz in xdp_convert_zc_to_xdp_frame().
>
> Fixes: 34cc0b338a61 ("xdp: Xdp_frame add member frame_sz and handle in convert_to_xdp_frame")
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Thanks for spotting and fixing this! :-)
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> net/core/xdp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 90f44f382115..3c45f99e26d5 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -462,6 +462,7 @@ struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
> xdpf->len = totsize - metasize;
> xdpf->headroom = 0;
> xdpf->metasize = metasize;
> + xdpf->frame_sz = PAGE_SIZE;
> xdpf->mem.type = MEM_TYPE_PAGE_ORDER0;
>
> xsk_buff_free(xdp);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net 2/2] dpaa_eth: fix usage as DSA master, try 4
From: Vladimir Oltean @ 2020-06-16 15:08 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: andrew@lunn.ch, davem@davemloft.net, fido_max@inbox.ru,
vivien.didelot@gmail.com, linux-kernel@vger.kernel.org,
f.fainelli@gmail.com, madalin.bucur@oss.nxp.com,
netdev@vger.kernel.org
In-Reply-To: <d02301e1e7fa9bee3486ea8b9e3d445863bf49c8.camel@infinera.com>
On Tue, 16 Jun 2020 at 18:04, Joakim Tjernlund
<Joakim.Tjernlund@infinera.com> wrote:
>
> On Tue, 2020-06-16 at 17:56 +0300, Vladimir Oltean wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> >
> > Hi Joakim,
> >
> > On Tue, 16 Jun 2020 at 17:51, Joakim Tjernlund
> > <Joakim.Tjernlund@infinera.com> wrote:
> > > On Tue, 2020-06-16 at 17:41 +0300, Vladimir Oltean wrote:
> > > > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > >
> > > > The dpaa-eth driver probes on compatible string for the MAC node, and
> > > > the fman/mac.c driver allocates a dpaa-ethernet platform device that
> > > > triggers the probing of the dpaa-eth net device driver.
> > > >
> > > > All of this is fine, but the problem is that the struct device of the
> > > > dpaa_eth net_device is 2 parents away from the MAC which can be
> > > > referenced via of_node. So of_find_net_device_by_node can't find it, and
> > > > DSA switches won't be able to probe on top of FMan ports.
> > > >
> > > > It would be a bit silly to modify a core function
> > > > (of_find_net_device_by_node) to look for dev->parent->parent->of_node
> > > > just for one driver. We're just 1 step away from implementing full
> > > > recursion.
> > > >
> > > > On T1040, the /sys/class/net/eth0 symlink currently points to:
> > > >
> > > > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> > >
> > > Just want to point out that on 4.19.x, the above patch still exists:
> > > cd /sys
> > > find -name eth0
> > > ./devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> > > ./class/net/eth
> > >
> >
> > By 'current' I mean 'the net tree just before this patch is applied',
> > i.e. a v5.7 tree with "dpaa_eth: fix usage as DSA master, try 3"
> > reverted.
>
> Confused, with patch reverted(and DSA working) in 4.19, I have
> ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> Is that the wanted path? Because I figured you wanted to change it to the path further down in this email?
>
> Jocke
> >
Yes, this is the wanted path.
The path is fine for anything below commit 060ad66f9795 ("dpaa_eth:
change DMA device"), including your v4.19.y, that's the point. By
specifying that commit in the Fixes: tag, people who deal with
backporting to stable trees know to not backport it below that commit.
So your stable tree will only get the revert patch.
-Vladimir
^ permalink raw reply
* [PATCH net] ionic: export features for vlans to use
From: Shannon Nelson @ 2020-06-16 15:06 UTC (permalink / raw)
To: netdev, davem; +Cc: Shannon Nelson
Set up vlan_features for use by any vlans above us.
Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support")
Signed-off-by: Shannon Nelson <snelson@pensando.io>
---
drivers/net/ethernet/pensando/ionic/ionic_lif.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.c b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
index bfadc4934702..8f29ef133743 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
+++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
@@ -1246,6 +1246,7 @@ static int ionic_init_nic_features(struct ionic_lif *lif)
netdev->hw_features |= netdev->hw_enc_features;
netdev->features |= netdev->hw_features;
+ netdev->vlan_features |= netdev->features & ~NETIF_F_VLAN_FEATURES;
netdev->priv_flags |= IFF_UNICAST_FLT |
IFF_LIVE_ADDR_CHANGE;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 2/3] mm, treewide: Rename kzfree() to kfree_sensitive()
From: Waiman Long @ 2020-06-16 15:05 UTC (permalink / raw)
To: Dan Carpenter
Cc: Andrew Morton, David Howells, Jarkko Sakkinen, James Morris,
Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox,
David Rientjes, Michal Hocko, Johannes Weiner, David Sterba,
Jason A . Donenfeld, linux-mm, keyrings, linux-kernel,
linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200616142624.GO4282@kadam>
On 6/16/20 10:26 AM, Dan Carpenter wrote:
> Last time you sent this we couldn't decide which tree it should go
> through. Either the crypto tree or through Andrew seems like the right
> thing to me.
>
> Also the other issue is that it risks breaking things if people add
> new kzfree() instances while we are doing the transition. Could you
> just add a "#define kzfree kfree_sensitive" so that things continue to
> compile and we can remove it in the next kernel release?
>
> regards,
> dan carpenter
>
Yes, that make sure sense. Will send out v5 later today.
Cheers,
Longman
^ permalink raw reply
* Re: [PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()
From: Waiman Long @ 2020-06-16 15:05 UTC (permalink / raw)
To: dsterba, Andrew Morton, David Howells, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, Linus Torvalds, Joe Perches,
Matthew Wilcox, David Rientjes, Michal Hocko, Johannes Weiner,
Dan Carpenter, Jason A . Donenfeld, linux-mm, keyrings,
linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200616144804.GD27795@twin.jikos.cz>
On 6/16/20 10:48 AM, David Sterba wrote:
> On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
>> In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
>> was incorrectly paired with kzfree(). According to David Sterba, there
>> isn't any sensitive information in the subvol_info that needs to be
>> cleared before freeing. So kfree_sensitive() isn't really needed,
>> use kfree() instead.
>>
>> Reported-by: David Sterba <dsterba@suse.cz>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> fs/btrfs/ioctl.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
>> index f1dd9e4271e9..e8f7c5f00894 100644
>> --- a/fs/btrfs/ioctl.c
>> +++ b/fs/btrfs/ioctl.c
>> @@ -2692,7 +2692,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp)
>> btrfs_put_root(root);
>> out_free:
>> btrfs_free_path(path);
>> - kfree_sensitive(subvol_info);
>> + kfree(subvol_info);
> I would rather merge a patch doing to kzfree -> kfree instead of doing
> the middle step to switch it to kfree_sensitive. If it would help
> integration of your patchset I can push it to the next rc so there are
> no kzfree left in the btrfs code. Treewide change like that can take
> time so it would be one less problem to care about for you.
>
Sure, I will move it forward in the patch series.
Thanks,
Longman
^ permalink raw reply
* Re: linux-next: build failures after merge of the vfs tree
From: Herbert Xu @ 2020-06-16 14:38 UTC (permalink / raw)
To: Al Viro
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, netdev
In-Reply-To: <20200616033849.GL23230@ZenIV.linux.org.uk>
On Tue, Jun 16, 2020 at 04:38:49AM +0100, Al Viro wrote:
>
> Folded and pushed
Thanks Al. Here's another one that I just got, could you add this
one too?
diff --git a/drivers/mtd/nand/raw/cadence-nand-controller.c b/drivers/mtd/nand/raw/cadence-nand-controller.c
index c405722adfe1..c4f273e2fe78 100644
--- a/drivers/mtd/nand/raw/cadence-nand-controller.c
+++ b/drivers/mtd/nand/raw/cadence-nand-controller.c
@@ -17,6 +17,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/of_device.h>
#include <linux/iopoll.h>
+#include <linux/slab.h>
/*
* HPNFC can work in 3 modes:
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH net 2/2] dpaa_eth: fix usage as DSA master, try 4
From: Joakim Tjernlund @ 2020-06-16 15:04 UTC (permalink / raw)
To: olteanv@gmail.com
Cc: andrew@lunn.ch, davem@davemloft.net, fido_max@inbox.ru,
vivien.didelot@gmail.com, linux-kernel@vger.kernel.org,
f.fainelli@gmail.com, madalin.bucur@oss.nxp.com,
netdev@vger.kernel.org
In-Reply-To: <CA+h21hoz_LJgvCiVeuPTUVHN2Nu9wWAVnzz9GS2bo=y+Y1hLJA@mail.gmail.com>
On Tue, 2020-06-16 at 17:56 +0300, Vladimir Oltean wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Hi Joakim,
>
> On Tue, 16 Jun 2020 at 17:51, Joakim Tjernlund
> <Joakim.Tjernlund@infinera.com> wrote:
> > On Tue, 2020-06-16 at 17:41 +0300, Vladimir Oltean wrote:
> > > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> > >
> > > The dpaa-eth driver probes on compatible string for the MAC node, and
> > > the fman/mac.c driver allocates a dpaa-ethernet platform device that
> > > triggers the probing of the dpaa-eth net device driver.
> > >
> > > All of this is fine, but the problem is that the struct device of the
> > > dpaa_eth net_device is 2 parents away from the MAC which can be
> > > referenced via of_node. So of_find_net_device_by_node can't find it, and
> > > DSA switches won't be able to probe on top of FMan ports.
> > >
> > > It would be a bit silly to modify a core function
> > > (of_find_net_device_by_node) to look for dev->parent->parent->of_node
> > > just for one driver. We're just 1 step away from implementing full
> > > recursion.
> > >
> > > On T1040, the /sys/class/net/eth0 symlink currently points to:
> > >
> > > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> >
> > Just want to point out that on 4.19.x, the above patch still exists:
> > cd /sys
> > find -name eth0
> > ./devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> > ./class/net/eth
> >
>
> By 'current' I mean 'the net tree just before this patch is applied',
> i.e. a v5.7 tree with "dpaa_eth: fix usage as DSA master, try 3"
> reverted.
Confused, with patch reverted(and DSA working) in 4.19, I have
../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
Is that the wanted path? Because I figured you wanted to change it to the path further down in this email?
Jocke
>
> > > which pretty much illustrates the problem. The closest of_node we've got
> > > is the "fsl,fman-memac" at /soc@ffe000000/fman@400000/ethernet@e6000,
> > > which is what we'd like to be able to reference from DSA as host port.
> > >
> > > For of_find_net_device_by_node to find the eth0 port, we would need the
> > > parent of the eth0 net_device to not be the "dpaa-ethernet" platform
> > > device, but to point 1 level higher, aka the "fsl,fman-memac" node
> > > directly. The new sysfs path would look like this:
> > >
> > > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0
> > >
> > > Actually this has worked before, through the SET_NETDEV_DEV mechanism,
> > > which sets the parent of the net_device as the parent of the platform
> > > device. But the device which was set as sysfs parent was inadvertently
> > > changed through commit 060ad66f9795 ("dpaa_eth: change DMA device"),
> > > which did not take into consideration the effect it would have upon
> > > of_find_net_device_by_node. So restore the old sysfs parent to make that
> > > work correctly.
> > >
> > > Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > ---
> > > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > index c4416a5f8816..2972244e6eb0 100644
> > > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > > @@ -2914,7 +2914,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
> > > }
> > >
> > > /* Do this here, so we can be verbose early */
> > > - SET_NETDEV_DEV(net_dev, dev);
> > > + SET_NETDEV_DEV(net_dev, dev->parent);
> > > dev_set_drvdata(dev, net_dev);
> > >
> > > priv = netdev_priv(net_dev);
> > > --
> > > 2.25.1
> > >
>
> Thanks,
> -Vladimir
^ permalink raw reply
* Re: [Patch net] net: change addr_list_lock back to static key
From: Taehee Yoo @ 2020-06-16 15:03 UTC (permalink / raw)
To: Cong Wang; +Cc: Netdev, syzbot+f3a0e80c34b3fc28ac5e, Dmitry Vyukov
In-Reply-To: <CAM_iQpVpiujEgTc0WEfESPSa-DmqyObSycQ+S2Eve53eK6AD_g@mail.gmail.com>
On Tue, 16 Jun 2020 at 06:33, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
Hi Cong,
> On Sat, Jun 13, 2020 at 9:03 AM Taehee Yoo <ap420073@gmail.com> wrote:
> >
> > On Thu, 11 Jun 2020 at 08:21, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > >
> >
> > Hi Cong :)
> >
> > > On Wed, Jun 10, 2020 at 7:48 AM Taehee Yoo <ap420073@gmail.com> wrote:
> > > >
> > > > On Tue, 9 Jun 2020 at 06:53, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > > > >
> > > > > + lockdep_set_class_and_subclass(&dev->addr_list_lock,
> > > > > + &vlan_netdev_addr_lock_key,
> > > > > + subclass);
> >
> > In this patch, lockdep_set_class_and_subclass() is used.
> > As far as I know, this function initializes lockdep key and subclass
> > value with a given variable.
> > A dev->lower_level variable is used as a subclass value in this patch.
> > When dev->lower_level value is changed, the subclass value of this
> > lockdep key is not changed automatically.
> > If this value has to be changed, additional function is needed.
>
> Hmm, but we pass a dynamic subclass to spin_lock_nested().
>
> So I guess I should just remove all the
> lockdep_set_class_and_subclass() and leave subclass to 0?
>
I agree with that.
And, do you have any plan to replace netif_addr_lock_bh() with
netif_addr_lock_nested()?
(Of course, it needs BH handling code)
I'm not sure but I think it would be needed.
> >
> > >>> netif_addr_lock_bh(from);
> > In this function, internally spin_lock_bh() is used and this function
> > might use an 'initialized subclass value' not a current dev->lower_level.
> > At this point, I think the lockdep splat might occur.
> >
> > +static inline void netif_addr_lock_nested(struct net_device *dev)
> > +{
> > + spin_lock_nested(&dev->addr_list_lock, dev->lower_level);
> > +}
> > In this patch, you used netif_addr_lock_nested() too.
> > These two subclass values could be different.
> > But I'm not sure whether using spin_lock_nested with two different
> > subclass values are the right way or not.
>
> Yeah, as long as dev->lower_level is different, it should be different
> subclass. I assume dev->lower_level is automatically adjusted
> whenever the topology changes, like the vlan over bond case above.
>
Yes, you're right.
Thanks!
Taehee Yoo
^ permalink raw reply
* Re: [PATCH net v2 2/2] net/sched: act_gate: fix configuration of the periodic timer
From: Davide Caratti @ 2020-06-16 14:58 UTC (permalink / raw)
To: Vladimir Oltean; +Cc: Po Liu, Cong Wang, David S . Miller, netdev
In-Reply-To: <CA+h21hpL+7tuEX7_NCNo7NdgZ1OYqjQ03=DHuZ3aOOKh6Z4tsw@mail.gmail.com>
On Tue, 2020-06-16 at 17:23 +0300, Vladimir Oltean wrote:
> > (but again, this would be a fix for 'entries' - not for 'hitimer', so I
> > plan to work on it as a separate patch, that fits better 'net-next' rather
> > than 'net').
>
> Targeting net-next would mean that the net tree would still keep
> appending to p->entries upon action replacement, instead of just
> replacing p->entries?
well, this is the original act_gate behavior (and the bug is discovered
today, in this thread). But if users can't wait for the proper fix (and
equally important, for the tdc test file), I can think of sending the
patch directly for 'net'.
--
davide
^ permalink raw reply
* Re: [PATCH v4 08/11] selftests/seccomp: Make kcmp() less required
From: Tycho Andersen @ 2020-06-16 14:57 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Sargun Dhillon, Christian Brauner, David S. Miller,
Christoph Hellwig, Jakub Kicinski, Alexander Viro, Aleksa Sarai,
Matt Denton, Jann Horn, Chris Palmer, Robert Sesek,
Giuseppe Scrivano, Greg Kroah-Hartman, Andy Lutomirski,
Will Drewry, Shuah Khan, netdev, containers, linux-api,
linux-fsdevel, linux-kselftest
In-Reply-To: <20200616032524.460144-9-keescook@chromium.org>
On Mon, Jun 15, 2020 at 08:25:21PM -0700, Kees Cook wrote:
> The seccomp tests are a bit noisy without CONFIG_CHECKPOINT_RESTORE (due
> to missing the kcmp() syscall). The seccomp tests are more accurate with
> kcmp(), but it's not strictly required. Refactor the tests to use
> alternatives (comparing fd numbers), and provide a central test for
> kcmp() so there is a single XFAIL instead of many. Continue to produce
> warnings for the other tests, though.
>
> Additionally adds some more bad flag EINVAL tests to the addfd selftest.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
This looks fine, but I wonder if this is enough motivation for taking
kcmp() out of CONFIG_CHECKPOINT_RESTORE guards?
Tycho
^ permalink raw reply
* Re: [PATCH v4 09/11] selftests/seccomp: Rename user_trap_syscall() to user_notif_syscall()
From: Tycho Andersen @ 2020-06-16 14:56 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Sargun Dhillon, Christian Brauner, David S. Miller,
Christoph Hellwig, Jakub Kicinski, Alexander Viro, Aleksa Sarai,
Matt Denton, Jann Horn, Chris Palmer, Robert Sesek,
Giuseppe Scrivano, Greg Kroah-Hartman, Andy Lutomirski,
Will Drewry, Shuah Khan, netdev, containers, linux-api,
linux-fsdevel, linux-kselftest
In-Reply-To: <20200616032524.460144-10-keescook@chromium.org>
On Mon, Jun 15, 2020 at 08:25:22PM -0700, Kees Cook wrote:
> The user_trap_syscall() helper creates a filter with
> SECCOMP_RET_USER_NOTIF. To avoid confusion with SECCOMP_RET_TRAP, rename
> the helper to user_notif_syscall().
>
> Additionally fix a redundant "return" after XFAIL.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Tycho Andersen <tycho@tycho.ws>
^ permalink raw reply
* Re: [PATCH net 2/2] dpaa_eth: fix usage as DSA master, try 4
From: Vladimir Oltean @ 2020-06-16 14:56 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: davem@davemloft.net, vivien.didelot@gmail.com,
madalin.bucur@oss.nxp.com, fido_max@inbox.ru,
netdev@vger.kernel.org, f.fainelli@gmail.com, andrew@lunn.ch,
linux-kernel@vger.kernel.org
In-Reply-To: <acb765da28bde4dff4fc2cd9ea661fa1b3486947.camel@infinera.com>
Hi Joakim,
On Tue, 16 Jun 2020 at 17:51, Joakim Tjernlund
<Joakim.Tjernlund@infinera.com> wrote:
>
> On Tue, 2020-06-16 at 17:41 +0300, Vladimir Oltean wrote:
> > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> >
> > The dpaa-eth driver probes on compatible string for the MAC node, and
> > the fman/mac.c driver allocates a dpaa-ethernet platform device that
> > triggers the probing of the dpaa-eth net device driver.
> >
> > All of this is fine, but the problem is that the struct device of the
> > dpaa_eth net_device is 2 parents away from the MAC which can be
> > referenced via of_node. So of_find_net_device_by_node can't find it, and
> > DSA switches won't be able to probe on top of FMan ports.
> >
> > It would be a bit silly to modify a core function
> > (of_find_net_device_by_node) to look for dev->parent->parent->of_node
> > just for one driver. We're just 1 step away from implementing full
> > recursion.
> >
> > On T1040, the /sys/class/net/eth0 symlink currently points to:
> >
> > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
>
> Just want to point out that on 4.19.x, the above patch still exists:
> cd /sys
> find -name eth0
> ./devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
> ./class/net/eth
>
By 'current' I mean 'the net tree just before this patch is applied',
i.e. a v5.7 tree with "dpaa_eth: fix usage as DSA master, try 3"
reverted.
> >
> > which pretty much illustrates the problem. The closest of_node we've got
> > is the "fsl,fman-memac" at /soc@ffe000000/fman@400000/ethernet@e6000,
> > which is what we'd like to be able to reference from DSA as host port.
> >
> > For of_find_net_device_by_node to find the eth0 port, we would need the
> > parent of the eth0 net_device to not be the "dpaa-ethernet" platform
> > device, but to point 1 level higher, aka the "fsl,fman-memac" node
> > directly. The new sysfs path would look like this:
> >
> > ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0
> >
> > Actually this has worked before, through the SET_NETDEV_DEV mechanism,
> > which sets the parent of the net_device as the parent of the platform
> > device. But the device which was set as sysfs parent was inadvertently
> > changed through commit 060ad66f9795 ("dpaa_eth: change DMA device"),
> > which did not take into consideration the effect it would have upon
> > of_find_net_device_by_node. So restore the old sysfs parent to make that
> > work correctly.
> >
> > Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > ---
> > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > index c4416a5f8816..2972244e6eb0 100644
> > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > @@ -2914,7 +2914,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
> > }
> >
> > /* Do this here, so we can be verbose early */
> > - SET_NETDEV_DEV(net_dev, dev);
> > + SET_NETDEV_DEV(net_dev, dev->parent);
> > dev_set_drvdata(dev, net_dev);
> >
> > priv = netdev_priv(net_dev);
> > --
> > 2.25.1
> >
>
Thanks,
-Vladimir
^ permalink raw reply
* Re: [PATCH v4 10/11] seccomp: Switch addfd to Extensible Argument ioctl
From: Tycho Andersen @ 2020-06-16 14:55 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Sargun Dhillon, Christian Brauner, David S. Miller,
Christoph Hellwig, Jakub Kicinski, Alexander Viro, Aleksa Sarai,
Matt Denton, Jann Horn, Chris Palmer, Robert Sesek,
Giuseppe Scrivano, Greg Kroah-Hartman, Andy Lutomirski,
Will Drewry, Shuah Khan, netdev, containers, linux-api,
linux-fsdevel, linux-kselftest
In-Reply-To: <20200616032524.460144-11-keescook@chromium.org>
On Mon, Jun 15, 2020 at 08:25:23PM -0700, Kees Cook wrote:
> This patch is based on discussions[1] with Sargun Dhillon, Christian
> Brauner, and David Laight. Instead of building size into the addfd
> structure, make it a function of the ioctl command (which is how sizes are
> normally passed to ioctls). To support forward and backward compatibility,
> just mask out the direction and size, and match everything. The size (and
> any future direction) checks are done along with copy_struct_from_user()
> logic. Also update the selftests to check size bounds.
>
> [1] https://lore.kernel.org/lkml/20200612104629.GA15814@ircssh-2.c.rugged-nimbus-611.internal
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> include/uapi/linux/seccomp.h | 2 -
> kernel/seccomp.c | 21 ++++++----
> tools/testing/selftests/seccomp/seccomp_bpf.c | 40 ++++++++++++++++---
> 3 files changed, 49 insertions(+), 14 deletions(-)
>
> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> index c347160378e5..473a61695ac3 100644
> --- a/include/uapi/linux/seccomp.h
> +++ b/include/uapi/linux/seccomp.h
> @@ -118,7 +118,6 @@ struct seccomp_notif_resp {
>
> /**
> * struct seccomp_notif_addfd
> - * @size: The size of the seccomp_notif_addfd structure
> * @id: The ID of the seccomp notification
> * @flags: SECCOMP_ADDFD_FLAG_*
> * @srcfd: The local fd number
> @@ -126,7 +125,6 @@ struct seccomp_notif_resp {
> * @newfd_flags: The O_* flags the remote FD should have applied
> */
> struct seccomp_notif_addfd {
> - __u64 size;
Huh? Won't this break builds?
Tycho
^ permalink raw reply
* Re: [PATCH 01/02] net: phy: marvell: Add Marvell 88E1340 support
From: Andrew Lunn @ 2020-06-16 14:54 UTC (permalink / raw)
To: Maxim Kochetkov; +Cc: netdev, f.fainelli, hkallweit1, linux
In-Reply-To: <3fcbc447-877d-0e95-af39-86fc72a34e10@inbox.ru>
On Tue, Jun 16, 2020 at 10:01:11AM +0300, Maxim Kochetkov wrote:
> Add Marvell 88E1340 support
Hi Maxim
Are you sure this is an 88E1340, not a 88E1340S?
Marvells DSDT SDK has:
MAD_88E1340S = 0x1C, /* 88E1340S */
MAD_88E1340 = 0x1e, /* 88E1340/x0a */
MAD_88E1340M = 0x1f, /* 88E1340M/x0a */
> #define MARVELL_PHY_ID_88E1149R 0x01410e50
> #define MARVELL_PHY_ID_88E1240 0x01410e30
> #define MARVELL_PHY_ID_88E1318S 0x01410e90
> +#define MARVELL_PHY_ID_88E1340 0x01410dc0
> #define MARVELL_PHY_ID_88E1116R 0x01410e40
> #define MARVELL_PHY_ID_88E1510 0x01410dd0
> #define MARVELL_PHY_ID_88E1540 0x01410eb0
For 88E1340 i would expect the ID to be 0x01410de0
Andrew
^ permalink raw reply
* Re: [PATCH] e1000e: add ifdef to avoid dead code
From: Eric Dumazet @ 2020-06-16 14:53 UTC (permalink / raw)
To: Greg Thelen, Jeff Kirsher, David S. Miller, Jakub Kicinski,
Vitaly Lifshits
Cc: intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20200614061122.35928-1-gthelen@google.com>
On 6/13/20 11:11 PM, Greg Thelen wrote:
> Commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> systems") added e1000e_check_me() but it's only called from
> CONFIG_PM_SLEEP protected code. Thus builds without CONFIG_PM_SLEEP
> see:
> drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning: 'e1000e_check_me' defined but not used [-Wunused-function]
>
> Add CONFIG_PM_SLEEP ifdef guard to avoid dead code.
>
> Fixes: e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
> Signed-off-by: Greg Thelen <gthelen@google.com>
> ---
> drivers/net/ethernet/intel/e1000e/netdev.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks Greg
^ permalink raw reply
* Re: [PATCH net 2/2] dpaa_eth: fix usage as DSA master, try 4
From: Joakim Tjernlund @ 2020-06-16 14:51 UTC (permalink / raw)
To: olteanv@gmail.com, davem@davemloft.net
Cc: vivien.didelot@gmail.com, madalin.bucur@oss.nxp.com,
fido_max@inbox.ru, netdev@vger.kernel.org, f.fainelli@gmail.com,
andrew@lunn.ch, linux-kernel@vger.kernel.org
In-Reply-To: <20200616144118.3902244-3-olteanv@gmail.com>
On Tue, 2020-06-16 at 17:41 +0300, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> The dpaa-eth driver probes on compatible string for the MAC node, and
> the fman/mac.c driver allocates a dpaa-ethernet platform device that
> triggers the probing of the dpaa-eth net device driver.
>
> All of this is fine, but the problem is that the struct device of the
> dpaa_eth net_device is 2 parents away from the MAC which can be
> referenced via of_node. So of_find_net_device_by_node can't find it, and
> DSA switches won't be able to probe on top of FMan ports.
>
> It would be a bit silly to modify a core function
> (of_find_net_device_by_node) to look for dev->parent->parent->of_node
> just for one driver. We're just 1 step away from implementing full
> recursion.
>
> On T1040, the /sys/class/net/eth0 symlink currently points to:
>
> ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
Just want to point out that on 4.19.x, the above patch still exists:
cd /sys
find -name eth0
./devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
./class/net/eth
>
> which pretty much illustrates the problem. The closest of_node we've got
> is the "fsl,fman-memac" at /soc@ffe000000/fman@400000/ethernet@e6000,
> which is what we'd like to be able to reference from DSA as host port.
>
> For of_find_net_device_by_node to find the eth0 port, we would need the
> parent of the eth0 net_device to not be the "dpaa-ethernet" platform
> device, but to point 1 level higher, aka the "fsl,fman-memac" node
> directly. The new sysfs path would look like this:
>
> ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0
>
> Actually this has worked before, through the SET_NETDEV_DEV mechanism,
> which sets the parent of the net_device as the parent of the platform
> device. But the device which was set as sysfs parent was inadvertently
> changed through commit 060ad66f9795 ("dpaa_eth: change DMA device"),
> which did not take into consideration the effect it would have upon
> of_find_net_device_by_node. So restore the old sysfs parent to make that
> work correctly.
>
> Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index c4416a5f8816..2972244e6eb0 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2914,7 +2914,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
> }
>
> /* Do this here, so we can be verbose early */
> - SET_NETDEV_DEV(net_dev, dev);
> + SET_NETDEV_DEV(net_dev, dev->parent);
> dev_set_drvdata(dev, net_dev);
>
> priv = netdev_priv(net_dev);
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v4 3/3] btrfs: Use kfree() in btrfs_ioctl_get_subvol_info()
From: David Sterba @ 2020-06-16 14:48 UTC (permalink / raw)
To: Waiman Long
Cc: Andrew Morton, David Howells, Jarkko Sakkinen, James Morris,
Serge E. Hallyn, Linus Torvalds, Joe Perches, Matthew Wilcox,
David Rientjes, Michal Hocko, Johannes Weiner, Dan Carpenter,
David Sterba, Jason A . Donenfeld, linux-mm, keyrings,
linux-kernel, linux-crypto, linux-pm, linux-stm32, linux-amlogic,
linux-mediatek, linuxppc-dev, virtualization, netdev, linux-ppp,
wireguard, linux-wireless, devel, linux-scsi, target-devel,
linux-btrfs, linux-cifs, linux-fscrypt, ecryptfs, kasan-dev,
linux-bluetooth, linux-wpan, linux-sctp, linux-nfs,
tipc-discussion, linux-security-module, linux-integrity
In-Reply-To: <20200616015718.7812-4-longman@redhat.com>
On Mon, Jun 15, 2020 at 09:57:18PM -0400, Waiman Long wrote:
> In btrfs_ioctl_get_subvol_info(), there is a classic case where kzalloc()
> was incorrectly paired with kzfree(). According to David Sterba, there
> isn't any sensitive information in the subvol_info that needs to be
> cleared before freeing. So kfree_sensitive() isn't really needed,
> use kfree() instead.
>
> Reported-by: David Sterba <dsterba@suse.cz>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> fs/btrfs/ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index f1dd9e4271e9..e8f7c5f00894 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2692,7 +2692,7 @@ static int btrfs_ioctl_get_subvol_info(struct file *file, void __user *argp)
> btrfs_put_root(root);
> out_free:
> btrfs_free_path(path);
> - kfree_sensitive(subvol_info);
> + kfree(subvol_info);
I would rather merge a patch doing to kzfree -> kfree instead of doing
the middle step to switch it to kfree_sensitive. If it would help
integration of your patchset I can push it to the next rc so there are
no kzfree left in the btrfs code. Treewide change like that can take
time so it would be one less problem to care about for you.
^ permalink raw reply
* [PATCH net 1/2] Revert "dpaa_eth: fix usage as DSA master, try 3"
From: Vladimir Oltean @ 2020-06-16 14:41 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, joakim.tjernlund,
madalin.bucur, fido_max, linux-kernel
In-Reply-To: <20200616144118.3902244-1-olteanv@gmail.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
This reverts commit 5d14c304bfc14b4fd052dc83d5224376b48f52f0.
The Fixes: tag was incorrect, and it was subsequently backported to the
incorrect stable trees, breaking them.
Reported-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 2972244e6eb0..c4416a5f8816 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2914,7 +2914,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
}
/* Do this here, so we can be verbose early */
- SET_NETDEV_DEV(net_dev, dev->parent);
+ SET_NETDEV_DEV(net_dev, dev);
dev_set_drvdata(dev, net_dev);
priv = netdev_priv(net_dev);
--
2.25.1
^ permalink raw reply related
* [PATCH net 2/2] dpaa_eth: fix usage as DSA master, try 4
From: Vladimir Oltean @ 2020-06-16 14:41 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, joakim.tjernlund,
madalin.bucur, fido_max, linux-kernel
In-Reply-To: <20200616144118.3902244-1-olteanv@gmail.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
The dpaa-eth driver probes on compatible string for the MAC node, and
the fman/mac.c driver allocates a dpaa-ethernet platform device that
triggers the probing of the dpaa-eth net device driver.
All of this is fine, but the problem is that the struct device of the
dpaa_eth net_device is 2 parents away from the MAC which can be
referenced via of_node. So of_find_net_device_by_node can't find it, and
DSA switches won't be able to probe on top of FMan ports.
It would be a bit silly to modify a core function
(of_find_net_device_by_node) to look for dev->parent->parent->of_node
just for one driver. We're just 1 step away from implementing full
recursion.
On T1040, the /sys/class/net/eth0 symlink currently points to:
../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0
which pretty much illustrates the problem. The closest of_node we've got
is the "fsl,fman-memac" at /soc@ffe000000/fman@400000/ethernet@e6000,
which is what we'd like to be able to reference from DSA as host port.
For of_find_net_device_by_node to find the eth0 port, we would need the
parent of the eth0 net_device to not be the "dpaa-ethernet" platform
device, but to point 1 level higher, aka the "fsl,fman-memac" node
directly. The new sysfs path would look like this:
../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0
Actually this has worked before, through the SET_NETDEV_DEV mechanism,
which sets the parent of the net_device as the parent of the platform
device. But the device which was set as sysfs parent was inadvertently
changed through commit 060ad66f9795 ("dpaa_eth: change DMA device"),
which did not take into consideration the effect it would have upon
of_find_net_device_by_node. So restore the old sysfs parent to make that
work correctly.
Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index c4416a5f8816..2972244e6eb0 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2914,7 +2914,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
}
/* Do this here, so we can be verbose early */
- SET_NETDEV_DEV(net_dev, dev);
+ SET_NETDEV_DEV(net_dev, dev->parent);
dev_set_drvdata(dev, net_dev);
priv = netdev_priv(net_dev);
--
2.25.1
^ permalink raw reply related
* [PATCH net 0/2] Reapply DSA fix for dpaa-eth with proper Fixes: tag
From: Vladimir Oltean @ 2020-06-16 14:41 UTC (permalink / raw)
To: davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, joakim.tjernlund,
madalin.bucur, fido_max, linux-kernel
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Joakim notified me that this breaks stable trees.
It turns out that my assessment about who-broke-who was wrong.
The real Fixes: tag should have been:
Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
which changes the device on which SET_NETDEV_DEV is made.
git describe --tags 060ad66f97954
v5.4-rc3-783-g060ad66f9795
Which means that it shouldn't have been backported to 4.19 and below.
This series reverts the commit with the misleading commit message, and
reapplies it with a corrected one. The resulting code is exactly the
same, but now, the revert should make it to the stable trees (along with
the bad fix), and the new fix should only make it down to v5.4.y.
Vladimir Oltean (2):
Revert "dpaa_eth: fix usage as DSA master, try 3"
dpaa_eth: fix usage as DSA master, try 4
--
2.25.1
^ permalink raw reply
* Re: [PATCHv4 bpf-next 1/2] xdp: add a new helper for dev map multicast support
From: Jesper Dangaard Brouer @ 2020-06-16 14:38 UTC (permalink / raw)
To: Hangbin Liu
Cc: bpf, netdev, Toke Høiland-Jørgensen, Jiri Benc,
Eelco Chaudron, ast, Daniel Borkmann, Lorenzo Bianconi, brouer
In-Reply-To: <20200616101133.GV102436@dhcp-12-153.nay.redhat.com>
On Tue, 16 Jun 2020 18:11:33 +0800
Hangbin Liu <liuhangbin@gmail.com> wrote:
> HI Jesper,
>
> On Tue, Jun 16, 2020 at 10:55:06AM +0200, Jesper Dangaard Brouer wrote:
> > > Is there anything else I should do except add the following line?
> > > nxdpf->mem.type = MEM_TYPE_PAGE_ORDER0;
> >
> > You do realize that you also have copied over the mem.id, right?
>
> Thanks for the reminding. To confirm, set mem.id to 0 is enough, right?
Yes.
> > And as I wrote below you also need to update frame_sz.
> >
> > > >
> > > > You also need to update xdpf->frame_sz, as you also cannot assume it is
> > > > the same.
> > >
> > > Won't the memcpy() copy xdpf->frame_sz to nxdpf?
> >
> > You obviously cannot use the frame_sz from the existing frame, as you
> > just allocated a new page for the new xdp_frame, that have another size
> > (here PAGE_SIZE).
>
> Thanks, I didn't understand the frame_sz correctly before.
> >
> >
> > > And I didn't see xdpf->frame_sz is set in xdp_convert_zc_to_xdp_frame(),
> > > do we need a fix?
> >
> > Good catch, that sounds like a bug, that should be fixed.
> > Will you send a fix?
>
> OK, I will.
Thanks.
> >
> > > > > +
> > > > > + nxdpf = addr;
> > > > > + nxdpf->data = addr + headroom;
> > > > > +
> > > > > + return nxdpf;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(xdpf_clone);
> > > >
> > > >
> > > > struct xdp_frame {
> > > > void *data;
> > > > u16 len;
> > > > u16 headroom;
> > > > u32 metasize:8;
> > > > u32 frame_sz:24;
> > > > /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
> > > > * while mem info is valid on remote CPU.
> > > > */
> > > > struct xdp_mem_info mem;
> > > > struct net_device *dev_rx; /* used by cpumap */
> > > > };
> > > >
> > >
> >
> > struct xdp_mem_info {
> > u32 type; /* 0 4 */
> > u32 id; /* 4 4 */
> >
> > /* size: 8, cachelines: 1, members: 2 */
> > /* last cacheline: 8 bytes */
> > };
> >
>
> Is this a struct reference or you want to remind me something else?
This is just a struct reference to help the readers of this email.
I had to lookup the struct to review this code, so I included it to
save time for other reviewers.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net v3 2/4] flow_offload: fix incorrect cb_priv check for flow_block_cb
From: Simon Horman @ 2020-06-16 14:34 UTC (permalink / raw)
To: wenxu; +Cc: netdev, davem, pablo, vladbu
In-Reply-To: <aee3192c-7664-580b-1f37-9003c91f185b@ucloud.cn>
On Tue, Jun 16, 2020 at 10:20:46PM +0800, wenxu wrote:
>
> 在 2020/6/16 18:51, Simon Horman 写道:
> > On Tue, Jun 16, 2020 at 11:19:38AM +0800, wenxu@ucloud.cn wrote:
> >> From: wenxu <wenxu@ucloud.cn>
> >>
> >> In the function __flow_block_indr_cleanup, The match stataments
> >> this->cb_priv == cb_priv is always false, the flow_block_cb->cb_priv
> >> is totally different data with the flow_indr_dev->cb_priv.
> >>
> >> Store the representor cb_priv to the flow_block_cb->indr.cb_priv in
> >> the driver.
> >>
> >> Fixes: 1fac52da5942 ("net: flow_offload: consolidate indirect flow_block infrastructure")
> >> Signed-off-by: wenxu <wenxu@ucloud.cn>
> > Hi Wenxu,
> >
> > I wonder if this can be resolved by using the cb_ident field of struct
> > flow_block_cb.
> >
> > I observe that mlx5e_rep_indr_setup_block() seems to be the only call-site
> > where the value of the cb_ident parameter of flow_block_cb_alloc() is
> > per-block rather than per-device. So part of my proposal is to change
> > that.
>
> I check all the xxdriver_indr_setup_block. It seems all the cb_ident parameter of
>
> flow_block_cb_alloc is per-block. Both in the nfp_flower_setup_indr_tc_block
>
> and bnxt_tc_setup_indr_block.
>
>
> nfp_flower_setup_indr_tc_block:
>
> struct nfp_flower_indr_block_cb_priv *cb_priv;
>
> block_cb = flow_block_cb_alloc(nfp_flower_setup_indr_block_cb,
> cb_priv, cb_priv,
> nfp_flower_setup_indr_tc_release);
>
>
> bnxt_tc_setup_indr_block:
>
> struct bnxt_flower_indr_block_cb_priv *cb_priv;
>
> block_cb = flow_block_cb_alloc(bnxt_tc_setup_indr_block_cb,
> cb_priv, cb_priv,
> bnxt_tc_setup_indr_rel);
>
>
> And the function flow_block_cb_is_busy called in most place. Pass the
>
> parameter as cb_priv but not cb_indent .
Thanks, I see that now. But I still think it would be useful to understand
the purpose of cb_ident. It feels like it would lead to a clean solution
to the problem you have highlighted.
> > The other part of my proposal is to make use of cb_ident in
> > __flow_block_indr_cleanup(). Which does seem to match the intended
> > purpose of cb_ident. Perhaps it would also be good to document what
> > the intended purpose of cb_ident (and the other fields of struct
> > flow_block_cb) is.
> >
> > Compile tested only.
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c
> > index a62bcf0cf512..4de6fcae5252 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c
> > @@ -438,7 +438,7 @@ mlx5e_rep_indr_setup_block(struct net_device *netdev,
> > list_add(&indr_priv->list,
> > &rpriv->uplink_priv.tc_indr_block_priv_list);
> >
> > - block_cb = flow_block_cb_alloc(setup_cb, indr_priv, indr_priv,
> > + block_cb = flow_block_cb_alloc(setup_cb, rpriv, indr_priv,
> > mlx5e_rep_indr_block_unbind);
> > if (IS_ERR(block_cb)) {
> > list_del(&indr_priv->list);
> > diff --git a/net/core/flow_offload.c b/net/core/flow_offload.c
> > index b288d2f03789..d281fb182894 100644
> > --- a/net/core/flow_offload.c
> > +++ b/net/core/flow_offload.c
> > @@ -373,14 +373,13 @@ int flow_indr_dev_register(flow_indr_block_bind_cb_t *cb, void *cb_priv)
> > EXPORT_SYMBOL(flow_indr_dev_register);
> >
> > static void __flow_block_indr_cleanup(void (*release)(void *cb_priv),
> > - void *cb_priv,
> > + void *cb_ident,
> > struct list_head *cleanup_list)
> > {
> > struct flow_block_cb *this, *next;
> >
> > list_for_each_entry_safe(this, next, &flow_block_indr_list, indr.list) {
> > - if (this->release == release &&
> > - this->cb_priv == cb_priv) {
> > + if (this->release == release && this->cb_ident == cb_ident) {
> > list_move(&this->indr.list, cleanup_list);
> > return;
> > }
> >
^ permalink raw reply
* Re: [PATCH net] ip6_gre: fix use-after-free in ip6gre_tunnel_lookup()
From: Taehee Yoo @ 2020-06-16 14:28 UTC (permalink / raw)
To: David Miller; +Cc: Jakub Kicinski, Netdev, xeb
In-Reply-To: <20200615.181701.1458193855639723291.davem@davemloft.net>
On Tue, 16 Jun 2020 at 10:17, David Miller <davem@davemloft.net> wrote:
>
Hi David,
Thank you for the review :)
> From: Taehee Yoo <ap420073@gmail.com>
> Date: Mon, 15 Jun 2020 15:07:51 +0000
>
> > In the datapath, the ip6gre_tunnel_lookup() is used and it internally uses
> > fallback tunnel device pointer, which is fb_tunnel_dev.
> > This pointer is protected by RTNL. It's not enough to be used
> > in the datapath.
> > So, this pointer would be used after an interface is deleted.
> > It eventually results in the use-after-free problem.
> >
> > In order to avoid the problem, the new tunnel pointer variable is added,
> > which indicates a fallback tunnel device's tunnel pointer.
> > This is protected by both RTNL and RCU.
> > So, it's safe to be used in the datapath.
> ...
>
> I'm marking this changes requested because it seems like the feedback Eric
> Dumazet provided for the ip_tunnel version of this fix applies here too.
>
> Thank you.
I will send a v2 patch soon.
Thanks a lot!
Taehee Yoo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox