* Re: [PATCH net-next] net: ethernet: ti: use devm_platform_ioremap_resource() to simplify code
From: Grygorii Strashko @ 2019-09-18 9:29 UTC (permalink / raw)
To: Geert Uytterhoeven, YueHaibing
Cc: David S. Miller, ivan.khoronzhuk, Andrew Lunn, Petr Štetiar,
Linux Kernel Mailing List, netdev,
open list:TI ETHERNET SWITCH DRIVER (CPSW)
In-Reply-To: <CAMuHMdXdd4oiHqTpFTYBTSeCB6A78_gSGmwPy5EgPRZXibOqZw@mail.gmail.com>
On 17/09/2019 21:35, Geert Uytterhoeven wrote:
> Hi YueHaibing,
>
> On Wed, Aug 21, 2019 at 2:51 PM YueHaibing <yuehaibing@huawei.com> wrote:
>> Use devm_platform_ioremap_resource() to simplify the code a bit.
>> This is detected by coccinelle.
>>
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> drivers/net/ethernet/ti/cpsw.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>> index 32a8974..5401095 100644
>> --- a/drivers/net/ethernet/ti/cpsw.c
>> +++ b/drivers/net/ethernet/ti/cpsw.c
>> @@ -2764,7 +2764,7 @@ static int cpsw_probe(struct platform_device *pdev)
>> struct net_device *ndev;
>> struct cpsw_priv *priv;
>> void __iomem *ss_regs;
>> - struct resource *res, *ss_res;
>> + struct resource *ss_res;
>> struct gpio_descs *mode;
>> const struct soc_device_attribute *soc;
>> struct cpsw_common *cpsw;
>> @@ -2798,8 +2798,7 @@ static int cpsw_probe(struct platform_device *pdev)
>
> And just out-of-context, we also have:
>
> ss_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ss_regs = devm_ioremap_resource(dev, ss_res);
> if (IS_ERR(ss_regs))
>
> which was not detected as being the same pattern?
>
> Interesting...
ss_res is used below to determine phys address of CPPI RAM.
>
>> return PTR_ERR(ss_regs);
>> cpsw->regs = ss_regs;
>>
>> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> - cpsw->wr_regs = devm_ioremap_resource(dev, res);
>> + cpsw->wr_regs = devm_platform_ioremap_resource(pdev, 1);
>> if (IS_ERR(cpsw->wr_regs))
>> return PTR_ERR(cpsw->wr_regs);
--
Best regards,
grygorii
^ permalink raw reply
* Re: [PATCH net-next] net: ethernet: ti: use devm_platform_ioremap_resource() to simplify code
From: Geert Uytterhoeven @ 2019-09-18 9:35 UTC (permalink / raw)
To: Grygorii Strashko
Cc: YueHaibing, David S. Miller, ivan.khoronzhuk, Andrew Lunn,
Petr Štetiar, Linux Kernel Mailing List, netdev,
open list:TI ETHERNET SWITCH DRIVER (CPSW)
In-Reply-To: <12c00786-980f-5761-3117-3e741e63d7b3@ti.com>
Hi Grygorii,
On Wed, Sep 18, 2019 at 11:29 AM Grygorii Strashko
<grygorii.strashko@ti.com> wrote:
> On 17/09/2019 21:35, Geert Uytterhoeven wrote:
> > On Wed, Aug 21, 2019 at 2:51 PM YueHaibing <yuehaibing@huawei.com> wrote:
> >> Use devm_platform_ioremap_resource() to simplify the code a bit.
> >> This is detected by coccinelle.
> >>
> >> Reported-by: Hulk Robot <hulkci@huawei.com>
> >> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> >> ---
> >> drivers/net/ethernet/ti/cpsw.c | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> >> index 32a8974..5401095 100644
> >> --- a/drivers/net/ethernet/ti/cpsw.c
> >> +++ b/drivers/net/ethernet/ti/cpsw.c
> >> @@ -2764,7 +2764,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >> struct net_device *ndev;
> >> struct cpsw_priv *priv;
> >> void __iomem *ss_regs;
> >> - struct resource *res, *ss_res;
> >> + struct resource *ss_res;
> >> struct gpio_descs *mode;
> >> const struct soc_device_attribute *soc;
> >> struct cpsw_common *cpsw;
> >> @@ -2798,8 +2798,7 @@ static int cpsw_probe(struct platform_device *pdev)
> >
> > And just out-of-context, we also have:
> >
> > ss_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > ss_regs = devm_ioremap_resource(dev, ss_res);
> > if (IS_ERR(ss_regs))
> >
> > which was not detected as being the same pattern?
> >
> > Interesting...
>
> ss_res is used below to determine phys address of CPPI RAM.
Right, thanks, I missed that.
> >
> >> return PTR_ERR(ss_regs);
> >> cpsw->regs = ss_regs;
> >>
> >> - res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> >> - cpsw->wr_regs = devm_ioremap_resource(dev, res);
> >> + cpsw->wr_regs = devm_platform_ioremap_resource(pdev, 1);
> >> if (IS_ERR(cpsw->wr_regs))
> >> return PTR_ERR(cpsw->wr_regs);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] net: sysctl: cleanup net_sysctl_init error exit paths
From: Nicolas Dichtel @ 2019-09-18 9:44 UTC (permalink / raw)
To: George G. Davis, David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20190917155354.GA15686@mam-gdavis-lt>
Le 17/09/2019 à 17:53, George G. Davis a écrit :
[snip]
> Ping, "Linux 5.3" kernel has been released [1] and it appears that the
> 5.4 merge window is open. The patch [2] remains unchanged since my initial
> post. Please consider applying it.
net-next is closed:
http://vger.kernel.org/~davem/net-next.html
You will have to resend the patch when net-next opens.
^ permalink raw reply
* RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Jianyong Wu (Arm Technology China) @ 2019-09-18 9:57 UTC (permalink / raw)
To: Paolo Bonzini, netdev@vger.kernel.org, yangbo.lu@nxp.com,
john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, maz@kernel.org,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China),
nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <83ed7fac-277f-a31e-af37-8ec134f39d26@redhat.com>
Hi Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Wednesday, September 18, 2019 4:26 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>; Will
> Deacon <Will.Deacon@arm.com>; Suzuki Poulose
> <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
>
> On 18/09/19 10:07, Jianyong Wu wrote:
> > + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
> > + getnstimeofday(ts);
>
> This is not Y2038-safe. Please use ktime_get_real_ts64 instead, and split the
> 64-bit seconds value between val[0] and val[1].
>
As far as I know, y2038-safe will only affect signed 32-bit integer, how does it affect 64-bit integer?
And why split 64-bit number into two blocks is necessary?
Also, split number will lead to shortage of return value.
> However, it seems to me that the new function is not needed and you can
> just use ktime_get_snapshot. You'll get the time in systime_snapshot->real
> and the cycles value in systime_snapshot->cycles.
See patch 5/6, I need both counter cycle and clocksource, ktime_get_snapshot seems only offer cycles.
>
> > + get_current_counterval(&sc);
> > + val[0] = ts->tv_sec;
> > + val[1] = ts->tv_nsec;
> > + val[2] = sc.cycles;
> > + val[3] = 0;
> > + break;
>
> This should return a guest-cycles value. If the cycles values always the same
> between the host and the guest on ARM, then okay. If not, you have to
> apply whatever offset exists.
>
In my opinion, when use ptp_kvm as clock sources to sync time between host and guest, user should promise the guest and host has no
clock offset. So we can be sure that the cycle between guest and host should be keep consistent. But I need check it.
I think host cycle should be returned to guest as we should promise we get clock and counter in the same time.
Thanks
Jianyong Wu
> Thanks,
>
> Paolo
^ permalink raw reply
* Re: [PATCH 3/4] seccomp: avoid overflow in implicit constant conversion
From: Tyler Hicks @ 2019-09-18 10:01 UTC (permalink / raw)
To: Christian Brauner
Cc: keescook, luto, jannh, wad, shuah, ast, daniel, kafai,
songliubraving, yhs, linux-kernel, linux-kselftest, netdev, bpf,
Tycho Andersen, stable
In-Reply-To: <20190918084833.9369-4-christian.brauner@ubuntu.com>
On 2019-09-18 10:48:32, Christian Brauner wrote:
> USER_NOTIF_MAGIC is assigned to int variables in this test so set it to INT_MAX
> to avoid warnings:
>
> seccomp_bpf.c: In function ‘user_notification_continue’:
> seccomp_bpf.c:3088:26: warning: overflow in implicit constant conversion [-Woverflow]
> #define USER_NOTIF_MAGIC 116983961184613L
> ^
> seccomp_bpf.c:3572:15: note: in expansion of macro ‘USER_NOTIF_MAGIC’
> resp.error = USER_NOTIF_MAGIC;
> ^~~~~~~~~~~~~~~~
>
> Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Will Drewry <wad@chromium.org>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Cc: Tycho Andersen <tycho@tycho.ws>
> CC: Tyler Hicks <tyhicks@canonical.com>
INT_MAX should be a safe value to use.
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
Tyler
> Cc: Jann Horn <jannh@google.com>
> Cc: stable@vger.kernel.org
> Cc: linux-kselftest@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: bpf@vger.kernel.org
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index ee52eab01800..921f0e26f835 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -35,6 +35,7 @@
> #include <stdbool.h>
> #include <string.h>
> #include <time.h>
> +#include <limits.h>
> #include <linux/elf.h>
> #include <sys/uio.h>
> #include <sys/utsname.h>
> @@ -3080,7 +3081,7 @@ static int user_trap_syscall(int nr, unsigned int flags)
> return seccomp(SECCOMP_SET_MODE_FILTER, flags, &prog);
> }
>
> -#define USER_NOTIF_MAGIC 116983961184613L
> +#define USER_NOTIF_MAGIC INT_MAX
> TEST(user_notification_basic)
> {
> pid_t pid;
> --
> 2.23.0
>
^ permalink raw reply
* [PATCH][next] can: fix resource leak of skb on error return paths
From: Colin King @ 2019-09-18 10:11 UTC (permalink / raw)
To: Robin van der Gracht, Oleksij Rempel, Pengutronix Kernel Team,
Oliver Hartkopp, Marc Kleine-Budde, David S . Miller, linux-can,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently the error return paths do not free skb and this results
in a memory leak. Fix this by freeing them before the return.
Addresses-Coverity: ("Resource leak")
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/can/j1939/socket.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/can/j1939/socket.c b/net/can/j1939/socket.c
index 37c1040bcb9c..5c6eabcb5df1 100644
--- a/net/can/j1939/socket.c
+++ b/net/can/j1939/socket.c
@@ -909,8 +909,10 @@ void j1939_sk_errqueue(struct j1939_session *session,
memset(serr, 0, sizeof(*serr));
switch (type) {
case J1939_ERRQUEUE_ACK:
- if (!(sk->sk_tsflags & SOF_TIMESTAMPING_TX_ACK))
+ if (!(sk->sk_tsflags & SOF_TIMESTAMPING_TX_ACK)) {
+ kfree_skb(skb);
return;
+ }
serr->ee.ee_errno = ENOMSG;
serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
@@ -918,8 +920,10 @@ void j1939_sk_errqueue(struct j1939_session *session,
state = "ACK";
break;
case J1939_ERRQUEUE_SCHED:
- if (!(sk->sk_tsflags & SOF_TIMESTAMPING_TX_SCHED))
+ if (!(sk->sk_tsflags & SOF_TIMESTAMPING_TX_SCHED)) {
+ kfree_skb(skb);
return;
+ }
serr->ee.ee_errno = ENOMSG;
serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 bpf-next 07/14] samples: bpf: add makefile.target for separate CC target build
From: Ivan Khoronzhuk @ 2019-09-18 10:12 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4Bzaidog3n0YP6F5dL2rCrHtKCOBXS0as7usymk8Twdro4w@mail.gmail.com>
On Tue, Sep 17, 2019 at 04:19:40PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:58 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> The makefile.target is added only and will be used in
>
>typo: Makefile
>
>> sample/bpf/Makefile later in order to switch cross-compiling on CC
>
>on -> to
>
>> from HOSTCC environment.
>>
>> The HOSTCC is supposed to build binaries and tools running on the host
>> afterwards, in order to simplify build or so, like "fixdep" or else.
>> In case of cross compiling "fixdep" is executed on host when the rest
>> samples should run on target arch. In order to build binaries for
>> target arch with CC and tools running on host with HOSTCC, lets add
>> Makefile.target for simplicity, having definition and routines similar
>> to ones, used in script/Makefile.host. This allows later add
>> cross-compilation to samples/bpf with minimum changes.
>>
>> The tprog stands for target programs built with CC.
>
>Why tprog? Could we just use prog: hostprog vs prog.
Prev. version was with prog, but Yonghong Song found it ambiguous.
As prog can be bpf also. So, decision was made to follow logic:
* target prog - non bpf progs
* bpf prog = bpf prog, that can be later smth similar, providing build options
for each bpf object separately.
Details here:
https://lkml.org/lkml/2019/9/13/1037
>
>>
>> Makefile.target contains only stuff needed for samples/bpf, potentially
>> can be reused later and now needed only for unblocking tricky
>> samples/bpf cross compilation.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile.target | 75 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 75 insertions(+)
>> create mode 100644 samples/bpf/Makefile.target
>>
>> diff --git a/samples/bpf/Makefile.target b/samples/bpf/Makefile.target
>> new file mode 100644
>> index 000000000000..fb6de63f7d2f
>> --- /dev/null
>> +++ b/samples/bpf/Makefile.target
>> @@ -0,0 +1,75 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# ==========================================================================
>> +# Building binaries on the host system
>> +# Binaries are not used during the compilation of the kernel, and intendent
>
>typo: intended
>
>> +# to be build for target board, target board can be host ofc. Added to build
>
>What's ofc, is it "of course"?
yes, ofc )
>
>> +# binaries to run not on host system.
>> +#
>> +# Sample syntax (see Documentation/kbuild/makefiles.rst for reference)
>> +# tprogs-y := xsk_example
>> +# Will compile xdpsock_example.c and create an executable named xsk_example
>
>You mix references to xsk_example and xdpsock_example, which is very
>confusing. I'm guessing you meant to use xdpsock_example consistently.
Oh, yes. Thanks.
>
>> +#
>> +# tprogs-y := xdpsock
>> +# xdpsock-objs := xdpsock_1.o xdpsock_2.o
>> +# Will compile xdpsock_1.c and xdpsock_2.c, and then link the executable
>> +# xdpsock, based on xdpsock_1.o and xdpsock_2.o
>> +#
>> +# Inherited from scripts/Makefile.host
>
>"Inspired by" or "Derived from" would be probably more appropriate term :)
I will replace with "Derived from", looks better.
>
>> +#
>> +__tprogs := $(sort $(tprogs-y))
>> +
>> +# C code
>> +# Executables compiled from a single .c file
>> +tprog-csingle := $(foreach m,$(__tprogs), \
>> + $(if $($(m)-objs),,$(m)))
>> +
>> +# C executables linked based on several .o files
>> +tprog-cmulti := $(foreach m,$(__tprogs),\
>> + $(if $($(m)-objs),$(m)))
>> +
>> +# Object (.o) files compiled from .c files
>> +tprog-cobjs := $(sort $(foreach m,$(__tprogs),$($(m)-objs)))
>> +
>> +tprog-csingle := $(addprefix $(obj)/,$(tprog-csingle))
>> +tprog-cmulti := $(addprefix $(obj)/,$(tprog-cmulti))
>> +tprog-cobjs := $(addprefix $(obj)/,$(tprog-cobjs))
>> +
>> +#####
>> +# Handle options to gcc. Support building with separate output directory
>> +
>> +_tprogc_flags = $(TPROGS_CFLAGS) \
>> + $(TPROGCFLAGS_$(basetarget).o)
>> +
>> +# $(objtree)/$(obj) for including generated headers from checkin source files
>> +ifeq ($(KBUILD_EXTMOD),)
>> +ifdef building_out_of_srctree
>> +_tprogc_flags += -I $(objtree)/$(obj)
>> +endif
>> +endif
>> +
>> +tprogc_flags = -Wp,-MD,$(depfile) $(_tprogc_flags)
>> +
>> +# Create executable from a single .c file
>> +# tprog-csingle -> Executable
>> +quiet_cmd_tprog-csingle = CC $@
>> + cmd_tprog-csingle = $(CC) $(tprogc_flags) $(TPROGS_LDFLAGS) -o $@ $< \
>> + $(TPROGS_LDLIBS) $(TPROGLDLIBS_$(@F))
>> +$(tprog-csingle): $(obj)/%: $(src)/%.c FORCE
>> + $(call if_changed_dep,tprog-csingle)
>> +
>> +# Link an executable based on list of .o files, all plain c
>> +# tprog-cmulti -> executable
>> +quiet_cmd_tprog-cmulti = LD $@
>> + cmd_tprog-cmulti = $(CC) $(tprogc_flags) $(TPROGS_LDFLAGS) -o $@ \
>> + $(addprefix $(obj)/,$($(@F)-objs)) \
>> + $(TPROGS_LDLIBS) $(TPROGLDLIBS_$(@F))
>> +$(tprog-cmulti): $(tprog-cobjs) FORCE
>> + $(call if_changed,tprog-cmulti)
>> +$(call multi_depend, $(tprog-cmulti), , -objs)
>> +
>> +# Create .o file from a single .c file
>> +# tprog-cobjs -> .o
>> +quiet_cmd_tprog-cobjs = CC $@
>> + cmd_tprog-cobjs = $(CC) $(tprogc_flags) -c -o $@ $<
>> +$(tprog-cobjs): $(obj)/%.o: $(src)/%.c FORCE
>> + $(call if_changed_dep,tprog-cobjs)
>> --
>> 2.17.1
>>
>
>tprogs is quite confusing, but overall looks good to me.
I tend to leave it as tprogs, unless it's going to be progs and agreed with
Yonghong.
It follows logic:
- tprogs for bins
- bpfprogs or bojs or bprogs (could be) for bpf obj
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: net/dst_cache.c: preemption bug in net/dst_cache.c
From: Bharath Vedartham @ 2019-09-18 10:19 UTC (permalink / raw)
To: Xin Long
Cc: davem, Greg Kroah-Hartman, allison, tglx, network dev, LKML,
Jon Maloy
In-Reply-To: <CADvbK_c5+1-qDohRtFap25ih6XoAD3JirUz-impy7jvNZYpdvg@mail.gmail.com>
On Mon, Sep 09, 2019 at 05:48:25PM +0800, Xin Long wrote:
> On Fri, Aug 23, 2019 at 3:58 PM Bharath Vedartham <linux.bhar@gmail.com> wrote:
> >
> > Hi all,
> >
> > I just want to bring attention to the syzbot bug [1]
> >
> > Even though syzbot claims the bug to be in net/tipc, I feel it is in
> > net/dst_cache.c. Please correct me if I am wrong.
> >
> > This bug is being triggered a lot of times by syzbot since the day it
> > was reported. Also given that this is core networking code, I felt it
> > was important to bring this to attention.
> >
> > It looks like preemption needs to be disabled before using this_cpu_ptr
> > or maybe we would be better of using a get_cpu_var and put_cpu_var combo
> > here.
> b->media->send_msg (tipc_udp_send_msg)
> -> tipc_udp_xmit() -> dst_cache_get()
>
> send_msg() is always called under the protection of rcu_read_lock(), which
> already disabled preemption. If not, there must be some unbalanced calls of
> disable/enable preemption elsewhere.
>
> Agree that this could be a serious issue, do you have any reproducer for this?
>
> Thanks.
Hi Xin,
Sorry for the delayed response. I do not have a reproducer for this. You
can submit a patch to syzbot which can run the patch on the same system
on which it found the bug.
Thank you
Bharath
> >
> > [1] https://syzkaller.appspot.com/bug?id=dc6352b92862eb79373fe03fdf9af5928753e057
> >
> > Thank you
> > Bharath
^ permalink raw reply
* Re: [PATCH v3 bpf-next 08/14] samples: bpf: makefile: base target programs rules on Makefile.target
From: Ivan Khoronzhuk @ 2019-09-18 10:23 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzYFoJJk+WM51YT7NwCxQpy117DAMmgiJ1YbqaW9UUWpEg@mail.gmail.com>
On Tue, Sep 17, 2019 at 04:28:01PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:58 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>
>Please don't prepend "samples: bpf: makefile:" to patches,
>"samples/bpf: " is a typical we've used for BPF samples changes.
Ok.
>
>
>> The main reason for that - HOSTCC and CC have different aims.
>> HOSTCC is used to build programs running on host, that can
>> cross-comple target programs with CC. It was tested for arm and arm64
>> cross compilation, based on linaro toolchain, but should work for
>> others.
>>
>> So, in order to split cross compilation (CC) with host build (HOSTCC),
>> lets base samples on Makefile.target. It allows to cross-compile
>> samples/bpf programs with CC while auxialry tools running on host
>> built with HOSTCC.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 135 ++++++++++++++++++++++---------------------
>> 1 file changed, 69 insertions(+), 66 deletions(-)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 9d923546e087..1579cc16a1c2 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -4,55 +4,53 @@ BPF_SAMPLES_PATH ?= $(abspath $(srctree)/$(src))
>> TOOLS_PATH := $(BPF_SAMPLES_PATH)/../../tools
>>
>> # List of programs to build
>> -hostprogs-y := test_lru_dist
[...]
>> -KBUILD_HOSTCFLAGS := $(ARM_ARCH_SELECTOR)
>> +TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR)
>> endif
>>
>> +TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS)
>
>Please group TPROGS_LDLIBS definition together with the one below,
>there doesn't seem to be a reason to split them this way.
No. It's used in Makefile.target and should be here, following hostprog logic.
>
>But also, it's kind of weird to use host libraries as cross-compiled
>libraries as well. Is that intentional?
No cross-compile split yet. This patch replace only KBUILD on TPROGS.
It's done in following patches.
>
>> +TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS)
>
>Same here, is it right to use HOSTCFLAGS and HOST_EXTRACFLAGS as a
>base for cross-compiled cflags?
same
[...]
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Paolo Bonzini @ 2019-09-18 10:23 UTC (permalink / raw)
To: Jianyong Wu (Arm Technology China), netdev@vger.kernel.org,
yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, maz@kernel.org,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Steve Capper,
Kaly Xin (Arm Technology China), Justin He (Arm Technology China),
nd, linux-arm-kernel@lists.infradead.org
In-Reply-To: <HE1PR0801MB1676F57B317AE85E3B934B32F48E0@HE1PR0801MB1676.eurprd08.prod.outlook.com>
On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
> Hi Paolo,
>
>> On 18/09/19 10:07, Jianyong Wu wrote:
>>> + case ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID:
>>> + getnstimeofday(ts);
>>
>> This is not Y2038-safe. Please use ktime_get_real_ts64 instead, and split the
>> 64-bit seconds value between val[0] and val[1].
>>
> As far as I know, y2038-safe will only affect signed 32-bit integer,
> how does it affect 64-bit integer?
> And why split 64-bit number into two blocks is necessary?
val is an u32, not an u64. (And val[0], where you store the seconds, is
best treated as signed, since val[0] == -1 is returned for
SMCCC_RET_NOT_SUPPORTED).
>> However, it seems to me that the new function is not needed and you can
>> just use ktime_get_snapshot. You'll get the time in systime_snapshot->real
>> and the cycles value in systime_snapshot->cycles.
>
> See patch 5/6, I need both counter cycle and clocksource, ktime_get_snapshot seems only offer cycles.
No, patch 5/6 only needs the current clock (ptp_sc.cycles is never
accessed). So you could just use READ_ONCE(tk->tkr_mono.clock).
However, even then I don't think it is correct to use ptp_sc.cs blindly
in patch 5. I think there is a misunderstanding on the meaning of
system_counterval.cs as passed to get_device_system_crosststamp.
system_counterval.cs is not the active clocksource; it's the clocksource
on which system_counterval.cycles is based.
Hypothetically, the clocksource could be one for which ptp_sc.cycles is
_not_ a cycle value. If you set system_counterval.cs to the system
clocksource, get_device_system_crosststamp will return a bogus value.
So system_counterval.cs should be set to something like
&clocksource_counter (from drivers/clocksource/arm_arch_timer.c).
Perhaps the right place to define kvm_arch_ptp_get_clock_fn is in that file?
>>> + get_current_counterval(&sc);
>>> + val[0] = ts->tv_sec;
>>> + val[1] = ts->tv_nsec;
>>> + val[2] = sc.cycles;
>>> + val[3] = 0;
>>> + break;
>>
>> This should return a guest-cycles value. If the cycles values always the same
>> between the host and the guest on ARM, then okay. If not, you have to
>> apply whatever offset exists.
>>
> In my opinion, when use ptp_kvm as clock sources to sync time
> between host and guest, user should promise the guest and host has no
> clock offset.
What would be the adverse effect of having a fixed offset between guest
and host? If there were one, you'd have to check that and fail the
hypercall if there is an offset. But again, I think it's enough to
subtract vcpu_vtimer(vcpu)->cntvoff or something like that.
You also have to check here that the clocksource is based on the ARM
architectural timer. Again, maybe you could place the implementation in
drivers/clocksource/arm_arch_timer.c, and make it return -ENODEV if the
active clocksource is not clocksource_counter. Then KVM can look for
errors and return SMCCC_RET_NOT_SUPPORTED in that case.
Thanks,
Paolo
> So we can be sure that the cycle between guest and
> host should be keep consistent. But I need check it.
> I think host cycle should be returned to guest as we should promise
> we get clock and counter in the same time.
^ permalink raw reply
* Re: [PATCH v3 bpf-next 09/14] samples: bpf: makefile: use own flags but not host when cross compile
From: Ivan Khoronzhuk @ 2019-09-18 10:35 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzbuPnxAs0A=w60q0jTCy5pb2R-h0uEuT2tmvjsaj4DH4A@mail.gmail.com>
On Tue, Sep 17, 2019 at 04:42:07PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> While compile natively, the hosts cflags and ldflags are equal to ones
>> used from HOSTCFLAGS and HOSTLDFLAGS. When cross compiling it should
>> have own, used for target arch. While verification, for arm, arm64 and
>> x86_64 the following flags were used alsways:
>>
>> -Wall
>> -O2
>> -fomit-frame-pointer
>> -Wmissing-prototypes
>> -Wstrict-prototypes
>>
>> So, add them as they were verified and used before adding
>> Makefile.target, but anyway limit it only for cross compile options as
>> for host can be some configurations when another options can be used,
>> So, for host arch samples left all as is, it allows to avoid potential
>> option mistmatches for existent environments.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 1579cc16a1c2..b5c87a8b8b51 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -178,8 +178,17 @@ CLANG_EXTRA_CFLAGS := $(ARM_ARCH_SELECTOR)
>> TPROGS_CFLAGS += $(ARM_ARCH_SELECTOR)
>> endif
>>
>> +ifdef CROSS_COMPILE
>> +TPROGS_CFLAGS += -Wall
>> +TPROGS_CFLAGS += -O2
>
>Specifying one arg per line seems like overkill, put them in one line?
Will combine.
>
>> +TPROGS_CFLAGS += -fomit-frame-pointer
>
>Why this one?
I've explained in commit msg. The logic is to have as much as close options
to have smiliar binaries. As those options are used before for hosts and kinda
cross builds - better follow same way.
>
>> +TPROGS_CFLAGS += -Wmissing-prototypes
>> +TPROGS_CFLAGS += -Wstrict-prototypes
>
>Are these in some way special that we want them in cross-compile mode only?
>
>All of those flags seem useful regardless of cross-compilation or not,
>shouldn't they be common? I'm a bit lost about the intent here...
They are common but split is needed to expose it at least. Also host for
different arches can have some own opts already used that shouldn't be present
for cross, better not mix it for safety.
>
>> +else
>> TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS)
>> TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS)
>> +endif
>> +
>> TPROGS_CFLAGS += -I$(objtree)/usr/include
>> TPROGS_CFLAGS += -I$(srctree)/tools/lib/bpf/
>> TPROGS_CFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v3 bpf-next 11/14] libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf targets
From: Ivan Khoronzhuk @ 2019-09-18 11:05 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzZXNN_dhs=jUjtfCqtuV1bk9H=q5b07kVDQQsysjhF4cQ@mail.gmail.com>
On Tue, Sep 17, 2019 at 10:19:22PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 4:00 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them
>> correctly to build command, for instance when --sysroot is used or
>> external libraries are used, like -lelf, wich can be absent in
>> toolchain. This can be used for samples/bpf cross-compiling allowing
>> to get elf lib from sysroot.
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> tools/lib/bpf/Makefile | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
>> index c6f94cffe06e..bccfa556ef4e 100644
>> --- a/tools/lib/bpf/Makefile
>> +++ b/tools/lib/bpf/Makefile
>> @@ -94,6 +94,10 @@ else
>> CFLAGS := -g -Wall
>> endif
>>
>> +ifdef EXTRA_CXXFLAGS
>> + CXXFLAGS := $(EXTRA_CXXFLAGS)
>> +endif
>> +
>> ifeq ($(feature-libelf-mmap), 1)
>> override CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
>> endif
>> @@ -176,8 +180,9 @@ $(BPF_IN): force elfdep bpfdep
>> $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
>>
>> $(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
>> - $(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
>> - -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
>> + $(QUIET_LINK)$(CC) $(LDFLAGS) \
>> + --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
>> + -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
>> @ln -sf $(@F) $(OUTPUT)libbpf.so
>> @ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION)
>>
>> @@ -185,7 +190,7 @@ $(OUTPUT)libbpf.a: $(BPF_IN)
>> $(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
>>
>> $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a
>> - $(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@
>> + $(QUIET_LINK)$(CXX) $(CXXFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@
>
>Instead of doing ifdef EXTRA_CXXFLAGS bit above, you can just include
>both $(CXXFLAGS) and $(EXTRA_CXXFLAGS), which will do the right thing
>(and is actually recommended my make documentation way to do this).
It's good practice to follow existent style, I've done similar way as for
CFLAGS + EXTRACFLAGS here, didn't want to verify it can impact on
smth else. And my goal is not to correct everything but embed my
functionality, series tool large w/o it.
>
>But actually, there is no need to use C++ compiler here,
>test_libbpf.cpp can just be plain C. Do you mind renaming it to .c and
>using C compiler instead?
Seems like, will try in next v.
>
>>
>> $(OUTPUT)libbpf.pc:
>> $(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* Re: [PATCH v3 bpf-next 13/14] samples: bpf: makefile: add sysroot support
From: Ivan Khoronzhuk @ 2019-09-18 11:09 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Alexei Starovoitov, Daniel Borkmann, Yonghong Song,
David S. Miller, Jakub Kicinski, Jesper Dangaard Brouer,
john fastabend, open list, Networking, bpf, clang-built-linux,
sergei.shtylyov
In-Reply-To: <CAEf4BzYa7mwFLZWdS0EMf4m=s88a94z6p30mxN8Q9=erpE5=Xg@mail.gmail.com>
On Tue, Sep 17, 2019 at 10:23:57PM -0700, Andrii Nakryiko wrote:
>On Mon, Sep 16, 2019 at 4:00 AM Ivan Khoronzhuk
><ivan.khoronzhuk@linaro.org> wrote:
>>
>> Basically it only enables that was added by previous couple fixes.
>> Sysroot contains correct libs installed and its headers ofc. Useful
>
>Please, let's not use unnecessary abbreviations/slang. "Of course" is
>not too long and is a proper English, let's stick to it.
>
>> when working with NFC or virtual machine.
>>
>> Usage:
>>
>> clean (on demand)
>> make ARCH=arm -C samples/bpf clean
>> make ARCH=arm -C tools clean
>> make ARCH=arm clean
>>
>> configure and install headers:
>>
>> make ARCH=arm defconfig
>> make ARCH=arm headers_install
>>
>> build samples/bpf:
>> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- samples/bpf/ \
>> SYSROOT="path/to/sysroot"
>>
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>> ---
>> samples/bpf/Makefile | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>> index 133123d4c7d7..57ddf055d6c3 100644
>> --- a/samples/bpf/Makefile
>> +++ b/samples/bpf/Makefile
>> @@ -194,6 +194,11 @@ TPROGS_CFLAGS += -I$(srctree)/tools/lib/
>> TPROGS_CFLAGS += -I$(srctree)/tools/include
>> TPROGS_CFLAGS += -I$(srctree)/tools/perf
>>
>> +ifdef SYSROOT
>> +TPROGS_CFLAGS += --sysroot=${SYSROOT}
>> +TPROGS_LDFLAGS := -L${SYSROOT}/usr/lib
>
>Please stay consistent: $() instead of ${}?
Yes, thanks.
>
>> +endif
>> +
>> EXTRA_CXXFLAGS := $(TPROGS_CFLAGS)
>>
>> # options not valid for C++
>> --
>> 2.17.1
>>
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH net,stable] cdc_ncm: fix divide-by-zero caused by invalid wMaxPacketSize
From: Bjørn Mork @ 2019-09-18 12:01 UTC (permalink / raw)
To: netdev
Cc: linux-usb, Oliver Neukum, Bjørn Mork,
syzbot+ce366e2b8296e25d84f5
Endpoints with zero wMaxPacketSize are not usable for transferring
data. Ignore such endpoints when looking for valid in, out and
status pipes, to make the driver more robust against invalid and
meaningless descriptors.
The wMaxPacketSize of the out pipe is used as divisor. So this change
fixes a divide-by-zero bug.
Reported-by: syzbot+ce366e2b8296e25d84f5@syzkaller.appspotmail.com
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
#syz test: https://github.com/google/kasan.git f0df5c1b
drivers/net/usb/cdc_ncm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 50c05d0f44cb..00cab3f43a4c 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -681,8 +681,12 @@ cdc_ncm_find_endpoints(struct usbnet *dev, struct usb_interface *intf)
u8 ep;
for (ep = 0; ep < intf->cur_altsetting->desc.bNumEndpoints; ep++) {
-
e = intf->cur_altsetting->endpoint + ep;
+
+ /* ignore endpoints which cannot transfer data */
+ if (!usb_endpoint_maxp(&e->desc))
+ continue;
+
switch (e->desc.bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) {
case USB_ENDPOINT_XFER_INT:
if (usb_endpoint_dir_in(&e->desc)) {
--
2.20.1
^ permalink raw reply related
* hippi: dead code issue on skb->data DMA limitations check
From: Colin Ian King @ 2019-09-18 12:07 UTC (permalink / raw)
To: Jes Sorensen, David S. Miller, open list:HIPPI, netdev; +Cc: linux-kernel
Hi there,
Static analysis with Coverity has detected an issue in rr_init1() in
drivers/net/hippi/rrunner.c as follows:
CID 13516 (#1 of 1): Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)
result_independent_of_operands: ((unsigned long)skb->data & 4095) >
18446744073709486295UL /* ~0xff28 */ is always false regardless of the
values of its operands. This occurs as the logical operand of if.
653 /*
654 * Sanity test to see if we conflict with the DMA
655 * limitations of the Roadrunner.
656 */
657 if ((((unsigned long)skb->data) & 0xfff) > ~65320)
CID 14371: Logically dead code (DEADCODE)
658 printk("skb alloc error\n");
659
Given that this check is currently dead code and it's been in the driver
for ages, should we just throw this check away or fix it? I'm not
entirely sure what the original intent was, so I'm not clear on a fix.
Colin
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: remove un-implemented property
From: Rob Herring @ 2019-09-18 12:07 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel@vger.kernel.org, David Miller
In-Reply-To: <20190918111447.3084-1-alexandru.ardelean@analog.com>
On Wed, Sep 18, 2019 at 3:15 AM Alexandru Ardelean
<alexandru.ardelean@analog.com> wrote:
>
> The `adi,disable-energy-detect` property was implemented in an initial
> version of the `adin` driver series, but after a review it was discarded in
> favor of implementing the ETHTOOL_PHY_EDPD phy-tunable option.
>
> With the ETHTOOL_PHY_EDPD control, it's possible to disable/enable
> Energy-Detect-Power-Down for the `adin` PHY, so this device-tree is not
> needed.
>
> Fixes: 767078132ff9 ("dt-bindings: net: add bindings for ADIN PHY driver")
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> Documentation/devicetree/bindings/net/adi,adin.yaml | 7 -------
> 1 file changed, 7 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH net] iwlwifi: add dependency of THERMAL with IWLMVM
From: Mao Wenan @ 2019-09-18 12:28 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo, davem
Cc: linux-wireless, netdev, linux-kernel, kernel-janitors, Mao Wenan
If CONFIG_IWLMVM=y, CONFIG_THERMAL=n, below error can be found:
drivers/net/wireless/intel/iwlwifi/mvm/fw.o: In function `iwl_mvm_up':
fw.c:(.text+0x2c26): undefined reference to `iwl_mvm_send_temp_report_ths_cmd'
make: *** [vmlinux] Error 1
After commit 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal
monitoring regardless of CONFIG_THERMAL"), iwl_mvm_up()
calls iwl_mvm_send_temp_report_ths_cmd(), but this function
is under CONFIG_THERMAL, which is depended on CONFIG_THERMAL.
Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig
index 7dbc0d3..801aa0f 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -65,6 +65,7 @@ config IWLMVM
tristate "Intel Wireless WiFi MVM Firmware support"
select WANT_DEV_COREDUMP
depends on MAC80211
+ depends on THERMAL
help
This is the driver that supports the MVM firmware. The list
of the devices that use this firmware is available here:
--
2.7.4
^ permalink raw reply related
* [PATCH net,stable] usbnet: ignore endpoints with invalid wMaxPacketSize
From: Bjørn Mork @ 2019-09-18 12:17 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Oliver Neukum, Bjørn Mork
Endpoints with zero wMaxPacketSize are not usable for transferring
data. Ignore such endpoints when looking for valid in, out and
status pipes, to make the drivers more robust against invalid and
meaningless descriptors.
The wMaxPacketSize of these endpoints are used for memory allocations
and as divisors in many usbnet minidrivers. Avoiding zero is therefore
critical.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/usb/usbnet.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 58952a79b05f..dbea2136d901 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -100,6 +100,11 @@ int usbnet_get_endpoints(struct usbnet *dev, struct usb_interface *intf)
int intr = 0;
e = alt->endpoint + ep;
+
+ /* ignore endpoints which cannot transfer data */
+ if (!usb_endpoint_maxp(&e->desc))
+ continue;
+
switch (e->desc.bmAttributes) {
case USB_ENDPOINT_XFER_INT:
if (!usb_endpoint_dir_in(&e->desc))
--
2.20.1
^ permalink raw reply related
* Re: divide error in cdc_ncm_update_rxtx_max
From: syzbot @ 2019-09-18 12:26 UTC (permalink / raw)
To: bjorn, linux-usb, netdev, oliver, syzkaller-bugs
In-Reply-To: <20190918120147.4520-1-bjorn@mork.no>
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+ce366e2b8296e25d84f5@syzkaller.appspotmail.com
Tested on:
commit: f0df5c1b usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git
kernel config: https://syzkaller.appspot.com/x/.config?x=5c6633fa4ed00be5
dashboard link: https://syzkaller.appspot.com/bug?extid=ce366e2b8296e25d84f5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
patch: https://syzkaller.appspot.com/x/patch.diff?x=114971b5600000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply
* Re: [PATCH v7 1/7] nfc: pn533: i2c: "pn532" as dt compatible string
From: Simon Horman @ 2019-09-18 12:34 UTC (permalink / raw)
To: Lars Poeschel
Cc: Allison Randal, Greg Kroah-Hartman, Jilayne Lovejoy, Kate Stewart,
Thomas Gleixner, open list:NFC SUBSYSTEM, open list, Johan Hovold
In-Reply-To: <20190910093129.1844-1-poeschel@lemonage.de>
On Tue, Sep 10, 2019 at 11:31:21AM +0200, Lars Poeschel wrote:
> It is favourable to have one unified compatible string for devices that
> have multiple interfaces. So this adds simply "pn532" as the devicetree
> binding compatible string and makes a note that the old ones are
> deprecated.
Do you also need to update
Documentation/devicetree/bindings/net/nfc/pn533-i2c.txt
to both document the new compat string and deprecate the old ones?
> Cc: Johan Hovold <johan@kernel.org>
> Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
> ---
> Changes in v6:
> - Rebased the patch series on v5.3-rc5
>
> Changes in v3:
> - This patch is new in v3
>
> drivers/nfc/pn533/i2c.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> index 1832cd921ea7..1abd40398a5a 100644
> --- a/drivers/nfc/pn533/i2c.c
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -245,6 +245,11 @@ static int pn533_i2c_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id of_pn533_i2c_match[] = {
> + { .compatible = "nxp,pn532", },
> + /*
> + * NOTE: The use of the compatibles with the trailing "...-i2c" is
> + * deprecated and will be removed.
> + */
> { .compatible = "nxp,pn533-i2c", },
> { .compatible = "nxp,pn532-i2c", },
> {},
> --
> 2.23.0
>
^ permalink raw reply
* [PATCH] bonding/802.3ad: fix slave initialization states race
From: Aleksei Zakharov @ 2019-09-18 13:05 UTC (permalink / raw)
To: netdev
Once a while, one of 802.3ad slaves fails to initialize and hangs in
BOND_LINK_FAIL state. Commit 334031219a84 ("bonding/802.3ad: fix slave
link initialization transition states") checks slave->last_link_up. But
link can still hang in weird state.
After physical link comes up it sends first two LACPDU messages and
doesn't work properly after that. It doesn't send or receive LACPDU.
Once it happens, the only message in dmesg is:
bond1: link status up again after 0 ms for interface eth2
This behavior can be reproduced (not every time):
1. Set slave link down
2. Wait for 1-3 seconds
3. Set slave link up
The fix is to check slave->link before setting it to BOND_LINK_FAIL or
BOND_LINK_DOWN state. If got invalid Speed/Dupex values and link is in
BOND_LINK_UP state, mark it as BOND_LINK_FAIL; otherwise mark it as
BOND_LINK_DOWN.
Fixes: 334031219a84 ("bonding/802.3ad: fix slave link initialization
transition states")
Signed-off-by: Aleksei Zakharov <zakharov.a.g@yandex.ru>
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 931d9d935686..a28776d8f33f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3135,7 +3135,7 @@ static int bond_slave_netdev_event(unsigned long event,
*/
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD) {
- if (slave->last_link_up)
+ if (slave->link == BOND_LINK_UP)
slave->link = BOND_LINK_FAIL;
else
slave->link = BOND_LINK_DOWN;
--
2.17.1
^ permalink raw reply related
* [PATCH v3] bonding: force enable lacp port after link state recovery for 802.3ad
From: zhangsha.zhang @ 2019-09-18 13:06 UTC (permalink / raw)
To: jay.vosburgh, vfalico, andy, davem, netdev, linux-kernel,
yuehaibing, hunongda, alex.chen, zhangsha.zhang
From: Sha Zhang <zhangsha.zhang@huawei.com>
After the commit 334031219a84 ("bonding/802.3ad: fix slave link
initialization transition states") merged,
the slave's link status will be changed to BOND_LINK_FAIL
from BOND_LINK_DOWN in the following scenario:
- Driver reports loss of carrier and
bonding driver receives NETDEV_DOWN notifier
- slave's duplex and speed is zerod and
its port->is_enabled is cleard to 'false';
- Driver reports link recovery and
bonding driver receives NETDEV_UP notifier;
- If speed/duplex getting failed here, the link status
will be changed to BOND_LINK_FAIL;
- The MII monotor later recover the slave's speed/duplex
and set link status to BOND_LINK_UP, but remains
the 'port->is_enabled' to 'false'.
In this scenario, the lacp port will not be enabled even its speed
and duplex are valid. The bond will not send LACPDU's, and its
state is 'AD_STATE_DEFAULTED' forever. The simplest fix I think
is to call bond_3ad_handle_link_change() in bond_miimon_commit,
this function can enable lacp after port slave speed check.
As enabled, the lacp port can run its state machine normally
after link recovery.
Signed-off-by: Sha Zhang <zhangsha.zhang@huawei.com>
---
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 931d9d9..76324a5 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2206,7 +2206,8 @@ static void bond_miimon_commit(struct bonding *bond)
*/
if (BOND_MODE(bond) == BOND_MODE_8023AD &&
slave->link == BOND_LINK_UP)
- bond_3ad_adapter_speed_duplex_changed(slave);
+ bond_3ad_handle_link_change(slave,
+ BOND_LINK_UP);
continue;
case BOND_LINK_UP:
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net] iwlwifi: add dependency of THERMAL with IWLMVM
From: Kalle Valo @ 2019-09-18 13:08 UTC (permalink / raw)
To: Mao Wenan
Cc: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
davem, linux-wireless, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20190918122815.155657-1-maowenan@huawei.com>
Mao Wenan <maowenan@huawei.com> writes:
> If CONFIG_IWLMVM=y, CONFIG_THERMAL=n, below error can be found:
> drivers/net/wireless/intel/iwlwifi/mvm/fw.o: In function `iwl_mvm_up':
> fw.c:(.text+0x2c26): undefined reference to `iwl_mvm_send_temp_report_ths_cmd'
> make: *** [vmlinux] Error 1
>
> After commit 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal
> monitoring regardless of CONFIG_THERMAL"), iwl_mvm_up()
> calls iwl_mvm_send_temp_report_ths_cmd(), but this function
> is under CONFIG_THERMAL, which is depended on CONFIG_THERMAL.
>
> Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
> Signed-off-by: Mao Wenan <maowenan@huawei.com>
Luca, should I apply this directly to wireless-drivers?
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] drivers:staging:qlge: Removed unnecessary variable
From: Aliasgar Surti @ 2019-09-18 13:16 UTC (permalink / raw)
To: manishc, GR-Linux-NIC-Dev, gregkh, netdev, devel; +Cc: Aliasgar Surti
From: Aliasgar Surti <aliasgar.surti500@gmail.com>
coccicheck reported warning for unnecessary variable used.
This patch fixes the same by removing the variable and
returning value directly.
Signed-off-by: Aliasgar Surti <aliasgar.surti500@gmail.com>
---
drivers/staging/qlge/qlge_dbg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/qlge/qlge_dbg.c b/drivers/staging/qlge/qlge_dbg.c
index 31389ab..5599525 100644
--- a/drivers/staging/qlge/qlge_dbg.c
+++ b/drivers/staging/qlge/qlge_dbg.c
@@ -389,7 +389,6 @@ static int ql_get_xgmac_regs(struct ql_adapter *qdev, u32 *buf,
static int ql_get_ets_regs(struct ql_adapter *qdev, u32 *buf)
{
- int status = 0;
int i;
for (i = 0; i < 8; i++, buf++) {
@@ -402,7 +401,7 @@ static int ql_get_ets_regs(struct ql_adapter *qdev, u32 *buf)
*buf = ql_read32(qdev, CNA_ETS);
}
- return status;
+ return 0;
}
static void ql_get_intr_states(struct ql_adapter *qdev, u32 *buf)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] iwlwifi: add dependency of THERMAL with IWLMVM
From: Luciano Coelho @ 2019-09-18 13:17 UTC (permalink / raw)
To: Kalle Valo, Mao Wenan
Cc: johannes.berg, emmanuel.grumbach, linuxwifi, davem,
linux-wireless, netdev, linux-kernel, kernel-janitors
In-Reply-To: <875zlpbvks.fsf@kamboji.qca.qualcomm.com>
On Wed, 2019-09-18 at 16:08 +0300, Kalle Valo wrote:
> Mao Wenan <maowenan@huawei.com> writes:
>
> > If CONFIG_IWLMVM=y, CONFIG_THERMAL=n, below error can be found:
> > drivers/net/wireless/intel/iwlwifi/mvm/fw.o: In function `iwl_mvm_up':
> > fw.c:(.text+0x2c26): undefined reference to `iwl_mvm_send_temp_report_ths_cmd'
> > make: *** [vmlinux] Error 1
> >
> > After commit 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal
> > monitoring regardless of CONFIG_THERMAL"), iwl_mvm_up()
> > calls iwl_mvm_send_temp_report_ths_cmd(), but this function
> > is under CONFIG_THERMAL, which is depended on CONFIG_THERMAL.
> >
> > Fixes: 242d9c8b9a93 ("iwlwifi: mvm: use FW thermal monitoring regardless of CONFIG_THERMAL")
> > Signed-off-by: Mao Wenan <maowenan@huawei.com>
>
> Luca, should I apply this directly to wireless-drivers?
No, this patch defeats the point of the patch it fixes.
We have a proper fix already internally, which I haven't sent out yet,
that moves a couple of #ifdef's around to solve the issue. I'll send
the patch in a sec.
--
Cheers,
Luca.
^ 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