[PATCH REBASE v4 00/14] Provide generic top-down mmap layout functions
Hi Andrew, This is simply a rebase on top of next-20190719, where I added various Acked/Reviewed-by from Kees and Catalin and a note on commit 08/14 suggested by Kees regarding the removal of STACK_RND_MASK that is safe doing. I would have appreciated a feedback from a mips maintainer but failed to get it: can you consider this series for inclusion anyway ? Mips parts have been reviewed-by Kees. Thanks, This series introduces generic functions to make top-down mmap layout easily accessible to architectures, in particular riscv which was the initial goal of this series. The generic implementation was taken from arm64 and used successively by arm, mips and finally riscv. Note that in addition the series fixes 2 issues: - stack randomization was taken into account even if not necessary. - [1] fixed an issue with mmap base which did not take into account randomization but did not report it to arm and mips, so by moving arm64 into a generic library, this problem is now fixed for both architectures. This work is an effort to factorize architecture functions to avoid code duplication and oversights as in [1]. [1]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html Changes in v4: - Make ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT select ARCH_HAS_ELF_RANDOMIZE by default as suggested by Kees, - ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT depends on MMU and defines the functions needed by ARCH_HAS_ELF_RANDOMIZE => architectures that use the generic mmap topdown functions cannot have ARCH_HAS_ELF_RANDOMIZE selected without MMU, but I think it's ok since randomization without MMU does not add much security anyway. - There is no common API to determine if a process is 32b, so I came up with !IS_ENABLED(CONFIG_64BIT) || is_compat_task() in [PATCH v4 12/14]. - Mention in the change log that x86 already takes care of not offseting mmap base address if the task does not want randomization. - Re-introduce a comment that should not have been removed. - Add Reviewed/Acked-By from Paul, Christoph and Kees, thank you for that. - I tried to minimize the changes from the commits in v3 in order to make easier the review of the v4, the commits changed or added are: - [PATCH v4 5/14] - [PATCH v4 8/14] - [PATCH v4 11/14] - [PATCH v4 12/14] - [PATCH v4 13/14] Changes in v3: - Split into small patches to ease review as suggested by Christoph Hellwig and Kees Cook - Move help text of new config as a comment, as suggested by Christoph - Make new config depend on MMU, as suggested by Christoph Changes in v2 as suggested by Christoph Hellwig: - Preparatory patch that moves randomize_stack_top - Fix duplicate config in riscv - Align #if defined on next line => this gives rise to a checkpatch warning. I found this pattern all around the tree, in the same proportion as the previous pattern which was less pretty: git grep -C 1 -n -P "^#if defined.+\|\|.*$" Alexandre Ghiti (14): mm, fs: Move randomize_stack_top from fs to mm arm64: Make use of is_compat_task instead of hardcoding this test arm64: Consider stack randomization for mmap base only when necessary arm64, mm: Move generic mmap layout functions to mm arm64, mm: Make randomization selected by generic topdown mmap layout arm: Properly account for stack randomization and stack guard gap arm: Use STACK_TOP when computing mmap base address arm: Use generic mmap top-down layout and brk randomization mips: Properly account for stack randomization and stack guard gap mips: Use STACK_TOP when computing mmap base address mips: Adjust brk randomization offset to fit generic version mips: Replace arch specific way to determine 32bit task with generic version mips: Use generic mmap top-down layout and brk randomization riscv: Make mmap allocation top-down by default arch/Kconfig | 11 +++ arch/arm/Kconfig | 2 +- arch/arm/include/asm/processor.h | 2 - arch/arm/kernel/process.c | 5 -- arch/arm/mm/mmap.c | 52 -- arch/arm64/Kconfig | 2 +- arch/arm64/include/asm/processor.h | 2 - arch/arm64/kernel/process.c| 8 --- arch/arm64/mm/mmap.c | 72 --- arch/mips/Kconfig | 2 +- arch/mips/include/asm/processor.h | 5 -- arch/mips/mm/mmap.c| 84 -- arch/riscv/Kconfig | 11 +++ fs/binfmt_elf.c| 20 -- include/linux/mm.h | 2 + kernel/sysctl.c| 6 +- mm/util.c | 107 - 17 files changed, 137 insertions(+), 256 deletions(-) -- 2.20.1
Re: [PATCH v2] drivers: net: xgene: Remove acpi_has_method() calls
On Tue, Jul 23, 2019 at 02:07:39PM -0700, David Miller wrote: > From: David Miller > Date: Tue, 23 Jul 2019 14:06:46 -0700 (PDT) > > > From: Kelsey Skunberg > > Date: Tue, 23 Jul 2019 12:58:11 -0600 > > > >> acpi_evaluate_object will already return an error if the needed method > >> does not exist. Remove unnecessary acpi_has_method() calls and check the > >> returned acpi_status for failure instead. > >> > >> Signed-off-by: Kelsey Skunberg > >> --- > >> Changes in v2: > >>- Fixed white space warnings and errors > > > > Applied to net-next. > > Wow did you even build test this? Reverted... > This patch has definitely been a mess, so thank you for your time and sticking with me here. I thought my build tests included these files, though discovered they did not. Since submitting v2, I was able to reproduce the same errors you listed and corrected the problem in v3. I also realized my .git/post-commit file needed to be fixed, so the white space problem in v1 should also not be a problem in the future. Please let me know if you notice anything else I can improve on. I will learn from my mistakes and really appreciate advice. Thank you again, David. Best Regards, Kelsey
Re: linux-next: Fixes tag needs some work in the s390-fixes tree
Hi Stephen,
On Wed, Jul 24, 2019 at 07:42:27AM +1000, Stephen Rothwell wrote:
> In commit
> 8b515be512a2 ("vfio-ccw: Fix memory leak and don't call cp_free in cp_init")
> Fixes tag
> Fixes: 812271b910 ("s390/cio: Squash cp_free() and cp_unpin_free()")
> - SHA1 should be at least 12 digits long
> Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> or later) just making sure it is not set (or set to "auto").
Yes, I noticed this when merging the vfio tree, but decided to not
ask for a rebase to fix this.
Are your scripts that do sanity checks available somewhere? I'm
wondering since I would also like to do some sanity checks before
pushing updates to kernel.org like
- has the git author signed off the patch?
- has the git committer signed off the patch?
- are "fixes" tags sane: does commit exist and is format ok?
Re: [PATCH 0/8] ti-sysc related warning fixes for v5.3-rc cycle
On 23/07/19 4:58 PM, Tony Lindgren wrote: Hi all, I noticed that with recent ti-sysc driver changes some new warnings have crept in. Mostly they are caused by having different configuration in the dts compared to the legacy platform data. Let's fix these first before we continue dropping the legacy platform data. I also noticed we need two fixes for the ti-sysc driver while looking at the warnings. Tony, Apart from Patch 2(breaks DS0 on AM3). Rest all work fine. Tested for DS0/RTC+ddr on AM4, DS0 on AM3 Boneblack. You can add my: Tested-by: Keerthy For all the 7 patches except Patch 2. Regards, Keerthy Regards, Tony Tony Lindgren (8): ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc bus: ti-sysc: Fix handling of forced idle bus: ti-sysc: Fix using configured sysc mask value ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8 ARM: dts: Fix flags for gpio7 ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7 ARM: dts: Fix lcdc sysc flags for am3 arch/arm/boot/dts/am33xx-l4.dtsi | 6 +++- arch/arm/boot/dts/am437x-l4.dtsi | 4 +++ .../boot/dts/am57xx-beagle-x15-common.dtsi| 2 +- arch/arm/boot/dts/dra7-evm.dts| 2 +- arch/arm/boot/dts/dra7-l4.dtsi| 31 --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c| 2 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 3 +- drivers/bus/ti-sysc.c | 10 +++--- 8 files changed, 31 insertions(+), 29 deletions(-)
Re: [PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
On 24/07/19 12:33 AM, Suman Anna wrote:
+ Jyri
On 7/23/19 6:28 AM, Tony Lindgren wrote:
We currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.
Hi Tony,
While I understand that you are trying to match the DT data with the
existing legacy data, do you know if there was a reason why this was
omitted in the first place? Should we be really adding the MSTANDBY_
flags and fix up the DTS node accordingly? I tried looking through the
git log, and the initial commit itself didn't add the MSTANDBY_ flags
but used the SYSC_HAS_MIDLEMODE.
Jyri,
Do you know the history?
Tony/Suman,
This patch breaks DS0 on am3.
- Keerthy
regards
Suman
Let's fix the warning by removing SYSC_HAS_MIDLEMODE. Note that
the am335x TRM lists SYSC_HAS_MIDLEMODE, but it is unused.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -231,7 +231,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
static struct omap_hwmod_class_sysconfig lcdc_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x54,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= _hwmod_sysc_type2,
};
[PATCH] quota: fix condition for resetting time limit in do_set_dqblk()
We reset time limit when current usage is smaller
or equal to soft limit in other place, so follow
this rule in do_set_dqblk().
Signed-off-by: Chengguang Xu
---
fs/quota/dquot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index be9c471cdbc8..6e826b454082 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -2731,7 +2731,7 @@ static int do_set_dqblk(struct dquot *dquot, struct
qc_dqblk *di)
if (check_blim) {
if (!dm->dqb_bsoftlimit ||
- dm->dqb_curspace + dm->dqb_rsvspace < dm->dqb_bsoftlimit) {
+ dm->dqb_curspace + dm->dqb_rsvspace <= dm->dqb_bsoftlimit) {
dm->dqb_btime = 0;
clear_bit(DQ_BLKS_B, >dq_flags);
} else if (!(di->d_fieldmask & QC_SPC_TIMER))
@@ -2740,7 +2740,7 @@ static int do_set_dqblk(struct dquot *dquot, struct
qc_dqblk *di)
}
if (check_ilim) {
if (!dm->dqb_isoftlimit ||
- dm->dqb_curinodes < dm->dqb_isoftlimit) {
+ dm->dqb_curinodes <= dm->dqb_isoftlimit) {
dm->dqb_itime = 0;
clear_bit(DQ_INODES_B, >dq_flags);
} else if (!(di->d_fieldmask & QC_INO_TIMER))
--
2.20.1
Re: [PATCH 1/2] mm/hmm: a few more C style and comment clean ups
On Tue, Jul 23, 2019 at 11:57:52PM +, Jason Gunthorpe wrote:
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 16b6731a34db79..3d8cdfb67a6ab8 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -285,8 +285,9 @@ struct hmm_vma_walk {
> struct hmm_range*range;
> struct dev_pagemap *pgmap;
> unsigned long last;
> - boolfault;
> - boolblock;
> + boolfault : 1;
> + boolblock : 1;
> + boolhugetlb : 1;
I don't think we should even keep these bools around. I have something
like this hiding in a branche, which properly cleans much of this up:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-dma-cleanup
Notably:
http://git.infradead.org/users/hch/misc.git/commitdiff/2abdc0ac8f9f32149246957121ebccbe5c0a729d
http://git.infradead.org/users/hch/misc.git/commitdiff/a34ccd30ee8a8a3111d9e91711c12901ed7dea74
http://git.infradead.org/users/hch/misc.git/commitdiff/81f442ebac7170815af7770a1efa9c4ab662137e
This doesn't go all the way yet - the page_walk infrastructure is
built around the idea of doing its own vma lookups, and we should
eventually kill the lookup inside hmm entirely.
Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition
On Tue, Jul 23, 2019 at 09:04:40AM +0200, Maxime Ripard wrote: > Hi Sean, > > On Tue, Jul 23, 2019 at 07:25:57AM +0100, Sean Young wrote: > > On Mon, Jul 15, 2019 at 01:12:45PM +0100, Sean Young wrote: > > > On Sun, Jul 14, 2019 at 04:32:22PM +0200, Clément Péron wrote: > > > > Hi Sean, > > > > > > > > You acked the whole v3 series but this patch has been introduced in v5 > > > > could you ack this one too? > > > > > > Acked-by: Sean Young > > > > So who's tree should this series go through? It seems mostly device tree. > > Alternatively I'm happy to try it get merged via the media tree. > > Ideally the media bits should go through the media tree, the DT bits > will go through arm-soc > > So you can apply the patches 1-4, 7 and 10, I'll apply the rest. > > Does that work for you? Works for me, I'll add them to my next pull request to Mauro. Thanks, Sean
Re: [PATCH] mt76_init_sband_2g: null check the allocation
Navid Emamdoost writes: > devm_kzalloc may fail and return NULL. So the null check is needed. > > Signed-off-by: Navid Emamdoost > --- > drivers/net/wireless/mediatek/mt7601u/init.c | 3 +++ > 1 file changed, 3 insertions(+) The prefix in the title should be "mt7601u:". https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong -- Kalle Valo
Re: [PATCH v2] media:dvb-frontends:Remove dvb_pll_devcount and id module parameters.
On Sat, Jul 20, 2019 at 11:43:02AM +0530, Vandana BN wrote: > Syzbot reported global-out-of-bounds Read in dvb_pll_attach, while > accessing id[dvb_pll_devcount], because dvb_pll_devcount was 65, > that is more than size of 'id' which is DVB_PLL_MAX(64). > > Fix would be to check if DVB_PLL_MAX devices are attached and if so return > NULL from dvb_pll_attach(). But this will put a limit on the number of > devices that can be attached. > Also dvb_pll_devcount and "id" module parameter are used for debugging > purpose to override/force PLL type. > So this patch removes these module parameters. > > Reported-by: syz...@syzkaller.appspotmail.com > > usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the > software demuxer > dvbdev: DVB: registering new adapter (774 Friio White ISDB-T USB2.0) > usb 1-1: media controller created > dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. > tc90522 0-0018: Toshiba TC90522 attached. > usb 1-1: DVB: registering adapter 0 frontend 0 (Toshiba TC90522 ISDB-T > module)... > dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-T > module' registered. > == > BUG: KASAN: global-out-of-bounds in dvb_pll_attach+0x6c5/0x830 > drivers/media/dvb-frontends/dvb-pll.c:798 > Read of size 4 at addr 89c9e5e0 by task kworker/0:1/12 > > CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc6+ #13 > 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+0xca/0x13e lib/dump_stack.c:113 > print_address_description+0x67/0x231 mm/kasan/report.c:188 > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317 > kasan_report+0xe/0x20 mm/kasan/common.c:614 > dvb_pll_attach+0x6c5/0x830 drivers/media/dvb-frontends/dvb-pll.c:798 > dvb_pll_probe+0xfe/0x174 drivers/media/dvb-frontends/dvb-pll.c:877 > i2c_device_probe+0x790/0xaa0 drivers/i2c/i2c-core-base.c:389 > really_probe+0x281/0x660 drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > __device_attach+0x217/0x360 drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > i2c_new_client_device+0x5b3/0xc40 drivers/i2c/i2c-core-base.c:778 > i2c_new_device+0x19/0x50 drivers/i2c/i2c-core-base.c:821 > dvb_module_probe+0xf9/0x220 drivers/media/dvb-core/dvbdev.c:985 > friio_tuner_attach+0x125/0x1d0 drivers/media/usb/dvb-usb-v2/gl861.c:536 > dvb_usbv2_adapter_frontend_init > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:675 [inline] > dvb_usbv2_adapter_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:804 > [inline] > dvb_usbv2_init drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:865 [inline] > dvb_usbv2_probe.cold+0x24dc/0x255d > drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:980 > usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 > really_probe+0x281/0x660 drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > __device_attach+0x217/0x360 drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 > generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 > usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 > really_probe+0x281/0x660 drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 > __device_attach+0x217/0x360 drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 > device_add+0xae6/0x16f0 drivers/base/core.c:2111 > usb_new_device.cold+0x8c1/0x1016 drivers/usb/core/hub.c:2534 > hub_port_connect drivers/usb/core/hub.c:5089 [inline] > hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] > port_event drivers/usb/core/hub.c:5350 [inline] > hub_event+0x1ada/0x3590 drivers/usb/core/hub.c:5432 > process_one_work+0x905/0x1570 kernel/workqueue.c:2269 > process_scheduled_works kernel/workqueue.c:2331 [inline] > worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 > kthread+0x30b/0x410 kernel/kthread.c:255 > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 > > The buggy address belongs to the variable: > id+0x100/0x120 > > Memory state around the buggy address: > 89c9e480: fa fa fa fa 00 00 fa fa fa fa fa fa 00 00 00 00 > 89c9e500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 89c9e580: 00 00 00 00 00 00 00 00 00 00 00 00
[PATCH] powerpc: Support CMDLINE_EXTEND
Device tree aware platforms can make use of CMDLINE_EXTEND to extend the kernel command line provided by the bootloader. This is particularly useful to set parameters for built-in modules that would otherwise be done at module insertion. Add support for this in the powerpc architecture. Signed-off-by: Chris Packham --- arch/powerpc/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d8dcd8820369..cd9b3974aa36 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -851,6 +851,11 @@ config CMDLINE some command-line options at build time by entering them here. In most cases you will need to specify the root device here. +choice + prompt "Kernel command line type" if CMDLINE != "" + default CMDLINE_FORCE + depends on CMDLINE_BOOL + config CMDLINE_FORCE bool "Always use the default kernel command string" depends on CMDLINE_BOOL @@ -860,6 +865,13 @@ config CMDLINE_FORCE This is useful if you cannot or don't want to change the command-line options your boot loader passes to the kernel. +config CMDLINE_EXTEND + bool "Extend bootloader kernel arguments" + help + The command-line arguments provided by the boot loader will be + appended to the default kernel command string. +endchoice + config EXTRA_TARGETS string "Additional default image types" help -- 2.22.0
Re: [PATCH] arm64: dts: meson: odroid-n2: keep SD card regulator always on
Hi All,
On Mon, 22 Jul 2019 at 12:51, Neil Armstrong wrote:
>
> On 19/07/2019 21:29, Xavier Ruppen wrote:
> > When powering off the Odroid N2, the tflash_vdd regulator is
> > automatically turned off by the kernel. This is a problem
> > when issuing the "reboot" command while using an SD card.
> > The boot ROM does not power this regulator back on, blocking
> > the reboot process at the boot ROM stage, preventing the
> > SD card from being detected.
> >
> > Adding the "regulator-always-on" property fixes the problem.
> >
> > Signed-off-by: Xavier Ruppen
> > ---
> >
> > Here is what the boot ROM output looks like without this patch:
> >
> > [root@alarm ~]# reboot
> > [...]
> > [ 24.275860] shutdown[1]: All loop devices detached.
> > [ 24.278864] shutdown[1]: Detaching DM devices.
> > [ 24.287105] kvm: exiting hardware virtualization
> > [ 24.318776] reboot: Restarting system
> > bl31 reboot reason: 0xd
> > bl31 reboot reason: 0x0
> > system cmd 1.
> > G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;
> > EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;
> > NAND:81;SD?:0;SD:400;USB:8;LOOP:2;EMMC:800;NAND:81;
> > SD?:0;SD:400;USB:8;LOOP:3; [...]
> >
> > Other people can be seen having this problem on the odroid
> > forum [1].
> >
> > The cause of the problem was found by Martin Blumenstingl
> > on #linux-amlogic. We may want to add his Suggested-by tag
> > if he agrees.
> >
> > [1] https://forum.odroid.com/viewtopic.php?f=176=33993
> >
> > arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > index 81780ffcc7f0..4e916e1f71f7 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
> > @@ -53,6 +53,7 @@
> >
> > gpio = <_ao GPIOAO_8 GPIO_ACTIVE_HIGH>;
> > enable-active-high;
> > + regulator-always-on;
> > };
> >
> > tf_io: gpio-regulator-tf_io {
> >
>
> Surely solves the situation, thanks !
>
> please add a comment on top of "regulator-always-on" to explain why we always
> enable it,
> note we should always enable it in case of watchdog reboot or other
> uncontrolled reset,
> this regulator must never be disabled.
>
> Reviewed-by: Neil Armstrong
>
> Thanks,
> Neil
>
I am afraid this did not fix the issue I was also facing with
Archlinux on Odroid N2 using mainline u-boot.
Here is the log of at my end using latest mainline u-boot with Neil's patches.
[0] https://pastebin.com/HNmeY5uF
Well this issue also persist with eMMC not getting detected after reboot
If I try to change the dts to fix the sdcard.
I am checking this should we enable regulator-boot-on option but still no luck.
Best Regards
-Anand
[PATCH] ASoC: wm8955: Fix a typo in 'wm8995_pll_factors()' function name
This should be 'wm8955_pll_factors()' instead.
Fix it and use it.
Signed-off-by: Christophe JAILLET
---
sound/soc/codecs/wm8955.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wm8955.c b/sound/soc/codecs/wm8955.c
index cd204f79647d..ec82a8fafdf6 100644
--- a/sound/soc/codecs/wm8955.c
+++ b/sound/soc/codecs/wm8955.c
@@ -143,7 +143,7 @@ struct pll_factors {
* to allow rounding later */
#define FIXED_FLL_SIZE ((1 << 22) * 10)
-static int wm8995_pll_factors(struct device *dev,
+static int wm8955_pll_factors(struct device *dev,
int Fref, int Fout, struct pll_factors *pll)
{
u64 Kpart;
@@ -282,7 +282,7 @@ static int wm8955_configure_clocking(struct
snd_soc_component *component)
/* Use the last divider configuration we saw for the
* sample rate. */
- ret = wm8995_pll_factors(component->dev, wm8955->mclk_rate,
+ ret = wm8955_pll_factors(component->dev, wm8955->mclk_rate,
clock_cfgs[sr].mclk, );
if (ret != 0) {
dev_err(component->dev,
--
2.20.1
Re: [PATCH] powerpc: Wire up clone3 syscall
Hi, may I also ask to provide ppc_clone3 symbol also for 32-bit powerpc? Otherwise Michael's patch breaks build for me: powerpc-e500v2-linux-gnuspe-ld: arch/powerpc/kernel/systbl.o: in function `sys_call_table': (.rodata+0x6cc): undefined reference to `ppc_clone3' make: *** [Makefile:1060: vmlinux] Error 1 The patch was tested using Christian's program on a real e500 machine. --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -597,6 +597,14 @@ ppc_clone: stw r0,_TRAP(r1)/* register set saved */ b sys_clone + .globl ppc_clone3 +ppc_clone3: + SAVE_NVGPRS(r1) + lwz r0,_TRAP(r1) + rlwinm r0,r0,0,0,30/* clear LSB to indicate full */ + stw r0,_TRAP(r1)/* register set saved */ + b sys_clone3 + .globl ppc_swapcontext ppc_swapcontext: SAVE_NVGPRS(r1) I don't think this trivial hunk deserves a separate patch submission. Thanks, Arseny
Re: [PATCH v2 5/5] arm64: dts: qcom: sdm845-cheza: remove macro from unit name
On Wed, Jul 24, 2019 at 10:20 AM Vinod Koul wrote:
>
> Unit address is supposed to be a number, using a macro with hex value is
> not recommended, so add the value in unit name.
>
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:966.16-969.4: Warning
> (unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4d:
> unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:971.16-974.4: Warning
> (unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4e:
> unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:976.16-979.4: Warning
> (unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4f:
> unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:981.16-984.4: Warning
> (unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x50:
> unit name should not have leading "0x"
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:986.16-989.4: Warning
> (unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x51:
> unit name should not have leading "0x"
>
> Signed-off-by: Vinod Koul
> Reviewed-by: Stephen Boyd
Reviewed-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> index 1ebbd568dfd7..9b27b8346ba1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -963,27 +963,27 @@ ap_ts_i2c: {
> };
>
> _adc {
> - adc-chan@ADC5_AMUX_THM1_100K_PU {
> + adc-chan@4d {
> reg = ;
> label = "sdm_temp";
> };
>
> - adc-chan@ADC5_AMUX_THM2_100K_PU {
> + adc-chan@4e {
> reg = ;
> label = "quiet_temp";
> };
>
> - adc-chan@ADC5_AMUX_THM3_100K_PU {
> + adc-chan@4f {
> reg = ;
> label = "lte_temp_1";
> };
>
> - adc-chan@ADC5_AMUX_THM4_100K_PU {
> + adc-chan@50 {
> reg = ;
> label = "lte_temp_2";
> };
>
> - adc-chan@ADC5_AMUX_THM5_100K_PU {
> + adc-chan@51 {
> reg = ;
> label = "charger_temp";
> };
> --
> 2.20.1
>
Re: [PATCH v2 3/5] arm64: dts: qcom: sdm845: remove unit name for thermal trip points
On Wed, Jul 24, 2019 at 10:20 AM Vinod Koul wrote: > > The thermal trip points have unit name but no reg property, so we can > remove them > > arch/arm64/boot/dts/qcom/sdm845.dtsi:2824.31-2828.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2830.31-2834.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2868.31-2872.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2874.31-2878.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2912.31-2916.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2918.31-2922.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2956.31-2960.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:2962.31-2966.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3000.31-3004.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu4-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3006.31-3010.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu4-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3044.31-3048.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu5-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3050.31-3054.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu5-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3088.31-3092.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu6-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3094.31-3098.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu6-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3132.31-3136.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu7-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3138.31-3142.7: Warning > (unit_address_vs_reg): /thermal-zones/cpu7-thermal/trips/trip-point@1: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3176.32-3180.7: Warning > (unit_address_vs_reg): /thermal-zones/aoss0-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3191.35-3195.7: Warning > (unit_address_vs_reg): /thermal-zones/cluster0-thermal/trips/trip-point@0: > node has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3211.35-3215.7: Warning > (unit_address_vs_reg): /thermal-zones/cluster1-thermal/trips/trip-point@0: > node has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3231.31-3235.7: Warning > (unit_address_vs_reg): /thermal-zones/gpu-thermal-top/trips/trip-point@0: > node has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3246.31-3250.7: Warning > (unit_address_vs_reg): /thermal-zones/gpu-thermal-bottom/trips/trip-point@0: > node has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3261.32-3265.7: Warning > (unit_address_vs_reg): /thermal-zones/aoss1-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3276.35-3280.7: Warning > (unit_address_vs_reg): /thermal-zones/q6-modem-thermal/trips/trip-point@0: > node has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3291.30-3295.7: Warning > (unit_address_vs_reg): /thermal-zones/mem-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3306.31-3310.7: Warning > (unit_address_vs_reg): /thermal-zones/wlan-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3321.33-3325.7: Warning > (unit_address_vs_reg): /thermal-zones/q6-hvx-thermal/trips/trip-point@0: node > has a unit name, but no reg property > arch/arm64/boot/dts/qcom/sdm845.dtsi:3336.33-3340.7: Warning > (unit_address_vs_reg):
Re: [PATCH v2 4/5] arm64: dts: qcom: sdm845: remove macro from unit name
On Wed, Jul 24, 2019 at 10:20 AM Vinod Koul wrote:
>
> Unit name is supposed to be a number, using a macro with hex value is
> not recommended, so add the value in unit name.
>
> arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning
> (unit_address_format): /soc/spmi@c44/pmic@0/adc@3100/adc-chan@0x06: unit
> name should not have leading "0x"
> arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning
> (unit_address_format): /soc/spmi@c44/pmic@0/adc@3100/adc-chan@0x06: unit
> name should not have leading 0s
>
> Signed-off-by: Vinod Koul
Reviewed-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/pm8998.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
> b/arch/arm64/boot/dts/qcom/pm8998.dtsi
> index 051a52df80f9..dc2ce23cde05 100644
> --- a/arch/arm64/boot/dts/qcom/pm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8998.dtsi
> @@ -78,7 +78,7 @@
> #size-cells = <0>;
> #io-channel-cells = <1>;
>
> - adc-chan@ADC5_DIE_TEMP {
> + adc-chan@6 {
> reg = ;
> label = "die_temp";
> };
> --
> 2.20.1
>
[GIT PULL] FPGA Manager fix for 5.3
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux-fpga.git tags/fixes-for-5.3 for you to fetch changes up to c3aefa0b8f54e8c7967191e546a11019bc060fe6: fpga-manager: altera-ps-spi: Fix build error (2019-07-23 17:29:17 -0700) FPGA Manager fixes for 5.3 Hi Greg, this is only one (late) bugfix for 5.3 that fixes a build error, when altera-ps-spi is built as builtin while a dependency is built as a module. This has been on the list for a while and I've reviewed it. Signed-off-by: Moritz Fischer YueHaibing (1): fpga-manager: altera-ps-spi: Fix build error drivers/fpga/Kconfig | 1 + 1 file changed, 1 insertion(+)
Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
Hi,
Saeed Mahameed 於 2019/7/24 上午 05:38 寫道:
On Mon, 2019-07-22 at 14:22 +0800, Ji-Ze Hong (Peter Hong) wrote:
This patch add support for Fintek PCIE to 2 CAN controller support
Signed-off-by: Ji-Ze Hong (Peter Hong)
---
Changelog:
v2:
1: Fix comment on the spinlock with write access.
2: Use ARRAY_SIZE instead of F81601_PCI_MAX_CHAN.
3: Check the strap pin outside the loop.
4: Fix the cleanup issue in f81601_pci_add_card().
5: Remove unused "channels" in struct f81601_pci_card.
drivers/net/can/sja1000/Kconfig | 8 ++
drivers/net/can/sja1000/Makefile | 1 +
drivers/net/can/sja1000/f81601.c | 215
+++
3 files changed, 224 insertions(+)
create mode 100644 drivers/net/can/sja1000/f81601.c
diff --git a/drivers/net/can/sja1000/Kconfig
b/drivers/net/can/sja1000/Kconfig
index f6dc89927ece..8588323c5138 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -101,4 +101,12 @@ config CAN_TSCAN1
IRQ numbers are read from jumpers JP4 and JP5,
SJA1000 IO base addresses are chosen heuristically (first
that works).
+config CAN_F81601
+ tristate "Fintek F81601 PCIE to 2 CAN Controller"
+ depends on PCI
+ help
+ This driver adds support for Fintek F81601 PCIE to 2 CAN
Controller.
+ It had internal 24MHz clock source, but it can be changed by
+ manufacturer. We can use modinfo to get usage for parameters.
+ Visit http://www.fintek.com.tw to get more information.
endif
diff --git a/drivers/net/can/sja1000/Makefile
b/drivers/net/can/sja1000/Makefile
index 9253aaf9e739..6f6268543bd9 100644
--- a/drivers/net/can/sja1000/Makefile
+++ b/drivers/net/can/sja1000/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_CAN_PEAK_PCMCIA) += peak_pcmcia.o
obj-$(CONFIG_CAN_PEAK_PCI) += peak_pci.o
obj-$(CONFIG_CAN_PLX_PCI) += plx_pci.o
obj-$(CONFIG_CAN_TSCAN1) += tscan1.o
+obj-$(CONFIG_CAN_F81601) += f81601.o
diff --git a/drivers/net/can/sja1000/f81601.c
b/drivers/net/can/sja1000/f81601.c
new file mode 100644
index ..3c378de8764d
--- /dev/null
+++ b/drivers/net/can/sja1000/f81601.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Fintek F81601 PCIE to 2 CAN controller driver
+ *
+ * Copyright (C) 2019 Peter Hong
+ * Copyright (C) 2019 Linux Foundation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sja1000.h"
+
+#define F81601_PCI_MAX_CHAN2
+
+#define F81601_DECODE_REG 0x209
+#define F81601_IO_MODE BIT(7)
+#define F81601_MEM_MODEBIT(6)
+#define F81601_CFG_MODEBIT(5)
+#define F81601_CAN2_INTERNAL_CLK BIT(3)
+#define F81601_CAN1_INTERNAL_CLK BIT(2)
+#define F81601_CAN2_EN BIT(1)
+#define F81601_CAN1_EN BIT(0)
+
+#define F81601_TRAP_REG0x20a
+#define F81601_CAN2_HAS_EN BIT(4)
+
+struct f81601_pci_card {
+ void __iomem *addr;
+ spinlock_t lock;/* use this spin lock only for write access
*/
+ struct pci_dev *dev;
+ struct net_device *net_dev[F81601_PCI_MAX_CHAN];
+};
+
+static const struct pci_device_id f81601_pci_tbl[] = {
+ { PCI_DEVICE(0x1c29, 0x1703) },
+ {},
+};
+
+MODULE_DEVICE_TABLE(pci, f81601_pci_tbl);
+
+static bool internal_clk = 1;
+module_param(internal_clk, bool, 0444);
+MODULE_PARM_DESC(internal_clk, "Use internal clock, default 1
(24MHz)");
+
+static unsigned int external_clk;
+module_param(external_clk, uint, 0444);
+MODULE_PARM_DESC(external_clk, "External Clock, must spec when
internal_clk = 0");
+
+static u8 f81601_pci_read_reg(const struct sja1000_priv *priv, int
port)
+{
+ return readb(priv->reg_base + port);
+}
+
+static void f81601_pci_write_reg(const struct sja1000_priv *priv,
int port,
+u8 val)
+{
+ struct f81601_pci_card *card = priv->priv;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ writeb(val, priv->reg_base + port);
+ readb(priv->reg_base);
+ spin_unlock_irqrestore(>lock, flags);
+}
+
+static void f81601_pci_del_card(struct pci_dev *pdev)
+{
+ struct f81601_pci_card *card = pci_get_drvdata(pdev);
+ struct net_device *dev;
+ int i = 0;
+
+ for (i = 0; i < ARRAY_SIZE(card->net_dev); i++) {
+ dev = card->net_dev[i];
+ if (!dev)
+ continue;
+
+ dev_info(>dev, "%s: Removing %s\n", __func__,
dev->name);
+
+ unregister_sja1000dev(dev);
+ free_sja1000dev(dev);
+ }
+
+ pcim_iounmap(pdev, card->addr);
+}
+
+/* Probe F81601 based device for the SJA1000 chips and register each
+ * available CAN channel to SJA1000 Socket-CAN subsystem.
+ */
+static int f81601_pci_add_card(struct pci_dev *pdev,
+
Re: [LKP] [SUNRPC] 0472e47660: fsmark.app_overhead 16.0% regression
On 7/12/2019 2:42 PM, Xing Zhengjun wrote:
Hi Trond,
I attached perf-profile part big changes, hope it is useful for
analyzing the issue.
Ping...
In testcase: fsmark
on test machine: 40 threads Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
with 384G memory
with following parameters:
iterations: 20x
nr_threads: 64t
disk: 1BRD_48G
fs: xfs
fs2: nfsv4
filesize: 4M
test_size: 80G
sync_method: fsyncBeforeClose
cpufreq_governor: performance
test-description: The fsmark is a file system benchmark to test
synchronous write workloads, for example, mail servers workload.
test-url: https://sourceforge.net/projects/fsmark/
commit:
e791f8e938 ("SUNRPC: Convert xs_send_kvec() to use iov_iter_kvec()")
0472e47660 ("SUNRPC: Convert socket page send code to use iov_iter()")
e791f8e9380d945e 0472e476604998c127f3c80d291
---
%stddev %change %stddev
\ | \
527.29 -22.6% 407.96 fsmark.files_per_sec
1.97 ± 11% +0.9 2.88 ± 4%
perf-profile.calltrace.cycles-pp.smp_apic_timer_interrupt.apic_timer_interrupt.cpuidle_enter_state.do_idle.cpu_startup_entry
0.00 +0.9 0.93 ± 4%
perf-profile.calltrace.cycles-pp.tcp_write_xmit.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.xs_sendpages
2.11 ± 10% +0.9 3.05 ± 4%
perf-profile.calltrace.cycles-pp.apic_timer_interrupt.cpuidle_enter_state.do_idle.cpu_startup_entry.start_secondary
5.29 ± 2% +1.2 6.46 ± 7%
perf-profile.calltrace.cycles-pp.svc_recv.nfsd.kthread.ret_from_fork
9.61 ± 5% +3.1 12.70 ± 2%
perf-profile.calltrace.cycles-pp.worker_thread.kthread.ret_from_fork
9.27 ± 5% +3.1 12.40 ± 2%
perf-profile.calltrace.cycles-pp.process_one_work.worker_thread.kthread.ret_from_fork
34.52 ± 4% +3.3 37.78 ± 2%
perf-profile.calltrace.cycles-pp.ret_from_fork
34.52 ± 4% +3.3 37.78 ± 2%
perf-profile.calltrace.cycles-pp.kthread.ret_from_fork
0.00 +3.4 3.41 ± 4%
perf-profile.calltrace.cycles-pp.memcpy_erms.memcpy_from_page._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg
0.00 +3.4 3.44 ± 4%
perf-profile.calltrace.cycles-pp.memcpy_from_page._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg
0.00 +3.5 3.54 ± 4%
perf-profile.calltrace.cycles-pp._copy_from_iter_full.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.xs_sendpages
2.30 ± 5% +3.7 6.02 ± 3%
perf-profile.calltrace.cycles-pp.__rpc_execute.rpc_async_schedule.process_one_work.worker_thread.kthread
2.30 ± 5% +3.7 6.02 ± 3%
perf-profile.calltrace.cycles-pp.rpc_async_schedule.process_one_work.worker_thread.kthread.ret_from_fork
1.81 ± 4% +3.8 5.59 ± 4%
perf-profile.calltrace.cycles-pp.call_transmit.__rpc_execute.rpc_async_schedule.process_one_work.worker_thread
1.80 ± 3% +3.8 5.59 ± 3%
perf-profile.calltrace.cycles-pp.xprt_transmit.call_transmit.__rpc_execute.rpc_async_schedule.process_one_work
1.73 ± 4% +3.8 5.54 ± 4%
perf-profile.calltrace.cycles-pp.xs_tcp_send_request.xprt_transmit.call_transmit.__rpc_execute.rpc_async_schedule
1.72 ± 4% +3.8 5.54 ± 4%
perf-profile.calltrace.cycles-pp.xs_sendpages.xs_tcp_send_request.xprt_transmit.call_transmit.__rpc_execute
0.00 +5.4 5.42 ± 4%
perf-profile.calltrace.cycles-pp.tcp_sendmsg_locked.tcp_sendmsg.sock_sendmsg.xs_sendpages.xs_tcp_send_request
0.00 +5.5 5.52 ± 4%
perf-profile.calltrace.cycles-pp.tcp_sendmsg.sock_sendmsg.xs_sendpages.xs_tcp_send_request.xprt_transmit
0.00 +5.5 5.53 ± 4%
perf-profile.calltrace.cycles-pp.sock_sendmsg.xs_sendpages.xs_tcp_send_request.xprt_transmit.call_transmit
9.61 ± 5% +3.1 12.70 ± 2%
perf-profile.children.cycles-pp.worker_thread
9.27 ± 5% +3.1 12.40 ± 2%
perf-profile.children.cycles-pp.process_one_work
6.19 +3.2 9.40 ± 4%
perf-profile.children.cycles-pp.memcpy_erms
34.53 ± 4% +3.3 37.78 ± 2%
perf-profile.children.cycles-pp.ret_from_fork
34.52 ± 4% +3.3 37.78 ± 2%
perf-profile.children.cycles-pp.kthread
0.00 +3.5 3.46 ± 4%
perf-profile.children.cycles-pp.memcpy_from_page
0.00 +3.6 3.56 ± 4%
perf-profile.children.cycles-pp._copy_from_iter_full
2.47 ± 4% +3.7 6.18 ± 3%
perf-profile.children.cycles-pp.__rpc_execute
2.30 ± 5% +3.7 6.02 ± 3%
perf-profile.children.cycles-pp.rpc_async_schedule
1.90 ± 4% +3.8 5.67 ± 3%
Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019
Subject: Great News: National Heart Center Singapore CT Coronary Calcium Score 18 July 2019 Good day from Singapore, This is good news for trillions and trillions of years to come! 1. My weight/mass is 123.5 kg (taken on 23 July 2019). 2. My height is 1.79 meters (taken on 23 July 2019). 3. My Body Mass Index (BMI) is 38.56 kg/m2 (as at 23 July 2019) 4. I have been living with random, intermittent, and chronic mild chest pain for the past 10 years since the year 2009. 5. I have seen countless (lost count) doctors in Singapore over the past 10 years. The diagnoses were always atypical chest pain (ie. nothing to do with the heart). All the doctors I have seen did not think it is angina pectoris. 6. I have done countless (lost count) cardiac tests in Singapore over the past 10 years, including electrocardiogram (ECG), treadmill stress test, MIBI heart perfusion test, and CT coronary angiogram. All the test results were either normal or perfect. 7. I have high cholesterol (hypercholesterolemia) for many years, according to doctors. 8. My pulse rate is consistently around 100 beats per minute for many years. 9. Recently, I went for CT coronary calcium scoring at National Heart Center Singapore (NHCS) on 18 July 2019. The following is a transcript of the CT coronary calcium scoring report obtained on 23 July 2019. -BEGIN NHCS CT Coronary Calcium Scoring Report 18 July 2019- National Heart Centre Singapore Patient Results Requested By: Chan Lihua Laura (Doctor) 23-Jul-2019 05:54 PM TURRITOPSIS DOHRNII TEO EN MING (ZHANG ENMING)Sex: M Age: 41yDOB: * MRN / Visit No.: * / H119042968E0003Locn: NHC-Cardiac Clinic B 18-Jul-2019 11:07 CT Coronary Calcium Scoring HCCT195011991718Final Additional Info Verified Date/Time: 18/07/2019 12:02 Final Verified Person: Dr. Narayan Lath Verified Section: NHC CT Performed at : National Heart Centre Singapore Level 5, 5D, 5 Hospital Drive Singapore 169609 CT Coronary Calcium Final Scoring HISTORY to reassess risk profile TECHNIQUE Calcium Scan was prospectively gated. Images were reconstructed at 3.0 mm slice thickness. Assessment was done using Vitrea Calcium software and Agatston scoring schema. REPORT Calcium Score: Agatston 0 , Volume score 0 mm3, LM 0 , RCA 0 , LAD 0 , LCX 0. The calcium score is between 0 th and 25 th percentile for [men between the ages of 40 and 44. Normal coronary origins. EXTRACARDIAC FINDINGS No incidental significant abnormalities in the included lungs or mediastinum. Report Indicator: Normal Finalised by:Narayan Lath, Senior Consultant, 12598I Finalised Date/Time: 18/07/2019 12:02 Report Link Final Printed from: National Heart Centre SingaporeEnd of Report Page: 1 of 1 -END NHCS CT Coronary Calcium Scoring Report 18 July 2019- For scanned image of the original CT coronary calcium scoring report from National Heart Center Singapore, please visit my RAID 1 mirroring redundant Blogger and Wordpress blogs at https://tdtemcerts.blogspot.sg https://tdtemcerts.wordpress.com On how to interpret CT Coronary Calcium Score, please visit the website of the Radiological Society of North America, Inc. (RSNA) at https://www.radiologyinfo.org/en/info.cfm?pg=ct_calscoring -BEGIN EMAIL SIGNATURE- The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming -END EMAIL SIGNATURE-
[PATCH] taskstats: Fix a typo - taskstsats --> taskstats
There is an extra 's' in 'taskstsats', remove it. Signed-off-by: Christophe JAILLET --- kernel/taskstats.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/taskstats.c b/kernel/taskstats.c index 13a0f2e6ebc2..30578b139d16 100644 --- a/kernel/taskstats.c +++ b/kernel/taskstats.c @@ -163,7 +163,7 @@ static void fill_stats(struct user_namespace *user_ns, memset(stats, 0, sizeof(*stats)); /* * Each accounting subsystem adds calls to its functions to -* fill in relevant parts of struct taskstsats as follows +* fill in relevant parts of struct taskstats as follows * * per-task-foo(stats, tsk); */ @@ -222,7 +222,7 @@ static int fill_stats_for_tgid(pid_t tgid, struct taskstats *stats) continue; /* * Accounting subsystem can call its functions here to -* fill in relevant parts of struct taskstsats as follows +* fill in relevant parts of struct taskstats as follows * * per-task-foo(stats, tsk); */ -- 2.20.1
Re: [PATCH v2 2/5] arm64: dts: qcom: sdm845: remove unnecessary properties for dsi nodes
On Wed, Jul 24, 2019 at 10:20 AM Vinod Koul wrote:
>
> We get a warning about unnecessary properties of
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2211.22-2257.6: Warning
> (avoid_unnecessary_addr_size): /soc/mdss@ae0/dsi@ae94000: unnecessary
> #address-cells/#size-cells without "ranges" or child "reg" property
> arch/arm64/boot/dts/qcom/sdm845.dtsi:2278.22-2324.6: Warning
> (avoid_unnecessary_addr_size): /soc/mdss@ae0/dsi@ae96000: unnecessary
> #address-cells/#size-cells without "ranges" or child "reg" property
>
> So, remove these properties
>
> Signed-off-by: Vinod Koul
> Reviewed-by: Stephen Boyd
Reviewed-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index e81f4a6d08ce..2985df032179 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -2234,9 +2234,6 @@
>
> status = "disabled";
>
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -2301,9 +2298,6 @@
>
> status = "disabled";
>
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.20.1
>
Re: [PATCH v2 1/5] arm64: dts: qcom: sdm845: Add unit name to soc node
On Wed, Jul 24, 2019 at 10:20 AM Vinod Koul wrote:
>
> We get a warning about missing unit name for soc node, so add it.
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
> (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit
> name
>
> Signed-off-by: Vinod Koul
> Reviewed-by: Stephen Boyd
Reviewed-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 601cfb078bd5..e81f4a6d08ce 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -620,7 +620,7 @@
> method = "smc";
> };
>
> - soc: soc {
> + soc: soc@0 {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0 0 0 0 0x10 0>;
> --
> 2.20.1
>
linux-next: Tree for Jul 24
Hi all, Changes since 20190723: The v4l-dvb tree lost its build failure. The keys tree gained a conflict against the afs tree. The devicetree tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 1806 1963 files changed, 153894 insertions(+), 30986 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 299 trees (counting Linus' and 72 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (ad5e427e0f6b Merge branch 'parisc-5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux) Merging fixes/master (c309b6f24222 Merge tag 'docs/v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging kbuild-current/fixes (5f9e832c1370 Linus 5.3-rc1) Merging arc-current/for-curr (24a20b0a443f ARC: [plat-hsdk]: Enable AXI DW DMAC in defconfig) Merging arm-current/fixes (c5d0e49e8d8f ARM: 8867/1: vdso: pass --be8 to linker if necessary) Merging arm-soc-fixes/arm/fixes (7bd9d465140a Merge tag 'imx-fixes-5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes) Merging arm64-fixes/for-next/fixes (40ca0ce56d4b arm64: entry: SP Alignment Fault doesn't write to FAR_EL1) Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire) Merging powerpc-fixes/fixes (3a855b7ac7d5 powerpc/papr_scm: Force a scm-unbind if initial scm-bind fails) Merging s390-fixes/fixes (9779048d71b1 s390/kasan: add bitops instrumentation) Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (d86afb89305d net: thunderx: Use fwnode_get_mac_address()) Merging bpf/master (decb705e01a5 libbpf: fix using uninitialized ioctl results) Merging ipsec/master (22d6552f827e xfrm interface: fix management of phydev) Merging netfilter/master (15a78ba1844a netfilter: ebtables: fix a memory leak bug in compat) Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes') Merging wireless-drivers/master (5f9e832c1370 Linus 5.3-rc1) Merging mac80211/master (d2b3fe42bc62 mac80211: don't warn about CW params when not using them) Merging rdma-fixes/for-rc (5f9e832c1370 Linus 5.3-rc1) Merging sound-current/for-linus (607975b30db4 ALSA: ac97: Fix double free of ac97_codec_device) Merging sound-asoc-fixes/for-linus (c12f7c23f7d6 Merge branch 'asoc-5.3' into asoc-linus) Merging regmap-fixes/for-linus (5f9e832c1370 Linus 5.3-rc1) Merging regulator-fixes/for-linus (5ea2148e305b Merge branch 'regulator-5.3' into regulator-linus) Merging spi-fixes/for-linus (29a603af8bc6 Merge branch 'spi-5.3' into spi-linus) Merging pci-current/for-linus (5f9e832c1370 Linus 5.3-rc1) Merging driver-core.current/driver-core-linus (5f9e832c1370 Linus 5.3-rc1) Merging tty.current/tty-linus (5f9e832c1370 Linus 5.3-rc1) Merging usb.current/usb-linus (5f9e832c1370 Linus 5.3-rc1) Merging usb-gadget-fixes/fixes (42de8afc40c9 usb: dwc2: Use generic PHY width in params setup) Merging usb-serial-fixes/usb-linus (f8377eff5481 USB: serial: ftdi_sio: add ID for isodebug v1) Merging usb-chipidea-fixes/ci-for-usb-stable (16009db47c51 usb: chipidea: udc: workaround for endpoint conflict issue) Merging phy
[PATCH] media: uvcvideo: Fix a typo in UVC_METATADA_BUF_SIZE
It is likely that it should be UVC_METADATA_BUF_SIZE instead.
Fix it and use it.
Signed-off-by: Christophe JAILLET
---
drivers/media/usb/uvc/uvc_metadata.c | 4 ++--
drivers/media/usb/uvc/uvc_queue.c| 2 +-
drivers/media/usb/uvc/uvcvideo.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_metadata.c
b/drivers/media/usb/uvc/uvc_metadata.c
index 99bb71b47117..b6279ad7ac84 100644
--- a/drivers/media/usb/uvc/uvc_metadata.c
+++ b/drivers/media/usb/uvc/uvc_metadata.c
@@ -51,7 +51,7 @@ static int uvc_meta_v4l2_get_format(struct file *file, void
*fh,
memset(fmt, 0, sizeof(*fmt));
fmt->dataformat = stream->meta.format;
- fmt->buffersize = UVC_METATADA_BUF_SIZE;
+ fmt->buffersize = UVC_METADATA_BUF_SIZE;
return 0;
}
@@ -72,7 +72,7 @@ static int uvc_meta_v4l2_try_format(struct file *file, void
*fh,
fmt->dataformat = fmeta == dev->info->meta_format
? fmeta : V4L2_META_FMT_UVC;
- fmt->buffersize = UVC_METATADA_BUF_SIZE;
+ fmt->buffersize = UVC_METADATA_BUF_SIZE;
return 0;
}
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index da72577c2998..cd60c6c1749e 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -79,7 +79,7 @@ static int uvc_queue_setup(struct vb2_queue *vq,
switch (vq->type) {
case V4L2_BUF_TYPE_META_CAPTURE:
- size = UVC_METATADA_BUF_SIZE;
+ size = UVC_METADATA_BUF_SIZE;
break;
default:
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index c7c1baa90dea..f773dc5d802c 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -491,7 +491,7 @@ struct uvc_stats_stream {
unsigned int max_sof; /* Maximum STC.SOF value */
};
-#define UVC_METATADA_BUF_SIZE 1024
+#define UVC_METADATA_BUF_SIZE 1024
/**
* struct uvc_copy_op: Context structure to schedule asynchronous memcpy
--
2.20.1
Re: [PATCH 3/4] locking/lockdep: Reduce space occupied by stack traces
On Mon, Jul 22, 2019 at 11:24:42AM -0700, Bart Van Assche wrote:
> Although commit 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys
> for workqueues") unregisters dynamic lockdep keys when a workqueue is
> destroyed, a side effect of that commit is that all stack traces
> associated with the lockdep key are leaked when a workqueue is destroyed.
> Fix this by storing each unique stack trace once. Other changes in this
> patch are:
> - Use NULL instead of { .nr_entries = 0 } to represent 'no trace'.
> - Store a pointer to a stack trace in struct lock_class and struct
> lock_list instead of storing 'nr_entries' and 'offset'.
>
> This patch avoids that the following program triggers the "BUG:
> MAX_STACK_TRACE_ENTRIES too low!" complaint:
Does this also fix any of the other bugs listed at
https://lore.kernel.org/lkml/20190710055838.GC2152@sol.localdomain/
?
BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
BUG: MAX_LOCKDEP_CHAINS too low!
BUG: MAX_LOCK_DEPTH too low! (2)
BUG: MAX_LOCKDEP_ENTRIES too low!
>
> #include
> #include
>
> int main()
> {
> for (;;) {
> int fd = open("/dev/infiniband/rdma_cm", O_RDWR);
> close(fd);
> }
> }
>
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Will Deacon
> Cc: Yuyang Du
> Cc: Waiman Long
> Reported-by: Eric Biggers
Can you please add:
Reported-by: syzbot+6f39a9deb697359fe...@syzkaller.appspotmail.com
Thanks,
- Eric
[PATCH v2 3/5] arm64: dts: qcom: sdm845: remove unit name for thermal trip points
The thermal trip points have unit name but no reg property, so we can remove them arch/arm64/boot/dts/qcom/sdm845.dtsi:2824.31-2828.7: Warning (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2830.31-2834.7: Warning (unit_address_vs_reg): /thermal-zones/cpu0-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2868.31-2872.7: Warning (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2874.31-2878.7: Warning (unit_address_vs_reg): /thermal-zones/cpu1-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2912.31-2916.7: Warning (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2918.31-2922.7: Warning (unit_address_vs_reg): /thermal-zones/cpu2-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2956.31-2960.7: Warning (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:2962.31-2966.7: Warning (unit_address_vs_reg): /thermal-zones/cpu3-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3000.31-3004.7: Warning (unit_address_vs_reg): /thermal-zones/cpu4-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3006.31-3010.7: Warning (unit_address_vs_reg): /thermal-zones/cpu4-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3044.31-3048.7: Warning (unit_address_vs_reg): /thermal-zones/cpu5-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3050.31-3054.7: Warning (unit_address_vs_reg): /thermal-zones/cpu5-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3088.31-3092.7: Warning (unit_address_vs_reg): /thermal-zones/cpu6-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3094.31-3098.7: Warning (unit_address_vs_reg): /thermal-zones/cpu6-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3132.31-3136.7: Warning (unit_address_vs_reg): /thermal-zones/cpu7-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3138.31-3142.7: Warning (unit_address_vs_reg): /thermal-zones/cpu7-thermal/trips/trip-point@1: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3176.32-3180.7: Warning (unit_address_vs_reg): /thermal-zones/aoss0-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3191.35-3195.7: Warning (unit_address_vs_reg): /thermal-zones/cluster0-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3211.35-3215.7: Warning (unit_address_vs_reg): /thermal-zones/cluster1-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3231.31-3235.7: Warning (unit_address_vs_reg): /thermal-zones/gpu-thermal-top/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3246.31-3250.7: Warning (unit_address_vs_reg): /thermal-zones/gpu-thermal-bottom/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3261.32-3265.7: Warning (unit_address_vs_reg): /thermal-zones/aoss1-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3276.35-3280.7: Warning (unit_address_vs_reg): /thermal-zones/q6-modem-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3291.30-3295.7: Warning (unit_address_vs_reg): /thermal-zones/mem-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3306.31-3310.7: Warning (unit_address_vs_reg): /thermal-zones/wlan-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3321.33-3325.7: Warning (unit_address_vs_reg): /thermal-zones/q6-hvx-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3336.33-3340.7: Warning (unit_address_vs_reg): /thermal-zones/camera-thermal/trips/trip-point@0: node has a unit name, but no reg property arch/arm64/boot/dts/qcom/sdm845.dtsi:3351.32-3355.7: Warning (unit_address_vs_reg): /thermal-zones/video-thermal/trips/trip-point@0:
[PATCH v2 5/5] arm64: dts: qcom: sdm845-cheza: remove macro from unit name
Unit address is supposed to be a number, using a macro with hex value is
not recommended, so add the value in unit name.
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:966.16-969.4: Warning
(unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4d: unit
name should not have leading "0x"
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:971.16-974.4: Warning
(unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4e: unit
name should not have leading "0x"
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:976.16-979.4: Warning
(unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x4f: unit
name should not have leading "0x"
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:981.16-984.4: Warning
(unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x50: unit
name should not have leading "0x"
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi:986.16-989.4: Warning
(unit_address_format): /soc@0/spmi@c44/pmic@0/adc@3100/adc-chan@0x51: unit
name should not have leading "0x"
Signed-off-by: Vinod Koul
Reviewed-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 1ebbd568dfd7..9b27b8346ba1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -963,27 +963,27 @@ ap_ts_i2c: {
};
_adc {
- adc-chan@ADC5_AMUX_THM1_100K_PU {
+ adc-chan@4d {
reg = ;
label = "sdm_temp";
};
- adc-chan@ADC5_AMUX_THM2_100K_PU {
+ adc-chan@4e {
reg = ;
label = "quiet_temp";
};
- adc-chan@ADC5_AMUX_THM3_100K_PU {
+ adc-chan@4f {
reg = ;
label = "lte_temp_1";
};
- adc-chan@ADC5_AMUX_THM4_100K_PU {
+ adc-chan@50 {
reg = ;
label = "lte_temp_2";
};
- adc-chan@ADC5_AMUX_THM5_100K_PU {
+ adc-chan@51 {
reg = ;
label = "charger_temp";
};
--
2.20.1
[PATCH v2 4/5] arm64: dts: qcom: sdm845: remove macro from unit name
Unit name is supposed to be a number, using a macro with hex value is
not recommended, so add the value in unit name.
arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning (unit_address_format):
/soc/spmi@c44/pmic@0/adc@3100/adc-chan@0x06: unit name should not have
leading "0x"
arch/arm64/boot/dts/qcom/pm8998.dtsi:81.18-84.6: Warning (unit_address_format):
/soc/spmi@c44/pmic@0/adc@3100/adc-chan@0x06: unit name should not have
leading 0s
Signed-off-by: Vinod Koul
---
arch/arm64/boot/dts/qcom/pm8998.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/pm8998.dtsi
b/arch/arm64/boot/dts/qcom/pm8998.dtsi
index 051a52df80f9..dc2ce23cde05 100644
--- a/arch/arm64/boot/dts/qcom/pm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8998.dtsi
@@ -78,7 +78,7 @@
#size-cells = <0>;
#io-channel-cells = <1>;
- adc-chan@ADC5_DIE_TEMP {
+ adc-chan@6 {
reg = ;
label = "die_temp";
};
--
2.20.1
[PATCH v2 0/5] arm64: dts: qcom: sdm845: Fix DTS warnings
So this is an attempt to fix some warns on sdm845 dts. We still have bunch of warnings to fix after this series (duplicate address and node names having underscores etc). Lets get long hanging ones fixed, we can see the warns with W=1 or W=2 Changes since v1: - Fix space after adc node unit address - Fix typo in commit log - Add review tags by Stephen Vinod Koul (5): arm64: dts: qcom: sdm845: Add unit name to soc node arm64: dts: qcom: sdm845: remove unnecessary properties for dsi nodes arm64: dts: qcom: sdm845: remove unit name for thermal trip points arm64: dts: qcom: sdm845: remove macro from unit name arm64: dts: qcom: sdm845-cheza: remove macro from unit name arch/arm64/boot/dts/qcom/pm8998.dtsi | 2 +- arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 10 ++-- arch/arm64/boot/dts/qcom/sdm845.dtsi | 66 ++ 3 files changed, 36 insertions(+), 42 deletions(-) -- 2.20.1
[PATCH v2 2/5] arm64: dts: qcom: sdm845: remove unnecessary properties for dsi nodes
We get a warning about unnecessary properties of
arch/arm64/boot/dts/qcom/sdm845.dtsi:2211.22-2257.6: Warning
(avoid_unnecessary_addr_size): /soc/mdss@ae0/dsi@ae94000: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
arch/arm64/boot/dts/qcom/sdm845.dtsi:2278.22-2324.6: Warning
(avoid_unnecessary_addr_size): /soc/mdss@ae0/dsi@ae96000: unnecessary
#address-cells/#size-cells without "ranges" or child "reg" property
So, remove these properties
Signed-off-by: Vinod Koul
Reviewed-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index e81f4a6d08ce..2985df032179 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2234,9 +2234,6 @@
status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
@@ -2301,9 +2298,6 @@
status = "disabled";
- #address-cells = <1>;
- #size-cells = <0>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.20.1
[PATCH v2 1/5] arm64: dts: qcom: sdm845: Add unit name to soc node
We get a warning about missing unit name for soc node, so add it.
arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
(unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
Signed-off-by: Vinod Koul
Reviewed-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 601cfb078bd5..e81f4a6d08ce 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -620,7 +620,7 @@
method = "smc";
};
- soc: soc {
+ soc: soc@0 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0 0 0 0 0x10 0>;
--
2.20.1
Re: linux-next: build warning after merge of the input-current tree
Hi Stephen,
at 07:54, Stephen Rothwell wrote:
Hi all,
After merging the input-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/input/mouse/elantech.c: In function 'elantech_use_host_notify':
drivers/input/mouse/elantech.c:1843:6: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if (dmi_get_bios_year() >= 2018)
^
drivers/input/mouse/elantech.c:1845:2: note: here
default:
^~~
Introduced by commit
883a2a80f79c ("Input: elantech - enable SMBus on new (2018+) systems")
I get these warnings because I am building with -Wimplicit-fallthrough
in attempt to catch new additions early. The gcc warning can be turned
off by adding a /* fall through */ comment at the point the fall through
happens (assuming that the fall through is intentional).
Yes the fall through is intentional.
Kai-Heng
--
Cheers,
Stephen Rothwell
Re: [PATCH AUTOSEL 5.2 039/249] signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig
Steve French writes:
> Very easy to see what caused the regression with this global change:
>
> mount (which launches "cifsd" thread to read the socket)
> umount (which kills the "cifsd" thread)
> rmmod (rmmod now fails since "cifsd" thread is still active)
>
> mount launches a thread to read from the socket ("cifsd")
> umount is supposed to kill that thread (but with the patch
> "signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of
> force_sig" that no longer works). So the regression is that after
> unmount you still see the "cifsd" thread, and the reason that cifsd
> thread is still around is that that patch no longer force kills the
> process (see line 2652 of fs/cifs/connect.c) which regresses module
> removal.
>
> - force_sig(SIGKILL, task);
> + send_sig(SIGKILL, task, 1);
>
> The comment in the changeset indicates "The signal SIGKILL can not be
> ignored" but obviously it can be ignored - at least on 5.3-rc1 it is
> being ignored.
>
> If send_sig(SIGKILL ...) doesn't work and if force_sig(SIGKILL, task)
> is removed and no longer possible - how do we kill a helper process
> ...
I think I see what is happening. It looks like as well as misuinsg
force_sig, cifs is also violating the invariant that keeps SIGKILL out
of the blocked signal set.
For that force_sig will act differently. I did not consider it because
that is never supposed to happen.
Can someone test this code below and confirm the issue goes away?
diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
index 5d6d44bfe10a..2a782ebc7b65 100644
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -347,6 +347,7 @@ __smb_send_rqst(struct TCP_Server_Info *server, int
num_rqst,
*/
sigfillset();
+ sigdelset(, SIGKILL);
sigprocmask(SIG_BLOCK, , );
/* Generate a rfc1002 marker for SMB2+ */
Eric
Re: WARNING in enqueue_task_dl
On Thu, Feb 07, 2019 at 10:35:04AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Mon, Jan 7, 2019 at 5:19 PM Daniel Bristot de Oliveira
> wrote:
> >
> > On 11/19/18 4:32 PM, Juri Lelli wrote:
> > > From 9326fd2b20269cffef7290bdc5b8173460d3c870 Mon Sep 17 00:00:00 2001
> > > From: Juri Lelli
> > > Date: Mon, 19 Nov 2018 16:04:42 +0100
> > > Subject: [PATCH] sched/core: Fix PI boosting between RT and DEADLINE
> > >
> > > syzbot reported the following warning:
> > >
> > > WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628
> > > enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> > > PM: Basic memory bitmaps freed
> > > Kernel panic - not syncing: panic_on_warn set ...
> > > CPU: 1 PID: 6351 Comm: syz-executor0 Not tainted 4.20.0-rc2+ #338
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > >__dump_stack lib/dump_stack.c:77 [inline]
> > >dump_stack+0x244/0x39d lib/dump_stack.c:113
> > >panic+0x2ad/0x55c kernel/panic.c:188
> > >__warn.cold.8+0x20/0x45 kernel/panic.c:540
> > >report_bug+0x254/0x2d0 lib/bug.c:186
> > >fixup_bug arch/x86/kernel/traps.c:178 [inline]
> > >do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
> > >do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
> > >invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
> > > RIP: 0010:enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504
> > > Code: ff 48 8b 8d c8 fe ff ff 48 c1 e6 2a 4c 8b 9d d0 fe ff ff 8b 95 d8
> > > fe
> > > ff ff 48 8b 85 e0 fe ff ff e9 16 e4 ff ff e8 16 d0 ea ff <0f> 0b e9 17 f1
> > > ff ff 48 8b bd e8 fe ff ff 4c 89 95 c8 fe ff ff 48
> > > RSP: 0018:8881ba39fa18 EFLAGS: 00010002
> > > RAX: RBX: 8881b9d6c000 RCX: 8881b9d6c278
> > > RDX: 8881b9d6c03c RSI: 0002 RDI: 8881daf2d710
> > > RBP: 8881ba39fb78 R08: 0001 R09: 8881daf0
> > > R10: 001a4d4f1987 R11: 8881daf2db3b R12: 111037473f4e
> > > R13: 8881b9d6c2cc R14: 8881daf2ccc0 R15: 8881daf2ccc0
> > >enqueue_task+0x184/0x390 kernel/sched/core.c:730
> > >__sched_setscheduler+0xe99/0x2190 kernel/sched/core.c:4336
> > >sched_setattr kernel/sched/core.c:4394 [inline]
> > >__do_sys_sched_setattr kernel/sched/core.c:4570 [inline]
> > >__se_sys_sched_setattr kernel/sched/core.c:4549 [inline]
> > >__x64_sys_sched_setattr+0x1b2/0x2f0 kernel/sched/core.c:4549
> > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > RIP: 0033:0x457569
> > > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89
> > > f7
> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > RSP: 002b:7f05ce0a2c78 EFLAGS: 0246 ORIG_RAX: 013a
> > > RAX: ffda RBX: 0003 RCX: 00457569
> > > RDX: RSI: 2000 RDI:
> > > RBP: 0072bfa0 R08: R09:
> > > R10: R11: 0246 R12: 7f05ce0a36d4
> > > R13: 004c369f R14: 004d5730 R15:
> > >
> > > At deadline.c:628 we have:
> > >
> > > 623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
> > > 624 {
> > > 625 struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
> > > 626 struct rq *rq = rq_of_dl_rq(dl_rq);
> > > 627
> > > 628 WARN_ON(dl_se->dl_boosted);
> > > 629 WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
> > > [...]
> > > }
> > >
> > > Which means that setup_new_dl_entity() has been called on a task
> > > currently boosted. This shouldn't happen though, as setup_new_
> > > dl_entity() is only called when the 'dynamic' deadline of the new entity
> > > is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this
> > > condition.
> > >
> > > Digging through PI code I noticed that what above might in fact happen
> > > if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the
> > > first branch of boosting conditions we check only if a pi_task 'dynamic'
> > > deadline is earlier than mutex holder's and in this case we set mutex
> > > holder to be dl_boosted. However, since RT 'dynamic' deadlines are only
> > > initialized if such tasks get boosted at some point (or if they become
> > > DEADLINE of course), in general RT 'dynamic' deadlines are usually equal
> > > to 0 and this verifies the aforementioned condition.
> > >
> > > Fix it by checking that the potential donor task is actually (even if
> > > temporary because in turn boosted) running at DEADLINE priority before
> > > using its 'dynamic' deadline value.
> > >
> > > Reported-by: syzbot+119ba87189432ead0...@syzkaller.appspotmail.com
> > > Signed-off-by: Juri Lelli
> >
> > Reviewed-by: Daniel Bristot de Oliveira
>
> What
[PATCH] net: fix semicolon.cocci warnings
From: kbuild test robot
drivers/target/iscsi/cxgbit/cxgbit_target.c:1451:47-48: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: d7840976e391 ("net: Use skb accessors in network drivers")
CC: Matthew Wilcox (Oracle)
Signed-off-by: kbuild test robot
---
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next.git
master
head: 3e3bb69589e482e0783f28d4cd1d8e56fda0bcbb
commit: d7840976e3915669382c62ddd1700960f348328e [7/33] net: Use skb accessors
in network drivers
cxgbit_target.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/target/iscsi/cxgbit/cxgbit_target.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_target.c
@@ -1448,7 +1448,7 @@ cxgbit_lro_skb_merge(struct cxgbit_sock
hpdu_cb->frags++;
hpdu_cb->hfrag_idx = hfrag_idx;
- len = skb_frag_size(>frags[hfrag_idx]);;
+ len = skb_frag_size(>frags[hfrag_idx]);
hskb->len += len;
hskb->data_len += len;
hskb->truesize += len;
Re: [PATCH v6 0/5] soc: qcom: Add SoC info driver
On 24-07-19, 04:05, Vaishali Thakkar wrote: > This patchset adds SoC info driver which can provide information > such as Chip ID, Chip family and serial number about Qualcomm SoCs > to user space via sysfs. Furthermore, it allows userspace to get > information about custom attributes and various image version > information via debugfs. > > The patchset cleanly applies on top of v5.2-rc7. And on v5.3-rc1 :) and I have tested this on db845c, seems to work fine for me Tested-by: Vinod Koul -- ~Vinod
Re: [PATCH v6 5/5] soc: qcom: socinfo: Expose image information
On 24-07-19, 04:05, Vaishali Thakkar wrote: > The socinfo driver provides information about version of the various > images loaded in the system. Expose this to user space for debugging > purpose. Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH v6 4/5] soc: qcom: socinfo: Expose custom attributes
On 24-07-19, 04:05, Vaishali Thakkar wrote: > The Qualcomm socinfo provides a number of additional attributes, > add these to the socinfo driver and expose them via debugfs > functionality. Reviewed-by: Vinod Koul -- ~Vinod
[PATCH 01/12] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: John Hubbard
Provide more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*() variant to call.
2. Christoph Hellwig's observation that set_page_dirty_lock()
is usually correct, and set_page_dirty() is usually a
bug, or at least questionable, within a put_user_page*()
calling chain.
This leads to the following API choices:
* put_user_pages_dirty_lock(page, npages, make_dirty)
* There is no put_user_pages_dirty(). You have to
hand code that, in the rare case that it's
required.
Cc: Matthew Wilcox
Cc: Jan Kara
Cc: Christoph Hellwig
Cc: Ira Weiny
Cc: Jason Gunthorpe
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 5 +-
drivers/infiniband/hw/hfi1/user_pages.c| 5 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 5 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 5 +-
drivers/infiniband/sw/siw/siw_mem.c| 8 +-
include/linux/mm.h | 5 +-
mm/gup.c | 115 +
7 files changed, 58 insertions(+), 90 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 08da840ed7ee..965cf9dea71a 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -54,10 +54,7 @@ static void __ib_umem_release(struct ib_device *dev, struct
ib_umem *umem, int d
for_each_sg_page(umem->sg_head.sgl, _iter, umem->sg_nents, 0) {
page = sg_page_iter_page(_iter);
- if (umem->writable && dirty)
- put_user_pages_dirty_lock(, 1);
- else
- put_user_page(page);
+ put_user_pages_dirty_lock(, 1, umem->writable && dirty);
}
sg_free_table(>sg_head);
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index b89a9b9aef7a..469acb961fbd 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -118,10 +118,7 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned
long vaddr, size_t np
void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
size_t npages, bool dirty)
{
- if (dirty)
- put_user_pages_dirty_lock(p, npages);
- else
- put_user_pages(p, npages);
+ put_user_pages_dirty_lock(p, npages, dirty);
if (mm) { /* during close after signal, mm can be NULL */
atomic64_sub(npages, >pinned_vm);
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index bfbfbb7e0ff4..6bf764e41891 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -40,10 +40,7 @@
static void __qib_release_user_pages(struct page **p, size_t num_pages,
int dirty)
{
- if (dirty)
- put_user_pages_dirty_lock(p, num_pages);
- else
- put_user_pages(p, num_pages);
+ put_user_pages_dirty_lock(p, num_pages, dirty);
}
/**
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 0b0237d41613..62e6ffa9ad78 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -75,10 +75,7 @@ static void usnic_uiom_put_pages(struct list_head
*chunk_list, int dirty)
for_each_sg(chunk->page_list, sg, chunk->nents, i) {
page = sg_page(sg);
pa = sg_phys(sg);
- if (dirty)
- put_user_pages_dirty_lock(, 1);
- else
- put_user_page(page);
+ put_user_pages_dirty_lock(, 1, dirty);
usnic_dbg("pa: %pa\n", );
}
kfree(chunk);
diff --git a/drivers/infiniband/sw/siw/siw_mem.c
b/drivers/infiniband/sw/siw/siw_mem.c
index 67171c82b0c4..358d440efa11 100644
--- a/drivers/infiniband/sw/siw/siw_mem.c
+++ b/drivers/infiniband/sw/siw/siw_mem.c
@@ -65,13 +65,7 @@ static void siw_free_plist(struct siw_page_chunk *chunk, int
num_pages,
{
struct page **p = chunk->plist;
- while (num_pages--) {
- if (!PageDirty(*p) && dirty)
- put_user_pages_dirty_lock(p, 1);
- else
- put_user_page(*p);
- p++;
- }
+ put_user_pages_dirty_lock(chunk->plist, num_pages, dirty);
}
void siw_umem_release(struct siw_umem *umem, bool dirty)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..9759b6a24420 100644
--- a/include/linux/mm.h
+++
Re: [PATCH v6 3/5] soc: qcom: Add socinfo driver
On 24-07-19, 04:05, Vaishali Thakkar wrote: > From: Imran Khan > > The Qualcomm socinfo driver exposes information about the SoC, its > version and its serial number to user space. Reviewed-by: Vinod Koul -- ~Vinod
Re: [PATCH v6 1/5] base: soc: Add serial_number attribute to soc
On 24-07-19, 04:05, Vaishali Thakkar wrote: > From: Bjorn Andersson > > Add new attribute named "serial_number" as a standard interface for > user space to acquire the serial number of the device. > > For ST-Ericsson SoCs this is exposed by the cryptically named "soc_id" > attribute, but this provides a human readable standardized name for this > property. Reviewed-by: Vinod Koul -- ~Vinod
[PATCH] x86/entry/32: pass cr2 to do_async_page_fault
Commit a0d14b8909de ("x86/mm, tracing: Fix CR2 corruption") added the
address parameter to do_async_page_fault, but does not pass it from the
32-bit entry point. To plumb it through, factor-out
common_exception_read_cr2 in the same fashion as common_exception, and
uses it from both page_fault and async_page_fault.
For a 32-bit KVM guest, this fixes:
[1.148669][T1] Run /sbin/init as init process
[1.153328][T1] Starting init: /sbin/init exists but couldn't execute it
(error -14)
Fixes: a0d14b8909de ("x86/mm, tracing: Fix CR2 corruption")
Signed-off-by: Matt Mullins
---
arch/x86/entry/entry_32.S | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 2bb986f305ac..4f86928246e7 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -1443,8 +1443,12 @@ BUILD_INTERRUPT3(hv_stimer0_callback_vector,
HYPERV_STIMER0_VECTOR,
ENTRY(page_fault)
ASM_CLAC
- pushl $0; /* %gs's slot on the stack */
+ pushl $do_page_fault
+ jmp common_exception_read_cr2
+END(page_fault)
+common_exception_read_cr2:
+ /* the function address is in %gs's slot on the stack */
SAVE_ALL switch_stacks=1 skip_gs=1
ENCODE_FRAME_POINTER
@@ -1452,6 +1456,7 @@ ENTRY(page_fault)
/* fixup %gs */
GS_TO_REG %ecx
+ movlPT_GS(%esp), %edi
REG_TO_PTGS %ecx
SET_KERNEL_GS %ecx
@@ -1463,9 +1468,9 @@ ENTRY(page_fault)
TRACE_IRQS_OFF
movl%esp, %eax # pt_regs pointer
- calldo_page_fault
+ CALL_NOSPEC %edi
jmp ret_from_exception
-END(page_fault)
+END(common_exception_read_cr2)
common_exception:
/* the function address is in %gs's slot on the stack */
@@ -1595,7 +1600,7 @@ END(general_protection)
ENTRY(async_page_fault)
ASM_CLAC
pushl $do_async_page_fault
- jmp common_exception
+ jmp common_exception_read_cr2
END(async_page_fault)
#endif
--
2.17.1
[PATCH] x86/crash: remove unnecessary comparison
This ret comparison and return are unnecessary as of
f296f2634920d205b93d878b48d87bb7e0a4c256
elf_header_exclude_ranges() returns ret in any case, with or
without this comparison.
Signed-off-by: Nikolas Nyby
---
arch/x86/kernel/crash.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 2bf70a2fed90..eb651fbde92a 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -225,8 +225,6 @@ static int elf_header_exclude_ranges(struct crash_mem *cmem)
if (crashk_low_res.end) {
ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
crashk_low_res.end);
- if (ret)
- return ret;
}
return ret;
--
2.20.1
Re: [PATCH 1/5] arm64: dts: qcom: sdm845: Add unit name to soc node
On 23-07-19, 07:50, Stephen Boyd wrote:
> Quoting Vinod Koul (2019-07-22 05:34:18)
> > We get a warning about missing unit name for soc node, so add it.
> >
> > arch/arm64/boot/dts/qcom/sdm845.dtsi:623.11-2814.4: Warning
> > (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit
> > name
> >
> > Signed-off-by: Vinod Koul
> > ---
>
> Reviewed-by: Stephen Boyd
Thanks for the review
>
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 601cfb078bd5..e81f4a6d08ce 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -620,7 +620,7 @@
> > method = "smc";
> > };
> >
> > - soc: soc {
> > + soc: soc@0 {
>
> This is kinda sad, but ok. Maybe you can apply this fix to at least all
> the qcom boards then.
Yeah that is the idea, start with sdm845 and 'reduce' the warns on all
qcom dts files
--
~Vinod
Re: [PATCH] mbcache: Speed up cache entry creation
On Tue, Jul 23, 2019 at 10:56:05AM -0600, Andreas Dilger wrote:
> Do you have any kind of performance metrics that show this is an actual
> improvement in performance? This would be either macro-level benchmarks
> (e.g. fio, but this seems unlikely to show any benefit), or micro-level
> measurements (e.g. flame graph) that show a net reduction in CPU cycles,
> lock contention, etc. in this part of the code.
Hi Andreas,
Here are some basic micro-benchmark results:
Before:
[3.162896] mb_cache_entry_create: AVG cycles: 75
[3.054701] mb_cache_entry_create: AVG cycles: 78
[3.152321] mb_cache_entry_create: AVG cycles: 77
After:
[3.043380] mb_cache_entry_create: AVG cycles: 68
[3.194321] mb_cache_entry_create: AVG cycles: 71
[3.038100] mb_cache_entry_create: AVG cycles: 69
The performance difference is probably more drastic when free memory is low,
since an unnecessary call to kmem_cache_alloc() can result in a long wait for
pages to be freed.
The micro-benchmark code is attached.
Thanks,
Sultan
---
diff --git a/fs/mbcache.c b/fs/mbcache.c
index 289f3664061e..e0f22ff8fab8 100644
--- a/fs/mbcache.c
+++ b/fs/mbcache.c
@@ -82,7 +82,7 @@ static inline struct mb_bucket *mb_cache_entry_bucket(struct
mb_cache *cache,
* -EBUSY if entry with the same key and value already exists in cache.
* Otherwise 0 is returned.
*/
-int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
+static int __mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
u64 value, bool reusable)
{
struct mb_cache_entry *entry, *dup;
@@ -148,6 +148,29 @@ int mb_cache_entry_create(struct mb_cache *cache, gfp_t
mask, u32 key,
return 0;
}
+
+int mb_cache_entry_create(struct mb_cache *cache, gfp_t mask, u32 key,
+ u64 value, bool reusable)
+{
+ static unsigned long count, sum;
+ static DEFINE_MUTEX(lock);
+ volatile cycles_t start, delta;
+ int ret;
+
+ mutex_lock();
+ local_irq_disable();
+ start = get_cycles();
+ ret = __mb_cache_entry_create(cache, mask, key, value, reusable);
+ delta = get_cycles() - start;
+ local_irq_enable();
+
+ sum += delta;
+ if (++count == 1000)
+ printk("%s: AVG cycles: %lu\n", __func__, sum / count);
+ mutex_unlock();
+
+ return ret;
+}
EXPORT_SYMBOL(mb_cache_entry_create);
void __mb_cache_entry_free(struct mb_cache_entry *entry)
Re: [PATCH v2] RDMA/hns: Fix build error for hip06
Pls ignore this, I will fix it.
On 2019/7/24 11:44, YueHaibing wrote:
> If INFINIBAND_HNS_HIP06 is selected and HNS_DSAF
> is m, but INFINIBAND_HNS is y, building fails:
>
> drivers/infiniband/hw/hns/hns_roce_hw_v1.o: In function `hns_roce_v1_reset':
> hns_roce_hw_v1.c:(.text+0x39fa): undefined reference to `hns_dsaf_roce_reset'
> hns_roce_hw_v1.c:(.text+0x3a25): undefined reference to `hns_dsaf_roce_reset'
>
> Reported-by: Hulk Robot
> Fixes: 08805fdbeb2d ("RDMA/hns: Split hw v1 driver from hns roce driver")
> Signed-off-by: YueHaibing
> ---
> v2: use select instead of depends
> ---
> drivers/infiniband/hw/hns/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/hns/Kconfig
> b/drivers/infiniband/hw/hns/Kconfig
> index b9dfac0..5f6d750 100644
> --- a/drivers/infiniband/hw/hns/Kconfig
> +++ b/drivers/infiniband/hw/hns/Kconfig
> @@ -12,7 +12,8 @@ config INFINIBAND_HNS
>
> config INFINIBAND_HNS_HIP06
> bool "Hisilicon Hip06 Family RoCE support"
> - depends on INFINIBAND_HNS && HNS && HNS_DSAF && HNS_ENET
> + depends on INFINIBAND_HNS && HNS && HNS_ENET
> + select HNS_DSAF
> ---help---
> RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip06 and
> Hip07 SoC. These RoCE engines are platform devices.
>
[PATCH resend v2] lib: scatterlist: Fix to support no mapped sg
In function sg_split, the second sg_calculate_split will return -EINVAL
when in_mapped_nents is 0.
Indeed there is no need to do second sg_calculate_split and sg_split_mapped
when in_mapped_nents is 0, as in_mapped_nents indicates no mapped entry in
original sgl.
Signed-off-by: Zhou Wang
Acked-by: Robert Jarzmik
---
v2: Just add Acked-by from Robert.
lib/sg_split.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/sg_split.c b/lib/sg_split.c
index 9982c63..60a0bab 100644
--- a/lib/sg_split.c
+++ b/lib/sg_split.c
@@ -176,11 +176,13 @@ int sg_split(struct scatterlist *in, const int
in_mapped_nents,
* The order of these 3 calls is important and should be kept.
*/
sg_split_phys(splitters, nb_splits);
- ret = sg_calculate_split(in, in_mapped_nents, nb_splits, skip,
-split_sizes, splitters, true);
- if (ret < 0)
- goto err;
- sg_split_mapped(splitters, nb_splits);
+ if (in_mapped_nents) {
+ ret = sg_calculate_split(in, in_mapped_nents, nb_splits, skip,
+split_sizes, splitters, true);
+ if (ret < 0)
+ goto err;
+ sg_split_mapped(splitters, nb_splits);
+ }
for (i = 0; i < nb_splits; i++) {
out[i] = splitters[i].out_sg;
--
2.8.1
Reminder: 3 open syzbot bugs in isdn subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the isdn subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 1 was seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the isdn subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KMSAN: uninit-value in capi_write Last occurred: 1 day ago Reported: 162 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=1075c8d832330e876cad2c8c6872323f5211bc31 Original thread: https://lkml.kernel.org/lkml/0e35f00581a57...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+0849c524d9c634f5a...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/0e35f00581a57...@google.com Title: KASAN: use-after-free Read in dev_expire_timer Last occurred: 168 days ago Reported: 202 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=a520c896ffb4fbc8539cda4c0bb6fe48995defd7 Original thread: https://lkml.kernel.org/lkml/a317f3057e766...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+7ea31f54ecacb8f68...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/a317f3057e766...@google.com Title: BUG: spinlock bad magic in flush_workqueue_prep_pwqs Last occurred: 144 days ago Reported: 143 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=cbd7a891bd8268f9eb68dfd1f3551670b4ccb412 Original thread: https://lkml.kernel.org/lkml/9e31600583172...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+130f0c441448a93a1...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/9e31600583172...@google.com
[PATCH] net: dsa: Check existence of .port_mdb_add callback before calling it
From: Chen-Yu Tsai
With the recent addition of commit 75dad2520fc3 ("net: dsa: b53: Disable
all ports on setup"), users of b53 (BCM53125 on Lamobo R1 in my case)
are forced to use the dsa subsystem to enable the switch, instead of
having it in the default transparent "forward-to-all" mode.
The b53 driver does not support mdb bitmap functions. However the dsa
layer does not check for the existence of the .port_mdb_add callback
before actually using it. This results in a NULL pointer dereference,
as shown in the kernel oops below.
The other functions seem to be properly guarded. Do the same for
.port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
b53 is not the only driver that doesn't support mdb bitmap functions.
Others include bcm_sf2, dsa_loop, lantiq_gswip, mt7530, mv88e6060,
qca8k, realtek-smi, and vitesse-vsc73xx.
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address
pgd = (ptrval)
[] *pgd=
Internal error: Oops: 8005 [#1] SMP ARM
Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common rtlwifi
mac80211 cfg80211
CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted 5.3.0-rc1-00247-gd3519030752a
#1
Hardware name: Allwinner sun7i (A20) Family
Workqueue: events switchdev_deferred_process_work
PC is at 0x0
LR is at dsa_switch_event+0x570/0x620
pc : [<>]lr : []psr: 80070013
sp : ee871db8 ip : fp : ee98d0a4
r10: 000c r9 : 0008 r8 : ee89f710
r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
r3 : r2 : ee89f710 r1 : 0008 r0 : ee98d040
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6deb406a DAC: 0051
Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
Stack: (0xee871db8 to 0xee872000)
1da0: ee871e14
103ace2d
1dc0: ee871e14 0005 c08524a0
1de0: e000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120
c014bef0
1e00: b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb
1e20: 0008 103ace2d c087e248 ee29c868 103ace2d 0001
1e40: ee871e98 0006 c0fb2a50 c087e2d0
c08523c4
1e60: c014bdfc 0006 c0fad2d0 ee871e98 ee89f710
c014c500
1e80: ee89f3c0 c0f04c48 ee9e5000 c087dfb4 ee9e5000
1ea0: ee89f710 ee871ecb 0001 103ace2d c0f04c48
c087e0a8
1ec0: efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000
0122
1ee0: 0100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000
c0fad2ec
1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 c087def8 c0fad2ec
c01447dc
1f20: ef315640 ef7a62c0 0008 ee839580 ee839594 ef7a62c0 0008
c0f03d00
1f40: ef7a62d8 ef7a62c0 e000 c0145b84 e000 c0fb2420 c0bfaa8c
1f60: e000 ee84b600 ee84b5c0 ee87 ee839580 c0145b40
ef0e5ea4
1f80: ee84b61c c014a6f8 0001 ee84b5c0 c014a5b0
1fa0: c01010e8
1fc0:
1fe0: 0013
[] (dsa_switch_event) from []
(notifier_call_chain+0x48/0x84)
[] (notifier_call_chain) from []
(raw_notifier_call_chain+0x18/0x20)
[] (raw_notifier_call_chain) from []
(dsa_port_mdb_add+0x48/0x74)
[] (dsa_port_mdb_add) from []
(__switchdev_handle_port_obj_add+0x54/0xd4)
[] (__switchdev_handle_port_obj_add) from []
(switchdev_handle_port_obj_add+0x8/0x14)
[] (switchdev_handle_port_obj_add) from []
(dsa_slave_switchdev_blocking_event+0x94/0xa4)
[] (dsa_slave_switchdev_blocking_event) from []
(notifier_call_chain+0x48/0x84)
[] (notifier_call_chain) from []
(blocking_notifier_call_chain+0x50/0x68)
[] (blocking_notifier_call_chain) from []
(switchdev_port_obj_notify+0x44/0xa8)
[] (switchdev_port_obj_notify) from []
(switchdev_port_obj_add_now+0x90/0x104)
[] (switchdev_port_obj_add_now) from []
(switchdev_port_obj_add_deferred+0x14/0x5c)
[] (switchdev_port_obj_add_deferred) from []
(switchdev_deferred_process+0x64/0x104)
[] (switchdev_deferred_process) from []
(switchdev_deferred_process_work+0xc/0x14)
[] (switchdev_deferred_process_work) from []
(process_one_work+0x218/0x50c)
[] (process_one_work) from [] (worker_thread+0x44/0x5bc)
[] (worker_thread) from [] (kthread+0x148/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xee871fb0 to 0xee871ff8)
1fa0:
1fc0:
1fe0:
[PATCH v2] RDMA/hns: Fix build error for hip06
If INFINIBAND_HNS_HIP06 is selected and HNS_DSAF
is m, but INFINIBAND_HNS is y, building fails:
drivers/infiniband/hw/hns/hns_roce_hw_v1.o: In function `hns_roce_v1_reset':
hns_roce_hw_v1.c:(.text+0x39fa): undefined reference to `hns_dsaf_roce_reset'
hns_roce_hw_v1.c:(.text+0x3a25): undefined reference to `hns_dsaf_roce_reset'
Reported-by: Hulk Robot
Fixes: 08805fdbeb2d ("RDMA/hns: Split hw v1 driver from hns roce driver")
Signed-off-by: YueHaibing
---
v2: use select instead of depends
---
drivers/infiniband/hw/hns/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hns/Kconfig
b/drivers/infiniband/hw/hns/Kconfig
index b9dfac0..5f6d750 100644
--- a/drivers/infiniband/hw/hns/Kconfig
+++ b/drivers/infiniband/hw/hns/Kconfig
@@ -12,7 +12,8 @@ config INFINIBAND_HNS
config INFINIBAND_HNS_HIP06
bool "Hisilicon Hip06 Family RoCE support"
- depends on INFINIBAND_HNS && HNS && HNS_DSAF && HNS_ENET
+ depends on INFINIBAND_HNS && HNS && HNS_ENET
+ select HNS_DSAF
---help---
RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip06 and
Hip07 SoC. These RoCE engines are platform devices.
--
2.7.4
[PATCH v2] RDMA/hns: Fix build error for hip08
If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
but INFINIBAND_HNS is y, building fails:
drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_exit':
hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to
`hnae3_unregister_client'
drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_init':
hns_roce_hw_v2.c:(.init.text+0xd): undefined reference to
`hnae3_register_client'
Reported-by: Hulk Robot
Suggested-by: Leon Romanovsky
Fixes: dd74282df573 ("RDMA/hns: Initialize the PCI device for hip08 RoCE")
Signed-off-by: YueHaibing
---
v2: select HNS3 to fix this
---
drivers/infiniband/hw/hns/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hns/Kconfig
b/drivers/infiniband/hw/hns/Kconfig
index 8bf847b..b9dfac0 100644
--- a/drivers/infiniband/hw/hns/Kconfig
+++ b/drivers/infiniband/hw/hns/Kconfig
@@ -22,7 +22,8 @@ config INFINIBAND_HNS_HIP06
config INFINIBAND_HNS_HIP08
bool "Hisilicon Hip08 Family RoCE support"
- depends on INFINIBAND_HNS && PCI && HNS3
+ depends on INFINIBAND_HNS && PCI
+ select HNS3
---help---
RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip08 SoC.
The RoCE engine is a PCI device.
--
2.7.4
Re: [PATCH AUTOSEL 5.2 039/249] signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig
Steve French writes:
> I did some additional testing and it looks like the "allow_signal"
> change may be safe enough
>
> # git diff -a
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index a4830ced0f98..a15a6e738eb5 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -1113,6 +1113,7 @@ cifs_demultiplex_thread(void *p)
> mempool_resize(cifs_req_poolp, length + cifs_min_rcv);
>
> set_freezable();
> + allow_signal(SIGKILL);
> while (server->tcpStatus != CifsExiting) {
> if (try_to_freeze())
> continue;
>
> See below:
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# insmod ./cifs.ko
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# mount -t cifs
> //localhost/scratch /mnt -o username=sfrench
> Password for sfrench@//localhost/scratch:
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# ps -A | grep cifsd
> 5176 ?00:00:00 cifsd
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# kill -9 5176
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# ls /mnt
> 0444 dir0750 dir0754 newfile
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# umount /mnt
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# ps -A | grep cifsd
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# rmmod cifs
Yes. I just discovered that kthreadd calls a function named
ignore_signals that set all signals to SIG_IGN. Which becomes
the default for all kernel threads. So something like allow_signal
to change the signal handler is necessary. The blocking of SIGKILL is
also concerning but apparently that is not the issue here.
Ideally I think cifs should use kthread_stop, instead of signals for
this purpose. The logic is convoluted enough that reading through the
cifs code quickly I don't see how sending SIGKILL to the daemon causes
it to stop.
Eric
> On Tue, Jul 23, 2019 at 9:19 PM Steve French wrote:
>>
>> Pavel noticed I missed a line from the attempt to do a similar patch
>> to Eric's suggestion
>> (it still didn't work though - although "allow_signal" does albeit is
>> possibly dangerous as user space can kill cifsd)
>>
>> # git diff -a
>> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
>> index a4830ced0f98..8758dff18c15 100644
>> --- a/fs/cifs/connect.c
>> +++ b/fs/cifs/connect.c
>> @@ -1104,6 +1104,7 @@ cifs_demultiplex_thread(void *p)
>> struct task_struct *task_to_wake = NULL;
>> struct mid_q_entry *mids[MAX_COMPOUND];
>> char *bufs[MAX_COMPOUND];
>> + sigset_t mask, oldmask;
>>
>> current->flags |= PF_MEMALLOC;
>> cifs_dbg(FYI, "Demultiplex PID: %d\n", task_pid_nr(current));
>> @@ -1113,6 +1114,9 @@ cifs_demultiplex_thread(void *p)
>> mempool_resize(cifs_req_poolp, length + cifs_min_rcv);
>>
>> set_freezable();
>> + sigfillset();
>> + sigdelset(, SIGKILL);
>> + sigprocmask(SIG_BLOCK, , );
>> while (server->tcpStatus != CifsExiting) {
>> if (try_to_freeze())
>> continue;
>>
>> On Tue, Jul 23, 2019 at 9:02 PM Steve French wrote:
>> >
>> > On Tue, Jul 23, 2019 at 8:32 PM Eric W. Biederman
>> > wrote:
>> > >
>> > > Steve French writes:
>> > >
>> > > > Very easy to see what caused the regression with this global change:
>> > > >
>> > > > mount (which launches "cifsd" thread to read the socket)
>> > > > umount (which kills the "cifsd" thread)
>> > > > rmmod (rmmod now fails since "cifsd" thread is still active)
>> > > >
>> > > > mount launches a thread to read from the socket ("cifsd")
>> > > > umount is supposed to kill that thread (but with the patch
>> > > > "signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of
>> > > > force_sig" that no longer works). So the regression is that after
>> > > > unmount you still see the "cifsd" thread, and the reason that cifsd
>> > > > thread is still around is that that patch no longer force kills the
>> > > > process (see line 2652 of fs/cifs/connect.c) which regresses module
>> > > > removal.
>> > > >
>> > > > - force_sig(SIGKILL, task);
>> > > > + send_sig(SIGKILL, task, 1);
>> > > >
>> > > > The comment in the changeset indicates "The signal SIGKILL can not be
>> > > > ignored" but obviously it can be ignored - at least on 5.3-rc1 it is
>> > > > being ignored.
>> > > >
>> > > > If send_sig(SIGKILL ...) doesn't work and if force_sig(SIGKILL, task)
>> > > > is removed and no longer possible - how do we kill a helper process
>> > > > ...
>> > >
>> > > I think I see what is happening. It looks like as well as misuinsg
>> > > force_sig, cifs is also violating the invariant that keeps SIGKILL out
>> > > of the blocked signal set.
>> > >
>> > > For that force_sig will act differently. I did not consider it because
>> > > that is never supposed to happen.
>> > >
>> > > Can someone test this code below and confirm the issue goes away?
>> > >
>> > > diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
>> > > index 5d6d44bfe10a..2a782ebc7b65 100644
>>
From: Mr.Ahmed Muzashah,
Good Day, I am Mr.Ahmed Muzashah, account Manager with an investment bank here in Burkina Faso. There is a draft account opened in my firm by a long-time client of our bank.I have the opportunity of transferring the left over fund (15.8 Million UsDollars)Fiftheen Million Eight Hundred Thousand United States of American Dollars. I want to invest this funds and introduce you to our bank for this deal and this will be executed under a legitimate arrangement that will protect us from any breach of the law.We will share the fund 40% for you,50% for me while 10% is for establishing of foundation for the poor children in your country.If you are really interested in my proposal further details of the fund transfer will be forwarded to you. Yours Sincerely, Mr.Ahmed Muzashah.
Re: [PATCH AUTOSEL 5.2 039/249] signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig
Patch attached - tests out ok.
On Tue, Jul 23, 2019 at 9:28 PM Steve French wrote:
>
> I did some additional testing and it looks like the "allow_signal"
> change may be safe enough
>
> # git diff -a
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index a4830ced0f98..a15a6e738eb5 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -1113,6 +1113,7 @@ cifs_demultiplex_thread(void *p)
> mempool_resize(cifs_req_poolp, length + cifs_min_rcv);
>
> set_freezable();
> + allow_signal(SIGKILL);
> while (server->tcpStatus != CifsExiting) {
> if (try_to_freeze())
> continue;
>
> See below:
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# insmod ./cifs.ko
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# mount -t cifs
> //localhost/scratch /mnt -o username=sfrench
> Password for sfrench@//localhost/scratch:
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# ps -A | grep cifsd
> 5176 ?00:00:00 cifsd
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# kill -9 5176
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# ls /mnt
> 0444 dir0750 dir0754 newfile
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# umount /mnt
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# ps -A | grep cifsd
> root@smf-Thinkpad-P51:~/cifs-2.6/fs/cifs# rmmod cifs
>
> On Tue, Jul 23, 2019 at 9:19 PM Steve French wrote:
> >
> > Pavel noticed I missed a line from the attempt to do a similar patch
> > to Eric's suggestion
> > (it still didn't work though - although "allow_signal" does albeit is
> > possibly dangerous as user space can kill cifsd)
> >
> > # git diff -a
> > diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> > index a4830ced0f98..8758dff18c15 100644
> > --- a/fs/cifs/connect.c
> > +++ b/fs/cifs/connect.c
> > @@ -1104,6 +1104,7 @@ cifs_demultiplex_thread(void *p)
> > struct task_struct *task_to_wake = NULL;
> > struct mid_q_entry *mids[MAX_COMPOUND];
> > char *bufs[MAX_COMPOUND];
> > + sigset_t mask, oldmask;
> >
> > current->flags |= PF_MEMALLOC;
> > cifs_dbg(FYI, "Demultiplex PID: %d\n", task_pid_nr(current));
> > @@ -1113,6 +1114,9 @@ cifs_demultiplex_thread(void *p)
> > mempool_resize(cifs_req_poolp, length + cifs_min_rcv);
> >
> > set_freezable();
> > + sigfillset();
> > + sigdelset(, SIGKILL);
> > + sigprocmask(SIG_BLOCK, , );
> > while (server->tcpStatus != CifsExiting) {
> > if (try_to_freeze())
> > continue;
> >
> > On Tue, Jul 23, 2019 at 9:02 PM Steve French wrote:
> > >
> > > On Tue, Jul 23, 2019 at 8:32 PM Eric W. Biederman
> > > wrote:
> > > >
> > > > Steve French writes:
> > > >
> > > > > Very easy to see what caused the regression with this global change:
> > > > >
> > > > > mount (which launches "cifsd" thread to read the socket)
> > > > > umount (which kills the "cifsd" thread)
> > > > > rmmod (rmmod now fails since "cifsd" thread is still active)
> > > > >
> > > > > mount launches a thread to read from the socket ("cifsd")
> > > > > umount is supposed to kill that thread (but with the patch
> > > > > "signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of
> > > > > force_sig" that no longer works). So the regression is that after
> > > > > unmount you still see the "cifsd" thread, and the reason that cifsd
> > > > > thread is still around is that that patch no longer force kills the
> > > > > process (see line 2652 of fs/cifs/connect.c) which regresses module
> > > > > removal.
> > > > >
> > > > > - force_sig(SIGKILL, task);
> > > > > + send_sig(SIGKILL, task, 1);
> > > > >
> > > > > The comment in the changeset indicates "The signal SIGKILL can not be
> > > > > ignored" but obviously it can be ignored - at least on 5.3-rc1 it is
> > > > > being ignored.
> > > > >
> > > > > If send_sig(SIGKILL ...) doesn't work and if force_sig(SIGKILL, task)
> > > > > is removed and no longer possible - how do we kill a helper process
> > > > > ...
> > > >
> > > > I think I see what is happening. It looks like as well as misuinsg
> > > > force_sig, cifs is also violating the invariant that keeps SIGKILL out
> > > > of the blocked signal set.
> > > >
> > > > For that force_sig will act differently. I did not consider it because
> > > > that is never supposed to happen.
> > > >
> > > > Can someone test this code below and confirm the issue goes away?
> > > >
> > > > diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
> > > > index 5d6d44bfe10a..2a782ebc7b65 100644
> > > > --- a/fs/cifs/transport.c
> > > > +++ b/fs/cifs/transport.c
> > > > @@ -347,6 +347,7 @@ __smb_send_rqst(struct TCP_Server_Info *server, int
> > > > num_rqst,
> > > > */
> > > >
> > > > sigfillset();
> > > > + sigdelset(, SIGKILL);
> > > > sigprocmask(SIG_BLOCK, , );
> > > >
> > > > /* Generate a rfc1002 marker for SMB2+ */
> > > >
> > > >
> > > > Eric
> > >
> > > I
[PATCH net-next 10/11] net: hns3: Add support for using order 1 pages with a 4K buffer
From: Yunsheng Lin
Hardware supports 0.5K, 1K, 2K, 4K RX buffer size, the
RX buffer can not be reused because the hns3_page_order
return 0 when page size and RX buffer size are both 4096.
So this patch changes the hns3_page_order to return 1 when
RX buffer is greater than half of the page size and page size
is less the 8192, and dev_alloc_pages has already been used
to allocate the compound page for RX buffer.
This patch also changes hnae3_* to hns3_* for page order
and RX buffer size calculation because they are used in
hns3 module.
Signed-off-by: Yunsheng Lin
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 15 ---
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index cff5d59..56af4be 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2086,7 +2086,7 @@ static void hns3_set_default_feature(struct net_device
*netdev)
static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
struct hns3_desc_cb *cb)
{
- unsigned int order = hnae3_page_order(ring);
+ unsigned int order = hns3_page_order(ring);
struct page *p;
p = dev_alloc_pages(order);
@@ -2097,7 +2097,7 @@ static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
cb->page_offset = 0;
cb->reuse_flag = 0;
cb->buf = page_address(p);
- cb->length = hnae3_page_size(ring);
+ cb->length = hns3_page_size(ring);
cb->type = DESC_TYPE_PAGE;
return 0;
@@ -2400,7 +2400,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int
i,
{
struct hns3_desc *desc = >desc[ring->next_to_clean];
int size = le16_to_cpu(desc->rx.size);
- u32 truesize = hnae3_buf_size(ring);
+ u32 truesize = hns3_buf_size(ring);
skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
size - pull_len, truesize);
@@ -2415,7 +2415,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int
i,
/* Move offset up to the next cache line */
desc_cb->page_offset += truesize;
- if (desc_cb->page_offset + truesize <= hnae3_page_size(ring)) {
+ if (desc_cb->page_offset + truesize <= hns3_page_size(ring)) {
desc_cb->reuse_flag = 1;
/* Bump ref count on page before it is given */
get_page(desc_cb->priv);
@@ -2697,7 +2697,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring,
struct hns3_desc *desc,
}
if (ring->tail_skb) {
- head_skb->truesize += hnae3_buf_size(ring);
+ head_skb->truesize += hns3_buf_size(ring);
head_skb->data_len += le16_to_cpu(desc->rx.size);
head_skb->len += le16_to_cpu(desc->rx.size);
skb = ring->tail_skb;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 848b866..1a17856 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -608,9 +608,18 @@ static inline bool hns3_nic_resetting(struct net_device
*netdev)
#define tx_ring_data(priv, idx) ((priv)->ring_data[idx])
-#define hnae3_buf_size(_ring) ((_ring)->buf_size)
-#define hnae3_page_order(_ring) (get_order(hnae3_buf_size(_ring)))
-#define hnae3_page_size(_ring) (PAGE_SIZE << (u32)hnae3_page_order(_ring))
+#define hns3_buf_size(_ring) ((_ring)->buf_size)
+
+static inline unsigned int hns3_page_order(struct hns3_enet_ring *ring)
+{
+#if (PAGE_SIZE < 8192)
+ if (ring->buf_size > (PAGE_SIZE / 2))
+ return 1;
+#endif
+ return 0;
+}
+
+#define hns3_page_size(_ring) (PAGE_SIZE << hns3_page_order(_ring))
/* iterator for handling rings in ring group */
#define hns3_for_each_ring(pos, head) \
--
2.7.4
[PATCH net-next 11/11] net: hns3: add support for handling IMP error
From: Weihang Li
When IMP goes errors, the hardware reports a RAS to the driver,
the driver record this kind of error. Then a IMP reset will happen,
the driver checks the reason and takes the corresponding action
when doing IMP reset.
So this patch adds imp_err_state field to the struct hclge_dev
to record the error type, and handle_imp_error ops to handle it.
Signed-off-by: Weihang Li
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 37 --
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 4 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 29 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 9 ++
5 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index a4624db..3a1d6cc 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -515,6 +515,7 @@ struct hnae3_ae_ops {
int (*mac_connect_phy)(struct hnae3_handle *handle);
void (*mac_disconnect_phy)(struct hnae3_handle *handle);
void (*restore_vlan_table)(struct hnae3_handle *handle);
+ void (*handle_imp_error)(struct hnae3_handle *handle);
};
struct hnae3_dcb_ops {
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
index 0a72438..25df66d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c
@@ -683,6 +683,28 @@ static int hclge_cmd_query_error(struct hclge_dev *hdev,
return ret;
}
+static int hclge_check_imp_poison_err(struct hclge_dev *hdev)
+{
+ struct device *dev = >pdev->dev;
+ int ras_status;
+ int ret = false;
+
+ ras_status = hclge_read_dev(>hw, HCLGE_PF_OTHER_INT_REG);
+ if (ras_status & HCLGE_RAS_IMP_RD_POISON_MASK) {
+ set_bit(HCLGE_IMP_RD_POISON, >imp_err_state);
+ /* This error will be handle by IMP reset */
+ dev_info(dev, "IMP RD poison detected!\n");
+ ret = true;
+ } else if (ras_status & HCLGE_RAS_IMP_CMDQ_ERR_MASK) {
+ set_bit(HCLGE_IMP_CMDQ_ERROR, >imp_err_state);
+ /* This error will be handle by IMP reset */
+ dev_info(dev, "IMP CMDQ error detected!\n");
+ ret = true;
+ }
+
+ return ret;
+}
+
static int hclge_clear_mac_tnl_int(struct hclge_dev *hdev)
{
struct hclge_desc desc;
@@ -1321,10 +1343,12 @@ static int hclge_handle_pf_ras_error(struct hclge_dev
*hdev,
/* log PPU(RCB) errors */
desc_data = (__le32 *)[3];
status = le32_to_cpu(*desc_data) & HCLGE_PPU_PF_INT_RAS_MASK;
- if (status)
+ if (status) {
hclge_log_error(dev, "PPU_PF_ABNORMAL_INT_ST0",
_ppu_pf_abnormal_int[0], status,
_dev->hw_err_reset_req);
+ hdev->ppu_poison_ras_err = true;
+ }
/* clear all PF RAS errors */
hclge_cmd_reuse_desc([0], false);
@@ -1632,6 +1656,7 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
struct hclge_dev *hdev = ae_dev->priv;
struct device *dev = >pdev->dev;
u32 status;
+ int ret;
if (!test_bit(HCLGE_STATE_SERVICE_INITED, >state)) {
dev_err(dev,
@@ -1639,6 +1664,9 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
return PCI_ERS_RESULT_NONE;
}
+ if (hclge_check_imp_poison_err(hdev))
+ return PCI_ERS_RESULT_RECOVERED;
+
status = hclge_read_dev(>hw, HCLGE_RAS_PF_OTHER_INT_STS_REG);
if (status & HCLGE_RAS_REG_NFE_MASK ||
@@ -1652,7 +1680,12 @@ pci_ers_result_t hclge_handle_hw_ras_error(struct
hnae3_ae_dev *ae_dev)
dev_warn(dev,
"HNS Non-Fatal RAS error(status=0x%x) identified\n",
status);
- hclge_handle_all_ras_errors(hdev);
+ ret = hclge_handle_all_ras_errors(hdev);
+ if (ret) {
+ ret = hclge_check_imp_poison_err(hdev);
+ if (ret)
+ return PCI_ERS_RESULT_RECOVERED;
+ }
}
/* Handling Non-fatal Rocee RAS errors */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
index 7ea8bb2..4839fc4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h
@@ -12,6 +12,10 @@
#define HCLGE_PF_MSIX_INT_MIN_BD_NUM 4
#define HCLGE_RAS_PF_OTHER_INT_STS_REG 0x20B00
+#define
[PATCH net-next 04/11] net: hns3: fix mis-counting IRQ vector numbers issue
From: Yonglong Liu
The num_msi_left means the vector numbers of NIC, but if the
PF supported RoCE, it contains the vector numbers of NIC and
RoCE(Not expected).
This may cause interrupts lost in some case, because of the
NIC module used the vector resources which belongs to RoCE.
This patch corrects the value of num_msi_left to be equals to
the vector numbers of NIC, and adjust the default tqp numbers
according to the value of num_msi_left.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility
Layer Support")
Signed-off-by: Yonglong Liu
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 5 -
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 12 ++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3c64d70..a59d13f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1470,13 +1470,16 @@ static int hclge_vport_setup(struct hclge_vport *vport,
u16 num_tqps)
{
struct hnae3_handle *nic = >nic;
struct hclge_dev *hdev = vport->back;
+ u16 alloc_tqps;
int ret;
nic->pdev = hdev->pdev;
nic->ae_algo = _algo;
nic->numa_node_mask = hdev->numa_node_mask;
- ret = hclge_knic_setup(vport, num_tqps,
+ alloc_tqps = min_t(u16, hdev->roce_base_msix_offset - 1, num_tqps);
+
+ ret = hclge_knic_setup(vport, alloc_tqps,
hdev->num_tx_desc, hdev->num_rx_desc);
if (ret)
dev_err(>pdev->dev, "knic setup failed %d\n", ret);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index a13a0e1..db84782 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -287,6 +287,14 @@ static int hclgevf_get_queue_info(struct hclgevf_dev *hdev)
memcpy(>rss_size_max, _msg[2], sizeof(u16));
memcpy(>rx_buf_len, _msg[4], sizeof(u16));
+ /* if irq is not enough, let tqps have the same value of irqs,
+* to make sure one irq just bind to one tqp, this can improve
+* the performance
+*/
+ hdev->num_tqps = min_t(u16, hdev->roce_base_msix_offset - 1,
+ hdev->num_tqps);
+ hdev->rss_size_max = min_t(u16, hdev->rss_size_max, hdev->num_tqps);
+
return 0;
}
@@ -2208,7 +2216,7 @@ static int hclgevf_init_msi(struct hclgevf_dev *hdev)
int vectors;
int i;
- if (hnae3_get_bit(hdev->ae_dev->flag, HNAE3_DEV_SUPPORT_ROCE_B))
+ if (hnae3_dev_roce_supported(hdev))
vectors = pci_alloc_irq_vectors(pdev,
hdev->roce_base_msix_offset + 1,
hdev->num_msi,
@@ -2495,7 +2503,7 @@ static int hclgevf_query_vf_resource(struct hclgevf_dev
*hdev)
req = (struct hclgevf_query_res_cmd *)desc.data;
- if (hnae3_get_bit(hdev->ae_dev->flag, HNAE3_DEV_SUPPORT_ROCE_B)) {
+ if (hnae3_dev_roce_supported(hdev)) {
hdev->roce_base_msix_offset =
hnae3_get_field(__le16_to_cpu(req->msixcap_localid_ba_rocee),
HCLGEVF_MSIX_OFT_ROCEE_M,
--
2.7.4
[PATCH net-next 01/11] net: hns3: add reset checking before set channels
From: Jian Shen hns3_set_channels() should check the resetting status firstly, since the device will reinitialize when resetting. If the reset has not completed, the hns3_set_channels() may access invalid memory. Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index 69f7ef8..08af782 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -4378,6 +4378,9 @@ int hns3_set_channels(struct net_device *netdev, u16 org_tqp_num; int ret; + if (hns3_nic_resetting(netdev)) + return -EBUSY; + if (ch->rx_count || ch->tx_count) return -EINVAL; -- 2.7.4
[PATCH net-next 03/11] net: hns3: remove upgrade reset level when reset fail
Currently, hclge_reset_err_handle() will assert a global reset
when the failing count is smaller than MAX_RESET_FAIL_CNT, which
will affect other running functions.
So this patch removes this upgrading, and uses re-scheduling reset
task to do it.
Signed-off-by: Huazhong Tan
Reviewed-by: Yunsheng Lin
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 28 +++---
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3fde5471..3c64d70 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3305,7 +3305,7 @@ static int hclge_reset_prepare_wait(struct hclge_dev
*hdev)
return ret;
}
-static bool hclge_reset_err_handle(struct hclge_dev *hdev, bool is_timeout)
+static bool hclge_reset_err_handle(struct hclge_dev *hdev)
{
#define MAX_RESET_FAIL_CNT 5
@@ -3322,20 +3322,11 @@ static bool hclge_reset_err_handle(struct hclge_dev
*hdev, bool is_timeout)
return false;
} else if (hdev->reset_fail_cnt < MAX_RESET_FAIL_CNT) {
hdev->reset_fail_cnt++;
- if (is_timeout) {
- set_bit(hdev->reset_type, >reset_pending);
- dev_info(>pdev->dev,
-"re-schedule to wait for hw reset done\n");
- return true;
- }
-
- dev_info(>pdev->dev, "Upgrade reset level\n");
- hclge_clear_reset_cause(hdev);
- set_bit(HNAE3_GLOBAL_RESET, >default_reset_request);
- mod_timer(>reset_timer,
- jiffies + HCLGE_RESET_INTERVAL);
-
- return false;
+ set_bit(hdev->reset_type, >reset_pending);
+ dev_info(>pdev->dev,
+"re-schedule reset task(%d)\n",
+hdev->reset_fail_cnt);
+ return true;
}
hclge_clear_reset_cause(hdev);
@@ -3382,7 +3373,6 @@ static int hclge_reset_stack(struct hclge_dev *hdev)
static void hclge_reset(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
- bool is_timeout = false;
int ret;
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3410,10 +3400,8 @@ static void hclge_reset(struct hclge_dev *hdev)
if (ret)
goto err_reset;
- if (hclge_reset_wait(hdev)) {
- is_timeout = true;
+ if (hclge_reset_wait(hdev))
goto err_reset;
- }
hdev->rst_stats.hw_reset_done_cnt++;
@@ -3465,7 +3453,7 @@ static void hclge_reset(struct hclge_dev *hdev)
err_reset_lock:
rtnl_unlock();
err_reset:
- if (hclge_reset_err_handle(hdev, is_timeout))
+ if (hclge_reset_err_handle(hdev))
hclge_reset_task_schedule(hdev);
}
--
2.7.4
[PATCH net-next 07/11] net: hns3: adds debug messages to identify eth down cause
From: Yonglong Liu
Some times just see the eth interface have been down/up via
dmesg, but can not know why the eth down. So adds some debug
messages to identify the cause for this.
Signed-off-by: Yonglong Liu
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 24
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 26 ++
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14
3 files changed, 64 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4d58c53..cff5d59 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -459,6 +459,10 @@ static int hns3_nic_net_open(struct net_device *netdev)
h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
hns3_config_xps(priv);
+
+ if (netif_msg_ifup(h))
+ netdev_info(netdev, "net open\n");
+
return 0;
}
@@ -519,6 +523,9 @@ static int hns3_nic_net_stop(struct net_device *netdev)
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, >state))
return 0;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "net stop\n");
+
if (h->ae_algo->ops->set_timer_task)
h->ae_algo->ops->set_timer_task(priv->ae_handle, false);
@@ -1550,6 +1557,9 @@ static int hns3_setup_tc(struct net_device *netdev, void
*type_data)
h = hns3_get_handle(netdev);
kinfo = >kinfo;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "setup tc: num_tc=%d\n", tc);
+
return (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
}
@@ -1593,6 +1603,11 @@ static int hns3_ndo_set_vf_vlan(struct net_device
*netdev, int vf, u16 vlan,
struct hnae3_handle *h = hns3_get_handle(netdev);
int ret = -EIO;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set vf vlan: vf=%d, vlan=%d, qos=%d,
vlan_proto=%d\n",
+ vf, vlan, qos, vlan_proto);
+
if (h->ae_algo->ops->set_vf_vlan_filter)
ret = h->ae_algo->ops->set_vf_vlan_filter(h, vf, vlan,
qos, vlan_proto);
@@ -1611,6 +1626,10 @@ static int hns3_nic_change_mtu(struct net_device
*netdev, int new_mtu)
if (!h->ae_algo->ops->set_mtu)
return -EOPNOTSUPP;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev, "change mtu from %d to %d\n",
+ netdev->mtu, new_mtu);
+
ret = h->ae_algo->ops->set_mtu(h, new_mtu);
if (ret)
netdev_err(netdev, "failed to change MTU in hardware %d\n",
@@ -4395,6 +4414,11 @@ int hns3_set_channels(struct net_device *netdev,
if (kinfo->rss_size == new_tqp_num)
return 0;
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set channels: tqp_num=%d, rxfh=%d\n",
+ new_tqp_num, rxfh_configured);
+
ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index e71c92b..edb9845 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -311,6 +311,9 @@ static void hns3_self_test(struct net_device *ndev,
if (eth_test->flags != ETH_TEST_FL_OFFLINE)
return;
+ if (netif_msg_ifdown(h))
+ netdev_info(ndev, "self test start\n");
+
st_param[HNAE3_LOOP_APP][0] = HNAE3_LOOP_APP;
st_param[HNAE3_LOOP_APP][1] =
h->flags & HNAE3_SUPPORT_APP_LOOPBACK;
@@ -374,6 +377,9 @@ static void hns3_self_test(struct net_device *ndev,
if (if_running)
ndev->netdev_ops->ndo_open(ndev);
+
+ if (netif_msg_ifdown(h))
+ netdev_info(ndev, "self test end\n");
}
static int hns3_get_sset_count(struct net_device *netdev, int stringset)
@@ -604,6 +610,11 @@ static int hns3_set_pauseparam(struct net_device *netdev,
{
struct hnae3_handle *h = hns3_get_handle(netdev);
+ if (netif_msg_ifdown(h))
+ netdev_info(netdev,
+ "set pauseparam: autoneg=%d, rx:%d, tx:%d\n",
+ param->autoneg, param->rx_pause, param->tx_pause);
+
if (h->ae_algo->ops->set_pauseparam)
return h->ae_algo->ops->set_pauseparam(h, param->autoneg,
param->rx_pause,
@@ -743,6 +754,13 @@ static int hns3_set_link_ksettings(struct net_device
*netdev,
if (cmd->base.speed == SPEED_1000
[PATCH net-next 09/11] net: hns3: make hclge_service use delayed workqueue
From: Yunsheng Lin
Use delayed work instead of using timers to trigger the
hclge_serive.
Simplify the code with one less middle function and in order
to support misc irq affinity.
Signed-off-by: Yunsheng Lin
Reviewed-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 60 --
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 3 +-
2 files changed, 22 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fe45986..45acbc9 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2524,9 +2524,13 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_DOWN, >state) &&
!test_bit(HCLGE_STATE_REMOVING, >state) &&
- !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state))
- queue_work_on(cpumask_first(>affinity_mask), system_wq,
- >service_task);
+ !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state)) {
+ hdev->hw_stats.stats_timer++;
+ hdev->fd_arfs_expire_timer++;
+ mod_delayed_work_on(cpumask_first(>affinity_mask),
+ system_wq, >service_task,
+ round_jiffies_relative(HZ));
+ }
}
static int hclge_get_mac_link_status(struct hclge_dev *hdev)
@@ -2741,25 +2745,6 @@ static int hclge_get_status(struct hnae3_handle *handle)
return hdev->hw.mac.link;
}
-static void hclge_service_timer(struct timer_list *t)
-{
- struct hclge_dev *hdev = from_timer(hdev, t, service_timer);
-
- mod_timer(>service_timer, jiffies + HZ);
- hdev->hw_stats.stats_timer++;
- hdev->fd_arfs_expire_timer++;
- hclge_task_schedule(hdev);
-}
-
-static void hclge_service_complete(struct hclge_dev *hdev)
-{
- WARN_ON(!test_bit(HCLGE_STATE_SERVICE_SCHED, >state));
-
- /* Flush memory before next watchdog */
- smp_mb__before_atomic();
- clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
-}
-
static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
{
u32 rst_src_reg, cmdq_src_reg, msix_src_reg;
@@ -2937,9 +2922,6 @@ static void hclge_irq_affinity_notify(struct
irq_affinity_notify *notify,
affinity_notify);
cpumask_copy(>affinity_mask, mask);
- del_timer_sync(>service_timer);
- hdev->service_timer.expires = jiffies + HZ;
- add_timer_on(>service_timer, cpumask_first(>affinity_mask));
}
static void hclge_irq_affinity_release(struct kref *ref)
@@ -3639,7 +3621,9 @@ static void hclge_update_vport_alive(struct hclge_dev
*hdev)
static void hclge_service_task(struct work_struct *work)
{
struct hclge_dev *hdev =
- container_of(work, struct hclge_dev, service_task);
+ container_of(work, struct hclge_dev, service_task.work);
+
+ clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
if (hdev->hw_stats.stats_timer >= HCLGE_STATS_TIMER_INTERVAL) {
hclge_update_stats_for_all(hdev);
@@ -3654,7 +3638,8 @@ static void hclge_service_task(struct work_struct *work)
hclge_rfs_filter_expire(hdev);
hdev->fd_arfs_expire_timer = 0;
}
- hclge_service_complete(hdev);
+
+ hclge_task_schedule(hdev);
}
struct hclge_vport *hclge_get_vport(struct hnae3_handle *handle)
@@ -6193,13 +6178,13 @@ static void hclge_set_timer_task(struct hnae3_handle
*handle, bool enable)
struct hclge_dev *hdev = vport->back;
if (enable) {
- del_timer_sync(>service_timer);
- hdev->service_timer.expires = jiffies + HZ;
- add_timer_on(>service_timer,
-cpumask_first(>affinity_mask));
+ hclge_task_schedule(hdev);
} else {
- del_timer_sync(>service_timer);
- cancel_work_sync(>service_task);
+ /* Set the DOWN flag here to disable the service to be
+* scheduled again
+*/
+ set_bit(HCLGE_STATE_DOWN, >state);
+ cancel_delayed_work_sync(>service_task);
clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
}
}
@@ -8638,12 +8623,10 @@ static void hclge_state_uninit(struct hclge_dev *hdev)
set_bit(HCLGE_STATE_DOWN, >state);
set_bit(HCLGE_STATE_REMOVING, >state);
- if (hdev->service_timer.function)
- del_timer_sync(>service_timer);
if (hdev->reset_timer.function)
del_timer_sync(>reset_timer);
- if (hdev->service_task.func)
- cancel_work_sync(>service_task);
+ if (hdev->service_task.work.func)
+
[PATCH net-next 02/11] net: hns3: add a check for get_reset_level
From: Guangbin Huang
For some cases, ops->get_reset_level may not be implemented, so we
should check whether it is NULL before calling get_reset_level.
Signed-off-by: Guangbin Huang
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 08af782..4d58c53 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1963,7 +1963,7 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev
*pdev)
ops = ae_dev->ops;
/* request the reset */
- if (ops->reset_event) {
+ if (ops->reset_event && ops->get_reset_level) {
if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
_dev->hw_err_reset_req);
--
2.7.4
[PATCH net-next 05/11] net: hns3: change GFP flag during lock period
From: Yufeng Mo
When allocating memory, the GFP_KERNEL cannot be used during the
spin_lock period. This is because it may cause scheduling when holding
spin_lock. This patch changes GFP flag to GFP_ATOMIC in this case.
Fixes: dd74f815dd41 ("net: hns3: Add support for rule add/delete for flow
director")
Signed-off-by: Yufeng Mo
Signed-off-by: lipeng 00277521
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index a59d13f..f345095 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5799,7 +5799,7 @@ static int hclge_add_fd_entry_by_arfs(struct hnae3_handle
*handle, u16 queue_id,
return -ENOSPC;
}
- rule = kzalloc(sizeof(*rule), GFP_KERNEL);
+ rule = kzalloc(sizeof(*rule), GFP_ATOMIC);
if (!rule) {
spin_unlock_bh(>fd_rule_lock);
--
2.7.4
[PATCH net-next 00/11] net: hns3: some code optimizations & bugfixes & features
This patch-set includes code optimizations, bugfixes and features for the HNS3 ethernet controller driver. [patch 1/11] checks reset status before setting channel. [patch 2/11] adds a NULL pointer checking. [patch 3/11] removes reset level upgrading when current reset fails. [patch 4/11] fixes a bug related to IRQ vector number initialization. [patch 5/11] fixes a GFP flags errors when holding spin_lock. [patch 6/11] modifies firmware version format. [patch 7/11] adds some print information. [patch 8/11 - 9/11] adds two code optimizations about interrupt handler and work task. [patch 10/11] adds support for using order 1 pages with a 4K buffer. [patch 11/11] adds a detection about the reason of IMP errors. Guangbin Huang (1): net: hns3: add a check for get_reset_level Huazhong Tan (1): net: hns3: remove upgrade reset level when reset fail Jian Shen (1): net: hns3: add reset checking before set channels Weihang Li (1): net: hns3: add support for handling IMP error Yonglong Liu (2): net: hns3: fix mis-counting IRQ vector numbers issue net: hns3: adds debug messages to identify eth down cause Yufeng Mo (2): net: hns3: change GFP flag during lock period net: hns3: modify firmware version display format Yunsheng Lin (3): net: hns3: add interrupt affinity support for misc interrupt net: hns3: make hclge_service use delayed workqueue net: hns3: Add support for using order 1 pages with a 4K buffer drivers/net/ethernet/hisilicon/hns3/hnae3.h| 10 ++ drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 39 - drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 15 +- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 41 - .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14 ++ .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.c | 37 - .../net/ethernet/hisilicon/hns3/hns3pf/hclge_err.h | 4 + .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 165 ++--- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 16 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 11 +- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 12 +- 12 files changed, 298 insertions(+), 76 deletions(-) -- 2.7.4
[PATCH net-next 08/11] net: hns3: add interrupt affinity support for misc interrupt
From: Yunsheng Lin
The misc interrupt is used to schedule the reset and mailbox
subtask, and a 1 sec timer is used to schedule the service
subtask, which does periodic work.
This patch sets the above three subtask's affinity using the
misc interrupt' affinity.
Also this patch setups a affinity notify for misc interrupt to
allow user to change the above three subtask's affinity.
Signed-off-by: Yunsheng Lin
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 59 --
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 4 ++
2 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index f345095..fe45986 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1270,6 +1270,12 @@ static int hclge_configure(struct hclge_dev *hdev)
hclge_init_kdump_kernel_config(hdev);
+ /* Set the init affinity based on pci func number */
+ i = cpumask_weight(cpumask_of_node(dev_to_node(>pdev->dev)));
+ i = i ? PCI_FUNC(hdev->pdev->devfn) % i : 0;
+ cpumask_set_cpu(cpumask_local_spread(i, dev_to_node(>pdev->dev)),
+ >affinity_mask);
+
return ret;
}
@@ -2502,14 +2508,16 @@ static void hclge_mbx_task_schedule(struct hclge_dev
*hdev)
{
if (!test_bit(HCLGE_STATE_CMD_DISABLE, >state) &&
!test_and_set_bit(HCLGE_STATE_MBX_SERVICE_SCHED, >state))
- schedule_work(>mbx_service_task);
+ queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >mbx_service_task);
}
static void hclge_reset_task_schedule(struct hclge_dev *hdev)
{
if (!test_bit(HCLGE_STATE_REMOVING, >state) &&
!test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, >state))
- schedule_work(>rst_service_task);
+ queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >rst_service_task);
}
static void hclge_task_schedule(struct hclge_dev *hdev)
@@ -2517,7 +2525,8 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
if (!test_bit(HCLGE_STATE_DOWN, >state) &&
!test_bit(HCLGE_STATE_REMOVING, >state) &&
!test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state))
- (void)schedule_work(>service_task);
+ queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >service_task);
}
static int hclge_get_mac_link_status(struct hclge_dev *hdev)
@@ -2921,6 +2930,39 @@ static void hclge_get_misc_vector(struct hclge_dev *hdev)
hdev->num_msi_used += 1;
}
+static void hclge_irq_affinity_notify(struct irq_affinity_notify *notify,
+ const cpumask_t *mask)
+{
+ struct hclge_dev *hdev = container_of(notify, struct hclge_dev,
+ affinity_notify);
+
+ cpumask_copy(>affinity_mask, mask);
+ del_timer_sync(>service_timer);
+ hdev->service_timer.expires = jiffies + HZ;
+ add_timer_on(>service_timer, cpumask_first(>affinity_mask));
+}
+
+static void hclge_irq_affinity_release(struct kref *ref)
+{
+}
+
+static void hclge_misc_affinity_setup(struct hclge_dev *hdev)
+{
+ irq_set_affinity_hint(hdev->misc_vector.vector_irq,
+ >affinity_mask);
+
+ hdev->affinity_notify.notify = hclge_irq_affinity_notify;
+ hdev->affinity_notify.release = hclge_irq_affinity_release;
+ irq_set_affinity_notifier(hdev->misc_vector.vector_irq,
+ >affinity_notify);
+}
+
+static void hclge_misc_affinity_teardown(struct hclge_dev *hdev)
+{
+ irq_set_affinity_notifier(hdev->misc_vector.vector_irq, NULL);
+ irq_set_affinity_hint(hdev->misc_vector.vector_irq, NULL);
+}
+
static int hclge_misc_irq_init(struct hclge_dev *hdev)
{
int ret;
@@ -6151,7 +6193,10 @@ static void hclge_set_timer_task(struct hnae3_handle
*handle, bool enable)
struct hclge_dev *hdev = vport->back;
if (enable) {
- mod_timer(>service_timer, jiffies + HZ);
+ del_timer_sync(>service_timer);
+ hdev->service_timer.expires = jiffies + HZ;
+ add_timer_on(>service_timer,
+cpumask_first(>affinity_mask));
} else {
del_timer_sync(>service_timer);
cancel_work_sync(>service_task);
@@ -8809,6 +8854,11 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
INIT_WORK(>rst_service_task, hclge_reset_service_task);
INIT_WORK(>mbx_service_task, hclge_mailbox_service_task);
+ /* Setup affinity after service timer setup because add_timer_on
+* is called in affinity notify.
+*/
+
[PATCH net-next 06/11] net: hns3: modify firmware version display format
From: Yufeng Mo
This patch modifies firmware version display format in
hclge(vf)_cmd_init() and hns3_get_drvinfo(). Also, adds
some optimizations for firmware version display format.
Signed-off-by: Yufeng Mo
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 9 +
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15 +--
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10 +-
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 11 +--
4 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 48c7b70..a4624db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -179,6 +179,15 @@ struct hnae3_vector_info {
#define HNAE3_RING_GL_RX 0
#define HNAE3_RING_GL_TX 1
+#define HNAE3_FW_VERSION_BYTE3_SHIFT 24
+#define HNAE3_FW_VERSION_BYTE3_MASKGENMASK(31, 24)
+#define HNAE3_FW_VERSION_BYTE2_SHIFT 16
+#define HNAE3_FW_VERSION_BYTE2_MASKGENMASK(23, 16)
+#define HNAE3_FW_VERSION_BYTE1_SHIFT 8
+#define HNAE3_FW_VERSION_BYTE1_MASKGENMASK(15, 8)
+#define HNAE3_FW_VERSION_BYTE0_SHIFT 0
+#define HNAE3_FW_VERSION_BYTE0_MASKGENMASK(7, 0)
+
struct hnae3_ring_chain_node {
struct hnae3_ring_chain_node *next;
u32 tqp_index;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 5bff98a..e71c92b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -527,6 +527,7 @@ static void hns3_get_drvinfo(struct net_device *netdev,
{
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
+ u32 fw_version;
if (!h->ae_algo->ops->get_fw_version) {
netdev_err(netdev, "could not get fw version!\n");
@@ -545,8 +546,18 @@ static void hns3_get_drvinfo(struct net_device *netdev,
sizeof(drvinfo->bus_info));
drvinfo->bus_info[ETHTOOL_BUSINFO_LEN - 1] = '\0';
- snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
-priv->ae_handle->ae_algo->ops->get_fw_version(h));
+ fw_version = priv->ae_handle->ae_algo->ops->get_fw_version(h);
+
+ snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+"%lu.%lu.%lu.%lu",
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE2_MASK,
+HNAE3_FW_VERSION_BYTE2_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE1_MASK,
+HNAE3_FW_VERSION_BYTE1_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE0_MASK,
+HNAE3_FW_VERSION_BYTE0_SHIFT));
}
static u32 hns3_get_link(struct net_device *netdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 22f6acd..c2320bf 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -419,7 +419,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
}
hdev->fw_version = version;
- dev_info(>pdev->dev, "The firmware version is %08x\n", version);
+ pr_info_once("The firmware version is %lu.%lu.%lu.%lu\n",
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+HNAE3_FW_VERSION_BYTE2_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+HNAE3_FW_VERSION_BYTE1_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+HNAE3_FW_VERSION_BYTE0_SHIFT));
return 0;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 652b796..004125b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -405,8 +405,15 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
}
hdev->fw_version = version;
- dev_info(>pdev->dev, "The firmware version is %08x\n", version);
-
+ pr_info_once("The firmware version is %lu.%lu.%lu.%lu\n",
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+
Re: [PATCH] mt76: switch to SPDX tag instead of verbose boilerplate text
On Wed, 2019-07-24 at 11:03 +0800, Roy Luo wrote: > Hi Ryder, > > Please follow the convention, some of your header files use //. > > C source: // SPDX-License-Identifier: > C header: /* SPDX-License-Identifier: */ > > Regards, > Cheng-Hao (Roy) Luo I also found that - copy paste mistake. And I will fold this one into 'fix many checkpatch.pl warnings' series then send v1. Ryder > On Tue, Jul 23, 2019 at 2:45 PM Ryder Lee wrote: > > > > Add SPDX identifiers to all remaining files in mt76/ > > > > Signed-off-by: Ryder Lee > > ---
[PATCH] clk: imx7ulp: Make sure earlycon's clock is enabled
From: Anson Huang
Earlycon's clock could be disabled during kernel boot up,
if earlycon is enabled and its clock is gated, then kernel
boot up will fail. Make sure earlycon's clock is enabled
during kernel boot up.
Signed-off-by: Anson Huang
---
drivers/clk/imx/clk-imx7ulp.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 42e4667..2022d9b 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -42,6 +42,19 @@ static const struct clk_div_table ulp_div_table[] = {
{ .val = 7, .div = 64, },
};
+static const int pcc2_uart_clk_ids[] __initconst = {
+ IMX7ULP_CLK_LPUART4,
+ IMX7ULP_CLK_LPUART5,
+};
+
+static const int pcc3_uart_clk_ids[] __initconst = {
+ IMX7ULP_CLK_LPUART6,
+ IMX7ULP_CLK_LPUART7,
+};
+
+static struct clk **pcc2_uart_clks[ARRAY_SIZE(pcc2_uart_clk_ids) + 1]
__initdata;
+static struct clk **pcc3_uart_clks[ARRAY_SIZE(pcc3_uart_clk_ids) + 1]
__initdata;
+
static void __init imx7ulp_clk_scg1_init(struct device_node *np)
{
struct clk_hw_onecell_data *clk_data;
@@ -135,6 +148,7 @@ static void __init imx7ulp_clk_pcc2_init(struct device_node
*np)
struct clk_hw_onecell_data *clk_data;
struct clk_hw **clks;
void __iomem *base;
+ int i;
clk_data = kzalloc(struct_size(clk_data, hws, IMX7ULP_CLK_PCC2_END),
GFP_KERNEL);
@@ -173,6 +187,14 @@ static void __init imx7ulp_clk_pcc2_init(struct
device_node *np)
imx_check_clk_hws(clks, clk_data->num);
of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
+
+ for (i = 0; i < ARRAY_SIZE(pcc2_uart_clk_ids); i++) {
+ int index = pcc2_uart_clk_ids[i];
+
+ pcc2_uart_clks[i] = [index]->clk;
+ }
+
+ imx_register_uart_clocks(pcc2_uart_clks);
}
CLK_OF_DECLARE(imx7ulp_clk_pcc2, "fsl,imx7ulp-pcc2", imx7ulp_clk_pcc2_init);
@@ -181,6 +203,7 @@ static void __init imx7ulp_clk_pcc3_init(struct device_node
*np)
struct clk_hw_onecell_data *clk_data;
struct clk_hw **clks;
void __iomem *base;
+ int i;
clk_data = kzalloc(struct_size(clk_data, hws, IMX7ULP_CLK_PCC3_END),
GFP_KERNEL);
@@ -218,6 +241,14 @@ static void __init imx7ulp_clk_pcc3_init(struct
device_node *np)
imx_check_clk_hws(clks, clk_data->num);
of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
+
+ for (i = 0; i < ARRAY_SIZE(pcc3_uart_clk_ids); i++) {
+ int index = pcc3_uart_clk_ids[i];
+
+ pcc3_uart_clks[i] = [index]->clk;
+ }
+
+ imx_register_uart_clocks(pcc3_uart_clks);
}
CLK_OF_DECLARE(imx7ulp_clk_pcc3, "fsl,imx7ulp-pcc3", imx7ulp_clk_pcc3_init);
--
2.7.4
Re: Reminder: 3 open syzbot bugs in vhost subsystem
On Wed, Jul 24, 2019 at 11:05:14AM +0800, Jason Wang wrote: > > > > Title: KASAN: use-after-free Write in tlb_finish_mmu > > Last occurred: 5 days ago > > Reported: 4 days ago > > Branches: Mainline > > Dashboard link: > > https://syzkaller.appspot.com/bug?id=d57b94f89e48c85ef7d95acc208209ea4bdc10de > > Original thread: > > https://lkml.kernel.org/lkml/45e7a1058e024...@google.com/T/#u > > > > This bug has a syzkaller reproducer only. > > > > This bug was bisected to: > > > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc > > Author: Jason Wang > > Date: Fri May 24 08:12:18 2019 + > > > > vhost: access vq metadata through kernel virtual address > > > > No one has replied to the original thread for this bug yet. > > > > If you fix this bug, please add the following tag to the commit: > > Reported-by: syzbot+8267e9af795434ffa...@syzkaller.appspotmail.com > > > > If you send any email or patch for this bug, please reply to the original > > thread. For the git send-email command to use, or tips on how to reply if > > the > > thread isn't in your mailbox, see the "Reply instructions" at > > https://lkml.kernel.org/r/45e7a1058e024...@google.com > > > > > > Title: KASAN: use-after-free Read in finish_task_switch (2) > > Last occurred: 5 days ago > > Reported: 4 days ago > > Branches: Mainline > > Dashboard link: > > https://syzkaller.appspot.com/bug?id=9a98fcad6c8bd31f5c3afbdc6c75de9f082c0ffa > > Original thread: > > https://lkml.kernel.org/lkml/490679058e024...@google.com/T/#u > > > > This bug has a syzkaller reproducer only. > > > > This bug was bisected to: > > > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc > > Author: Jason Wang > > Date: Fri May 24 08:12:18 2019 + > > > > vhost: access vq metadata through kernel virtual address > > > > No one has replied to the original thread for this bug yet. > > > Hi: > > We believe above two bugs are duplicated with the report "WARNING in > __mmdrop". Can I just dup them with > > #syz dup "WARNING in __mmdrop" > > (If yes, just wonder how syzbot differ bugs, technically, several different > bug can hit the same warning). > Yes, please mark them as duplicates; see https://goo.gl/tpsmEJ#status for correct syntax. You need to send the command to the syzbot email address specific to each bug. Easiest way is to reply to the original threads. - Eric
Re: [PATCH] RDMA/hns: Fix build error for hip08
On 2019/7/23 21:37, Jason Gunthorpe wrote:
> On Tue, Jul 23, 2019 at 04:35:40PM +0300, Leon Romanovsky wrote:
>> On Tue, Jul 23, 2019 at 09:34:02AM -0300, Jason Gunthorpe wrote:
>>> On Tue, Jul 23, 2019 at 10:43:39AM +0300, Leon Romanovsky wrote:
On Tue, Jul 23, 2019 at 10:49:08AM +0800, YueHaibing wrote:
> If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
> but INFINIBAND_HNS is y, building fails:
>
> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function
> `hns_roce_hw_v2_exit':
> hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to
> `hnae3_unregister_client'
> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function
> `hns_roce_hw_v2_init':
> hns_roce_hw_v2.c:(.init.text+0xd): undefined reference to
> `hnae3_register_client'
It means that you have a problem with header files of your hns3.
>
> Reported-by: Hulk Robot
> Fixes: dd74282df573 ("RDMA/hns: Initialize the PCI device for hip08 RoCE")
> Signed-off-by: YueHaibing
> drivers/infiniband/hw/hns/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/hns/Kconfig
> b/drivers/infiniband/hw/hns/Kconfig
> index b59da5d..4371c80 100644
> +++ b/drivers/infiniband/hw/hns/Kconfig
> @@ -23,7 +23,8 @@ config INFINIBAND_HNS_HIP06
>
> config INFINIBAND_HNS_HIP08
> bool "Hisilicon Hip08 Family RoCE support"
> - depends on INFINIBAND_HNS && PCI && HNS3
> + depends on INFINIBAND_HNS && (INFINIBAND_HNS = HNS3)
This is wrong.
>>>
>>> It is tricky. It is asserting that the IB side is built as a module if
>>> the ethernet side is a module..
>>>
>>> It is kind of a weird pattern as the module config is INFINIBAND_HNS
>>> and these others are just bool opens what to include, but I think it
>>> is OK..
>>
>> select ???
>
> select doesn't influence module or not any different from depeends
Ok, it seems select is a better solution, it allows HNS3 is y while
INFINIBAND_HNS is m,
Will send v2, Thanks!
>
> Jason
>
> .
>
Re: [PATCH] kexec: Bail out upon SIGKILL when allocating memory.
On 2019/07/24 11:54, Eric Biggers wrote: > > What happened to this patch? This bug is still occurring. Andrew Morton added this patch to the -mm tree. Should appear in the linux-next tree in a few days. https://marc.info/?l=linux-mm-commits=156391134729795=2
RE: [PATCH v3 2/2] mailbox: introduce ARM SMC based mailbox
Hi All,
> Subject: [PATCH v3 2/2] mailbox: introduce ARM SMC based mailbox
Any comments with this patch?
>
> From: Peng Fan
>
> This mailbox driver implements a mailbox which signals transmitted data via
> an ARM smc (secure monitor call) instruction. The mailbox receiver is
> implemented in firmware and can synchronously return data when it returns
> execution to the non-secure world again.
> An asynchronous receive path is not implemented.
> This allows the usage of a mailbox to trigger firmware actions on SoCs which
> either don't have a separate management processor or on which such a core
> is not available. A user of this mailbox could be the SCP interface.
>
> Modified from Andre Przywara's v2 patch
> https://lore.kernel.org/patchwork/patch/812999/
>
> Cc: Andre Przywara
> Signed-off-by: Peng Fan
> ---
>
> V3:
> Drop interrupt.
> Introduce transports for mem/reg usage.
> Add chan-id for mem usage.
>
> V2:
> Add interrupts notification support.
>
> drivers/mailbox/Kconfig | 7 ++
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/arm-smc-mailbox.c | 215
> ++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/mailbox/arm-smc-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig index
> 595542bfae85..c3bd0f1ddcd8 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -15,6 +15,13 @@ config ARM_MHU
> The controller has 3 mailbox channels, the last of which can be
> used in Secure mode only.
>
> +config ARM_SMC_MBOX
> + tristate "Generic ARM smc mailbox"
> + depends on OF && HAVE_ARM_SMCCC
> + help
> + Generic mailbox driver which uses ARM smc calls to call into
> + firmware for triggering mailboxes.
> +
> config IMX_MBOX
> tristate "i.MX Mailbox"
> depends on ARCH_MXC || COMPILE_TEST
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile index
> c22fad6f696b..93918a84c91b 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST)+= mailbox-test.o
>
> obj-$(CONFIG_ARM_MHU)+= arm_mhu.o
>
> +obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
> +
> obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
>
> obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) +=
> armada-37xx-rwtm-mailbox.o
> diff --git a/drivers/mailbox/arm-smc-mailbox.c
> b/drivers/mailbox/arm-smc-mailbox.c
> new file mode 100644
> index ..76a2ae11ee4d
> --- /dev/null
> +++ b/drivers/mailbox/arm-smc-mailbox.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016,2017 ARM Ltd.
> + * Copyright 2019 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ARM_SMC_MBOX_MEM_TRANS BIT(0)
> +
> +struct arm_smc_chan_data {
> + u32 function_id;
> + u32 chan_id;
> + u32 flags;
> +};
> +
> +struct arm_smccc_mbox_cmd {
> + unsigned long a0, a1, a2, a3, a4, a5, a6, a7; };
> +
> +typedef unsigned long (smc_mbox_fn)(unsigned long, unsigned long,
> + unsigned long, unsigned long,
> + unsigned long, unsigned long,
> + unsigned long, unsigned long);
> +static smc_mbox_fn *invoke_smc_mbox_fn;
> +
> +static int arm_smc_send_data(struct mbox_chan *link, void *data) {
> + struct arm_smc_chan_data *chan_data = link->con_priv;
> + struct arm_smccc_mbox_cmd *cmd = data;
> + unsigned long ret;
> + u32 function_id;
> + u32 chan_id;
> +
> + if (chan_data->flags & ARM_SMC_MBOX_MEM_TRANS) {
> + if (chan_data->function_id != UINT_MAX)
> + function_id = chan_data->function_id;
> + else
> + function_id = cmd->a0;
> + chan_id = chan_data->chan_id;
> + ret = invoke_smc_mbox_fn(function_id, chan_id, 0, 0, 0, 0,
> + 0, 0);
> + } else {
> + ret = invoke_smc_mbox_fn(cmd->a0, cmd->a1, cmd->a2, cmd->a3,
> + cmd->a4, cmd->a5, cmd->a6, cmd->a7);
> + }
> +
> + mbox_chan_received_data(link, (void *)ret);
> +
> + return 0;
> +}
> +
> +static unsigned long __invoke_fn_hvc(unsigned long function_id,
> + unsigned long arg0, unsigned long arg1,
> + unsigned long arg2, unsigned long arg3,
> + unsigned long arg4, unsigned long arg5,
> + unsigned long arg6)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
> + arg5, arg6, );
> + return res.a0;
> +}
> +
> +static unsigned long __invoke_fn_smc(unsigned long function_id,
> + unsigned long arg0, unsigned long arg1,
>
Re: Re: Reminder: 3 open syzbot bugs in vhost subsystem
On 2019/7/24 上午10:38, Eric Biggers wrote: [This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the vhost subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 2 were seen in mainline in the last week. Of these 3 bugs, 2 were bisected to commits from the following person: Jason Wang If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the vhost subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KASAN: use-after-free Write in tlb_finish_mmu Last occurred: 5 days ago Reported: 4 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=d57b94f89e48c85ef7d95acc208209ea4bdc10de Original thread: https://lkml.kernel.org/lkml/45e7a1058e024...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit 7f466032dc9e5a61217f22ea34b2df932786bbfc Author: Jason Wang Date: Fri May 24 08:12:18 2019 + vhost: access vq metadata through kernel virtual address No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+8267e9af795434ffa...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/45e7a1058e024...@google.com Title: KASAN: use-after-free Read in finish_task_switch (2) Last occurred: 5 days ago Reported: 4 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=9a98fcad6c8bd31f5c3afbdc6c75de9f082c0ffa Original thread: https://lkml.kernel.org/lkml/490679058e024...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit 7f466032dc9e5a61217f22ea34b2df932786bbfc Author: Jason Wang Date: Fri May 24 08:12:18 2019 + vhost: access vq metadata through kernel virtual address No one has replied to the original thread for this bug yet. Hi: We believe above two bugs are duplicated with the report "WARNING in __mmdrop". Can I just dup them with #syz dup "WARNING in __mmdrop" I see the command but can't find the corresponding bug. Please resend the email to syzbot+h...@syzkaller.appspotmail.com address that is the sender of the bug report (also present in the Reported-by tag). (If yes, just wonder how syzbot differ bugs, technically, several different bug can hit the same warning). If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+7f067c796eee2acbc...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/490679058e024...@google.com Title: memory leak in vhost_net_ioctl Last occurred: 22 days ago Reported: 48 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=12ba349d7e26ccfe95317bc376e812ebbae2ee0f Original thread: https://lkml.kernel.org/lkml/188da1058a9c2...@google.com/T/#u This bug has a C reproducer. The original thread for this bug has received 4 replies; the last was 39 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+0789f0c7e45efd7bb...@syzkaller.appspotmail.com I do remember it can not be reproduced upstream, let me double check and close this one. Thanks If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at
Re: Reminder: 3 open syzbot bugs in vhost subsystem
On 2019/7/24 上午10:38, Eric Biggers wrote: [This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the vhost subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 2 were seen in mainline in the last week. Of these 3 bugs, 2 were bisected to commits from the following person: Jason Wang If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the vhost subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KASAN: use-after-free Write in tlb_finish_mmu Last occurred: 5 days ago Reported: 4 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=d57b94f89e48c85ef7d95acc208209ea4bdc10de Original thread: https://lkml.kernel.org/lkml/45e7a1058e024...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit 7f466032dc9e5a61217f22ea34b2df932786bbfc Author: Jason Wang Date: Fri May 24 08:12:18 2019 + vhost: access vq metadata through kernel virtual address No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+8267e9af795434ffa...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/45e7a1058e024...@google.com Title: KASAN: use-after-free Read in finish_task_switch (2) Last occurred: 5 days ago Reported: 4 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=9a98fcad6c8bd31f5c3afbdc6c75de9f082c0ffa Original thread: https://lkml.kernel.org/lkml/490679058e024...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit 7f466032dc9e5a61217f22ea34b2df932786bbfc Author: Jason Wang Date: Fri May 24 08:12:18 2019 + vhost: access vq metadata through kernel virtual address No one has replied to the original thread for this bug yet. Hi: We believe above two bugs are duplicated with the report "WARNING in __mmdrop". Can I just dup them with #syz dup "WARNING in __mmdrop" (If yes, just wonder how syzbot differ bugs, technically, several different bug can hit the same warning). If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+7f067c796eee2acbc...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/490679058e024...@google.com Title: memory leak in vhost_net_ioctl Last occurred: 22 days ago Reported: 48 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=12ba349d7e26ccfe95317bc376e812ebbae2ee0f Original thread: https://lkml.kernel.org/lkml/188da1058a9c2...@google.com/T/#u This bug has a C reproducer. The original thread for this bug has received 4 replies; the last was 39 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+0789f0c7e45efd7bb...@syzkaller.appspotmail.com I do remember it can not be reproduced upstream, let me double check and close this one. Thanks If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/188da1058a9c2...@google.com
Re: [PATCH] mt76: switch to SPDX tag instead of verbose boilerplate text
Hi Ryder, Please follow the convention, some of your header files use //. C source: // SPDX-License-Identifier: C header: /* SPDX-License-Identifier: */ Regards, Cheng-Hao (Roy) Luo On Tue, Jul 23, 2019 at 2:45 PM Ryder Lee wrote: > > Add SPDX identifiers to all remaining files in mt76/ > > Signed-off-by: Ryder Lee > --- > drivers/net/wireless/mediatek/mt76/agg-rx.c | 13 + > drivers/net/wireless/mediatek/mt76/debugfs.c| 13 + > drivers/net/wireless/mediatek/mt76/dma.c| 13 + > drivers/net/wireless/mediatek/mt76/dma.h| 13 + > drivers/net/wireless/mediatek/mt76/eeprom.c | 13 + > drivers/net/wireless/mediatek/mt76/mac80211.c | 13 + > drivers/net/wireless/mediatek/mt76/mcu.c| 13 + > drivers/net/wireless/mediatek/mt76/mmio.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x0/pci.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x0/pci_mcu.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02.h| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c | 13 + > .../net/wireless/mediatek/mt76/mt76x02_debugfs.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_dfs.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_dfs.h| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_dma.h| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_eeprom.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_mac.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_mac.h| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_mcu.h| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_phy.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_phy.h| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_regs.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_trace.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_trace.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_txrx.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_usb.h| 13 + > .../net/wireless/mediatek/mt76/mt76x02_usb_core.c | 13 + > .../net/wireless/mediatek/mt76/mt76x02_usb_mcu.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/eeprom.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/init.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/mac.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/mac.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/mcu.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/mcu.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/mt76x2u.h | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/pci.c | 13 + > .../net/wireless/mediatek/mt76/mt76x2/pci_init.c| 13 + > .../net/wireless/mediatek/mt76/mt76x2/pci_main.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/pci_mcu.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/phy.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 13 + > .../net/wireless/mediatek/mt76/mt76x2/usb_init.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/usb_mac.c | 13 + > .../net/wireless/mediatek/mt76/mt76x2/usb_main.c| 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/usb_mcu.c | 13 + > drivers/net/wireless/mediatek/mt76/mt76x2/usb_phy.c | 13 + > drivers/net/wireless/mediatek/mt76/trace.c | 13 + > drivers/net/wireless/mediatek/mt76/trace.h | 13 + > drivers/net/wireless/mediatek/mt76/tx.c | 13 + > drivers/net/wireless/mediatek/mt76/usb.c| 13 + > drivers/net/wireless/mediatek/mt76/usb_trace.c | 13 + > drivers/net/wireless/mediatek/mt76/usb_trace.h | 13 + > drivers/net/wireless/mediatek/mt76/util.c | 13 + > 63
[PATCH] ata: libata-core: Fix possible null-pointer dereferences in ata_host_alloc_pinfo()
In ata_host_alloc_pinfo(), when ppi[j] is NULL (line 6184), pi is NULL.
In this case, pi is used on lines 6187-6195:
ap->pio_mask = pi->pio_mask;
ap->mwdma_mask = pi->mwdma_mask;
...
Thus, possible null-pointer dereferences may occur.
To fix these possible bugs, when ppi[j] is NULL, the loop continues, and
"j++" is moved to the loop's regulator.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
drivers/ata/libata-core.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 28c492be0a57..dabfa50dfbbe 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6178,11 +6178,13 @@ struct ata_host *ata_host_alloc_pinfo(struct device
*dev,
if (!host)
return NULL;
- for (i = 0, j = 0, pi = NULL; i < host->n_ports; i++) {
+ for (i = 0, j = 0, pi = NULL; i < host->n_ports; i++, j++) {
struct ata_port *ap = host->ports[i];
if (ppi[j])
- pi = ppi[j++];
+ pi = ppi[j];
+ else
+ continue;
ap->pio_mask = pi->pio_mask;
ap->mwdma_mask = pi->mwdma_mask;
--
2.17.0
linux-next: manual merge of the devicetree tree with Linus' tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
between commit:
355fb0e54e85 ("dt-bindings: input: sun4i-lradc-keys: Add A64 compatible")
from Linus' tree and commit:
3f587b3b77b9 ("dt-bindings: input: Convert Allwinner LRADC to a schema")
from the devicetree tree.
I fixed it up (I removed the file - the additions from the former
have been incorporated into the latter) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpC9Hgn_8_OG.pgp
Description: OpenPGP digital signature
Reminder: 1 open syzbot bug in "android/ashmem" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "android/ashmem" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "android/ashmem" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: WARNING in __vm_enough_memory Last occurred: 91 days ago Reported: 554 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=52304f8f4b4e28508d52875f95df5e30417eff1b Original thread: https://lkml.kernel.org/lkml/001a1144593661efb50562d96...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 1 reply, 553 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+cc298e15b6a571ba0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/001a1144593661efb50562d96...@google.com
Reminder: 1 open syzbot bug in "kernel/cgroup" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "kernel/cgroup" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "kernel/cgroup" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: WARNING in cgroup_apply_control_enable Last occurred: 4 days ago Reported: 379 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=4cb6430631b7567848a6736be59d0350b3ada2ea Original thread: https://lkml.kernel.org/lkml/09f9a305708fa...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+5493b2a54d31d6aea...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/09f9a305708fa...@google.com
arch/xtensa/kernel/coprocessor.S:128: Error: literal pool location required for text-section-literals; specify with .literal_position
Hi Max, First bad commit (maybe != root cause): tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git master head: ad5e427e0f6b702e52c11d1f7b2b7be3bac7de82 commit: d6d5f19e21d98c0607ff029e4e2e508d4cdd1d5a xtensa: abstract 'entry' and 'retw' in assembly code date: 2 weeks ago config: xtensa-audio_kc705_defconfig (attached as .config) compiler: xtensa-test_kc705_hifi-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout d6d5f19e21d98c0607ff029e4e2e508d4cdd1d5a # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=xtensa If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): arch/xtensa/kernel/coprocessor.S: Assembler messages: arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'rur.ae_ovf_sar' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'rur.ae_bithead' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'rur.ae_ts_fts_bu_bp' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'rur.ae_cw_sd_no' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'rur.ae_cbegin0' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'rur.ae_cend0' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_s64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_salign64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_salign64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_salign64.i' arch/xtensa/kernel/coprocessor.S:69: Error: unknown opcode or format name 'ae_salign64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'wur.ae_ovf_sar' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'wur.ae_bithead' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'wur.ae_ts_fts_bu_bp' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'wur.ae_cw_sd_no' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'wur.ae_cbegin0' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'wur.ae_cend0' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown opcode or format name 'ae_l64.i' arch/xtensa/kernel/coprocessor.S:78: Error: unknown
Re: [PATCH] kexec: Bail out upon SIGKILL when allocating memory.
On Fri, Jun 14, 2019 at 07:16:18PM +0900, Tetsuo Handa wrote:
> syzbot found that a thread can stall for minutes inside kexec_load() after
> that thread was killed by SIGKILL [1]. It turned out that the reproducer
> was trying to allocate 2408MB of memory using kimage_alloc_page() from
> kimage_load_normal_segment(). Let's check for SIGKILL before doing memory
> allocation.
>
> [1]
> https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
>
> Signed-off-by: Tetsuo Handa
> Reported-by: syzbot
> ---
> kernel/kexec_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index fd5c95f..2b25d95 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -302,6 +302,8 @@ static struct page *kimage_alloc_pages(gfp_t gfp_mask,
> unsigned int order)
> {
> struct page *pages;
>
> + if (fatal_signal_pending(current))
> + return NULL;
> pages = alloc_pages(gfp_mask & ~__GFP_ZERO, order);
> if (pages) {
> unsigned int count, i;
> --
> 1.8.3.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/993c9185-d324-2640-d061-bed2dd18b1f7%40I-love.SAKURA.ne.jp.
> For more options, visit https://groups.google.com/d/optout.
What happened to this patch? This bug is still occurring.
- Eric
Reminder: 1 open syzbot bug in "net/pfkey" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "net/pfkey" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "net/pfkey" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: WARNING in pfkey_sock_destruct Last occurred: 168 days ago Reported: 300 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=6dc52e859d5ccc5fdce168973ab63b97ac7e41ba Original thread: https://lkml.kernel.org/lkml/2b8eb70576c15...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+4acf0d9092f91bb60...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/2b8eb70576c15...@google.com
Reminder: 1 open syzbot bug in "net/ppp" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "net/ppp" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "net/ppp" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: memory leak in pppoe_sendmsg Last occurred: 6 days ago Reported: 53 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=68fe3119847862315e52aa14961144b5a909bc23 Original thread: https://lkml.kernel.org/lkml/d981f1058a26e...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+6bdfd184eac7709e5...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/d981f1058a26e...@google.com
Reminder: 1 open syzbot bug in "net/sunrpc" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "net/sunrpc" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "net/sunrpc" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: linux-next test error: WARNING in remove_proc_entry Last occurred: 69 days ago Reported: 71 days ago Branches: linux-next Dashboard link: https://syzkaller.appspot.com/bug?id=0b23d0049d5af6699d68ff17e2db121569b78fd4 Original thread: https://lkml.kernel.org/lkml/55d6590588bf9...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+4887e9dd9042fae2a...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/55d6590588bf9...@google.com
Reminder: 1 open syzbot bug in "net/strparser" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "net/strparser" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "net/strparser" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: WARNING in strp_done (2) Last occurred: 163 days ago Reported: 174 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=95997d9e84b5e2f966ac13c3ccf01670e77ca4f6 Original thread: https://lkml.kernel.org/lkml/7c36aa0580b16...@google.com/T/#u This bug has a syzkaller reproducer only. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+ea38a133bb90dd367...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/7c36aa0580b16...@google.com
Reminder: 1 open syzbot bug in rtc subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the rtc subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the rtc subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: BUG: workqueue lockup (4) Last occurred: 40 days ago Reported: 289 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=0041bf1423916e9ae458b08b760e269a33c14960 Original thread: https://lkml.kernel.org/lkml/5764090577a27...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 4 replies; the last was 42 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+08116743f8ad6f9a6...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/5764090577a27...@google.com
Reminder: 1 open syzbot bug in "security/integrity" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "security/integrity" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "security/integrity" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: INFO: task hung in process_measurement Last occurred: 133 days ago Reported: 295 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=623c2e176b9d80b1872e7559e5b823b1ec4911b6 Original thread: https://lkml.kernel.org/lkml/33ebee0577262...@google.com/T/#u This bug has a C reproducer. syzbot has bisected this bug, but I think the bisection result is incorrect. The original thread for this bug received 1 reply, 120 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+cdc562bc26a2b2b0a...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/33ebee0577262...@google.com
Reminder: 1 open syzbot bug in "security/smack" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the "security/smack" subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the "security/smack" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: possible deadlock in ext4_evict_inode Last occurred: 281 days ago Reported: 320 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=9eda6092f146cb23cb9109f675a2e2cb743ee48b Original thread: https://lkml.kernel.org/lkml/91615e0575368...@google.com/T/#u This bug has a syzkaller reproducer only. The original thread for this bug received 2 replies; the last was 320 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+0eefc1e06a77d327a...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/91615e0575368...@google.com
Reminder: 1 open syzbot bug in sound subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 1 of them as possibly being a bug in the sound subsystem. If you believe this bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed this bug to the sound subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here is the bug: Title: KASAN: use-after-free Read in wake_up_if_idle Last occurred: 131 days ago Reported: 267 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=b1e300cd7b124fc83dd4199d4d1df26310111b0f Original thread: https://lkml.kernel.org/lkml/66ab7105795f2...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+2c1253bc508adef78...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/66ab7105795f2...@google.com
[PATCH] fs: jffs2: Fix possible null-pointer dereferences in jffs2_add_frag_to_fragtree()
In jffs2_add_frag_to_fragtree(), there is an if statement on line 223 to
check whether "this" is NULL:
if (this)
When "this" is NULL, it is used at several places, such as on line 249:
if (this->node)
and on line 260:
if (newfrag->ofs > this->ofs)
Thus possible null-pointer dereferences may occur.
To fix these bugs, -EINVAL is returned when "this" is NULL.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai
---
fs/jffs2/nodelist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jffs2/nodelist.c b/fs/jffs2/nodelist.c
index b86c78d178c6..021a4a2190ee 100644
--- a/fs/jffs2/nodelist.c
+++ b/fs/jffs2/nodelist.c
@@ -226,7 +226,7 @@ static int jffs2_add_frag_to_fragtree(struct jffs2_sb_info
*c, struct rb_root *r
lastend = this->ofs + this->size;
} else {
dbg_fragtree2("lookup gave no frag\n");
- lastend = 0;
+ return -EINVAL;
}
/* See if we ran off the end of the fragtree */
--
2.17.0
Reminder: 2 open syzbot bugs in "net/l2tp" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 2 of them as possibly being bugs in the "net/l2tp" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 2 bugs, 1 was seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/l2tp" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: WARNING: locking bug in inet_autobind Last occurred: 1 day ago Reported: 68 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=a7d678fba80c34b5770cc1b5638b8a2709ae9f3f Original thread: https://lkml.kernel.org/lkml/33a0120588fac...@google.com/T/#u This bug has a syzkaller reproducer only. syzbot has bisected this bug, but I think the bisection result is incorrect. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+94cc2a66fc228b23f...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/33a0120588fac...@google.com Title: WARNING: locking bug in do_ipv6_setsockopt Last occurred: 4 days ago Reported: 62 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=6a970baf20aa5a64455be86fb920f468def703c6 Original thread: https://lkml.kernel.org/lkml/f7707805897c0...@google.com/T/#u This bug has a syzkaller reproducer only. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+f28170ca1ee366e97...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/f7707805897c0...@google.com
Reminder: 2 open syzbot bugs in "net/rxrpc" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 2 of them as possibly being bugs in the "net/rxrpc" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 2 bugs, 1 was seen in mainline in the last week. Of these 2 bugs, 1 was bisected to a commit from the following person: David Howells If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/rxrpc" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: kernel BUG at net/rxrpc/local_object.c:LINE! Last occurred: 2 days ago Reported: 25 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=53b6555b27af2cae74e2fbdac6cadc73f9cb18aa Original thread: https://lkml.kernel.org/lkml/4c2416058c594...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit 46894a13599a977ac35411b536fb3e0b2feefa95 Author: David Howells Date: Thu Oct 4 08:32:28 2018 + rxrpc: Use IPv4 addresses throught the IPv6 The original thread for this bug has received 3 replies; the last was 18 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+1e0edc4b8b7494c28...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/4c2416058c594...@google.com Title: WARNING: locking bug in flush_workqueue_prep_pwqs Last occurred: 30 days ago Reported: 158 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=4ae48f9c43f87ccf9f2f270b14d5b9284dadd05c Original thread: https://lkml.kernel.org/lkml/5c7e6f0581f1b...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+0c4264acb66ea0484...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/5c7e6f0581f1b...@google.com
Re: x86 - clang / objtool status
On Thu, Jul 18, 2019 at 10:40:09PM +0200, Thomas Gleixner wrote:
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
> .altinstr_replacement+0x86: redundant UACCESS disable
Looking at this one, I think I agree with objtool.
PeterZ, Linus, I know y'all discussed this code a few months ago.
__copy_from_user() already does a CLAC in its error path. So isn't the
user_access_end() redundant for the __copy_from_user() error path?
Untested fix:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 5fae0e50aad0..41dab9ea33cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1628,6 +1628,7 @@ static int check_relocations(const struct
drm_i915_gem_exec_object2 *entry)
static int eb_copy_relocations(const struct i915_execbuffer *eb)
{
+ struct drm_i915_gem_relocation_entry *relocs;
const unsigned int count = eb->buffer_count;
unsigned int i;
int err;
@@ -1635,7 +1636,6 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
for (i = 0; i < count; i++) {
const unsigned int nreloc = eb->exec[i].relocation_count;
struct drm_i915_gem_relocation_entry __user *urelocs;
- struct drm_i915_gem_relocation_entry *relocs;
unsigned long size;
unsigned long copied;
@@ -1663,14 +1663,8 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
if (__copy_from_user((char *)relocs + copied,
(char __user *)urelocs + copied,
-len)) {
-end_user:
- user_access_end();
-end:
- kvfree(relocs);
- err = -EFAULT;
- goto err;
- }
+len))
+ goto end;
copied += len;
} while (copied < size);
@@ -1699,10 +1693,14 @@ static int eb_copy_relocations(const struct
i915_execbuffer *eb)
return 0;
+end_user:
+ user_access_end();
+end:
+ kvfree(relocs);
+ err = -EFAULT;
err:
while (i--) {
- struct drm_i915_gem_relocation_entry *relocs =
- u64_to_ptr(typeof(*relocs), eb->exec[i].relocs_ptr);
+ relocs = u64_to_ptr(typeof(*relocs), eb->exec[i].relocs_ptr);
if (eb->exec[i].relocation_count)
kvfree(relocs);
}
Reminder: 2 open syzbot bugs in "security/tomoyo" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 2 of them as possibly being bugs in the "security/tomoyo" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "security/tomoyo" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KASAN: use-after-free Read in tomoyo_realpath_from_path Last occurred: 28 days ago Reported: 48 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74 Original thread: https://lkml.kernel.org/lkml/4f43fa058a97f...@google.com/T/#u This bug has a syzkaller reproducer only. The original thread for this bug has received 7 replies; the last was 31 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+0341f6a4d729d4e0a...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/4f43fa058a97f...@google.com Title: KASAN: invalid-free in tomoyo_realpath_from_path Last occurred: 57 days ago Reported: 56 days ago Branches: net-next Dashboard link: https://syzkaller.appspot.com/bug?id=e9e5a1d41c3fb5d0f79aeea0e4cd535f160a6702 Original thread: https://lkml.kernel.org/lkml/785e9d0589ec3...@google.com/T/#u Unfortunately, this bug does not have a reproducer. The original thread for this bug has received 1 reply, 56 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+9742b1c6c7aedf18b...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/785e9d0589ec3...@google.com
Reminder: 3 open syzbot bugs in hid subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the hid subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 2 were seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the hid subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KASAN: use-after-free Read in hidraw_ioctl Last occurred: 0 days ago Reported: 0 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=c7e345ba243bc4476aae52a3354ccbd2a90e344e Original thread: https://lkml.kernel.org/lkml/c07378058e589...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. This looks like a bug in a hid USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+ded1794a717e3b235...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/c07378058e589...@google.com Title: KASAN: use-after-free Read in usbhid_power Last occurred: 0 days ago Reported: 0 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=36143971c5b9b0341ad4018313375a5a40cb52c8 Original thread: https://lkml.kernel.org/lkml/bb4247058e589...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. This looks like a bug in a hid USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+ef5de9c4f99c4edb4...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/bb4247058e589...@google.com Title: INFO: task hung in fsnotify_connector_destroy_workfn (2) Last occurred: 32 days ago Reported: 311 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=d6011f00f49a2253c15a60ac102b2ea79e3ee8de Original thread: https://lkml.kernel.org/lkml/6364200575dfc...@google.com/T/#u This bug has a syzkaller reproducer only. The original thread for this bug received 7 replies; the last was 301 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+6fb572170402d311d...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/6364200575dfc...@google.com
Reminder: 3 open syzbot bugs in "net/kcm" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the "net/kcm" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 1 was seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/kcm" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KMSAN: uninit-value in ip_tunnel_xmit (2) Last occurred: 0 days ago Reported: 347 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=b0e069ac9b03eab43b106c22fcc8bd778a7ccfb5 Original thread: https://lkml.kernel.org/lkml/5012b60573159...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 1 reply, 347 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+4a2c52677a8a1aa28...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/5012b60573159...@google.com Title: general protection fault in skb_unlink Last occurred: 182 days ago Reported: 418 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=2d6d1853e26eb3b70cd558298ebf0c98157fcccf Original thread: https://lkml.kernel.org/lkml/fdc15c056d7c1...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+278279efdd2730dd1...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/fdc15c056d7c1...@google.com Title: general protection fault in requeue_rx_msgs Last occurred: 419 days ago Reported: 418 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=da9b672629747f28e76eca9949696c410cb75d7b Original thread: https://lkml.kernel.org/lkml/0482ce056d7c1...@google.com/T/#u This bug has a syzkaller reproducer only. syzbot has bisected this bug, but I think the bisection result is incorrect. The original thread for this bug received 1 reply, 418 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+554266c04a41d1f97...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/0482ce056d7c1...@google.com
Reminder: 3 open syzbot bugs in "net/llc" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the "net/llc" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 3 were seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/llc" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: memory leak in llc_conn_ac_send_sabme_cmd_p_set_x Last occurred: 0 days ago Reported: 63 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=1c2132cc5a2f0d05091adc4f2ed088020522f73a Original thread: https://lkml.kernel.org/lkml/5974af0589660...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+6b825a6494a04cc0e...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/5974af0589660...@google.com Title: memory leak in llc_ui_sendmsg Last occurred: 1 day ago Reported: 63 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=4e8b3190d51a3b721b554f103da5399613748ea0 Original thread: https://lkml.kernel.org/lkml/9382e7058965f...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+31c16aa4202dace38...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/9382e7058965f...@google.com Title: memory leak in llc_ui_create (2) Last occurred: 6 days ago Reported: 32 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=ecc7f04cd94b5c062c000865d43bfb682d718b8e Original thread: https://lkml.kernel.org/lkml/058a0f058bd50...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+6bf095f9becf5efef...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/058a0f058bd50...@google.com
Reminder: 3 open syzbot bugs in "net/rose" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better, or if you want it re-generated with the latest status.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 3 of them as possibly being bugs in the "net/rose" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 3 bugs, 1 was seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/rose" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: general protection fault in rose_send_frame Last occurred: 2 days ago Reported: 194 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=f46c94afb217ab49c75350adbd467d86ae2b59a6 Original thread: https://lkml.kernel.org/lkml/89904d057f1e0...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+7078ae989d857fe17...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/89904d057f1e0...@google.com Title: INFO: rcu detected stall in rose_loopback_timer (2) Last occurred: 46 days ago Reported: 44 days ago Branches: net Dashboard link: https://syzkaller.appspot.com/bug?id=42c06438fe5956ab9978486a1898ca2f23b1fc1f Original thread: https://lkml.kernel.org/lkml/cf98fa058adf3...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+d37efb0ca1b826823...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/cf98fa058adf3...@google.com Title: INFO: rcu detected stall in rose_connect Last occurred: 52 days ago Reported: 49 days ago Branches: net-next Dashboard link: https://syzkaller.appspot.com/bug?id=0b258dc8ece5bb93dfb5a137ae25a6db300d5892 Original thread: https://lkml.kernel.org/lkml/17b026058a785...@google.com/T/#u Unfortunately, this bug does not have a reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+af81c7a21a31b18be...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/17b026058a785...@google.com
