* [PATCH net-next] net/ipv6: Fix ip6_convert_metrics() bug
From: Eric Dumazet @ 2018-04-19 16:14 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, David Ahern
If ip6_convert_metrics() fails to allocate memory, it should not
overwrite rt->fib6_metrics or we risk a crash later as syzbot found.
BUG: KASAN: null-ptr-deref in atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
BUG: KASAN: null-ptr-deref in refcount_sub_and_test+0x92/0x330 lib/refcount.c:179
Read of size 4 at addr 0000000000000044 by task syzkaller832429/4487
CPU: 1 PID: 4487 Comm: syzkaller832429 Not tainted 4.16.0+ #6
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
kasan_report_error mm/kasan/report.c:352 [inline]
kasan_report.cold.7+0x6d/0x2fe mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
atomic_read include/asm-generic/atomic-instrumented.h:21 [inline]
refcount_sub_and_test+0x92/0x330 lib/refcount.c:179
refcount_dec_and_test+0x1a/0x20 lib/refcount.c:212
fib6_info_destroy+0x2d0/0x3c0 net/ipv6/ip6_fib.c:206
fib6_info_release include/net/ip6_fib.h:304 [inline]
ip6_route_info_create+0x677/0x3240 net/ipv6/route.c:3020
ip6_route_add+0x23/0xb0 net/ipv6/route.c:3030
inet6_rtm_newroute+0x142/0x160 net/ipv6/route.c:4406
rtnetlink_rcv_msg+0x466/0xc10 net/core/rtnetlink.c:4648
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4666
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:639
___sys_sendmsg+0x805/0x940 net/socket.c:2117
__sys_sendmsg+0x115/0x270 net/socket.c:2155
SYSC_sendmsg net/socket.c:2164 [inline]
SyS_sendmsg+0x29/0x30 net/socket.c:2162
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: d4ead6b34b67 ("net/ipv6: move metrics from dst to rt6_info")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Ahern <dsa@cumulusnetworks.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/ipv6/route.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f9c363327d620322dda2269d8398a5dc5de7aa4e..9279f4ec84b6b885357390d3de0826a8a4c54daf 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2600,21 +2600,19 @@ static int ip6_dst_gc(struct dst_ops *ops)
static int ip6_convert_metrics(struct net *net, struct fib6_info *rt,
struct fib6_config *cfg)
{
- int err = 0;
+ struct dst_metrics *p;
- if (cfg->fc_mx) {
- rt->fib6_metrics = kzalloc(sizeof(*rt->fib6_metrics),
- GFP_KERNEL);
- if (unlikely(!rt->fib6_metrics))
- return -ENOMEM;
+ if (!cfg->fc_mx)
+ return 0;
- refcount_set(&rt->fib6_metrics->refcnt, 1);
+ p = kzalloc(sizeof(*rt->fib6_metrics), GFP_KERNEL);
+ if (unlikely(!p))
+ return -ENOMEM;
- err = ip_metrics_convert(net, cfg->fc_mx, cfg->fc_mx_len,
- rt->fib6_metrics->metrics);
- }
+ refcount_set(&p->refcnt, 1);
+ rt->fib6_metrics = p;
- return err;
+ return ip_metrics_convert(net, cfg->fc_mx, cfg->fc_mx_len, p->metrics);
}
static struct rt6_info *ip6_nh_lookup_table(struct net *net,
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* Re: [PATCH v4 1/9] net-next: phy: new Asix Electronics PHY driver
From: Florian Fainelli @ 2018-04-19 16:15 UTC (permalink / raw)
To: Michael Schmitz, netdev
Cc: andrew, fthain, geert, linux-m68k, Michael.Karcher
In-Reply-To: <1524103526-12240-2-git-send-email-schmitzmic@gmail.com>
On 04/18/2018 07:05 PM, Michael Schmitz wrote:
> The Asix Electronics PHY found on the X-Surf 100 Amiga Zorro network
> card by Individual Computers is buggy, and needs the reset bit toggled
> as workaround to make a PHY soft reset succeed.
>
> Add workaround driver just for this special case.
>
> Suggested in xsurf100 patch series review by Andrew Lunn <andrew@lunn.ch>
>
> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
From: Eric Dumazet @ 2018-04-19 16:25 UTC (permalink / raw)
To: Mikulas Patocka, David Miller, Andrew Morton, linux-mm
Cc: dm-devel, eric.dumazet, mst, netdev, linux-kernel, virtualization,
edumazet, bhutchings, Vlastimil Babka
In-Reply-To: <alpine.LRH.2.02.1804191207380.31175@file01.intranet.prod.int.rdu2.redhat.com>
On 04/19/2018 09:12 AM, Mikulas Patocka wrote:
>
>
> These bugs are hard to reproduce because vmalloc falls back to kmalloc
> only if memory is fragmented.
>
This sentence is wrong.
.... because kvmalloc() falls back to vmalloc() ...
^ permalink raw reply
* Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
From: Mikulas Patocka @ 2018-04-19 16:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Andrew Morton, linux-mm, edumazet, bhutchings,
netdev, linux-kernel, mst, jasowang, virtualization, dm-devel,
Vlastimil Babka
In-Reply-To: <6260a8af-3166-94d3-9441-104d342ab7a1@gmail.com>
On Thu, 19 Apr 2018, Eric Dumazet wrote:
>
>
> On 04/19/2018 09:12 AM, Mikulas Patocka wrote:
> >
> >
> > These bugs are hard to reproduce because vmalloc falls back to kmalloc
> > only if memory is fragmented.
> >
>
> This sentence is wrong.
>
> .... because kvmalloc() falls back to vmalloc() ...
Yes. There should be "falls back to vmalloc()".
Mikulas
^ permalink raw reply
* Re: [PATCH v2] x86/cpufeature: guard asm_volatile_goto usage with NO_BPF_WORKAROUND
From: Yonghong Song @ 2018-04-19 16:36 UTC (permalink / raw)
To: peterz, mingo, ast, daniel, linux-kernel, x86; +Cc: kernel-team, netdev
In-Reply-To: <20180415042738.1788215-1-yhs@fb.com>
Hi, Peter,
Just pinging. Did you get chances to look at this?
[ cc netdev as well so folks are aware of the issue. ]
Thanks!
Yonghong
On 4/14/18 9:27 PM, Yonghong Song wrote:
> Commit d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
> removed X86_FAST_FEATURE_TESTS and make macro static_cpu_has() always
> use __always_inline function _static_cpu_has() funciton.
> The static_cpu_has() uses gcc feature asm_volatile_goto construct,
> which is not supported by clang.
>
> Currently, for BPF programs written in C, the only widely-supported
> compiler is clang. Because of clang lacking support
> of asm_volatile_goto construct, if you try to compile
> bpf programs under samples/bpf/,
> $ make -j20 && make headers_install && make samples/bpf/
> you will see a lot of failures like below:
>
> =========================
> clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include \
> -I/home/yhs/work/bpf-next/arch/x86/include \
> -I./arch/x86/include/generated -I/home/yhs/work/bpf-next/include \
> -I./include -I/home/yhs/work/bpf-next/arch/x86/include/uapi \
> -I./arch/x86/include/generated/uapi \
> -I/home/yhs/work/bpf-next/include/uapi -I./include/generated/uapi \
> -include /home/yhs/work/bpf-next/include/linux/kconfig.h
> -Isamples/bpf \
> -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/ \
> -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \
> -D__TARGET_ARCH_x86 -Wno-compare-distinct-pointer-types \
> -Wno-gnu-variable-sized-type-not-at-end \
> -Wno-address-of-packed-member -Wno-tautological-compare \
> -Wno-unknown-warning-option \
> -O2 -emit-llvm -c /home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c \
> -o -| llc -march=bpf -filetype=obj -o samples/bpf/xdp_redirect_cpu_kern.o
> In file included from /home/yhs/work/bpf-next/samples/bpf/xdp_redirect_cpu_kern.c:10:
> In file included from /home/yhs/work/bpf-next/include/uapi/linux/in.h:24:
> In file included from /home/yhs/work/bpf-next/include/linux/socket.h:8:
> In file included from /home/yhs/work/bpf-next/include/linux/uio.h:13:
> In file included from /home/yhs/work/bpf-next/include/linux/thread_info.h:38:
> In file included from /home/yhs/work/bpf-next/arch/x86/include/asm/thread_info.h:53:
> /home/yhs/work/bpf-next/arch/x86/include/asm/cpufeature.h:150:2: error: 'asm goto' constructs are not supported yet
> asm_volatile_goto("1: jmp 6f\n"
> ^
> /home/yhs/work/bpf-next/include/linux/compiler-gcc.h:296:42: note: expanded from macro 'asm_volatile_goto'
> #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
> ^
> 1 error generated.
> =========================
> ...
> In file included from /home/yhs/work/bpf-next/samples/bpf/tracex4_kern.c:7:
> In file included from /home/yhs/work/bpf-next/include/linux/ptrace.h:6:
> In file included from /home/yhs/work/bpf-next/include/linux/sched.h:14:
> In file included from /home/yhs/work/bpf-next/include/linux/pid.h:5:
> In file included from /home/yhs/work/bpf-next/include/linux/rculist.h:11:
> In file included from /home/yhs/work/bpf-next/include/linux/rcupdate.h:40:
> In file included from /home/yhs/work/bpf-next/include/linux/preempt.h:81:
> In file included from /home/yhs/work/bpf-next/arch/x86/include/asm/preempt.h:7:
> In file included from /home/yhs/work/bpf-next/include/linux/thread_info.h:38:
> In file included from /home/yhs/work/bpf-next/arch/x86/include/asm/thread_info.h:53:
> /home/yhs/work/bpf-next/arch/x86/include/asm/cpufeature.h:150:2: error: 'asm goto' constructs are not supported yet
> ...
> =========================
>
> This patch adds a preprocessor guard NO_BPF_WORKAROUND around the
> asm_volatile_goto based static_cpu_has(). NO_BPF_WORKAROUND is set
> at toplevel Makefile when compiler supports asm-goto. That is,
> if the compiler supports asm-goto, the kernel build will use
> asm-goto version of static_cpu_has().
>
> For clang compilation for bpf programs where only header files
> are accessed, NO_BPF_WORKAROUND is not defined and asm-goto version
> of static_cpu_has() will not be accessed, hence the above compilation
> error will disappear.
>
> If later clang compiler starts to support asm_volatile_goto,
> the change in this patch can be reverted.
>
> Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
> Suggested-by: Alexei Starovoitov <ast@kernel.org>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> Makefile | 1 +
> arch/x86/include/asm/cpufeature.h | 5 +++++
> 2 files changed, 6 insertions(+)
>
> Changelog:
> v1 -> v2:
> Use NO_BPF_WORKAROUND macro instead of CC_HAVE_ASM_GOTO
> to make it explicit that this is a workaround.
>
> diff --git a/Makefile b/Makefile
> index c1a608a..7b81f1f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -504,6 +504,7 @@ export RETPOLINE_CFLAGS
> ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) $(KBUILD_CFLAGS)), y)
> CC_HAVE_ASM_GOTO := 1
> KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
> + KBUILD_CFLAGS += -DNO_BPF_WORKAROUND
> KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
> endif
>
> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index b27da96..638417b 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -140,6 +140,8 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
>
> #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
>
> +/* this macro is a temporary hack for bpf until clang gains asm-goto support */
> +#ifdef NO_BPF_WORKAROUND
> /*
> * Static testing of CPU features. Used the same as boot_cpu_has().
> * These will statically patch the target code for additional
> @@ -195,6 +197,9 @@ static __always_inline __pure bool _static_cpu_has(u16 bit)
> boot_cpu_has(bit) : \
> _static_cpu_has(bit) \
> )
> +#else
> +#define static_cpu_has(bit) boot_cpu_has(bit)
> +#endif
>
> #define cpu_has_bug(c, bit) cpu_has(c, (bit))
> #define set_cpu_bug(c, bit) set_cpu_cap(c, (bit))
>
^ permalink raw reply
* [PATCH net-next] sfc: set and clear interrupt affinity hints
From: Bert Kenward @ 2018-04-19 16:37 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev, linux-net-drivers
Use cpumask_local_spread to provide interrupt affinity hints
for each queue. This will spread interrupts across NUMA local
CPUs first, extending to remote nodes if needed.
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
---
drivers/net/ethernet/sfc/efx.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 692dd729ee2a..c30b9e26f131 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -1551,6 +1551,38 @@ static int efx_probe_interrupts(struct efx_nic *efx)
return 0;
}
+#if defined(CONFIG_SMP)
+static void efx_set_interrupt_affinity(struct efx_nic *efx)
+{
+ struct efx_channel *channel;
+ unsigned int cpu;
+
+ efx_for_each_channel(channel, efx) {
+ cpu = cpumask_local_spread(channel->channel,
+ pcibus_to_node(efx->pci_dev->bus));
+ irq_set_affinity_hint(channel->irq, cpumask_of(cpu));
+ }
+}
+
+static void efx_clear_interrupt_affinity(struct efx_nic *efx)
+{
+ struct efx_channel *channel;
+
+ efx_for_each_channel(channel, efx)
+ irq_set_affinity_hint(channel->irq, NULL);
+}
+#else
+static void
+efx_set_interrupt_affinity(struct efx_nic *efx __attribute__ ((unused)))
+{
+}
+
+static void
+efx_clear_interrupt_affinity(struct efx_nic *efx __attribute__ ((unused)))
+{
+}
+#endif /* CONFIG_SMP */
+
static int efx_soft_enable_interrupts(struct efx_nic *efx)
{
struct efx_channel *channel, *end_channel;
@@ -3165,6 +3197,7 @@ static void efx_pci_remove_main(struct efx_nic *efx)
cancel_work_sync(&efx->reset_work);
efx_disable_interrupts(efx);
+ efx_clear_interrupt_affinity(efx);
efx_nic_fini_interrupt(efx);
efx_fini_port(efx);
efx->type->fini(efx);
@@ -3314,6 +3347,8 @@ static int efx_pci_probe_main(struct efx_nic *efx)
rc = efx_nic_init_interrupt(efx);
if (rc)
goto fail5;
+
+ efx_set_interrupt_affinity(efx);
rc = efx_enable_interrupts(efx);
if (rc)
goto fail6;
@@ -3321,6 +3356,7 @@ static int efx_pci_probe_main(struct efx_nic *efx)
return 0;
fail6:
+ efx_clear_interrupt_affinity(efx);
efx_nic_fini_interrupt(efx);
fail5:
efx_fini_port(efx);
--
2.13.6
^ permalink raw reply related
* Re: [PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency
From: Kalle Valo @ 2018-04-19 16:41 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio, linux-wireless, linux-fpga,
linux-remoteproc, alsa-devel, Bjorn Andersson, Eric Anholt,
netdev, linux-mtd, linux-i2c, linux1394-devel, Christoph Hellwig,
Marek Szyprowski, Stefan Wahren, Boris Brezillon, Herbert Xu,
Richard Weinberger, Joerg Roedel, Jassi Brar, Marek Vasut,
linux-serial, Matias Bjorling, David Woodhouse, l
In-Reply-To: <1523987360-18760-16-git-send-email-geert@linux-m68k.org>
(adding linux-wireless)
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
> symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
> In most cases this other symbol is an architecture or platform specific
> symbol, or PCI.
>
> Generic symbols and drivers without platform dependencies keep their
> dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
> cannot work anyway.
>
> This simplifies the dependencies, and allows to improve compile-testing.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Acked-by: Robin Murphy <robin.murphy@arm.com>
> ---
> v3:
> - Rebase to v4.17-rc1,
> - Drop obsolete note about FSL_FMAN,
>
> v2:
> - Add Reviewed-by, Acked-by,
> - Drop RFC state,
> - Split per subsystem.
> ---
> drivers/net/ethernet/amd/Kconfig | 2 +-
> drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 -
> drivers/net/ethernet/apm/xgene/Kconfig | 1 -
> drivers/net/ethernet/arc/Kconfig | 6 ++++--
> drivers/net/ethernet/broadcom/Kconfig | 2 --
> drivers/net/ethernet/calxeda/Kconfig | 2 +-
> drivers/net/ethernet/hisilicon/Kconfig | 2 +-
> drivers/net/ethernet/marvell/Kconfig | 8 +++-----
> drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
> drivers/net/ethernet/renesas/Kconfig | 2 --
> drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
> drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +-
> 12 files changed, 12 insertions(+), 19 deletions(-)
For wireless:
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Leaving the hunks for linux-wireless list to see:
> diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> index 9d99eb42d9176f0f..6acba67bca07abd7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
> +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> @@ -60,7 +60,6 @@ config BRCMFMAC_PCIE
> bool "PCIE bus interface support for FullMAC driver"
> depends on BRCMFMAC
> depends on PCI
> - depends on HAS_DMA
> select BRCMFMAC_PROTO_MSGBUF
> select FW_LOADER
> ---help---
> diff --git a/drivers/net/wireless/quantenna/qtnfmac/Kconfig b/drivers/net/wireless/quantenna/qtnfmac/Kconfig
> index 025fa6018550895a..8d1492a90bd135c0 100644
> --- a/drivers/net/wireless/quantenna/qtnfmac/Kconfig
> +++ b/drivers/net/wireless/quantenna/qtnfmac/Kconfig
> @@ -7,7 +7,7 @@ config QTNFMAC
> config QTNFMAC_PEARL_PCIE
> tristate "Quantenna QSR10g PCIe support"
> default n
> - depends on HAS_DMA && PCI && CFG80211
> + depends on PCI && CFG80211
> select QTNFMAC
> select FW_LOADER
> select CRC32
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
From: Michael S. Tsirkin @ 2018-04-19 16:43 UTC (permalink / raw)
To: Mikulas Patocka
Cc: David Miller, Andrew Morton, linux-mm, eric.dumazet, edumazet,
bhutchings, netdev, linux-kernel, jasowang, virtualization,
dm-devel, Vlastimil Babka
In-Reply-To: <alpine.LRH.2.02.1804191207380.31175@file01.intranet.prod.int.rdu2.redhat.com>
On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 18 Apr 2018, Mikulas Patocka wrote:
>
> >
> >
> > On Wed, 18 Apr 2018, David Miller wrote:
> >
> > > From: Mikulas Patocka <mpatocka@redhat.com>
> > > Date: Wed, 18 Apr 2018 12:44:25 -0400 (EDT)
> > >
> > > > The structure net_device is followed by arbitrary driver-specific data
> > > > (accessible with the function netdev_priv). And for virtio-net, these
> > > > driver-specific data must be in DMA memory.
> > >
> > > And we are saying that this assumption is wrong and needs to be
> > > corrected.
> >
> > So, try to find all the networking drivers that to DMA to the private
> > area.
> >
> > The problem here is that kvzalloc usually returns DMA-able area, but it
> > may return non-DMA area rarely, if the memory is too fragmented. So, we
> > are in a situation, where some networking drivers will randomly fail. Go
> > and find them.
> >
> > Mikulas
>
> Her I submit a patch that makes kvmalloc always use vmalloc if
> CONFIG_DEBUG_VM is defined.
>
>
>
>
> From: Mikulas Patocka <mpatocka@redhat.com>
> Subject: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
>
> The kvmalloc function tries to use kmalloc and falls back to vmalloc if
> kmalloc fails.
>
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code.
>
> These bugs are hard to reproduce because vmalloc falls back to kmalloc
> only if memory is fragmented.
>
> In order to detect these bugs reliably I submit this patch that changes
> kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Maybe make it conditional on CONFIG_DEBUG_SG too?
Otherwise I think you just trigger a hard to debug memory corruption.
> ---
> mm/util.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6/mm/util.c
> ===================================================================
> --- linux-2.6.orig/mm/util.c 2018-04-18 15:46:23.000000000 +0200
> +++ linux-2.6/mm/util.c 2018-04-18 16:00:43.000000000 +0200
> @@ -395,6 +395,7 @@ EXPORT_SYMBOL(vm_mmap);
> */
> void *kvmalloc_node(size_t size, gfp_t flags, int node)
> {
> +#ifndef CONFIG_DEBUG_VM
> gfp_t kmalloc_flags = flags;
> void *ret;
>
> @@ -426,6 +427,7 @@ void *kvmalloc_node(size_t size, gfp_t f
> */
> if (ret || size <= PAGE_SIZE)
> return ret;
> +#endif
>
> return __vmalloc_node_flags_caller(size, node, flags,
> __builtin_return_address(0));
^ permalink raw reply
* Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)
From: Al Viro @ 2018-04-19 16:44 UTC (permalink / raw)
To: Kirill Tkhai; +Cc: Alexander Aring, linux-kernel, netdev, Jamal Hadi Salim
In-Reply-To: <20180419153447.GH30522@ZenIV.linux.org.uk>
On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote:
> IOW, we only get there if our vfsmount was an MNT_INTERNAL one.
> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in
> ->mnt_pins of some other mount. Which, AFAICS, means that
> it used to be mounted on that other mount. How the hell can
> that happen?
>
> It looks like you somehow get a long chain of MNT_INTERNAL mounts
> stacked on top of each other, which ought to be prevented by
> mnt_flags &= ~MNT_INTERNAL_FLAGS;
> in do_add_mount(). Nuts...
Arrrrrgh... Nuts is right - clone_mnt() preserves the sodding
MNT_INTERNAL, with obvious results.
netns is related to the problem, by exposing MNT_INTERNAL mounts
(in /proc/*/ns/*) for mount --bind to copy and attach to the
tree. AFAICS, the minimal reproducer is
touch /tmp/a
unshare -m sh -c 'for i in `seq 10000`; do mount --bind /proc/1/ns/net /tmp/a; done'
(and it can be anything in /proc/*/ns/*, really)
I think the fix should be along the lines of the following:
Don't leak MNT_INTERNAL away from internal mounts
We want it only for the stuff created by SB_KERNMOUNT mounts, *not* for
their copies.
Cc: stable@kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/namespace.c b/fs/namespace.c
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1089,7 +1089,8 @@ static struct mount *clone_mnt(struct mount *old, struct dentry *root,
goto out_free;
}
- mnt->mnt.mnt_flags = old->mnt.mnt_flags & ~(MNT_WRITE_HOLD|MNT_MARKED);
+ mnt->mnt.mnt_flags = old->mnt.mnt_flags;
+ mnt->mnt.mnt_flags &= ~(MNT_WRITE_HOLD|MNT_MARKED|MNT_INTERNAL);
/* Don't allow unprivileged users to change mount flags */
if (flag & CL_UNPRIVILEGED) {
mnt->mnt.mnt_flags |= MNT_LOCK_ATIME;
^ permalink raw reply
* Re: [PATCH net-next] net/ipv6: Fix ip6_convert_metrics() bug
From: David Ahern @ 2018-04-19 16:46 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20180419161453.46977-1-edumazet@google.com>
On 4/19/18 10:14 AM, Eric Dumazet wrote:
> If ip6_convert_metrics() fails to allocate memory, it should not
> overwrite rt->fib6_metrics or we risk a crash later as syzbot found.
>
...
>
> Fixes: d4ead6b34b67 ("net/ipv6: move metrics from dst to rt6_info")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: David Ahern <dsa@cumulusnetworks.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> ---
> net/ipv6/route.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
Acked-by: David Ahern <dsa@cumulusnetworks.com>
Thanks for fixing.
^ permalink raw reply
* Re: [bisected] Stack overflow after fs: "switch the IO-triggering parts of umount to fs_pin" (was net namespaces kernel stack overflow)
From: Kirill Tkhai @ 2018-04-19 16:56 UTC (permalink / raw)
To: Al Viro; +Cc: Alexander Aring, linux-kernel, netdev, Jamal Hadi Salim
In-Reply-To: <20180419164424.GI30522@ZenIV.linux.org.uk>
On 19.04.2018 19:44, Al Viro wrote:
> On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote:
>
>> IOW, we only get there if our vfsmount was an MNT_INTERNAL one.
>> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in
>> ->mnt_pins of some other mount. Which, AFAICS, means that
>> it used to be mounted on that other mount. How the hell can
>> that happen?
>>
>> It looks like you somehow get a long chain of MNT_INTERNAL mounts
>> stacked on top of each other, which ought to be prevented by
>> mnt_flags &= ~MNT_INTERNAL_FLAGS;
>> in do_add_mount(). Nuts...
>
> Arrrrrgh... Nuts is right - clone_mnt() preserves the sodding
> MNT_INTERNAL, with obvious results.
>
> netns is related to the problem, by exposing MNT_INTERNAL mounts
> (in /proc/*/ns/*) for mount --bind to copy and attach to the
> tree. AFAICS, the minimal reproducer is
>
> touch /tmp/a
> unshare -m sh -c 'for i in `seq 10000`; do mount --bind /proc/1/ns/net /tmp/a; done'
>
> (and it can be anything in /proc/*/ns/*, really)
>
> I think the fix should be along the lines of the following:
>
> Don't leak MNT_INTERNAL away from internal mounts
>
> We want it only for the stuff created by SB_KERNMOUNT mounts, *not* for
> their copies.
>
> Cc: stable@kernel.org
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Flawless victory! Thanks.
Tested-by: Kirill Tkhai <ktkhai@virtuozzo.com>
> ---
> diff --git a/fs/namespace.c b/fs/namespace.c
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1089,7 +1089,8 @@ static struct mount *clone_mnt(struct mount *old, struct dentry *root,
> goto out_free;
> }
>
> - mnt->mnt.mnt_flags = old->mnt.mnt_flags & ~(MNT_WRITE_HOLD|MNT_MARKED);
> + mnt->mnt.mnt_flags = old->mnt.mnt_flags;
> + mnt->mnt.mnt_flags &= ~(MNT_WRITE_HOLD|MNT_MARKED|MNT_INTERNAL);
> /* Don't allow unprivileged users to change mount flags */
> if (flag & CL_UNPRIVILEGED) {
> mnt->mnt.mnt_flags |= MNT_LOCK_ATIME;
>
^ permalink raw reply
* [PATCH v4 0/3] lan78xx: Read configuration from Device Tree
From: Phil Elwell @ 2018-04-19 16:59 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for reading the MAC address and LED modes from
Device Tree.
v4:
- Rename nodes in bindings doc.
v3:
- Move LED setting into PHY driver.
v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.
Phil Elwell (3):
lan78xx: Read MAC address from DT if present
lan78xx: Read LED states from Device Tree
dt-bindings: Document the DT bindings for lan78xx
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++
MAINTAINERS | 2 +
drivers/net/phy/microchip.c | 25 ++++++++
drivers/net/usb/lan78xx.c | 74 +++++++++++++++-------
include/dt-bindings/net/microchip-lan78xx.h | 21 ++++++
include/linux/microchipphy.h | 3 +
6 files changed, 156 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply
* [PATCH v4 1/3] lan78xx: Read MAC address from DT if present
From: Phil Elwell @ 2018-04-19 16:59 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
In-Reply-To: <1524157180-27276-1-git-send-email-phil@raspberrypi.org>
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
---
drivers/net/usb/lan78xx.c | 42 ++++++++++++++++++++----------------------
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_net.h>
#include "lan78xx.h"
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net *dev)
addr[5] = (addr_hi >> 8) & 0xFF;
if (!is_valid_ether_addr(addr)) {
- /* reading mac address from EEPROM or OTP */
- if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0) ||
- (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
- if (is_valid_ether_addr(addr)) {
- /* eeprom values are valid so use them */
- netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
- } else {
- /* generate random MAC */
- random_ether_addr(addr);
- netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
- }
-
- addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
- addr_hi = addr[4] | (addr[5] << 8);
-
- ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
- ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+ if (!eth_platform_get_mac_address(&dev->udev->dev, addr)) {
+ /* valid address present in Device Tree */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+ } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0) ||
+ (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+ is_valid_ether_addr(addr)) {
+ /* eeprom values are valid so use them */
+ netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
"MAC address set to random addr");
}
+
+ addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+ addr_hi = addr[4] | (addr[5] << 8);
+
+ ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+ ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/3] lan78xx: Read LED states from Device Tree
From: Phil Elwell @ 2018-04-19 16:59 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
In-Reply-To: <1524157180-27276-1-git-send-email-phil@raspberrypi.org>
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/activity 5=link10/1000/activity
6=link10/100/activity 14=off 15=on
These values are given symbolic constants in a dt-bindings header.
Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
MAINTAINERS | 1 +
drivers/net/phy/microchip.c | 25 ++++++++++++++++++++++
drivers/net/usb/lan78xx.c | 32 ++++++++++++++++++++++++++++-
include/dt-bindings/net/microchip-lan78xx.h | 21 +++++++++++++++++++
include/linux/microchipphy.h | 3 +++
5 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/net/microchip-lan78xx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..23735d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-lan78xx.h
USB MASS STORAGE DRIVER
M: Alan Stern <stern@rowland.harvard.edu>
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef..ef5e160 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,8 @@
#include <linux/ethtool.h>
#include <linux/phy.h>
#include <linux/microchipphy.h>
+#include <linux/of.h>
+#include <dt-bindings/net/microchip-lan78xx.h>
#define DRIVER_AUTHOR "WOOJUNG HUH <woojung.huh@microchip.com>"
#define DRIVER_DESC "Microchip LAN88XX PHY driver"
@@ -70,6 +72,8 @@ static int lan88xx_probe(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
struct lan88xx_priv *priv;
+ u32 led_modes[4];
+ int len;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -77,6 +81,27 @@ static int lan88xx_probe(struct phy_device *phydev)
priv->wolopts = 0;
+ len = of_property_read_variable_u32_array(dev->of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+ if (len >= 0) {
+ u32 reg = 0;
+ int i;
+
+ for (i = 0; i < len; i++) {
+ if (led_modes[i] > 15)
+ return -EINVAL;
+ reg |= led_modes[i] << (i * 4);
+ }
+ for (; i < ARRAY_SIZE(led_modes); i++)
+ reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+ (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+ } else if (len == -EOVERFLOW) {
+ return -EINVAL;
+ }
+
/* these values can be used to identify internal PHY */
priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..6b03b97 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
#include <linux/irqchip/chained_irq.h>
#include <linux/microchipphy.h>
#include <linux/phy.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "lan78xx.h"
@@ -1760,6 +1761,7 @@ static int lan78xx_mdiobus_write(struct mii_bus *bus, int phy_id, int idx,
static int lan78xx_mdio_init(struct lan78xx_net *dev)
{
+ struct device_node *node;
int ret;
dev->mdiobus = mdiobus_alloc();
@@ -1788,7 +1790,13 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
break;
}
- ret = mdiobus_register(dev->mdiobus);
+ node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
+ if (node) {
+ ret = of_mdiobus_register(dev->mdiobus, node);
+ of_node_put(node);
+ } else {
+ ret = mdiobus_register(dev->mdiobus);
+ }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
@@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
+ if (phydev->mdio.dev.of_node) {
+ u32 reg;
+ int len;
+
+ len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
+ "microchip,led-modes",
+ sizeof(u32));
+ if (len >= 0) {
+ /* Ensure the appropriate LEDs are enabled */
+ lan78xx_read_reg(dev, HW_CFG, ®);
+ reg &= ~(HW_CFG_LED0_EN_ |
+ HW_CFG_LED1_EN_ |
+ HW_CFG_LED2_EN_ |
+ HW_CFG_LED3_EN_);
+ reg |= (len > 0) * HW_CFG_LED0_EN_ |
+ (len > 1) * HW_CFG_LED1_EN_ |
+ (len > 2) * HW_CFG_LED2_EN_ |
+ (len > 3) * HW_CFG_LED3_EN_;
+ lan78xx_write_reg(dev, HW_CFG, reg);
+ }
+ }
+
genphy_config_aneg(phydev);
dev->fc_autoneg = phydev->autoneg;
diff --git a/include/dt-bindings/net/microchip-lan78xx.h b/include/dt-bindings/net/microchip-lan78xx.h
new file mode 100644
index 0000000..0742ff0
--- /dev/null
+++ b/include/dt-bindings/net/microchip-lan78xx.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_MICROCHIP_LAN78XX_H
+#define _DT_BINDINGS_MICROCHIP_LAN78XX_H
+
+/* LED modes for LAN7800/LAN7850 embedded PHY */
+
+#define LAN78XX_LINK_ACTIVITY 0
+#define LAN78XX_LINK_1000_ACTIVITY 1
+#define LAN78XX_LINK_100_ACTIVITY 2
+#define LAN78XX_LINK_10_ACTIVITY 3
+#define LAN78XX_LINK_100_1000_ACTIVITY 4
+#define LAN78XX_LINK_10_1000_ACTIVITY 5
+#define LAN78XX_LINK_10_100_ACTIVITY 6
+#define LAN78XX_DUPLEX_COLLISION 8
+#define LAN78XX_COLLISION 9
+#define LAN78XX_ACTIVITY 10
+#define LAN78XX_AUTONEG_FAULT 12
+#define LAN78XX_FORCE_LED_OFF 14
+#define LAN78XX_FORCE_LED_ON 15
+
+#endif
diff --git a/include/linux/microchipphy.h b/include/linux/microchipphy.h
index eb492d4..8e4015e 100644
--- a/include/linux/microchipphy.h
+++ b/include/linux/microchipphy.h
@@ -70,4 +70,7 @@
#define LAN88XX_MMD3_CHIP_ID (32877)
#define LAN88XX_MMD3_CHIP_REV (32878)
+/* Registers specific to the LAN7800/LAN7850 embedded phy */
+#define LAN78XX_PHY_LED_MODE_SELECT (0x1D)
+
#endif /* _MICROCHIPPHY_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/3] dt-bindings: Document the DT bindings for lan78xx
From: Phil Elwell @ 2018-04-19 16:59 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, David S. Miller,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Linus Walleij,
Andrew Morton, Randy Dunlap, Phil Elwell, netdev, devicetree,
linux-kernel, linux-usb
In-Reply-To: <1524157180-27276-1-git-send-email-phil@raspberrypi.org>
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in a bindings file.
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
.../devicetree/bindings/net/microchip,lan78xx.txt | 54 ++++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 0000000..76786a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,54 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address: see ethernet.txt
+- mac-address: see ethernet.txt
+
+Optional properties of the embedded PHY:
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+ the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+ are defined in "include/dt-bindings/net/microchip-lan78xx.h".
+
+Example:
+
+/* Based on the configuration for a Raspberry Pi 3 B+ */
+&usb {
+ usb-port@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb-port@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: ethernet@1 {
+ compatible = "usb424,7800";
+ reg = <1>;
+ local-mac-address = [ 00 11 22 33 44 55 ];
+
+ mdio {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ eth_phy: ethernet-phy@1 {
+ reg = <1>;
+ microchip,led-modes = <
+ LAN78XX_LINK_1000_ACTIVITY
+ LAN78XX_LINK_10_100_ACTIVITY
+ >;
+ };
+ };
+ };
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 23735d9..91cb961 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M: Woojung Huh <woojung.huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
L: netdev@vger.kernel.org
S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
F: drivers/net/usb/lan78xx.*
F: include/dt-bindings/net/microchip-lan78xx.h
--
2.7.4
^ permalink raw reply related
* KMSAN: uninit-value in dccp_invalid_packet
From: syzbot @ 2018-04-19 17:06 UTC (permalink / raw)
To: davem, dccp, gerrit, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
e2ab7e8abba47a2f2698216258e5d8727ae58717 (Fri Apr 6 16:24:31 2018 +0000)
kmsan: temporarily disable visitAsmInstruction() to help syzbot
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=00763607efc31f91b276
So far this crash happened 19 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5163725019414528
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=4836676144726016
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=4771447134224384
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+00763607efc31f91b276@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
==================================================================
BUG: KMSAN: uninit-value in dccp_invalid_packet+0x3b8/0xf50
net/dccp/ipv4.c:716
CPU: 1 PID: 3572 Comm: syzkaller338124 Not tainted 4.16.0+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
dccp_invalid_packet+0x3b8/0xf50 net/dccp/ipv4.c:716
dccp_v4_rcv+0xf7/0x2630 net/dccp/ipv4.c:778
ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
__netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
</IRQ>
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
ip_finish_output2+0x124e/0x1380 net/ipv4/ip_output.c:231
ip_finish_output+0xcb0/0xff0 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip_output+0x502/0x5c0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:443 [inline]
ip_local_out net/ipv4/ip_output.c:124 [inline]
ip_send_skb+0x5f3/0x820 net/ipv4/ip_output.c:1414
ip_push_pending_frames+0x105/0x170 net/ipv4/ip_output.c:1434
raw_sendmsg+0x2960/0x3ed0 net/ipv4/raw.c:684
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
SYSC_sendto+0x6c3/0x7e0 net/socket.c:1747
SyS_sendto+0x8a/0xb0 net/socket.c:1715
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x441709
RSP: 002b:00007ffffde4d688 EFLAGS: 00000217 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 000000000000001b RCX: 0000000000441709
RDX: 0000000000000030 RSI: 0000000020000140 RDI: 0000000000000003
RBP: 00000000004a3318 R08: 0000000020000000 R09: 0000000000000010
R10: 0000000000000000 R11: 0000000000000217 R12: 00007ffffde4d768
R13: 0000000000402490 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:526
__msan_memcpy+0x19f/0x1f0 mm/kmsan/kmsan_instr.c:470
skb_copy_bits+0x63a/0xdb0 net/core/skbuff.c:2046
__pskb_pull_tail+0x483/0x22e0 net/core/skbuff.c:1883
pskb_may_pull include/linux/skbuff.h:2112 [inline]
dccp_invalid_packet+0x352/0xf50 net/dccp/ipv4.c:708
dccp_v4_rcv+0xf7/0x2630 net/dccp/ipv4.c:778
ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
__netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_alloc_meta_for_pages+0x161/0x3a0 mm/kmsan/kmsan.c:814
kmsan_alloc_page+0x82/0xe0 mm/kmsan/kmsan.c:868
__alloc_pages_nodemask+0xf5b/0x5dc0 mm/page_alloc.c:4283
alloc_pages_current+0x6b5/0x970 mm/mempolicy.c:2055
alloc_pages include/linux/gfp.h:494 [inline]
skb_page_frag_refill+0x3ba/0x5e0 net/core/sock.c:2208
sk_page_frag_refill+0xa4/0x340 net/core/sock.c:2228
__ip_append_data+0x107e/0x3d10 net/ipv4/ip_output.c:1057
ip_append_data+0x2fb/0x440 net/ipv4/ip_output.c:1170
raw_sendmsg+0x287b/0x3ed0 net/ipv4/raw.c:678
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
SYSC_sendto+0x6c3/0x7e0 net/socket.c:1747
SyS_sendto+0x8a/0xb0 net/socket.c:1715
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* KMSAN: uninit-value in __udp4_lib_rcv
From: syzbot @ 2018-04-19 17:06 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot hit the following crash on
https://github.com/google/kmsan.git/master commit
35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +0000)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=493bccc5b8cfe9d5035e
So far this crash happened 11 times on
https://github.com/google/kmsan.git/master.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=4935004320694272
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5133260011077632
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=5329144879513600
Kernel config:
https://syzkaller.appspot.com/x/.config?id=6627248707860932248
compiler: clang version 7.0.0 (trunk 329391)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+493bccc5b8cfe9d5035e@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
==================================================================
BUG: KMSAN: uninit-value in __udp4_lib_rcv+0x628/0x4740 net/ipv4/udp.c:2066
CPU: 1 PID: 3573 Comm: syzkaller192717 Not tainted 4.16.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:53
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
__udp4_lib_rcv+0x628/0x4740 net/ipv4/udp.c:2066
udp_rcv+0x5c/0x70 net/ipv4/udp.c:2287
ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
__netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
</IRQ>
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
ip_finish_output2+0x124e/0x1380 net/ipv4/ip_output.c:231
ip_finish_output+0xcb0/0xff0 net/ipv4/ip_output.c:317
NF_HOOK_COND include/linux/netfilter.h:277 [inline]
ip_output+0x502/0x5c0 net/ipv4/ip_output.c:405
dst_output include/net/dst.h:443 [inline]
ip_local_out net/ipv4/ip_output.c:124 [inline]
ip_send_skb+0x5f3/0x820 net/ipv4/ip_output.c:1414
ip_push_pending_frames+0x105/0x170 net/ipv4/ip_output.c:1434
raw_sendmsg+0x2960/0x3ed0 net/ipv4/raw.c:684
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43fe99
RSP: 002b:00007ffca5bf5be8 EFLAGS: 00000217 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fe99
RDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000217 R12: 00000000004017c0
R13: 0000000000401850 R14: 0000000000000000 R15: 0000000000000000
Uninit was stored to memory at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
kmsan_memcpy_origins+0x11d/0x170 mm/kmsan/kmsan.c:526
__msan_memcpy+0x19f/0x1f0 mm/kmsan/kmsan_instr.c:470
skb_copy_bits+0x63a/0xdb0 net/core/skbuff.c:2046
__pskb_pull_tail+0x483/0x22e0 net/core/skbuff.c:1883
pskb_may_pull include/linux/skbuff.h:2112 [inline]
__udp4_lib_rcv+0x55f/0x4740 net/ipv4/udp.c:2058
udp_rcv+0x5c/0x70 net/ipv4/udp.c:2287
ip_local_deliver_finish+0x6ed/0xd40 net/ipv4/ip_input.c:216
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_local_deliver+0x43c/0x4e0 net/ipv4/ip_input.c:257
dst_input include/net/dst.h:449 [inline]
ip_rcv_finish+0x1253/0x16d0 net/ipv4/ip_input.c:397
NF_HOOK include/linux/netfilter.h:288 [inline]
ip_rcv+0x119d/0x16f0 net/ipv4/ip_input.c:493
__netif_receive_skb_core+0x47cf/0x4a80 net/core/dev.c:4562
__netif_receive_skb net/core/dev.c:4627 [inline]
process_backlog+0x62d/0xe20 net/core/dev.c:5307
napi_poll net/core/dev.c:5705 [inline]
net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
__do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
kmsan_alloc_meta_for_pages+0x161/0x3a0 mm/kmsan/kmsan.c:814
kmsan_alloc_page+0x82/0xe0 mm/kmsan/kmsan.c:868
__alloc_pages_nodemask+0xf5b/0x5dc0 mm/page_alloc.c:4283
alloc_pages_current+0x6b5/0x970 mm/mempolicy.c:2055
alloc_pages include/linux/gfp.h:494 [inline]
skb_page_frag_refill+0x3ba/0x5e0 net/core/sock.c:2208
sk_page_frag_refill+0xa4/0x340 net/core/sock.c:2228
__ip_append_data+0x107e/0x3d10 net/ipv4/ip_output.c:1057
ip_append_data+0x2fb/0x440 net/ipv4/ip_output.c:1170
raw_sendmsg+0x287b/0x3ed0 net/ipv4/raw.c:678
inet_sendmsg+0x48d/0x740 net/ipv4/af_inet.c:764
sock_sendmsg_nosec net/socket.c:630 [inline]
sock_sendmsg net/socket.c:640 [inline]
___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
__sys_sendmsg net/socket.c:2080 [inline]
SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
SyS_sendmsg+0x54/0x80 net/socket.c:2087
do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
==================================================================
---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkaller@googlegroups.com.
syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
^ permalink raw reply
* Re: [PATCH net-next 0/4] tracking TCP data delivery and ECN stats
From: David Miller @ 2018-04-19 17:07 UTC (permalink / raw)
To: ycheng; +Cc: netdev, edumazet, ncardwell, soheil
In-Reply-To: <20180418061849.220459-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 17 Apr 2018 23:18:45 -0700
> This patch series improve tracking the data delivery status
> 1. minor improvement on SYN data
> 2. accounting bytes delivered with CE marks
> 3. exporting the delivery stats to applications
>
> s.t. users can get better sense of TCP performance at per host,
> per connection, and even per application message level.
Definitely useful, so series applied.
But it is not lost upon me that slowly over time tcp sockets are
bloating quite a bit...
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: Fix DMA address mask size
From: David Miller @ 2018-04-19 17:13 UTC (permalink / raw)
To: maxime.chevallier
Cc: netdev, linux-kernel, antoine.tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180418091444.14039-1-maxime.chevallier@bootlin.com>
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Wed, 18 Apr 2018 11:14:44 +0200
> PPv2 TX/RX descriptors uses 40bits DMA addresses, but 41 bits masks were
> used (GENMASK_ULL(40, 0)).
>
> This commit fixes that by using the correct mask.
>
> Fixes: e7c5359f2eed ("net: mvpp2: introduce PPv2.2 HW descriptors and adapt accessors")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Disable ACS Feature for GMAC >= 4
From: David Miller @ 2018-04-19 17:34 UTC (permalink / raw)
To: Jose.Abreu; +Cc: netdev, Joao.Pinto, peppe.cavallaro, alexandre.torgue
In-Reply-To: <1c69d3cabd8d26648c327d72a0a58d3d879cfc34.1524045087.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Wed, 18 Apr 2018 10:57:55 +0100
> ACS Feature is currently enabled for GMAC >= 4 but the llc_snap status
> is never checked in descriptor rx_status callback. This will cause
> stmmac to always strip packets even that ACS feature is already
> stripping them.
>
> Lets be safe and disable the ACS feature for GMAC >= 4 and always strip
> the packets for this GMAC version.
>
> Fixes: 477286b53f55 ("stmmac: add GMAC4 core support")
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> ---
> Hi David,
>
> Requesting this to go up for stable also. I think its for v4.7+ but if you
> could cross-check it would be great! Let me know if you need any more
> info for queueing this.
Yeah v4.7+ looks about right.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net-next/hinic: add arm64 support
From: David Miller @ 2018-04-19 17:34 UTC (permalink / raw)
To: zhaochen6
Cc: linux-kernel, netdev, aviad.krawczyk, tony.qu, yin.yinshi,
luoshaokai
In-Reply-To: <20180418100739.12948-1-zhaochen6@huawei.com>
From: Zhao Chen <zhaochen6@huawei.com>
Date: Wed, 18 Apr 2018 06:07:39 -0400
> This patch enables arm64 platform support for the HINIC driver.
>
> Signed-off-by: Zhao Chen <zhaochen6@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v3] net: change the comment of dev_mc_init
From: David Miller @ 2018-04-19 17:36 UTC (permalink / raw)
To: sunlw.fnst; +Cc: netdev
In-Reply-To: <05dbc297-8371-4e82-21ca-d6fae4cf9512@cn.fujitsu.com>
From: sunlianwen <sunlw.fnst@cn.fujitsu.com>
Date: Wed, 18 Apr 2018 09:22:39 +0800
> The comment of dev_mc_init() is wrong. which use dev_mc_flush
> instead of dev_mc_init.
>
> Signed-off-by: Lianwen Sun <sunlw.fnst@cn.fujitsu.com
Applied.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: add Wistron Neweb D19Q1
From: David Miller @ 2018-04-19 17:38 UTC (permalink / raw)
To: paweldembicki; +Cc: bjorn, netdev, linux-usb, linux-kernel
In-Reply-To: <1524060204-7814-1-git-send-email-paweldembicki@gmail.com>
From: Pawel Dembicki <paweldembicki@gmail.com>
Date: Wed, 18 Apr 2018 16:03:24 +0200
> This modem is embedded on dlink dwr-960 router.
> The oem configuration states:
...
> Tested on openwrt distribution
>
> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] atm: iphase: fix spelling mistake: "Tansmit" -> "Transmit"
From: David Miller @ 2018-04-19 17:42 UTC (permalink / raw)
To: colin.king
Cc: 3chas3, linux-atm-general, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180418155505.10334-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Wed, 18 Apr 2018 16:55:05 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in message text.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: Direct networking documentation changes to netdev
From: David Miller @ 2018-04-19 17:42 UTC (permalink / raw)
To: corbet; +Cc: netdev
In-Reply-To: <20180418101413.46fd1212@lwn.net>
From: Jonathan Corbet <corbet@lwn.net>
Date: Wed, 18 Apr 2018 10:14:13 -0600
> Networking docs changes go through the networking tree, so patch the
> MAINTAINERS file to direct authors to the right place.
>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Applied, thanks Jonathan.
^ 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