* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Andrew Lunn @ 2018-03-29 14:40 UTC (permalink / raw)
To: Alexandre Belloni
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180329140544.GB12066@piout.net>
On Thu, Mar 29, 2018 at 04:05:44PM +0200, Alexandre Belloni wrote:
> On 23/03/2018 at 21:49:39 +0100, Andrew Lunn wrote:
> > On Fri, Mar 23, 2018 at 09:11:12PM +0100, Alexandre Belloni wrote:
> > > Add a driver for the Microsemi MII Management controller (MIIM) found on
> > > Microsemi SoCs.
> > > On Ocelot, there are two controllers, one is connected to the internal
> > > PHYs, the other one can communicate with external PHYs.
> >
> > Hi Alexandre
> >
> > This looks to be standalone. Such drivers we try to put in
> > drivers/net/phy.
> >
> > > +static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum)
> > > +{
> > > + struct mscc_miim_dev *miim = bus->priv;
> > > + u32 val;
> > > + int ret;
> > > +
> > > + mutex_lock(&miim->lock);
> >
> > What are you locking against here?
> >
> > And you don't appear to initialize the mutex anywhere.
> >
> > > +static int mscc_miim_reset(struct mii_bus *bus)
> > > +{
> > > + struct mscc_miim_dev *miim = bus->priv;
> > > + int i;
> > > +
> > > + if (miim->phy_regs) {
> > > + writel(0, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > > + writel(0x1ff, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > > + mdelay(500);
> > > + }
> > > +
> > > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > > + bus->phy_mask |= BIT(i);
> > > + }
> >
> > Why do this? Especially so for the external bus, where the PHYs might
> > have a GPIO reset line, and won't respond until the gpio is
> > released. The core code does that just before it scans the bus, or
> > just before it scans the particular address on the bus, depending on
> > the scope of the GPIO.
> >
>
> IIRC, this was needed when probing the bus without DT, in that case, the
> mdiobus_scan loop of __mdiobus_register() will fail when doing the
> get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
> -EIO and so it is impossible to register the bus. Other drivers have a
> similar code to handle that case.
Hi Alexandre
Do you mean mscc_miim_read() will return -EIO if there is no device on
the bus at the address trying to be read? Most devices just return
0xffff because there is a pull up on the data line, nothing is driving
it, so all 1's are read.
It sounds like the correct fix is for get_phy_id() to look at the
error code for mdiobus_read(bus, addr, MII_PHYSID1). If it is EIO and
maybe ENODEV, set *phy_id to 0xffffffff and return. The scan code
should then do the correct thing.
Andrew
^ permalink raw reply
* pull-request: bpf 2018-03-29
From: Daniel Borkmann @ 2018-03-29 14:38 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix nfp to properly check max insn count while emitting
instructions in the JIT which was wrongly comparing bytes
against number of instructions before, from Jakub.
2) Fix for bpftool to avoid usage of hex numbers in JSON
output since JSON doesn't accept hex numbers with 0x
prefix, also from Jakub.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 1bfa26ff8c4b7512f4e4efa6df211239223033d4:
ipv6: fix possible deadlock in rt6_age_examine_exception() (2018-03-23 13:40:34 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to e8a4796ee2954db9f7e9b52e5fbc66ef876752f6:
nfp: bpf: fix check of program max insn count (2018-03-24 10:41:24 -0700)
----------------------------------------------------------------
Jakub Kicinski (2):
tools: bpftool: don't use hex numbers in JSON output
nfp: bpf: fix check of program max insn count
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 6 +++++-
tools/bpf/bpftool/map.c | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* [patch iproute2-next] man: fix devlink object list
From: Jiri Pirko @ 2018-03-29 14:26 UTC (permalink / raw)
To: netdev; +Cc: stephen, dsahern, mlxsw, valex
From: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
man/man8/devlink.8 | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/man/man8/devlink.8 b/man/man8/devlink.8
index b83909da9a53..7986310f0617 100644
--- a/man/man8/devlink.8
+++ b/man/man8/devlink.8
@@ -19,7 +19,7 @@ devlink \- Devlink tool
.ti -8
.IR OBJECT " := { "
-.BR dev " | " port " | " monitor " }"
+.BR dev " | " port " | " monitor " | " sb " | " resource " }"
.sp
.ti -8
@@ -74,6 +74,14 @@ When combined with -j generate a pretty JSON output.
.B monitor
- watch for netlink messages.
+.TP
+.B sb
+- devlink shared buffer configuration.
+
+.TP
+.B resource
+- devlink device resource configuration.
+
.SS
.I COMMAND
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 07/30] aio: add delayed cancel support
From: Al Viro @ 2018-03-29 14:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180329085305.GA22215@lst.de>
On Thu, Mar 29, 2018 at 10:53:05AM +0200, Christoph Hellwig wrote:
> On Wed, Mar 28, 2018 at 05:35:26PM +0100, Al Viro wrote:
> > > ret = vfs_fsync(req->file, req->datasync);
> > > - fput(req->file);
> > > - aio_complete(container_of(req, struct aio_kiocb, fsync), ret, 0);
> > > + if (aio_complete(iocb, ret, 0, 0))
> > > + fput(file);
> >
> > IDGI.
> > 1) can aio_complete() ever return false here?
>
> It won't. But sometimes checking the return value and sometimes not
> seems like a bad pattern.
>
> > 2) do we ever have aio_kiocb that would not have an associated
> > struct file * that needs to be dropped on successful aio_complete()? AFAICS,
> > rw, fsync and poll variants all have one, and I'm not sure what kind of
> > async IO *could* be done without an opened file.
>
> All have a file assoiated at least right now. As mentioned last time
> finding a struct to pass that file would be rather annoying, so we'd either
> have to pass it explicitly, or do something nasty like duplicating the
> pointer in the aio_kiocb in addition to struct kiocb. Which might not
> be that bad after all, as it would only bloat the aio_kiocb and not
> struct kiocb used on stack all over.
OK. Let's leave that alone for now. Re deferred cancels - AFAICS, we *must*
remove the sucker from ctx->active_reqs before dropping ->ctx_lock.
As it is, you are creating a io_cancel()/io_cancel() race leading to double
fput(). It's not that hard to fix; I can do that myself while applying your
series (as described in previous posting - kiocb_cancel_locked() returning
NULL or ERR_PTR() in non-deferred case and pointer to aio_kiocb removed from
->active_reqs in deferred one) or you could fix it in some other way and
update your branch.
As it is, the race is user-exploitable and not that hard to trigger - AIO_POLL,
then have two threads try and cancel it at the same time.
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply
* Re: [PATCH 000/109] remove in-kernel calls to syscalls
From: Matthew Wilcox @ 2018-03-29 14:20 UTC (permalink / raw)
To: Dominik Brodowski
Cc: linux-kernel, viro, torvalds, arnd, linux-arch, hmclauchlan,
tautschn, Amir Goldstein, Andi Kleen, Andrew Morton,
Christoph Hellwig, Darren Hart, David S . Miller,
Eric W . Biederman, H . Peter Anvin, Ingo Molnar, Jaswinder Singh,
Jeff Dike, Jiri Slaby, kexec, linux-fsdevel, linux-mm, linux-s390,
Luis R . Rodriguez, netdev
In-Reply-To: <20180329112426.23043-1-linux@dominikbrodowski.net>
On Thu, Mar 29, 2018 at 01:22:37PM +0200, Dominik Brodowski wrote:
> At least on 64-bit x86, it will likely be a hard requirement from v4.17
> onwards to not call system call functions in the kernel: It is better to
> use use a different calling convention for system calls there, where
> struct pt_regs is decoded on-the-fly in a syscall wrapper which then hands
> processing over to the actual syscall function. This means that only those
> parameters which are actually needed for a specific syscall are passed on
> during syscall entry, instead of filling in six CPU registers with random
> user space content all the time (which may cause serious trouble down the
> call chain).[*]
How do we stop new ones from springing up? Some kind of linker trick
like was used to, er, "dissuade" people from using gets()?
^ permalink raw reply
* Re: pull request (net): ipsec 2018-03-29
From: David Miller @ 2018-03-29 14:18 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20180329071120.27353-1-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 29 Mar 2018 09:11:12 +0200
> 1) Fix a rcu_read_lock/rcu_read_unlock imbalance
> in the error path of xfrm_local_error().
> From Taehee Yoo.
>
> 2) Some VTI MTU fixes. From Stefano Brivio.
>
> 3) Fix a too early overwritten skb control buffer
> on xfrm transport mode.
>
> Please not that this pull request has a merge conflict
> in net/ipv4/ip_tunnel.c.
...
Pulled, and thanks for the conflict info.
^ permalink raw reply
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Alexandre Belloni @ 2018-03-29 14:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Andrew Lunn, netdev, devicetree, linux-kernel,
linux-mips
In-Reply-To: <9547b11d-147d-5029-0abe-8bf0f705c959@gmail.com>
On 23/03/2018 at 14:51:19 -0700, Florian Fainelli wrote:
> > + writel(MSCC_MIIM_CMD_VLD | (mii_id << MSCC_MIIM_CMD_PHYAD_SHIFT) |
> > + (regnum << MSCC_MIIM_CMD_REGAD_SHIFT) | MSCC_MIIM_CMD_OPR_READ,
> > + miim->regs + MSCC_MIIM_REG_CMD);
> > +
> > + ret = mscc_miim_wait_ready(bus);
> > + if (ret)
> > + goto out;
>
> Your example had an interrupt specified, can't you use that instead of
> polling?
>
the interrupt doesn't handle that. It is used to detect when a PHY
register has changed once the MIIM controller is configured to poll the
phys. At some point, this could be used to replace the PHY interrupts
but it doesn't correspond to the linux model so I didn't investigate too
much.
> > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > + bus->phy_mask |= BIT(i);
> > + }
>
> What is this used for? You have an OF MDIO bus which would create a
> phy_device for each node specified, is this a similar workaround to what
> drivers/net/phy/mdio-bcm-unimac.c has to do? If so, please document it
> as such.
>
I replied to Andrew who had the same question.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] connector: add parent pid and tgid to coredump and exit events
From: Stefan Strogin @ 2018-03-29 14:12 UTC (permalink / raw)
To: Evgeniy Polyakov, netdev
Cc: Stefan Strogin, linux-kernel, xe-linux-external, Jesper Derehag,
Matt Helsley, Mathias Krause
The intention is to get notified of process failures as soon
as possible, before a possible core dumping (which could be very long)
(e.g. in some process-manager). Coredump and exit process events
are perfect for such use cases (see 2b5faa4c553f "connector: Added
coredumping event to the process connector").
The problem is that for now the process-manager cannot know the parent
of a dying process using connectors. This could be useful if the
process-manager should monitor for failures only children of certain
parents, so we could filter the coredump and exit events by parent
process and/or thread ID.
Add parent pid and tgid to coredump and exit process connectors event
data.
Signed-off-by: Stefan Strogin <sstrogin@cisco.com>
---
drivers/connector/cn_proc.c | 4 ++++
include/uapi/linux/cn_proc.h | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index a782ce87715c..ed5e42461094 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -262,6 +262,8 @@ void proc_coredump_connector(struct task_struct *task)
ev->what = PROC_EVENT_COREDUMP;
ev->event_data.coredump.process_pid = task->pid;
ev->event_data.coredump.process_tgid = task->tgid;
+ ev->event_data.coredump.parent_pid = task->real_parent->pid;
+ ev->event_data.coredump.parent_tgid = task->real_parent->tgid;
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
@@ -288,6 +290,8 @@ void proc_exit_connector(struct task_struct *task)
ev->event_data.exit.process_tgid = task->tgid;
ev->event_data.exit.exit_code = task->exit_code;
ev->event_data.exit.exit_signal = task->exit_signal;
+ ev->event_data.exit.parent_pid = task->real_parent->pid;
+ ev->event_data.exit.parent_tgid = task->real_parent->tgid;
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
diff --git a/include/uapi/linux/cn_proc.h b/include/uapi/linux/cn_proc.h
index 68ff25414700..db210625cee8 100644
--- a/include/uapi/linux/cn_proc.h
+++ b/include/uapi/linux/cn_proc.h
@@ -116,12 +116,16 @@ struct proc_event {
struct coredump_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
+ __kernel_pid_t parent_pid;
+ __kernel_pid_t parent_tgid;
} coredump;
struct exit_proc_event {
__kernel_pid_t process_pid;
__kernel_pid_t process_tgid;
__u32 exit_code, exit_signal;
+ __kernel_pid_t parent_pid;
+ __kernel_pid_t parent_tgid;
} exit;
} event_data;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 3/8] net: mscc: Add MDIO driver
From: Alexandre Belloni @ 2018-03-29 14:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Florian Fainelli, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180323204939.GS24361@lunn.ch>
On 23/03/2018 at 21:49:39 +0100, Andrew Lunn wrote:
> On Fri, Mar 23, 2018 at 09:11:12PM +0100, Alexandre Belloni wrote:
> > Add a driver for the Microsemi MII Management controller (MIIM) found on
> > Microsemi SoCs.
> > On Ocelot, there are two controllers, one is connected to the internal
> > PHYs, the other one can communicate with external PHYs.
>
> Hi Alexandre
>
> This looks to be standalone. Such drivers we try to put in
> drivers/net/phy.
>
> > +static int mscc_miim_read(struct mii_bus *bus, int mii_id, int regnum)
> > +{
> > + struct mscc_miim_dev *miim = bus->priv;
> > + u32 val;
> > + int ret;
> > +
> > + mutex_lock(&miim->lock);
>
> What are you locking against here?
>
> And you don't appear to initialize the mutex anywhere.
>
> > +static int mscc_miim_reset(struct mii_bus *bus)
> > +{
> > + struct mscc_miim_dev *miim = bus->priv;
> > + int i;
> > +
> > + if (miim->phy_regs) {
> > + writel(0, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > + writel(0x1ff, miim->phy_regs + MSCC_PHY_REG_PHY_CFG);
> > + mdelay(500);
> > + }
> > +
> > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > + if (mscc_miim_read(bus, i, MII_PHYSID1) < 0)
> > + bus->phy_mask |= BIT(i);
> > + }
>
> Why do this? Especially so for the external bus, where the PHYs might
> have a GPIO reset line, and won't respond until the gpio is
> released. The core code does that just before it scans the bus, or
> just before it scans the particular address on the bus, depending on
> the scope of the GPIO.
>
IIRC, this was needed when probing the bus without DT, in that case, the
mdiobus_scan loop of __mdiobus_register() will fail when doing the
get_phy_id for phys 0 to 31 because get_phy_id() transforms any error in
-EIO and so it is impossible to register the bus. Other drivers have a
similar code to handle that case.
Anyway, I'll remove that loop for now because I'm only supporting DT.
I'll get back to that later.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: David Miller @ 2018-03-29 14:04 UTC (permalink / raw)
To: okaya
Cc: benh, torvalds, alexander.duyck, will.deacon, arnd, jgg,
David.Laight, oohall, linuxppc-dev, linux-rdma, alexander.h.duyck,
paulmck, netdev, linus971
In-Reply-To: <29fe17e0-9978-dc43-d02c-de8fabdc66c2@codeaurora.org>
From: Sinan Kaya <okaya@codeaurora.org>
Date: Thu, 29 Mar 2018 09:56:01 -0400
> sparc question sent
Sparc never lets physical memory accesses pass MMIO, and vice versa.
They are always strongly ordered amongst eachother.
Therefore no explicit barrier instructions are necessary.
^ permalink raw reply
* [PATCH net-next 3/3] net: Close race between {un, }register_netdevice_notifier() and setup_net()/cleanup_net()
From: Kirill Tkhai @ 2018-03-29 14:03 UTC (permalink / raw)
To: davem, steffen.klassert, herbert, davem, pablo, kadlec, fw,
daniel, jakub.kicinski, ast, brouer, linux, john.fastabend,
dsahern, netdev, ktkhai, netfilter-devel, coreteam
In-Reply-To: <152233127015.1654.2122693690388452589.stgit@localhost.localdomain>
{un,}register_netdevice_notifier() iterate over all net namespaces
hashed to net_namespace_list. But pernet_operations register and
unregister netdevices in unhashed net namespace, and they are not
seen for netdevice notifiers. This results in asymmetry:
1)Race with register_netdevice_notifier()
pernet_operations::init(net) ...
register_netdevice() ...
call_netdevice_notifiers() ...
... nb is not called ...
... register_netdevice_notifier(nb) -> net skipped
... ...
list_add_tail(&net->list, ..) ...
Then, userspace stops using net, and it's destructed:
pernet_operations::exit(net)
unregister_netdevice()
call_netdevice_notifiers()
... nb is called ...
This always happens with net::loopback_dev, but it may be not the only device.
2)Race with unregister_netdevice_notifier()
pernet_operations::init(net)
register_netdevice()
call_netdevice_notifiers()
... nb is called ...
Then, userspace stops using net, and it's destructed:
list_del_rcu(&net->list) ...
pernet_operations::exit(net) unregister_netdevice_notifier(nb) -> net skipped
dev_change_net_namespace() ...
call_netdevice_notifiers()
... nb is not called ...
unregister_netdevice()
call_netdevice_notifiers()
... nb is not called ...
This race is more danger, since dev_change_net_namespace() moves real
network devices, which use not trivial netdevice notifiers, and if this
will happen, the system will be left in unpredictable state.
The patch closes the race. During the testing I found two places,
where register_netdevice_notifier() is called from pernet init/exit
methods (which led to deadlock) and fixed them (see previous patches).
The review moved me to one more unusual registration place:
raw_init() (can driver). It may be a reason of problems,
if someone creates in-kernel CAN_RAW sockets, since they
will be destroyed in exit method and raw_release()
will call unregister_netdevice_notifier(). But grep over
kernel tree does not show, someone creates such sockets
from kernel space.
Theoretically, there can be more places like this, and which are
hidden from review, but we found them on the first bumping there
(since there is no a race, it will be 100% reproducible).
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/core/dev.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index e13807b5c84d..43abc5785a85 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1623,6 +1623,8 @@ int register_netdevice_notifier(struct notifier_block *nb)
struct net *net;
int err;
+ /* Close race with setup_net() and cleanup_net() */
+ down_write(&pernet_ops_rwsem);
rtnl_lock();
err = raw_notifier_chain_register(&netdev_chain, nb);
if (err)
@@ -1645,6 +1647,7 @@ int register_netdevice_notifier(struct notifier_block *nb)
unlock:
rtnl_unlock();
+ up_write(&pernet_ops_rwsem);
return err;
rollback:
@@ -1689,6 +1692,8 @@ int unregister_netdevice_notifier(struct notifier_block *nb)
struct net *net;
int err;
+ /* Close race with setup_net() and cleanup_net() */
+ down_write(&pernet_ops_rwsem);
rtnl_lock();
err = raw_notifier_chain_unregister(&netdev_chain, nb);
if (err)
@@ -1706,6 +1711,7 @@ int unregister_netdevice_notifier(struct notifier_block *nb)
}
unlock:
rtnl_unlock();
+ up_write(&pernet_ops_rwsem);
return err;
}
EXPORT_SYMBOL(unregister_netdevice_notifier);
^ permalink raw reply related
* [PATCH net-next 2/3] netfilter: Rework xt_TEE netdevice notifier
From: Kirill Tkhai @ 2018-03-29 14:03 UTC (permalink / raw)
To: davem, steffen.klassert, herbert, davem, pablo, kadlec, fw,
daniel, jakub.kicinski, ast, brouer, linux, john.fastabend,
dsahern, netdev, ktkhai, netfilter-devel, coreteam
In-Reply-To: <152233127015.1654.2122693690388452589.stgit@localhost.localdomain>
Register netdevice notifier for every iptable entry
is not good, since this breaks modularity, and
the hidden synchronization is based on rtnl_lock().
This patch reworks the synchronization via new lock,
while the rest of logic remains as it was before.
This is required for the next patch.
Tested via:
while :; do
unshare -n iptables -t mangle -A OUTPUT -j TEE --gateway 1.1.1.2 --oif lo;
done
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
net/netfilter/xt_TEE.c | 73 ++++++++++++++++++++++++++++++------------------
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/net/netfilter/xt_TEE.c b/net/netfilter/xt_TEE.c
index 86b0580b2216..475957cfcf50 100644
--- a/net/netfilter/xt_TEE.c
+++ b/net/netfilter/xt_TEE.c
@@ -20,7 +20,7 @@
#include <linux/netfilter/xt_TEE.h>
struct xt_tee_priv {
- struct notifier_block notifier;
+ struct list_head list;
struct xt_tee_tginfo *tginfo;
int oif;
};
@@ -51,29 +51,35 @@ tee_tg6(struct sk_buff *skb, const struct xt_action_param *par)
}
#endif
+static DEFINE_MUTEX(priv_list_mutex);
+static LIST_HEAD(priv_list);
+
static int tee_netdev_event(struct notifier_block *this, unsigned long event,
void *ptr)
{
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
struct xt_tee_priv *priv;
- priv = container_of(this, struct xt_tee_priv, notifier);
- switch (event) {
- case NETDEV_REGISTER:
- if (!strcmp(dev->name, priv->tginfo->oif))
- priv->oif = dev->ifindex;
- break;
- case NETDEV_UNREGISTER:
- if (dev->ifindex == priv->oif)
- priv->oif = -1;
- break;
- case NETDEV_CHANGENAME:
- if (!strcmp(dev->name, priv->tginfo->oif))
- priv->oif = dev->ifindex;
- else if (dev->ifindex == priv->oif)
- priv->oif = -1;
- break;
+ mutex_lock(&priv_list_mutex);
+ list_for_each_entry(priv, &priv_list, list) {
+ switch (event) {
+ case NETDEV_REGISTER:
+ if (!strcmp(dev->name, priv->tginfo->oif))
+ priv->oif = dev->ifindex;
+ break;
+ case NETDEV_UNREGISTER:
+ if (dev->ifindex == priv->oif)
+ priv->oif = -1;
+ break;
+ case NETDEV_CHANGENAME:
+ if (!strcmp(dev->name, priv->tginfo->oif))
+ priv->oif = dev->ifindex;
+ else if (dev->ifindex == priv->oif)
+ priv->oif = -1;
+ break;
+ }
}
+ mutex_unlock(&priv_list_mutex);
return NOTIFY_DONE;
}
@@ -89,8 +95,6 @@ static int tee_tg_check(const struct xt_tgchk_param *par)
return -EINVAL;
if (info->oif[0]) {
- int ret;
-
if (info->oif[sizeof(info->oif)-1] != '\0')
return -EINVAL;
@@ -100,14 +104,11 @@ static int tee_tg_check(const struct xt_tgchk_param *par)
priv->tginfo = info;
priv->oif = -1;
- priv->notifier.notifier_call = tee_netdev_event;
info->priv = priv;
- ret = register_netdevice_notifier(&priv->notifier);
- if (ret) {
- kfree(priv);
- return ret;
- }
+ mutex_lock(&priv_list_mutex);
+ list_add(&priv->list, &priv_list);
+ mutex_unlock(&priv_list_mutex);
} else
info->priv = NULL;
@@ -120,7 +121,9 @@ static void tee_tg_destroy(const struct xt_tgdtor_param *par)
struct xt_tee_tginfo *info = par->targinfo;
if (info->priv) {
- unregister_netdevice_notifier(&info->priv->notifier);
+ mutex_lock(&priv_list_mutex);
+ list_del(&info->priv->list);
+ mutex_unlock(&priv_list_mutex);
kfree(info->priv);
}
static_key_slow_dec(&xt_tee_enabled);
@@ -153,13 +156,29 @@ static struct xt_target tee_tg_reg[] __read_mostly = {
#endif
};
+static struct notifier_block tee_netdev_notifier = {
+ .notifier_call = tee_netdev_event,
+};
+
static int __init tee_tg_init(void)
{
- return xt_register_targets(tee_tg_reg, ARRAY_SIZE(tee_tg_reg));
+ int ret;
+
+ ret = xt_register_targets(tee_tg_reg, ARRAY_SIZE(tee_tg_reg));
+ if (ret)
+ return ret;
+ ret = register_netdevice_notifier(&tee_netdev_notifier);
+ if (ret) {
+ xt_unregister_targets(tee_tg_reg, ARRAY_SIZE(tee_tg_reg));
+ return ret;
+ }
+
+ return 0;
}
static void __exit tee_tg_exit(void)
{
+ unregister_netdevice_notifier(&tee_netdev_notifier);
xt_unregister_targets(tee_tg_reg, ARRAY_SIZE(tee_tg_reg));
}
^ permalink raw reply related
* [PATCH net-next 1/3] xfrm: Register xfrm_dev_notifier in appropriate place
From: Kirill Tkhai @ 2018-03-29 14:03 UTC (permalink / raw)
To: davem, steffen.klassert, herbert, davem, pablo, kadlec, fw,
daniel, jakub.kicinski, ast, brouer, linux, john.fastabend,
dsahern, netdev, ktkhai, netfilter-devel, coreteam
In-Reply-To: <152233127015.1654.2122693690388452589.stgit@localhost.localdomain>
Currently, driver registers it from pernet_operations::init method,
and this breaks modularity, because initialization of net namespace
and netdevice notifiers are orthogonal actions. We don't have
per-namespace netdevice notifiers; all of them are global for all
devices in all namespaces.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
---
include/net/xfrm.h | 2 +-
net/xfrm/xfrm_device.c | 2 +-
net/xfrm/xfrm_policy.c | 3 +--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index aa027ba1d032..a872379b69da 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1894,7 +1894,7 @@ static inline struct xfrm_offload *xfrm_offload(struct sk_buff *skb)
#endif
}
-void __net_init xfrm_dev_init(void);
+void __init xfrm_dev_init(void);
#ifdef CONFIG_XFRM_OFFLOAD
void xfrm_dev_resume(struct sk_buff *skb);
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index e87d6c4dd5b6..175941e15a6e 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -350,7 +350,7 @@ static struct notifier_block xfrm_dev_notifier = {
.notifier_call = xfrm_dev_event,
};
-void __net_init xfrm_dev_init(void)
+void __init xfrm_dev_init(void)
{
register_netdevice_notifier(&xfrm_dev_notifier);
}
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 625b3fca5704..f29c8d588116 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2895,8 +2895,6 @@ static int __net_init xfrm_policy_init(struct net *net)
INIT_LIST_HEAD(&net->xfrm.policy_all);
INIT_WORK(&net->xfrm.policy_hash_work, xfrm_hash_resize);
INIT_WORK(&net->xfrm.policy_hthresh.work, xfrm_hash_rebuild);
- if (net_eq(net, &init_net))
- xfrm_dev_init();
return 0;
out_bydst:
@@ -2999,6 +2997,7 @@ void __init xfrm_init(void)
INIT_WORK(&xfrm_pcpu_work[i], xfrm_pcpu_work_fn);
register_pernet_subsys(&xfrm_net_ops);
+ xfrm_dev_init();
seqcount_init(&xfrm_policy_hash_generation);
xfrm_input_init();
}
^ permalink raw reply related
* [PATCH net-next 0/3] Close race between {un, }register_netdevice_notifier and pernet_operations
From: Kirill Tkhai @ 2018-03-29 14:03 UTC (permalink / raw)
To: davem, steffen.klassert, herbert, davem, pablo, kadlec, fw,
daniel, jakub.kicinski, ast, brouer, linux, john.fastabend,
dsahern, netdev, ktkhai, netfilter-devel, coreteam
Hi,
the problem is {,un}register_netdevice_notifier() do not take
pernet_ops_rwsem, and they don't see network namespaces, being
initialized in setup_net() and cleanup_net(), since at this
time net is not hashed to net_namespace_list.
This may lead to imbalance, when a notifier is called at time of
setup_net()/net is alive, but it's not called at time of cleanup_net(),
for the devices, hashed to the net, and vise versa. See (3/3) for
the scheme of imbalance.
This patchset fixes the problem by acquiring pernet_ops_rwsem
at the time of {,un}register_netdevice_notifier() (3/3).
(1-2/3) are preparations in xfrm and netfilter subsystems.
The problem was introduced a long ago, but backporting won't be easy,
since every previous kernel version may have changes in netdevice
notifiers, and they all need review and testing. Otherwise, there
may be more pernet_operations, which register or unregister
netdevice notifiers, and that leads to deadlock (which is was fixed
in 1-2/3). This patchset is for net-next.
Thanks,
Kirill
---
Kirill Tkhai (3):
xfrm: Register xfrm_dev_notifier in appropriate place
netfilter: Rework xt_TEE netdevice notifier
net: Close race between {un,}register_netdevice_notifier() and setup_net()/cleanup_net()
include/net/xfrm.h | 2 +
net/core/dev.c | 6 ++++
net/netfilter/xt_TEE.c | 73 ++++++++++++++++++++++++++++++------------------
net/xfrm/xfrm_device.c | 2 +
net/xfrm/xfrm_policy.c | 3 +-
5 files changed, 55 insertions(+), 31 deletions(-)
^ permalink raw reply
* Re: RFC on writel and writel_relaxed
From: Sinan Kaya @ 2018-03-29 13:56 UTC (permalink / raw)
To: David Miller, benh
Cc: torvalds, alexander.duyck, will.deacon, arnd, jgg, David.Laight,
oohall, linuxppc-dev, linux-rdma, alexander.h.duyck, paulmck,
netdev, linus971
In-Reply-To: <20180328.115509.481837809903086401.davem@davemloft.net>
On 3/28/2018 11:55 AM, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Thu, 29 Mar 2018 02:13:16 +1100
>
>> Let's fix all archs, it's way easier than fixing all drivers. Half of
>> the archs are unused or dead anyway.
>
> Agreed.
>
I pinged most of the maintainers yesterday.
Which arches do we care about these days?
I have not been paying attention any other architecture besides arm64.
arch status detail
------ ------------- ------------------------------------
alpha question sent
arc question sent ysato@users.sourceforge.jp will fix it.
arm no issues
arm64 no issues
blackfin question sent about to be removed
c6x question sent
cris question sent
frv
h8300 question sent
hexagon question sent
ia64 no issues confirmed by Tony Luck
m32r
m68k question sent
metag
microblaze question sent
mips question sent
mn10300 question sent
nios2 question sent
openrisc no issues shorne@gmail.com says should no issues
parisc no issues grantgrundler@gmail.com says most probably no problem but still looking
powerpc no issues
riscv question sent
s390 question sent
score question sent
sh question sent
sparc question sent
tile question sent
unicore32 question sent
x86 no issues
xtensa question sent
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb()
From: Sinan Kaya @ 2018-03-29 13:45 UTC (permalink / raw)
To: Elior, Ariel, netdev@vger.kernel.org, timur@codeaurora.org,
sulrich@codeaurora.org
Cc: linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Dept-Eng Everest Linux L2,
linux-kernel@vger.kernel.org
In-Reply-To: <CY1PR0701MB133742146E2848330CA89FB290A20@CY1PR0701MB1337.namprd07.prod.outlook.com>
Hi Ariel,
On 3/29/2018 5:17 AM, Elior, Ariel wrote:
>> Subject: [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb()
>>
>> barrier() doesn't guarantee memory writes to be observed by the hardware on
>> all architectures. barrier() only tells compiler not to move this code
>> with respect to other read/writes.
>>
>> If memory write needs to be observed by the HW, wmb() is the right choice.
> The wmb() is there (a couple of lines above). Your modification adds an
> unnecessary fence which would hurt high pps scenarios. The memory
> writes which the HW needs to observe are the buffer descriptors, not the
> producer update message. The producer is written to the HW, and exists
> on the stack. The barrier() is there to prevent the compiler from mixing the
> order of the prod update message preparation and writing it to the host.
> A possible alternative would be to move the existing wmb() to where
> the barrier() is, achieving both goals, although in the existing design each
> barrier has a distinct purpose. The comment location is misleading, though.
I was told that barrier() is there to guarantee that HW is observing the memory
write before writel().
I reacted to this and changed barrier() to wmb() following the old directions.
You are saying that this not true.
Since then, Linus gave us direction not to have wmb() in front of writel() as
writel() already has memory-IO guarantee.
https://www.mail-archive.com/netdev@vger.kernel.org/msg225806.html
I'll be doing one more pass to remove wmb() before writel() soon. Please review
that carefully.
Intel drivers use wmb() as a substitute for smp_wmb(). So, we can't always assume
that you can remove all wmb() in front of writel() as the write barrier seems to
serve dual purpose.
Please help me getting this right on the next version.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* pull-request: wireless-drivers-next 2018-03-29
From: Kalle Valo @ 2018-03-29 13:21 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 4.17. If the merge window starts
on Sunday this will be the last pull request. Do note that I pulled
wireless-drivers into wireless-drivers-next as iwlwifi needed some
patches.
Please let me know if you have any problems.
Kalle
The following changes since commit 996bfed118748c128ad4b6c05c09fd2f5fdfa1b4:
Merge tag 'wireless-drivers-next-for-davem-2018-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next (2018-03-25 21:27:38 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-03-29
for you to fetch changes up to 14c99949a3398a655c47b262ca8e2e83edfae7fd:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2018-03-29 15:55:28 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.17
Smaller new features to various drivers but nothing really out of
ordinary.
Major changes:
ath10k
* enable chip temperature measurement for QCA6174/QCA9377
* add firmware memory dump for QCA9984
* enable buffer STA on TDLS link for QCA6174
* support different beacon internals in multiple interface scenario
for QCA988X/QCA99X0/QCA9984/QCA4019
iwlwifi
* support for new PCI IDs for the 9000 family
* support for a new firmware API version
* support for advanced dwell and Optimized Connectivity Experience
(OCE) in scanning
btrsi
* fix kconfig dependencies
wil6210
* support multiple virtual interfaces
----------------------------------------------------------------
Amitkumar Karwar (2):
rsi: fix error path handling in SDIO probe
rsi: fix kernel panic observed on 64bit machine
Andrei Otcheretianski (2):
iwlwifi: mvm: Increase session protection time after CS
iwlwifi: mvm: Move unused phy's to a default channel
Anilkumar Kolli (2):
ath10k: add memory dump support QCA9984
ath10k: advertize beacon_int_min_gcd
Arend Van Spriel (12):
brcmfmac: do not convert linux error to firmware error string
brcmfmac: use brcmf_chip_name() to store name in revinfo
brcmfmac: use brcmf_chip_name() for consistency
brcmfmac: allocate struct brcmf_pub instance using wiphy_new()
brcmfmac: use wiphy debugfs dir entry
brcmfmac: derive firmware filenames from basename mapping
brcmfmac: pass struct in brcmf_fw_get_firmwares()
brcmfmac: introduce brcmf_fw_alloc_request() function
brcmfmac: add extension to .get_fwname() callbacks
brcmfmac: get rid of brcmf_fw_map_chip_to_name()
brcmfmac: get rid of brcmf_fw_get_full_name()
brcmfmac: add kerneldoc for struct brcmf_bus::msgbuf
Arnd Bergmann (1):
Bluetooth: btrsi: rework dependencies
Avraham Stern (3):
iwlwifi: mvm: clear tx queue id when unreserving aggregation queue
iwlwifi: mvm: make sure internal station has a valid id
iwlwifi: mvm: fix array out of bounds reference
Ayala Beker (1):
iwlwifi: fw api: support the new scan request FW API version
Beni Lev (1):
iwlwifi: mvm: Correctly set IGTK for AP
Carl Huang (1):
ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait
Christian Lamparter (1):
ath10k: fix recent bandwidth conversion bug
Colin Ian King (4):
wil6210: fix spelling mistake: "preperation"-> "preparation"
ath5k: remove duplicated re-assignment to pointer 'tq'
rsi: remove redundant duplicate assignment of buffer_size
rtlwifi: rtl8821ae: fix spelling mistake: "Aboslute" -> "Absolute"
Daniel Mack (1):
wcn36xx: dequeue all pending indicator messages
Emmanuel Grumbach (2):
iwlwifi: mvm: set the correct tid when we flush the MCAST sta
iwlwifi: bump the max API version for 9000 and 22000 devices
Ganapathi Bhat (1):
mwifiex: remove warnings in mwifiex_cmd_append_11n_tlv()
Govind Singh (1):
ath10k: fix log message for hif power on failure
Haim Dreyfuss (1):
iwlwifi: api: Add geographic profile information to MCC_UPDATE_CMD
Ignacio Nunez Hernanz (1):
ath10k: make ath10k report discarded packets to mac80211
Ilan Peer (1):
iwlwifi: mvm: Allow iwl_mvm_mac_mgd_prepare_tx() when associated
Joe Perches (2):
wireless: Use octal not symbolic permissions
ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr
Johannes Berg (1):
iwlwifi: mvm: fix error checking for multi/broadcast sta
Kalle Valo (7):
Merge tag 'iwlwifi-for-kalle-2018-03-16' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'iwlwifi-for-kalle-2018-03-19' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
Merge tag 'iwlwifi-next-for-kalle-2018-03-28' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
ath10k: refactor ath10k_pci_dump_memory() in preparation for QCA9984 support
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthikeyan Periyasamy (2):
ath10k: Fix kernel panic while using worker (ath10k_sta_rc_update_wk)
Revert "ath10k: send (re)assoc peer command when NSS changed"
Kevin Lo (1):
rtlwifi: correct comment
Lior David (8):
wil6210: add wil6210_vif structure for per-VIF data
wil6210: support concurrency record in FW file
wil6210: infrastructure for multiple virtual interfaces
wil6210: add support for adding and removing virtual interfaces
wil6210: multiple VIFs support for start/stop AP
wil6210: rename p2p_wdev_mutex to vif_mutex
wil6210: multiple VIFs support for connections and data path
wil6210: add debugfs 'mids' file
Loic Poulain (2):
wcn36xx: Fix warning due to duplicate scan_completed notification
wcn36xx: Fix firmware crash due to corrupted buffer address
Lorenzo Bianconi (3):
mt76: use mt76_poll_msec routine in mt76pci_load_firmware()
mt76x2: fix possible NULL pointer dereferencing in mt76x2_tx()
mt76x2: fix warning in ieee80211_get_key_rx_seq()
Luca Coelho (3):
iwlwifi: add shared clock PHY config flag for some devices
iwlwifi: mvm: check if mac80211_queue is valid in iwl_mvm_disable_txq
iwlwifi: add a bunch of new 9000 PCI IDs
Maharaja Kennadyrajan (1):
ath10k: debugfs support to get final TPC stats for 10.4 variants
Mordechay Goodstein (1):
iwlwifi: set default timstamp marker cmd
Peter Große (1):
ath9k: spelling s/premble/preamble/
Ping-Ke Shih (11):
rtlwifi: Add modifier static to functions reported by sparse
rtlwifi: remove redundant statement found by static checker
rtlwifi: btcoex: Add enum DM_INFO for btcoex to query dm's counters
rtlwifi: btcoex: Add customer_id to do special deal to oem vendor
rtlwifi: btcoex: Get status of multichannel concurrence
rtlwifi: btcoex: Add rate table for the use of btcoex
rtlwifi: btcoex: Add interaction with phydm
rtlwifi: btcoex: Add pre- and post- normal LPS function
rtlwifi: btcoex: add assoc type v2 to connection notify
rtlwifi: btcoex: new definitions introduced by 8822be
rtlwifi: btcoex: Add new but dummy definitions introduced by 8822b
Rafał Miłecki (1):
brcmfmac: drop Inter-Access Point Protocol packets by default
Rajkumar Manoharan (1):
ath10k: fix vdev stats for 10.4 firmware
Rakesh Pillai (1):
ath10k: dma unmap mgmt tx buffer if wmi cmd send fails
Ramon Fried (5):
wcn36xx: reduce verbosity of drivers messages
wcn36xx: calculate DXE control registers values
wcn36xx: calculate DXE default channel values
wcn36xx: Check DXE IRQ reason
wcn36xx: turn off probe response offloading
Ryan Hsu (3):
ath10k: update the IRAM bank number for QCA9377
ath10k: enable QCA6174/QCA9377 to read the chip temperature
ath10k: add FW API 6 firmware image for QCA9377
Sara Sharon (4):
iwlwifi: mvm: flip AMSDU addresses only for 9000 family
iwlwifi: mvm: take RCU lock before dereferencing
iwlwifi: mvm: move TSO segment to a separate function
iwlwifi: mvm: save low latency causes in an enum
Sathishkumar Muruganandam (1):
ath10k: suppress "Unknown eventid: 36925" warnings
Sebastian Gottschall (1):
ath9k: fix crash in spectral scan
Shahar S Matityahu (1):
iwlwifi: wrt: add fw force restart via triggers
Sriram R (1):
ath: fix false radar detection in JP region
Stefan Wahren (1):
brcmfmac: Fix check for ISO3166 code
Takashi Iwai (1):
brcmsmac: allocate ucode with GFP_KERNEL
Timothy Redaelli (1):
ath9k: fix DFS detector synchronization
Tobin C. Harding (1):
rsi: Remove stack VLA usage
Toke Høiland-Jørgensen (1):
ath9k: Protect queue draining by rcu_read_lock()
Vasanthakumar Thiagarajan (1):
ath10k: add sta rx packet stats per tid
Wojciech Dubowik (2):
ath9k: Fix airtime calculation for quarter/half channels
ath9k: Fix ack SIFS time for quarter/half channels
Yingying Tang (4):
ath10k: enable TDLS peer buffer STA feature
ath10k: enable TDLS peer inactivity detection
ath10k: avoid to set WEP key for TDLS peer
ath10k: fix TDLS peer TX data failure issue on encryped AP
Zamir, Roee (2):
iwlwifi: mvm: add adaptive dwell support
iwlwifi: mvm: add support for oce
drivers/bluetooth/Kconfig | 4 +-
drivers/net/wireless/ath/ath.h | 2 -
drivers/net/wireless/ath/ath10k/core.c | 9 +-
drivers/net/wireless/ath/ath10k/core.h | 88 +++
drivers/net/wireless/ath/ath10k/coredump.c | 90 +++
drivers/net/wireless/ath/ath10k/coredump.h | 2 +
drivers/net/wireless/ath/ath10k/debug.c | 154 +++++
drivers/net/wireless/ath/ath10k/debug.h | 41 ++
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 286 ++++++++
drivers/net/wireless/ath/ath10k/htt_rx.c | 113 +++-
drivers/net/wireless/ath/ath10k/mac.c | 54 +-
drivers/net/wireless/ath/ath10k/pci.c | 101 ++-
drivers/net/wireless/ath/ath10k/trace.h | 12 +-
drivers/net/wireless/ath/ath10k/txrx.c | 12 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 56 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 116 +++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 18 +
drivers/net/wireless/ath/ath10k/wmi.c | 462 ++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 94 ++-
drivers/net/wireless/ath/ath5k/attach.c | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 6 +-
drivers/net/wireless/ath/ath5k/debug.c | 37 +-
drivers/net/wireless/ath/ath5k/qcu.c | 2 -
drivers/net/wireless/ath/ath5k/sysfs.c | 8 +-
drivers/net/wireless/ath/ath6kl/debug.c | 43 +-
drivers/net/wireless/ath/ath9k/common-debug.c | 9 +-
drivers/net/wireless/ath/ath9k/common-init.c | 2 +-
drivers/net/wireless/ath/ath9k/common-spectral.c | 22 +-
drivers/net/wireless/ath/ath9k/debug.c | 40 +-
drivers/net/wireless/ath/ath9k/debug_sta.c | 6 +-
drivers/net/wireless/ath/ath9k/dfs_debug.c | 4 +-
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 16 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 14 +-
drivers/net/wireless/ath/ath9k/init.c | 11 +-
drivers/net/wireless/ath/ath9k/tx99.c | 4 +-
drivers/net/wireless/ath/ath9k/xmit.c | 4 +
drivers/net/wireless/ath/carl9170/debug.c | 8 +-
drivers/net/wireless/ath/carl9170/main.c | 4 +-
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
drivers/net/wireless/ath/wcn36xx/debug.c | 5 +-
drivers/net/wireless/ath/wcn36xx/dxe.c | 69 +-
drivers/net/wireless/ath/wcn36xx/dxe.h | 221 +++++-
drivers/net/wireless/ath/wcn36xx/main.c | 14 +-
drivers/net/wireless/ath/wcn36xx/smd.c | 115 ++--
drivers/net/wireless/ath/wcn36xx/txrx.c | 32 +-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 741 +++++++++++++++------
drivers/net/wireless/ath/wil6210/debug.c | 9 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 117 +++-
drivers/net/wireless/ath/wil6210/ethtool.c | 4 +-
drivers/net/wireless/ath/wil6210/fw.h | 38 +-
drivers/net/wireless/ath/wil6210/fw_inc.c | 52 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 8 +-
drivers/net/wireless/ath/wil6210/main.c | 333 +++++----
drivers/net/wireless/ath/wil6210/netdev.c | 382 +++++++++--
drivers/net/wireless/ath/wil6210/p2p.c | 175 ++---
drivers/net/wireless/ath/wil6210/pcie_bus.c | 57 +-
drivers/net/wireless/ath/wil6210/pm.c | 132 ++--
drivers/net/wireless/ath/wil6210/pmc.c | 8 +-
drivers/net/wireless/ath/wil6210/rx_reorder.c | 45 +-
drivers/net/wireless/ath/wil6210/txrx.c | 177 +++--
drivers/net/wireless/ath/wil6210/txrx.h | 22 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 217 +++---
drivers/net/wireless/ath/wil6210/wmi.c | 460 +++++++++----
.../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 6 +
.../wireless/broadcom/brcm80211/brcmfmac/btcoex.c | 2 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 7 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 88 ++-
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 17 +-
.../wireless/broadcom/brcm80211/brcmfmac/chip.c | 14 +-
.../wireless/broadcom/brcm80211/brcmfmac/chip.h | 3 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 82 +--
.../wireless/broadcom/brcm80211/brcmfmac/common.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 105 ++-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 42 +-
.../wireless/broadcom/brcm80211/brcmfmac/debug.h | 17 -
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 3 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 7 +
.../broadcom/brcm80211/brcmfmac/firmware.c | 242 ++++---
.../broadcom/brcm80211/brcmfmac/firmware.h | 82 ++-
.../wireless/broadcom/brcm80211/brcmfmac/fwil.c | 3 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 11 +-
.../broadcom/brcm80211/brcmfmac/fwsignal.h | 1 +
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 8 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 2 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 157 +++--
.../wireless/broadcom/brcm80211/brcmfmac/proto.c | 3 +-
.../wireless/broadcom/brcm80211/brcmfmac/proto.h | 7 +
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 151 +++--
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 96 ++-
.../wireless/broadcom/brcm80211/brcmsmac/debug.c | 2 +-
.../broadcom/brcm80211/brcmsmac/mac80211_if.c | 6 +-
drivers/net/wireless/cisco/airo.c | 6 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 29 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 51 +-
drivers/net/wireless/intel/ipw2x00/libipw_module.c | 2 +-
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 35 +-
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 19 +-
drivers/net/wireless/intel/iwlegacy/4965-rs.c | 8 +-
drivers/net/wireless/intel/iwlegacy/common.c | 4 +-
drivers/net/wireless/intel/iwlegacy/debug.c | 58 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 66 +-
drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c | 78 ++-
drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 16 +-
.../net/wireless/intel/iwlwifi/fw/api/nvm-reg.h | 20 +-
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 73 +-
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 10 +
drivers/net/wireless/intel/iwlwifi/fw/debugfs.c | 26 +-
drivers/net/wireless/intel/iwlwifi/fw/debugfs.h | 5 +
drivers/net/wireless/intel/iwlwifi/fw/file.h | 17 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 +
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 43 +-
drivers/net/wireless/intel/iwlwifi/mvm/constants.h | 2 +
.../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 51 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 110 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 51 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c | 21 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs-fw.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 25 +-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 199 ++++--
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 74 +-
.../net/wireless/intel/iwlwifi/mvm/time-event.c | 15 +-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 168 ++---
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 19 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 195 +++++-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 12 +-
drivers/net/wireless/intersil/p54/main.c | 2 +-
drivers/net/wireless/marvell/mwifiex/11n.c | 10 +-
drivers/net/wireless/mediatek/mt76/debugfs.c | 10 +-
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 8 +-
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 11 +
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 13 +-
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 5 +-
drivers/net/wireless/mediatek/mt7601u/debugfs.c | 16 +-
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800soc.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 64 +-
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 2 +-
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
drivers/net/wireless/ray_cs.c | 8 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 1 -
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 1 +
.../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 6 +-
.../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c | 33 -
.../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 4 +-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 86 ++-
.../realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 122 ++++
.../wireless/realtek/rtlwifi/rtl8188ee/pwrseq.h | 4 +-
.../wireless/realtek/rtlwifi/rtl8192ee/pwrseq.h | 4 +-
.../wireless/realtek/rtlwifi/rtl8723ae/pwrseq.h | 4 +-
.../wireless/realtek/rtlwifi/rtl8723be/pwrseq.h | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 16 +-
.../wireless/realtek/rtlwifi/rtl8821ae/pwrseq.h | 4 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 33 +
drivers/net/wireless/rsi/Kconfig | 4 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 65 +-
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
drivers/net/wireless/rsi/rsi_sdio.h | 2 +
drivers/net/wireless/st/cw1200/debug.c | 6 +-
drivers/net/wireless/st/cw1200/main.c | 2 +-
drivers/net/wireless/ti/wl18xx/main.c | 27 +-
drivers/net/wireless/ti/wlcore/main.c | 8 +-
drivers/net/wireless/ti/wlcore/sdio.c | 2 +-
drivers/net/wireless/ti/wlcore/sysfs.c | 7 +-
173 files changed, 6233 insertions(+), 2505 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek
From: Andreas Gruenbacher @ 2018-03-29 13:15 UTC (permalink / raw)
To: Herbert Xu
Cc: cluster-devel, netdev, LKML, NeilBrown, Thomas Graf, Tom Herbert
In-Reply-To: <20180329123544.GA22551@gondor.apana.org.au>
On 29 March 2018 at 14:35, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Thu, Mar 29, 2018 at 02:06:10PM +0200, Andreas Gruenbacher wrote:
>> Here's a second version of the patch (now a patch set) to eliminate
>> rhashtable_walk_peek in gfs2.
>>
>> The first patch introduces lockref_put_not_zero, the inverse of
>> lockref_get_not_zero.
>>
>> The second patch eliminates rhashtable_walk_peek in gfs2. In
>> gfs2_glock_iter_next, the new lockref function from patch one is used to
>> drop a lockref count as long as the count doesn't drop to zero. This is
>> almost always the case; if there is a risk of dropping the last
>> reference, we must defer that to a work queue because dropping the last
>> reference may sleep.
>
> In light of Neil's latest patch, do we still need this?
For all I know, Neil's latest plan is to get rhashtable_walk_peek
replaced and removed because it is unfixable. This patch removes the
one and only user.
Thanks,
Andreas
^ permalink raw reply
* Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek
From: Andreas Gruenbacher @ 2018-03-29 13:12 UTC (permalink / raw)
To: Steven Whitehouse
Cc: cluster-devel, Herbert Xu, netdev, LKML, NeilBrown, Thomas Graf,
Tom Herbert
In-Reply-To: <b15f44f6-d052-17f2-b099-ea2d601c9a6e@redhat.com>
On 29 March 2018 at 14:24, Steven Whitehouse <swhiteho@redhat.com> wrote:
> Hi,
>
> Can we solve the problem another way, by not taking refs on the glocks when
> we are iterating over them for the debugfs files? I assume that is the main
> issue here.
>
> We didn't used to take refs since the rcu locking was enough during the walk
> itself. We used to only keep track of the hash bucket and offset within the
> bucket when we dropped the rcu lock between calls to the iterator. I may
> have lost track of why that approach did not work?
That doesn't work because when a glock doesn't fit into one read, we
need to make sure that the next read will continue with the same glock
or else we'll end up with a corrupted dump. And rhashtable_walk_peek
cannot guarantee that.
I've done some minimal performance testing and the additional ref
taking only impacted the performance in the 10% range or less, so it
doesn't really matter.
Andreas
^ permalink raw reply
* pull-request: mac80211-next 2018-03-29
From: Johannes Berg @ 2018-03-29 13:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Last update for -next, I guess, but I wanted to get the ETSI adaptivity
requirements code and the eapol-over-nl80211 thing out - both have been
around for a while. A number of other smaller things are also there, of
course.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 0466080c751ec2de9efae3ac6305225cc4326047:
Merge branch 'dsa-mv88e6xxx-some-fixes' (2018-03-20 12:29:58 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2018-03-29
for you to fetch changes up to c470bdc1aaf36669e04ba65faf1092b2d1c6cabe:
mac80211: don't WARN on bad WMM parameters from buggy APs (2018-03-29 15:02:38 +0200)
----------------------------------------------------------------
We have a fair number of patches, but many of them are from the
first bullet here:
* EAPoL-over-nl80211 from Denis - this will let us fix
some long-standing issues with bridging, races with
encryption and more
* DFS offload support from the qtnfmac folks
* regulatory database changes for the new ETSI adaptivity
requirements
* various other fixes and small enhancements
----------------------------------------------------------------
Benjamin Beichler (1):
mac80211_hwsim: fix use-after-free bug in hwsim_exit_net
Denis Kenzior (11):
cfg80211: Support all iftypes in autodisconnect_wk
nl80211: Add SOCKET_OWNER support to JOIN_IBSS
nl80211: Add SOCKET_OWNER support to JOIN_MESH
nl80211: Add SOCKET_OWNER support to START_AP
nl80211: Add CMD_CONTROL_PORT_FRAME API
nl80211: Implement TX of control port frames
nl80211: Add CONTROL_PORT_OVER_NL80211 attribute
nl80211: Add control_port_over_nl80211 for ibss
nl80211: Add control_port_over_nl80211 to mesh_setup
mac80211: Add support for tx_control_port
mac80211: Send control port frames over nl80211
Dmitry Lebed (4):
cfg80211/nl80211: add CAC_STARTED event
cfg80211/nl80211: add DFS offload flag
cfg80211: fix CAC_STARTED event handling
cfg80211: enable use of non-cleared DFS channels for DFS offload
Emmanuel Grumbach (1):
mac80211: don't WARN on bad WMM parameters from buggy APs
Haim Dreyfuss (3):
cfg80211: read wmm rules from regulatory database
mac80211: limit wmm params to comply with ETSI requirements
cfg80211: Add API to allow querying regdb for wmm_rule
Johannes Berg (4):
mac80211_hwsim: fix secondary MAC address assignment
cfg80211: don't require RTNL held for regdomain reads
mac80211: remove shadowing duplicated variable
Merge branch 'eapol-over-nl80211' into mac80211-next
Manikanta Pubbisetty (1):
mac80211: allow AP_VLAN operation on crypto controlled devices
Pradeep Kumar Chitrapu (1):
mac80211: notify driver for change in multicast rates
Tosoni (1):
mac80211: inform wireless layer when frame RSSI is invalid
tamizhr@codeaurora.org (3):
cfg80211: fix data type of sta_opmode_info parameter
mac80211: Use proper smps_mode enum in sta opmode event
mac80211: Use proper chan_width enum in sta opmode event
drivers/net/wireless/mac80211_hwsim.c | 10 +-
include/net/cfg80211.h | 76 ++++++++++++-
include/net/mac80211.h | 3 +
include/net/regulatory.h | 28 +++++
include/uapi/linux/nl80211.h | 46 +++++++-
net/mac80211/cfg.c | 12 ++
net/mac80211/ht.c | 15 +++
net/mac80211/ibss.c | 3 +-
net/mac80211/ieee80211_i.h | 12 ++
net/mac80211/iface.c | 2 +
net/mac80211/key.c | 8 +-
net/mac80211/main.c | 10 +-
net/mac80211/mesh.c | 3 +-
net/mac80211/mlme.c | 168 ++++++++++++++-------------
net/mac80211/rx.c | 45 ++++++--
net/mac80211/scan.c | 4 +-
net/mac80211/tx.c | 46 ++++++++
net/mac80211/util.c | 47 +++++++-
net/mac80211/vht.c | 32 +++++-
net/wireless/ap.c | 1 +
net/wireless/chan.c | 9 +-
net/wireless/core.h | 12 +-
net/wireless/ibss.c | 27 +----
net/wireless/mesh.c | 16 +--
net/wireless/mlme.c | 9 +-
net/wireless/nl80211.c | 205 +++++++++++++++++++++++++++++++--
net/wireless/rdev-ops.h | 15 +++
net/wireless/reg.c | 206 ++++++++++++++++++++++++++++++++--
net/wireless/sme.c | 43 +++++--
net/wireless/trace.h | 47 ++++++++
30 files changed, 979 insertions(+), 181 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH ghak32 V2 01/13] audit: add container id
From: Jonathan Corbet @ 2018-03-29 13:03 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: cgroups, containers, linux-api, Linux-Audit Mailing List,
linux-fsdevel, LKML, netdev, luto, jlayton, carlos, viro,
dhowells, simo, eparis, serge, ebiederm, madzcar
In-Reply-To: <20180329090132.r3qfomigkw3hbwbw@madcap2.tricolour.ca>
On Thu, 29 Mar 2018 05:01:32 -0400
Richard Guy Briggs <rgb@redhat.com> wrote:
> > A little detail, but still...
>
> I am understanding that you would prefer more context (as opposed to
> operational detail) in the description, laying out the use case for this
> patch(set)?
No, sorry, "a little detail" was referring to my comment. The use case,
I believe, has been well described.
Thanks,
jon
^ permalink raw reply
* Re: [EXT] [PATCH net-next v2 1/2] net: phy: phylink: Provide PHY interface to mac_link_{up,down}
From: Andrew Lunn @ 2018-03-29 12:57 UTC (permalink / raw)
To: Yan Markman
Cc: Florian Fainelli, netdev@vger.kernel.org, Thomas Petazzoni,
David S. Miller, Russell King, open list, Antoine Tenart,
Stefan Chulski, Maxime Chevallier, Miquel Raynal, Marcin Wojtas,
Yelena Krivosheev
In-Reply-To: <843035ef7cfb45a7a02be516b8fcdd49@IL-EXCH01.marvell.com>
On Thu, Mar 29, 2018 at 05:59:02AM +0000, Yan Markman wrote:
> Hi Florian
> Please keep CC Yelena Krivosheev <yelena@marvell.com>
> for changes with drivers/net/ethernet/marvell/mvneta.c
> Thanks
> Yan Markman
> Tel. 05-44732819
Hi Yan
Since you have obviously seen the patches, how about a Reviewed-by, or
a Tested-by.
Andrew
^ permalink raw reply
* [PATCH net-next 1/1] tc-testing: add connmark action tests
From: Roman Mashak @ 2018-03-29 12:52 UTC (permalink / raw)
To: davem; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri, Roman Mashak
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
.../tc-testing/tc-tests/actions/connmark.json | 291 +++++++++++++++++++++
1 file changed, 291 insertions(+)
create mode 100644 tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json
diff --git a/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json b/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json
new file mode 100644
index 000000000000..70952bd98ff9
--- /dev/null
+++ b/tools/testing/selftests/tc-testing/tc-tests/actions/connmark.json
@@ -0,0 +1,291 @@
+[
+ {
+ "id": "2002",
+ "name": "Add valid connmark action with defaults",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action connmark",
+ "matchPattern": "action order [0-9]+: connmark zone 0 pipe",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "56a5",
+ "name": "Add valid connmark action with control pass",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark pass index 1",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action connmark index 1",
+ "matchPattern": "action order [0-9]+: connmark zone 0 pass.*index 1 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "7c66",
+ "name": "Add valid connmark action with control drop",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark drop index 100",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action connmark index 100",
+ "matchPattern": "action order [0-9]+: connmark zone 0 drop.*index 100 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "a913",
+ "name": "Add valid connmark action with control pipe",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark pipe index 455",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action connmark index 455",
+ "matchPattern": "action order [0-9]+: connmark zone 0 pipe.*index 455 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "bdd8",
+ "name": "Add valid connmark action with control reclassify",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark reclassify index 7",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action connmark",
+ "matchPattern": "action order [0-9]+: connmark zone 0 reclassify.*index 7 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "b8be",
+ "name": "Add valid connmark action with control continue",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark continue index 17",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action connmark",
+ "matchPattern": "action order [0-9]+: connmark zone 0 continue.*index 17 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "d8a6",
+ "name": "Add valid connmark action with control jump",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark jump 10 index 17",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions list action connmark",
+ "matchPattern": "action order [0-9]+: connmark zone 0 jump 10.*index 17 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "aae8",
+ "name": "Add valid connmark action with zone argument",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark zone 100 pipe index 1",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action connmark index 1",
+ "matchPattern": "action order [0-9]+: connmark zone 100 pipe.*index 1 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "2f0b",
+ "name": "Add valid connmark action with invalid zone argument",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark zone 65536 reclassify index 21",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action connmark index 1",
+ "matchPattern": "action order [0-9]+: connmark zone 65536 reclassify.*index 21 ref",
+ "matchCount": "0",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "9305",
+ "name": "Add connmark action with unsupported argument",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark zone 655 unsupp_arg pass index 2",
+ "expExitCode": "255",
+ "verifyCmd": "$TC actions get action connmark index 2",
+ "matchPattern": "action order [0-9]+: connmark zone 655 unsupp_arg pass.*index 2 ref",
+ "matchCount": "0",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "71ca",
+ "name": "Add valid connmark action and replace it",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ],
+ "$TC actions add action connmark zone 777 pass index 555"
+ ],
+ "cmdUnderTest": "$TC actions replace action connmark zone 555 reclassify index 555",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action connmark index 555",
+ "matchPattern": "action order [0-9]+: connmark zone 555 reclassify.*index 555 ref",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ },
+ {
+ "id": "5f8f",
+ "name": "Add valid connmark action with cookie",
+ "category": [
+ "actions",
+ "connmark"
+ ],
+ "setup": [
+ [
+ "$TC actions flush action connmark",
+ 0,
+ 1,
+ 255
+ ]
+ ],
+ "cmdUnderTest": "$TC actions add action connmark zone 555 pipe index 5 cookie aabbccddeeff112233445566778800a1",
+ "expExitCode": "0",
+ "verifyCmd": "$TC actions get action connmark index 5",
+ "matchPattern": "action order [0-9]+: connmark zone 555 pipe.*index 5 ref.*cookie aabbccddeeff112233445566778800a1",
+ "matchCount": "1",
+ "teardown": [
+ "$TC actions flush action connmark"
+ ]
+ }
+]
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] vhost: validate log when IOTLB is enabled
From: Michael S. Tsirkin @ 2018-03-29 12:48 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <1522310404-8486-1-git-send-email-jasowang@redhat.com>
On Thu, Mar 29, 2018 at 04:00:04PM +0800, Jason Wang wrote:
> Vq log_base is the userspace address of bitmap which has nothing to do
> with IOTLB. So it needs to be validated unconditionally otherwise we
> may try use 0 as log_base which may lead to pin pages that will lead
> unexpected result (e.g trigger BUG_ON() in set_bit_to_user()).
>
> Fixes: 6b1e6cc7855b0 ("vhost: new device IOTLB API")
> Reported-by: syzbot+6304bf97ef436580fede@syzkaller.appspotmail.com
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
stable material I guess.
> ---
> drivers/vhost/vhost.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5d5a9d9..5320039 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1244,14 +1244,12 @@ static int vq_log_access_ok(struct vhost_virtqueue *vq,
> /* Caller should have vq mutex and device mutex */
> int vhost_vq_access_ok(struct vhost_virtqueue *vq)
> {
> - if (vq->iotlb) {
> - /* When device IOTLB was used, the access validation
> - * will be validated during prefetching.
> - */
> - return 1;
> - }
> - return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used) &&
> - vq_log_access_ok(vq, vq->log_base);
> + int ret = vq_log_access_ok(vq, vq->log_base);
> +
> + if (ret || vq->iotlb)
> + return ret;
> +
> + return vq_access_ok(vq, vq->num, vq->desc, vq->avail, vq->used);
> }
> EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek
From: Herbert Xu @ 2018-03-29 12:35 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: cluster-devel, netdev, linux-kernel, NeilBrown, Thomas Graf,
Tom Herbert
In-Reply-To: <20180329120612.6104-1-agruenba@redhat.com>
On Thu, Mar 29, 2018 at 02:06:10PM +0200, Andreas Gruenbacher wrote:
> Here's a second version of the patch (now a patch set) to eliminate
> rhashtable_walk_peek in gfs2.
>
> The first patch introduces lockref_put_not_zero, the inverse of
> lockref_get_not_zero.
>
> The second patch eliminates rhashtable_walk_peek in gfs2. In
> gfs2_glock_iter_next, the new lockref function from patch one is used to
> drop a lockref count as long as the count doesn't drop to zero. This is
> almost always the case; if there is a risk of dropping the last
> reference, we must defer that to a work queue because dropping the last
> reference may sleep.
In light of Neil's latest patch, do we still need this?
Thanks,
--
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
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