* Re: [PATCH] doc: clarification about setting SO_ZEROCOPY
From: Willem de Bruijn @ 2018-01-09 13:05 UTC (permalink / raw)
To: Kornilios Kourtis; +Cc: Network Development, Willem de Bruijn
In-Reply-To: <20180109085222.GA6585@yvoz.zurich.ibm.com>
On Tue, Jan 9, 2018 at 3:52 AM, Kornilios Kourtis <kou@zurich.ibm.com> wrote:
> Signed-off-by: Kornilios Kourtis <kou@zurich.ibm.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Thanks, Kornilios.
> ---
> Documentation/networking/msg_zerocopy.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/networking/msg_zerocopy.rst b/Documentation/networking/msg_zerocopy.rst
> index 77f6d7e..c3380f4 100644
> --- a/Documentation/networking/msg_zerocopy.rst
> +++ b/Documentation/networking/msg_zerocopy.rst
> @@ -72,6 +72,10 @@ this flag, a process must first signal intent by setting a socket option:
> if (setsockopt(fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one)))
> error(1, errno, "setsockopt zerocopy");
>
> +Setting the socket option only works when the socket is in its initial
> +(TCP_CLOSED) state. Trying to set the option for a socket returned by accept(),
> +for example, will lead to an EBUSY error. In this case, the option should be set
> +to the listening socket and it will be inherited by the accepted sockets.
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Andrew Lunn @ 2018-01-09 13:00 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Graeme Gregory, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <CAPv3WKehwsrxuxemgL_5fKtUT2xjqkE6yf9DMcCcO2WRJ6nQaQ@mail.gmail.com>
On Tue, Jan 09, 2018 at 11:22:00AM +0100, Marcin Wojtas wrote:
> 2018-01-09 11:19 GMT+01:00 Graeme Gregory <graeme.gregory@linaro.org>:
> > On Mon, Jan 08, 2018 at 06:17:06PM +0100, Marcin Wojtas wrote:
> >> Hi Andrew,
> >>
> >>
> >>
> >> 2018-01-08 16:42 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> >> > w> I am not familiar with MDIO, but if its similar or a specific
> >> >> implementation of a serial bus that does sound sane!
> >> >
> >>
> >> Thanks for digging, I will check if and how we can use
> >> GenericSerialBus with MDIO.
> >>
> > Maybe Lorenzo, Hanjun, Sudeep can comment here they might have come
> > across similar on other ARM boards.
> >
>
> I'm looking forward to their feedback, however, what I've noticed,
> each driver handles mdio/phys on its own, not using any generic
> solution, which is what I need to actually avoid :)
Agreed. Lets define it once for all drivers using phylib/phylink.
Andrew
^ permalink raw reply
* pull-request: wireless-drivers 2018-01-09
From: Kalle Valo @ 2018-01-09 12:59 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
My first pull request in 2018 so Happy New Year!
This is for 4.15 to the net tree. Only two fixes this time so should be
an easy pull.
This is quite late due to the holidays but it has been pretty quiet so I
guess I wasn't the only one trying to not touch the computer ;) And
Linus said that he will be releasing -rc8 anyway so this shouldn't be
that late.
Please let me know if you have any problems.
Kalle
The following changes since commit a41886f56b7bbb88e6a23b5d738a94f2632142a4:
Merge tag 'iwlwifi-for-kalle-2017-12-05' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2017-12-07 15:50:34 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2018-01-09
for you to fetch changes up to 49fdde89e2b8574cb55f99b57b7798f44567bc4b:
Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2018-01-05 14:02:36 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.15
Hopefully the last set of fixes for 4.15.
iwlwifi
* fix DMA mapping regression since v4.14
wcn36xx
* fix dynamic power save which has been broken since the driver was commited
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: pcie: fix DMA memory mapping / unmapping
Kalle Valo (1):
Merge ath-current from git://git.kernel.org/.../kvalo/ath.git
Loic Poulain (1):
wcn36xx: Fix dynamic power saving
drivers/net/wireless/ath/wcn36xx/main.c | 23 +++++++++++-----------
drivers/net/wireless/ath/wcn36xx/pmc.c | 6 ++++--
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 10 +++++++---
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 11 +++--------
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 8 ++++----
5 files changed, 30 insertions(+), 28 deletions(-)
^ permalink raw reply
* [PATCH net, v3] of_mdio: avoid MDIO bus removal when a PHY is missing
From: Madalin Bucur @ 2018-01-09 12:43 UTC (permalink / raw)
To: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Madalin Bucur
If one of the child devices is missing the of_mdiobus_register_phy()
call will return -ENODEV. When a missing device is encountered the
registration of the remaining PHYs is stopped and the MDIO bus will
fail to register. Propagate all errors except ENODEV to avoid it.
Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
---
v3: move if after else
v2: add an error print for the first change; the second place has
some noise already generated by the existing code
drivers/of/of_mdio.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 3481e69..a327be1 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -231,7 +231,12 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
rc = of_mdiobus_register_phy(mdio, child, addr);
else
rc = of_mdiobus_register_device(mdio, child, addr);
- if (rc)
+
+ if (rc == -ENODEV)
+ dev_err(&mdio->dev,
+ "MDIO device at address %d is missing.\n",
+ addr);
+ else if (rc)
goto unregister;
}
@@ -255,7 +260,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
- if (rc)
+ if (rc && rc != -ENODEV)
goto unregister;
}
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: aio poll, io_pgetevents and a new in-kernel poll API
From: Christoph Hellwig @ 2018-01-09 12:28 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-kernel
In-Reply-To: <20180104080043.14506-1-hch@lst.de>
On Thu, Jan 04, 2018 at 09:00:12AM +0100, Christoph Hellwig wrote:
> The changes were sponsored by Scylladb, and improve performance
> of the seastar framework up to 10%, while also removing the need
> for a privileged SCHED_FIFO epoll listener thread.
Due to the current events:
With KPTI enabled the aio poll code is almost 16% faster than epoll
with the special SCHED_FIFO listener thread.
The Scylladb https example is still more than 4% faster with KPTI
and aio poll vs non-KPTI with epoll.
--
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
* [PATCH bpf] bpf: avoid false sharing of map refcount with max_entries
From: Daniel Borkmann @ 2018-01-09 12:17 UTC (permalink / raw)
To: ast; +Cc: netdev, Daniel Borkmann
In addition to commit b2157399cc98 ("bpf: prevent out-of-bounds
speculation") also change the layout of struct bpf_map such that
false sharing of fast-path members like max_entries is avoided
when the maps reference counter is altered. Therefore enforce
them to be placed into separate cachelines.
pahole dump after change:
struct bpf_map {
const struct bpf_map_ops * ops; /* 0 8 */
struct bpf_map * inner_map_meta; /* 8 8 */
void * security; /* 16 8 */
enum bpf_map_type map_type; /* 24 4 */
u32 key_size; /* 28 4 */
u32 value_size; /* 32 4 */
u32 max_entries; /* 36 4 */
u32 map_flags; /* 40 4 */
u32 pages; /* 44 4 */
u32 id; /* 48 4 */
int numa_node; /* 52 4 */
bool unpriv_array; /* 56 1 */
/* XXX 7 bytes hole, try to pack */
/* --- cacheline 1 boundary (64 bytes) --- */
struct user_struct * user; /* 64 8 */
atomic_t refcnt; /* 72 4 */
atomic_t usercnt; /* 76 4 */
struct work_struct work; /* 80 32 */
char name[16]; /* 112 16 */
/* --- cacheline 2 boundary (128 bytes) --- */
/* size: 128, cachelines: 2, members: 17 */
/* sum members: 121, holes: 1, sum holes: 7 */
};
Now all entries in the first cacheline are read only throughout
the life time of the map, set up once during map creation. Overall
struct size and number of cachelines doesn't change from the
reordering. struct bpf_map is usually first member and embedded
in map structs in specific map implementations, so also avoid those
members to sit at the end where it could potentially share the
cacheline with first map values e.g. in the array since remote
CPUs could trigger map updates just as well for those (easily
dirtying members like max_entries intentionally as well) while
having subsequent values in cache.
Quoting from Goolge's Project Zero blog [1]:
Additionally, at least on the Intel machine on which this was
tested, bouncing modified cache lines between cores is slow,
apparently because the MESI protocol is used for cache coherence
[8]. Changing the reference counter of an eBPF array on one
physical CPU core causes the cache line containing the reference
counter to be bounced over to that CPU core, making reads of the
reference counter on all other CPU cores slow until the changed
reference counter has been written back to memory. Because the
length and the reference counter of an eBPF array are stored in
the same cache line, this also means that changing the reference
counter on one physical CPU core causes reads of the eBPF array's
length to be slow on other physical CPU cores (intentional false
sharing).
While this doesn't 'control' the out-of-bounds speculation through
masking the index as in commit b2157399cc98, triggering a manipulation
of the map's reference counter is really trivial, so lets not allow
to easily affect max_entries from it.
Splitting to separate cachelines also generally makes sense from
a performance perspective anyway in that fast-path won't have a
cache miss if the map gets pinned, reused in other progs, etc out
of control path, thus also avoids unintentional false sharing.
[1] https://googleprojectzero.blogspot.ch/2018/01/reading-privileged-memory-with-side.html
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/bpf.h | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 1b985ca..fe2cb7c 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -43,7 +43,14 @@ struct bpf_map_ops {
};
struct bpf_map {
- atomic_t refcnt;
+ /* 1st cacheline with read-mostly members of which some
+ * are also accessed in fast-path (e.g. ops, max_entries).
+ */
+ const struct bpf_map_ops *ops ____cacheline_aligned;
+ struct bpf_map *inner_map_meta;
+#ifdef CONFIG_SECURITY
+ void *security;
+#endif
enum bpf_map_type map_type;
u32 key_size;
u32 value_size;
@@ -53,15 +60,16 @@ struct bpf_map {
u32 id;
int numa_node;
bool unpriv_array;
- struct user_struct *user;
- const struct bpf_map_ops *ops;
- struct work_struct work;
+ /* 7 bytes hole */
+
+ /* 2nd cacheline with misc members to avoid false sharing
+ * particularly with refcounting.
+ */
+ struct user_struct *user ____cacheline_aligned;
+ atomic_t refcnt;
atomic_t usercnt;
- struct bpf_map *inner_map_meta;
+ struct work_struct work;
char name[BPF_OBJ_NAME_LEN];
-#ifdef CONFIG_SECURITY
- void *security;
-#endif
};
/* function argument constraints */
--
2.9.5
^ permalink raw reply related
* RFC(V3): Audit Kernel Container IDs
From: Richard Guy Briggs @ 2018-01-09 12:16 UTC (permalink / raw)
To: cgroups-u79uwXL29TY76Z2rM5mHXA, Linux Containers, Linux API,
Linux Audit, Linux FS Devel, Linux Kernel,
Linux Network Development
Cc: Simo Sorce, Carlos O'Donell, Aristeu Rozanski, David Howells,
Eric W. Biederman, Eric Paris, Daniel Walsh,
jlayton-H+wXaHxf7aLQT0dZR+AlfA, Andy Lutomirski,
mszeredi-H+wXaHxf7aLQT0dZR+AlfA, Paul Moore, Serge E. Hallyn,
Steve Grubb, trondmy-7I+n7zu2hftEKMMhf/gKZA, Al Viro, Madz Car
Containers are a userspace concept. The kernel knows nothing of them.
The Linux audit system needs a way to be able to track the container
provenance of events and actions. Audit needs the kernel's help to do
this.
Since the concept of a container is entirely a userspace concept, a
registration from the userspace container orchestration system initiates
this. This will define a point in time and a set of resources
associated with a particular container with an audit container
identifier.
The registration is a u64 representing the audit container identifier
written to a special file in a pseudo filesystem (proc, since PID tree
already exists) representing a process that will become a parent process
in that container. This write might place restrictions on mount
namespaces required to define a container, or at least careful checking
of namespaces in the kernel to verify permissions of the orchestrator so
it can't change its own container ID. A bind mount of nsfs may be
necessary in the container orchestrator's mount namespace. This write
can only happen once per process.
Note: The justification for using a u64 is that it minimizes the
information printed in every audit record, reducing bandwidth and limits
comparisons to a single u64 which will be faster and less error-prone.
Require CAP_AUDIT_CONTROL to be able to carry out the registration. At
that time, record the target container's user-supplied audit container
identifier along with a target container's parent process (which may
become the target container's "init" process) process ID (referenced
from the initial PID namespace) in a new record AUDIT_CONTAINER with a
qualifying op=$action field.
Issue a new auxilliary record AUDIT_CONTAINER_INFO for each valid
container ID present on an auditable action or event.
Forked and cloned processes inherit their parent's audit container
identifier, referenced in the process' task_struct. Since the audit
container identifier is inherited rather than written, it can still be
written once. This will prevent tampering while allowing nesting.
(This can be implemented with an internal settable flag upon
registration that does not get copied across a fork/clone.)
Mimic setns(2) and return an error if the process has already initiated
threading or forked since this registration should happen before the
process execution is started by the orchestrator and hence should not
yet have any threads or children. If this is deemed overly restrictive,
switch all of the target's threads and children to the new containerID.
Trust the orchestrator to judiciously use and restrict CAP_AUDIT_CONTROL.
When a container ceases to exist because the last process in that
container has exited log the fact to balance the registration action.
(This is likely needed for certification accountability.)
At this point it appears unnecessary to add a container session
identifier since this is all tracked from loginuid and sessionid to
communicate with the container orchestrator to spawn an additional
session into an existing container which would be logged. It can be
added at a later date without breaking API should it be deemed
necessary.
The following namespace logging actions are not needed for certification
purposes at this point, but are helpful for tracking namespace activity.
These are auxilliary records that are associated with namespace
manipulation syscalls unshare(2), clone(2) and setns(2), so the records
will only show up if explicit syscall rules have been added to document
this activity.
Log the creation of every namespace, inheriting/adding its spawning
process' audit container identifier(s), if applicable. Include the
spawning and spawned namespace IDs (device and inode number tuples).
[AUDIT_NS_CREATE, AUDIT_NS_DESTROY] [clone(2), unshare(2), setns(2)]
Note: At this point it appears only network namespaces may need to track
container IDs apart from processes since incoming packets may cause an
auditable event before being associated with a process. Since a
namespace can be shared by processes in different containers, the
namespace will need to track all containers to which it has been
assigned.
Upon registration, the target process' namespace IDs (in the form of a
nsfs device number and inode number tuple) will be recorded in an
AUDIT_NS_INFO auxilliary record.
Log the destruction of every namespace that is no longer used by any
process, including the namespace IDs (device and inode number tuples).
[AUDIT_NS_DESTROY] [process exit, unshare(2), setns(2)]
Issue a new auxilliary record AUDIT_NS_CHANGE listing (opt: op=$action)
the parent and child namespace IDs for any changes to a process'
namespaces. [setns(2)]
Note: It may be possible to combine AUDIT_NS_* record formats and
distinguish them with an op=$action field depending on the fields
required for each message type.
The audit container identifier will need to be reaped from all
implicated namespaces upon the destruction of a container.
This namespace information adds supporting information for tracking
events not attributable to specific processes.
Changelog:
(Upstream V3)
- switch back to u64 (from pmoore, can be expanded to u128 in future if
need arises without breaking API. u32 was originally proposed, up to
c36 discussed)
- write-once, but children inherit audit container identifier and can
then still be written once
- switch to CAP_AUDIT_CONTROL
- group namespace actions together, auxilliary records to namespace
operations.
(Upstream V2)
- switch from u64 to u128 UUID
- switch from "signal" and "trigger" to "register"
- restrict registration to single process or force all threads and
children into same container
- RGB
--
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH net-next v3 06/10] net/mlx5e: Change Mellanox references in DIM code
From: kbuild test robot @ 2018-01-09 12:08 UTC (permalink / raw)
To: Andy Gospodarek
Cc: kbuild-all, netdev, mchan, talgi, ogerlitz, Andy Gospodarek
In-Reply-To: <1515478402-6048-7-git-send-email-andy@greyhouse.net>
Hi Andy,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Andy-Gospodarek/net-create-dynamic-software-irq-moderation-library/20180109-182838
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:15: sparse: no member 'rx_am_enabled' in struct mlx5e_params
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:33: sparse: call with no type!
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:33: sparse: call with no type!
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:33: sparse: unknown expression (14 0)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:33: sparse: unknown expression (30 46)
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:33: sparse: unknown expression (14 0)
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:15: sparse: generating address of non-lvalue (8)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_build_rep_params':
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:10: error: 'struct mlx5e_params' has no member named 'rx_am_enabled'; did you mean
params->rx_am_enabled = MLX5_CAP_GEN(mdev, cq_moderation);
^~~~~~~~~~~~~
rx_dim_enabled
vim +887 drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
cb67b832 Hadar Hen Zion 2016-07-01 875
6a9764ef Saeed Mahameed 2016-12-21 876 static void mlx5e_build_rep_params(struct mlx5_core_dev *mdev,
6a9764ef Saeed Mahameed 2016-12-21 877 struct mlx5e_params *params)
cb67b832 Hadar Hen Zion 2016-07-01 878 {
cb67b832 Hadar Hen Zion 2016-07-01 879 u8 cq_period_mode = MLX5_CAP_GEN(mdev, cq_period_start_from_cqe) ?
cb67b832 Hadar Hen Zion 2016-07-01 880 MLX5_CQ_PERIOD_MODE_START_FROM_CQE :
cb67b832 Hadar Hen Zion 2016-07-01 881 MLX5_CQ_PERIOD_MODE_START_FROM_EQE;
cb67b832 Hadar Hen Zion 2016-07-01 882
6a9764ef Saeed Mahameed 2016-12-21 883 params->log_sq_size = MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE;
6a9764ef Saeed Mahameed 2016-12-21 884 params->rq_wq_type = MLX5_WQ_TYPE_LINKED_LIST;
6a9764ef Saeed Mahameed 2016-12-21 885 params->log_rq_size = MLX5E_PARAMS_MINIMUM_LOG_RQ_SIZE;
cb67b832 Hadar Hen Zion 2016-07-01 886
6a9764ef Saeed Mahameed 2016-12-21 @887 params->rx_am_enabled = MLX5_CAP_GEN(mdev, cq_moderation);
6a9764ef Saeed Mahameed 2016-12-21 888 mlx5e_set_rx_cq_mode_params(params, cq_period_mode);
cb67b832 Hadar Hen Zion 2016-07-01 889
6a9764ef Saeed Mahameed 2016-12-21 890 params->tx_max_inline = mlx5e_get_max_inline_cap(mdev);
6a9764ef Saeed Mahameed 2016-12-21 891 params->num_tc = 1;
6a9764ef Saeed Mahameed 2016-12-21 892 params->lro_wqe_sz = MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ;
5f195c2c Chris Mi 2017-05-16 893
5f195c2c Chris Mi 2017-05-16 894 mlx5_query_min_inline(mdev, ¶ms->tx_min_inline_mode);
cb67b832 Hadar Hen Zion 2016-07-01 895 }
cb67b832 Hadar Hen Zion 2016-07-01 896
:::::: The code at line 887 was first introduced by commit
:::::: 6a9764efb255f49a91e229799c38d5c1c9361987 net/mlx5e: Isolate open_channels from priv->params
:::::: TO: Saeed Mahameed <saeedm@mellanox.com>
:::::: CC: Saeed Mahameed <saeedm@mellanox.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH ipsec] xfrm: don't call xfrm_policy_cache_flush while holding spinlock
From: Steffen Klassert @ 2018-01-09 12:00 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20180106001308.12765-1-fw@strlen.de>
On Sat, Jan 06, 2018 at 01:13:08AM +0100, Florian Westphal wrote:
> xfrm_policy_cache_flush can sleep, so it cannot be called while holding
> a spinlock. We could release the lock first, but I don't see why we need
> to invoke this function here in first place, the packet path won't reuse
> an xdst entry unless its still valid.
>
> While at it, add an annotation to xfrm_policy_cache_flush, it would
> have probably caught this bug sooner.
>
> Fixes: ec30d78c14a813 ("xfrm: add xdst pcpu cache")
> Reported-by: syzbot+e149f7d1328c26f9c12f@syzkaller.appspotmail.com
> Signed-off-by: Florian Westphal <fw@strlen.de>
Applied, thanks a lot!
^ permalink raw reply
* Re: [PATCH v2] xfrm: Return error on unknown encap_type in init_state
From: Steffen Klassert @ 2018-01-09 11:59 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20180105111232.GA15350@gondor.apana.org.au>
On Fri, Jan 05, 2018 at 10:12:32PM +1100, Herbert Xu wrote:
> On Fri, Jan 05, 2018 at 09:32:47AM +0100, Steffen Klassert wrote:
> >
> > Looks like we catch the unknown mode in __xfrm_init_state().
> > But in any case, if we want to return -EINVAL on unknown mode,
> > we should do it for IPv6 and for IPv4.
>
> OK, how about this one then:
>
> ---8<---
> Currently esp will happily create an xfrm state with an unknown
> encap type for IPv4, without setting the necessary state parameters.
> This patch fixes it by returning -EINVAL.
>
> There is a similar problem in IPv6 where if the mode is unknown
> we will skip initialisation while returning zero. However, this
> is harmless as the mode has already been checked further up the
> stack. This patch removes this anomaly by aligning the IPv6
> behaviour with IPv4 and treating unknown modes (which cannot
> actually happen) as transport mode.
>
> Fixes: 38320c70d282 ("[IPSEC]: Use crypto_aead and authenc in ESP")
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Patch applied, thanks Herbert!
^ permalink raw reply
* [PATCH] caif_usb: use strlcpy() instead of strncpy()
From: Xiongfeng Wang @ 2018-01-09 11:58 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, wangxiongfeng2
From: Xiongfeng Wang <xiongfeng.wang@linaro.org>
gcc-8 reports
net/caif/caif_usb.c: In function 'cfusbl_device_notify':
./include/linux/string.h:245:9: warning: '__builtin_strncpy' output may
be truncated copying 15 bytes from a string of length 15
[-Wstringop-truncation]
The compiler require that the input param 'len' of strncpy() should be
greater than the length of the src string, so that '\0' is copied as
well. We can just use strlcpy() to avoid this warning.
Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>
---
net/caif/caif_usb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
index 5cd44f0..1a082a9 100644
--- a/net/caif/caif_usb.c
+++ b/net/caif/caif_usb.c
@@ -176,9 +176,7 @@ static int cfusbl_device_notify(struct notifier_block *me, unsigned long what,
dev_add_pack(&caif_usb_type);
pack_added = true;
- strncpy(layer->name, dev->name,
- sizeof(layer->name) - 1);
- layer->name[sizeof(layer->name) - 1] = 0;
+ strlcpy(layer->name, dev->name, sizeof(layer->name));
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next v3 06/10] net/mlx5e: Change Mellanox references in DIM code
From: kbuild test robot @ 2018-01-09 11:12 UTC (permalink / raw)
To: Andy Gospodarek
Cc: kbuild-all, netdev, mchan, talgi, ogerlitz, Andy Gospodarek
In-Reply-To: <1515478402-6048-7-git-send-email-andy@greyhouse.net>
[-- Attachment #1: Type: text/plain, Size: 3105 bytes --]
Hi Andy,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Andy-Gospodarek/net-create-dynamic-software-irq-moderation-library/20180109-182838
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All errors (new ones prefixed by >>):
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_build_rep_params':
>> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:887:10: error: 'struct mlx5e_params' has no member named 'rx_am_enabled'; did you mean 'rx_dim_enabled'?
params->rx_am_enabled = MLX5_CAP_GEN(mdev, cq_moderation);
^~~~~~~~~~~~~
rx_dim_enabled
vim +887 drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
cb67b832 Hadar Hen Zion 2016-07-01 875
6a9764ef Saeed Mahameed 2016-12-21 876 static void mlx5e_build_rep_params(struct mlx5_core_dev *mdev,
6a9764ef Saeed Mahameed 2016-12-21 877 struct mlx5e_params *params)
cb67b832 Hadar Hen Zion 2016-07-01 878 {
cb67b832 Hadar Hen Zion 2016-07-01 879 u8 cq_period_mode = MLX5_CAP_GEN(mdev, cq_period_start_from_cqe) ?
cb67b832 Hadar Hen Zion 2016-07-01 880 MLX5_CQ_PERIOD_MODE_START_FROM_CQE :
cb67b832 Hadar Hen Zion 2016-07-01 881 MLX5_CQ_PERIOD_MODE_START_FROM_EQE;
cb67b832 Hadar Hen Zion 2016-07-01 882
6a9764ef Saeed Mahameed 2016-12-21 883 params->log_sq_size = MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE;
6a9764ef Saeed Mahameed 2016-12-21 884 params->rq_wq_type = MLX5_WQ_TYPE_LINKED_LIST;
6a9764ef Saeed Mahameed 2016-12-21 885 params->log_rq_size = MLX5E_PARAMS_MINIMUM_LOG_RQ_SIZE;
cb67b832 Hadar Hen Zion 2016-07-01 886
6a9764ef Saeed Mahameed 2016-12-21 @887 params->rx_am_enabled = MLX5_CAP_GEN(mdev, cq_moderation);
6a9764ef Saeed Mahameed 2016-12-21 888 mlx5e_set_rx_cq_mode_params(params, cq_period_mode);
cb67b832 Hadar Hen Zion 2016-07-01 889
6a9764ef Saeed Mahameed 2016-12-21 890 params->tx_max_inline = mlx5e_get_max_inline_cap(mdev);
6a9764ef Saeed Mahameed 2016-12-21 891 params->num_tc = 1;
6a9764ef Saeed Mahameed 2016-12-21 892 params->lro_wqe_sz = MLX5E_PARAMS_DEFAULT_LRO_WQE_SZ;
5f195c2c Chris Mi 2017-05-16 893
5f195c2c Chris Mi 2017-05-16 894 mlx5_query_min_inline(mdev, ¶ms->tx_min_inline_mode);
cb67b832 Hadar Hen Zion 2016-07-01 895 }
cb67b832 Hadar Hen Zion 2016-07-01 896
:::::: The code at line 887 was first introduced by commit
:::::: 6a9764efb255f49a91e229799c38d5c1c9361987 net/mlx5e: Isolate open_channels from priv->params
:::::: TO: Saeed Mahameed <saeedm@mellanox.com>
:::::: CC: Saeed Mahameed <saeedm@mellanox.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49872 bytes --]
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Arend van Spriel @ 2018-01-09 11:11 UTC (permalink / raw)
To: Jia-Ju Bai, Greg KH, Larry.Finger
Cc: kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <555069e4-dd2c-b17a-d44f-9258558cb98d@gmail.com>
On 1/9/2018 10:47 AM, Jia-Ju Bai wrote:
>
>
> On 2018/1/9 17:07, Arend van Spriel wrote:
>> On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>>>
>>>
>>> On 2018/1/9 16:35, Greg KH wrote:
>>>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>>>>> b43_radio_2057_init_post is not called in an interrupt handler
>>>>> nor holding a spinlock.
>>>>> The function mdelay in it can be replaced with usleep_range,
>>>>> to reduce busy wait.
>>>>>
>>>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>>>> ---
>>>>> v2:
>>>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>>>> Thank Larry for good advice.
>>>>> ---
>>>>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>>>> index a5557d7..f2a2f41 100644
>>>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>>>> b43_wldev *dev)
>>>>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>>>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>>>> - mdelay(2);
>>>>> + usleep_range(2000, 3000);
>>>> Where did 3000 come from? Are you sure about that?
>>>
>>> I am not very sure, and I use it according to Larry's message:
>>
>> Hi Jia-Ju Bai,
>>
>> The duration here is for settling the registers so hardware can pick
>> it up. Right after this they are written again. Now this is during
>> initialization of the radio so not time critical, but probably
>> anything in the range of 2000..3000 would also have been fine.
>
> Hi Arend,
>
> Thanks for your detailed explanation :)
> So I think usleep_range(2000, 3000) is okay.
Sure.
Regards,
Arend
^ permalink raw reply
* [PATCH] net: phy: Fix phy_modify() semantic difference fallout
From: Geert Uytterhoeven @ 2018-01-09 11:11 UTC (permalink / raw)
To: Russell King, David S . Miller, Andrew Lunn, Florian Fainelli
Cc: netdev, linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In case of success, the return values of (__)phy_write() and
(__)phy_modify() are not compatible: (__)phy_write() returns 0, while
(__)phy_modify() returns the old PHY register value.
Apparently this change was catered for in drivers/net/phy/marvell.c, but
not in other source files.
Hence genphy_restart_aneg() now returns 4416 instead zero, which is
considered an error:
ravb e6800000.ethernet eth0: failed to connect PHY
IP-Config: Failed to open eth0
IP-Config: No network devices available
Fix this by converting positive values to zero in all callers of
phy_modify().
Fixes: fea23fb591cce995 ("net: phy: convert read-modify-write to phy_modify()")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Alternatively, __phy_modify() could be changed to follow __phy_write()
semantics?
---
drivers/net/phy/at803x.c | 4 +++-
drivers/net/phy/phy_device.c | 29 +++++++++++++++++++++--------
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index 411cf1072bae5796..6b6b9cef517f1bc3 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -230,7 +230,9 @@ static int at803x_suspend(struct phy_device *phydev)
static int at803x_resume(struct phy_device *phydev)
{
- return phy_modify(phydev, MII_BMCR, BMCR_PDOWN | BMCR_ISOLATE, 0);
+ int ret = phy_modify(phydev, MII_BMCR, BMCR_PDOWN | BMCR_ISOLATE, 0);
+
+ return ret < 0 ? ret : 0;
}
static int at803x_probe(struct phy_device *phydev)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 6bd11a070ec8147b..a132e845e4aec3d5 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1369,6 +1369,7 @@ static int genphy_config_eee_advert(struct phy_device *phydev)
int genphy_setup_forced(struct phy_device *phydev)
{
u16 ctl = 0;
+ int ret;
phydev->pause = 0;
phydev->asym_pause = 0;
@@ -1381,8 +1382,12 @@ int genphy_setup_forced(struct phy_device *phydev)
if (DUPLEX_FULL == phydev->duplex)
ctl |= BMCR_FULLDPLX;
- return phy_modify(phydev, MII_BMCR,
- BMCR_LOOPBACK | BMCR_ISOLATE | BMCR_PDOWN, ctl);
+ ret = phy_modify(phydev, MII_BMCR,
+ BMCR_LOOPBACK | BMCR_ISOLATE | BMCR_PDOWN, ctl);
+ if (ret < 0)
+ return ret;
+
+ return 0;
}
EXPORT_SYMBOL(genphy_setup_forced);
@@ -1393,8 +1398,10 @@ EXPORT_SYMBOL(genphy_setup_forced);
int genphy_restart_aneg(struct phy_device *phydev)
{
/* Don't isolate the PHY if we're negotiating */
- return phy_modify(phydev, MII_BMCR, BMCR_ISOLATE,
- BMCR_ANENABLE | BMCR_ANRESTART);
+ int ret = phy_modify(phydev, MII_BMCR, BMCR_ISOLATE,
+ BMCR_ANENABLE | BMCR_ANRESTART);
+
+ return ret < 0 ? ret : 0;
}
EXPORT_SYMBOL(genphy_restart_aneg);
@@ -1660,20 +1667,26 @@ EXPORT_SYMBOL(genphy_config_init);
int genphy_suspend(struct phy_device *phydev)
{
- return phy_modify(phydev, MII_BMCR, 0, BMCR_PDOWN);
+ int ret = phy_modify(phydev, MII_BMCR, 0, BMCR_PDOWN);
+
+ return ret < 0 ? ret : 0;
}
EXPORT_SYMBOL(genphy_suspend);
int genphy_resume(struct phy_device *phydev)
{
- return phy_modify(phydev, MII_BMCR, BMCR_PDOWN, 0);
+ int ret = phy_modify(phydev, MII_BMCR, BMCR_PDOWN, 0);
+
+ return ret < 0 ? ret : 0;
}
EXPORT_SYMBOL(genphy_resume);
int genphy_loopback(struct phy_device *phydev, bool enable)
{
- return phy_modify(phydev, MII_BMCR, BMCR_LOOPBACK,
- enable ? BMCR_LOOPBACK : 0);
+ int ret = phy_modify(phydev, MII_BMCR, BMCR_LOOPBACK,
+ enable ? BMCR_LOOPBACK : 0);
+
+ return ret < 0 ? ret : 0;
}
EXPORT_SYMBOL(genphy_loopback);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] vhost_net: batch used ring update in rx
From: Jason Wang @ 2018-01-09 10:27 UTC (permalink / raw)
To: mst, kvm, virtualization, netdev, linux-kernel; +Cc: willemb, Jason Wang
This patch tries to batched used ring update during RX. This is pretty
fit for the case when guest is much faster (e.g dpdk based
backend). In this case, used ring is almost empty:
- we may get serious cache line misses/contending on both used ring
and used idx.
- at most 1 packet could be dequeued at one time, batching in guest
does not make much effect.
Update used ring in a batch can help since guest won't access the used
ring until used idx was advanced for several descriptors and since we
advance used ring for every N packets, guest will only need to access
used idx for every N packet since it can cache the used idx. To have a
better interaction for both batch dequeuing and dpdk batching,
VHOST_RX_BATCH was used as the maximum number of descriptors that
could be batched.
Test were done between two machines with 2.40GHz Intel(R) Xeon(R) CPU
E5-2630 connected back to back through ixgbe. Traffic were generated
on one remote ixgbe through MoonGen and measure the RX pps through
testpmd in guest when do xdp_redirect_map from local ixgbe to
tap. RX pps were increased from 3.05 Mpps to 4.00 Mpps (about 31%
improvement).
One possible concern for this is the implications for TCP (especially
latency sensitive workload). Result[1] does not show obvious changes
for most of the netperf test (RR, TX, and RX). And we do get some
improvements for RX on some specific size.
Guest RX:
size/sessions/+thu%/+normalize%
64/ 1/ +2%/ +2%
64/ 2/ +2%/ -1%
64/ 4/ +1%/ +1%
64/ 8/ 0%/ 0%
256/ 1/ +6%/ -3%
256/ 2/ -3%/ +2%
256/ 4/ +11%/ +11%
256/ 8/ 0%/ 0%
512/ 1/ +4%/ 0%
512/ 2/ +2%/ +2%
512/ 4/ 0%/ -1%
512/ 8/ -8%/ -8%
1024/ 1/ -7%/ -17%
1024/ 2/ -8%/ -7%
1024/ 4/ +1%/ 0%
1024/ 8/ 0%/ 0%
2048/ 1/ +30%/ +14%
2048/ 2/ +46%/ +40%
2048/ 4/ 0%/ 0%
2048/ 8/ 0%/ 0%
4096/ 1/ +23%/ +22%
4096/ 2/ +26%/ +23%
4096/ 4/ 0%/ +1%
4096/ 8/ 0%/ 0%
16384/ 1/ -2%/ -3%
16384/ 2/ +1%/ -4%
16384/ 4/ -1%/ -3%
16384/ 8/ 0%/ -1%
65535/ 1/ +15%/ +7%
65535/ 2/ +4%/ +7%
65535/ 4/ 0%/ +1%
65535/ 8/ 0%/ 0%
TCP_RR:
size/sessions/+thu%/+normalize%
1/ 1/ 0%/ +1%
1/ 25/ +2%/ +1%
1/ 50/ +4%/ +1%
64/ 1/ 0%/ -4%
64/ 25/ +2%/ +1%
64/ 50/ 0%/ -1%
256/ 1/ 0%/ 0%
256/ 25/ 0%/ 0%
256/ 50/ +4%/ +2%
Guest TX:
size/sessions/+thu%/+normalize%
64/ 1/ +4%/ -2%
64/ 2/ -6%/ -5%
64/ 4/ +3%/ +6%
64/ 8/ 0%/ +3%
256/ 1/ +15%/ +16%
256/ 2/ +11%/ +12%
256/ 4/ +1%/ 0%
256/ 8/ +5%/ +5%
512/ 1/ -1%/ -6%
512/ 2/ 0%/ -8%
512/ 4/ -2%/ +4%
512/ 8/ +6%/ +9%
1024/ 1/ +3%/ +1%
1024/ 2/ +3%/ +9%
1024/ 4/ 0%/ +7%
1024/ 8/ 0%/ +7%
2048/ 1/ +8%/ +2%
2048/ 2/ +3%/ -1%
2048/ 4/ -1%/ +11%
2048/ 8/ +3%/ +9%
4096/ 1/ +8%/ +8%
4096/ 2/ 0%/ -7%
4096/ 4/ +4%/ +4%
4096/ 8/ +2%/ +5%
16384/ 1/ -3%/ +1%
16384/ 2/ -1%/ -12%
16384/ 4/ -1%/ +5%
16384/ 8/ 0%/ +1%
65535/ 1/ 0%/ -3%
65535/ 2/ +5%/ +16%
65535/ 4/ +1%/ +2%
65535/ 8/ +1%/ -1%
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index c7bdeb6..988af72 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -744,7 +744,7 @@ static void handle_rx(struct vhost_net *net)
};
size_t total_len = 0;
int err, mergeable;
- s16 headcount;
+ s16 headcount, nheads = 0;
size_t vhost_hlen, sock_hlen;
size_t vhost_len, sock_len;
struct socket *sock;
@@ -772,7 +772,7 @@ static void handle_rx(struct vhost_net *net)
while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk))) {
sock_len += sock_hlen;
vhost_len = sock_len + vhost_hlen;
- headcount = get_rx_bufs(vq, vq->heads, vhost_len,
+ headcount = get_rx_bufs(vq, vq->heads + nheads, vhost_len,
&in, vq_log, &log,
likely(mergeable) ? UIO_MAXIOV : 1);
/* On error, stop handling until the next kick. */
@@ -844,8 +844,12 @@ static void handle_rx(struct vhost_net *net)
vhost_discard_vq_desc(vq, headcount);
goto out;
}
- vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
- headcount);
+ nheads += headcount;
+ if (nheads > VHOST_RX_BATCH) {
+ vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
+ nheads);
+ nheads = 0;
+ }
if (unlikely(vq_log))
vhost_log_write(vq, vq_log, log, vhost_len);
total_len += vhost_len;
@@ -856,6 +860,9 @@ static void handle_rx(struct vhost_net *net)
}
vhost_net_enable_vq(net, vq);
out:
+ if (nheads)
+ vhost_add_used_and_signal_n(&net->dev, vq, vq->heads,
+ nheads);
mutex_unlock(&vq->mutex);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-09 10:22 UTC (permalink / raw)
To: Graeme Gregory
Cc: Andrew Lunn, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia, Nadav Haklai
In-Reply-To: <20180109101941.GD31502@xora-haswell>
2018-01-09 11:19 GMT+01:00 Graeme Gregory <graeme.gregory@linaro.org>:
> On Mon, Jan 08, 2018 at 06:17:06PM +0100, Marcin Wojtas wrote:
>> Hi Andrew,
>>
>>
>>
>> 2018-01-08 16:42 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
>> > w> I am not familiar with MDIO, but if its similar or a specific
>> >> implementation of a serial bus that does sound sane!
>> >
>>
>> Thanks for digging, I will check if and how we can use
>> GenericSerialBus with MDIO.
>>
> Maybe Lorenzo, Hanjun, Sudeep can comment here they might have come
> across similar on other ARM boards.
>
I'm looking forward to their feedback, however, what I've noticed,
each driver handles mdio/phys on its own, not using any generic
solution, which is what I need to actually avoid :)
Best regards,
Marcin
^ permalink raw reply
* Re: [PATCH bpf] bpf: prevent out-of-bounds speculation
From: Will Deacon @ 2018-01-09 10:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mark Rutland, Alexei Starovoitov, David S . Miller,
Daniel Borkmann, Jann Horn, Dan Williams, Peter Zijlstra,
Elena Reshetova, Alan Cox, Network Development, kernel-team
In-Reply-To: <CA+55aFz0tsreoa=5Ud2noFCpng-dizLBhT9WU9asyhpLfjdcYA@mail.gmail.com>
Hi Linus,
On Mon, Jan 08, 2018 at 10:49:01AM -0800, Linus Torvalds wrote:
> On Mon, Jan 8, 2018 at 9:05 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > I'm a little worried that in the presence of some CPU/compiler
> > optimisations, the masking may effectively be skipped under speculation.
> > So I'm not sure how robust this is going to be.
>
> Honestly, I think the masking is a hell of a lot more robust than any
> of the "official" fixes.
>
> More generic data speculation (as opposed to control speculation) is
>
> (a) mainly academic masturbation
>
> (b) hasn't even been shown to be a good idea even in _theory_ yet
> (except for the "completely unreal hardware" kind of theory where
> people assume some data oracle)
>
> (c) isn't actually done in any real CPU's today that I'm aware of
> (unless you want to call the return stack data speculation).
>
> and the thing is, we should really not then worry about "... but maybe
> future CPU's will be more aggressive", which is the traditional worry
> in these kinds of cases.
>
> Why? Because quite honestly, any future CPU's that are more aggressive
> about speculating things like this are broken shit that we should call
> out as such, and tell people not to use.
>
> Seriously.
>
> In this particular case, we should be very much aware of future CPU's
> being more _constrained_, because CPU vendors had better start taking
> this thing into account.
>
> So the masking approach is FUNDAMENTALLY SAFER than the "let's try to
> limit control speculation".
>
> If somebody can point to a CPU that actually speculates across an
> address masking operation, I will be very surprised. And unless you
> can point to that, then stop trying to dismiss the masking approach.
Whilst I agree with your comments about future CPUs, this stuff is further
out of academia than you might think. We're definitely erring on the
belt-and-braces side of things at the moment, so let me go check what's
*actually* been built and I suspect we'll be able to make the masking work.
Stay tuned...
Will
^ permalink raw reply
* Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Graeme Gregory @ 2018-01-09 10:19 UTC (permalink / raw)
To: Marcin Wojtas
Cc: Andrew Lunn, Ard Biesheuvel, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
<netdev@vger.kernel.org>, David S. Miller,
Russell King - ARM Linux, Rafael J. Wysocki, Florian Fainelli,
Antoine Ténart, Thomas Petazzoni, Gregory CLEMENT,
Ezequiel Garcia
In-Reply-To: <CAPv3WKewA+7WabMYN1w=9fOxe6zOKDbxcjX0VipumQmfZtJKjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
On Mon, Jan 08, 2018 at 06:17:06PM +0100, Marcin Wojtas wrote:
> Hi Andrew,
>
>
>
> 2018-01-08 16:42 GMT+01:00 Andrew Lunn <andrew@lunn.ch>:
> > w> I am not familiar with MDIO, but if its similar or a specific
> >> implementation of a serial bus that does sound sane!
> >
>
> Thanks for digging, I will check if and how we can use
> GenericSerialBus with MDIO.
>
Maybe Lorenzo, Hanjun, Sudeep can comment here they might have come
across similar on other ARM boards.
Graeme
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution
From: Greg KH @ 2018-01-09 10:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Dan Williams, linux-kernel, linux-arch, alan, peterz, netdev,
tglx, Mauro Carvalho Chehab, torvalds, Elena Reshetova,
linux-media
In-Reply-To: <7187306.jmXyF4vJKt@avalon>
On Tue, Jan 09, 2018 at 10:40:21AM +0200, Laurent Pinchart wrote:
> On Saturday, 6 January 2018 11:40:26 EET Greg KH wrote:
> > On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> >
> > While I'm all for fixing this type of thing, I feel like we need to do
> > something "else" for this as playing whack-a-mole for this pattern is
> > going to be a never-ending battle for all drivers for forever.
>
> That's my concern too, as even if we managed to find and fix all the
> occurrences of the problematic patterns (and we won't), new ones will keep
> being merged all the time.
And what about the millions of lines of out-of-tree drivers that we all
rely on every day in our devices? What about the distro kernels that
add random new drivers?
We need some sort of automated way to scan for this.
Intel, any chance we can get your coverity rules? Given that the date
of this original patchset was from last August, has anyone looked at
what is now in Linus's tree? What about linux-next? I just added 3
brand-new driver subsystems to the kernel tree there, how do we know
there isn't problems in them?
And what about all of the other ways user-data can be affected? Again,
as Peter pointed out, USB devices. I want some chance to be able to at
least audit the codebase we have to see if that path is an issue.
Without any hint of how to do this in an automated manner, we are all
in deep shit for forever.
> > Either we need some way to mark this data path to make it easy for tools
> > like sparse to flag easily, or we need to catch the issue in the driver
> > subsystems, which unfortunatly, would harm the drivers that don't have
> > this type of issue (like here.)
>
> But how would you do so ?
I do not know, it all depends on the access pattern, right?
> > I'm guessing that other operating systems, which don't have the luxury
> > of auditing all of their drivers are going for the "big hammer in the
> > subsystem" type of fix, right?
>
> Other operating systems that ship closed-source drivers authored by hardware
> vendors and not reviewed by third parties will likely stay vulnerable forever.
> That's a small concern though as I expect those drivers to contain much large
> security holes anyway.
Well yes, but odds are those operating systems are doing something to
mitigate this, right? Slowing down all user/kernel data paths?
Targeted code analysis tools? Something else? I doubt they just don't
care at all about it. At the least, I would think Coverity would be
trying to sell licenses for this :(
thanks,
greg k-h
^ permalink raw reply
* Re: AM43x boot broken on linux-next
From: Keerthy @ 2018-01-09 9:52 UTC (permalink / raw)
To: linux-omap; +Cc: Grygorii Strashko, netdev
In-Reply-To: <bf1fc3d2-b882-7850-4afd-c1e753e2a1a7@ti.com>
On Tuesday 09 January 2018 02:03 PM, Keerthy wrote:
> Hi,
Adding netdev@vger.kernel.org
>
> Seems like AM437x boot is broken on latest linux-next.
> Log here:
>
> https://pastebin.ubuntu.com/26351906/
>
> "Unable to handle kernel paging request at virtual address 000013e8
> [ 2.367045] pgd = c0350bf7
> [ 2.370019] [000013e8] *pgd=00000000
> [ 2.373823] Internal error: Oops: 5 [#1] SMP ARM
> [ 2.378709] Modules linked in:
> [ 2.381949] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.15.0-rc6-next-20180108-38410-g895c0dd #4
> [ 2.391242] Hardware name: Generic AM43 (Flattened Device Tree)
> [ 2.397523] PC is at phy_attached_print+0xc/0x10c
> [ 2.402506] LR is at cpsw_slave_open+0x16c/0x258"
>
> Regards,
> Keerthy
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] net: Fix netdev_WARN_ONCE macro
From: Gal Pressman @ 2018-01-09 9:51 UTC (permalink / raw)
To: David Miller, joe; +Cc: netdev, tariqt, saeedm
In-Reply-To: <20180108.220541.1359488060683672177.davem@davemloft.net>
On 09-Jan-18 05:05, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Mon, 08 Jan 2018 18:42:01 -0800
>
>> On Sun, 2018-01-07 at 12:08 +0200, Gal Pressman wrote:
>>> netdev_WARN_ONCE is broken (whoops..), this fix will remove the
>>> unnecessary "condition" parameter, add the missing comma and change
>>> "arg" to "args".
>>>
>>> Fixes: 375ef2b1f0d0 ("net: Introduce netdev_*_once functions")
>>> Signed-off-by: Gal Pressman <galp@mellanox.com>
>>> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com>
>>> ---
>>> include/linux/netdevice.h | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>> index 352066e..5ff1ef9 100644
>>> --- a/include/linux/netdevice.h
>>> +++ b/include/linux/netdevice.h
>>> @@ -4407,8 +4407,8 @@ do { \
>>> WARN(1, "netdevice: %s%s\n" format, netdev_name(dev), \
>>> netdev_reg_state(dev), ##args)
>>>
>>> -#define netdev_WARN_ONCE(dev, condition, format, arg...) \
>>> - WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev) \
>>> +#define netdev_WARN_ONCE(dev, format, args...) \
>>> + WARN_ONCE(1, "netdevice: %s%s\n" format, netdev_name(dev), \
>>
>> You sure you want the newline before the format?
>
> Hmmm, Gal please send me a relative fix for this.
>
The newline is removed in the next patch, which handles the formatting of both macros.
Do you want to remove it as part of this bug fix?
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Jia-Ju Bai @ 2018-01-09 9:47 UTC (permalink / raw)
To: Arend van Spriel, Greg KH, Larry.Finger
Cc: kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <5A54864A.8020006@broadcom.com>
On 2018/1/9 17:07, Arend van Spriel wrote:
> On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>>
>>
>> On 2018/1/9 16:35, Greg KH wrote:
>>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>>>> b43_radio_2057_init_post is not called in an interrupt handler
>>>> nor holding a spinlock.
>>>> The function mdelay in it can be replaced with usleep_range,
>>>> to reduce busy wait.
>>>>
>>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>>> ---
>>>> v2:
>>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>>> Thank Larry for good advice.
>>>> ---
>>>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> index a5557d7..f2a2f41 100644
>>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>>> b43_wldev *dev)
>>>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>>> - mdelay(2);
>>>> + usleep_range(2000, 3000);
>>> Where did 3000 come from? Are you sure about that?
>>
>> I am not very sure, and I use it according to Larry's message:
>
> Hi Jia-Ju Bai,
>
> The duration here is for settling the registers so hardware can pick
> it up. Right after this they are written again. Now this is during
> initialization of the radio so not time critical, but probably
> anything in the range of 2000..3000 would also have been fine.
Hi Arend,
Thanks for your detailed explanation :)
So I think usleep_range(2000, 3000) is okay.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Steffen Klassert @ 2018-01-09 9:26 UTC (permalink / raw)
To: Tobias Hommel; +Cc: netdev
In-Reply-To: <20180109090651.wuxcdju5ynlkq25l@arbeitstier>
On Tue, Jan 09, 2018 at 10:06:51AM +0100, Tobias Hommel wrote:
> >
> > You have CONFIG_INET_ESP_OFFLOAD enabled, this is new maybe it
> > still has some problems. You should not hit an offload codepath
> > because all your SAs are configured with UDP encapsulation which
> > is still not supported with offload.
> >
> > Please try to disable GRO on both interfaces and see what happens:
> >
> > ethtool -K eth0 gro off
> > ethtool -K eth1 gro off
> I actually already tried that with only eth1 off, to verify I turned offloading
> off for both interfaces. The same problem: see attached panic.gro_off.log
>
> >
> > Then disable CONFIG_INET_ESP_OFFLOAD and try again.
> Rebuild with CONFIG_INET_ESP_OFFLOAD disabled, same problem: see attached
> panic.esp_offload_disabled.log
So ESP offload is not the problem. Next thing that comes to my mind
is the flowcache removal, this was introduced with v4.14.
>
> >
> > This should show us if this feature is responsible for the bug.
> >
>
> I will try narrowing down the problem by trying out some older kernels for now.
Thanks!
Let me know about the results.
^ permalink raw reply
* Re: [v2] net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Fabio Estevam @ 2018-01-09 9:15 UTC (permalink / raw)
To: Yangbo Lu; +Cc: Claudiu Manoil, Richard Cochran, netdev, linux-kernel
In-Reply-To: <20180109030233.16013-1-yangbo.lu@nxp.com>
On Tue, Jan 9, 2018 at 1:02 AM, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> set_fipers() calling should be protected by spinlock in
> case that any interrupt breaks related registers setting
> and the function we expect. This patch is to move set_fipers()
> to spinlock protecting area in ptp_gianfar_adjtime().
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v2:
> - explained why spinlock was needed in commit message.
Thanks for improving the commit log:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] b43: Replace mdelay with usleep_range in b43_radio_2057_init_post
From: Arend van Spriel @ 2018-01-09 9:07 UTC (permalink / raw)
To: Jia-Ju Bai, Greg KH
Cc: Larry.Finger, kvalo, kstewart, johannes.berg, tiwai, colin.king,
andrew.zaborowski, linux-kernel, linux-wireless, netdev, b43-dev
In-Reply-To: <4201e8cd-81ba-ab7d-2a0d-af957c5dfed6@gmail.com>
On 1/9/2018 9:39 AM, Jia-Ju Bai wrote:
>
>
> On 2018/1/9 16:35, Greg KH wrote:
>> On Tue, Jan 09, 2018 at 09:40:06AM +0800, Jia-Ju Bai wrote:
>>> b43_radio_2057_init_post is not called in an interrupt handler
>>> nor holding a spinlock.
>>> The function mdelay in it can be replaced with usleep_range,
>>> to reduce busy wait.
>>>
>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>> ---
>>> v2:
>>> * Replace mdelay with usleep_range, instead of msleep in v1.
>>> Thank Larry for good advice.
>>> ---
>>> drivers/net/wireless/broadcom/b43/phy_n.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> index a5557d7..f2a2f41 100644
>>> --- a/drivers/net/wireless/broadcom/b43/phy_n.c
>>> +++ b/drivers/net/wireless/broadcom/b43/phy_n.c
>>> @@ -1031,7 +1031,7 @@ static void b43_radio_2057_init_post(struct
>>> b43_wldev *dev)
>>> b43_radio_set(dev, R2057_RFPLL_MISC_CAL_RESETN, 0x78);
>>> b43_radio_set(dev, R2057_XTAL_CONFIG2, 0x80);
>>> - mdelay(2);
>>> + usleep_range(2000, 3000);
>> Where did 3000 come from? Are you sure about that?
>
> I am not very sure, and I use it according to Larry's message:
Hi Jia-Ju Bai,
The duration here is for settling the registers so hardware can pick it
up. Right after this they are written again. Now this is during
initialization of the radio so not time critical, but probably anything
in the range of 2000..3000 would also have been fine.
Regards,
Arend
^ 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