Re: [PATCH 1/7] net: 8021q: remove unneeded MODULE_VERSION() usage
On Fri, 2020-12-04 at 16:09 -0800, Jakub Kicinski wrote: > On Wed, 2 Dec 2020 13:49:53 +0100 Enrico Weigelt, metux IT consult > wrote: > > Remove MODULE_VERSION(), as it isn't needed at all: the only version > > making sense is the kernel version. > > > > Signed-off-by: Enrico Weigelt, metux IT consult > > Thanks for the patches. Please drop the "metux IT consult" from the > addresses. The from space is supposed to be for your name. If you _really_ want this superfluous 'metux IT consult' content in your signature, and I don't think you should, use parentheses around it. Enrico Weigelt (metux IT consult) Using a comma makes copy/paste into an email client think it's two addresses.
Re: [PATCH] staging: greybus: audio: Add missing unlock in gbaudio_dapm_free_controls()
在 2020/12/5 2:02, Vaibhav Agarwal 写道:
On Fri, Dec 4, 2020 at 2:10 PM Johan Hovold wrote:
On Fri, Dec 04, 2020 at 10:13:50AM +0800, Wang Hai wrote:
Add the missing unlock before return from function
gbaudio_dapm_free_controls() in the error handling case.
Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic audio
module")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
drivers/staging/greybus/audio_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/greybus/audio_helper.c
b/drivers/staging/greybus/audio_helper.c
index 237531ba60f3..293675dbea10 100644
--- a/drivers/staging/greybus/audio_helper.c
+++ b/drivers/staging/greybus/audio_helper.c
@@ -135,6 +135,7 @@ int gbaudio_dapm_free_controls(struct snd_soc_dapm_context
*dapm,
if (!w) {
dev_err(dapm->dev, "%s: widget not found\n",
widget->name);
+ mutex_unlock(>card->dapm_mutex);
return -EINVAL;
}
widget++;
This superficially looks correct, but there seems to be another bug in
this function. It can be used free an array of widgets, but if one of
them isn't found we just leak the rest. Perhaps that return should
rather be "widget++; continue;".
Vaibhav?
Thanks Wang for sharing the patch. As already pointed by Johan, this
function indeed has another bug as well.
Pls feel free to share the patch as suggested above.
I just sent another patch
"[PATCH] staging: greybus: audio: Fix possible leak free widgets in
gbaudio_dapm_free_controls"
Johan
.
[tip:core/mm] BUILD SUCCESS 68061c02bb295da4955f0d309b9459f0a7ba83dd
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/mm branch HEAD: 68061c02bb295da4955f0d309b9459f0a7ba83dd ARM: highmem: Fix cache_is_vivt() reference elapsed time: 724m configs tested: 116 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig nios2alldefconfig arcvdk_hs38_defconfig powerpc cm5200_defconfig arm tango4_defconfig mips decstation_r4k_defconfig powerpc tqm8555_defconfig sh se7721_defconfig powerpc ep88xc_defconfig arm bcm2835_defconfig powerpc acadia_defconfig arm assabet_defconfig powerpc skiroot_defconfig powerpc motionpro_defconfig mips jazz_defconfig powerpccell_defconfig ia64 alldefconfig nds32 defconfig powerpc tqm5200_defconfig arc haps_hs_defconfig arm spitz_defconfig arm exynos_defconfig arm pxa3xx_defconfig openrisc alldefconfig powerpc mgcoge_defconfig arm s3c2410_defconfig openriscor1ksim_defconfig arm at91_dt_defconfig powerpc ebony_defconfig mips tb0226_defconfig arm sama5_defconfig powerpc mpc8560_ads_defconfig ia64generic_defconfig arm omap1_defconfig armmini2440_defconfig s390defconfig m68kq40_defconfig sparc64 defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20201204 x86_64 randconfig-a006-20201204 x86_64 randconfig-a002-20201204 x86_64 randconfig-a001-20201204 x86_64 randconfig-a005-20201204 x86_64 randconfig-a003-20201204 i386 randconfig-a005-20201204 i386 randconfig-a004-20201204 i386 randconfig-a001-20201204 i386 randconfig-a002-20201204 i386 randconfig-a006-20201204 i386 randconfig-a003-20201204 i386 randconfig-a005-20201205 i386 randconfig-a004-20201205 i386 randconfig-a001-20201205 i386 randconfig-a002-20201205 i386 randconfig-a006-20201205 i386 randconfig-a003-20201205 i386 randconfig-a014-20201204 i386 randconfig-a013-20201204 i386 randconfig-a011-20201204 i386 randconfig-a015-20201204 i386 randconfig-a012-20201204 i386 randconfig-a016-20201204 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv
Re: [PATCH v3 1/4] irq: export kstat_irqs
On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote: > To try and detect potential interrupt storms that > have been occurring with tpm_tis devices it was suggested > to use kstat_irqs() to get the number of interrupts. > Since tpm_tis can be built as a module it needs kstat_irqs > exported. I think you should also have a paragraph explicitly stating that i915_pmu.c contains a duplicate of kstat_irqs() because it is not exported as of today. It adds a lot more weight to this given that there is already existing mainline usage (kind of). > > Reported-by: kernel test robot I'm not sure if this makes much sense. > Cc: Thomas Gleixner > Cc: Jarkko Sakkinen > Cc: Jason Gunthorpe > Cc: Peter Huewe > Cc: James Bottomley > Cc: Matthew Garrett > Cc: Hans de Goede > Signed-off-by: Jerry Snitselaar /Jarkko
[PATCH] staging: greybus: audio: Fix possible leak free widgets in gbaudio_dapm_free_controls
In gbaudio_dapm_free_controls(), if one of the widgets is not found, an error
will be returned directly, which will cause the rest to be unable to be freed,
resulting in leak.
This patch fixes the bug. If if one of them is not found, just skip and free
the others.
Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic
audio module")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
---
drivers/staging/greybus/audio_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_helper.c
b/drivers/staging/greybus/audio_helper.c
index 237531ba60f3..3011b8abce38 100644
--- a/drivers/staging/greybus/audio_helper.c
+++ b/drivers/staging/greybus/audio_helper.c
@@ -135,7 +135,8 @@ int gbaudio_dapm_free_controls(struct snd_soc_dapm_context
*dapm,
if (!w) {
dev_err(dapm->dev, "%s: widget not found\n",
widget->name);
- return -EINVAL;
+ widget++;
+ continue;
}
widget++;
#ifdef CONFIG_DEBUG_FS
--
2.17.1
Re: [PATCH v6] checkpatch: add fix for non-standard signature - co-authored-by
On 4/12/20 8:10 pm, Aditya Srivastava wrote:
> Currently, checkpatch.pl warns us for BAD_SIGN_OFF on the usage of
> non-standard signatures.
>
> An evaluation on v4.13..v5.8 showed that out of 539 warnings due to
> non-standard signatures, 43 are due to the use of 'Co-authored-by'
> tag, which may seem correct, but is not standard.
>
> The standard signature equivalent for 'Co-authored-by' is
> 'Co-developed-by'.
>
> Provide a fix by suggesting users with this signature alternative and
> replacing.
>
> Signed-off-by: Aditya Srivastava
> ---
> applies perfectly on the latest next-20201204 branch
>
> changes in v2: replace commit specific example with brief evaluation
>
> changes in v3: provide rationale to users for every signature tag suggestion;
> modify commit message describing arrival to conclusion in a structured way
>
> changes in v4: modify rationale for certain suggestions
>
> changes in v5: remove the tag deletion suggestions, ie "Generated-by" and
> "Celebrated-by"; rebase on last accepted changes; modify commit message
>
> changes in v6: reduce tag suggestions to only "Co-authored-by"; modify commit
> message accordingly; include complete version changelog
>
> scripts/checkpatch.pl | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4a026926139f..fc036d545d2d 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2832,6 +2832,9 @@ sub process {
>
> if ($sign_off !~ /$signature_tags/) {
> my $suggested_signature =
> find_standard_signature($sign_off);
> + if ($sign_off =~ /co-authored-by:/i) {
> + $suggested_signature =
> "Co-developed-by:";
> + }
> if ($suggested_signature eq "") {
> WARN("BAD_SIGN_OFF",
>"Non-standard signature:
> $sign_off\n" . $herecurr);
>
Hi Daniel and Peter
Sorry to disturb you. Actually we were planning to introduce a fix for
suggesting users to use "Co-developed-by" tag over "Co-authored-by"
and I noticed that you have earlier used "Co-authored-by" tag.
We feel that users perhaps use this tag as they are unaware of its
standard equivalent tag, "Co-developed-by"
Do you think that this fix will be beneficial for future users? If so,
can you please add your Acked-by to the patch?
Thanks
Aditya
Re: [tip: x86/urgent] x86/uprobes: Do not use prefixes.nbytes when looping over prefixes.bytes
On Sat, Dec 05, 2020 at 09:12:56AM +0900, Masami Hiramatsu wrote: > This may break tools/objtool build. Please keep "inat.h". How? Please elaborate. Build tests are fine here. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH REPOST] pcmcia: Remove NEC VRC4173 CARDU
Am Fri, Dec 04, 2020 at 08:20:09PM +0100 schrieb Sebastian Andrzej Siewior:
> On 2020-11-19 18:06:24 [+0100], To linux-kernel@vger.kernel.org wrote:
> > On 2020-11-13 22:34:08 [+0100], To linux-kernel@vger.kernel.org wrote:
> > > This driver is the very definition of bitrotting:
> > > - Introduced in commit
> > > 79a140932c776 ("[PATCH] mips: vR41xx updates")
> > > which is 2.6.11-rc3.
> > >
> > > - Provides ->register_callback which was removed in commit
> > > 7f316b033b36a ("[PATCH] pcmcia: remove socket register_callback")
> > > which is v2.6.14-rc3
> > >
> > > - Uses INIT_WORK() with three arguments which was removed in commit
> > > 65f27f38446e1 ("WorkStruct: Pass the work_struct pointer instead of
> > > context data")
> > > which is v2.6.20-rc1
> > >
> > > - Provides ->inquire_socket and uses socket_cap_t which was removed in
> > > commit
> > > b7949fdacbe00 ("[PCMCIA] Remove inquire_socket")
> > > which is 2.5.72
> > >
> > > - Provides ->get_io_map which was removed in commit
> > > d7de1b64a23b9 ("[PCMCIA] pcmcia-2: Remove get_io_map and get_mem_map
> > > socket methods.")
> > > which is 2.5.66
> > >
> > > Remove VRC4173 CARDU from the tree because it never had the luck to be
> > > successfully compiled. Let it finally find peace in byte heaven.
> > …
> > > This is a repost of
> > > https://lkml.kernel.org/r/20201001193234.gi6fp4vk3dypw...@linutronix.de
> > >
> > > which was a repost of
> > > https://lkml.kernel.org/r/20200916081629.cfi6svr3yjvzi...@linutronix.de
> >
> > Andrew, are you okay with routing this via your tree?
> > Nobody responded to this and as I documented in the patch description it
> > never compiled so.
>
> Andrew, any chance?
It's in pcmcia-next now.
Thanks,
Dominik
Re: [PATCH v3 1/3] x86/uprobes: Fix not using prefixes.nbytes for loop over prefixes.bytes
On Sat, Dec 05, 2020 at 09:10:32AM +0900, Masami Hiramatsu wrote: > In the future, if x86 ISA is expanded and add a legacy prefix > groups, Very unlikely. > then we have to add new insn_prefix_field data structure, which > size will not depend on NUM_INSN_FIELD_BYTES, but still depend on > MAX_LEGACY_PREFIX_GROUPS (and that will be 5). Isn't that what I'm saying too? Bottomline is, legacy prefixes should not use insn_field but a separate element which array size is independent of insn_byte_t bytes[4]. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Linux man-pages maintainership adjustments
Gidday, Anyone following linux-man@ in the last few months will have noticed that Alejandro (Alex) Colomar has become rather active in the project. Alex has kindly volunteered to take up some of the work of maintaining the project. In practice, that means he will be reviewing and merging some of the patches that land on linux-man@ and I'll be taking those changes from him to then push to git.kernel.org. After 16 years as maintainer, I'm very happy that Alex has come along to help out. And to be clear, I'm not planning to step away from the project any time soon, but maybe one day I will return to being just a contributor and no longer the maintainer. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH] pcmcia: db1xxx_ss: remove unneeded semicolon
Am Thu, Sep 10, 2020 at 10:05:24PM +0800 schrieb Jason Yan: > Eliminate the following coccicheck warning: > > drivers/pcmcia/db1xxx_ss.c:455:2-3: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: Jason Yan Applied to pcmcia-next. Thanks, Dominik
Re: KMSAN: uninit-value in dvb_usb_adapter_dvb_init (2)
syzbot has found a reproducer for the following issue on: HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=170babf750 kernel config: https://syzkaller.appspot.com/x/.config?x=eef728deea880383 dashboard link: https://syzkaller.appspot.com/bug?extid=e27b4fd589762b0b9329 compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=158833f750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=102a343750 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e27b4fd589762b0b9...@syzkaller.appspotmail.com dvb-usb: bulk message failed: -22 (5/0) dvb-usb: bulk message failed: -22 (5/0) dvb-usb: bulk message failed: -22 (5/0) = BUG: KMSAN: uninit-value in mac_address_string+0x1040/0x1170 lib/vsprintf.c:1281 CPU: 1 PID: 3485 Comm: kworker/1:2 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 mac_address_string+0x1040/0x1170 lib/vsprintf.c:1281 pointer+0x9fe/0x1ca0 lib/vsprintf.c:2241 vsnprintf+0x1a4f/0x3610 lib/vsprintf.c:2622 vscnprintf+0xbe/0x1c0 lib/vsprintf.c:2721 vprintk_store+0xff/0x14a0 kernel/printk/printk.c:1954 vprintk_emit+0x2ae/0x820 kernel/printk/printk.c:2018 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2052 vprintk_func+0x2ed/0x2f0 kernel/printk/printk_safe.c:393 printk+0x180/0x1cd kernel/printk/printk.c:2083 dvb_usb_adapter_dvb_init+0x818/0x1300 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:166 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:83 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:173 [inline] dvb_usb_device_init+0x27fd/0x3350 drivers/media/usb/dvb-usb/dvb-usb-init.c:287 nova_t_probe+0x73/0x80 drivers/media/usb/dvb-usb/nova-t-usb2.c:156 usb_probe_interface+0xfcc/0x1520 drivers/usb/core/driver.c:396 really_probe+0xebd/0x2420 drivers/base/dd.c:558 driver_probe_device+0x293/0x390 drivers/base/dd.c:738 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:844 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x538/0x860 drivers/base/dd.c:912 device_initial_probe+0x4a/0x60 drivers/base/dd.c:959 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x399e/0x3f20 drivers/base/core.c:2936 usb_set_configuration+0x39cf/0x4010 drivers/usb/core/message.c:2159 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x317/0x570 drivers/usb/core/driver.c:293 really_probe+0xebd/0x2420 drivers/base/dd.c:558 driver_probe_device+0x293/0x390 drivers/base/dd.c:738 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:844 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x538/0x860 drivers/base/dd.c:912 device_initial_probe+0x4a/0x60 drivers/base/dd.c:959 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x399e/0x3f20 drivers/base/core.c:2936 usb_new_device+0x1bd6/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5222 [inline] hub_port_connect_change drivers/usb/core/hub.c:5362 [inline] port_event drivers/usb/core/hub.c:5508 [inline] hub_event+0x5bc9/0x8890 drivers/usb/core/hub.c:5590 process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 kthread+0x51c/0x560 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 nova_t_read_mac_address+0x2d4/0x2f0 drivers/media/usb/dvb-usb/nova-t-usb2.c:144 dvb_usb_adapter_dvb_init+0x774/0x1300 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:165 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:83 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:173 [inline] dvb_usb_device_init+0x27fd/0x3350 drivers/media/usb/dvb-usb/dvb-usb-init.c:287 nova_t_probe+0x73/0x80 drivers/media/usb/dvb-usb/nova-t-usb2.c:156 usb_probe_interface+0xfcc/0x1520 drivers/usb/core/driver.c:396 really_probe+0xebd/0x2420 drivers/base/dd.c:558 driver_probe_device+0x293/0x390 drivers/base/dd.c:738 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:844 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x538/0x860 drivers/base/dd.c:912 device_initial_probe+0x4a/0x60 drivers/base/dd.c:959 bus_probe_device+0x177/0x3d0
[PATCH] tick/nohz: Make the idle_exittime update correctly
The idle_exittime field of tick_sched is used to record the time when
the idle state was left. but currently the idle_exittime is updated in
the function tick_nohz_restart_sched_tick(), which is not always in idle
state when nohz_full is configured.
tick_irq_exit
tick_nohz_irq_exit
tick_nohz_full_update_tick
tick_nohz_restart_sched_tick
ts->idle_exittime = now;
So move to tick_nohz_stop_idle() to make the idle_exittime update
correctly.
Signed-off-by: Yunfeng Ye
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 749ec2a583de..be2e5d772d50 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -591,6 +591,7 @@ static void tick_nohz_stop_idle(struct tick_sched *ts,
ktime_t now)
{
update_ts_time_stats(smp_processor_id(), ts, now, NULL);
ts->idle_active = 0;
+ ts->idle_exittime = now;
sched_clock_idle_wakeup_event();
}
@@ -901,7 +902,6 @@ static void tick_nohz_restart_sched_tick(struct tick_sched
*ts, ktime_t now)
* Cancel the scheduled timer and restore the tick
*/
ts->tick_stopped = 0;
- ts->idle_exittime = now;
tick_nohz_restart(ts, now);
}
--
2.18.4
Re: [PATCH 1/2] pcmcia: at91_cf: move definitions locally
Am Tue, Nov 24, 2020 at 12:07:30PM +0100 schrieb Alexandre Belloni: > On Wed, 30 Sep 2020 20:48:02 +0200, Alexandre Belloni wrote: > > struct at91_cf_data is only used in the driver since all the platforms moved > > to device tree, move its definition locally. > > I've now applied those patches on the at91-drivers branch, please shout if you > want them to go through your branch. > > [1/2] pcmcia: at91_cf: move definitions locally > commit: 496e9b64d7297d3e6c209c51218cee2939694b25 > [2/2] pcmcia: at91_cf: remove platform data support > commit: 91be3e89f450aa738204f6629f06d8b0e3d8d77b Thanks, I'm fine with that. Dominik
Re: [PATCH] drivers/pcmcia: Fix error return code in electra_cf_probe()
Am Tue, Nov 24, 2020 at 03:00:40PM +0800 schrieb Wei Li:
> When it fails to call of_get_property(), it just jumps to 'fail1',
> while the 'status' which will be returned is not updated.
>
> Fixes: 2b571a066a2f ("pcmcia: CompactFlash driver for PA Semi Electra boards")
> Signed-off-by: Wei Li
Thnaks for the patch. However, this issue is already fixed by
commit f15480e947d4 ("pcmcia/electra_cf: Fix some return values in
'electra_cf_probe()'
in case of error")
in pcmcia-next.
Thanks,
Dominik
Re: [PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
Le 05/12/2020 à 09:48, Christoph Hellwig a écrit :
On Sat, Dec 05, 2020 at 08:43:06AM +, Christophe Leroy wrote:
Since commit c33165253492 ("powerpc: use non-set_fs based maccess
routines"), userspace access is not granted anymore when using
copy_from_kernel_nofault()
However, kthread_probe_data() uses copy_from_kernel_nofault()
to check validity of pointers. When the pointer is NULL,
it points to userspace, leading to a KUAP fault and triggering
the following big hammer warning many times when you request
a sysrq "show task":
To avoid that, copy_from_kernel_nofault_allowed() is used to check
whether the address is a valid kernel address. But the default
version of it returns true for any address.
Provide a powerpc version of copy_from_kernel_nofault_allowed()
that returns false when the address is below TASK_USER_MAX,
so that copy_from_kernel_nofault() will return -ERANGE.
Looks good. I wonder if we should just default to the TASK_SIZE_MAX
check in copy_from_kernel_nofault_allowed for architectures that select
CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE?
Yes maybe that would be better.
Can you cook a patch an get it into 5.10 ?
Christophe
Reported-by: Qian Cai
Fixes: c33165253492 ("powerpc: use non-set_fs based maccess routines")
Cc: Christoph Hellwig
Cc: Al Viro
Signed-off-by: Christophe Leroy
---
This issue was introduced in 5.10. I didn't mark it for stable, hopping it will
go into 5.10-rc7
---
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/maccess.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/mm/maccess.c
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 5e147986400d..55b4a8bd408a 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -5,7 +5,7 @@
ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
-obj-y:= fault.o mem.o pgtable.o mmap.o \
+obj-y := fault.o mem.o pgtable.o mmap.o maccess.o \
init_$(BITS).o pgtable_$(BITS).o \
pgtable-frag.o ioremap.o ioremap_$(BITS).o \
init-common.o mmu_context.o drmem.o
diff --git a/arch/powerpc/mm/maccess.c b/arch/powerpc/mm/maccess.c
new file mode 100644
index ..56e97c0fb233
--- /dev/null
+++ b/arch/powerpc/mm/maccess.c
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+
+bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
+{
+ return (unsigned long)unsafe_src >= TASK_SIZE_MAX;
+}
--
2.25.0
---end quoted text---
Re: linux-next: build warning after merge of the akpm tree
Hi Andrew, On Fri, 4 Dec 2020 21:19:23 -0800 Andrew Morton wrote: > > Odd. clang wants that signature, according to > https://clang.llvm.org/docs/SanitizerCoverage.html. But gcc seems to > want a different signature. Beats me - best I can do is to cc various > likely culprits ;) > > Which gcc version? Did you recently update gcc? gcc (Debian 10.2.0-15) 10.2.0 Not recently upgraded. -- Cheers, Stephen Rothwell pgpClXrQuZRe_.pgp Description: OpenPGP digital signature
Re: recursion handling: Re: [PATCH next v2 3/3] printk: remove logbuf_lock, add syslog_lock
On (20/12/04 17:10), Petr Mladek wrote:
>
> One reason is the use of per-cpu variables. Alternative solution would
> be to store printk_context into task_struct.
We can keep per-CPU, disable preemption and have counters for
every context (task, soft/hard irq, NMI). Shouldn't be a problem
vprintk_emit()
{
preempt_disable()
vprintk_store()
preempt_enable()
preempt_disable()
console_unlock()
preempt_enable()
}
vprintk_store() is a small fraction of console_unlock() time wise.
-ss
Re: [PATCH v2] clk: renesas: r9a06g032: Drop __packed for portability
Hi Stephen,
On Sat, Dec 5, 2020 at 7:24 AM Stephen Boyd wrote:
> Quoting Geert Uytterhoeven (2020-11-30 00:57:43)
> > The R9A06G032 clock driver uses an array of packed structures to reduce
> > kernel size. However, this array contains pointers, which are no longer
> > aligned naturally, and cannot be relocated on PPC64. Hence when
> > compile-testing this driver on PPC64 with CONFIG_RELOCATABLE=y (e.g.
> > PowerPC allyesconfig), the following warnings are produced:
> >
> > WARNING: 136 bad relocations
> > c0616be3 R_PPC64_UADDR64 .rodata+0x000cf338
> > c0616bfe R_PPC64_UADDR64 .rodata+0x000cf370
> > ...
> >
> > Fix this by dropping the __packed attribute from the r9a06g032_clkdesc
> > definition, trading a small size increase for portability.
> >
> > This increases the 156-entry clock table by 1 byte per entry, but due to
> > the compiler generating more efficient code for unpacked accesses, the
> > net size increase is only 76 bytes (gcc 9.3.0 on arm32).
> >
> > Reported-by: Stephen Rothwell
> > Fixes: 4c3d88526eba2143 ("clk: renesas: Renesas R9A06G032 clock driver")
> > Signed-off-by: Geert Uytterhoeven
> > ---
>
> Acked-by: Stephen Boyd
>
> Unless you want me to pick this up for clk-fixes?
Yes please. Forgot to retain this comment for v2:
"Please take directly (ppc or clk), as this is a build fix.
https://lore.kernel.org/linux-clk/20201128122819.32187...@canb.auug.org.au/;
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH] pcmcia: omap: Fix error return code in omap_cf_probe()
Am Wed, Nov 25, 2020 at 08:50:57PM +0800 schrieb Wang ShaoBo: > Fix to return proper error code instaed of 0 in omap_cf_probe(), as done > elsewhere in this function. > > Signed-off-by: Wang ShaoBo Applied to pcmcia-next. Thanks, Dominik
[PATCH] phy: mediatek: statify mtk_hdmi_phy_driver
mtk_hdmi_phy_driver is not declared as static, so statify it.
drivers/phy/mediatek/phy-mtk-hdmi.c:204:24: warning: symbol
'mtk_hdmi_phy_driver' was not declared. Should it be static?
Signed-off-by: Vinod Koul
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index 47c029d4b270..c5c61f5a9ea0 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -201,7 +201,7 @@ static const struct of_device_id mtk_hdmi_phy_match[] = {
{},
};
-struct platform_driver mtk_hdmi_phy_driver = {
+static struct platform_driver mtk_hdmi_phy_driver = {
.probe = mtk_hdmi_phy_probe,
.driver = {
.name = "mediatek-hdmi-phy",
--
2.26.2
Re: [PATCH] pcmcia: Remove NEC VRC4173 CARDU
Am Wed, Sep 16, 2020 at 10:16:29AM +0200 schrieb Sebastian Andrzej Siewior:
> This driver is the very definition of bitrotting:
> - Introduced in commit
> 79a140932c776 ("[PATCH] mips: vR41xx updates")
> which is 2.6.11-rc3.
>
> - Provides ->register_callback which was removed in commit
> 7f316b033b36a ("[PATCH] pcmcia: remove socket register_callback")
> which is v2.6.14-rc3
>
> - Uses INIT_WORK() with three arguments which was removed in commit
> 65f27f38446e1 ("WorkStruct: Pass the work_struct pointer instead of context
> data")
> which is v2.6.20-rc1
>
> - Provides ->inquire_socket and uses socket_cap_t which was removed in
> commit
> b7949fdacbe00 ("[PCMCIA] Remove inquire_socket")
> which is 2.5.72
>
> - Provides ->get_io_map which was removed in commit
> d7de1b64a23b9 ("[PCMCIA] pcmcia-2: Remove get_io_map and get_mem_map socket
> methods.")
> which is 2.5.66
>
> Remove VRC4173 CARDU from the tree because it never had the luck to be
> successfully compiled. Let it finally find peace in byte heaven.
>
> Cc: Reported-by: kernel test robot
> Signed-off-by: Sebastian Andrzej Siewior
Applied to pcmcia-next.
Thanks,
Dominik
mips-linux-ld: decompress.c:(.text.decompress_kernel+0x21c): undefined reference to `__ubsan_handle_out_of_bounds'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b3298500b23f0b53a8d81e0d5ad98a29db71f4f0 commit: 8d58f222e85f01da0c0e1fc1e77986c86de889e2 ubsan: disable UBSAN_ALIGNMENT under COMPILE_TEST date: 7 months ago config: mips-randconfig-r033-20201205 (attached as .config) compiler: mips-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d58f222e85f01da0c0e1fc1e77986c86de889e2 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 8d58f222e85f01da0c0e1fc1e77986c86de889e2 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): mips-linux-ld: arch/mips/boot/compressed/decompress.o: in function `get_bits': decompress.c:(.text.get_bits+0xc4): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_bits+0x100): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_bits+0x184): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_bits+0x1a0): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-linux-ld: arch/mips/boot/compressed/decompress.o: in function `get_next_block': decompress.c:(.text.get_next_block+0x31c): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x344): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x448): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x46c): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x490): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x4b0): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x4cc): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x4f4): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x510): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x538): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x604): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x628): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x658): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x678): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x6a0): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x764): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x788): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x7a8): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x7e8): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x828): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x8b4): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x8f0): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x930): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x95c): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0x980): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0x9e0): undefined reference to `__ubsan_handle_out_of_bounds' mips-linux-ld: decompress.c:(.text.get_next_block+0xa14): undefined reference to `__ubsan_handle_type_mismatch_v1' mips-linux-ld: decompress.c:(.text.get_next_block+0xbf8): undefined ref
[rcu:rcu/next] BUILD SUCCESS 2c05cc5920504514a39df422145c68306f030a60
randconfig-a004-20201204 x86_64 randconfig-a006-20201204 x86_64 randconfig-a002-20201204 x86_64 randconfig-a001-20201204 x86_64 randconfig-a005-20201204 x86_64 randconfig-a003-20201204 i386 randconfig-a005-20201204 i386 randconfig-a004-20201204 i386 randconfig-a001-20201204 i386 randconfig-a002-20201204 i386 randconfig-a006-20201204 i386 randconfig-a003-20201204 i386 randconfig-a005-20201205 i386 randconfig-a004-20201205 i386 randconfig-a001-20201205 i386 randconfig-a002-20201205 i386 randconfig-a006-20201205 i386 randconfig-a003-20201205 i386 randconfig-a014-20201204 i386 randconfig-a013-20201204 i386 randconfig-a011-20201204 i386 randconfig-a015-20201204 i386 randconfig-a012-20201204 i386 randconfig-a016-20201204 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a012-20201204 x86_64 randconfig-a014-20201204 x86_64 randconfig-a013-20201204 x86_64 randconfig-a015-20201204 x86_64 randconfig-a011-20201204 x86_64 randconfig-a016-20201204 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [resend/standalone PATCH v4] Add auxiliary bus support
On Fri, Dec 04, 2020 at 09:10:34AM -0800, Ranjani Sridharan wrote: > On Fri, 2020-12-04 at 13:59 +0100, Greg KH wrote: > > On Fri, Dec 04, 2020 at 02:32:07PM +0200, Leon Romanovsky wrote: > > > On Fri, Dec 04, 2020 at 12:42:46PM +0100, Greg KH wrote: > > > > On Wed, Dec 02, 2020 at 04:54:24PM -0800, Dan Williams wrote: > > > > > From: Dave Ertman > > > > > > > > > > Add support for the Auxiliary Bus, auxiliary_device and > > > > > auxiliary_driver. > > > > > It enables drivers to create an auxiliary_device and bind an > > > > > auxiliary_driver to it. > > > > > > > > > > The bus supports probe/remove shutdown and suspend/resume > > > > > callbacks. > > > > > Each auxiliary_device has a unique string based id; driver > > > > > binds to > > > > > an auxiliary_device based on this id through the bus. > > > > > > > > > > Co-developed-by: Kiran Patil > > > > > Co-developed-by: Ranjani Sridharan < > > > > > ranjani.sridha...@linux.intel.com> > > > > > Co-developed-by: Fred Oh > > > > > Co-developed-by: Leon Romanovsky > > > > > Signed-off-by: Kiran Patil > > > > > Signed-off-by: Ranjani Sridharan < > > > > > ranjani.sridha...@linux.intel.com> > > > > > Signed-off-by: Fred Oh > > > > > Signed-off-by: Leon Romanovsky > > > > > Signed-off-by: Dave Ertman > > > > > Reviewed-by: Pierre-Louis Bossart < > > > > > pierre-louis.boss...@linux.intel.com> > > > > > Reviewed-by: Shiraz Saleem > > > > > Reviewed-by: Parav Pandit > > > > > Reviewed-by: Dan Williams > > > > > Reviewed-by: Martin Habets > > > > > Link: > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > Signed-off-by: Dan Williams > > > > > --- > > > > > This patch is "To:" the maintainers that have a pending backlog > > > > > of > > > > > driver updates dependent on this facility, and "Cc:" Greg. > > > > > Greg, I > > > > > understand you have asked for more time to fully review this > > > > > and apply > > > > > it to driver-core.git, likely for v5.12, but please consider > > > > > Acking it > > > > > for v5.11 instead. It looks good to me and several other > > > > > stakeholders. > > > > > Namely, stakeholders that have pressure building up behind this > > > > > facility > > > > > in particular Mellanox RDMA, but also SOF, Intel Ethernet, and > > > > > later on > > > > > Compute Express Link. > > > > > > > > > > I will take the blame for the 2 months of silence that made > > > > > this awkward > > > > > to take through driver-core.git, but at the same time I do not > > > > > want to > > > > > see that communication mistake inconvenience other parties that > > > > > reasonably thought this was shaping up to land in v5.11. > > > > > > > > > > I am willing to host this version at: > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux > > > > > tags/auxiliary-bus-for-5.11 > > > > > > > > > > ...for all the independent drivers to have a common commit > > > > > baseline. It > > > > > is not there yet pending Greg's Ack. > > > > > > > > > > For example implementations incorporating this patch, see Dave > > > > > Ertman's > > > > > SOF series: > > > > > > > > > > https://lore.kernel.org/r/20201113161859.1775473-2-david.m.ert...@intel.com > > > > > > > > > > ...and Leon's mlx5 series: > > > > > > > > > > http://lore.kernel.org/r/20201026111849.1035786-1-l...@kernel.org > > > > > > > > > > PS: Greg I know I promised some review on newcomer patches to > > > > > help with > > > > > your queue, unfortunately Intel-internal review is keeping my > > > > > plate > > > > > full. Again, I do not want other stakeholder to be waiting on > > > > > me to > > > > > resolve that backlog. > > > > > > > > Ok, I spent some hours today playing around with this. I wrote > > > > up a > > > > small test-patch for this (how did anyone test this thing???). > > > > > > We are running all verifications tests that we have over our > > > mlx5 driver. It includes devices reloads, power failures, FW > > > reconfiguration to emulate different devices with and without error > > > injections and many more. Up till now, no new bugs that are not > > > known > > > to us were found. > > > > Yes, sorry, I was implying that the authors here had to create _some_ > > code to test this with, it would have been nice to include that as > > well > > here. We are collecting more and more in-kernel tests, having one > > for > > this code would be nice to also have so we make sure not to break any > > functionality in the future. > > Hi Greg, > > Thanks for your patience with this series. The v4 version submitted by > Dave included the SOF usage code to demonstrate the usage. We have run > all tests for device registration, module reload, PM etc and have not > observed any regressions in the SOF audio driver. Yes, that works great if you have that specific hardware to test with. If you don't, then it's kind of impossible to test this code :( thanks, greg k-h
Re: [PATCH v1] HID: make arrays usage and value to be the same
On Sat, Dec 05, 2020 at 12:48:48AM +, Will McVicker wrote: > The HID subsystem allows an "HID report field" to have a different > number of "values" and "usages" when it is allocated. When a field > struct is created, the size of the usage array is guaranteed to be at > least as large as the values array, but it may be larger. This leads to > a potential out-of-bounds write in > __hidinput_change_resolution_multipliers() and an out-of-bounds read in > hidinput_count_leds(). > > To fix this, let's make sure that both the usage and value arrays are > the same size. > > Signed-off-by: Will McVicker Any reason not to also add a cc: stable on this? And, has this always been the case, or was this caused by some specific commit in the past? If so, a "Fixes:" tag is always nice to included. And finally, as you have a fix for this already, no need to cc: security@k.o as there's nothing the people there can do about it now :) thanks, greg k-h
Re: [PATCH v3] PM: domains: create debugfs nodes when adding power domains
On Fri, Dec 04, 2020 at 04:57:16PM -0800, Thierry Strudel wrote: > debugfs nodes were created in genpd_debug_init alled in late_initcall > preventing power domains registered though loadable modules to have > a debugfs entry. > > Create/remove debugfs nodes when the power domain is added/removed > to/from the internal gpd_list. > > Signed-off-by: Thierry Strudel > --- > v2: fix forward declaration and genpd_debugfs_dir being NULL - Ulf > v3: remove extra trailing char added by mistake in v2 - kernel test robot > drivers/base/power/domain.c | 83 - > 1 file changed, 55 insertions(+), 28 deletions(-) > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > index 743268996336..3e40ef5cd9ab 100644 > --- a/drivers/base/power/domain.c > +++ b/drivers/base/power/domain.c > @@ -24,6 +24,16 @@ > > #include "power.h" > > +#ifdef CONFIG_DEBUG_FS > +#include > +#include > +#include > +#include > +#include > +#include Why do you need all of these files included for debugfs stuff? And why put it in a #ifdef at all? Include files are not normally gated that way. > +static struct dentry *genpd_debugfs_dir; That's the variable you want to only have declared or not, just #ifdef for this :) thanks, greg k-h
Re: [PATCH v3] bridge: Fix a deadlock when enabling multicast snooping
On 05/12/2020 01:56, Joseph Huang wrote:
> When enabling multicast snooping, bridge module deadlocks on multicast_lock
> if 1) IPv6 is enabled, and 2) there is an existing querier on the same L2
> network.
>
> The deadlock was caused by the following sequence: While holding the lock,
> br_multicast_open calls br_multicast_join_snoopers, which eventually causes
> IP stack to (attempt to) send out a Listener Report (in igmp6_join_group).
> Since the destination Ethernet address is a multicast address, br_dev_xmit
> feeds the packet back to the bridge via br_multicast_rcv, which in turn
> calls br_multicast_add_group, which then deadlocks on multicast_lock.
>
> The fix is to move the call br_multicast_join_snoopers outside of the
> critical section. This works since br_multicast_join_snoopers only deals
> with IP and does not modify any multicast data structures of the bridge,
> so there's no need to hold the lock.
>
> Steps to reproduce:
> 1. sysctl net.ipv6.conf.all.force_mld_version=1
> 2. have another querier
> 3. ip link set dev bridge type bridge mcast_snooping 0 && \
>ip link set dev bridge type bridge mcast_snooping 1 < deadlock >
>
> A typical call trace looks like the following:
>
> [ 936.251495] _raw_spin_lock+0x5c/0x68
> [ 936.255221] br_multicast_add_group+0x40/0x170 [bridge]
> [ 936.260491] br_multicast_rcv+0x7ac/0xe30 [bridge]
> [ 936.265322] br_dev_xmit+0x140/0x368 [bridge]
> [ 936.269689] dev_hard_start_xmit+0x94/0x158
> [ 936.273876] __dev_queue_xmit+0x5ac/0x7f8
> [ 936.277890] dev_queue_xmit+0x10/0x18
> [ 936.281563] neigh_resolve_output+0xec/0x198
> [ 936.285845] ip6_finish_output2+0x240/0x710
> [ 936.290039] __ip6_finish_output+0x130/0x170
> [ 936.294318] ip6_output+0x6c/0x1c8
> [ 936.297731] NF_HOOK.constprop.0+0xd8/0xe8
> [ 936.301834] igmp6_send+0x358/0x558
> [ 936.305326] igmp6_join_group.part.0+0x30/0xf0
> [ 936.309774] igmp6_group_added+0xfc/0x110
> [ 936.313787] __ipv6_dev_mc_inc+0x1a4/0x290
> [ 936.317885] ipv6_dev_mc_inc+0x10/0x18
> [ 936.321677] br_multicast_open+0xbc/0x110 [bridge]
> [ 936.326506] br_multicast_toggle+0xec/0x140 [bridge]
>
> Fixes: 4effd28c1245 ("bridge: join all-snoopers multicast address")
> Signed-off-by: Joseph Huang
> ---
> net/bridge/br_device.c| 6 ++
> net/bridge/br_multicast.c | 34 +-
> net/bridge/br_private.h | 10 ++
> 3 files changed, 41 insertions(+), 9 deletions(-)
>
LGTM, thanks!
Acked-by: Nikolay Aleksandrov
Re: [PATCHv2] clocksource: dw_apb_timer_of: add error handling if no clock available
On 04/12/2020 23:39, Dinh Nguyen wrote:
>
>
> On 12/4/20 2:00 PM, Daniel Lezcano wrote:
>> On 04/12/2020 16:36, Dinh Nguyen wrote:
>>> commit ("b0fc70ce1f02 arm64: berlin: Select DW_APB_TIMER_OF") added the
>>> support for the dw_apb_timer into the arm64 defconfig. However, for some
>>> platforms like the Intel Stratix10 and Agilex, the clock manager doesn't
>>> get loaded until after the timer driver get loaded. Thus, the driver
>>> hits
>>> the panic "No clock nor clock-frequency property for" because it cannot
>>> properly get the clock.
>>>
>>> This patch adds the error handling needed for the timer driver so that
>>> the kernel can continue booting instead of just hitting the panic.
>>>
>>> Signed-off-by: Dinh Nguyen
>>
>> Did you have time to test the different combinations ?
>
> I did test both versions and did not see any difference between the two.
> On both versions, the kernel was able to continue to boot after trying
> to probe the timer driver.
Great, thanks!
--
Facebook |
Twitter |
Re: [PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
On Sat, Dec 05, 2020 at 08:43:06AM +, Christophe Leroy wrote:
> Since commit c33165253492 ("powerpc: use non-set_fs based maccess
> routines"), userspace access is not granted anymore when using
> copy_from_kernel_nofault()
>
> However, kthread_probe_data() uses copy_from_kernel_nofault()
> to check validity of pointers. When the pointer is NULL,
> it points to userspace, leading to a KUAP fault and triggering
> the following big hammer warning many times when you request
> a sysrq "show task":
> To avoid that, copy_from_kernel_nofault_allowed() is used to check
> whether the address is a valid kernel address. But the default
> version of it returns true for any address.
>
> Provide a powerpc version of copy_from_kernel_nofault_allowed()
> that returns false when the address is below TASK_USER_MAX,
> so that copy_from_kernel_nofault() will return -ERANGE.
Looks good. I wonder if we should just default to the TASK_SIZE_MAX
check in copy_from_kernel_nofault_allowed for architectures that select
CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE?
>
> Reported-by: Qian Cai
> Fixes: c33165253492 ("powerpc: use non-set_fs based maccess routines")
> Cc: Christoph Hellwig
> Cc: Al Viro
> Signed-off-by: Christophe Leroy
> ---
> This issue was introduced in 5.10. I didn't mark it for stable, hopping it
> will go into 5.10-rc7
> ---
> arch/powerpc/mm/Makefile | 2 +-
> arch/powerpc/mm/maccess.c | 9 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/mm/maccess.c
>
> diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
> index 5e147986400d..55b4a8bd408a 100644
> --- a/arch/powerpc/mm/Makefile
> +++ b/arch/powerpc/mm/Makefile
> @@ -5,7 +5,7 @@
>
> ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC)
>
> -obj-y:= fault.o mem.o pgtable.o mmap.o \
> +obj-y:= fault.o mem.o pgtable.o mmap.o
> maccess.o \
> init_$(BITS).o pgtable_$(BITS).o \
> pgtable-frag.o ioremap.o ioremap_$(BITS).o \
> init-common.o mmu_context.o drmem.o
> diff --git a/arch/powerpc/mm/maccess.c b/arch/powerpc/mm/maccess.c
> new file mode 100644
> index ..56e97c0fb233
> --- /dev/null
> +++ b/arch/powerpc/mm/maccess.c
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include
> +#include
> +
> +bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
> +{
> + return (unsigned long)unsafe_src >= TASK_SIZE_MAX;
> +}
> --
> 2.25.0
---end quoted text---
[PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
Since commit c33165253492 ("powerpc: use non-set_fs based maccess
routines"), userspace access is not granted anymore when using
copy_from_kernel_nofault()
However, kthread_probe_data() uses copy_from_kernel_nofault()
to check validity of pointers. When the pointer is NULL,
it points to userspace, leading to a KUAP fault and triggering
the following big hammer warning many times when you request
a sysrq "show task":
[ 1117.202054] [ cut here ]
[ 1117.202102] Bug: fault blocked by AP register !
[ 1117.202261] WARNING: CPU: 0 PID: 377 at
arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
[ 1117.202310] Modules linked in:
[ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: GW
5.10.0-rc5-01340-g83f53be2de31-dirty #4175
[ 1117.202499] NIP: c0012048 LR: c0012048 CTR:
[ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: GW
(5.10.0-rc5-01340-g83f53be2de31-dirty)
[ 1117.202625] MSR: 00021032 CR: 2408 XER: 2000
[ 1117.202899]
[ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 0023 c092e554 0001
c09865e8 c092e640
[ 1117.202899] GPR08: 1032 00014efc 28082224 100d166a
100a0920
[ 1117.202899] GPR16: 100cac0c 100b 1080c3fc 1080d685 100d 100d
100a0900
[ 1117.202899] GPR24: 100d c07892ec c0921510 c21f4440 005c
c000 cacdbc80
[ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
[ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
[ 1117.204509] Call Trace:
[ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
[ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
[ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
[ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 0001
[ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: GW
(5.10.0-rc5-01340-g83f53be2de31-dirty)
[ 1117.205104] MSR: 9032 CR: 28082224 XER:
[ 1117.205416] DAR: 005c DSISR: c000
[ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 0001 0017 0017
0027 000f
[ 1117.205416] GPR08: c09926ec 3000 24082224
[ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
[ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
[ 1117.206258] --- interrupt: 301
[ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
[ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
[ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
[ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
[ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
[ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
[ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
[ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
[ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
[ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
[ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
[ 1117.207938] --- interrupt: c01 at 0xfd4e784
[ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
[ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: GW
(5.10.0-rc5-01340-g83f53be2de31-dirty)
[ 1117.208134] MSR: d032 CR: 4400 XER:
[ 1117.208470]
[ 1117.208470] GPR00: 0004 7fc34090 77bfb4e0 0001 1080fa40 0002
740f fefefeff
[ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0
[ 1117.209104] NIP [0fd4e784] 0xfd4e784
[ 1117.209180] LR [0fe0f244] 0xfe0f244
[ 1117.209236] --- interrupt: c01
[ 1117.209274] Instruction dump:
[ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040
4082ff60
[ 1117.209727] 0fe0 3c60c082 386399f4 48013b65 <0fe0> 80010034 386b
7c0803a6
[ 1117.210102] ---[ end trace 1927c0323393af3e ]---
To avoid that, copy_from_kernel_nofault_allowed() is used to check
whether the address is a valid kernel address. But the default
version of it returns true for any address.
Provide a powerpc version of copy_from_kernel_nofault_allowed()
that returns false when the address is below TASK_USER_MAX,
so that copy_from_kernel_nofault() will return -ERANGE.
Reported-by: Qian Cai
Fixes: c33165253492 ("powerpc: use non-set_fs based maccess routines")
Cc: Christoph Hellwig
Cc: Al Viro
Signed-off-by: Christophe Leroy
---
This issue was introduced in 5.10. I didn't mark it for stable, hopping it will
go into 5.10-rc7
---
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/maccess.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/mm/maccess.c
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 5e147986400d..55b4a8bd408a 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -5,7 +5,7 @@
ccflags-$(CONFIG_PPC64):= $(NO_MINIMAL_TOC)
-obj-y := fault.o
Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
On Fri, Dec 04, 2020 at 07:35:17PM -0800, mark gross wrote: > On Wed, Dec 02, 2020 at 08:01:18PM +0100, Greg KH wrote: > > On Wed, Dec 02, 2020 at 09:42:00AM -0800, mark gross wrote: > > > On Wed, Dec 02, 2020 at 07:16:20AM +0100, Greg KH wrote: > > > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote: > > > > > --- a/MAINTAINERS > > > > > +++ b/MAINTAINERS > > > > > @@ -8955,6 +8955,14 @@ M: Deepak Saxena > > > > > S: Maintained > > > > > F: drivers/char/hw_random/ixp4xx-rng.c > > > > > > > > > > +INTEL KEEM BAY IPC DRIVER > > > > > +M: Daniele Alessandrelli > > > > > +M: Mark Gross > > > > > +S: Maintained > > > > > +F: > > > > > Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml > > > > > +F: drivers/soc/intel/keembay-ipc.c > > > > > +F: include/linux/soc/intel/keembay-ipc.h > > > > > > > > Sad that Intel is not going to actually pay you all to do this > > > > maintenance work for a brand new subsystem you are wanting to add to the > > > > tree :( > > > I thought adding my name to these maintainer items would help with > > > continuity > > > as the individual engineers tend to move on to other things over time. > > > > > > While I'm paid for a number of things at intel this is one of them. My > > > role is > > > as stable as I choose it to be at the point I'm at in my Intel career and > > > the > > > business unit I'm now part of. We can leave my name off if that would be > > > better. > > > > > > Even if I'm not a VPU IP domain expert like Daniele is I can still chase > > > down > > > the experts as needed after Daniele grows into other things over time. > > > > I'm not objecting to your, or anyone else's name on this at all. I'm > > just asking about Intel's support for this new codebase being added. > > Having a new subsystem from a major company and not have someone paid to > > actually maintain it seems really odd to me. > > > > That's all. If that's Intel's stance, that's fine, just wanted to > > clarify it is correct as I know some people at Intel have been confused > > recently about just what the S: field means. > I've been following up on whether the status field should be "Supported" or > "Maintained" at this time. For this current instantiation of the VPU enabling > under review here I think Maintained most appropriate. There are a good > number > of people who look after it. > > However; I have learned that the instantiations of the VPU after keem bay and > its follow on SoC will include an evolution of this stack and between now and > when those get close to landing that evolved version will become "Supported". > > Given this, would it be more appropriate to put this stack into staging for a > while? drivers/staging/ is for code that for some reason is not good enough to be merged to the "right" place in the kernel tree, and you need community help to get it cleaned up because you can not do it yourself. Is that the case here? If not, then no, it should not go into drivers/staging/. thanks, greg k-h
[PATCH] iommu: Up front sanity check in the arm_lpae_map
... then we have more chance to detect wrong code logic. Signed-off-by: Keqian Zhu --- drivers/iommu/io-pgtable-arm.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index a7a9bc08dcd1..8ade72adab31 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -444,10 +444,6 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova, arm_lpae_iopte prot; long iaext = (s64)iova >> cfg->ias; - /* If no access, then nothing to do */ - if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE))) - return 0; - if (WARN_ON(!size || (size & cfg->pgsize_bitmap) != size)) return -EINVAL; @@ -456,6 +452,10 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova, if (WARN_ON(iaext || paddr >> cfg->oas)) return -ERANGE; + /* If no access, then nothing to do */ + if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE))) + return 0; + prot = arm_lpae_prot_to_pte(data, iommu_prot); ret = __arm_lpae_map(data, iova, paddr, size, prot, lvl, ptep, gfp); /* -- 2.23.0
Re: [PATCH v3 3/6] mm: support THP migration to device private memory
On Wed, Dec 02, 2020 at 11:08:54AM +0100, Christoph Hellwig wrote: > On Fri, Nov 20, 2020 at 04:01:33PM -0400, Jason Gunthorpe wrote: > > On Wed, Nov 11, 2020 at 03:38:42PM -0800, Ralph Campbell wrote: > > > > > MEMORY_DEVICE_GENERIC: > > > Struct pages are created in dev_dax_probe() and represent non-volatile > > > memory. > > > The device can be mmap()'ed which calls dax_mmap() which sets > > > vma->vm_flags | VM_HUGEPAGE. > > > A CPU page fault will result in a PTE, PMD, or PUD sized page > > > (but not compound) to be inserted by vmf_insert_mixed() which will call > > > either > > > insert_pfn() or insert_page(). > > > Neither insert_pfn() nor insert_page() increments the page reference > > > count. > > > > But why was this done? It seems very strange to put a pfn with a > > struct page into a VMA and then deliberately not take the refcount for > > the duration of that pfn being in the VMA? > > > > What prevents memunmap_pages() from progressing while VMAs still point > > at the memory? > > Agreed. Adding Roger who added MEMORY_DEVICE_GENERIC and the only > user. MEMORY_DEVICE_GENERIC is just a rename of the previous MEMORY_DEVICE_DEVDAX, and seems to be used by the DAX device apart from Xen? It's main purpose is to be able to allocate unused physical memory ranges and have a baking struct page for them, so they can be used to map foreign memory when running on Xen. I'm currently on leave and won't be back until the end of the month, could you please Cc the Xen maintainers if you modify the logic here in order to make sure it will work for Xen? Thanks, Roger.
Re: [PATCH 0/2] phy: rockchip: set otapdlysec for in dts
On 02-12-20, 16:25, Chris Ruehl wrote: > This patchset add support to set output-tapdelay-selec via dt property Applied, thanks -- ~Vinod
[rcu:dev.2020.12.03a] BUILD SUCCESS 8c884f433ec3fb5b009bd14be9cd2a16e960cd40
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.12.03a branch HEAD: 8c884f433ec3fb5b009bd14be9cd2a16e960cd40 squash! percpu_ref: Add kmem_cache_last_alloc() argument for stack trace elapsed time: 721m configs tested: 132 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig nios2alldefconfig arcvdk_hs38_defconfig powerpc cm5200_defconfig arm tango4_defconfig mips decstation_r4k_defconfig powerpc tqm8555_defconfig s390defconfig sh se7721_defconfig m68k amiga_defconfig sh r7785rp_defconfig sh microdev_defconfig m68k m5275evb_defconfig armshmobile_defconfig um x86_64_defconfig ia64 tiger_defconfig arm mv78xx0_defconfig ia64zx1_defconfig powerpc ep88xc_defconfig arm bcm2835_defconfig powerpc acadia_defconfig arm assabet_defconfig powerpc skiroot_defconfig powerpc motionpro_defconfig nds32 defconfig mips jazz_defconfig powerpccell_defconfig ia64 alldefconfig powerpc redwood_defconfig powerpc g5_defconfig powerpc wii_defconfig powerpc mpc836x_mds_defconfig arm jornada720_defconfig arm pxa3xx_defconfig openrisc alldefconfig powerpc mgcoge_defconfig arm s3c2410_defconfig openriscor1ksim_defconfig powerpcamigaone_defconfig powerpc mpc834x_itxgp_defconfig sparc defconfig armspear3xx_defconfig arm at91_dt_defconfig powerpc ebony_defconfig mips tb0226_defconfig powerpc mpc8272_ads_defconfig sh espt_defconfig arm vf610m4_defconfig armmulti_v5_defconfig arm nhk8815_defconfig m68kq40_defconfig sparc64 defconfig m68km5307c3_defconfig arm tct_hammer_defconfig m68k bvme6000_defconfig armkeystone_defconfig s390 debug_defconfig arm pxa255-idp_defconfig powerpc tqm8548_defconfig xtensa defconfig armoxnas_v6_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig i386 allyesconfig sparcallyesconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20201204 x86_64 randconfig-a006-20201204 x86_64 randconfig-a002-20201204 x86_64 randconfig-a001-20201204 x86_64
Re: [PATCH v9 0/3] Use the generic PHY framework for Ingenic USB PHY.
On 16-11-20, 22:19, 周琰杰 (Zhou Yanjie) wrote: > v3->v4: > Only add new generic-PHY driver, without removing the old one. Because the > jz4740-musb driver is not ready to use the generic PHY framework. When the > jz4740-musb driver is modified to use the generic PHY framework, the old > jz4770-phy driver can be "retired". > > v4->v5: > 1.Add an extra blank line between "devm_of_phy_provider_register" and > "return". > 2.Remove unnecessary "phy_set_drvdata". > 3.Add Paul Cercueil's Reviewed-by. > > v5->v6: > 1.Revert the removal of "phy_set_drvdata" in v5, removing "phy_set_drvdata" > will > cause a kernel panic on CI20. > Reported-by: H. Nikolaus Schaller > 2.Rewrite the macro definitions, replace the original code with "FIELD_PREP()" > and "u32p_replace_bits()" according to Vinod Koul's suggestion. > > v6->v7: > 1.Remove the stray tab character. > 2.Remove unnecessary "platform_set_drvdata". > 3.Remove the "dev" field in priv structure, and use >dev instead. > > v7->v8: > Add support for Ingenic JZ4775 SoC and X2000 SoC. > > v8->v9: > Correct the path errors in "ingenic,phy-usb.yaml" and "ingenic,cgu.yaml". Applied, thanks -- ~Vinod
Re: [PATCH v2] dt-bindings: phy: Convert Broadcom SATA PHY to YAML
On 04-12-20, 11:35, Florian Fainelli wrote: > Update the Broadcom SATA PHY Device Tree binding to a YAML format. > Applied, thanks -- ~Vinod
Re: [PATCH v3 9/9] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
Hi Lyude,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20201204]
[cannot apply to linus/master drm/drm-next v5.10-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Lyude-Paul/drm-i915-Add-support-for-Intel-s-eDP-backlight-controls/20201205-063902
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/18a741e6e1a9f39966c71ef577ef96600891d7ac
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Lyude-Paul/drm-i915-Add-support-for-Intel-s-eDP-backlight-controls/20201205-063902
git checkout 18a741e6e1a9f39966c71ef577ef96600891d7ac
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/msm/dp/dp_ctrl.c: In function 'dp_ctrl_use_fixed_nvid':
>> drivers/gpu/drm/msm/dp/dp_ctrl.c:1421:16: error: implicit declaration of
>> function 'drm_dp_get_edid_quirks'; did you mean 'drm_do_get_edid'?
>> [-Werror=implicit-function-declaration]
1421 | edid_quirks = drm_dp_get_edid_quirks(ctrl->panel->edid);
|^~
|drm_do_get_edid
>> drivers/gpu/drm/msm/dp/dp_ctrl.c:1427:11: error: too many arguments to
>> function 'drm_dp_has_quirk'
1427 | return (drm_dp_has_quirk(>panel->desc, edid_quirks,
| ^~~~
In file included from drivers/gpu/drm/msm/dp/dp_ctrl.c:14:
include/drm/drm_dp_helper.h:1895:1: note: declared here
1895 | drm_dp_has_quirk(const struct drm_dp_desc *desc, enum drm_dp_quirk
quirk)
| ^~~~
cc1: some warnings being treated as errors
vim +1421 drivers/gpu/drm/msm/dp/dp_ctrl.c
c943b4948b5848 Chandan Uddaraju 2020-08-27 1415
c943b4948b5848 Chandan Uddaraju 2020-08-27 1416 static bool
dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
c943b4948b5848 Chandan Uddaraju 2020-08-27 1417 {
c943b4948b5848 Chandan Uddaraju 2020-08-27 1418u8 *dpcd =
ctrl->panel->dpcd;
c943b4948b5848 Chandan Uddaraju 2020-08-27 1419u32 edid_quirks = 0;
c943b4948b5848 Chandan Uddaraju 2020-08-27 1420
c943b4948b5848 Chandan Uddaraju 2020-08-27 @1421edid_quirks =
drm_dp_get_edid_quirks(ctrl->panel->edid);
c943b4948b5848 Chandan Uddaraju 2020-08-27 1422/*
c943b4948b5848 Chandan Uddaraju 2020-08-27 1423 * For better interop
experience, used a fixed NVID=0x8000
c943b4948b5848 Chandan Uddaraju 2020-08-27 1424 * whenever connected
to a VGA dongle downstream.
c943b4948b5848 Chandan Uddaraju 2020-08-27 1425 */
c943b4948b5848 Chandan Uddaraju 2020-08-27 1426if
(drm_dp_is_branch(dpcd))
c943b4948b5848 Chandan Uddaraju 2020-08-27 @1427return
(drm_dp_has_quirk(>panel->desc, edid_quirks,
c943b4948b5848 Chandan Uddaraju 2020-08-27 1428
DP_DPCD_QUIRK_CONSTANT_N));
c943b4948b5848 Chandan Uddaraju 2020-08-27 1429
c943b4948b5848 Chandan Uddaraju 2020-08-27 1430return false;
c943b4948b5848 Chandan Uddaraju 2020-08-27 1431 }
c943b4948b5848 Chandan Uddaraju 2020-08-27 1432
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2] phy: rockchip: set pulldown for strobe line in dts
On 29-11-20, 13:44, Chris Ruehl wrote: > This patchset add support to set the strobe line pulldown via dt property Applied, thanks -- ~Vinod
RE: [PATCH] ufshcd: fix Wsometimes-uninitialized warning
>
>
> From: Arnd Bergmann
>
> clang complains about a possible code path in which a variable is
> used without an initialization:
>
> drivers/scsi/ufs/ufshcd.c:7690:3: error: variable 'sdp' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
> BUG_ON(1);
> ^
> include/asm-generic/bug.h:63:36: note: expanded from macro 'BUG_ON'
> #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
>^~~
>
> Turn the BUG_ON(1) into an unconditional BUG() that makes it clear
> to clang that this code path is never hit.
>
> Fixes: 4f3e900b6282 ("scsi: ufs: Clear UAC for FFU and RPMB LUNs")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Avri Altman
> ---
> drivers/scsi/ufs/ufshcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index f165baee937f..b4f7c4263334 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7687,7 +7687,7 @@ static int ufshcd_clear_ua_wlun(struct ufs_hba
> *hba, u8 wlun)
> else if (wlun == UFS_UPIU_RPMB_WLUN)
> sdp = hba->sdev_rpmb;
> else
> - BUG_ON(1);
> + BUG();
> if (sdp) {
> ret = scsi_device_get(sdp);
> if (!ret && !scsi_device_online(sdp)) {
> --
> 2.27.0
RE: [PATCH] ufshcd: fix Wsometimes-uninitialized warning
>
>
> From: Arnd Bergmann
>
> clang complains about a possible code path in which a variable is
> used without an initialization:
>
> drivers/scsi/ufs/ufshcd.c:7690:3: error: variable 'sdp' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
> BUG_ON(1);
> ^
> include/asm-generic/bug.h:63:36: note: expanded from macro 'BUG_ON'
> #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
>^~~
>
> Turn the BUG_ON(1) into an unconditional BUG() that makes it clear
> to clang that this code path is never hit.
>
> Fixes: 4f3e900b6282 ("scsi: ufs: Clear UAC for FFU and RPMB LUNs")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Avri Altman
> ---
> drivers/scsi/ufs/ufshcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index f165baee937f..b4f7c4263334 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7687,7 +7687,7 @@ static int ufshcd_clear_ua_wlun(struct ufs_hba
> *hba, u8 wlun)
> else if (wlun == UFS_UPIU_RPMB_WLUN)
> sdp = hba->sdev_rpmb;
> else
> - BUG_ON(1);
> + BUG();
> if (sdp) {
> ret = scsi_device_get(sdp);
> if (!ret && !scsi_device_online(sdp)) {
> --
> 2.27.0
RE: [PATCH v4 0/8] Refine error history and introduce event_notify vop
> > Hi Stanley, > Will you split this series to 3 separate series: > Phy initialization cleanup, Error history, and event notification? > As those 3 aren't really connected? > > Please maintain Can's reviewed-by tag for the error history patches, > And add mine for the phy initialization, so Martin can pick those. And for the new event notification vop of course. Sorry. Thanks, Avri > > Thanks, > Avri > > > > > Hi, > > This series refines error history functions, do vop cleanups and introduce a > > new event_notify vop to allow vendor to get notification of important > > events. > > > > Changes since v3: > > - Fix build warning in patch [8/8] > > > > Changes since v2: > > - Add patches for vop cleanups > > - Introduce phy_initialization helper and replace direct invoking in > > ufs-cdns > > and ufs-dwc by the helper > > - Introduce event_notify vop implemntation in ufs-mediatek > > > > Changes since v1: > > - Change notify_event() to event_notify() to follow vop naming covention > > > > Stanley Chu (8): > > scsi: ufs: Remove unused setup_regulators variant function > > scsi: ufs: Introduce phy_initialization helper > > scsi: ufs-cdns: Use phy_initialization helper > > scsi: ufs-dwc: Use phy_initialization helper > > scsi: ufs: Add error history for abort event in UFS Device W-LUN > > scsi: ufs: Refine error history functions > > scsi: ufs: Introduce event_notify variant function > > scsi: ufs-mediatek: Introduce event_notify implementation > > > > drivers/scsi/ufs/cdns-pltfrm.c| 3 +- > > drivers/scsi/ufs/ufs-mediatek-trace.h | 37 > > drivers/scsi/ufs/ufs-mediatek.c | 12 +++ > > drivers/scsi/ufs/ufshcd-dwc.c | 11 +-- > > drivers/scsi/ufs/ufshcd.c | 132 ++ > > drivers/scsi/ufs/ufshcd.h | 100 +-- > > 6 files changed, 175 insertions(+), 120 deletions(-) > > create mode 100644 drivers/scsi/ufs/ufs-mediatek-trace.h > > > > -- > > 2.18.0
Re: [PATCH 1/2] dt-bindings: phy: add Amlogic G12A Analog MIPI D-PHY bindings
On 23-11-20, 15:51, Neil Armstrong wrote:
> The Amlogic G12A SoCs embeds an Analog MIPI D-PHY to communicate with DSI
> panels, this adds the bindings.
>
> This Analog D-PHY works with a separate Digital MIPI D-PHY.
Pls cc Rob on dt binding patches (hint get_maintainer.pl would tell you
do so)
>
> Signed-off-by: Neil Armstrong
> ---
> .../phy/amlogic,g12a-mipi-dphy-analog.yaml| 40 +++
> 1 file changed, 40 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
> b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
> new file mode 100644
> index ..28663552f05b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/amlogic,g12a-mipi-dphy-analog.yaml
> @@ -0,0 +1,40 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/phy/amlogic,g12a-mipi-dphy-analog.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Amlogic G12A MIPI analog PHY
> +
> +maintainers:
> + - Neil Armstrong
> +
> +description: |+
> + The Everything-Else Power Domains node should be the child of a syscon
> + node with the required property:
> +
> + - compatible: Should be the following:
> +"amlogic,meson-gx-hhi-sysctrl", "simple-mfd", "syscon"
> +
> + Refer to the the bindings described in
> + Documentation/devicetree/bindings/mfd/syscon.yaml
> +
> +properties:
> + compatible:
> +const: amlogic,g12a-mipi-dphy-analog
> +
> + "#phy-cells":
> +const: 0
> +
> +required:
> + - compatible
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +mpphy: phy {
> + compatible = "amlogic,g12a-mipi-dphy-analog";
> + #phy-cells = <0>;
> +};
> --
> 2.25.1
--
~Vinod
RE: [PATCH v4 0/8] Refine error history and introduce event_notify vop
Hi Stanley, Will you split this series to 3 separate series: Phy initialization cleanup, Error history, and event notification? As those 3 aren't really connected? Please maintain Can's reviewed-by tag for the error history patches, And add mine for the phy initialization, so Martin can pick those. Thanks, Avri > > Hi, > This series refines error history functions, do vop cleanups and introduce a > new event_notify vop to allow vendor to get notification of important > events. > > Changes since v3: > - Fix build warning in patch [8/8] > > Changes since v2: > - Add patches for vop cleanups > - Introduce phy_initialization helper and replace direct invoking in > ufs-cdns > and ufs-dwc by the helper > - Introduce event_notify vop implemntation in ufs-mediatek > > Changes since v1: > - Change notify_event() to event_notify() to follow vop naming covention > > Stanley Chu (8): > scsi: ufs: Remove unused setup_regulators variant function > scsi: ufs: Introduce phy_initialization helper > scsi: ufs-cdns: Use phy_initialization helper > scsi: ufs-dwc: Use phy_initialization helper > scsi: ufs: Add error history for abort event in UFS Device W-LUN > scsi: ufs: Refine error history functions > scsi: ufs: Introduce event_notify variant function > scsi: ufs-mediatek: Introduce event_notify implementation > > drivers/scsi/ufs/cdns-pltfrm.c| 3 +- > drivers/scsi/ufs/ufs-mediatek-trace.h | 37 > drivers/scsi/ufs/ufs-mediatek.c | 12 +++ > drivers/scsi/ufs/ufshcd-dwc.c | 11 +-- > drivers/scsi/ufs/ufshcd.c | 132 ++ > drivers/scsi/ufs/ufshcd.h | 100 +-- > 6 files changed, 175 insertions(+), 120 deletions(-) > create mode 100644 drivers/scsi/ufs/ufs-mediatek-trace.h > > -- > 2.18.0
Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver
On 04.12.20 04:35, Jason Wang wrote: >> --- a/drivers/gpio/Kconfig >> +++ b/drivers/gpio/Kconfig >> @@ -1615,6 +1615,15 @@ config GPIO_MOCKUP >> tools/testing/selftests/gpio/gpio-mockup.sh. Reference the >> usage in >> it. >> +config GPIO_VIRTIO >> + tristate "VirtIO GPIO support" >> + depends on VIRTIO > > > Let's use select, since there's no prompt for VIRTIO and it doesn't have > any dependencies. whoops, it's not that simple: make: Entering directory '/home/nekrad/src/apu2-dev/pkg/kernel.apu2.git' make[1]: Entering directory '/home/nekrad/src/dk/DistroKit/platform-x86_64/build-target/linux-5.8.9-build' GEN Makefile drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO drivers/gpio/Kconfig:1618: symbol GPIO_VIRTIO depends on GPIOLIB drivers/gpio/Kconfig:14:symbol GPIOLIB is selected by I2C_MUX_LTC4306 drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C drivers/i2c/Kconfig:8: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER Seems that we can only depend on or select some symbol - we run into huge trouble if thats mixed. Just changed DRM_VIRTIO_GPU to just select VIRIO instead of depending on it, and now it works. I've posted another patch for fixing drivers/gpu/drm/virtio/Kconfig to use 'select' instead of 'depends on'. -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
Excerpts from Andy Lutomirski's message of December 3, 2020 3:09 pm: > On Tue, Dec 1, 2020 at 6:50 PM Nicholas Piggin wrote: >> >> Excerpts from Andy Lutomirski's message of November 29, 2020 3:55 am: >> > On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: >> >> >> >> And get rid of the generic sync_core_before_usermode facility. This is >> >> functionally a no-op in the core scheduler code, but it also catches >> >> >> >> This helper is the wrong way around I think. The idea that membarrier >> >> state requires a core sync before returning to user is the easy one >> >> that does not need hiding behind membarrier calls. The gap in core >> >> synchronization due to x86's sysret/sysexit and lazy tlb mode, is the >> >> tricky detail that is better put in x86 lazy tlb code. >> >> >> >> Consider if an arch did not synchronize core in switch_mm either, then >> >> membarrier_mm_sync_core_before_usermode would be in the wrong place >> >> but arch specific mmu context functions would still be the right place. >> >> There is also a exit_lazy_tlb case that is not covered by this call, which >> >> could be a bugs (kthread use mm the membarrier process's mm then context >> >> switch back to the process without switching mm or lazy mm switch). >> >> >> >> This makes lazy tlb code a bit more modular. >> > >> > I have a couple of membarrier fixes that I want to send out today or >> > tomorrow, and they might eliminate the need for this patch. Let me >> > think about this a little bit. I'll cc you. The existing code is way >> > to subtle and the comments are far too confusing for me to be quickly >> > confident about any of my conclusions :) >> > >> >> Thanks for the head's up. I'll have to have a better look through them >> but I don't know that it eliminates the need for this entirely although >> it might close some gaps and make this not a bug fix. The problem here >> is x86 code wanted something to be called when a lazy mm is unlazied, >> but it missed some spots and also the core scheduler doesn't need to >> know about those x86 details if it has this generic call that annotates >> the lazy handling better. > > I'll send v3 tomorrow. They add more sync_core_before_usermode() callers. > > Having looked at your patches a bunch and the membarrier code a bunch, > I don't think I like the approach of pushing this logic out into new > core functions called by arch code. Right now, even with my > membarrier patches applied, understanding how (for example) the x86 > switch_mm_irqs_off() plus the scheduler code provides the barriers > that membarrier needs is quite complicated, and it's not clear to me > that the code is even correct. At the very least I'm pretty sure that > the x86 comments are misleading. > > With your patches, someone trying to > audit the code would have to follow core code calling into arch code > and back out into core code to figure out what's going on. I think > the result is worse. Sorry I missed this and rather than reply to the later version you have a bigger comment here. I disagree. Until now nobody following it noticed that the mm gets un-lazied in other cases, because that was not too clear from the code (only indirectly using non-standard terminology in the arch support document). In other words, membarrier needs a special sync to deal with the case when a kthread takes the mm. exit_lazy_tlb gives membarrier code that exact hook that it wants from the core scheduler code. > > I wrote this incomplete patch which takes the opposite approach (sorry > for whitespace damage): That said, if you want to move the code entirely in the x86 arch from exit_lazy_tlb to switch_mm_irqs_off, it's trivial and touches no core code after my series :) and I would have no problem with doing that. I suspect it might actually be more readable to go the other way and pull most of the real_prev == next membarrier code into exit_lazy_tlb instead, but I could be wrong I don't know exactly how the x86 lazy state correlates with core lazy tlb state. Thanks, Nick > > commit 928b5c60e93f475934892d6e0b357ebf0a2bf87d > Author: Andy Lutomirski > Date: Wed Dec 2 17:24:02 2020 -0800 > > [WIP] x86/mm: Handle unlazying membarrier core sync in the arch code > > The core scheduler isn't a great place for > membarrier_mm_sync_core_before_usermode() -- the core scheduler > doesn't actually know whether we are lazy. With the old code, if a > CPU is running a membarrier-registered task, goes idle, gets unlazied > via a TLB shootdown IPI, and switches back to the > membarrier-registered task, it will do an unnecessary core sync. > > Conveniently, x86 is the only architecture that does anything in this > hook, so we can just move the code. > > XXX: actually delete the old code. > > Signed-off-by: Andy Lutomirski > > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c > index 3338a1feccf9..e27300fc865b 100644 > --- a/arch/x86/mm/tlb.c > +++ b/arch/x86/mm/tlb.c
