* linux-next: manual merge of the staging tree with the net-next tree
From: Stephen Rothwell @ 2018-03-15 7:35 UTC (permalink / raw)
To: Greg KH, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Denys Vlasenko
[-- Attachment #1: Type: text/plain, Size: 800 bytes --]
Hi all,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/irda/net/af_irda.c
between commit:
9b2c45d479d0 ("net: make getname() functions return length rather than use int* parameter")
from the net-next tree and commit:
d64c2a76123f ("staging: irda: remove the irda network stack and drivers")
from the staging tree.
I fixed it up (I just removed the file) 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH] lan78xx: Connect phy early
From: Nisar.Sayed @ 2018-03-15 7:36 UTC (permalink / raw)
To: agraf, Woojung.Huh
Cc: UNGLinuxDriver, netdev, linux-usb, linux-kernel, tbogendoerfer,
phil
In-Reply-To: <20180314145456.69029-1-agraf@suse.de>
Hi Alexander,
Thanks for the patch.
> @@ -2575,13 +2571,7 @@ static int lan78xx_stop(struct net_device *net)
> if (timer_pending(&dev->stat_monitor))
> del_timer_sync(&dev->stat_monitor);
>
> - phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfffffff0);
> - phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfffffff0);
> -
> phy_stop(net->phydev);
> - phy_disconnect(net->phydev);
> -
> - net->phydev = NULL;
>
> clear_bit(EVENT_DEV_OPEN, &dev->flags);
> netif_stop_queue(net);
Please do add valid "phydev" check before phy_stop, since "phy_disconnect" should be called before "unregister_netdev"
+ if (net->phydev)
phy_stop(net->phydev);
> @@ -3481,6 +3471,11 @@ static void lan78xx_disconnect(struct
> usb_interface *intf)
> net = dev->net;
> unregister_netdev(net);
>
> + phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfffffff0);
> + phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfffffff0);
> +
> + phy_disconnect(net->phydev);
> +
> cancel_delayed_work_sync(&dev->wq);
>
> usb_scuttle_anchored_urbs(&dev->deferred);
Please move "unregister_netdev" after "phy_disconnect", otherwise "phy_disconnect" will fail while we disconnect USB.
> @@ -3634,6 +3629,10 @@ static int lan78xx_probe(struct usb_interface
> *intf,
> pm_runtime_set_autosuspend_delay(&udev->dev,
> DEFAULT_AUTOSUSPEND_DELAY);
>
> + ret = lan78xx_phy_init(dev);
> + if (ret < 0)
> + return ret;
> +
> return 0;
>
> out3:
> --
> 2.12.3
We should "goto out4" instead of "return" upon "lan78xx_phy_init" fail
+ out4:
+ unregister_netdev(netdev);
In addition to current changes, you might have to take care of the following.
In function "lan78xx_reset_resume"
- lan78xx_phy_init(dev);
+ phy_start(dev->net->phydev);
Thanks,
Sd.Nisar
^ permalink raw reply
* Re: [PATCH 06/47] net: smsc: remove m32r specific smc91x configuration
From: Arnd Bergmann @ 2018-03-15 8:07 UTC (permalink / raw)
To: Finn Thain
Cc: Nicolas Pitre, Linux Kernel Mailing List, David S. Miller,
Networking
In-Reply-To: <alpine.LNX.2.21.1803151556420.19@nippy.intranet>
On Thu, Mar 15, 2018 at 5:58 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
>
> MN103 is a separate architecture, unrelated to M32R afaict...
That is correct. They are both being removed, but I must have made
a mistake when writing the changelog text here. I've fixed it now
to say
8<---
net: smsc: remove m32r/mn10300 specific smc91x configuration
The m32r and mn10300 architectures are getting removed, so this
part can be cleaned up as well.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
--->8
Arnd
^ permalink raw reply
* Re: [PATCH] vhost: fix vhost ioctl signature to build with clang
From: Darren Kenny @ 2018-03-15 8:20 UTC (permalink / raw)
To: Sonny Rao
Cc: kvm, Michael S . Tsirkin, Jason Wang, virtualization, netdev,
linux-kernel
In-Reply-To: <20180314170506.121791-1-sonnyrao@chromium.org>
On Wed, Mar 14, 2018 at 10:05:06AM -0700, Sonny Rao wrote:
>Clang is particularly anal about signed vs unsigned comparisons and
>doesn't like the fact that some ioctl numbers set the MSB, so we get
>this error when trying to build vhost on aarch64:
>
>drivers/vhost/vhost.c:1400:7: error: overflow converting case value to
> switch condition type (3221794578 to 18446744072636378898)
> [-Werror, -Wswitch]
> case VHOST_GET_VRING_BASE:
>
>3221794578 is 0xC008AF12 in hex
>18446744072636378898 is 0xFFFFFFFFC008AF12 in hex
>
>Fix this by using unsigned ints in the function signature for
>vhost_vring_ioctl().
>
>Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
All the other callers of this function already appear to assume that
it is an unsigned int.
Thanks,
Darren.
>---
> drivers/vhost/vhost.c | 2 +-
> drivers/vhost/vhost.h | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>index 1b3e8d2d5c8b4..5316319d84081 100644
>--- a/drivers/vhost/vhost.c
>+++ b/drivers/vhost/vhost.c
>@@ -1337,7 +1337,7 @@ static long vhost_set_memory(struct vhost_dev *d, struct vhost_memory __user *m)
> return -EFAULT;
> }
>
>-long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp)
>+long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp)
> {
> struct file *eventfp, *filep = NULL;
> bool pollstart = false, pollstop = false;
>diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
>index ac4b6056f19ae..d8ee85ae8fdcc 100644
>--- a/drivers/vhost/vhost.h
>+++ b/drivers/vhost/vhost.h
>@@ -45,7 +45,7 @@ void vhost_poll_stop(struct vhost_poll *poll);
> void vhost_poll_flush(struct vhost_poll *poll);
> void vhost_poll_queue(struct vhost_poll *poll);
> void vhost_work_flush(struct vhost_dev *dev, struct vhost_work *work);
>-long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp);
>+long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp);
>
> struct vhost_log {
> u64 addr;
>@@ -177,7 +177,7 @@ void vhost_dev_reset_owner(struct vhost_dev *, struct vhost_umem *);
> void vhost_dev_cleanup(struct vhost_dev *);
> void vhost_dev_stop(struct vhost_dev *);
> long vhost_dev_ioctl(struct vhost_dev *, unsigned int ioctl, void __user *argp);
>-long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void __user *argp);
>+long vhost_vring_ioctl(struct vhost_dev *d, unsigned int ioctl, void __user *argp);
> int vhost_vq_access_ok(struct vhost_virtqueue *vq);
> int vhost_log_access_ok(struct vhost_dev *);
>
>--
>2.13.5
>
^ permalink raw reply
* Re: [PATCH V2] brcmfmac: drop Inter-Access Point Protocol packets by default
From: Arend van Spriel @ 2018-03-15 8:36 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Chi-Hsien Lin, Wright Feng,
Pieter-Paul Giesberts, James Hughes,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w,
brcm80211-dev-list-+wT8y+m8/X5BDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Linus Lüssing, Felix Fietkau,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Rafał Miłecki
In-Reply-To: <20180315072909.1512-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 3/15/2018 8:29 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Testing brcmfmac with more recent firmwares resulted in AP interfaces
> not working in some specific setups. Debugging resulted in discovering
> support for IAPP in Broadcom's firmwares.
>
> Older firmwares were only generating 802.11f frames. Newer ones like:
> 1) 10.10 (TOB) (r663589)
> 2) 10.10.122.20 (r683106)
> for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames
> in the Tx path by performing a STA disassociation.
>
> This obsoleted standard and its implementation is something that:
> 1) Most people don't need / want to use
> 2) Can allow local DoS attacks
> 3) Breaks AP interfaces in some specific bridge setups
>
> To solve issues it can cause this commit modifies brcmfmac to drop IAPP
> packets. If affects:
> 1) Rx path: driver won't be sending these unwanted packets up.
> 2) Tx path: driver will reject packets that would trigger STA
> disassociation perfromed by a firmware (possible local DoS attack).
>
> It appears there are some Broadcom's clients/users who care about this
> feature despite the drawbacks. They can switch it on using a new module
> param.
>
> This change results in only two more comparisons (check for module param
> and check for Ethernet packet length) for 99.9% of packets. Its overhead
> should be very minimal.
Hi Rafał,
Thanks for this patch.
Acked-by: Arend van Spriel <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/common.c | 5 ++
> .../wireless/broadcom/brcm80211/brcmfmac/common.h | 1 +
> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 57 ++++++++++++++++++++++
> 3 files changed, 63 insertions(+)
^ permalink raw reply
* Re: [PATCH 1/2] sysfs: symlink: export sysfs_create_link_nowarn()
From: Sergei Shtylyov @ 2018-03-15 8:38 UTC (permalink / raw)
To: Grygorii Strashko, David S. Miller, netdev, Andrew Lunn,
Florian Fainelli, Greg Kroah-Hartman
Cc: Sekhar Nori, linux-kernel, linux-omap
In-Reply-To: <20180314222624.12744-2-grygorii.strashko@ti.com>
Hello!
On 3/15/2018 1:26 AM, Grygorii Strashko wrote:
> The sysfs_create_link_nowarn() is going to be used in phylib framework in
> suseuent patch which can be built as module. Hence, export
Subsequent.
> sysfs_create_link_nowarn() to avoid build errors.
>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Fixes: a3995460491d ("net: phy: Relax error checking on sysfs_create_link()")
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] tuntap: XDP_TX can use native XDP
From: Jason Wang @ 2018-03-15 8:39 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel
In-Reply-To: <20180314053424-mutt-send-email-mst@kernel.org>
On 2018年03月14日 11:37, Michael S. Tsirkin wrote:
>> return NULL;
>> case XDP_TX:
>> - xdp_xmit = true;
>> - /* fall through */
>> + get_page(alloc_frag->page);
>> + alloc_frag->offset += buflen;
>> + if (tun_xdp_xmit(tun->dev, &xdp))
>> + goto err_redirect;
>> + tun_xdp_flush(tun->dev);
> Why do we have to flush here though?
> It might be a good idea to document the reason in a code comment.
>
ndo_xdp_xmit() does not touch doorbell, so we need a ndo_xdp_flush()
here. It's the assumption of XDP API I think, so not sure it's worth to
mention it here.
Thanks
^ permalink raw reply
* Re: [RESEND] rsi: Remove stack VLA usage
From: Kalle Valo @ 2018-03-15 9:07 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Kees Cook, Andy Shevchenko, Kernel Hardening,
Linux Kernel Mailing List, netdev, open list:TI WILINK WIRELES...,
Tycho Andersen, Konstantin Ryabitsev
In-Reply-To: <20180314201944.GC11666@eros>
"Tobin C. Harding" <me@tobin.cc> writes:
> On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote:
>> "Tobin C. Harding" <me@tobin.cc> writes:
>>
>> > Added Konstantin in case he is in charge of administering patchwork.kernel.org?
>> >
>> > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote:
>> >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <me@tobin.cc> wrote:
>> >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
>> >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <me@tobin.cc> wrote:
>> >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote:
>> >> >> >> tcharding <me@tobin.cc> wrote:
>> >> >>
>> >> >> I'm pretty much sure it depends on the original email headers, like
>> >> >> above ^^^ — no name.
>> >> >> Perhaps git config on your side should be done.
>> >> >
>> >> > Thanks for the suggestion Andy but the 'tcharding' as the name was
>> >> > munged by either Kalle or patchwork. I'm guessing patchwork.
>> >>
>> >> Something you're sending from is using "tcharding" (see the email Andy
>> >> quotes). I see the headers as:
>> >>
>> >> Date: Wed, 14 Mar 2018 07:17:57 +1100
>> >> From: tcharding <me@tobin.cc>
>> >> ...
>> >> Message-ID: <20180313201757.GK8631@eros>
>> >> X-Mailer: Mutt 1.5.24 (2015-08-30)
>> >> User-Agent: Mutt/1.5.24 (2015-08-30)
>> >>
>> >> Your most recently email shows "Tobin C. Harding" though, and also
>> >> sent with Mutt...
>> >>
>> >> Do you have multiple Mutt configurations? Is something lacking a
>> >> "From" header insertion and your MTA is filling it in for you from
>> >> your username?
>> >
>> > Thanks for taking the time to respond Kees (and Tycho). I have mutt
>> > configured to reply from whichever email address I receive from so if
>> > patchwork sent an email to 'tcharding <me@tobin.cc>' (which is the
>> > details it has) and I hit reply it would have come from 'tcharding',
>> > hence Andy's reply. I wouldn't bet my life on it but I'm kinda
>> > confident that I cannot initiate an email from 'tcharding' with my
>> > current set up.
>> >
>> > Super bad form to blame someone (or something else) but I think this is
>> > a problem with how my patchwork account is configured. Either way, that
>> > is still my fault I should have added my real name to patchwork when I
>> > signed up (not just username 'tcharding').
>> >
>> > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added
>> > Konstantin to CC's.
>>
>> Like I said earlier, just send a request to helpdesk@kernel.org and
>> admins should fix your name.
>
> thanks Kalle, I'm on it.
Thanks. Looks to be fixed, now patchwork gives me:
From: Tobin C. Harding <me@tobin.cc>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] can: enable multi-queue for SocketCAN devices
From: Jonas Mark (BT-FIR/ENG1) @ 2018-03-15 9:08 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, hs@denx.de,
ZHU Yi (BT-FIR/ENG1-Zhu)
Hello Marc,
> > The driver consists of two layers because the HW is accessed via SPI.
>
> Normal SPI?
Yes, normal SPI (CLK, MOSI, MISO, SEL) plus two GPIOs for flow control.
The CAN peripheral (SPI slave) asserts the additional signals to
request a transfer and to signal that it is busy.
> > I will have to check but I am pretty confident that we would be willing
> > to publish the driver on these mailing lists as well. We will anyhow
> > ship the source code (or a written offer) with every distribution.
>
> Sure - can I find your devices used and low priced on ebay :) ?
That is rather unlikely. Though, you could buy a building containing
one.
> > If you are really serious about the review I will get the process
> > rolling for an early publication of our driver.
>
> Yes, please go ahead!
Ok, I'll kick off the process and start to collect the required signatures.
Greetings,
Mark
Bosch Building Technologies, Panel Software Fire (ST-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply
* Re: [PATCH 00/47] arch-removal: device drivers
From: Arnd Bergmann @ 2018-03-15 9:09 UTC (permalink / raw)
To: Boris Brezillon
Cc: Ulf Hansson, linux-usb, Wolfram Sang, linux-iio, Viresh Kumar,
Linus Walleij, Alexandre Belloni, IDE-ML, Networking, linux-mtd,
linux-i2c, linux-rtc, Lars-Peter Clausen, Herbert Xu,
Jonathan Corbet, open list:DOCUMENTATION, Alan Stern,
linux-serial, Jiri Slaby, linux-mmc, Shaohua Li, wg,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-pwm
In-Reply-To: <20180315063238.3303b8d1@bbrezillon>
On Thu, Mar 15, 2018 at 6:32 AM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> Hi Arnd,
>
> On Wed, 14 Mar 2018 16:35:13 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> Hi driver maintainers,
>>
>> I just posted one series with the removal of eight architectures,
>> see https://lkml.org/lkml/2018/3/14/505 for details, or
>> https://lwn.net/Articles/748074/ for more background.
>>
>> These are the device drivers that go along with them. I have already
>> picked up the drivers for arch/metag/ into my tree, they were reviewed
>> earlier.
>>
>> Please let me know if you have any concerns with the patch, or if you
>> prefer to pick up the patches in your respective trees. I created
>> the patches with 'git format-patch -D', so they will not apply without
>> manually removing those files.
>>
>> For anything else, I'd keep the removal patches in my asm-generic tree
>> and will send a pull request for 4.17 along with the actual arch removal.
>>
>
> If you don't mind, I'd like to take the mtd patches through the MTD
> tree. As you've probably noticed, nand code has been moved around and
> it's easier for me to carry those 2 simple changes in my tree than
> creating an immutable branch.
>
> Let me know if this is a problem.
Sounds good, I've removed the two patches from my tree now.
I've already sent a version of those that is based on your latest tree to
you for inclusion.
Arnd
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH net-next 0/6] Converting pernet_operations (part #8)
From: Kirill Tkhai @ 2018-03-15 9:10 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
Hi,
this series continues to review and to convert pernet_operations
to make them possible to be executed in parallel for several
net namespaces at the same time. There are different operations
over the tree, mostly are ipvs.
Thanks,
Kirill
---
Kirill Tkhai (6):
net: Convert l2tp_net_ops
net: Convert mpls_net_ops
net: Convert ovs_net_ops
net: Convert ipvs_core_ops
net: Convert ipvs_core_dev_ops
net: Convert ip_vs_ftp_ops
net/l2tp/l2tp_core.c | 1 +
net/mpls/af_mpls.c | 1 +
net/netfilter/ipvs/ip_vs_core.c | 2 ++
net/netfilter/ipvs/ip_vs_ftp.c | 1 +
net/openvswitch/datapath.c | 1 +
5 files changed, 6 insertions(+)
--
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
^ permalink raw reply
* [PATCH net-next 1/6] net: Convert l2tp_net_ops
From: Kirill Tkhai @ 2018-03-15 9:10 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Init method is rather simple. Exit method queues del_work
for every tunnel from per-net list. This seems to be safe
to be marked async.
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
---
net/l2tp/l2tp_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 83421c6f0bef..189a12a5e4ac 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1787,6 +1787,7 @@ static struct pernet_operations l2tp_net_ops = {
.exit = l2tp_exit_net,
.id = &l2tp_net_id,
.size = sizeof(struct l2tp_net),
+ .async = true,
};
static int __init l2tp_init(void)
^ permalink raw reply related
* [PATCH net-next 2/6] net: Convert mpls_net_ops
From: Kirill Tkhai @ 2018-03-15 9:11 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
These pernet_operations register and unregister sysctl table.
Exit methods frees platform_labels from net::mpls::platform_label.
Everything is per-net, and they looks safe to be marked async.
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
---
net/mpls/af_mpls.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 7a4de6d618b1..d4a89a8be013 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -2488,6 +2488,7 @@ static void mpls_net_exit(struct net *net)
static struct pernet_operations mpls_net_ops = {
.init = mpls_net_init,
.exit = mpls_net_exit,
+ .async = true,
};
static struct rtnl_af_ops mpls_af_ops __read_mostly = {
^ permalink raw reply related
* [PATCH net-next 3/6] net: Convert ovs_net_ops
From: Kirill Tkhai @ 2018-03-15 9:11 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
These pernet_operations initialize and destroy net_generic()
data pointed by ovs_net_id. Exit method destroys vports from
alive net to exiting net. Since they are only pernet_operations
interested in this data, and exit method is executed under
exclusive global lock (ovs_mutex), they are safe to be executed
in parallel.
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
---
net/openvswitch/datapath.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index ef38e5aecd28..100191df0371 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -2384,6 +2384,7 @@ static struct pernet_operations ovs_net_ops = {
.exit = ovs_exit_net,
.id = &ovs_net_id,
.size = sizeof(struct ovs_net),
+ .async = true,
};
static int __init dp_init(void)
^ permalink raw reply related
* [PATCH net-next 4/6] net: Convert ipvs_core_ops
From: Kirill Tkhai @ 2018-03-15 9:11 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
These pernet_operations register and unregister nf hooks,
/proc entries, sysctl, percpu statistics. There are several
global lists, and the only list modified without exclusive
locks is ip_vs_conn_tab in ip_vs_conn_flush(). We iterate
the list and force the timers expire at the moment. Since
there were possible several timer expirations before this
patch, and since they are safe, the patch does not invent
new parallelism of their destruction. These pernet_operations
look safe to be converted.
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
---
net/netfilter/ipvs/ip_vs_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index 5f6f73cf2174..c5d16e2bc8e2 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -2289,6 +2289,7 @@ static struct pernet_operations ipvs_core_ops = {
.exit = __ip_vs_cleanup,
.id = &ip_vs_net_id,
.size = sizeof(struct netns_ipvs),
+ .async = true,
};
static struct pernet_operations ipvs_core_dev_ops = {
^ permalink raw reply related
* [PATCH net-next 5/6] net: Convert ipvs_core_dev_ops
From: Kirill Tkhai @ 2018-03-15 9:11 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Exit method stops two per-net threads and cancels
delayed work. Everything looks nicely per-net divided.
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
---
net/netfilter/ipvs/ip_vs_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index c5d16e2bc8e2..6a6cb9db030b 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -2294,6 +2294,7 @@ static struct pernet_operations ipvs_core_ops = {
static struct pernet_operations ipvs_core_dev_ops = {
.exit = __ip_vs_dev_cleanup,
+ .async = true,
};
/*
^ permalink raw reply related
* [PATCH net-next 6/6] net: Convert ip_vs_ftp_ops
From: Kirill Tkhai @ 2018-03-15 9:11 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, wensong-ud5FBsm0p/xg9hUCZPvPmw,
horms-/R6kz+dDXgpPR4JQBCEnsQ, ja-FgGsKACvmQM,
pablo-Cap9r6Oaw4JrovVCs/uTlw,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pshelar-LZ6Gd1LRuIk,
g.nault-pHk1y4uTXVDytLWWfqlThQ, jchapman-Bm0nJX+W7e9BDgjK7y7TUQ,
lorenzo.bianconi-H+wXaHxf7aLQT0dZR+AlfA,
dwindsor-Re5JQEeQqe8AvxtiuMwx3w,
elena.reshetova-ral2JQCrhuEAvxtiuMwx3w,
dsahern-Re5JQEeQqe8AvxtiuMwx3w,
roopa-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR,
rshearma-43mecJUBy8ZBDgjK7y7TUQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
amine.kherbouche-pdR9zngts4EAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, lvs-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, ktkhai-5HdwGun5lf+gSpxsJD1C4w
In-Reply-To: <152110491273.28582.13804059107038714030.stgit-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
These pernet_operations register and unregister ipvs app.
register_ip_vs_app(), unregister_ip_vs_app() and
register_ip_vs_app_inc() modify per-net structures,
and there are no global structures touched. So,
this looks safe to be marked as async.
Signed-off-by: Kirill Tkhai <ktkhai-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
---
net/netfilter/ipvs/ip_vs_ftp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index 58d5d05aec24..8b25aab41928 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -479,6 +479,7 @@ static void __ip_vs_ftp_exit(struct net *net)
static struct pernet_operations ip_vs_ftp_ops = {
.init = __ip_vs_ftp_init,
.exit = __ip_vs_ftp_exit,
+ .async = true,
};
static int __init ip_vs_ftp_init(void)
^ permalink raw reply related
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Shmulik Ladkani @ 2018-03-15 9:21 UTC (permalink / raw)
To: Liran Alon, Daniel Borkmann
Cc: davem, netdev, linux-kernel, idan.brown, Yuval Shaia
In-Reply-To: <1520953642-8145-1-git-send-email-liran.alon@oracle.com>
Hi,
On Tue, 13 Mar 2018 17:07:22 +0200 Liran Alon <liran.alon@oracle.com> wrote:
> Before this commit, dev_forward_skb() always cleared packet's
> per-network-namespace info. Even if the packet doesn't cross
> network namespaces.
>
> The comment above dev_forward_skb() describes that this is done
> because the receiving device may be in another network namespace.
> However, this case can easily be tested for and therefore we can
> scrub packet's per-network-namespace info only when receiving device
> is indeed in another network namespace.
>
> Therefore, this commit changes ____dev_forward_skb() to tell
> skb_scrub_packet() that skb has crossed network-namespace only in case
> transmitting device (skb->dev) network namespace is different then
> receiving device (dev) network namespace.
Assuming the premise of this commit is correct, note it may not act as
intended for xnet situation in ipvlan_process_multicast, snip:
nskb->dev = ipvlan->dev;
if (tx_pkt)
ret = dev_forward_skb(ipvlan->dev, nskb);
else
ret = netif_rx(nskb);
as 'dev' gets already assigned to nskb prior dev_forward_skb (hence in
____dev_forward_skb both dev and skb->dev are the same).
Fortunately every ipvlan_multicast_enqueue call is preceded by a forced
scrub; It would be future-proof to not assign nskb->dev in the
dev_forward_skb case (assign it only in the netif_rx case).
Regarding the premise of this commit, this "reduces" the
ipvs/orphan/mark scrubbing in the following *non* xnet situations:
1. mac2vlan port xmit to other macvlan ports in Bridge Mode
2. similarly for ipvlan
3. veth xmit
4. l2tp_eth_dev_recv
5. bpf redirect/clone_redirect ingress actions
Regarding l2tp recv, this commit seems to align the srubbing behavior
with ip tunnels (full scrub only if crossing netns, see ip_tunnel_rcv).
Regarding veth xmit, it does makes sense to preserve the fields if not
crossing netns. This is also the case when one uses tc mirred.
Regarding bpf redirect, well, it depends on the expectations of each bpf
program.
I'd argue that preserving the fields (at least the mark field) in the
*non* xnet makes sense and provides more information and therefore more
capabilities; Alas this might change behavior already being relied on.
Maybe Daniel can comment on the matter.
Regards,
Shmulik
^ permalink raw reply
* Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default
From: Kalle Valo @ 2018-03-15 9:23 UTC (permalink / raw)
To: Arend van Spriel
Cc: Rafał Miłecki, Rafał Miłecki, Franky Lin,
Hante Meuleman, Chi-Hsien Lin, Wright Feng, Pieter-Paul Giesberts,
James Hughes, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w,
brcm80211-dev-list-+wT8y+m8/X5BDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA, Linus Lüssing, Felix Fietkau,
bridge-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <5AA98C3B.2070406-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Arend van Spriel <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> On 3/14/2018 5:10 PM, Kalle Valo wrote:
>> Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org> writes:
>>
>>>>> + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
>>>>> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>>>>
>>>> #ifndef?
>>>
>>> I followed what is used in the include/linux/etherdevice.h. Is that a
>>> good exceuse? Could it be there any some good reason for #if defined()?
>>
>> Don't know, maybe just a matter of taste? But it would be nice to know
>> the background behind #ifdef vs #if defined(), never figured it out why
>> two different forms.
>
> Well. In this case you could use either one, but if you have more
> conditions #if defined() is bit more efficient:
>
> #ifdef A
> #ifdef B
> #endif
> #endif
>
> vs.
>
> #if defined(A) && defined(B)
Oh yeah, here defined() definitely helps.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 0/5] DPAA Ethernet fixes
From: Madalin-cristian Bucur @ 2018-03-15 9:32 UTC (permalink / raw)
To: jocke@infinera.com, davem@davemloft.net
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li, Camelia Alexandra Groza,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1521052994.4790.148.camel@infinera.com>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:Joakim.Tjernlund@infinera.com]
> Sent: Wednesday, March 14, 2018 8:43 PM
> To: davem@davemloft.net; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>
>
> On Wed, 2018-03-14 at 08:37 -0500, Madalin Bucur wrote:
> > Hi,
> >
> > This patch set is addressing several issues in the DPAA Ethernet
> > driver suite:
> >
> > - module unload crash caused by wrong reference to device being left
> > in the cleanup code after the DSA related changes
> > - scheduling wile atomic bug in QMan code revealed during dpaa_eth
> > module unload
> > - a couple of error counter fixes, a duplicated init in dpaa_eth.
>
> hmm, some of these(all?) bugs are in stable too, CC: stable perhaps?
Hi Jocke,
I did not check that, they should be added.
Thanks,
Madalin
> >
> > Madalin
> >
> > Camelia Groza (3):
> > dpaa_eth: remove duplicate initialization
> > dpaa_eth: increment the RX dropped counter when needed
> > dpaa_eth: remove duplicate increment of the tx_errors counter
> >
> > Madalin Bucur (2):
> > soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
> > dpaa_eth: fix error in dpaa_remove()
> >
> > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 8 ++++----
> > drivers/soc/fsl/qbman/qman.c | 28 +++++---------------------
> > 2 files changed, 9 insertions(+), 27 deletions(-)
> >
> > --
> > 2.1.0
> >
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: David Howells @ 2018-03-15 9:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-block, linux-fbdev, linux-watchdog, linux-doc,
netdev, linux-usb, linux-wireless, linux-kernel, linux-pwm,
linux-spi, dhowells, linux-ide, dri-devel, linux-input,
linux-fsdevel, linux-mm, linux-rtc
In-Reply-To: <20180314143529.1456168-1-arnd@arndb.de>
Do we have anything left that still implements NOMMU?
David
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: netns: send uevent messages
From: Kirill Tkhai @ 2018-03-15 9:47 UTC (permalink / raw)
To: Christian Brauner, ebiederm, gregkh, netdev, linux-kernel; +Cc: serge, avagin
In-Reply-To: <20180315001214.19462-1-christian.brauner@ubuntu.com>
CC Andrey Vagin
On 15.03.2018 03:12, Christian Brauner wrote:
> This patch adds a receive method to NETLINK_KOBJECT_UEVENT netlink sockets
> to allow sending uevent messages into the network namespace the socket
> belongs to.
>
> Currently non-initial network namespaces are already isolated and don't
> receive uevents. There are a number of cases where it is beneficial for a
> sufficiently privileged userspace process to send a uevent into a network
> namespace.
>
> One such use case would be debugging and fuzzing of a piece of software
> which listens and reacts to uevents. By running a copy of that software
> inside a network namespace, specific uevents could then be presented to it.
> More concretely, this would allow for easy testing of udevd/ueventd.
>
> This will also allow some piece of software to run components inside a
> separate network namespace and then effectively filter what that software
> can receive. Some examples of software that do directly listen to uevents
> and that we have in the past attempted to run inside a network namespace
> are rbd (CEPH client) or the X server.
>
> Implementation:
> The implementation has been kept as simple as possible from the kernel's
> perspective. Specifically, a simple input method uevent_net_rcv() is added
> to NETLINK_KOBJECT_UEVENT sockets which completely reuses existing
> af_netlink infrastructure and does neither add an additional netlink family
> nor requires any user-visible changes.
>
> For example, by using netlink_rcv_skb() we can make use of existing netlink
> infrastructure to report back informative error messages to userspace.
>
> Furthermore, this implementation does not introduce any overhead for
> existing uevent generating codepaths. The struct netns gets a new uevent
> socket member that records the uevent socket associated with that network
> namespace. Since we record the uevent socket for each network namespace in
> struct net we don't have to walk the whole uevent socket list.
> Instead we can directly retrieve the relevant uevent socket and send the
> message. This keeps the codepath very performant without introducing
> needless overhead.
>
> Uevent sequence numbers are kept global. When a uevent message is sent to
> another network namespace the implementation will simply increment the
> global uevent sequence number and append it to the received uevent. This
> has the advantage that the kernel will never need to parse the received
> uevent message to replace any existing uevent sequence numbers. Instead it
> is up to the userspace process to remove any existing uevent sequence
> numbers in case the uevent message to be sent contains any.
>
> Security:
> In order for a caller to send uevent messages to a target network namespace
> the caller must have CAP_SYS_ADMIN in the owning user namespace of the
> target network namespace. Additionally, any received uevent message is
> verified to not exceed size UEVENT_BUFFER_SIZE. This includes the space
> needed to append the uevent sequence number.
>
> Testing:
> This patch has been tested and verified to work with the following udev
> implementations:
> 1. CentOS 6 with udevd version 147
> 2. Debian Sid with systemd-udevd version 237
> 3. Android 7.1.1 with ueventd
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
> include/net/net_namespace.h | 1 +
> lib/kobject_uevent.c | 88 ++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index f306b2aa15a4..467bde763a9b 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -78,6 +78,7 @@ struct net {
>
> struct sock *rtnl; /* rtnetlink socket */
> struct sock *genl_sock;
> + struct sock *uevent_sock; /* uevent socket */
Since you add this per-net uevent_sock pointer, currently existing iterations in uevent_net_exit()
become to look confusing. There are:
mutex_lock(&uevent_sock_mutex);
list_for_each_entry(ue_sk, &uevent_sock_list, list) {
if (sock_net(ue_sk->sk) == net)
goto found;
}
Can't we make a small cleanup in lib/kobject_uevent.c after this change
and before the main part of the patch goes?
>
> struct list_head dev_base_head;
> struct hlist_head *dev_name_head;
> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> index 9fe6ec8fda28..10b2144b9fc3 100644
> --- a/lib/kobject_uevent.c
> +++ b/lib/kobject_uevent.c
> @@ -25,6 +25,7 @@
> #include <linux/uuid.h>
> #include <linux/ctype.h>
> #include <net/sock.h>
> +#include <net/netlink.h>
> #include <net/net_namespace.h>
>
>
> @@ -602,12 +603,94 @@ int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...)
> EXPORT_SYMBOL_GPL(add_uevent_var);
>
> #if defined(CONFIG_NET)
> +static int uevent_net_send(struct sock *usk, struct sk_buff *skb,
> + struct netlink_ext_ack *extack)
> +{
> + int ret;
> + u64 seqnum;
> + /* u64 to chars: 2^64 - 1 = 21 chars */
18446744073709551615 -- 20 chars (+1 '\0'). Comment makes me think
we forgot +1 in buf declaration.
> + char buf[sizeof("SEQNUM=") + 21];
> + struct sk_buff *skbc;
> +
> + /* bump sequence number */
> + mutex_lock(&uevent_sock_mutex);
> + seqnum = ++uevent_seqnum;
> + mutex_unlock(&uevent_sock_mutex);
Commit 7b60a18da393 from Andrew Vagin says:
uevent: send events in correct order according to seqnum (v3)
The queue handling in the udev daemon assumes that the events are
ordered.
Before this patch uevent_seqnum is incremented under sequence_lock,
than an event is send uner uevent_sock_mutex. I want to say that code
contained a window between incrementing seqnum and sending an event.
This patch locks uevent_sock_mutex before incrementing uevent_seqnum.
Signed-off-by: Andrew Vagin <avagin@openvz.org>
After this change the order will be lost. Also the rest of namespaces
will have holes in uevent numbers, as they won't receive a number sent
to specific namespace.
It seems we should made uevent_seqnum per-net to solve this problem.
> + /* prepare sequence number */
> + ret = snprintf(buf, sizeof(buf), "SEQNUM=%llu", seqnum);
> + if (ret < 0 || (size_t)ret >= sizeof(buf))
> + return -ENOMEM;> + ret++;
> +
> + /* verify message does not overflow */
> + if ((skb->len + ret) > UEVENT_BUFFER_SIZE) {
> + NL_SET_ERR_MSG(extack, "uevent message too big");
> + return -EINVAL;
> + }
> +
> + /* copy skb and extend to accommodate sequence number */
> + skbc = skb_copy_expand(skb, 0, ret, GFP_KERNEL);
> + if (!skbc)
> + return -ENOMEM;
> +
> + /* append sequence number */
> + skb_put_data(skbc, buf, ret);
> +
> + /* remove msg header */
> + skb_pull(skbc, NLMSG_HDRLEN);
> +
> + /* set portid 0 to inform userspace message comes from kernel */
> + NETLINK_CB(skbc).portid = 0;
> + NETLINK_CB(skbc).dst_group = 1;
> +
> + ret = netlink_broadcast(usk, skbc, 0, 1, GFP_KERNEL);
> + /* ENOBUFS should be handled in userspace */
> + if (ret == -ENOBUFS || ret == -ESRCH)
> + ret = 0;
> +
> + return ret;
> +}
> +
> +static int uevent_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
> + struct netlink_ext_ack *extack)
> +{
> + void *msg;
> + struct net *target_net;
> + struct sock *target_sk;
> +
> + msg = nlmsg_data(nlh);
> + if (!msg)
> + return -EINVAL;
> +
> + target_net = sock_net(NETLINK_CB(skb).sk);
> + target_sk = target_net->uevent_sock;
> +
> + /*
> + * Verify that we are allowed to send messages to the target network
> + * namespace. The caller must have CAP_SYS_ADMIN in the owning user
> + * namespace of the target network namespace.
> + */
> + if (!netlink_ns_capable(skb, target_net->user_ns, CAP_SYS_ADMIN)) {
> + NL_SET_ERR_MSG(extack, "missing CAP_SYS_ADMIN capability");
> + return -EPERM;
> + }
> +
> + return uevent_net_send(target_sk, skb, extack);
> +}
> +
> +static void uevent_net_rcv(struct sk_buff *skb)
> +{
> + netlink_rcv_skb(skb, &uevent_rcv_msg);
> +}
> +
> static int uevent_net_init(struct net *net)
> {
> struct uevent_sock *ue_sk;
> struct netlink_kernel_cfg cfg = {
> .groups = 1,
> - .flags = NL_CFG_F_NONROOT_RECV,
> + .input = uevent_net_rcv,
> + .flags = NL_CFG_F_NONROOT_RECV
> };
>
> ue_sk = kzalloc(sizeof(*ue_sk), GFP_KERNEL);
> @@ -621,6 +704,9 @@ static int uevent_net_init(struct net *net)
> kfree(ue_sk);
> return -ENODEV;
> }
> +
> + net->uevent_sock = ue_sk->sk;
> +
> mutex_lock(&uevent_sock_mutex);
> list_add_tail(&ue_sk->list, &uevent_sock_list);
> mutex_unlock(&uevent_sock_mutex);
Kirill
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Geert Uytterhoeven @ 2018-03-15 9:48 UTC (permalink / raw)
To: David Howells
Cc: Linux-Arch, Linux PWM List, Linux Fbdev development list,
Linux Watchdog Mailing List, Arnd Bergmann, linux-doc, netdev,
USB list, linux-wireless, Linux Kernel Mailing List,
DRI Development, linux-spi, linux-block, linux-ide, linux-input,
Linux FS Devel, Linux MM, linux-rtc
In-Reply-To: <2929.1521106970@warthog.procyon.org.uk>
Hi David,
On Thu, Mar 15, 2018 at 10:42 AM, David Howells <dhowells@redhat.com> wrote:
> Do we have anything left that still implements NOMMU?
Sure: arm, c6x, m68k, microblaze, and sh.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] can: enable multi-queue for SocketCAN devices
From: Marc Kleine-Budde @ 2018-03-15 9:53 UTC (permalink / raw)
To: Jonas Mark (BT-FIR/ENG1), Wolfgang Grandegger
Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, hs@denx.de,
ZHU Yi (BT-FIR/ENG1-Zhu)
In-Reply-To: <d2afad3064f6458390ad692bec0edff9@de.bosch.com>
[-- Attachment #1.1: Type: text/plain, Size: 1277 bytes --]
On 03/15/2018 10:08 AM, Jonas Mark (BT-FIR/ENG1) wrote:
>> Normal SPI?
>
> Yes, normal SPI (CLK, MOSI, MISO, SEL) plus two GPIOs for flow control.
> The CAN peripheral (SPI slave) asserts the additional signals to
> request a transfer and to signal that it is busy.
Sounds interesting.
>>> I will have to check but I am pretty confident that we would be willing
>>> to publish the driver on these mailing lists as well. We will anyhow
>>> ship the source code (or a written offer) with every distribution.
>>
>> Sure - can I find your devices used and low priced on ebay :) ?
>
> That is rather unlikely. Though, you could buy a building containing
> one.
One building one device sounds like a bad deal to me :)
>>> If you are really serious about the review I will get the process
>>> rolling for an early publication of our driver.
>>
>> Yes, please go ahead!
>
> Ok, I'll kick off the process and start to collect the required signatures.
Tnx.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 00/16] remove eight obsolete architectures
From: Arnd Bergmann @ 2018-03-15 9:56 UTC (permalink / raw)
To: David Howells
Cc: linux-arch, linux-pwm, linux-fbdev, linux-watchdog,
open list:DOCUMENTATION, Networking, linux-usb, linux-wireless,
Linux Kernel Mailing List, dri-devel, linux-spi, linux-block,
IDE-ML, open list:HID CORE LAYER, Linux FS-devel Mailing List,
Linux-MM, linux-rtc
In-Reply-To: <2929.1521106970@warthog.procyon.org.uk>
On Thu, Mar 15, 2018 at 10:42 AM, David Howells <dhowells@redhat.com> wrote:
> Do we have anything left that still implements NOMMU?
Yes, plenty. I was wondering the same thing, but it seems that the architectures
we remove are almost completely representative of what we support overall,
except that they are all not licensed to 3rd parties, unlike many of the ones we
keep.
I've made an overview of the remaining architectures for my own reference[1].
The remaining NOMMU architectures are:
- arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
gaining traction
- arch/sh has an open-source J2 core that was added not that long ago,
it seems to
be the only SH compatible core that anyone is working on.
- arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
- arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
classic processors
- c6x has no MMU
Arnd
[1] https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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