On Wed, Nov 21, 2018 at 11:11:18AM +0500, Victoria Anosova wrote:
> Glad this come to kernel. We've already applied this patch.
The current version, with the bottom half toggling or the original one
with preempt_disable/enable?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Many HP AMD based laptops contain an SMB0001 device like this:
Device (SMBD)
{
Name (_HID, "SMB0001") // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
IO (Decode16,
0x0B20, // Range Minimum
0x0B20, // Range Maximum
0x20, // Alignment
0x20, // Length
)
IRQ (Level, ActiveLow, Shared, )
{7}
})
}
The legacy style IRQ resource here causes acpi_dev_get_irqresource() to
be called with legacy=true and this message to show in dmesg:
ACPI: IRQ 7 override to edge, high
This causes issues when later on the AMD0030 GPIO device gets enumerated:
Device (GPIO)
{
Name (_HID, "AMDI0030") // _HID: Hardware ID
Name (_CID, "AMDI0030") // _CID: Compatible ID
Name (_UID, Zero) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
{
0x00000007,
}
Memory32Fixed (ReadWrite,
0xFED81500, // Address Base
0x00000400, // Address Length
)
})
Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */
}
}
Now acpi_dev_get_irqresource() gets called with legacy=false, but because
of the earlier override of the trigger-type acpi_register_gsi() returns
-EBUSY (because we try to register the same interrupt with a different
trigger-type) and we end up setting IORESOURCE_DISABLED in the flags.
The setting of IORESOURCE_DISABLED causes platform_get_irq() to call
acpi_irq_get() which is not implemented on x86 and returns -EINVAL.
resulting in the following in dmesg:
amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
amd_gpio: probe of AMDI0030:00 failed with error -22
The SMB0001 is a "virtual" device in the sense that the only way the OS
interacts with it is through calling a couple of methods to do SMBus
transfers. As such it is weird that it has IO and IRQ resources at all,
because the driver for it is not expected to ever access the hardware
directly.
The Linux driver for the SMB0001 device directly binds to the acpi_device
through the acpi_bus, so we do not need to instantiate a platform_device
for this ACPI device. This commit adds the SMB0001 HID to the
forbidden_id_list, avoiding the instantiating of a platform_device for it.
Not instantiating a platform_device means we will no longer call
acpi_dev_get_irqresource() for the legacy IRQ resource fixing the probe of
the AMDI0030 device failing.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198715
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=199523
Reported-by: Lukas Kahnert <openproggerfreak(a)gmail.com>
Tested-by: Marc <suaefar(a)googlemail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/acpi/acpi_platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index eaa60c94205a..1f32caa87686 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -30,6 +30,7 @@ static const struct acpi_device_id forbidden_id_list[] = {
{"PNP0200", 0}, /* AT DMA Controller */
{"ACPI0009", 0}, /* IOxAPIC */
{"ACPI000A", 0}, /* IOAPIC */
+ {"SMB0001", 0}, /* ACPI SMBUS virtual device */
{"", 0},
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm644x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index de1ec6dc01e9..38f92b7d413e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -518,6 +518,8 @@ static struct resource dm644_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm644_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 71,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/da830.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 0bc5bd2665df..2cc9fe4c3a91 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -759,7 +759,9 @@ static struct davinci_id da830_ids[] = {
};
static struct davinci_gpio_platform_data da830_gpio_platform_data = {
- .ngpio = 128,
+ .no_auto_base = true,
+ .base = 0,
+ .ngpio = 128,
};
int __init da830_register_gpio(void)
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm355.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 2b0f5d97ab7c..4c6e0bef4509 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -584,6 +584,8 @@ static struct resource dm355_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm355_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 104,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm646x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index d9b93e2806d2..7dc54b2a610f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -458,6 +458,8 @@ static struct resource dm646x_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm646x_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 43,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm365.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 42665914166a..01fb2b0c82de 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -308,6 +308,8 @@ static struct resource dm365_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm365_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 104,
.gpio_unbanked = 8,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
We now have the option to specify the GPIO base manually for davinci,
so add the relevant fields to platform data.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/da850.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4528bbf0c861..e7b78df2bfef 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -719,7 +719,9 @@ int __init da850_register_vpif_capture(struct vpif_capture_config
}
static struct davinci_gpio_platform_data da850_gpio_platform_data = {
- .ngpio = 144,
+ .no_auto_base = true,
+ .base = 0,
+ .ngpio = 144,
};
int __init da850_register_gpio(void)
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
Other boards may be broken too, which I haven't tested.
The problem is in the fact that most board files still use the legacy
GPIO API where lines are requested by numbers rather than descriptors.
While this should be fixed eventually, in order to unbreak the board
for now - provide a way to manually specify the GPIO base in platform
data.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Acked-by: Linus Walleij <linus.walleij(a)linaro.org>
---
drivers/gpio/gpio-davinci.c | 2 +-
include/linux/platform_data/gpio-davinci.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5c1564fcc24e..bdb29e51b417 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -258,7 +258,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.set = davinci_gpio_set;
chips->chip.ngpio = ngpio;
- chips->chip.base = -1;
+ chips->chip.base = pdata->no_auto_base ? pdata->base : -1;
#ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
diff --git a/include/linux/platform_data/gpio-davinci.h b/include/linux/platform_data/gpio-davinci.h
index f92a47e18034..a93841bfb9f7 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -17,6 +17,8 @@
#define __DAVINCI_GPIO_PLATFORM_H
struct davinci_gpio_platform_data {
+ bool no_auto_base;
+ u32 base;
u32 ngpio;
u32 gpio_unbanked;
};
--
2.19.1
This was marked for stable, and honestly, nowhere in the discussion
did I see any mention of just *how* bad the performance impact of this
was.
When performance goes down by 50% on some loads, people need to start
asking themselves whether it was worth it. It's apparently better to
just disable SMT entirely, which is what security-conscious people do
anyway.
So why do that STIBP slow-down by default when the people who *really*
care already disabled SMT?
I think we should use the same logic as for L1TF: we default to
something that doesn't kill performance. Warn once about it, and let
the crazy people say "I'd rather take a 50% performance hit than
worry about a theoretical issue".
Linus
KEXEC needs the new kernel's load address to be aligned on a page
boundary (see sanity_check_segment_list()), but on MIPS the default
vmlinuz load address is only explicitly aligned to 16 bytes.
Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
the alignment calculated by calc_vmlinuz_load_addr to 64KB.
Cc: <stable(a)vger.kernel.org> # 2.6.36+
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
---
arch/mips/boot/compressed/calc_vmlinuz_load_addr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c b/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
index 37fe58c..542c3ed 100644
--- a/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
+++ b/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
@@ -13,6 +13,7 @@
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
+#include "../../../../include/linux/sizes.h"
int main(int argc, char *argv[])
{
@@ -45,11 +46,11 @@ int main(int argc, char *argv[])
vmlinuz_load_addr = vmlinux_load_addr + vmlinux_size;
/*
- * Align with 16 bytes: "greater than that used for any standard data
- * types by a MIPS compiler." -- See MIPS Run Linux (Second Edition).
+ * Align with 64KB: KEXEC needs load sections to be aligned to PAGE_SIZE,
+ * which may be as large as 64KB depending on the kernel configuration.
*/
- vmlinuz_load_addr += (16 - vmlinux_size % 16);
+ vmlinuz_load_addr += (SZ_64K - vmlinux_size % SZ_64K);
printf("0x%llx\n", vmlinuz_load_addr);
--
2.7.0
This is the start of the stable review cycle for the 4.9.138 release.
There are 83 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Nov 21 16:25:13 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.138-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.138-rc1
Mark Rutland <mark.rutland(a)arm.com>
KVM: arm64: Fix caching of host MDCR_EL2 value
Chris Wilson <chris(a)chris-wilson.co.uk>
drm/i915/execlists: Force write serialisation into context image vs execution
Clint Taylor <clinton.a.taylor(a)intel.com>
drm/i915/hdmi: Add HDMI 2.0 audio clock recovery N values
Stanislav Lisovskiy <stanislav.lisovskiy(a)intel.com>
drm/dp_mst: Check if primary mstb is null
Marc Zyngier <marc.zyngier(a)arm.com>
drm/rockchip: Allow driver to be shutdown on reboot/kexec
Mike Kravetz <mike.kravetz(a)oracle.com>
mm: migration: fix migration of huge PMD shared pages
Mike Kravetz <mike.kravetz(a)oracle.com>
hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444!
Arnd Bergmann <arnd(a)arndb.de>
lib/ubsan.c: don't mark __ubsan_handle_builtin_unreachable as noreturn
Guenter Roeck <linux(a)roeck-us.net>
configfs: replace strncpy with memcpy
Miklos Szeredi <mszeredi(a)redhat.com>
fuse: fix leaked notify reply
Lukas Czerner <lczerner(a)redhat.com>
fuse: fix use-after-free in fuse_direct_IO()
Maciej W. Rozycki <macro(a)linux-mips.org>
rtc: hctosys: Add missing range error reporting
Scott Mayhew <smayhew(a)redhat.com>
nfsd: COPY and CLONE operations require the saved filehandle to be set
Frank Sorenson <sorenson(a)redhat.com>
sunrpc: correct the computation for page_ptr when truncating
Eric W. Biederman <ebiederm(a)xmission.com>
mount: Prevent MNT_DETACH from disconnecting locked mounts
Eric W. Biederman <ebiederm(a)xmission.com>
mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts
Eric W. Biederman <ebiederm(a)xmission.com>
mount: Retest MNT_LOCKED in do_umount
Vasily Averin <vvs(a)virtuozzo.com>
ext4: fix buffer leak in __ext4_read_dirblock() on error path
Vasily Averin <vvs(a)virtuozzo.com>
ext4: fix buffer leak in ext4_xattr_move_to_block() on error path
Vasily Averin <vvs(a)virtuozzo.com>
ext4: release bs.bh before re-using in ext4_xattr_block_find()
Vasily Averin <vvs(a)virtuozzo.com>
ext4: fix possible leak of s_journal_flag_rwsem in error path
Theodore Ts'o <tytso(a)mit.edu>
ext4: fix possible leak of sbi->s_group_desc_leak in error path
Theodore Ts'o <tytso(a)mit.edu>
ext4: avoid possible double brelse() in add_new_gdb() on error path
Vasily Averin <vvs(a)virtuozzo.com>
ext4: fix missing cleanup if ext4_alloc_flex_bg_array() fails while resizing
Vasily Averin <vvs(a)virtuozzo.com>
ext4: avoid buffer leak in ext4_orphan_add() after prior errors
Vasily Averin <vvs(a)virtuozzo.com>
ext4: fix possible inode leak in the retry loop of ext4_resize_fs()
Vasily Averin <vvs(a)virtuozzo.com>
ext4: avoid potential extra brelse in setup_new_flex_group_blocks()
Vasily Averin <vvs(a)virtuozzo.com>
ext4: add missing brelse() add_new_gdb_meta_bg()'s error path
Vasily Averin <vvs(a)virtuozzo.com>
ext4: add missing brelse() in set_flexbg_block_bitmap()'s error path
Vasily Averin <vvs(a)virtuozzo.com>
ext4: add missing brelse() update_backups()'s error path
Michael Kelley <mikelley(a)microsoft.com>
clockevents/drivers/i8253: Add support for PIT shutdown quirk
Filipe Manana <fdmanana(a)suse.com>
Btrfs: fix data corruption due to cloning of eof block
Robbie Ko <robbieko(a)synology.com>
Btrfs: fix cur_offset in the error case for nocow
H. Peter Anvin (Intel) <hpa(a)zytor.com>
arch/alpha, termios: implement BOTHER, IBSHIFT and termios2
H. Peter Anvin <hpa(a)zytor.com>
termios, tty/tty_baudrate.c: fix buffer overrun
John Garry <john.garry(a)huawei.com>
of, numa: Validate some distance map rules
Arnd Bergmann <arnd(a)arndb.de>
mtd: docg3: don't set conflicting BCH_CONST_PARAMS option
Vasily Khoruzhick <vasilykh(a)arista.com>
netfilter: conntrack: fix calculation of next bucket number in early_drop
Andrea Arcangeli <aarcange(a)redhat.com>
mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
Changwei Ge <ge.changwei(a)h3c.com>
ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry
Greg Edwards <gedwards(a)ddn.com>
vhost/scsi: truncate T10 PI iov_iter to prot_bytes
Gustavo A. R. Silva <gustavo(a)embeddedor.com>
reset: hisilicon: fix potential NULL pointer dereference
Mikulas Patocka <mpatocka(a)redhat.com>
mach64: fix image corruption due to reading accelerator registers
Mikulas Patocka <mpatocka(a)redhat.com>
mach64: fix display corruption on big endian machines
Yan, Zheng <zyan(a)redhat.com>
Revert "ceph: fix dentry leak in splice_dentry()"
Ilya Dryomov <idryomov(a)gmail.com>
libceph: bump CEPH_MSG_MAX_DATA_LEN
Enric Balletbo i Serra <enric.balletbo(a)collabora.com>
clk: rockchip: Fix static checker warning in rockchip_ddrclk_get_parent call
Ronald Wahl <rwahl(a)gmx.de>
clk: at91: Fix division by zero in PLL recalc_rate()
Krzysztof Kozlowski <krzk(a)kernel.org>
clk: s2mps11: Fix matching when built as module and DT node contains compatible
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: fix boot parameters address translation
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: make sure bFLT stack is 16 byte aligned
Max Filippov <jcmvbkbc(a)gmail.com>
xtensa: add NOTES section to the linker script
Huacai Chen <chenhc(a)lemote.com>
MIPS: Loongson-3: Fix BRIDGE irq delivery problem
Huacai Chen <chenhc(a)lemote.com>
MIPS: Loongson-3: Fix CPU UART irq delivery problem
Helge Deller <deller(a)gmx.de>
parisc: Fix exported address of os_hpmc handler
Helge Deller <deller(a)gmx.de>
parisc: Fix HPMC handler by increasing size to multiple of 16 bytes
Helge Deller <deller(a)gmx.de>
parisc: Align os_hpmc_size on word boundary
Kees Cook <keescook(a)chromium.org>
bna: ethtool: Avoid reading past end of buffer
Vincenzo Maffione <v.maffione(a)gmail.com>
e1000: fix race condition between e1000_down() and e1000_watchdog
Colin Ian King <colin.king(a)canonical.com>
e1000: avoid null pointer dereference on invalid stat type
Michal Hocko <mhocko(a)suse.com>
mm: do not bug_on on incorrect length in __mm_populate()
Miklos Szeredi <mszeredi(a)redhat.com>
fuse: set FR_SENT while locked
Miklos Szeredi <mszeredi(a)redhat.com>
fuse: fix blocked_waitq wakeup
Kirill Tkhai <ktkhai(a)virtuozzo.com>
fuse: Fix use-after-free in fuse_dev_do_write()
Kirill Tkhai <ktkhai(a)virtuozzo.com>
fuse: Fix use-after-free in fuse_dev_do_read()
Quinn Tran <quinn.tran(a)cavium.com>
scsi: qla2xxx: shutdown chip if reset fail
Himanshu Madhani <himanshu.madhani(a)cavium.com>
scsi: qla2xxx: Fix incorrect port speed being set for FC adapters
Young_X <YangX92(a)hotmail.com>
cdrom: fix improper type cast, which can leat to information leak.
Dominique Martinet <dominique.martinet(a)cea.fr>
9p: clear dangling pointers in p9stat_free
Dominique Martinet <dominique.martinet(a)cea.fr>
9p locks: fix glock.client_id leak in do_lock
Breno Leitao <leitao(a)debian.org>
powerpc/selftests: Wait all threads to join
Marco Felsch <m.felsch(a)pengutronix.de>
media: tvp5150: fix width alignment during set_selection()
Phil Elwell <phil(a)raspberrypi.org>
sc16is7xx: Fix for multi-channel stall
Huacai Chen <chenhc(a)lemote.com>
MIPS/PCI: Call pcie_bus_configure_settings() to set MPS/MRRS
Joel Stanley <joel(a)jms.id.au>
powerpc/boot: Ensure _zimage_start is a weak symbol
Dengcheng Zhu <dzhu(a)wavecomp.com>
MIPS: kexec: Mark CPU offline before disabling local IRQ
Nicholas Mc Guire <hofrat(a)osadl.org>
media: pci: cx23885: handle adding to list failure
Tomi Valkeinen <tomi.valkeinen(a)ti.com>
drm/omap: fix memory barrier bug in DMM driver
Daniel Axtens <dja(a)axtens.net>
powerpc/nohash: fix undefined behaviour when testing page size support
Fabio Estevam <fabio.estevam(a)nxp.com>
ARM: imx_v6_v7_defconfig: Select CONFIG_TMPFS_POSIX_ACL
Miles Chen <miles.chen(a)mediatek.com>
tty: check name length in tty_find_polling_driver()
Sam Bobroff <sbobroff(a)linux.ibm.com>
powerpc/eeh: Fix possible null deref in eeh_dump_dev_log()
-------------
Diffstat:
Makefile | 4 +-
arch/alpha/include/asm/termios.h | 8 +++-
arch/alpha/include/uapi/asm/ioctls.h | 5 ++
arch/alpha/include/uapi/asm/termbits.h | 17 +++++++
arch/arm/configs/imx_v6_v7_defconfig | 1 +
arch/arm/kvm/arm.c | 4 +-
arch/mips/include/asm/mach-loongson64/irq.h | 2 +-
arch/mips/kernel/crash.c | 3 ++
arch/mips/kernel/machine_kexec.c | 3 ++
arch/mips/loongson64/loongson-3/irq.c | 56 +++-------------------
arch/mips/pci/pci-legacy.c | 4 ++
arch/parisc/kernel/hpmc.S | 10 ++--
arch/powerpc/boot/crt0.S | 4 +-
arch/powerpc/kernel/eeh.c | 5 ++
arch/powerpc/mm/tlb_nohash.c | 3 ++
arch/xtensa/boot/Makefile | 2 +-
arch/xtensa/include/asm/processor.h | 6 ++-
arch/xtensa/kernel/head.S | 7 ++-
arch/xtensa/kernel/vmlinux.lds.S | 1 +
drivers/cdrom/cdrom.c | 2 +-
drivers/clk/at91/clk-pll.c | 3 ++
drivers/clk/clk-s2mps11.c | 30 ++++++++++++
drivers/clk/hisilicon/reset.c | 5 +-
drivers/clk/rockchip/clk-ddr.c | 4 --
drivers/clocksource/i8253.c | 14 +++++-
drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++
drivers/gpu/drm/i915/intel_audio.c | 17 +++++++
drivers/gpu/drm/i915/intel_lrc.c | 14 +++++-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++++
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 +++
drivers/media/i2c/tvp5150.c | 14 ++++--
drivers/media/pci/cx23885/altera-ci.c | 10 ++++
drivers/mtd/devices/Kconfig | 2 +-
drivers/net/ethernet/brocade/bna/bnad_ethtool.c | 4 +-
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 9 ++--
drivers/net/ethernet/intel/e1000/e1000_main.c | 11 ++++-
drivers/of/of_numa.c | 9 +++-
drivers/rtc/hctosys.c | 4 +-
drivers/scsi/qla2xxx/qla_init.c | 2 +-
drivers/scsi/qla2xxx/qla_mbx.c | 5 +-
drivers/tty/serial/sc16is7xx.c | 19 +++++---
drivers/tty/tty_io.c | 2 +-
drivers/tty/tty_ioctl.c | 4 +-
drivers/vhost/scsi.c | 4 +-
drivers/video/fbdev/aty/mach64_accel.c | 28 +++++------
fs/9p/vfs_file.c | 16 ++++++-
fs/btrfs/inode.c | 5 +-
fs/btrfs/ioctl.c | 12 ++++-
fs/ceph/inode.c | 8 +++-
fs/configfs/symlink.c | 2 +-
fs/ext4/namei.c | 5 +-
fs/ext4/resize.c | 28 ++++++-----
fs/ext4/super.c | 17 +++----
fs/ext4/xattr.c | 4 ++
fs/fuse/dev.c | 29 +++++++++---
fs/fuse/file.c | 4 +-
fs/namespace.c | 22 +++++++--
fs/nfsd/nfs4proc.c | 3 ++
fs/ocfs2/dir.c | 3 +-
include/linux/ceph/libceph.h | 8 +++-
include/linux/hugetlb.h | 14 ++++++
include/linux/i8253.h | 1 +
include/linux/mm.h | 6 +++
lib/ubsan.c | 3 +-
mm/gup.c | 2 -
mm/hugetlb.c | 60 +++++++++++++++++++++---
mm/mempolicy.c | 32 ++++++++++++-
mm/mmap.c | 19 ++++----
mm/rmap.c | 56 ++++++++++++++++++++++
net/9p/protocol.c | 5 ++
net/netfilter/nf_conntrack_core.c | 13 +++--
net/sunrpc/xdr.c | 5 +-
tools/testing/selftests/powerpc/tm/tm-tmspr.c | 27 +++++++----
73 files changed, 580 insertions(+), 210 deletions(-)
On Tue, Nov 20, 2018 at 01:25:30PM +0000, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.19.2, v4.18.19, v4.14.81, v4.9.137, v4.4.163, v3.18.125.
>
> v4.19.2: Build OK!
> v4.18.19: Build OK!
> v4.14.81: Build OK!
> v4.9.137: Failed to apply! Possible dependencies:
> Unable to calculate
AFAIR, Victoria asked about this fix a while ago. CCed.
Victoria, do you still need this patch in your 4.9? If so, you might
wanna give it a try:
https://git.kernel.org/tip/68239654acafe6aad5a3c1dc7237e60accfebc03
Let us know if you need help backporting - it should be easy though.
HTH.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: vicodec: fix memchr() kernel oops
Author: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Sat Nov 17 06:25:08 2018 -0500
The size passed to memchr is too large as it assumes the search
starts at the start of the buffer, but it can start at an offset.
Cc: <stable(a)vger.kernel.org> # for v4.19 and up
Signed-off-by: Hans Verkuil <hverkuil(a)xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org>
drivers/media/platform/vicodec/vicodec-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
---
diff --git a/drivers/media/platform/vicodec/vicodec-core.c b/drivers/media/platform/vicodec/vicodec-core.c
index b292cff26c86..013cdebecbc4 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -304,7 +304,8 @@ restart:
for (; p < p_out + sz; p++) {
u32 copy;
- p = memchr(p, magic[ctx->comp_magic_cnt], sz);
+ p = memchr(p, magic[ctx->comp_magic_cnt],
+ p_out + sz - p);
if (!p) {
ctx->comp_magic_cnt = 0;
break;
To change the active state of an MMIO, halt is requested for all vcpus of
the affected guest before modifying the IRQ state. This is done by calling
cond_resched_lock() in vgic_mmio_change_active(). However interrupts are
disabled at this point and running a vcpu cannot get rescheduled.
Solve this by waiting for all vcpus to be halted after emmiting the halt
request.
Fixes commit 6c1b7521f4a07cc63bbe2dfe290efed47cdb780a ("KVM: arm/arm64:
Factor out functionality to get vgic mmio requester_vcpu")
Signed-off-by: Julien Thierry <julien.thierry(a)arm.com>
Suggested-by: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Christoffer Dall <christoffer.dall(a)arm.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: stable(a)vger.kernel.org
---
virt/kvm/arm/vgic/vgic-mmio.c | 33 +++++++++++----------------------
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index f56ff1c..eefd877 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -313,27 +313,6 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
spin_lock_irqsave(&irq->irq_lock, flags);
- /*
- * If this virtual IRQ was written into a list register, we
- * have to make sure the CPU that runs the VCPU thread has
- * synced back the LR state to the struct vgic_irq.
- *
- * As long as the conditions below are true, we know the VCPU thread
- * may be on its way back from the guest (we kicked the VCPU thread in
- * vgic_change_active_prepare) and still has to sync back this IRQ,
- * so we release and re-acquire the spin_lock to let the other thread
- * sync back the IRQ.
- *
- * When accessing VGIC state from user space, requester_vcpu is
- * NULL, which is fine, because we guarantee that no VCPUs are running
- * when accessing VGIC state from user space so irq->vcpu->cpu is
- * always -1.
- */
- while (irq->vcpu && /* IRQ may have state in an LR somewhere */
- irq->vcpu != requester_vcpu && /* Current thread is not the VCPU thread */
- irq->vcpu->cpu != -1) /* VCPU thread is running */
- cond_resched_lock(&irq->irq_lock);
-
if (irq->hw) {
vgic_hw_irq_change_active(vcpu, irq, active, !requester_vcpu);
} else {
@@ -368,8 +347,18 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
*/
static void vgic_change_active_prepare(struct kvm_vcpu *vcpu, u32 intid)
{
- if (intid > VGIC_NR_PRIVATE_IRQS)
+ if (intid > VGIC_NR_PRIVATE_IRQS) {
+ struct kvm_vcpu *tmp;
+ int i;
+
kvm_arm_halt_guest(vcpu->kvm);
+
+ /* Wait for each vcpu to be halted */
+ kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
+ while (tmp->cpu != -1)
+ cond_resched();
+ }
+ }
}
/* See vgic_change_active_prepare */
--
1.9.1
On Tue, Nov 20, 2018 at 08:18:57PM +0530, Harsh Shandilya wrote:
> On 20 November 2018 4:46:13 PM IST, Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote:
> >On Tue, Nov 20, 2018 at 04:09:05PM +0530, Harsh Shandilya wrote:
> >> On 19 November 2018 9:58:42 PM IST, Greg Kroah-Hartman
> ><gregkh(a)linuxfoundation.org> wrote:
> >> >This is the start of the stable review cycle for the 3.18.126
> >release.
> >> >There are 90 patches in this series, all will be posted as a
> >response
> >> >to this one. If anyone has any issues with these being applied,
> >please
> >> >let me know.
> >> >
> >> >Responses should be made by Wed Nov 21 16:25:28 UTC 2018.
> >> >Anything received after that time might be too late.
> >> >
> >> >The whole patch series can be found in one patch at:
> >>
> >> https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.126-r…
> >> >or in the git tree and branch at:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> >linux-3.18.y
> >> >and the diffstat can be found below.
> >> >
> >> >thanks,
> >> >
> >> >greg k-h
> >> Peachy as always on the OnePlus 3(T).
> >>
> >> P.S. Not tired of this old-ass tree yet? :P
> >
> >I am very tired of it, but it turns out lots of people still depend on
> >it, so I'll keep it around for a while longer :(
> >
> >thanks for testing,
> >
> >greg k-h
>
> That's just sad. Anybody using this outside Android?
Not that I know of. And really, they better not be, as it is NOT a
kernel one should use anywhere else at this point in time...
thanks,
greg k-h
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: 857962e4c7ee Linux 4.19.3-rc1
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Patch merge: OK
Compile: OK
Hardware test: FAILED
One or more hardware tests failed:
x86_64: PASSED
powerpc: FAILED
Test name: /kernel/distribution/ltp/lite
powerpc: PASSED
arm64: PASSED
We hope that these logs can help you find the problem quickly. For the full
detail on our testing procedures, please scroll to the bottom of this message.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( I ) Continuous
`-',-.`-' Kernel
( K ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 4 architectures:
x86_64:
make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg
configuration: https://artifacts.cki-project.org/builds/x86_64/857962e4c7ee68cec7bbf720850…
powerpc:
make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg
configuration: https://artifacts.cki-project.org/builds/ppc64/857962e4c7ee68cec7bbf720850c…
powerpc:
make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg
configuration: https://artifacts.cki-project.org/builds/ppc64le/857962e4c7ee68cec7bbf72085…
arm64:
make options: make INSTALL_MOD_STRIP=1 -j56 targz-pkg
configuration: https://artifacts.cki-project.org/builds/aarch64/857962e4c7ee68cec7bbf72085…
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm644x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 0720da7809a6..f25b508a831b 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -498,6 +498,8 @@ static struct resource dm644_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm644_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 71,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/da830.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 0bc5bd2665df..822d2590fbc9 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -759,6 +759,8 @@ static struct davinci_id da830_ids[] = {
};
static struct davinci_gpio_platform_data da830_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 128,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm355.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9f7d38d12c88..73f2f70ce729 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -554,6 +554,8 @@ static struct resource dm355_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm355_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 104,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm646x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 6bd2ed069d0d..158f5908a0f0 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -448,6 +448,8 @@ static struct resource dm646x_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm646x_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 43,
};
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/dm365.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index abcf2a5ed89b..c8e66d8745b7 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -273,6 +273,8 @@ static struct resource dm365_gpio_resources[] = {
};
static struct davinci_gpio_platform_data dm365_gpio_platform_data = {
+ .no_auto_base = true,
+ .base = 0,
.ngpio = 104,
.gpio_unbanked = 8,
};
--
2.19.1
The PixArt OEM mice are known for disconnecting every minute in
runlevel 1 or 3 if they are not always polled. So add quirk
ALWAYS_POLL for two Primax mice as well.
0x4e22 is the Dell MS111-P and 0x4d0f is the unbranded HP Portia
mouse HP 697738-001. Both were built until approx. 2014.
Those were the standard mice from those vendors and are still
around - even as new old stock.
Reference: https://github.com/sriemer/fix-linux-mouse/issues/11
Signed-off-by: Sebastian Parschauer <sparschauer(a)suse.de>
CC: stable(a)vger.kernel.org
---
drivers/hid/hid-ids.h | 2 ++
drivers/hid/hid-quirks.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2114ac647bef..ed35c9a9a110 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1210,6 +1210,8 @@
#define USB_DEVICE_ID_PRIMAX_MOUSE_4D22 0x4d22
#define USB_DEVICE_ID_PRIMAX_KEYBOARD 0x4e05
#define USB_DEVICE_ID_PRIMAX_REZEL 0x4e72
+#define USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F 0x4d0f
+#define USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4E22 0x4e22
#define USB_VENDOR_ID_RISO_KAGAKU 0x1294 /* Riso Kagaku Corp. */
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index d82e5ab48837..c85a79986b6a 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -130,6 +130,8 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_MOUSE_4D22), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4E22), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRODIGE, USB_DEVICE_ID_PRODIGE_CORDLESS), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3001), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH_3003), HID_QUIRK_NOGET },
--
2.13.7
This is a note to let you know that I've just added the patch titled
usb: cdc-acm: add entry for Hiro (Conexant) modem
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 63529eaa6164ef7ab4b907b25ac3648177e5e78f Mon Sep 17 00:00:00 2001
From: Maarten Jacobs <maarten256(a)outlook.com>
Date: Mon, 19 Nov 2018 23:18:49 +0000
Subject: usb: cdc-acm: add entry for Hiro (Conexant) modem
The cdc-acm kernel module currently does not support the Hiro (Conexant)
H05228 USB modem. The patch below adds the device specific information:
idVendor 0x0572
idProduct 0x1349
Signed-off-by: Maarten Jacobs <maarten256(a)outlook.com>
Acked-by: Oliver Neukum <oneukum(a)suse.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/class/cdc-acm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 47d75c20c211..1b68fed464cb 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1696,6 +1696,9 @@ static const struct usb_device_id acm_ids[] = {
{ USB_DEVICE(0x0572, 0x1328), /* Shiro / Aztech USB MODEM UM-3100 */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},
+ { USB_DEVICE(0x0572, 0x1349), /* Hiro (Conexant) USB MODEM H50228 */
+ .driver_info = NO_UNION_NORMAL, /* has no union descriptor */
+ },
{ USB_DEVICE(0x20df, 0x0001), /* Simtec Electronics Entropy Key */
.driver_info = QUIRK_CONTROL_LINE_STATE, },
{ USB_DEVICE(0x2184, 0x001c) }, /* GW Instek AFG-2225 */
--
2.19.1
stable-rc/linux-3.18.y build: 183 builds: 0 failed, 183 passed, 291 warnings (v3.18.125-89-g968849030780)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125-8…
Tree: stable-rc
Branch: linux-3.18.y
Git Describe: v3.18.125-89-g968849030780
Git Commit: 96884903078008c1d796add463633bb1337fed53
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 4 unique architectures
Warnings Detected:
arm64: gcc version 7.3.0 (Debian 7.3.0-28)
allnoconfig: 2 warnings
defconfig: 2 warnings
tinyconfig: 2 warnings
arm: gcc version 7.3.0 (Debian 7.3.0-28)
acs5k_defconfig: 2 warnings
acs5k_tiny_defconfig: 2 warnings
allnoconfig: 2 warnings
am200epdkit_defconfig: 2 warnings
ape6evm_defconfig: 2 warnings
armadillo800eva_defconfig: 2 warnings
assabet_defconfig: 2 warnings
at91_dt_defconfig: 2 warnings
at91rm9200_defconfig: 2 warnings
at91sam9260_9g20_defconfig: 2 warnings
at91sam9261_9g10_defconfig: 2 warnings
at91sam9263_defconfig: 2 warnings
at91sam9g45_defconfig: 2 warnings
at91sam9rl_defconfig: 2 warnings
at91x40_defconfig: 2 warnings
axm55xx_defconfig: 2 warnings
badge4_defconfig: 2 warnings
bcm2835_defconfig: 2 warnings
bcm_defconfig: 2 warnings
bockw_defconfig: 2 warnings
cerfcube_defconfig: 2 warnings
clps711x_defconfig: 2 warnings
cm_x2xx_defconfig: 2 warnings
cm_x300_defconfig: 2 warnings
cns3420vb_defconfig: 2 warnings
colibri_pxa270_defconfig: 2 warnings
colibri_pxa300_defconfig: 2 warnings
collie_defconfig: 2 warnings
corgi_defconfig: 2 warnings
davinci_all_defconfig: 2 warnings
dove_defconfig: 2 warnings
ebsa110_defconfig: 2 warnings
efm32_defconfig: 2 warnings
em_x270_defconfig: 2 warnings
ep93xx_defconfig: 2 warnings
eseries_pxa_defconfig: 2 warnings
exynos_defconfig: 2 warnings
ezx_defconfig: 2 warnings
footbridge_defconfig: 2 warnings
h3600_defconfig: 2 warnings
h5000_defconfig: 2 warnings
hackkit_defconfig: 2 warnings
hisi_defconfig: 2 warnings
imote2_defconfig: 2 warnings
imx_v4_v5_defconfig: 2 warnings
imx_v6_v7_defconfig: 2 warnings
integrator_defconfig: 2 warnings
iop13xx_defconfig: 2 warnings
iop32x_defconfig: 2 warnings
iop33x_defconfig: 2 warnings
ixp4xx_defconfig: 2 warnings
jornada720_defconfig: 2 warnings
keystone_defconfig: 2 warnings
koelsch_defconfig: 2 warnings
ks8695_defconfig: 2 warnings
kzm9g_defconfig: 2 warnings
lager_defconfig: 2 warnings
lart_defconfig: 2 warnings
lpc32xx_defconfig: 2 warnings
lpd270_defconfig: 2 warnings
lubbock_defconfig: 2 warnings
mackerel_defconfig: 2 warnings
magician_defconfig: 2 warnings
mainstone_defconfig: 2 warnings
marzen_defconfig: 2 warnings
mini2440_defconfig: 2 warnings
mmp2_defconfig: 2 warnings
moxart_defconfig: 2 warnings
msm_defconfig: 2 warnings
multi_v5_defconfig: 2 warnings
multi_v7_defconfig: 2 warnings
mv78xx0_defconfig: 2 warnings
mvebu_v5_defconfig: 2 warnings
mvebu_v7_defconfig: 2 warnings
mxs_defconfig: 2 warnings
neponset_defconfig: 2 warnings
netwinder_defconfig: 2 warnings
netx_defconfig: 2 warnings
nhk8815_defconfig: 2 warnings
nuc910_defconfig: 2 warnings
nuc950_defconfig: 2 warnings
nuc960_defconfig: 2 warnings
omap1_defconfig: 2 warnings
omap2plus_defconfig: 2 warnings
orion5x_defconfig: 2 warnings
palmz72_defconfig: 2 warnings
pcm027_defconfig: 2 warnings
pleb_defconfig: 2 warnings
prima2_defconfig: 2 warnings
pxa168_defconfig: 2 warnings
pxa255-idp_defconfig: 2 warnings
pxa3xx_defconfig: 2 warnings
pxa910_defconfig: 2 warnings
qcom_defconfig: 2 warnings
raumfeld_defconfig: 2 warnings
realview-smp_defconfig: 2 warnings
realview_defconfig: 2 warnings
rpc_defconfig: 2 warnings
s3c2410_defconfig: 2 warnings
s3c6400_defconfig: 2 warnings
s5pv210_defconfig: 2 warnings
sama5_defconfig: 2 warnings
shannon_defconfig: 2 warnings
shmobile_defconfig: 2 warnings
simpad_defconfig: 2 warnings
socfpga_defconfig: 2 warnings
spear13xx_defconfig: 2 warnings
spear3xx_defconfig: 2 warnings
spear6xx_defconfig: 2 warnings
spitz_defconfig: 2 warnings
sunxi_defconfig: 2 warnings
tct_hammer_defconfig: 2 warnings
tegra_defconfig: 2 warnings
tinyconfig: 2 warnings
trizeps4_defconfig: 2 warnings
u300_defconfig: 2 warnings
u8500_defconfig: 2 warnings
versatile_defconfig: 2 warnings
vexpress_defconfig: 2 warnings
viper_defconfig: 2 warnings
vt8500_v6_v7_defconfig: 2 warnings
xcep_defconfig: 2 warnings
zeus_defconfig: 2 warnings
x86: gcc version 7.3.0 (Debian 7.3.0-29)
allnoconfig: 3 warnings
i386_defconfig: 3 warnings
tinyconfig: 3 warnings
x86_64_defconfig: 30 warnings
Warnings summary:
126 scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
126 scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
3 arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
2 include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
1 net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
1 lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
1 kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
1 drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
1 block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
1 block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ape6evm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
armadillo800eva_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
assabet_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91_dt_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91rm9200_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9260_9g20_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9261_9g10_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9263_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9g45_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9rl_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91x40_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ath79_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
badge4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm2835_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bigsur_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bockw_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
capcella_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
clps711x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cns3420vb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cobalt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
collie_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
corgi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
davinci_all_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
db1xxx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
dove_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
e55_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
efm32_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
em_x270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ep93xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
exynos_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ezx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
footbridge_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
h5000_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hackkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hisi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
i386_defconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
imote2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
integrator_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop32x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop33x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ip22_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
jazz_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
keystone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
koelsch_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ks8695_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
kzm9g_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lager_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lasat_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lpd270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ls1b_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mackerel_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
magician_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mainstone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
malta_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
marzen_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mini2440_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
moxart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mpc30x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
msp71xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mv78xx0_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mxs_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
neponset_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netwinder_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nhk8815_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc950_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc960_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap1_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap2plus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
orion5x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
palmz72_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pcm027_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pleb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa168_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qcom_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rb532_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview-smp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
realview_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rm200_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rt305x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s3c6400_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s5pv210_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sama5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3micro_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
shmobile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
simpad_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
socfpga_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear6xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spitz_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sunxi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tb0219_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tegra_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
tinyconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u8500_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
versatile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vexpress_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
viper_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
workpad_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86) — PASS, 0 errors, 30 warnings, 0 section mismatches
Warnings:
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
--------------------------------------------------------------------------------
xcep_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
xway_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
---
For more info write to <info(a)kernelci.org>
CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on some newer F17h
procssors but their revision guide has not been released.
For example,Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx"
and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx",
their CPUID Fn0000_0001_EAX is 0x00810f10 and should have
CPB feature according AMD product specifications, however
their Fn8000_0007_EDX is 0x00006599, indicating they don't
support CPB feature.
Since whole F17h should support CPB, we set the cap for all of
them.
Cc: stable(a)vger.kernel.org
Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com>
---
arch/x86/kernel/cpu/amd.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index eeea634bee0a..37989fa9e620 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -818,12 +818,13 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
static void init_amd_zn(struct cpuinfo_x86 *c)
{
set_cpu_cap(c, X86_FEATURE_ZEN);
+
/*
* Fix erratum 1076: CPB feature bit not being set in CPUID. It affects
- * all up to and including B1.
+ * a lot of Family 17h processors and some models are undocumented, since
+ * whole F17h should support CPB, we set the cap for all of them.
*/
- if (c->x86_model <= 1 && c->x86_stepping <= 1)
- set_cpu_cap(c, X86_FEATURE_CPB);
+ set_cpu_cap(c, X86_FEATURE_CPB);
}
static void init_amd(struct cpuinfo_x86 *c)
--
2.19.1
Commit 93bba24d4b5ad1e5cd8b43f64e66ff9d6355dd20 upstream.
Function btrfs_trim_fs() doesn't handle errors in a consistent way. If
error happens when trimming existing block groups, it will skip the
remaining blocks and continue to trim unallocated space for each device.
The return value will only reflect the final error from device trimming.
This patch will fix such behavior by:
1) Recording the last error from block group or device trimming
The return value will also reflect the last error during trimming.
Make developer more aware of the problem.
2) Continuing trimming if possible
If we failed to trim one block group or device, we could still try
the next block group or device.
3) Report number of failures during block group and device trimming
It would be less noisy, but still gives user a brief summary of
what's going wrong.
Such behavior can avoid confusion for cases like failure to trim the
first block group and then only unallocated space is trimmed.
Reported-by: Chris Murphy <lists(a)colorremedies.com>
CC: stable(a)vger.kernel.org # 4.9
Signed-off-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ add bg_ret and dev_ret to the messages ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
---
fs/btrfs/extent-tree.c | 40 +++++++++++++++++++++++++++++-----------
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 6661116c47d9..4f28fef9dc7f 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -11124,6 +11124,10 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
u64 end;
u64 trimmed = 0;
u64 total_bytes = btrfs_super_total_bytes(fs_info->super_copy);
+ u64 bg_failed = 0;
+ u64 dev_failed = 0;
+ int bg_ret = 0;
+ int dev_ret = 0;
int ret = 0;
/*
@@ -11134,7 +11138,7 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
else
cache = btrfs_lookup_block_group(fs_info, range->start);
- while (cache) {
+ for (; cache; cache = next_block_group(fs_info->tree_root, cache)) {
if (cache->key.objectid >= (range->start + range->len)) {
btrfs_put_block_group(cache);
break;
@@ -11148,13 +11152,15 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
if (!block_group_cache_done(cache)) {
ret = cache_block_group(cache, 0);
if (ret) {
- btrfs_put_block_group(cache);
- break;
+ bg_failed++;
+ bg_ret = ret;
+ continue;
}
ret = wait_block_group_cache_done(cache);
if (ret) {
- btrfs_put_block_group(cache);
- break;
+ bg_failed++;
+ bg_ret = ret;
+ continue;
}
}
ret = btrfs_trim_block_group(cache,
@@ -11165,28 +11171,40 @@ int btrfs_trim_fs(struct btrfs_root *root, struct fstrim_range *range)
trimmed += group_trimmed;
if (ret) {
- btrfs_put_block_group(cache);
- break;
+ bg_failed++;
+ bg_ret = ret;
+ continue;
}
}
-
- cache = next_block_group(fs_info->tree_root, cache);
}
+ if (bg_failed)
+ btrfs_warn(fs_info,
+ "failed to trim %llu block group(s), last error %d",
+ bg_failed, bg_ret);
mutex_lock(&root->fs_info->fs_devices->device_list_mutex);
devices = &root->fs_info->fs_devices->alloc_list;
list_for_each_entry(device, devices, dev_alloc_list) {
ret = btrfs_trim_free_extents(device, range->minlen,
&group_trimmed);
- if (ret)
+ if (ret) {
+ dev_failed++;
+ dev_ret = ret;
break;
+ }
trimmed += group_trimmed;
}
mutex_unlock(&root->fs_info->fs_devices->device_list_mutex);
+ if (dev_failed)
+ btrfs_warn(fs_info,
+ "failed to trim %llu device(s), last error %d",
+ dev_failed, dev_ret);
range->len = trimmed;
- return ret;
+ if (bg_ret)
+ return bg_ret;
+ return dev_ret;
}
/*
--
2.19.1
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
We now have the option to specify the GPIO base manually for davinci,
so add the relevant fields to platform data.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
arch/arm/mach-davinci/da850.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4528bbf0c861..e7b78df2bfef 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -719,7 +719,9 @@ int __init da850_register_vpif_capture(struct vpif_capture_config
}
static struct davinci_gpio_platform_data da850_gpio_platform_data = {
- .ngpio = 144,
+ .no_auto_base = true,
+ .base = 0,
+ .ngpio = 144,
};
int __init da850_register_gpio(void)
--
2.19.1
From: Larry Finger <Larry.Finger(a)lwfinger.net>
The cordic routine for calculating sines and cosines that was added in
commit 6f98e62a9f1b ("b43: update cordic code to match current specs")
contains an error whereby a quantity declared u32 can in fact go negative.
This problem was detected by Priit Laes who is switching b43 to use the
routine in the library functions of the kernel.
Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)")
Reported-by: Priit Laes <plaes(a)plaes.org>
Cc: Rafał Miłecki <zajec5(a)gmail.com>
Cc: Stable <stable(a)vger.kernel.org> # 2.6.34
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Signed-off-by: Priit Laes <plaes(a)plaes.org>
---
drivers/net/wireless/broadcom/b43/phy_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/b43/phy_common.c b/drivers/net/wireless/broadcom/b43/phy_common.c
index 85f2ca9..ef3ffa5 100644
--- a/drivers/net/wireless/broadcom/b43/phy_common.c
+++ b/drivers/net/wireless/broadcom/b43/phy_common.c
@@ -616,7 +616,7 @@ struct b43_c32 b43_cordic(int theta)
u8 i;
s32 tmp;
s8 signx = 1;
- u32 angle = 0;
+ s32 angle = 0;
struct b43_c32 ret = { .i = 39797, .q = 0, };
while (theta > (180 << 16))
--
git-series 0.9.1
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ceadddde8875bda7af3824244de3d93e386d08c1 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Mon, 8 Oct 2018 12:57:34 +0200
Subject: [PATCH] mach64: detect the dot clock divider correctly on sparc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Sun Ultra 5, it happens that the dot clock is not set up properly for
some videomodes. For example, if we set the videomode "r1024x768x60" in
the firmware, Linux would incorrectly set a videomode with refresh rate
180Hz when booting (suprisingly, my LCD monitor can display it, although
display quality is very low).
The reason is this: Older mach64 cards set the divider in the register
VCLK_POST_DIV. The register has four 2-bit fields (the field that is
actually used is specified in the lowest two bits of the register
CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
there's another bit added - the top four bits of PLL_EXT_CNTL extend the
divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
them, so it can work regardless if the card supports them. However, the
sparc64 firmware may set these extended dividers during boot - and the
mach64 driver detects incorrect dot clock in this case.
This patch makes the driver read the additional divider bit from
PLL_EXT_CNTL and calculate the initial refresh rate properly.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Acked-by: David S. Miller <davem(a)davemloft.net>
Reviewed-by: Ville Syrjälä <syrjala(a)sci.fi>
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
diff --git a/drivers/video/fbdev/aty/atyfb.h b/drivers/video/fbdev/aty/atyfb.h
index 8235b285dbb2..d09bab3bf224 100644
--- a/drivers/video/fbdev/aty/atyfb.h
+++ b/drivers/video/fbdev/aty/atyfb.h
@@ -333,6 +333,8 @@ extern const struct aty_pll_ops aty_pll_ct; /* Integrated */
extern void aty_set_pll_ct(const struct fb_info *info, const union aty_pll *pll);
extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
+extern const u8 aty_postdividers[8];
+
/*
* Hardware cursor support
@@ -359,7 +361,6 @@ static inline void wait_for_idle(struct atyfb_par *par)
extern void aty_reset_engine(const struct atyfb_par *par);
extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
-extern u8 aty_ld_pll_ct(int offset, const struct atyfb_par *par);
void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
void atyfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c
index a9a8272f7a6e..05111e90f168 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3087,17 +3087,18 @@ static int atyfb_setup_sparc(struct pci_dev *pdev, struct fb_info *info,
/*
* PLL Reference Divider M:
*/
- M = pll_regs[2];
+ M = pll_regs[PLL_REF_DIV];
/*
* PLL Feedback Divider N (Dependent on CLOCK_CNTL):
*/
- N = pll_regs[7 + (clock_cntl & 3)];
+ N = pll_regs[VCLK0_FB_DIV + (clock_cntl & 3)];
/*
* PLL Post Divider P (Dependent on CLOCK_CNTL):
*/
- P = 1 << (pll_regs[6] >> ((clock_cntl & 3) << 1));
+ P = aty_postdividers[((pll_regs[VCLK_POST_DIV] >> ((clock_cntl & 3) << 1)) & 3) |
+ ((pll_regs[PLL_EXT_CNTL] >> (2 + (clock_cntl & 3))) & 4)];
/*
* PLL Divider Q:
diff --git a/drivers/video/fbdev/aty/mach64_ct.c b/drivers/video/fbdev/aty/mach64_ct.c
index 74a62aa193c0..f87cc81f4fa2 100644
--- a/drivers/video/fbdev/aty/mach64_ct.c
+++ b/drivers/video/fbdev/aty/mach64_ct.c
@@ -115,7 +115,7 @@ static void aty_st_pll_ct(int offset, u8 val, const struct atyfb_par *par)
*/
#define Maximum_DSP_PRECISION 7
-static u8 postdividers[] = {1,2,4,8,3};
+const u8 aty_postdividers[8] = {1,2,4,8,3,5,6,12};
static int aty_dsp_gt(const struct fb_info *info, u32 bpp, struct pll_ct *pll)
{
@@ -222,7 +222,7 @@ static int aty_valid_pll_ct(const struct fb_info *info, u32 vclk_per, struct pll
pll->vclk_post_div += (q < 64*8);
pll->vclk_post_div += (q < 32*8);
}
- pll->vclk_post_div_real = postdividers[pll->vclk_post_div];
+ pll->vclk_post_div_real = aty_postdividers[pll->vclk_post_div];
// pll->vclk_post_div <<= 6;
pll->vclk_fb_div = q * pll->vclk_post_div_real / 8;
pllvclk = (1000000 * 2 * pll->vclk_fb_div) /
@@ -513,7 +513,7 @@ static int aty_init_pll_ct(const struct fb_info *info, union aty_pll *pll)
u8 mclk_fb_div, pll_ext_cntl;
pll->ct.pll_ref_div = aty_ld_pll_ct(PLL_REF_DIV, par);
pll_ext_cntl = aty_ld_pll_ct(PLL_EXT_CNTL, par);
- pll->ct.xclk_post_div_real = postdividers[pll_ext_cntl & 0x07];
+ pll->ct.xclk_post_div_real = aty_postdividers[pll_ext_cntl & 0x07];
mclk_fb_div = aty_ld_pll_ct(MCLK_FB_DIV, par);
if (pll_ext_cntl & PLL_MFB_TIMES_4_2B)
mclk_fb_div <<= 1;
@@ -535,7 +535,7 @@ static int aty_init_pll_ct(const struct fb_info *info, union aty_pll *pll)
xpost_div += (q < 64*8);
xpost_div += (q < 32*8);
}
- pll->ct.xclk_post_div_real = postdividers[xpost_div];
+ pll->ct.xclk_post_div_real = aty_postdividers[xpost_div];
pll->ct.mclk_fb_div = q * pll->ct.xclk_post_div_real / 8;
#ifdef CONFIG_PPC
@@ -584,7 +584,7 @@ static int aty_init_pll_ct(const struct fb_info *info, union aty_pll *pll)
mpost_div += (q < 64*8);
mpost_div += (q < 32*8);
}
- sclk_post_div_real = postdividers[mpost_div];
+ sclk_post_div_real = aty_postdividers[mpost_div];
pll->ct.sclk_fb_div = q * sclk_post_div_real / 8;
pll->ct.spll_cntl2 = mpost_div << 4;
#ifdef DEBUG
commit 10283ea525d30f2e99828978fd04d8427876a7ad upstream.
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
attached to the resource group glocks. That function should release the
buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
gfs2_rgrp_brelse for doing that is missing.
When gfs2_releasepage later runs across these buffers which are still
referenced, it refuses to free them. This causes the pages the buffers
are attached to to remain referenced as well. With enough mount/unmount
cycles, the system will eventually run out of memory.
Fix this by adding the missing call to gfs2_rgrp_brelse in
gfs2_clear_rgrpd.
(Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
Cc: stable(a)vger.kernel.org # v4.4
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
---
fs/gfs2/rgrp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 832824994aae..073126707270 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -715,6 +715,7 @@ void gfs2_clear_rgrpd(struct gfs2_sbd *sdp)
spin_lock(&gl->gl_lockref.lock);
gl->gl_object = NULL;
spin_unlock(&gl->gl_lockref.lock);
+ gfs2_rgrp_brelse(rgd);
gfs2_glock_add_to_lru(gl);
gfs2_glock_put(gl);
}
@@ -1125,7 +1126,7 @@ static u32 count_unlinked(struct gfs2_rgrpd *rgd)
* @rgd: the struct gfs2_rgrpd describing the RG to read in
*
* Read in all of a Resource Group's header and bitmap blocks.
- * Caller must eventually call gfs2_rgrp_relse() to free the bitmaps.
+ * Caller must eventually call gfs2_rgrp_brelse() to free the bitmaps.
*
* Returns: errno
*/
--
2.19.1.546.g028f9c799.dirty
From: Mark Rutland <mark.rutland(a)arm.com>
commit da5a3ce66b8bb51b0ea8a89f42aac153903f90fb upstream.
At boot time, KVM stashes the host MDCR_EL2 value, but only does this
when the kernel is not running in hyp mode (i.e. is non-VHE). In these
cases, the stashed value of MDCR_EL2.HPMN happens to be zero, which can
lead to CONSTRAINED UNPREDICTABLE behaviour.
Since we use this value to derive the MDCR_EL2 value when switching
to/from a guest, after a guest have been run, the performance counters
do not behave as expected. This has been observed to result in accesses
via PMXEVTYPER_EL0 and PMXEVCNTR_EL0 not affecting the relevant
counters, resulting in events not being counted. In these cases, only
the fixed-purpose cycle counter appears to work as expected.
Fix this by always stashing the host MDCR_EL2 value, regardless of VHE.
Cc: Christopher Dall <christoffer.dall(a)arm.com>
Cc: James Morse <james.morse(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: stable(a)vger.kernel.org
Fixes: 1e947bad0b63b351 ("arm64: KVM: Skip HYP setup when already running in HYP")
Tested-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
---
arch/arm/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 20436972537f..a670c70f4def 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1092,8 +1092,6 @@ static void cpu_init_hyp_mode(void *dummy)
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
-
- kvm_arm_init_debug();
}
static void cpu_hyp_reinit(void)
@@ -1108,6 +1106,8 @@ static void cpu_hyp_reinit(void)
if (__hyp_get_vectors() == hyp_default_vectors)
cpu_init_hyp_mode(NULL);
}
+
+ kvm_arm_init_debug();
}
static void cpu_hyp_reset(void)
--
2.19.1
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f9005571701920551bcf54a500973fb61f2e1eda Mon Sep 17 00:00:00 2001
From: Stefano Stabellini <stefanos(a)xilinx.com>
Date: Wed, 31 Oct 2018 16:11:49 -0700
Subject: [PATCH] CONFIG_XEN_PV breaks xen_create_contiguous_region on ARM
xen_create_contiguous_region has now only an implementation if
CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
we do have an implementation of xen_create_contiguous_region which is
required for swiotlb-xen to work correctly (although it just sets
*dma_handle).
Cc: <stable(a)vger.kernel.org> # 4.12
Fixes: 16624390816c ("xen: create xen_create/destroy_contiguous_region() stubs for PVHVM only builds")
Signed-off-by: Stefano Stabellini <stefanos(a)xilinx.com>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
CC: Jeff.Kubascik(a)dornerworks.com
CC: Jarvis.Roach(a)dornerworks.com
CC: Nathan.Studer(a)dornerworks.com
CC: vkuznets(a)redhat.com
CC: boris.ostrovsky(a)oracle.com
CC: jgross(a)suse.com
CC: julien.grall(a)arm.com
Signed-off-by: Juergen Gross <jgross(a)suse.com>
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 18803ff76e27..4969817124a8 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -42,16 +42,12 @@ int xen_setup_shutdown_event(void);
extern unsigned long *xen_contiguous_bitmap;
-#ifdef CONFIG_XEN_PV
+#if defined(CONFIG_XEN_PV) || defined(CONFIG_ARM) || defined(CONFIG_ARM64)
int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
unsigned int address_bits,
dma_addr_t *dma_handle);
void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order);
-
-int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
- xen_pfn_t *pfn, int nr, int *err_ptr, pgprot_t prot,
- unsigned int domid, bool no_translate, struct page **pages);
#else
static inline int xen_create_contiguous_region(phys_addr_t pstart,
unsigned int order,
@@ -63,7 +59,13 @@ static inline int xen_create_contiguous_region(phys_addr_t pstart,
static inline void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order) { }
+#endif
+#if defined(CONFIG_XEN_PV)
+int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
+ xen_pfn_t *pfn, int nr, int *err_ptr, pgprot_t prot,
+ unsigned int domid, bool no_translate, struct page **pages);
+#else
static inline int xen_remap_pfn(struct vm_area_struct *vma, unsigned long addr,
xen_pfn_t *pfn, int nr, int *err_ptr,
pgprot_t prot, unsigned int domid,
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From df5e31c204b34e8d9e5ec33f5b28e960c4f25e14 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 25 Oct 2018 16:05:36 +0300
Subject: [PATCH] drm/i915: Fix ilk+ watermarks when disabling pipes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We're no longer programming any watermarks when we're disabling
a pipe. That means ilk_wm_merge() & co. will keep considering
the any pipe that is getting disabled as still enabled. Thus we
either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal
ones (hsw-bdw).
This seems to have been broken by commit b6b178a77210 ("drm/i915:
Calculate ironlake intermediate watermarks correctly, v2."). Before
that we apparently had some difference between the intermediate
and optimal watermarks and so we would program the optiomal ones.
Now intermediate and optimal are identical for disabled pipes
and so we don't program either.
Fix this by programming the intermediate watermarks even for
disabled pipes. We were already doing that for skl+. We'll
leave out gmch platforms for now since those do the merging
in a different manner and should work as is. We'll want to
unify this eventually, but play it safe for now and just put
in a FIXME.
Cc: stable(a)vger.kernel.org
Cc: Matt Roper <matthew.d.roper(a)intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181025130536.29024-1-ville.…
Reviewed-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> #irc
(cherry picked from commit a748faea3bfd7fd1d1485bc1c426c7d460cc6503)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b8dfdbc9ca1f..23d8008a93bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12768,17 +12768,12 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
intel_check_cpu_fifo_underruns(dev_priv);
intel_check_pch_fifo_underruns(dev_priv);
- if (!new_crtc_state->active) {
- /*
- * Make sure we don't call initial_watermarks
- * for ILK-style watermark updates.
- *
- * No clue what this is supposed to achieve.
- */
- if (INTEL_GEN(dev_priv) >= 9)
- dev_priv->display.initial_watermarks(intel_state,
- to_intel_crtc_state(new_crtc_state));
- }
+ /* FIXME unify this for all platforms */
+ if (!new_crtc_state->active &&
+ !HAS_GMCH_DISPLAY(dev_priv) &&
+ dev_priv->display.initial_watermarks)
+ dev_priv->display.initial_watermarks(intel_state,
+ to_intel_crtc_state(new_crtc_state));
}
}
From: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
Other boards may be broken too, which I haven't tested.
The problem is in the fact that most board files still use the legacy
GPIO API where lines are requested by numbers rather than descriptors.
While this should be fixed eventually, in order to unbreak the board
for now - provide a way to manually specify the GPIO base in platform
data.
Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base selection")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski(a)baylibre.com>
---
drivers/gpio/gpio-davinci.c | 2 +-
include/linux/platform_data/gpio-davinci.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5c1564fcc24e..bdb29e51b417 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -258,7 +258,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.set = davinci_gpio_set;
chips->chip.ngpio = ngpio;
- chips->chip.base = -1;
+ chips->chip.base = pdata->no_auto_base ? pdata->base : -1;
#ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
diff --git a/include/linux/platform_data/gpio-davinci.h b/include/linux/platform_data/gpio-davinci.h
index f92a47e18034..a93841bfb9f7 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -17,6 +17,8 @@
#define __DAVINCI_GPIO_PLATFORM_H
struct davinci_gpio_platform_data {
+ bool no_auto_base;
+ u32 base;
u32 ngpio;
u32 gpio_unbanked;
};
--
2.19.1
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 9b27390139dbe0dc10d1899545248862fe826b61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 3 Oct 2018 17:50:17 +0300
Subject: [PATCH] drm/i915: Use the correct crtc when sanitizing plane mapping
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When we decide that a plane is attached to the wrong pipe we try
to turn off said plane. However we are passing around the crtc we
think that the plane is supposed to be using rather than the crtc
it is currently using. That doesn't work all that well because
we may have to do vblank waits etc. and the other pipe might
not even be enabled here. So let's pass the plane's current crtc to
intel_plane_disable_noatomic() so that it can its job correctly.
To do that semi-cleanly we also have to change the plane readout
to record the plane's visibility into the bitmasks of the crtc
where the plane is currently enabled rather than to the crtc
we want to use for the plane.
One caveat here is that our active_planes bitmask will get confused
if both planes are enabled on the same pipe. Fortunately we can use
plane_mask to reconstruct active_planes sufficiently since
plane_mask still has the same meaning (is the plane visible?)
during readout. We also have to do the same during the initial
plane readout as the second plane could clear the active_planes
bit the first plane had already set.
v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
Add Daniel's proposed comment to better document why we do this
Drop the redundant intel_set_plane_visible() call
Cc: stable(a)vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe
Cc: stable(a)vger.kernel.org
Cc: Dennis <dennis.nezic(a)utoronto.ca>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Tested-by: Dennis <dennis.nezic(a)utoronto.ca>
Tested-by: Peter Nowee <peter.nowee(a)gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181003145017.4527-1-ville.s…
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
(cherry picked from commit 62358aa4ee86481ce044bef04859820e1bc7c1d9)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ce23b0546407..1025d58ea1e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state *crtc_state,
plane_state->base.visible = visible;
- /* FIXME pre-g4x don't work like this */
- if (visible) {
+ if (visible)
crtc_state->base.plane_mask |= drm_plane_mask(&plane->base);
- crtc_state->active_planes |= BIT(plane->id);
- } else {
+ else
crtc_state->base.plane_mask &= ~drm_plane_mask(&plane->base);
- crtc_state->active_planes &= ~BIT(plane->id);
- }
DRM_DEBUG_KMS("%s active planes 0x%x\n",
crtc_state->base.crtc->name,
crtc_state->active_planes);
}
+static void fixup_active_planes(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_plane *plane;
+
+ /*
+ * Active_planes aliases if multiple "primary" or cursor planes
+ * have been used on the same (or wrong) pipe. plane_mask uses
+ * unique ids, hence we can use that to reconstruct active_planes.
+ */
+ crtc_state->active_planes = 0;
+
+ drm_for_each_plane_mask(plane, &dev_priv->drm,
+ crtc_state->base.plane_mask)
+ crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
+}
+
static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane)
{
@@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
to_intel_plane_state(plane->base.state);
intel_set_plane_visible(crtc_state, plane_state, false);
+ fixup_active_planes(crtc_state);
if (plane->id == PLANE_PRIMARY)
intel_pre_disable_primary_noatomic(&crtc->base);
@@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
- struct drm_crtc_state *crtc_state = intel_crtc->base.state;
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
@@ -2900,10 +2913,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
plane_state->fb = fb;
plane_state->crtc = &intel_crtc->base;
- intel_set_plane_visible(to_intel_crtc_state(crtc_state),
- to_intel_plane_state(plane_state),
- true);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
&obj->frontbuffer_bits);
}
@@ -15450,17 +15459,6 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
}
-static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
- struct intel_plane *plane)
-{
- enum pipe pipe;
-
- if (!plane->get_hw_state(plane, &pipe))
- return true;
-
- return pipe == crtc->pipe;
-}
-
static void
intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
{
@@ -15472,13 +15470,20 @@ intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_plane *plane =
to_intel_plane(crtc->base.primary);
+ struct intel_crtc *plane_crtc;
+ enum pipe pipe;
- if (intel_plane_mapping_ok(crtc, plane))
+ if (!plane->get_hw_state(plane, &pipe))
+ continue;
+
+ if (pipe == crtc->pipe)
continue;
DRM_DEBUG_KMS("%s attached to the wrong pipe, disabling plane\n",
plane->base.name);
- intel_plane_disable_noatomic(crtc, plane);
+
+ plane_crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ intel_plane_disable_noatomic(plane_crtc, plane);
}
}
@@ -15646,23 +15651,32 @@ void i915_redisable_vga(struct drm_i915_private *dev_priv)
}
/* FIXME read out full plane state for all planes */
-static void readout_plane_state(struct intel_crtc *crtc)
+static void readout_plane_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state *crtc_state =
- to_intel_crtc_state(crtc->base.state);
struct intel_plane *plane;
+ struct intel_crtc *crtc;
- for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
+ for_each_intel_plane(&dev_priv->drm, plane) {
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
- enum pipe pipe;
+ struct intel_crtc_state *crtc_state;
+ enum pipe pipe = PIPE_A;
bool visible;
visible = plane->get_hw_state(plane, &pipe);
+ crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
intel_set_plane_visible(crtc_state, plane_state, visible);
}
+
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+
+ fixup_active_planes(crtc_state);
+ }
}
static void intel_modeset_readout_hw_state(struct drm_device *dev)
@@ -15694,13 +15708,13 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev)
if (crtc_state->base.active)
dev_priv->active_crtcs |= 1 << crtc->pipe;
- readout_plane_state(crtc);
-
DRM_DEBUG_KMS("[CRTC:%d:%s] hw state readout: %s\n",
crtc->base.base.id, crtc->base.name,
enableddisabled(crtc_state->base.active));
}
+ readout_plane_state(dev_priv);
+
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i];
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 9b27390139dbe0dc10d1899545248862fe826b61 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Wed, 3 Oct 2018 17:50:17 +0300
Subject: [PATCH] drm/i915: Use the correct crtc when sanitizing plane mapping
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When we decide that a plane is attached to the wrong pipe we try
to turn off said plane. However we are passing around the crtc we
think that the plane is supposed to be using rather than the crtc
it is currently using. That doesn't work all that well because
we may have to do vblank waits etc. and the other pipe might
not even be enabled here. So let's pass the plane's current crtc to
intel_plane_disable_noatomic() so that it can its job correctly.
To do that semi-cleanly we also have to change the plane readout
to record the plane's visibility into the bitmasks of the crtc
where the plane is currently enabled rather than to the crtc
we want to use for the plane.
One caveat here is that our active_planes bitmask will get confused
if both planes are enabled on the same pipe. Fortunately we can use
plane_mask to reconstruct active_planes sufficiently since
plane_mask still has the same meaning (is the plane visible?)
during readout. We also have to do the same during the initial
plane readout as the second plane could clear the active_planes
bit the first plane had already set.
v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
Add Daniel's proposed comment to better document why we do this
Drop the redundant intel_set_plane_visible() call
Cc: stable(a)vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state() return the current pipe
Cc: stable(a)vger.kernel.org
Cc: Dennis <dennis.nezic(a)utoronto.ca>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Tested-by: Dennis <dennis.nezic(a)utoronto.ca>
Tested-by: Peter Nowee <peter.nowee(a)gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181003145017.4527-1-ville.s…
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
(cherry picked from commit 62358aa4ee86481ce044bef04859820e1bc7c1d9)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ce23b0546407..1025d58ea1e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state *crtc_state,
plane_state->base.visible = visible;
- /* FIXME pre-g4x don't work like this */
- if (visible) {
+ if (visible)
crtc_state->base.plane_mask |= drm_plane_mask(&plane->base);
- crtc_state->active_planes |= BIT(plane->id);
- } else {
+ else
crtc_state->base.plane_mask &= ~drm_plane_mask(&plane->base);
- crtc_state->active_planes &= ~BIT(plane->id);
- }
DRM_DEBUG_KMS("%s active planes 0x%x\n",
crtc_state->base.crtc->name,
crtc_state->active_planes);
}
+static void fixup_active_planes(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_plane *plane;
+
+ /*
+ * Active_planes aliases if multiple "primary" or cursor planes
+ * have been used on the same (or wrong) pipe. plane_mask uses
+ * unique ids, hence we can use that to reconstruct active_planes.
+ */
+ crtc_state->active_planes = 0;
+
+ drm_for_each_plane_mask(plane, &dev_priv->drm,
+ crtc_state->base.plane_mask)
+ crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
+}
+
static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane)
{
@@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
to_intel_plane_state(plane->base.state);
intel_set_plane_visible(crtc_state, plane_state, false);
+ fixup_active_planes(crtc_state);
if (plane->id == PLANE_PRIMARY)
intel_pre_disable_primary_noatomic(&crtc->base);
@@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
- struct drm_crtc_state *crtc_state = intel_crtc->base.state;
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
@@ -2900,10 +2913,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
plane_state->fb = fb;
plane_state->crtc = &intel_crtc->base;
- intel_set_plane_visible(to_intel_crtc_state(crtc_state),
- to_intel_plane_state(plane_state),
- true);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
&obj->frontbuffer_bits);
}
@@ -15450,17 +15459,6 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
}
-static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
- struct intel_plane *plane)
-{
- enum pipe pipe;
-
- if (!plane->get_hw_state(plane, &pipe))
- return true;
-
- return pipe == crtc->pipe;
-}
-
static void
intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
{
@@ -15472,13 +15470,20 @@ intel_sanitize_plane_mapping(struct drm_i915_private *dev_priv)
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_plane *plane =
to_intel_plane(crtc->base.primary);
+ struct intel_crtc *plane_crtc;
+ enum pipe pipe;
- if (intel_plane_mapping_ok(crtc, plane))
+ if (!plane->get_hw_state(plane, &pipe))
+ continue;
+
+ if (pipe == crtc->pipe)
continue;
DRM_DEBUG_KMS("%s attached to the wrong pipe, disabling plane\n",
plane->base.name);
- intel_plane_disable_noatomic(crtc, plane);
+
+ plane_crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ intel_plane_disable_noatomic(plane_crtc, plane);
}
}
@@ -15646,23 +15651,32 @@ void i915_redisable_vga(struct drm_i915_private *dev_priv)
}
/* FIXME read out full plane state for all planes */
-static void readout_plane_state(struct intel_crtc *crtc)
+static void readout_plane_state(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state *crtc_state =
- to_intel_crtc_state(crtc->base.state);
struct intel_plane *plane;
+ struct intel_crtc *crtc;
- for_each_intel_plane_on_crtc(&dev_priv->drm, crtc, plane) {
+ for_each_intel_plane(&dev_priv->drm, plane) {
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
- enum pipe pipe;
+ struct intel_crtc_state *crtc_state;
+ enum pipe pipe = PIPE_A;
bool visible;
visible = plane->get_hw_state(plane, &pipe);
+ crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
intel_set_plane_visible(crtc_state, plane_state, visible);
}
+
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
+
+ fixup_active_planes(crtc_state);
+ }
}
static void intel_modeset_readout_hw_state(struct drm_device *dev)
@@ -15694,13 +15708,13 @@ static void intel_modeset_readout_hw_state(struct drm_device *dev)
if (crtc_state->base.active)
dev_priv->active_crtcs |= 1 << crtc->pipe;
- readout_plane_state(crtc);
-
DRM_DEBUG_KMS("[CRTC:%d:%s] hw state readout: %s\n",
crtc->base.base.id, crtc->base.name,
enableddisabled(crtc_state->base.active));
}
+ readout_plane_state(dev_priv);
+
for (i = 0; i < dev_priv->num_shared_dpll; i++) {
struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i];
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 4bbf0d4749e707b6b262d576a9a9ef5c63b52dd4 Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Mon, 8 Oct 2018 19:24:34 -0400
Subject: [PATCH] drm/i915: Fix intel_dp_mst_best_encoder()
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-longer-present MSTB ports by
changing the DPMS state to off and this still requires that we retrieve
an encoder.
So, fix this by always returning a valid encoder regardless of the state
of the MST port.
Changes since v1:
- Remove mst atomic helper, since this got replaced with a much simpler
solution
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: stable(a)vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-6-lyude@r…
(cherry picked from commit a9f9ca33d1fe9325f414914be526c0fc4ba5281c)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 0f14c0d1669c..7f155b4f1a7d 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -404,8 +404,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (!READ_ONCE(connector->registered))
- return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From d9a515867bdba59ebf196a6ade10faae8e8be36a Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Tue, 16 Oct 2018 19:00:11 +0300
Subject: [PATCH] drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: Hans de Goede <hdegoede(a)redhat.com>
Cc: <ronald(a)innovation.ch>
Cc: <stable(a)vger.kernel.org>
Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Reported-by: <ronald(a)innovation.ch>
Tested-by: <ronald(a)innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264
Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()")
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016160011.28347-1-imre.d…
(cherry picked from commit 914a4fd8cd28016038ce749a818a836124a8d270)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 1025d58ea1e8..3cd813c21af1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2722,6 +2722,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (size_aligned * 2 > dev_priv->stolen_usable_size)
return false;
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ break;
+ default:
+ DRM_DEBUG_DRIVER("Unsupported modifier for initial FB: 0x%llx\n",
+ fb->modifier);
+ return false;
+ }
+
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen_for_preallocated(dev_priv,
base_aligned,
@@ -2731,8 +2742,17 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
if (!obj)
return false;
- if (plane_config->tiling == I915_TILING_X)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ switch (plane_config->tiling) {
+ case I915_TILING_NONE:
+ break;
+ case I915_TILING_X:
+ case I915_TILING_Y:
+ obj->tiling_and_stride = fb->pitches[0] | plane_config->tiling;
+ break;
+ default:
+ MISSING_CASE(plane_config->tiling);
+ return false;
+ }
mode_cmd.pixel_format = fb->format->format;
mode_cmd.width = fb->width;
@@ -8865,6 +8885,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
+ plane_config->tiling = I915_TILING_Y;
if (val & PLANE_CTL_RENDER_DECOMPRESSION_ENABLE)
fb->modifier = I915_FORMAT_MOD_Y_TILED_CCS;
else
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From de9f8eea5a44b0b756d3d6345af7f8e630a3c8c0 Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 16 Oct 2018 16:39:46 -0400
Subject: [PATCH] drm/atomic_helper: Stop modesets on unregistered connectors
harder
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: David Airlie <airlied(a)linux.ie>
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@r…
(cherry picked from commit 39b50c603878f4f8ae541ac4088a805d588abc79)
Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Fixes: 34ca26a98ad6 ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors")
Cc: stable(a)vger.kernel.org
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index e49b22381048..1cc3a045ec2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -308,6 +308,26 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
+ crtc_state = drm_atomic_get_new_crtc_state(state,
+ new_connector_state->crtc);
+ /*
+ * For compatibility with legacy users, we want to make sure that
+ * we allow DPMS On->Off modesets on unregistered connectors. Modesets
+ * which would result in anything else must be considered invalid, to
+ * avoid turning on new displays on dead connectors.
+ *
+ * Since the connector can be unregistered at any point during an
+ * atomic check or commit, this is racy. But that's OK: all we care
+ * about is ensuring that userspace can't do anything but shut off the
+ * display on a connector that was destroyed after its been notified,
+ * not before.
+ */
+ if (drm_connector_is_unregistered(connector) && crtc_state->active) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
funcs = connector->helper_private;
if (funcs->atomic_best_encoder)
@@ -352,7 +372,6 @@ update_connector_routing(struct drm_atomic_state *state,
set_best_encoder(state, new_connector_state, new_encoder);
- crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc);
crtc_state->connectors_changed = true;
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index a22d6f269b07..d5b7f315098c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -299,27 +299,6 @@ drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
struct drm_connector *connector = conn_state->connector;
struct drm_crtc_state *crtc_state;
- /*
- * For compatibility with legacy users, we want to make sure that
- * we allow DPMS On<->Off modesets on unregistered connectors, since
- * legacy modesetting users will not be expecting these to fail. We do
- * not however, want to allow legacy users to assign a connector
- * that's been unregistered from sysfs to another CRTC, since doing
- * this with a now non-existent connector could potentially leave us
- * in an invalid state.
- *
- * Since the connector can be unregistered at any point during an
- * atomic check or commit, this is racy. But that's OK: all we care
- * about is ensuring that userspace can't use this connector for new
- * configurations after it's been notified that the connector is no
- * longer present.
- */
- if (!READ_ONCE(connector->registered) && crtc) {
- DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
- connector->base.id, connector->name);
- return -EINVAL;
- }
-
if (conn_state->crtc == crtc)
return 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1e40e5decbe9..4943cef178be 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -379,7 +379,8 @@ void drm_connector_cleanup(struct drm_connector *connector)
/* The connector should have been removed from userspace long before
* it is finally destroyed.
*/
- if (WARN_ON(connector->registered))
+ if (WARN_ON(connector->registration_state ==
+ DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
if (connector->tile_group) {
@@ -436,7 +437,7 @@ int drm_connector_register(struct drm_connector *connector)
return 0;
mutex_lock(&connector->mutex);
- if (connector->registered)
+ if (connector->registration_state != DRM_CONNECTOR_INITIALIZING)
goto unlock;
ret = drm_sysfs_connector_add(connector);
@@ -456,7 +457,7 @@ int drm_connector_register(struct drm_connector *connector)
drm_mode_object_register(connector->dev, &connector->base);
- connector->registered = true;
+ connector->registration_state = DRM_CONNECTOR_REGISTERED;
goto unlock;
err_debugfs:
@@ -478,7 +479,7 @@ EXPORT_SYMBOL(drm_connector_register);
void drm_connector_unregister(struct drm_connector *connector)
{
mutex_lock(&connector->mutex);
- if (!connector->registered) {
+ if (connector->registration_state != DRM_CONNECTOR_REGISTERED) {
mutex_unlock(&connector->mutex);
return;
}
@@ -489,7 +490,7 @@ void drm_connector_unregister(struct drm_connector *connector)
drm_sysfs_connector_remove(connector);
drm_debugfs_connector_remove(connector);
- connector->registered = false;
+ connector->registration_state = DRM_CONNECTOR_UNREGISTERED;
mutex_unlock(&connector->mutex);
}
EXPORT_SYMBOL(drm_connector_unregister);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index 7f155b4f1a7d..1b00f8ea145b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -77,7 +77,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
pipe_config->pbn = mst_pbn;
/* Zombie connectors can't have VCPI slots */
- if (READ_ONCE(connector->registered)) {
+ if (!drm_connector_is_unregistered(connector)) {
slots = drm_dp_atomic_find_vcpi_slots(state,
&intel_dp->mst_mgr,
port,
@@ -313,7 +313,7 @@ static int intel_dp_mst_get_ddc_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (!READ_ONCE(connector->registered))
+ if (drm_connector_is_unregistered(connector))
return intel_connector_update_modes(connector, NULL);
edid = drm_dp_mst_get_edid(connector, &intel_dp->mst_mgr, intel_connector->port);
@@ -329,7 +329,7 @@ intel_dp_mst_detect(struct drm_connector *connector, bool force)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
- if (!READ_ONCE(connector->registered))
+ if (drm_connector_is_unregistered(connector))
return connector_status_disconnected;
return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
@@ -372,7 +372,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
int bpp = 24; /* MST uses fixed bpp */
int max_rate, mode_rate, max_lanes, max_link_clock;
- if (!READ_ONCE(connector->registered))
+ if (drm_connector_is_unregistered(connector))
return MODE_ERROR;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 91a877fa00cb..9ccad6b062f2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -82,6 +82,53 @@ enum drm_connector_status {
connector_status_unknown = 3,
};
+/**
+ * enum drm_connector_registration_status - userspace registration status for
+ * a &drm_connector
+ *
+ * This enum is used to track the status of initializing a connector and
+ * registering it with userspace, so that DRM can prevent bogus modesets on
+ * connectors that no longer exist.
+ */
+enum drm_connector_registration_state {
+ /**
+ * @DRM_CONNECTOR_INITIALIZING: The connector has just been created,
+ * but has yet to be exposed to userspace. There should be no
+ * additional restrictions to how the state of this connector may be
+ * modified.
+ */
+ DRM_CONNECTOR_INITIALIZING = 0,
+
+ /**
+ * @DRM_CONNECTOR_REGISTERED: The connector has been fully initialized
+ * and registered with sysfs, as such it has been exposed to
+ * userspace. There should be no additional restrictions to how the
+ * state of this connector may be modified.
+ */
+ DRM_CONNECTOR_REGISTERED = 1,
+
+ /**
+ * @DRM_CONNECTOR_UNREGISTERED: The connector has either been exposed
+ * to userspace and has since been unregistered and removed from
+ * userspace, or the connector was unregistered before it had a chance
+ * to be exposed to userspace (e.g. still in the
+ * @DRM_CONNECTOR_INITIALIZING state). When a connector is
+ * unregistered, there are additional restrictions to how its state
+ * may be modified:
+ *
+ * - An unregistered connector may only have its DPMS changed from
+ * On->Off. Once DPMS is changed to Off, it may not be switched back
+ * to On.
+ * - Modesets are not allowed on unregistered connectors, unless they
+ * would result in disabling its assigned CRTCs. This means
+ * disabling a CRTC on an unregistered connector is OK, but enabling
+ * one is not.
+ * - Removing a CRTC from an unregistered connector is OK, but new
+ * CRTCs may never be assigned to an unregistered connector.
+ */
+ DRM_CONNECTOR_UNREGISTERED = 2,
+};
+
enum subpixel_order {
SubPixelUnknown = 0,
SubPixelHorizontalRGB,
@@ -853,10 +900,12 @@ struct drm_connector {
bool ycbcr_420_allowed;
/**
- * @registered: Is this connector exposed (registered) with userspace?
+ * @registration_state: Is this connector initializing, exposed
+ * (registered) with userspace, or unregistered?
+ *
* Protected by @mutex.
*/
- bool registered;
+ enum drm_connector_registration_state registration_state;
/**
* @modes:
@@ -1166,6 +1215,24 @@ static inline void drm_connector_unreference(struct drm_connector *connector)
drm_connector_put(connector);
}
+/**
+ * drm_connector_is_unregistered - has the connector been unregistered from
+ * userspace?
+ * @connector: DRM connector
+ *
+ * Checks whether or not @connector has been unregistered from userspace.
+ *
+ * Returns:
+ * True if the connector was unregistered, false if the connector is
+ * registered or has not yet been registered with userspace.
+ */
+static inline bool
+drm_connector_is_unregistered(struct drm_connector *connector)
+{
+ return READ_ONCE(connector->registration_state) ==
+ DRM_CONNECTOR_UNREGISTERED;
+}
+
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
const char *drm_get_dpms_name(int val);
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 34ca26a98ad67edd6e4870fe2d4aa047d41a51dd Mon Sep 17 00:00:00 2001
From: Lyude Paul <lyude(a)redhat.com>
Date: Tue, 9 Oct 2018 16:44:24 -0400
Subject: [PATCH] drm/atomic_helper: Allow DPMS On<->Off changes for
unregistered connectors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It appears when testing my previous fix for some of the legacy
modesetting issues with MST, I misattributed some kernel splats that
started appearing on my machine after a rebase as being from upstream.
But it appears they actually came from my patch series:
[ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1]
[ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered
[ 2.980516] ------------[ cut here ]------------
[ 2.980519] Could not determine valid watermarks for inherited state
[ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
[ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd
[ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1
[ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016
[ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915]
[ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00
[ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282
[ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006
[ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0
[ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065
[ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000
[ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800
[ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000
[ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0
[ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2.980645] Call Trace:
[ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915]
[ 2.980681] ? kernfs_add_one+0xe7/0x130
[ 2.980709] i915_pci_probe+0x46/0x60 [i915]
[ 2.980715] pci_device_probe+0xd4/0x150
[ 2.980719] really_probe+0x243/0x3b0
[ 2.980722] driver_probe_device+0xba/0x100
[ 2.980726] __driver_attach+0xe4/0x110
[ 2.980729] ? driver_probe_device+0x100/0x100
[ 2.980733] bus_for_each_dev+0x74/0xb0
[ 2.980736] driver_attach+0x1e/0x20
[ 2.980739] bus_add_driver+0x159/0x230
[ 2.980743] ? 0xffffffffa0393000
[ 2.980746] driver_register+0x70/0xc0
[ 2.980749] ? 0xffffffffa0393000
[ 2.980753] __pci_register_driver+0x57/0x60
[ 2.980780] i915_init+0x55/0x58 [i915]
[ 2.980785] do_one_initcall+0x4a/0x1c4
[ 2.980789] ? do_init_module+0x27/0x210
[ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190
[ 2.980797] do_init_module+0x60/0x210
[ 2.980800] load_module+0x2063/0x22e0
[ 2.980804] ? vfs_read+0x116/0x140
[ 2.980807] ? vfs_read+0x116/0x140
[ 2.980811] __do_sys_finit_module+0xbd/0x120
[ 2.980814] ? __do_sys_finit_module+0xbd/0x120
[ 2.980818] __x64_sys_finit_module+0x1a/0x20
[ 2.980821] do_syscall_64+0x5a/0x110
[ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2.980826] RIP: 0033:0x7f4754e32879
[ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48
[ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879
[ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018
[ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000
[ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000
[ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000
[ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915]
[ 2.980884] ---[ end trace 5eb47a76277d4731 ]---
The cause of this appears to be due to the fact that if there's
pre-existing display state that was set by the BIOS when i915 loads, it
will attempt to perform a modeset before the driver is registered with
userspace. Since this happens before the driver's registered with
userspace, it's connectors are also unregistered and thus-states which
would turn on DPMS on a connector end up getting rejected since the
connector isn't registered.
These bugs managed to get past Intel's CI partially due to the fact it
never ran a full test on my patches for some reason, but also because
all of the tests unload the GPU once before running. Since this bug is
only really triggered when the drivers tries to perform a modeset before
it's been fully registered with userspace when coming from whatever
display configuration the firmware left us with, it likely would never
have been picked up by CI in the first place.
After some discussion with vsyrjala, we decided the best course of
action would be to just move the unregistered connector checks out of
update_connector_routing() and into drm_atomic_set_crtc_for_connector().
The reason for this being that legacy modesetting isn't going to be
expecting failures anywhere (at least this is the case with X), so
ideally we want to ensure that any DPMS changes will still work even on
unregistered connectors. Instead, we now only reject new modesets which
would change the current CRTC assigned to an unregistered connector
unless no new CRTC is being assigned to replace the connector's previous
one.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Reported-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@…
(cherry picked from commit b5d29843d8ef86d4cde4742e095b81b7fd41e688)
Fixes: e96550956fbc ("drm/atomic_helper: Disallow new modesets on unregistered connectors")
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 20bd176138a0..e49b22381048 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -308,26 +308,6 @@ update_connector_routing(struct drm_atomic_state *state,
return 0;
}
- crtc_state = drm_atomic_get_new_crtc_state(state,
- new_connector_state->crtc);
- /*
- * For compatibility with legacy users, we want to make sure that
- * we allow DPMS On->Off modesets on unregistered connectors. Modesets
- * which would result in anything else must be considered invalid, to
- * avoid turning on new displays on dead connectors.
- *
- * Since the connector can be unregistered at any point during an
- * atomic check or commit, this is racy. But that's OK: all we care
- * about is ensuring that userspace can't do anything but shut off the
- * display on a connector that was destroyed after its been notified,
- * not before.
- */
- if (!READ_ONCE(connector->registered) && crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
- connector->base.id, connector->name);
- return -EINVAL;
- }
-
funcs = connector->helper_private;
if (funcs->atomic_best_encoder)
@@ -372,6 +352,7 @@ update_connector_routing(struct drm_atomic_state *state,
set_best_encoder(state, new_connector_state, new_encoder);
+ crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc);
crtc_state->connectors_changed = true;
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..a22d6f269b07 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -299,6 +299,27 @@ drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
struct drm_connector *connector = conn_state->connector;
struct drm_crtc_state *crtc_state;
+ /*
+ * For compatibility with legacy users, we want to make sure that
+ * we allow DPMS On<->Off modesets on unregistered connectors, since
+ * legacy modesetting users will not be expecting these to fail. We do
+ * not however, want to allow legacy users to assign a connector
+ * that's been unregistered from sysfs to another CRTC, since doing
+ * this with a now non-existent connector could potentially leave us
+ * in an invalid state.
+ *
+ * Since the connector can be unregistered at any point during an
+ * atomic check or commit, this is racy. But that's OK: all we care
+ * about is ensuring that userspace can't use this connector for new
+ * configurations after it's been notified that the connector is no
+ * longer present.
+ */
+ if (!READ_ONCE(connector->registered) && crtc) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
if (conn_state->crtc == crtc)
return 0;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From c1a17777eb45d9f3821f35e9869c0a08cd2e664e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com>
Date: Mon, 12 Nov 2018 18:08:31 +0100
Subject: [PATCH] drm/amdgpu: fix huge page handling on Vega10
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We accidentially set the huge flag on the parent instead of the childs.
This caused some VM faults under memory pressure.
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Acked-by: Alex Deucher <alexander.deucher(a)amd.com>
Tested-by: Samuel Pitoiset <samuel.pitoiset(a)gmail.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Cc: stable(a)vger.kernel.org
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 352b30409060..dad0e2342df9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1632,13 +1632,6 @@ static int amdgpu_vm_update_ptes(struct amdgpu_pte_update_params *params,
continue;
}
- /* First check if the entry is already handled */
- if (cursor.pfn < frag_start) {
- cursor.entry->huge = true;
- amdgpu_vm_pt_next(adev, &cursor);
- continue;
- }
-
/* If it isn't already handled it can't be a huge page */
if (cursor.entry->huge) {
/* Add the entry to the relocated list to update it. */
@@ -1701,8 +1694,17 @@ static int amdgpu_vm_update_ptes(struct amdgpu_pte_update_params *params,
}
} while (frag_start < entry_end);
- if (frag >= shift)
+ if (amdgpu_vm_pt_descendant(adev, &cursor)) {
+ /* Mark all child entries as huge */
+ while (cursor.pfn < frag_start) {
+ cursor.entry->huge = true;
+ amdgpu_vm_pt_next(adev, &cursor);
+ }
+
+ } else if (frag >= shift) {
+ /* or just move on to the next on the same level. */
amdgpu_vm_pt_next(adev, &cursor);
+ }
}
return 0;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 9d064be1e6a195eaaa3762af5c7c6cd3f66aa6cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= <ckoenig.leichtzumerken(a)gmail.com>
Date: Wed, 24 Oct 2018 14:59:10 +0200
Subject: [PATCH] drm/amdgpu: revert "enable gfxoff in non-sriov and stutter
mode by default"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is still completely breaking my Raven system.
This reverts commit cdf2f910fa969adca1b0e3ad2b487821233dc038.
Revert until we sort out the sbios and firmware combinations that work
correctly.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=108606
Cc: stable(a)vger.kernel.org # v4.19
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f06d068b8eb5..30bc345d6fdf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1493,8 +1493,6 @@ static int amdgpu_device_ip_early_init(struct amdgpu_device *adev)
}
adev->powerplay.pp_feature = amdgpu_pp_feature_mask;
- if (amdgpu_sriov_vf(adev))
- adev->powerplay.pp_feature &= ~PP_GFXOFF_MASK;
for (i = 0; i < adev->num_ip_blocks; i++) {
if ((amdgpu_ip_block_mask & (1 << i)) == 0) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 28781414d71c..943dbf3c5da1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -114,8 +114,8 @@ uint amdgpu_pg_mask = 0xffffffff;
uint amdgpu_sdma_phase_quantum = 32;
char *amdgpu_disable_cu = NULL;
char *amdgpu_virtual_display = NULL;
-/* OverDrive(bit 14) disabled by default*/
-uint amdgpu_pp_feature_mask = 0xffffbfff;
+/* OverDrive(bit 14),gfxoff(bit 15),stutter mode(bit 17) disabled by default*/
+uint amdgpu_pp_feature_mask = 0xfffd3fff;
int amdgpu_ngg = 0;
int amdgpu_prim_buf_per_se = 0;
int amdgpu_pos_buf_per_se = 0;
From: Eric Biggers <ebiggers(a)google.com>
When a UHID_CREATE command is written to the uhid char device, a
copy_from_user() is done from a user pointer embedded in the command.
When the address limit is KERNEL_DS, e.g. as is the case during
sendfile(), this can read from kernel memory. Therefore, UHID_CREATE
must not be allowed in this case.
For consistency and to make sure all current and future uhid commands
are covered, apply the restriction to uhid_char_write() as a whole
rather than to UHID_CREATE specifically.
Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
Jann Horn for commit 9da3f2b740544 ("x86/fault: BUG() when uaccess
helpers fault on kernel addresses"), allowing this bug to be found.
Reported-by: syzbot+72473edc9bf4eb1c6556(a)syzkaller.appspotmail.com
Fixes: d365c6cfd337 ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
Cc: <stable(a)vger.kernel.org> # v3.6+
Cc: Jann Horn <jannh(a)google.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
drivers/hid/uhid.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index 3c55073136064..e94c5e248b56e 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -705,6 +705,12 @@ static ssize_t uhid_char_write(struct file *file, const char __user *buffer,
int ret;
size_t len;
+ if (uaccess_kernel()) { /* payload may contain a __user pointer */
+ pr_err_once("%s: process %d (%s) called from kernel context, this is not allowed.\n",
+ __func__, task_tgid_vnr(current), current->comm);
+ return -EACCES;
+ }
+
/* we need at least the "type" member of uhid_event */
if (count < sizeof(__u32))
return -EINVAL;
--
2.19.1.930.g4563a0d9d0-goog
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 017b1660df89f5fb4bfe66c34e35f7d2031100c7 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Fri, 5 Oct 2018 15:51:29 -0700
Subject: [PATCH] mm: migration: fix migration of huge PMD shared pages
The page migration code employs try_to_unmap() to try and unmap the source
page. This is accomplished by using rmap_walk to find all vmas where the
page is mapped. This search stops when page mapcount is zero. For shared
PMD huge pages, the page map count is always 1 no matter the number of
mappings. Shared mappings are tracked via the reference count of the PMD
page. Therefore, try_to_unmap stops prematurely and does not completely
unmap all mappings of the source page.
This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the target
page. Hence, data is lost.
This problem was originally seen as DB corruption of shared global areas
after a huge page was soft offlined due to ECC memory errors. DB
developers noticed they could reproduce the issue by (hotplug) offlining
memory used to back huge pages. A simple testcase can reproduce the
problem by creating a shared PMD mapping (note that this must be at least
PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
migrate_pages() to migrate process pages between nodes while continually
writing to the huge pages being migrated.
To fix, have the try_to_unmap_one routine check for huge PMD sharing by
calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared
mapping it will be 'unshared' which removes the page table entry and drops
the reference on the PMD page. After this, flush caches and TLB.
mmu notifiers are called before locking page tables, but we can not be
sure of PMD sharing until page tables are locked. Therefore, check for
the possibility of PMD sharing before locking so that notifiers can
prepare for the worst possible case.
Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com
[mike.kravetz(a)oracle.com: make _range_in_vma() a static inline]
Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Jerome Glisse <jglisse(a)redhat.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6b68e345f0ca..087fd5f48c91 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -140,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte_t *huge_pte_offset(struct mm_struct *mm,
unsigned long addr, unsigned long sz);
int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end);
struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
int write);
struct page *follow_huge_pd(struct vm_area_struct *vma,
@@ -170,6 +172,18 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
}
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+ pte_t *ptep)
+{
+ return 0;
+}
+
+static inline void adjust_range_if_pmd_sharing_possible(
+ struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
+
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n) ({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a61ebe8ad4ca..0416a7204be3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2455,6 +2455,12 @@ static inline struct vm_area_struct *find_exact_vma(struct mm_struct *mm,
return vma;
}
+static inline bool range_in_vma(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ return (vma && vma->vm_start <= start && end <= vma->vm_end);
+}
+
#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
void vma_set_page_prot(struct vm_area_struct *vma);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3c21775f196b..b903d746e132 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4545,12 +4545,40 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
/*
* check on proper vm_flags and page table alignment
*/
- if (vma->vm_flags & VM_MAYSHARE &&
- vma->vm_start <= base && end <= vma->vm_end)
+ if (vma->vm_flags & VM_MAYSHARE && range_in_vma(vma, base, end))
return true;
return false;
}
+/*
+ * Determine if start,end range within vma could be mapped by shared pmd.
+ * If yes, adjust start and end to cover range associated with possible
+ * shared pmd mappings.
+ */
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+ unsigned long check_addr = *start;
+
+ if (!(vma->vm_flags & VM_MAYSHARE))
+ return;
+
+ for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) {
+ unsigned long a_start = check_addr & PUD_MASK;
+ unsigned long a_end = a_start + PUD_SIZE;
+
+ /*
+ * If sharing is possible, adjust start/end if necessary.
+ */
+ if (range_in_vma(vma, a_start, a_end)) {
+ if (a_start < *start)
+ *start = a_start;
+ if (a_end > *end)
+ *end = a_end;
+ }
+ }
+}
+
/*
* Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
* and returns the corresponding pte. While this is not necessary for the
@@ -4648,6 +4676,11 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
{
return 0;
}
+
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
#define want_pmd_share() (0)
#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
diff --git a/mm/rmap.c b/mm/rmap.c
index eb477809a5c0..1e79fac3186b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1362,11 +1362,21 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
}
/*
- * We have to assume the worse case ie pmd for invalidation. Note that
- * the page can not be free in this function as call of try_to_unmap()
- * must hold a reference on the page.
+ * For THP, we have to assume the worse case ie pmd for invalidation.
+ * For hugetlb, it could be much worse if we need to do pud
+ * invalidation in the case of pmd sharing.
+ *
+ * Note that the page can not be free in this function as call of
+ * try_to_unmap() must hold a reference on the page.
*/
end = min(vma->vm_end, start + (PAGE_SIZE << compound_order(page)));
+ if (PageHuge(page)) {
+ /*
+ * If sharing is possible, start and end will be adjusted
+ * accordingly.
+ */
+ adjust_range_if_pmd_sharing_possible(vma, &start, &end);
+ }
mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
while (page_vma_mapped_walk(&pvmw)) {
@@ -1409,6 +1419,32 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
address = pvmw.address;
+ if (PageHuge(page)) {
+ if (huge_pmd_unshare(mm, &address, pvmw.pte)) {
+ /*
+ * huge_pmd_unshare unmapped an entire PMD
+ * page. There is no way of knowing exactly
+ * which PMDs may be cached for this mm, so
+ * we must flush them all. start/end were
+ * already adjusted above to cover this range.
+ */
+ flush_cache_range(vma, start, end);
+ flush_tlb_range(vma, start, end);
+ mmu_notifier_invalidate_range(mm, start, end);
+
+ /*
+ * The ref count of the PMD page was dropped
+ * which is part of the way map counting
+ * is done for shared PMDs. Return 'true'
+ * here. When there is no other sharing,
+ * huge_pmd_unshare returns false and we will
+ * unmap the actual page and drop map count
+ * to zero.
+ */
+ page_vma_mapped_walk_done(&pvmw);
+ break;
+ }
+ }
if (IS_ENABLED(CONFIG_MIGRATION) &&
(flags & TTU_MIGRATION) &&
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 017b1660df89f5fb4bfe66c34e35f7d2031100c7 Mon Sep 17 00:00:00 2001
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Date: Fri, 5 Oct 2018 15:51:29 -0700
Subject: [PATCH] mm: migration: fix migration of huge PMD shared pages
The page migration code employs try_to_unmap() to try and unmap the source
page. This is accomplished by using rmap_walk to find all vmas where the
page is mapped. This search stops when page mapcount is zero. For shared
PMD huge pages, the page map count is always 1 no matter the number of
mappings. Shared mappings are tracked via the reference count of the PMD
page. Therefore, try_to_unmap stops prematurely and does not completely
unmap all mappings of the source page.
This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the target
page. Hence, data is lost.
This problem was originally seen as DB corruption of shared global areas
after a huge page was soft offlined due to ECC memory errors. DB
developers noticed they could reproduce the issue by (hotplug) offlining
memory used to back huge pages. A simple testcase can reproduce the
problem by creating a shared PMD mapping (note that this must be at least
PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
migrate_pages() to migrate process pages between nodes while continually
writing to the huge pages being migrated.
To fix, have the try_to_unmap_one routine check for huge PMD sharing by
calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared
mapping it will be 'unshared' which removes the page table entry and drops
the reference on the PMD page. After this, flush caches and TLB.
mmu notifiers are called before locking page tables, but we can not be
sure of PMD sharing until page tables are locked. Therefore, check for
the possibility of PMD sharing before locking so that notifiers can
prepare for the worst possible case.
Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com
[mike.kravetz(a)oracle.com: make _range_in_vma() a static inline]
Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Jerome Glisse <jglisse(a)redhat.com>
Cc: Mike Kravetz <mike.kravetz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 6b68e345f0ca..087fd5f48c91 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -140,6 +140,8 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pte_t *huge_pte_offset(struct mm_struct *mm,
unsigned long addr, unsigned long sz);
int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end);
struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
int write);
struct page *follow_huge_pd(struct vm_area_struct *vma,
@@ -170,6 +172,18 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
}
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+ pte_t *ptep)
+{
+ return 0;
+}
+
+static inline void adjust_range_if_pmd_sharing_possible(
+ struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
+
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n) ({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a61ebe8ad4ca..0416a7204be3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2455,6 +2455,12 @@ static inline struct vm_area_struct *find_exact_vma(struct mm_struct *mm,
return vma;
}
+static inline bool range_in_vma(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ return (vma && vma->vm_start <= start && end <= vma->vm_end);
+}
+
#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
void vma_set_page_prot(struct vm_area_struct *vma);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3c21775f196b..b903d746e132 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4545,12 +4545,40 @@ static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
/*
* check on proper vm_flags and page table alignment
*/
- if (vma->vm_flags & VM_MAYSHARE &&
- vma->vm_start <= base && end <= vma->vm_end)
+ if (vma->vm_flags & VM_MAYSHARE && range_in_vma(vma, base, end))
return true;
return false;
}
+/*
+ * Determine if start,end range within vma could be mapped by shared pmd.
+ * If yes, adjust start and end to cover range associated with possible
+ * shared pmd mappings.
+ */
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+ unsigned long check_addr = *start;
+
+ if (!(vma->vm_flags & VM_MAYSHARE))
+ return;
+
+ for (check_addr = *start; check_addr < *end; check_addr += PUD_SIZE) {
+ unsigned long a_start = check_addr & PUD_MASK;
+ unsigned long a_end = a_start + PUD_SIZE;
+
+ /*
+ * If sharing is possible, adjust start/end if necessary.
+ */
+ if (range_in_vma(vma, a_start, a_end)) {
+ if (a_start < *start)
+ *start = a_start;
+ if (a_end > *end)
+ *end = a_end;
+ }
+ }
+}
+
/*
* Search for a shareable pmd page for hugetlb. In any case calls pmd_alloc()
* and returns the corresponding pte. While this is not necessary for the
@@ -4648,6 +4676,11 @@ int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
{
return 0;
}
+
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
#define want_pmd_share() (0)
#endif /* CONFIG_ARCH_WANT_HUGE_PMD_SHARE */
diff --git a/mm/rmap.c b/mm/rmap.c
index eb477809a5c0..1e79fac3186b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1362,11 +1362,21 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
}
/*
- * We have to assume the worse case ie pmd for invalidation. Note that
- * the page can not be free in this function as call of try_to_unmap()
- * must hold a reference on the page.
+ * For THP, we have to assume the worse case ie pmd for invalidation.
+ * For hugetlb, it could be much worse if we need to do pud
+ * invalidation in the case of pmd sharing.
+ *
+ * Note that the page can not be free in this function as call of
+ * try_to_unmap() must hold a reference on the page.
*/
end = min(vma->vm_end, start + (PAGE_SIZE << compound_order(page)));
+ if (PageHuge(page)) {
+ /*
+ * If sharing is possible, start and end will be adjusted
+ * accordingly.
+ */
+ adjust_range_if_pmd_sharing_possible(vma, &start, &end);
+ }
mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
while (page_vma_mapped_walk(&pvmw)) {
@@ -1409,6 +1419,32 @@ static bool try_to_unmap_one(struct page *page, struct vm_area_struct *vma,
subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
address = pvmw.address;
+ if (PageHuge(page)) {
+ if (huge_pmd_unshare(mm, &address, pvmw.pte)) {
+ /*
+ * huge_pmd_unshare unmapped an entire PMD
+ * page. There is no way of knowing exactly
+ * which PMDs may be cached for this mm, so
+ * we must flush them all. start/end were
+ * already adjusted above to cover this range.
+ */
+ flush_cache_range(vma, start, end);
+ flush_tlb_range(vma, start, end);
+ mmu_notifier_invalidate_range(mm, start, end);
+
+ /*
+ * The ref count of the PMD page was dropped
+ * which is part of the way map counting
+ * is done for shared PMDs. Return 'true'
+ * here. When there is no other sharing,
+ * huge_pmd_unshare returns false and we will
+ * unmap the actual page and drop map count
+ * to zero.
+ */
+ page_vma_mapped_walk_done(&pvmw);
+ break;
+ }
+ }
if (IS_ENABLED(CONFIG_MIGRATION) &&
(flags & TTU_MIGRATION) &&
Hi all,
Here are fixes that worth to have in the @stable, as they were hit by
different people, including Arista on v4.9 stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.
Mikulas, can you add your tested-by on this patches set again, please?
I tried to reproduce reboot issue on qemu-hppa and even built
cross-compiler for pa-risc.. but was unlucky in reproducing.
Thanks,
Dima
Changes since v5:
- Better commit tags
- Hopefully fixed issue with reboot on pa-risc with Debian 5
Changes since v4:
- back to lock ldisc with (5*HZ) timeout in tty_reopen()
(LKP report link: lkml.kernel.org/r/<1536940609.3185.29.camel(a)arista.com>)
- reordered 3/7 with 2/7 for LKP robot
Changes since v3:
- Added tested-by Mark Rutland (thanks!)
- Dropped patch with smp_wmb() - wrong idea
- lockdep_assert_held() should be actually lockdep_assert_held_exclusive()
- Described why tty_ldisc_open() can be called without ldisc_sem held
for pty slave end (o_tty).
- Added Peter's patch for dropping self-made lockdep annotations
- Fix for a reader(s) of ldisc semaphore waiting for an active reader(s)
Changes since v2:
- Added reviewed-by tags
- Hopefully, fixed reported by 0-day issue.
- Added optional fix for wait_readers decrement
Changes since v1:
- Added tested-by/reported-by tags
- Dropped 3/4 (locking tty pair for lockdep sake),
Because of that - not adding lockdep_assert_held() in tty_ldisc_open()
- Added 4/4 cleanup to inc tty->count only on success of
tty_ldisc_reinit()
- lock ldisc without (5*HZ) timeout in tty_reopen()
v1 link: lkml.kernel.org/r/<20180829022353.23568-1-dima(a)arista.com>
v2 link: lkml.kernel.org/r/<20180903165257.29227-1-dima(a)arista.com>
v3 link: lkml.kernel.org/r/<20180911014821.26286-1-dima(a)arista.com>
v4 link: lkml.kernel.org/r/<20180912001702.18522-1-dima(a)arista.com>
Cc: Daniel Axtens <dja(a)axtens.net>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Michael Neuling <mikey(a)neuling.org>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: Nathan March <nathan(a)gt.net>
Cc: Pasi Kärkkäinen <pasik(a)iki.fi>
Cc: Peter Hurley <peter(a)hurleysoftware.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: "Rong, Chen" <rong.a.chen(a)intel.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com>
Cc: Tan Xiaojun <tanxiaojun(a)huawei.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
(please, ignore if I Cc'ed you mistakenly)
Dmitry Safonov (6):
tty/ldsem: Wake up readers after timed out down_write()
tty: Hold tty_ldisc_lock() during tty_reopen()
tty: Don't block on IO when ldisc change is pending
tty: Simplify tty->count math in tty_reopen()
tty/ldsem: Add lockdep asserts for ldisc_sem
tty/ldsem: Decrement wait_readers on timeouted down_read()
Peter Zijlstra (1):
tty/ldsem: Convert to regular lockdep annotations
drivers/tty/n_hdlc.c | 4 +--
drivers/tty/n_r3964.c | 2 +-
drivers/tty/n_tty.c | 8 +++---
drivers/tty/tty_io.c | 14 ++++++----
drivers/tty/tty_ldisc.c | 16 +++++++++++
drivers/tty/tty_ldsem.c | 62 +++++++++++++++++------------------------
include/linux/tty.h | 7 +++++
7 files changed, 63 insertions(+), 50 deletions(-)
--
2.19.1
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 10283ea525d30f2e99828978fd04d8427876a7ad Mon Sep 17 00:00:00 2001
From: Andreas Gruenbacher <agruenba(a)redhat.com>
Date: Mon, 5 Nov 2018 22:57:24 +0000
Subject: [PATCH] gfs2: Put bitmap buffers in put_super
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
attached to the resource group glocks. That function should release the
buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
gfs2_rgrp_brelse for doing that is missing.
When gfs2_releasepage later runs across these buffers which are still
referenced, it refuses to free them. This causes the pages the buffers
are attached to to remain referenced as well. With enough mount/unmount
cycles, the system will eventually run out of memory.
Fix this by adding the missing call to gfs2_rgrp_brelse in
gfs2_clear_rgrpd.
(Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
Cc: stable(a)vger.kernel.org # v4.2+
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index ffe3032b1043..b08a530433ad 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -733,6 +733,7 @@ void gfs2_clear_rgrpd(struct gfs2_sbd *sdp)
if (gl) {
glock_clear_object(gl, rgd);
+ gfs2_rgrp_brelse(rgd);
gfs2_glock_put(gl);
}
@@ -1174,7 +1175,7 @@ static u32 count_unlinked(struct gfs2_rgrpd *rgd)
* @rgd: the struct gfs2_rgrpd describing the RG to read in
*
* Read in all of a Resource Group's header and bitmap blocks.
- * Caller must eventually call gfs2_rgrp_relse() to free the bitmaps.
+ * Caller must eventually call gfs2_rgrp_brelse() to free the bitmaps.
*
* Returns: errno
*/
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 10283ea525d30f2e99828978fd04d8427876a7ad Mon Sep 17 00:00:00 2001
From: Andreas Gruenbacher <agruenba(a)redhat.com>
Date: Mon, 5 Nov 2018 22:57:24 +0000
Subject: [PATCH] gfs2: Put bitmap buffers in put_super
gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
attached to the resource group glocks. That function should release the
buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
gfs2_rgrp_brelse for doing that is missing.
When gfs2_releasepage later runs across these buffers which are still
referenced, it refuses to free them. This causes the pages the buffers
are attached to to remain referenced as well. With enough mount/unmount
cycles, the system will eventually run out of memory.
Fix this by adding the missing call to gfs2_rgrp_brelse in
gfs2_clear_rgrpd.
(Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
Fixes: 39b0f1e92908 ("GFS2: Don't brelse rgrp buffer_heads every allocation")
Cc: stable(a)vger.kernel.org # v4.2+
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index ffe3032b1043..b08a530433ad 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -733,6 +733,7 @@ void gfs2_clear_rgrpd(struct gfs2_sbd *sdp)
if (gl) {
glock_clear_object(gl, rgd);
+ gfs2_rgrp_brelse(rgd);
gfs2_glock_put(gl);
}
@@ -1174,7 +1175,7 @@ static u32 count_unlinked(struct gfs2_rgrpd *rgd)
* @rgd: the struct gfs2_rgrpd describing the RG to read in
*
* Read in all of a Resource Group's header and bitmap blocks.
- * Caller must eventually call gfs2_rgrp_relse() to free the bitmaps.
+ * Caller must eventually call gfs2_rgrp_brelse() to free the bitmaps.
*
* Returns: errno
*/
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ebacb81273599555a7a19f7754a1451206a5fc4f Mon Sep 17 00:00:00 2001
From: Lukas Czerner <lczerner(a)redhat.com>
Date: Fri, 9 Nov 2018 14:51:46 +0100
Subject: [PATCH] fuse: fix use-after-free in fuse_direct_IO()
In async IO blocking case the additional reference to the io is taken for
it to survive fuse_aio_complete(). In non blocking case this additional
reference is not needed, however we still reference io to figure out
whether to wait for completion or not. This is wrong and will lead to
use-after-free. Fix it by storing blocking information in separate
variable.
This was spotted by KASAN when running generic/208 fstest.
Signed-off-by: Lukas Czerner <lczerner(a)redhat.com>
Reported-by: Zorro Lang <zlang(a)redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 744742d692e3 ("fuse: Add reference counting for fuse_io_priv")
Cc: <stable(a)vger.kernel.org> # v4.6
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index cc2121b37bf5..b52f9baaa3e7 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2924,10 +2924,12 @@ fuse_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
}
if (io->async) {
+ bool blocking = io->blocking;
+
fuse_aio_complete(io, ret < 0 ? ret : 0, -1);
/* we have a non-extending, async request, so return */
- if (!io->blocking)
+ if (!blocking)
return -EIOCBQUEUED;
wait_for_completion(&wait);
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 763f191af51f127cf8e69cd361f50bf6180768a5 Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Thu, 1 Nov 2018 13:22:38 +0100
Subject: [PATCH] ARM: cpuidle: Don't register the driver when back-end init
returns -ENXIO
There's no point to register the cpuidle driver for the current CPU, when
the initialization of the arch specific back-end data fails by returning
-ENXIO.
Instead, let's re-order the sequence to its original flow, by first trying
to initialize the back-end part and then act accordingly on the returned
error code. Additionally, let's print the error message, no matter of what
error code that was returned.
Fixes: a0d46a3dfdc3 (ARM: cpuidle: Register per cpuidle device)
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: 4.19+ <stable(a)vger.kernel.org> # v4.19+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 073557f433eb..df564d783216 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -103,13 +103,6 @@ static int __init arm_idle_init_cpu(int cpu)
goto out_kfree_drv;
}
- ret = cpuidle_register_driver(drv);
- if (ret) {
- if (ret != -EBUSY)
- pr_err("Failed to register cpuidle driver\n");
- goto out_kfree_drv;
- }
-
/*
* Call arch CPU operations in order to initialize
* idle states suspend back-end specific data
@@ -117,15 +110,20 @@ static int __init arm_idle_init_cpu(int cpu)
ret = arm_cpuidle_init(cpu);
/*
- * Skip the cpuidle device initialization if the reported
+ * Allow the initialization to continue for other CPUs, if the reported
* failure is a HW misconfiguration/breakage (-ENXIO).
*/
- if (ret == -ENXIO)
- return 0;
-
if (ret) {
pr_err("CPU %d failed to init idle CPU ops\n", cpu);
- goto out_unregister_drv;
+ ret = ret == -ENXIO ? 0 : ret;
+ goto out_kfree_drv;
+ }
+
+ ret = cpuidle_register_driver(drv);
+ if (ret) {
+ if (ret != -EBUSY)
+ pr_err("Failed to register cpuidle driver\n");
+ goto out_kfree_drv;
}
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 763f191af51f127cf8e69cd361f50bf6180768a5 Mon Sep 17 00:00:00 2001
From: Ulf Hansson <ulf.hansson(a)linaro.org>
Date: Thu, 1 Nov 2018 13:22:38 +0100
Subject: [PATCH] ARM: cpuidle: Don't register the driver when back-end init
returns -ENXIO
There's no point to register the cpuidle driver for the current CPU, when
the initialization of the arch specific back-end data fails by returning
-ENXIO.
Instead, let's re-order the sequence to its original flow, by first trying
to initialize the back-end part and then act accordingly on the returned
error code. Additionally, let's print the error message, no matter of what
error code that was returned.
Fixes: a0d46a3dfdc3 (ARM: cpuidle: Register per cpuidle device)
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: 4.19+ <stable(a)vger.kernel.org> # v4.19+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 073557f433eb..df564d783216 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -103,13 +103,6 @@ static int __init arm_idle_init_cpu(int cpu)
goto out_kfree_drv;
}
- ret = cpuidle_register_driver(drv);
- if (ret) {
- if (ret != -EBUSY)
- pr_err("Failed to register cpuidle driver\n");
- goto out_kfree_drv;
- }
-
/*
* Call arch CPU operations in order to initialize
* idle states suspend back-end specific data
@@ -117,15 +110,20 @@ static int __init arm_idle_init_cpu(int cpu)
ret = arm_cpuidle_init(cpu);
/*
- * Skip the cpuidle device initialization if the reported
+ * Allow the initialization to continue for other CPUs, if the reported
* failure is a HW misconfiguration/breakage (-ENXIO).
*/
- if (ret == -ENXIO)
- return 0;
-
if (ret) {
pr_err("CPU %d failed to init idle CPU ops\n", cpu);
- goto out_unregister_drv;
+ ret = ret == -ENXIO ? 0 : ret;
+ goto out_kfree_drv;
+ }
+
+ ret = cpuidle_register_driver(drv);
+ if (ret) {
+ if (ret != -EBUSY)
+ pr_err("Failed to register cpuidle driver\n");
+ goto out_kfree_drv;
}
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 506481b20e818db40b6198815904ecd2d6daee64 Mon Sep 17 00:00:00 2001
From: Robbie Ko <robbieko(a)synology.com>
Date: Tue, 30 Oct 2018 18:04:04 +0800
Subject: [PATCH] Btrfs: fix cur_offset in the error case for nocow
When the cow_file_range fails, the related resources are unlocked
according to the range [start..end), so the unlock cannot be repeated in
run_delalloc_nocow.
In some cases (e.g. cur_offset <= end && cow_start != -1), cur_offset is
not updated correctly, so move the cur_offset update before
cow_file_range.
kernel BUG at mm/page-writeback.c:2663!
Internal error: Oops - BUG: 0 [#1] SMP
CPU: 3 PID: 31525 Comm: kworker/u8:7 Tainted: P O
Hardware name: Realtek_RTD1296 (DT)
Workqueue: writeback wb_workfn (flush-btrfs-1)
task: ffffffc076db3380 ti: ffffffc02e9ac000 task.ti: ffffffc02e9ac000
PC is at clear_page_dirty_for_io+0x1bc/0x1e8
LR is at clear_page_dirty_for_io+0x14/0x1e8
pc : [<ffffffc00033c91c>] lr : [<ffffffc00033c774>] pstate: 40000145
sp : ffffffc02e9af4f0
Process kworker/u8:7 (pid: 31525, stack limit = 0xffffffc02e9ac020)
Call trace:
[<ffffffc00033c91c>] clear_page_dirty_for_io+0x1bc/0x1e8
[<ffffffbffc514674>] extent_clear_unlock_delalloc+0x1e4/0x210 [btrfs]
[<ffffffbffc4fb168>] run_delalloc_nocow+0x3b8/0x948 [btrfs]
[<ffffffbffc4fb948>] run_delalloc_range+0x250/0x3a8 [btrfs]
[<ffffffbffc514c0c>] writepage_delalloc.isra.21+0xbc/0x1d8 [btrfs]
[<ffffffbffc516048>] __extent_writepage+0xe8/0x248 [btrfs]
[<ffffffbffc51630c>] extent_write_cache_pages.isra.17+0x164/0x378 [btrfs]
[<ffffffbffc5185a8>] extent_writepages+0x48/0x68 [btrfs]
[<ffffffbffc4f5828>] btrfs_writepages+0x20/0x30 [btrfs]
[<ffffffc00033d758>] do_writepages+0x30/0x88
[<ffffffc0003ba0f4>] __writeback_single_inode+0x34/0x198
[<ffffffc0003ba6c4>] writeback_sb_inodes+0x184/0x3c0
[<ffffffc0003ba96c>] __writeback_inodes_wb+0x6c/0xc0
[<ffffffc0003bac20>] wb_writeback+0x1b8/0x1c0
[<ffffffc0003bb0f0>] wb_workfn+0x150/0x250
[<ffffffc0002b0014>] process_one_work+0x1dc/0x388
[<ffffffc0002b02f0>] worker_thread+0x130/0x500
[<ffffffc0002b6344>] kthread+0x10c/0x110
[<ffffffc000284590>] ret_from_fork+0x10/0x40
Code: d503201f a9025bb5 a90363b7 f90023b9 (d4210000)
CC: stable(a)vger.kernel.org # 4.4+
Reviewed-by: Filipe Manana <fdmanana(a)suse.com>
Signed-off-by: Robbie Ko <robbieko(a)synology.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index f4d31fd62eed..55761b1519f5 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1531,12 +1531,11 @@ static noinline int run_delalloc_nocow(struct inode *inode,
}
btrfs_release_path(path);
- if (cur_offset <= end && cow_start == (u64)-1) {
+ if (cur_offset <= end && cow_start == (u64)-1)
cow_start = cur_offset;
- cur_offset = end;
- }
if (cow_start != (u64)-1) {
+ cur_offset = end;
ret = cow_file_range(inode, locked_page, cow_start, end, end,
page_started, nr_written, 1, NULL);
if (ret)
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 81bd415c91eb966118d773dddf254aebf3022411 Mon Sep 17 00:00:00 2001
From: Mathieu Malaterre <malat(a)debian.org>
Date: Wed, 6 Jun 2018 21:42:32 +0200
Subject: [PATCH] watchdog/core: Add missing prototypes for weak functions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The split out of the hard lockup detector exposed two new weak functions,
but no prototypes for them, which triggers the build warning:
kernel/watchdog.c:109:12: warning: no previous prototype for ‘watchdog_nmi_enable’ [-Wmissing-prototypes]
kernel/watchdog.c:115:13: warning: no previous prototype for ‘watchdog_nmi_disable’ [-Wmissing-prototypes]
Add the prototypes.
Fixes: 73ce0511c436 ("kernel/watchdog.c: move hardlockup detector to separate file")
Signed-off-by: Mathieu Malaterre <malat(a)debian.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Babu Moger <babu.moger(a)oracle.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20180606194232.17653-1-malat@debian.org
diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 08f9247e9827..9003e29cde46 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -119,6 +119,8 @@ static inline int hardlockup_detector_perf_init(void) { return 0; }
void watchdog_nmi_stop(void);
void watchdog_nmi_start(void);
int watchdog_nmi_probe(void);
+int watchdog_nmi_enable(unsigned int cpu);
+void watchdog_nmi_disable(unsigned int cpu);
/**
* touch_nmi_watchdog - restart NMI watchdog timeout.
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From ea53abfab960909d622ca37bcfb8e1c5378d21cc Mon Sep 17 00:00:00 2001
From: Jarod Wilson <jarod(a)redhat.com>
Date: Sun, 4 Nov 2018 14:59:46 -0500
Subject: [PATCH] bonding/802.3ad: fix link_failure_count tracking
Commit 4d2c0cda07448ea6980f00102dc3964eb25e241c set slave->link to
BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
were read, to fix a problem with slaves getting into weird states, but
in the process, broke tracking of link failures, as going straight to
BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
!link_state was already true, we never incremented commit, and never got
a chance to call bond_miimon_commit(), where slave->link_failure_count
would be incremented. I believe the simple fix here is to mark the slave
as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
_FAIL to either _UP or _DOWN, and in the latter case, we now get proper
incrementing of link_failure_count again.
Fixes: 4d2c0cda0744 ("bonding: speed/duplex update at NETDEV_UP event")
CC: Mahesh Bandewar <maheshb(a)google.com>
CC: David S. Miller <davem(a)davemloft.net>
CC: netdev(a)vger.kernel.org
CC: stable(a)vger.kernel.org
Signed-off-by: Jarod Wilson <jarod(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index ffa37adb7681..333387f1f1fe 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3112,13 +3112,13 @@ static int bond_slave_netdev_event(unsigned long event,
case NETDEV_CHANGE:
/* For 802.3ad mode only:
* Getting invalid Speed/Duplex values here will put slave
- * in weird state. So mark it as link-down for the time
+ * in weird state. So mark it as link-fail for the time
* being and let link-monitoring (miimon) set it right when
* correct speeds/duplex are available.
*/
if (bond_update_speed_duplex(slave) &&
BOND_MODE(bond) == BOND_MODE_8023AD)
- slave->link = BOND_LINK_DOWN;
+ slave->link = BOND_LINK_FAIL;
if (BOND_MODE(bond) == BOND_MODE_8023AD)
bond_3ad_adapter_speed_duplex_changed(slave);
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 53c613fe6349994f023245519265999eed75957f Mon Sep 17 00:00:00 2001
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Tue, 25 Sep 2018 14:38:55 +0200
Subject: [PATCH] x86/speculation: Enable cross-hyperthread spectre v2 STIBP
mitigation
STIBP is a feature provided by certain Intel ucodes / CPUs. This feature
(once enabled) prevents cross-hyperthread control of decisions made by
indirect branch predictors.
Enable this feature if
- the CPU is vulnerable to spectre v2
- the CPU supports SMT and has SMT siblings online
- spectre_v2 mitigation autoselection is enabled (default)
After some previous discussion, this leaves STIBP on all the time, as wrmsr
on crossing kernel boundary is a no-no. This could perhaps later be a bit
more optimized (like disabling it in NOHZ, experiment with disabling it in
idle, etc) if needed.
Note that the synchronization of the mask manipulation via newly added
spec_ctrl_mutex is currently not strictly needed, as the only updater is
already being serialized by cpu_add_remove_lock, but let's make this a
little bit more future-proof.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "WoodhouseDavid" <dwmw(a)amazon.co.uk>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: "SchauflerCasey" <casey.schaufler(a)intel.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1809251438240.15880@cbobk.fhfr.pm
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea97fe7..53eb14a65610 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -35,12 +35,10 @@ static void __init spectre_v2_select_mitigation(void);
static void __init ssb_select_mitigation(void);
static void __init l1tf_select_mitigation(void);
-/*
- * Our boot-time value of the SPEC_CTRL MSR. We read it once so that any
- * writes to SPEC_CTRL contain whatever reserved bits have been set.
- */
-u64 __ro_after_init x86_spec_ctrl_base;
+/* The base value of the SPEC_CTRL MSR that always has to be preserved. */
+u64 x86_spec_ctrl_base;
EXPORT_SYMBOL_GPL(x86_spec_ctrl_base);
+static DEFINE_MUTEX(spec_ctrl_mutex);
/*
* The vendor and possibly platform specific bits which can be modified in
@@ -325,6 +323,46 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
return cmd;
}
+static bool stibp_needed(void)
+{
+ if (spectre_v2_enabled == SPECTRE_V2_NONE)
+ return false;
+
+ if (!boot_cpu_has(X86_FEATURE_STIBP))
+ return false;
+
+ return true;
+}
+
+static void update_stibp_msr(void *info)
+{
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+}
+
+void arch_smt_update(void)
+{
+ u64 mask;
+
+ if (!stibp_needed())
+ return;
+
+ mutex_lock(&spec_ctrl_mutex);
+ mask = x86_spec_ctrl_base;
+ if (cpu_smt_control == CPU_SMT_ENABLED)
+ mask |= SPEC_CTRL_STIBP;
+ else
+ mask &= ~SPEC_CTRL_STIBP;
+
+ if (mask != x86_spec_ctrl_base) {
+ pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
+ cpu_smt_control == CPU_SMT_ENABLED ?
+ "Enabling" : "Disabling");
+ x86_spec_ctrl_base = mask;
+ on_each_cpu(update_stibp_msr, NULL, 1);
+ }
+ mutex_unlock(&spec_ctrl_mutex);
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -424,6 +462,9 @@ static void __init spectre_v2_select_mitigation(void)
setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+
+ /* Enable STIBP if appropriate */
+ arch_smt_update();
}
#undef pr_fmt
@@ -814,6 +855,8 @@ static ssize_t l1tf_show_state(char *buf)
static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr,
char *buf, unsigned int bug)
{
+ int ret;
+
if (!boot_cpu_has_bug(bug))
return sprintf(buf, "Not affected\n");
@@ -831,10 +874,12 @@ static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
case X86_BUG_SPECTRE_V2:
- return sprintf(buf, "%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
+ ret = sprintf(buf, "%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled],
boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : "",
boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "",
+ (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ", STIBP" : "",
spectre_v2_module_string());
+ return ret;
case X86_BUG_SPEC_STORE_BYPASS:
return sprintf(buf, "%s\n", ssb_strings[ssb_mode]);
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aa7fe85ad62e..2fb49916ea56 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2025,6 +2025,12 @@ static void cpuhp_online_cpu_device(unsigned int cpu)
kobject_uevent(&dev->kobj, KOBJ_ONLINE);
}
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override this.
+ */
+void __weak arch_smt_update(void) { };
+
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
@@ -2051,8 +2057,10 @@ static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
*/
cpuhp_offline_cpu_device(cpu);
}
- if (!ret)
+ if (!ret) {
cpu_smt_control = ctrlval;
+ arch_smt_update();
+ }
cpu_maps_update_done();
return ret;
}
@@ -2063,6 +2071,7 @@ static int cpuhp_smt_enable(void)
cpu_maps_update_begin();
cpu_smt_control = CPU_SMT_ENABLED;
+ arch_smt_update();
for_each_present_cpu(cpu) {
/* Skip online CPUs and CPUs on offline nodes */
if (cpu_online(cpu) || !node_online(cpu_to_node(cpu)))
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 Mon Sep 17 00:00:00 2001
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Thu, 1 Nov 2018 00:30:22 -0700
Subject: [PATCH] acpi, nfit: Fix ARS overflow continuation
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a prescribed location. The
driver detects the overflow condition, but then fails to report it to
the ARS state machine after reaping the records. Propagate -ENOSPC
correctly to continue the ARS operation.
Cc: <stable(a)vger.kernel.org>
Fixes: 1cf03c00e7c1 ("nfit: scrub and register regions in a workqueue")
Reported-by: Jacek Zloch <jacek.zloch(a)intel.com>
Reviewed-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index f8c638f3c946..5970b8f5f768 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2928,9 +2928,9 @@ static int acpi_nfit_query_poison(struct acpi_nfit_desc *acpi_desc)
return rc;
if (ars_status_process_records(acpi_desc))
- return -ENOMEM;
+ dev_err(acpi_desc->dev, "Failed to process ARS records\n");
- return 0;
+ return rc;
}
static int ars_register(struct acpi_nfit_desc *acpi_desc,
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 Mon Sep 17 00:00:00 2001
From: Dan Williams <dan.j.williams(a)intel.com>
Date: Thu, 1 Nov 2018 00:30:22 -0700
Subject: [PATCH] acpi, nfit: Fix ARS overflow continuation
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a prescribed location. The
driver detects the overflow condition, but then fails to report it to
the ARS state machine after reaping the records. Propagate -ENOSPC
correctly to continue the ARS operation.
Cc: <stable(a)vger.kernel.org>
Fixes: 1cf03c00e7c1 ("nfit: scrub and register regions in a workqueue")
Reported-by: Jacek Zloch <jacek.zloch(a)intel.com>
Reviewed-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index f8c638f3c946..5970b8f5f768 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2928,9 +2928,9 @@ static int acpi_nfit_query_poison(struct acpi_nfit_desc *acpi_desc)
return rc;
if (ars_status_process_records(acpi_desc))
- return -ENOMEM;
+ dev_err(acpi_desc->dev, "Failed to process ARS records\n");
- return 0;
+ return rc;
}
static int ars_register(struct acpi_nfit_desc *acpi_desc,
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e8a308e5f47e545e0d41d0686c00f5f5217c5f61 Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:29 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Validate a MCE's address before using it
The NFIT machine check handler uses the physical address from the mce
structure, and compares it against information in the ACPI NFIT table
to determine whether that location lies on an NVDIMM. The mce->addr
field however may not always be valid, and this is indicated by the
MCI_STATUS_ADDRV bit in the status field.
Export mce_usable_address() which already performs validation for the
address, and use it in the NFIT handler.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Robert Elliott <elliott(a)hpe.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
Cc: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index dbd9fe2f6163..c1a812bd5a27 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -222,6 +222,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
bool mce_is_correctable(struct mce *m);
+int mce_usable_address(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 77527b8ea982..36d2696c9563 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -485,7 +485,7 @@ static void mce_report_event(struct pt_regs *regs)
* be somewhat complicated (e.g. segment offset would require an instruction
* parser). So only support physical addresses up to page granuality for now.
*/
-static int mce_usable_address(struct mce *m)
+int mce_usable_address(struct mce *m)
{
if (!(m->status & MCI_STATUS_ADDRV))
return 0;
@@ -505,6 +505,7 @@ static int mce_usable_address(struct mce *m)
return 1;
}
+EXPORT_SYMBOL_GPL(mce_usable_address);
bool mce_is_memory_error(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index 7a51707f87e9..d6c1b10f6c25 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -29,6 +29,10 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
+ /* Verify the address reported in the MCE is valid. */
+ if (!mce_usable_address(mce))
+ return NOTIFY_DONE;
+
/*
* mce->addr contains the physical addr accessed that caused the
* machine check. We need to walk through the list of NFITs, and see
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From e8a308e5f47e545e0d41d0686c00f5f5217c5f61 Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:29 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Validate a MCE's address before using it
The NFIT machine check handler uses the physical address from the mce
structure, and compares it against information in the ACPI NFIT table
to determine whether that location lies on an NVDIMM. The mce->addr
field however may not always be valid, and this is indicated by the
MCI_STATUS_ADDRV bit in the status field.
Export mce_usable_address() which already performs validation for the
address, and use it in the NFIT handler.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Robert Elliott <elliott(a)hpe.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
Cc: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index dbd9fe2f6163..c1a812bd5a27 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -222,6 +222,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
bool mce_is_correctable(struct mce *m);
+int mce_usable_address(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 77527b8ea982..36d2696c9563 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -485,7 +485,7 @@ static void mce_report_event(struct pt_regs *regs)
* be somewhat complicated (e.g. segment offset would require an instruction
* parser). So only support physical addresses up to page granuality for now.
*/
-static int mce_usable_address(struct mce *m)
+int mce_usable_address(struct mce *m)
{
if (!(m->status & MCI_STATUS_ADDRV))
return 0;
@@ -505,6 +505,7 @@ static int mce_usable_address(struct mce *m)
return 1;
}
+EXPORT_SYMBOL_GPL(mce_usable_address);
bool mce_is_memory_error(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index 7a51707f87e9..d6c1b10f6c25 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -29,6 +29,10 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
+ /* Verify the address reported in the MCE is valid. */
+ if (!mce_usable_address(mce))
+ return NOTIFY_DONE;
+
/*
* mce->addr contains the physical addr accessed that caused the
* machine check. We need to walk through the list of NFITs, and see
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5d96c9342c23ee1d084802dcf064caa67ecaa45b Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:28 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Handle only uncorrectable machine checks
The MCE handler for nfit devices is called for memory errors on a
Non-Volatile DIMM and adds the error location to a 'badblocks' list.
This list is used by the various NVDIMM drivers to avoid consuming known
poison locations during IO.
The MCE handler gets called for both corrected and uncorrectable errors.
Until now, both kinds of errors have been added to the badblocks list.
However, corrected memory errors indicate that the problem has already
been fixed by hardware, and the resulting interrupt is merely a
notification to Linux.
As far as future accesses to that location are concerned, it is
perfectly fine to use, and thus doesn't need to be included in the above
badblocks list.
Add a check in the nfit MCE handler to filter out corrected mce events,
and only process uncorrectable errors.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Omar Avelar <omar.avelar(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
CC: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 4da9b1c58d28..dbd9fe2f6163 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -221,6 +221,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
+bool mce_is_correctable(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8c66d2fc8f81..77527b8ea982 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -534,7 +534,7 @@ bool mce_is_memory_error(struct mce *m)
}
EXPORT_SYMBOL_GPL(mce_is_memory_error);
-static bool mce_is_correctable(struct mce *m)
+bool mce_is_correctable(struct mce *m)
{
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
@@ -547,6 +547,7 @@ static bool mce_is_correctable(struct mce *m)
return true;
}
+EXPORT_SYMBOL_GPL(mce_is_correctable);
static bool cec_add_mce(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index e9626bf6ca29..7a51707f87e9 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -25,8 +25,8 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
struct acpi_nfit_desc *acpi_desc;
struct nfit_spa *nfit_spa;
- /* We only care about memory errors */
- if (!mce_is_memory_error(mce))
+ /* We only care about uncorrectable memory errors */
+ if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
/*
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5d96c9342c23ee1d084802dcf064caa67ecaa45b Mon Sep 17 00:00:00 2001
From: Vishal Verma <vishal.l.verma(a)intel.com>
Date: Thu, 25 Oct 2018 18:37:28 -0600
Subject: [PATCH] acpi/nfit, x86/mce: Handle only uncorrectable machine checks
The MCE handler for nfit devices is called for memory errors on a
Non-Volatile DIMM and adds the error location to a 'badblocks' list.
This list is used by the various NVDIMM drivers to avoid consuming known
poison locations during IO.
The MCE handler gets called for both corrected and uncorrectable errors.
Until now, both kinds of errors have been added to the badblocks list.
However, corrected memory errors indicate that the problem has already
been fixed by hardware, and the resulting interrupt is merely a
notification to Linux.
As far as future accesses to that location are concerned, it is
perfectly fine to use, and thus doesn't need to be included in the above
badblocks list.
Add a check in the nfit MCE handler to filter out corrected mce events,
and only process uncorrectable errors.
Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error")
Reported-by: Omar Avelar <omar.avelar(a)intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
CC: Arnd Bergmann <arnd(a)arndb.de>
CC: Dan Williams <dan.j.williams(a)intel.com>
CC: Dave Jiang <dave.jiang(a)intel.com>
CC: elliott(a)hpe.com
CC: "H. Peter Anvin" <hpa(a)zytor.com>
CC: Ingo Molnar <mingo(a)redhat.com>
CC: Len Brown <lenb(a)kernel.org>
CC: linux-acpi(a)vger.kernel.org
CC: linux-edac <linux-edac(a)vger.kernel.org>
CC: linux-nvdimm(a)lists.01.org
CC: Qiuxu Zhuo <qiuxu.zhuo(a)intel.com>
CC: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
CC: Ross Zwisler <zwisler(a)kernel.org>
CC: stable <stable(a)vger.kernel.org>
CC: Thomas Gleixner <tglx(a)linutronix.de>
CC: Tony Luck <tony.luck(a)intel.com>
CC: x86-ml <x86(a)kernel.org>
CC: Yazen Ghannam <yazen.ghannam(a)amd.com>
Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.com
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 4da9b1c58d28..dbd9fe2f6163 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -221,6 +221,7 @@ static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return mce_am
int mce_available(struct cpuinfo_x86 *c);
bool mce_is_memory_error(struct mce *m);
+bool mce_is_correctable(struct mce *m);
DECLARE_PER_CPU(unsigned, mce_exception_count);
DECLARE_PER_CPU(unsigned, mce_poll_count);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 8c66d2fc8f81..77527b8ea982 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -534,7 +534,7 @@ bool mce_is_memory_error(struct mce *m)
}
EXPORT_SYMBOL_GPL(mce_is_memory_error);
-static bool mce_is_correctable(struct mce *m)
+bool mce_is_correctable(struct mce *m)
{
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
@@ -547,6 +547,7 @@ static bool mce_is_correctable(struct mce *m)
return true;
}
+EXPORT_SYMBOL_GPL(mce_is_correctable);
static bool cec_add_mce(struct mce *m)
{
diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c
index e9626bf6ca29..7a51707f87e9 100644
--- a/drivers/acpi/nfit/mce.c
+++ b/drivers/acpi/nfit/mce.c
@@ -25,8 +25,8 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val,
struct acpi_nfit_desc *acpi_desc;
struct nfit_spa *nfit_spa;
- /* We only care about memory errors */
- if (!mce_is_memory_error(mce))
+ /* We only care about uncorrectable memory errors */
+ if (!mce_is_memory_error(mce) || mce_is_correctable(mce))
return NOTIFY_DONE;
/*
This reverts commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3.
Turns out that commit is wrong. Host controllers are allowed to use
Clear Feature HALT as means to sync data toggle between host and
periperal.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/gadget.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 9faad896b3a1..9f92ee03dde7 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1470,9 +1470,6 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
unsigned transfer_in_flight;
unsigned started;
- if (dep->flags & DWC3_EP_STALL)
- return 0;
-
if (dep->number > 1)
trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
else
@@ -1494,8 +1491,6 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
else
dep->flags |= DWC3_EP_STALL;
} else {
- if (!(dep->flags & DWC3_EP_STALL))
- return 0;
ret = dwc3_send_clear_stall_ep_cmd(dep);
if (ret)
--
2.19.1
Hi,
that patch is not 100% correct. You can revert it in your tree. I added
that because of a problem I found when running adb against macOS.
It's actually okay to send Clear Halt at any time, but for some reason
dwc3 was hanging when running adb against macOS.
If you can revert the patch and make sure it works against all 3 major
OSes (linux, windows and mac) I'd be really glad.
liangshengjun <liangshengjun(a)hisilicon.com> writes:
> Hi felipe,
>
> I have met a case about set/clear Halt patch
> Version: linux v4.16,
> Case: usb uvc run with bulk-mode connect to Windows 7 PC. When PC stop camera application , it would send clearHalt request to uvc device to streaming-off video transfer.
> But with v4.16 dwc3 drivers, it would skip handling this clear Halt request , because dep->flags is not DWC3_EP_STALL status, then it causes PC restart camera application , uvc transfer fail.
> And I have confirmed v3.18 dwc3 drivers is OK.
>
> So how to balance for handling clear Halt without first setHalt ??
>
> PS:
> commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3
> Author: Felipe Balbi <felipe.balbi(a)linux.intel.com>
> Date: Thu Jan 19 13:38:42 2017 +0200
>
> usb: dwc3: gadget: skip Set/Clear Halt when invalid
>
> At least macOS seems to be sending
> ClearFeature(ENDPOINT_HALT) to endpoints which
> aren't Halted. This makes DWC3's CLEARSTALL command
> time out which causes several issues for the driver.
>
> Instead, let's just return 0 and bail out early.
>
> Cc: <stable(a)vger.kernel.org>
> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 6faf484..0a664d8 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
> unsigned transfer_in_flight;
> unsigned started;
>
> + if (dep->flags & DWC3_EP_STALL)
> + return 0;
> +
> if (dep->number > 1)
> trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
> else
> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, int value, int protocol)
> else
> dep->flags |= DWC3_EP_STALL;
> } else {
> + if (!(dep->flags & DWC3_EP_STALL))
> + return 0;
>
> ret = dwc3_send_clear_stall_ep_cmd(dep);
> if (ret)
>
>
> Liang Shengjun
> [cid:image001.png@01D40971.9265B340]
> HISILICON TECHNOLOGIES CO., LTD.
> New R&D Center, Wuhe Road, Bantian,
> Longgang District, Shenzhen 518129 P.R. China
>
--
balbi
Hi Greg,
I noticed that 3.18.125 added commit bc07ee33284a ('Revert "drm/i915:
Fix mutex->owner inspection race under DEBUG_MUTEXES"'), which states
that the reason it can be applied is:
The core fix was applied in
commit a63b03e2d2477586440741677ecac45bcf28d7b1
Author: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Tue Jan 6 10:29:35 2015 +0000
mutex: Always clear owner field upon mutex_unlock()
(note the absence of stable@ tag)
so we can now revert our band-aid commit 226e5ae9e5f910 for -next.
but that the commit referenced wasn't also pulled in.
Please consider pulling that one too if you're going to do another 3.18
stable release.
Thanks,
Tom
Use the new of_get_compatible_child() helper to lookup the nfc child
node instead of using of_find_compatible_node(), which searches the
entire tree from a given start node and thus can return an unrelated
(i.e. non-child) node.
This also addresses a potential use-after-free (e.g. after probe
deferral) as the tree-wide helper drops a reference to its first
argument (i.e. the node of the device being probed).
While at it, also fix a related nfc-node reference leak.
Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
Cc: stable <stable(a)vger.kernel.org> # 4.11
Cc: Nicolas Ferre <nicolas.ferre(a)microchip.com>
Cc: Josh Wu <rainyfeeling(a)outlook.com>
Cc: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index a068b214ebaa..d3dfe63956ac 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -2061,8 +2061,7 @@ atmel_hsmc_nand_controller_legacy_init(struct atmel_hsmc_nand_controller *nc)
int ret;
nand_np = dev->of_node;
- nfc_np = of_find_compatible_node(dev->of_node, NULL,
- "atmel,sama5d3-nfc");
+ nfc_np = of_get_compatible_child(dev->of_node, "atmel,sama5d3-nfc");
nc->clk = of_clk_get(nfc_np, 0);
if (IS_ERR(nc->clk)) {
@@ -2472,15 +2471,19 @@ static int atmel_nand_controller_probe(struct platform_device *pdev)
}
if (caps->legacy_of_bindings) {
+ struct device_node *nfc_node;
u32 ale_offs = 21;
/*
* If we are parsing legacy DT props and the DT contains a
* valid NFC node, forward the request to the sama5 logic.
*/
- if (of_find_compatible_node(pdev->dev.of_node, NULL,
- "atmel,sama5d3-nfc"))
+ nfc_node = of_get_compatible_child(pdev->dev.of_node,
+ "atmel,sama5d3-nfc");
+ if (nfc_node) {
caps = &atmel_sama5_nand_caps;
+ of_node_put(nfc_node);
+ }
/*
* Even if the compatible says we are dealing with an
--
2.18.0
From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Subject: scripts/spdxcheck.py: make python3 compliant
Without this change the following happens when using Python3 (3.6.6):
$ echo "GPL-2.0" | python3 scripts/spdxcheck.py -
FAIL: 'str' object has no attribute 'decode'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 253, in <module>
parser.parse_lines(sys.stdin, args.maxlines, '-')
File "scripts/spdxcheck.py", line 171, in parse_lines
line = line.decode(locale.getpreferredencoding(False), errors='ignore')
AttributeError: 'str' object has no attribute 'decode'
So as the line is already a string, there is no need to decode it and
the line can be dropped.
/usr/bin/python on Arch is Python 3. So this would indeed be worth
going into 4.19.
Link: http://lkml.kernel.org/r/20181023070802.22558-1-u.kleine-koenig@pengutronix…
Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Joe Perches <joe(a)perches.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/scripts/spdxcheck.py~scripts-spdxcheck-make-python3-compliant
+++ a/scripts/spdxcheck.py
@@ -168,7 +168,6 @@ class id_parser(object):
self.curline = 0
try:
for line in fd:
- line = line.decode(locale.getpreferredencoding(False), errors='ignore')
self.curline += 1
if self.curline > maxlines:
break
_
From: Daniel Colascione <dancol(a)google.com>
commit 1ae80cf31938c8f77c37a29bbe29e7f1cd492be8 upstream.
The map-in-map frequently serves as a mechanism for atomic
snapshotting of state that a BPF program might record. The current
implementation is dangerous to use in this way, however, since
userspace has no way of knowing when all programs that might have
retrieved the "old" value of the map may have completed.
This change ensures that map update operations on map-in-map map types
always wait for all references to the old map to drop before returning
to userspace.
Signed-off-by: Daniel Colascione <dancol(a)google.com>
Reviewed-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
[fengc(a)google.com: 4.19 clean cherry-picks, no modification]
Signed-off-by: Chenbo Feng <fengc(a)google.com>
---
kernel/bpf/syscall.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 8339d81cba1d..675eb6d36e47 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -741,6 +741,17 @@ static int map_lookup_elem(union bpf_attr *attr)
return err;
}
+static void maybe_wait_bpf_programs(struct bpf_map *map)
+{
+ /* Wait for any running BPF programs to complete so that
+ * userspace, when we return to it, knows that all programs
+ * that could be running use the new map value.
+ */
+ if (map->map_type == BPF_MAP_TYPE_HASH_OF_MAPS ||
+ map->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS)
+ synchronize_rcu();
+}
+
#define BPF_MAP_UPDATE_ELEM_LAST_FIELD flags
static int map_update_elem(union bpf_attr *attr)
@@ -831,6 +842,7 @@ static int map_update_elem(union bpf_attr *attr)
}
__this_cpu_dec(bpf_prog_active);
preempt_enable();
+ maybe_wait_bpf_programs(map);
out:
free_value:
kfree(value);
@@ -883,6 +895,7 @@ static int map_delete_elem(union bpf_attr *attr)
rcu_read_unlock();
__this_cpu_dec(bpf_prog_active);
preempt_enable();
+ maybe_wait_bpf_programs(map);
out:
kfree(key);
err_put:
--
2.19.1.930.g4563a0d9d0-goog
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 99a3ae51d557d8e38a7aece65678a31f9db215ee Mon Sep 17 00:00:00 2001
From: Helge Deller <deller(a)gmx.de>
Date: Sun, 14 Oct 2018 21:58:00 +0200
Subject: [PATCH] parisc: Fix exported address of os_hpmc handler
In the C-code we need to put the physical address of the hpmc handler in
the interrupt vector table (IVA) in order to get HPMCs working. Since
on parisc64 function pointers are indirect (in fact they are function
descriptors) we instead export the address as variable and not as
function.
This reverts a small part of commit f39cce654f9a ("parisc: Add
cfi_startproc and cfi_endproc to assembly code").
Signed-off-by: Helge Deller <deller(a)gmx.de>
Cc: <stable(a)vger.kernel.org> [4.9+]
diff --git a/arch/parisc/kernel/hpmc.S b/arch/parisc/kernel/hpmc.S
index 781c3b9a3e46..fde654115564 100644
--- a/arch/parisc/kernel/hpmc.S
+++ b/arch/parisc/kernel/hpmc.S
@@ -85,7 +85,7 @@ END(hpmc_pim_data)
.import intr_save, code
.align 16
-ENTRY_CFI(os_hpmc)
+ENTRY(os_hpmc)
.os_hpmc:
/*
@@ -302,7 +302,6 @@ os_hpmc_6:
b .
nop
.align 16 /* make function length multiple of 16 bytes */
-ENDPROC_CFI(os_hpmc)
.os_hpmc_end:
Hello,
Please picked up this patch for linux 4.4 and 4.9.
Compiled/tested without problem.
Thank.
[ Upstream commit 5983587c8c5ef00d6886477544ad67d495bc5479 ]
From: Colin Ian King <colin.king(a)canonical.com>
Date: Fri, 22 Sep 2017 18:13:48 +0100
Subject: [PATCH] e1000: avoid null pointer dereference on invalid stat type
Currently if the stat type is invalid then data[i] is being set
either by dereferencing a null pointer p, or it is reading from
an incorrect previous location if we had a valid stat type
previously. Fix this by skipping over the read of p on an invalid
stat type.
Detected by CoverityScan, CID#113385 ("Explicit null dereferenced")
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
index ec8aa4562cc90..3b3983a1ffbba 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
@@ -1824,11 +1824,12 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
int i;
- char *p = NULL;
const struct e1000_stats *stat = e1000_gstrings_stats;
e1000_update_stats(adapter);
- for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++) {
+ for (i = 0; i < E1000_GLOBAL_STATS_LEN; i++, stat++) {
+ char *p;
+
switch (stat->type) {
case NETDEV_STATS:
p = (char *)netdev + stat->stat_offset;
@@ -1839,15 +1840,13 @@ static void e1000_get_ethtool_stats(struct net_device *netdev,
default:
WARN_ONCE(1, "Invalid E1000 stat type: %u index %d\n",
stat->type, i);
- break;
+ continue;
}
if (stat->sizeof_stat == sizeof(u64))
data[i] = *(u64 *)p;
else
data[i] = *(u32 *)p;
-
- stat++;
}
/* BUG_ON(i != E1000_STATS_LEN); */
}
Hello,
Please picked up this patch for linux 4.4 and 4.9.
Compiled/tested without problem.
Thank.
[ Upstream commit 44c445c3d1b4eacff23141fa7977c3b2ec3a45c9 ]
From: Vincenzo Maffione <v.maffione(a)gmail.com>
Date: Sat, 16 Sep 2017 18:00:00 +0200
Subject: [PATCH] e1000: fix race condition between e1000_down() and
e1000_watchdog
This patch fixes a race condition that can result into the interface being
up and carrier on, but with transmits disabled in the hardware.
The bug may show up by repeatedly IFF_DOWN+IFF_UP the interface, which
allows e1000_watchdog() interleave with e1000_down().
CPU x CPU y
--------------------------------------------------------------------
e1000_down():
netif_carrier_off()
e1000_watchdog():
if (carrier == off) {
netif_carrier_on();
enable_hw_transmit();
}
disable_hw_transmit();
e1000_watchdog():
/* carrier on, do nothing */
Signed-off-by: Vincenzo Maffione <v.maffione(a)gmail.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 98375e1e1185e..1982f7917a8d5 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -520,8 +520,6 @@ void e1000_down(struct e1000_adapter *adapter)
struct net_device *netdev = adapter->netdev;
u32 rctl, tctl;
- netif_carrier_off(netdev);
-
/* disable receives in the hardware */
rctl = er32(RCTL);
ew32(RCTL, rctl & ~E1000_RCTL_EN);
@@ -537,6 +535,15 @@ void e1000_down(struct e1000_adapter *adapter)
E1000_WRITE_FLUSH();
msleep(10);
+ /* Set the carrier off after transmits have been disabled in the
+ * hardware, to avoid race conditions with e1000_watchdog() (which
+ * may be running concurrently to us, checking for the carrier
+ * bit to decide whether it should enable transmits again). Such
+ * a race condition would result into transmission being disabled
+ * in the hardware until the next IFF_DOWN+IFF_UP cycle.
+ */
+ netif_carrier_off(netdev);
+
napi_disable(&adapter->napi);
e1000_irq_disable(adapter);
Hello,
Please picked up this patch for linux 4.4 and 4.9.
Compiled/tested without problem.
Thank.
[ Upstream commit 4dc69c1c1fff2f587f8e737e70b4a4e7565a5c94 ]
From: Kees Cook <keescook(a)chromium.org>
Date: Fri, 5 May 2017 15:30:23 -0700
Subject: [PATCH] bna: ethtool: Avoid reading past end of buffer
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. Instead, use strncpy() which will fill the trailing bytes
with zeros.
This was found with the future CONFIG_FORTIFY_SOURCE feature.
Cc: Daniel Micay <danielmicay(a)gmail.com>
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
---
drivers/net/ethernet/brocade/bna/bnad_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
index 286593922139e..31032de5843b1 100644
--- a/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
+++ b/drivers/net/ethernet/brocade/bna/bnad_ethtool.c
@@ -547,8 +547,8 @@ bnad_get_strings(struct net_device *netdev, u32 stringset, u8 *string)
for (i = 0; i < BNAD_ETHTOOL_STATS_NUM; i++) {
BUG_ON(!(strlen(bnad_net_stats_strings[i]) <
ETH_GSTRING_LEN));
- memcpy(string, bnad_net_stats_strings[i],
- ETH_GSTRING_LEN);
+ strncpy(string, bnad_net_stats_strings[i],
+ ETH_GSTRING_LEN);
string += ETH_GSTRING_LEN;
}
bmap = bna_tx_rid_mask(&bnad->bna);
mstc->port isn't validated here so it could be null or worse when we
access it. And drivers aren't ever supposed to be looking at it's
contents anyway. Plus, we can already get the MST manager from
&mstc->mstm->mgr.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e6f72ca0b1fa..66c40b56a0cb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -893,7 +893,8 @@ nv50_mstc_get_modes(struct drm_connector *connector)
struct nv50_mstc *mstc = nv50_mstc(connector);
int ret = 0;
- mstc->edid = drm_dp_mst_get_edid(&mstc->connector, mstc->port->mgr, mstc->port);
+ mstc->edid = drm_dp_mst_get_edid(&mstc->connector,
+ &mstc->mstm->mgr, mstc->port);
drm_connector_update_edid_property(&mstc->connector, mstc->edid);
if (mstc->edid)
ret = drm_add_edid_modes(&mstc->connector, mstc->edid);
--
2.19.1
From: Roman Gushchin <guro(a)fb.com>
Subject: mm: don't reclaim inodes with many attached pages
Spock reported that the commit 172b06c32b94 ("mm: slowly shrink slabs with
a relatively small number of objects") leads to a regression on his setup:
periodically the majority of the pagecache is evicted without an obvious
reason, while before the change the amount of free memory was balancing
around the watermark.
The reason behind is that the mentioned above change created some minimal
background pressure on the inode cache. The problem is that if an inode
is considered to be reclaimed, all belonging pagecache page are stripped,
no matter how many of them are there. So, if a huge multi-gigabyte file
is cached in the memory, and the goal is to reclaim only few slab objects
(unused inodes), we still can eventually evict all gigabytes of the
pagecache at once.
The workload described by Spock has few large non-mapped files in the
pagecache, so it's especially noticeable.
To solve the problem let's postpone the reclaim of inodes, which have more
than 1 attached page. Let's wait until the pagecache pages will be
evicted naturally by scanning the corresponding LRU lists, and only then
reclaim the inode structure.
Link: http://lkml.kernel.org/r/20181023164302.20436-1-guro@fb.com
Signed-off-by: Roman Gushchin <guro(a)fb.com>
Reported-by: Spock <dairinin(a)gmail.com>
Tested-by: Spock <dairinin(a)gmail.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Rik van Riel <riel(a)surriel.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: <stable(a)vger.kernel.org> [4.19.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/inode.c~mm-dont-reclaim-inodes-with-many-attached-pages
+++ a/fs/inode.c
@@ -730,8 +730,11 @@ static enum lru_status inode_lru_isolate
return LRU_REMOVED;
}
- /* recently referenced inodes get one more pass */
- if (inode->i_state & I_REFERENCED) {
+ /*
+ * Recently referenced inodes and inodes with many attached pages
+ * get one more pass.
+ */
+ if (inode->i_state & I_REFERENCED || inode->i_data.nrpages > 1) {
inode->i_state &= ~I_REFERENCED;
spin_unlock(&inode->i_lock);
return LRU_ROTATE;
_
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: lib/ubsan.c: don't mark __ubsan_handle_builtin_unreachable as noreturn
gcc-8 complains about the prototype for this function:
lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a built-in function '__ubsan_handle_builtin_unreachable' because it conflicts with attribute 'const' [-Werror=attributes]
This is actually a GCC's bug. In GCC internals
__ubsan_handle_builtin_unreachable() declared with both 'noreturn' and
'const' attributes instead of only 'noreturn':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84210
Workaround this by removing the noreturn attribute.
[aryabinin: add information about GCC bug in changelog]
Link: http://lkml.kernel.org/r/20181107144516.4587-1-aryabinin@virtuozzo.com
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Acked-by: Olof Johansson <olof(a)lixom.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/lib/ubsan.c~ubsan-dont-mark-__ubsan_handle_builtin_unreachable-as-noreturn
+++ a/lib/ubsan.c
@@ -427,8 +427,7 @@ void __ubsan_handle_shift_out_of_bounds(
EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds);
-void __noreturn
-__ubsan_handle_builtin_unreachable(struct unreachable_data *data)
+void __ubsan_handle_builtin_unreachable(struct unreachable_data *data)
{
unsigned long flags;
_
From: Wengang Wang <wen.gang.wang(a)oracle.com>
Subject: ocfs2: free up write context when direct IO failed
The write context should also be freed even when direct IO failed.
Otherwise a memory leak is introduced and entries remain in
oi->ip_unwritten_list causing the following BUG later in unlink path:
ERROR: bug expression: !list_empty(&oi->ip_unwritten_list)
ERROR: Clear inode of 215043, inode has unwritten extents
...
Call Trace:
? __set_current_blocked+0x42/0x68
ocfs2_evict_inode+0x91/0x6a0 [ocfs2]
? bit_waitqueue+0x40/0x33
evict+0xdb/0x1af
iput+0x1a2/0x1f7
do_unlinkat+0x194/0x28f
SyS_unlinkat+0x1b/0x2f
do_syscall_64+0x79/0x1ae
entry_SYSCALL_64_after_hwframe+0x151/0x0
This patch also logs, with frequency limit, direct IO failures.
Link: http://lkml.kernel.org/r/20181102170632.25921-1-wen.gang.wang@oracle.com
Signed-off-by: Wengang Wang <wen.gang.wang(a)oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi(a)oracle.com>
Reviewed-by: Changwei Ge <ge.changwei(a)h3c.com>
Reviewed-by: Joseph Qi <jiangqi903(a)gmail.com>
Cc: Mark Fasheh <mark(a)fasheh.com>
Cc: Joel Becker <jlbec(a)evilplan.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/fs/ocfs2/aops.c~ocfs2-free-up-write-context-when-direct-io-failed
+++ a/fs/ocfs2/aops.c
@@ -2411,8 +2411,16 @@ static int ocfs2_dio_end_io(struct kiocb
/* this io's submitter should not have unlocked this before we could */
BUG_ON(!ocfs2_iocb_is_rw_locked(iocb));
- if (bytes > 0 && private)
- ret = ocfs2_dio_end_io_write(inode, private, offset, bytes);
+ if (bytes <= 0)
+ mlog_ratelimited(ML_ERROR, "Direct IO failed, bytes = %lld",
+ (long long)bytes);
+ if (private) {
+ if (bytes > 0)
+ ret = ocfs2_dio_end_io_write(inode, private, offset,
+ bytes);
+ else
+ ocfs2_dio_free_write_ctx(inode, private);
+ }
ocfs2_iocb_clear_rw_locked(iocb);
--- a/fs/ocfs2/cluster/masklog.h~ocfs2-free-up-write-context-when-direct-io-failed
+++ a/fs/ocfs2/cluster/masklog.h
@@ -178,6 +178,15 @@ do { \
##__VA_ARGS__); \
} while (0)
+#define mlog_ratelimited(mask, fmt, ...) \
+do { \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ if (__ratelimit(&_rs)) \
+ mlog(mask, fmt, ##__VA_ARGS__); \
+} while (0)
+
#define mlog_errno(st) ({ \
int _st = (st); \
if (_st != -ERESTARTSYS && _st != -EINTR && \
_
From: Vasily Averin <vvs(a)virtuozzo.com>
Subject: mm/swapfile.c: use kvzalloc for swap_info_struct allocation
a2468cc9bfdf ("swap: choose swap device according to numa node") changed
'avail_lists' field of 'struct swap_info_struct' to an array. In popular
linux distros it increased size of swap_info_struct up to 40 Kbytes and
now swap_info_struct allocation requires order-4 page. Switch to
kvzmalloc allows to avoid unexpected allocation failures.
Link: http://lkml.kernel.org/r/fc23172d-3c75-21e2-d551-8b1808cbe593@virtuozzo.com
Fixes: a2468cc9bfdf ("swap: choose swap device according to numa node")
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Acked-by: Aaron Lu <aaron.lu(a)intel.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Huang Ying <ying.huang(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/swapfile.c~mm-use-kvzalloc-for-swap_info_struct-allocation
+++ a/mm/swapfile.c
@@ -2813,7 +2813,7 @@ static struct swap_info_struct *alloc_sw
unsigned int type;
int i;
- p = kzalloc(sizeof(*p), GFP_KERNEL);
+ p = kvzalloc(sizeof(*p), GFP_KERNEL);
if (!p)
return ERR_PTR(-ENOMEM);
@@ -2824,7 +2824,7 @@ static struct swap_info_struct *alloc_sw
}
if (type >= MAX_SWAPFILES) {
spin_unlock(&swap_lock);
- kfree(p);
+ kvfree(p);
return ERR_PTR(-EPERM);
}
if (type >= nr_swapfiles) {
@@ -2838,7 +2838,7 @@ static struct swap_info_struct *alloc_sw
smp_wmb();
nr_swapfiles++;
} else {
- kfree(p);
+ kvfree(p);
p = swap_info[type];
/*
* Do not memset this entry: a racing procfs swap_next()
_
From: Mike Kravetz <mike.kravetz(a)oracle.com>
Subject: hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444!
This bug has been experienced several times by Oracle DB team. The BUG is
in remove_inode_hugepages() as follows:
/*
* If page is mapped, it was faulted in after being
* unmapped in caller. Unmap (again) now after taking
* the fault mutex. The mutex will prevent faults
* until we finish removing the page.
*
* This race can only happen in the hole punch case.
* Getting here in a truncate operation is a bug.
*/
if (unlikely(page_mapped(page))) {
BUG_ON(truncate_op);
In this case, the elevated map count is not the result of a race. Rather
it was incorrectly incremented as the result of a bug in the huge pmd
sharing code. Consider the following:
- Process A maps a hugetlbfs file of sufficient size and alignment
(PUD_SIZE) that a pmd page could be shared.
- Process B maps the same hugetlbfs file with the same size and alignment
such that a pmd page is shared.
- Process B then calls mprotect() to change protections for the mapping
with the shared pmd. As a result, the pmd is 'unshared'.
- Process B then calls mprotect() again to chage protections for the
mapping back to their original value. pmd remains unshared.
- Process B then forks and process C is created. During the fork process,
we do dup_mm -> dup_mmap -> copy_page_range to copy page tables. Copying
page tables for hugetlb mappings is done in the routine
copy_hugetlb_page_range.
In copy_hugetlb_page_range(), the destination pte is obtained by:
dst_pte = huge_pte_alloc(dst, addr, sz);
If pmd sharing is possible, the returned pointer will be to a pte in an
existing page table. In the situation above, process C could share with
either process A or process B. Since process A is first in the list, the
returned pte is a pointer to a pte in process A's page table.
However, the following check for pmd sharing is in
copy_hugetlb_page_range.
/* If the pagetables are shared don't copy or take references */
if (dst_pte == src_pte)
continue;
Since process C is sharing with process A instead of process B, the above
test fails. The code in copy_hugetlb_page_range which follows assumes
dst_pte points to a huge_pte_none pte. It copies the pte entry from
src_pte to dst_pte and increments this map count of the associated page.
This is how we end up with an elevated map count.
To solve, check the dst_pte entry for huge_pte_none. If !none, this
implies PMD sharing so do not copy.
Link: http://lkml.kernel.org/r/20181105212315.14125-1-mike.kravetz@oracle.com
Fixes: c5c99429fa57 ("fix hugepages leak due to pagetable page sharing")
Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Prakash Sangappa <prakash.sangappa(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/hugetlb.c~hugetlbfs-fix-kernel-bug-at-fs-hugetlbfs-inodec-444
+++ a/mm/hugetlb.c
@@ -3233,7 +3233,7 @@ static int is_hugetlb_entry_hwpoisoned(p
int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)
{
- pte_t *src_pte, *dst_pte, entry;
+ pte_t *src_pte, *dst_pte, entry, dst_entry;
struct page *ptepage;
unsigned long addr;
int cow;
@@ -3261,15 +3261,30 @@ int copy_hugetlb_page_range(struct mm_st
break;
}
- /* If the pagetables are shared don't copy or take references */
- if (dst_pte == src_pte)
+ /*
+ * If the pagetables are shared don't copy or take references.
+ * dst_pte == src_pte is the common case of src/dest sharing.
+ *
+ * However, src could have 'unshared' and dst shares with
+ * another vma. If dst_pte !none, this implies sharing.
+ * Check here before taking page table lock, and once again
+ * after taking the lock below.
+ */
+ dst_entry = huge_ptep_get(dst_pte);
+ if ((dst_pte == src_pte) || !huge_pte_none(dst_entry))
continue;
dst_ptl = huge_pte_lock(h, dst, dst_pte);
src_ptl = huge_pte_lockptr(h, src, src_pte);
spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
entry = huge_ptep_get(src_pte);
- if (huge_pte_none(entry)) { /* skip none entry */
+ dst_entry = huge_ptep_get(dst_pte);
+ if (huge_pte_none(entry) || !huge_pte_none(dst_entry)) {
+ /*
+ * Skip if src entry none. Also, skip in the
+ * unlikely case dst entry !none as this implies
+ * sharing with another vma.
+ */
;
} else if (unlikely(is_hugetlb_entry_migration(entry) ||
is_hugetlb_entry_hwpoisoned(entry))) {
_
From: Kan Liang <kan.liang(a)linux.intel.com>
The client IMC bandwidth events return very huge result.
perf stat -e uncore_imc/data_reads/ -e uncore_imc/data_writes/ -I
10000 -a
10.000117222 34,788.76 MiB uncore_imc/data_reads/
10.000117222 8.26 MiB uncore_imc/data_writes/
20.000374584 34,842.89 MiB uncore_imc/data_reads/
20.000374584 10.45 MiB uncore_imc/data_writes/
30.000633299 37,965.29 MiB uncore_imc/data_reads/
30.000633299 323.62 MiB uncore_imc/data_writes/
40.000891548 41,012.88 MiB uncore_imc/data_reads/
40.000891548 6.98 MiB uncore_imc/data_writes/
50.001142480 1,125,899,906,621,494.75 MiB uncore_imc/data_reads/
50.001142480 6.97 MiB uncore_imc/data_writes/
The client IMC events are freerunning counters. They still use the
old event encoding format (0x1 for data_read and 0x2 for data write).
The counter bit width is calculated by common code, which assume that
the standard encoding format is used for the freerunning counters.
Error bit width information is calculated.
The event->attr.config, which directly from user space, should not be
used by the functions of freerunning counters.
For client IMC events, the attr.config needs to be converted to the
standard encoding format. The modified event config will be stored in
event->hw.config.
For other freerunning counters, the attr.config has the correct format.
Just save it in event->hw.config.
Using event->hw.config to replace event->attr.config for the functions
of freerunning counters.
Fix: commit 9aae1780e7e8 ("perf/x86/intel/uncore: Clean up client IMC
uncore")
Reported-by: Jin Yao <yao.jin(a)linux.intel.com>
Tested-by: Jin Yao <yao.jin(a)linux.intel.com>
Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com>
---
arch/x86/events/intel/uncore.c | 1 +
arch/x86/events/intel/uncore.h | 12 ++++++------
arch/x86/events/intel/uncore_snb.c | 4 +++-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 27a461414b30..2690135bf83f 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -740,6 +740,7 @@ static int uncore_pmu_event_init(struct perf_event *event)
/* fixed counters have event field hardcoded to zero */
hwc->config = 0ULL;
} else if (is_freerunning_event(event)) {
+ hwc->config = event->attr.config;
if (!check_valid_freerunning_event(box, event))
return -EINVAL;
event->hw.idx = UNCORE_PMC_IDX_FREERUNNING;
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index e17ab885b1e9..cc6dd4f78158 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -285,8 +285,8 @@ static inline
unsigned int uncore_freerunning_counter(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
- unsigned int idx = uncore_freerunning_idx(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
+ unsigned int idx = uncore_freerunning_idx(event->hw.config);
struct intel_uncore_pmu *pmu = box->pmu;
return pmu->type->freerunning[type].counter_base +
@@ -360,7 +360,7 @@ static inline
unsigned int uncore_freerunning_bits(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
return box->pmu->type->freerunning[type].bits;
}
@@ -368,7 +368,7 @@ unsigned int uncore_freerunning_bits(struct intel_uncore_box *box,
static inline int uncore_num_freerunning(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
return box->pmu->type->freerunning[type].num_counters;
}
@@ -382,8 +382,8 @@ static inline int uncore_num_freerunning_types(struct intel_uncore_box *box,
static inline bool check_valid_freerunning_event(struct intel_uncore_box *box,
struct perf_event *event)
{
- unsigned int type = uncore_freerunning_type(event->attr.config);
- unsigned int idx = uncore_freerunning_idx(event->attr.config);
+ unsigned int type = uncore_freerunning_type(event->hw.config);
+ unsigned int idx = uncore_freerunning_idx(event->hw.config);
return (type < uncore_num_freerunning_types(box, event)) &&
(idx < uncore_num_freerunning(box, event));
diff --git a/arch/x86/events/intel/uncore_snb.c b/arch/x86/events/intel/uncore_snb.c
index 8527c3e1038b..48d7121f71c7 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -425,9 +425,11 @@ static int snb_uncore_imc_event_init(struct perf_event *event)
/* must be done before validate_group */
event->hw.event_base = base;
- event->hw.config = cfg;
event->hw.idx = idx;
+ /* Convert to standard encoding format for free running counters */
+ event->hw.config = ((cfg - 1) << 8) | 0x10ff;
+
/* no group validation needed, we have free running counters */
return 0;
--
2.14.3
From: Rafał Miłecki <rafal(a)milecki.pl>
Driver can report IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ so it's
important to provide valid & complete info about supported bands for
each channel. By default no support for 160 MHz should be assumed unless
firmware reports it for a given channel later.
This fixes info passed to the userspace. Without that change userspace
could try to use invalid channel and fail to start an interface.
Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl>
Cc: stable(a)vger.kernel.org
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 230a378c26fc..7f0a5bade70a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6005,7 +6005,8 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
* for subsequent chanspecs.
*/
channel->flags = IEEE80211_CHAN_NO_HT40 |
- IEEE80211_CHAN_NO_80MHZ;
+ IEEE80211_CHAN_NO_80MHZ |
+ IEEE80211_CHAN_NO_160MHZ;
ch.bw = BRCMU_CHAN_BW_20;
cfg->d11inf.encchspec(&ch);
chaninfo = ch.chspec;
--
2.13.7
Sasha has somehow been convinced into helping me with the stable kernel
maintenance. Codify this slip in good judgement before he realizes what
he really signed up for :)
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Acked-by: Sasha Levin <sashal(a)kernel.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index 0abecc528dac..a46c1aa82398 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14078,6 +14078,7 @@ F: Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
STABLE BRANCH
M: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
+M: Sasha Levin <sashal(a)kernel.org>
L: stable(a)vger.kernel.org
S: Supported
F: Documentation/process/stable-kernel-rules.rst
The patch titled
Subject: mm: cleancache: fix corruption on missed inode invalidation
has been added to the -mm tree. Its filename is
mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-cleancache-fix-corruption-on-mi…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-cleancache-fix-corruption-on-mi…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Subject: mm: cleancache: fix corruption on missed inode invalidation
If all pages are deleted from the mapping by memory reclaim and also
moved to the cleancache:
__delete_from_page_cache
(no shadow case)
unaccount_page_cache_page
cleancache_put_page
page_cache_delete
mapping->nrpages -= nr
(nrpages becomes 0)
We don't clean the cleancache for an inode after final file truncation
(removal).
truncate_inode_pages_final
check (nrpages || nrexceptional) is false
no truncate_inode_pages
no cleancache_invalidate_inode(mapping)
These way when reading the new file created with same inode we may get
these trash leftover pages from cleancache and see wrong data instead of
the contents of the new file.
Fix it by always doing truncate_inode_pages which is already ready for
nrpages == 0 && nrexceptional == 0 case and just invalidates inode.
Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com
Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")
Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Reviewed-by: Vasily Averin <vvs(a)virtuozzo.com>
Reviewed-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Reviewed-by: Jan Kara <jack(a)suse.cz>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/truncate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/truncate.c~mm-cleancache-fix-corruption-on-missed-inode-invalidation
+++ a/mm/truncate.c
@@ -517,9 +517,9 @@ void truncate_inode_pages_final(struct a
*/
xa_lock_irq(&mapping->i_pages);
xa_unlock_irq(&mapping->i_pages);
-
- truncate_inode_pages(mapping, 0);
}
+
+ truncate_inode_pages(mapping, 0);
}
EXPORT_SYMBOL(truncate_inode_pages_final);
_
Patches currently in -mm which might be from ptikhomirov(a)virtuozzo.com are
mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
Hi Stable team,
Le 08/11/2018 10:31, Jerome Brunet a écrit :
> Similar to gxbb and gxl platforms, axg SCPI Cortex-M co-processor
> uses the fdiv2 and fdiv3 to, among other things, provide the cpu
> clock.
>
> Until clock hand-off mechanism makes its way to CCF and the generic
> SCPI claims platform specific clocks, these clocks must be marked as
> critical to make sure they are never disabled when needed by the
> co-processor.
>
> Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Could this fix go into the next 4.18 and 4.19 stable releases since it hit linus master with commit id d6ee1e7e9004d3d246cdfa14196989e0a9466c16 ?
Thanks,
Neil
> ---
>
> Hi Stephen,
>
> If you can put this one in clk-fixes as well, it would be awesome.
> It is basically the same thing as the change you took this Tuesday.
>
> Since then, we had reports the same problem with SCPI was happening
> on the axg, calling for the same fixup.
>
> Cheers
> Jerome
>
> drivers/clk/meson/axg.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> index c981159b02c0..792735d7e46e 100644
> --- a/drivers/clk/meson/axg.c
> +++ b/drivers/clk/meson/axg.c
> @@ -325,6 +325,7 @@ static struct clk_regmap axg_fclk_div2 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div2_div" },
> .num_parents = 1,
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
> @@ -349,6 +350,18 @@ static struct clk_regmap axg_fclk_div3 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div3_div" },
> .num_parents = 1,
> + /*
> + * FIXME:
> + * This clock, as fdiv2, is used by the SCPI FW and is required
> + * by the platform to operate correctly.
> + * Until the following condition are met, we need this clock to
> + * be marked as critical:
> + * a) The SCPI generic driver claims and enable all the clocks
> + * it needs
> + * b) CCF has a clock hand-off mechanism to make the sure the
> + * clock stays on until the proper driver comes along
> + */
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
>
From: Michal Hocko <mhocko(a)suse.com>
commit bb177a732c4369bb58a1fe1df8f552b6f0f7db5f upstream.
syzbot has noticed that a specially crafted library can easily hit
VM_BUG_ON in __mm_populate
kernel BUG at mm/gup.c:1242!
invalid opcode: 0000 [#1] SMP
CPU: 2 PID: 9667 Comm: a.out Not tainted 4.18.0-rc3 #644
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
RIP: 0010:__mm_populate+0x1e2/0x1f0
Code: 55 d0 65 48 33 14 25 28 00 00 00 89 d8 75 21 48 83 c4 20 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 75 18 f1 ff 0f 0b e8 6e 18 f1 ff <0f> 0b 31 db eb c9 e8 93 06 e0 ff 0f 1f 00 55 48 89 e5 53 48 89 fb
Call Trace:
vm_brk_flags+0xc3/0x100
vm_brk+0x1f/0x30
load_elf_library+0x281/0x2e0
__ia32_sys_uselib+0x170/0x1e0
do_fast_syscall_32+0xca/0x420
entry_SYSENTER_compat+0x70/0x7f
The reason is that the length of the new brk is not page aligned when we
try to populate the it. There is no reason to bug on that though.
do_brk_flags already aligns the length properly so the mapping is
expanded as it should. All we need is to tell mm_populate about it.
Besides that there is absolutely no reason to to bug_on in the first
place. The worst thing that could happen is that the last page wouldn't
get populated and that is far from putting system into an inconsistent
state.
Fix the issue by moving the length sanitization code from do_brk_flags
up to vm_brk_flags. The only other caller of do_brk_flags is brk
syscall entry and it makes sure to provide the proper length so t here
is no need for sanitation and so we can use do_brk_flags without it.
Also remove the bogus BUG_ONs.
[osalvador(a)techadventures.net: fix up vm_brk_flags s@request@len@]
Link: http://lkml.kernel.org/r/20180706090217.GI32658@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: syzbot <syzbot+5dcb560fe12aa5091c06(a)syzkaller.appspotmail.com>
Tested-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Reviewed-by: Oscar Salvador <osalvador(a)suse.de>
Cc: Zi Yan <zi.yan(a)cs.rutgers.edu>
Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.vnet.ibm.com>
Cc: Dan Williams <dan.j.williams(a)intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Cc: Michael S. Tsirkin <mst(a)redhat.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: "Huang, Ying" <ying.huang(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
[bwh: Backported to 4.9:
- There is no do_brk_flags() function; update do_brk()
- Adjust context]
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
mm/gup.c | 2 --
mm/mmap.c | 19 ++++++++++---------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index be4ccddac26f..d71da7216c6e 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1122,8 +1122,6 @@ int __mm_populate(unsigned long start, unsigned long len, int ignore_errors)
int locked = 0;
long ret = 0;
- VM_BUG_ON(start & ~PAGE_MASK);
- VM_BUG_ON(len != PAGE_ALIGN(len));
end = start + len;
for (nstart = start; nstart < end; nstart = nend) {
diff --git a/mm/mmap.c b/mm/mmap.c
index aa97074a4a99..283755645d17 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2876,21 +2876,15 @@ static inline void verify_mm_writelocked(struct mm_struct *mm)
* anonymous maps. eventually we may be able to do some
* brk-specific accounting here.
*/
-static int do_brk(unsigned long addr, unsigned long request)
+static int do_brk(unsigned long addr, unsigned long len)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma, *prev;
- unsigned long flags, len;
+ unsigned long flags;
struct rb_node **rb_link, *rb_parent;
pgoff_t pgoff = addr >> PAGE_SHIFT;
int error;
- len = PAGE_ALIGN(request);
- if (len < request)
- return -ENOMEM;
- if (!len)
- return 0;
-
flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
error = get_unmapped_area(NULL, addr, len, 0, MAP_FIXED);
@@ -2959,12 +2953,19 @@ static int do_brk(unsigned long addr, unsigned long request)
return 0;
}
-int vm_brk(unsigned long addr, unsigned long len)
+int vm_brk(unsigned long addr, unsigned long request)
{
struct mm_struct *mm = current->mm;
+ unsigned long len;
int ret;
bool populate;
+ len = PAGE_ALIGN(request);
+ if (len < request)
+ return -ENOMEM;
+ if (!len)
+ return 0;
+
if (down_write_killable(&mm->mmap_sem))
return -EINTR;
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
Hi Stable team,
Le 06/11/2018 00:08, Jerome Brunet a écrit :
> From: Christian Hewitt <christianshewitt(a)gmail.com>
>
> On the Khadas VIM2 (GXM) and LePotato (GXL) board there are problems
> with reboot; e.g. a ~60 second delay between issuing reboot and the
> board power cycling (and in some OS configurations reboot will fail
> and require manual power cycling).
>
> Similar to 'commit c987ac6f1f088663b6dad39281071aeb31d450a8 ("clk:
> meson-gxbb: set fclk_div2 as CLK_IS_CRITICAL")' the SCPI Cortex-M4
> Co-Processor seems to depend on FCLK_DIV3 being operational.
>
> Until commit 05f814402d6174369b3b29832cbb5eb5ed287059 ("clk:
> meson: add fdiv clock gates"), this clock was modeled and left on by
> the bootloader.
>
> We don't have precise documentation about the SCPI Co-Processor and
> its clock requirement so we are learning things the hard way.
>
> Marking this clock as critical solves the problem but it should not
> be viewed as final solution. Ideally, the SCPI driver should claim
> these clocks. We also depends on some clock hand-off mechanism
> making its way to CCF, to make sure the clock stays on between its
> registration and the SCPI driver probe.
>
> Fixes: 05f814402d61 ("clk: meson: add fdiv clock gates")
> Signed-off-by: Christian Hewitt <christianshewitt(a)gmail.com>
> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Could this patch go into the next 4.18 stable release since it hit linus master with commit id e2576c8bdfd462c34b8a46c0084e7c30b0851bf4 ?
Thanks,
Neil
> ---
> drivers/clk/meson/gxbb.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
> index 9309cfaaa464..4ada9668fd49 100644
> --- a/drivers/clk/meson/gxbb.c
> +++ b/drivers/clk/meson/gxbb.c
> @@ -506,6 +506,18 @@ static struct clk_regmap gxbb_fclk_div3 = {
> .ops = &clk_regmap_gate_ops,
> .parent_names = (const char *[]){ "fclk_div3_div" },
> .num_parents = 1,
> + /*
> + * FIXME:
> + * This clock, as fdiv2, is used by the SCPI FW and is required
> + * by the platform to operate correctly.
> + * Until the following condition are met, we need this clock to
> + * be marked as critical:
> + * a) The SCPI generic driver claims and enable all the clocks
> + * it needs
> + * b) CCF has a clock hand-off mechanism to make the sure the
> + * clock stays on until the proper driver comes along
> + */
> + .flags = CLK_IS_CRITICAL,
> },
> };
>
>
Please apply the attached fixes to the 4.4-stable branch.
Ben.
--
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
Manchester, M1 2HF, United Kingdom
UBIFS's recovery code strictly assumes that a deleted inode will never
come back, therefore it removes all data which belongs to that inode
as soon it faces an inode with link count 0 in the replay list.
Before O_TMPFILE this assumption was perfectly fine. With O_TMPFILE
it can lead to data loss upon a power-cut.
Consider a journal with entries like:
0: inode X (nlink = 0) /* O_TMPFILE was created */
1: data for inode X /* Someone writes to the temp file */
2: inode X (nlink = 0) /* inode was changed, xattr, chmod, … */
3: inode X (nlink = 1) /* inode was re-linked via linkat() */
Upon replay of entry #2 UBIFS will drop all data that belongs to inode X,
this will lead to an empty file after mounting.
As solution for this problem, scan the replay list for a re-link entry
before dropping data.
Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE")
Cc: stable(a)vger.kernel.org
Cc: Russell Senior <russell(a)personaltelco.net>
Cc: Rafał Miłecki <zajec5(a)gmail.com>
Reported-by: Russell Senior <russell(a)personaltelco.net>
Reported-by: Rafał Miłecki <zajec5(a)gmail.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
---
fs/ubifs/replay.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 75f961c4c044..cb1f23459553 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -212,6 +212,38 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r)
return ubifs_tnc_remove_range(c, &min_key, &max_key);
}
+/**
+ * inode_still_linked - check whether inode in question will be re-linked.
+ * @c: UBIFS file-system description object
+ * @rino: replay entry to test
+ *
+ * O_TMPFILE files can be re-linked, this means link count goes from 0 to 1.
+ * This case needs special care, otherwise all references to the inode will
+ * be removed upon the first replay entry of an inode with link count 0
+ * is found.
+ */
+static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
+{
+ struct replay_entry *r;
+
+ ubifs_assert(c, rino->deletion);
+ ubifs_assert(c, key_type(c, &rino->key) == UBIFS_INO_KEY);
+
+ /*
+ * Find the most recent entry for the inode behind @rino and check
+ * whether it is a deletion.
+ */
+ list_for_each_entry_reverse(r, &c->replay_list, list) {
+ ubifs_assert(c, r->sqnum >= rino->sqnum);
+ if (key_inum(c, &r->key) == key_inum(c, &rino->key))
+ return r->deletion == 0;
+
+ }
+
+ ubifs_assert(c, 0);
+ return false;
+}
+
/**
* apply_replay_entry - apply a replay entry to the TNC.
* @c: UBIFS file-system description object
@@ -239,6 +271,11 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r)
{
ino_t inum = key_inum(c, &r->key);
+ if (inode_still_linked(c, r)) {
+ err = 0;
+ break;
+ }
+
err = ubifs_tnc_remove_ino(c, inum);
break;
}
--
2.19.1
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss <robert.foss(a)collabora.com>
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: stable(a)vger.kernel.org
---
Changes since v2:
- Chris Wilson: Added r-b and stable kernel tag
Changes since v1:
- Chris Wilson: Make sure that dma_fence_put() is always executed
drivers/gpu/drm/msm/msm_gem_submit.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
index a90aedd6883a..d5e6665a4c8f 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_file_private *ctx = file->driver_priv;
struct msm_gem_submit *submit;
struct msm_gpu *gpu = priv->gpu;
- struct dma_fence *in_fence = NULL;
struct sync_file *sync_file = NULL;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
@@ -444,6 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
ring = gpu->rb[queue->prio];
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
+ struct dma_fence *in_fence;
+
in_fence = sync_file_get_fence(args->fence_fd);
if (!in_fence)
@@ -453,11 +454,13 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
* Wait if the fence is from a foreign context, or if the fence
* array contains any fence from a foreign context.
*/
- if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
+ ret = 0;
+ if (!dma_fence_match_context(in_fence, ring->fctx->context))
ret = dma_fence_wait(in_fence, true);
- if (ret)
- return ret;
- }
+
+ dma_fence_put(in_fence);
+ if (ret)
+ return ret;
}
ret = mutex_lock_interruptible(&dev->struct_mutex);
@@ -583,8 +586,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
}
out:
- if (in_fence)
- dma_fence_put(in_fence);
submit_cleanup(submit);
if (ret)
msm_gem_submit_free(submit);
--
2.17.1
drm_atomic_helper_setup_commit() auto-completes commit->flip_done when
state->legacy_cursor_update is true, but we know for sure that we want
a sync update when we call drm_atomic_helper_setup_commit() from
vc4_atomic_commit().
Explicitly set state->legacy_cursor_update to false to prevent this
auto-completion.
Fixes: 184d3cf4f738 ("drm/vc4: Use wait_for_flip_done() instead of wait_for_vblanks()")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
---
Changes in v3:
- Add missing Fixes and Cc-stable tags
- Fix a typo in the commit message
Changes in v2:
- Add Eric's R-b
---
drivers/gpu/drm/vc4/vc4_kms.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 127468785f74..1f94b9affe4b 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -214,6 +214,12 @@ static int vc4_atomic_commit(struct drm_device *dev,
return 0;
}
+ /* We know for sure we don't want an async update here. Set
+ * state->legacy_cursor_update to false to prevent
+ * drm_atomic_helper_setup_commit() from auto-completing
+ * commit->flip_done.
+ */
+ state->legacy_cursor_update = false;
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
--
2.17.1
USB3 roothub might autosuspend before a plugged USB3 device is detected,
causing USB3 device enumeration failure.
USB3 devices don't show up as connected and enabled until USB3 link trainig
completes. On a fast booting platform with a slow USB3 link training the
link might reach the connected enabled state just as the bus is suspending.
If this device is discovered first time by the xhci_bus_suspend() routine
it will be put to U3 suspended state like the other ports which failed to
suspend earlier.
The hub thread will notice the connect change and resume the bus,
moving the port back to U0
This U0 -> U3 -> U0 transition right after being connected seems to be
too much for some devices, causing them to first go to SS.Inactive state,
and finally end up stuck in a polling state with reset asserted
Fix this by failing the bus suspend if a port has a connect change or is
in a polling state in xhci_bus_suspend().
Don't do any port changes until all ports are checked, buffer all port
changes and only write them in the end if suspend can proceed
Cc: stable(a)vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci-hub.c | 60 ++++++++++++++++++++++++++++++++++-----------
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index da98a11..94aca1b 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1474,15 +1474,18 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
unsigned long flags;
struct xhci_hub *rhub;
struct xhci_port **ports;
+ u32 portsc_buf[USB_MAXCHILDREN];
+ bool wake_enabled;
rhub = xhci_get_rhub(hcd);
ports = rhub->ports;
max_ports = rhub->num_ports;
bus_state = &xhci->bus_state[hcd_index(hcd)];
+ wake_enabled = hcd->self.root_hub->do_remote_wakeup;
spin_lock_irqsave(&xhci->lock, flags);
- if (hcd->self.root_hub->do_remote_wakeup) {
+ if (wake_enabled) {
if (bus_state->resuming_ports || /* USB2 */
bus_state->port_remote_wakeup) { /* USB3 */
spin_unlock_irqrestore(&xhci->lock, flags);
@@ -1490,26 +1493,36 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
return -EBUSY;
}
}
-
- port_index = max_ports;
+ /*
+ * Prepare ports for suspend, but don't write anything before all ports
+ * are checked and we know bus suspend can proceed
+ */
bus_state->bus_suspended = 0;
+ port_index = max_ports;
while (port_index--) {
- /* suspend the port if the port is not suspended */
u32 t1, t2;
- int slot_id;
t1 = readl(ports[port_index]->addr);
t2 = xhci_port_state_to_neutral(t1);
+ portsc_buf[port_index] = 0;
- if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
- xhci_dbg(xhci, "port %d not suspended\n", port_index);
- slot_id = xhci_find_slot_id_by_port(hcd, xhci,
- port_index + 1);
- if (slot_id) {
+ /* Bail out if a USB3 port has a new device in link training */
+ if ((t1 & PORT_PLS_MASK) == XDEV_POLLING) {
+ bus_state->bus_suspended = 0;
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ xhci_dbg(xhci, "Bus suspend bailout, port in polling\n");
+ return -EBUSY;
+ }
+
+ /* suspend ports in U0, or bail out for new connect changes */
+ if ((t1 & PORT_PE) && (t1 & PORT_PLS_MASK) == XDEV_U0) {
+ if ((t1 & PORT_CSC) && wake_enabled) {
+ bus_state->bus_suspended = 0;
spin_unlock_irqrestore(&xhci->lock, flags);
- xhci_stop_device(xhci, slot_id, 1);
- spin_lock_irqsave(&xhci->lock, flags);
+ xhci_dbg(xhci, "Bus suspend bailout, port connect change\n");
+ return -EBUSY;
}
+ xhci_dbg(xhci, "port %d not suspended\n", port_index);
t2 &= ~PORT_PLS_MASK;
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, &bus_state->bus_suspended);
@@ -1518,7 +1531,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM
* is enabled, so also enable remote wake here.
*/
- if (hcd->self.root_hub->do_remote_wakeup) {
+ if (wake_enabled) {
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;
@@ -1538,7 +1551,26 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
t1 = xhci_port_state_to_neutral(t1);
if (t1 != t2)
- writel(t2, ports[port_index]->addr);
+ portsc_buf[port_index] = t2;
+ }
+
+ /* write port settings, stopping and suspending ports if needed */
+ port_index = max_ports;
+ while (port_index--) {
+ if (!portsc_buf[port_index])
+ continue;
+ if (test_bit(port_index, &bus_state->bus_suspended)) {
+ int slot_id;
+
+ slot_id = xhci_find_slot_id_by_port(hcd, xhci,
+ port_index + 1);
+ if (slot_id) {
+ spin_unlock_irqrestore(&xhci->lock, flags);
+ xhci_stop_device(xhci, slot_id, 1);
+ spin_lock_irqsave(&xhci->lock, flags);
+ }
+ }
+ writel(portsc_buf[port_index], ports[port_index]->addr);
}
hcd->state = HC_STATE_SUSPENDED;
bus_state->next_statechange = jiffies + msecs_to_jiffies(10);
--
2.7.4
KEXEC needs the new kernel's load address to be aligned on a page
boundary (see sanity_check_segment_list()), but on MIPS the default
vmlinuz load address is only explicitly aligned to 16 bytes.
Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
the alignment calculated by calc_vmlinuz_load_addr to 64KB.
Cc: <stable(a)vger.kernel.org> # 2.6.36+
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
---
arch/mips/boot/compressed/calc_vmlinuz_load_addr.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c b/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
index 37fe58c..542c3ed 100644
--- a/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
+++ b/arch/mips/boot/compressed/calc_vmlinuz_load_addr.c
@@ -13,6 +13,7 @@
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
+#include "../../../../include/linux/sizes.h"
int main(int argc, char *argv[])
{
@@ -45,11 +46,11 @@ int main(int argc, char *argv[])
vmlinuz_load_addr = vmlinux_load_addr + vmlinux_size;
/*
- * Align with 16 bytes: "greater than that used for any standard data
- * types by a MIPS compiler." -- See MIPS Run Linux (Second Edition).
+ * Align with 64KB: KEXEC needs load sections to be aligned to PAGE_SIZE,
+ * which may be as large as 64KB depending on the kernel configuration.
*/
- vmlinuz_load_addr += (16 - vmlinux_size % 16);
+ vmlinuz_load_addr += (SZ_64K - vmlinux_size % SZ_64K);
printf("0x%llx\n", vmlinuz_load_addr);
--
2.7.0
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6cd078702f2f33cb6b19a682de3e9184112f1a46 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Thu, 18 Oct 2018 09:45:49 +0300
Subject: [PATCH] ovl: fix recursive oi->lock in ovl_link()
linking a non-copied-up file into a non-copied-up parent results in a
nested call to mutex_lock_interruptible(&oi->lock). Fix this by copying up
target parent before ovl_nlink_start(), same as done in ovl_rename().
~/unionmount-testsuite$ ./run --ov -s
~/unionmount-testsuite$ ln /mnt/a/foo100 /mnt/a/dir100/
WARNING: possible recursive locking detected
--------------------------------------------
ln/1545 is trying to acquire lock:
00000000bcce7c4c (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_copy_up_start+0x28/0x7d
but task is already holding lock:
0000000026d73d5b (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0x3c/0xc1
[SzM: this seems to be a false positive, but doing the copy-up first is
harmless and removes the lockdep splat]
Reported-by: syzbot+3ef5c0d1a5cb0b21e6be(a)syzkaller.appspotmail.com
Fixes: 5f8415d6b87e ("ovl: persistent overlay inode nlink for...")
Cc: <stable(a)vger.kernel.org> # v4.13
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 276914ae3c60..e1a55ecb7aba 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -663,6 +663,10 @@ static int ovl_link(struct dentry *old, struct inode *newdir,
if (err)
goto out_drop_write;
+ err = ovl_copy_up(new->d_parent);
+ if (err)
+ goto out_drop_write;
+
if (ovl_is_metacopy_dentry(old)) {
err = ovl_set_redirect(old, false);
if (err)
We need to actually make sure we check this on resume since otherwise we
won't know whether or not the topology is still there once we've
resumed, which will cause us to still think the topology is connected
even after it's been removed if the removal happens mid-suspend.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6cbbae3f438b..6aa3521b6326 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1255,8 +1255,16 @@ nv50_mstm_fini(struct nv50_mstm *mstm)
static void
nv50_mstm_init(struct nv50_mstm *mstm)
{
- if (mstm && mstm->mgr.mst_state)
- drm_dp_mst_topology_mgr_resume(&mstm->mgr);
+ int ret;
+
+ if (!mstm || !mstm->mgr.mst_state)
+ return;
+
+ ret = drm_dp_mst_topology_mgr_resume(&mstm->mgr);
+ if (ret == -1) {
+ drm_dp_mst_topology_mgr_set_mst(&mstm->mgr, false);
+ drm_kms_helper_hotplug_event(mstm->mgr.dev);
+ }
}
static void
--
2.19.1
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 908a572b80f6e9577b45e81b3dfe2e22111286b8 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Fri, 28 Sep 2018 16:43:22 +0200
Subject: [PATCH] fuse: fix blocked_waitq wakeup
Using waitqueue_active() is racy. Make sure we issue a wake_up()
unconditionally after storing into fc->blocked. After that it's okay to
optimize with waitqueue_active() since the first wake up provides the
necessary barrier for all waiters, not the just the woken one.
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 3c18ef8117f0 ("fuse: optimize wake_up")
Cc: <stable(a)vger.kernel.org> # v3.10
diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
index 34976b42f3e1..51eb602a435b 100644
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -391,12 +391,19 @@ static void request_end(struct fuse_conn *fc, struct fuse_req *req)
if (test_bit(FR_BACKGROUND, &req->flags)) {
spin_lock(&fc->lock);
clear_bit(FR_BACKGROUND, &req->flags);
- if (fc->num_background == fc->max_background)
+ if (fc->num_background == fc->max_background) {
fc->blocked = 0;
-
- /* Wake up next waiter, if any */
- if (!fc->blocked && waitqueue_active(&fc->blocked_waitq))
wake_up(&fc->blocked_waitq);
+ } else if (!fc->blocked) {
+ /*
+ * Wake up next waiter, if any. It's okay to use
+ * waitqueue_active(), as we've already synced up
+ * fc->blocked with waiters with the wake_up() call
+ * above.
+ */
+ if (waitqueue_active(&fc->blocked_waitq))
+ wake_up(&fc->blocked_waitq);
+ }
if (fc->num_background == fc->congestion_threshold && fc->sb) {
clear_bdi_congested(fc->sb->s_bdi, BLK_RW_SYNC);
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From db186382af21e926e90df19499475f2552192b77 Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Wed, 26 Sep 2018 22:05:12 -0700
Subject: [PATCH] scsi: qla2xxx: Fix NVMe Target discovery
This patch fixes issue when remoteport registers itself as both FCP and
FC-NVMe with the switch, driver will pick FC-NVMe personality as default when
scanning for targets.
Driver was using comaprative operator instead of bitwise operator to check for
fc4_type for both FCP and FC-NVME.
Fixes: 2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Reviewed-by: Ewan D. Milne <emilne(a)redhat.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 429033ab6897..dba672f87cb2 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4880,10 +4880,10 @@ void qla24xx_create_new_sess(struct scsi_qla_host *vha, struct qla_work_evt *e)
fcport->d_id = e->u.new_sess.id;
fcport->flags |= FCF_FABRIC_DEVICE;
fcport->fw_login_state = DSC_LS_PLOGI_PEND;
- if (e->u.new_sess.fc4_type == FS_FC4TYPE_FCP)
+ if (e->u.new_sess.fc4_type & FS_FC4TYPE_FCP)
fcport->fc4_type = FC4_TYPE_FCP_SCSI;
- if (e->u.new_sess.fc4_type == FS_FC4TYPE_NVME) {
+ if (e->u.new_sess.fc4_type & FS_FC4TYPE_NVME) {
fcport->fc4_type = FC4_TYPE_OTHER;
fcport->fc4f_nvme = FC4_TYPE_NVME;
}
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 56d942de59ebfa2e970a6cd33299d1984710b6c0 Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Tue, 11 Sep 2018 10:18:22 -0700
Subject: [PATCH] scsi: qla2xxx: Reject bsg request if chip is down.
Reject bsg request if chip is down. This prevent erroneous timeout.
Fixes: d051a5aa1c23 ("[SCSI] qla2xxx: Add an "is reset active" helper.")
Cc: stable(a)vger.kernel.org # 4.10
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index c11a89be292c..4a9fd8d944d6 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -2487,7 +2487,7 @@ qla24xx_bsg_request(struct bsg_job *bsg_job)
vha = shost_priv(host);
}
- if (qla2x00_reset_active(vha)) {
+ if (qla2x00_chip_is_down(vha)) {
ql_dbg(ql_dbg_user, vha, 0x709f,
"BSG: ISP abort active/needed -- cmd=%d.\n",
bsg_request->msgcode);
The patch below does not apply to the 4.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 56d942de59ebfa2e970a6cd33299d1984710b6c0 Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Tue, 11 Sep 2018 10:18:22 -0700
Subject: [PATCH] scsi: qla2xxx: Reject bsg request if chip is down.
Reject bsg request if chip is down. This prevent erroneous timeout.
Fixes: d051a5aa1c23 ("[SCSI] qla2xxx: Add an "is reset active" helper.")
Cc: stable(a)vger.kernel.org # 4.10
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index c11a89be292c..4a9fd8d944d6 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -2487,7 +2487,7 @@ qla24xx_bsg_request(struct bsg_job *bsg_job)
vha = shost_priv(host);
}
- if (qla2x00_reset_active(vha)) {
+ if (qla2x00_chip_is_down(vha)) {
ql_dbg(ql_dbg_user, vha, 0x709f,
"BSG: ISP abort active/needed -- cmd=%d.\n",
bsg_request->msgcode);
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From f7d61c995df74d6bb57bbff6a2b7b1874c4a2baa Mon Sep 17 00:00:00 2001
From: Quinn Tran <quinn.tran(a)cavium.com>
Date: Wed, 26 Sep 2018 22:05:11 -0700
Subject: [PATCH] scsi: qla2xxx: Fix NVMe session hang on unload
Send aborts only when chip is active.
Fixes: 623ee824e579 ("scsi: qla2xxx: Fix FC-NVMe IO abort during driver reset")
Cc: <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com>
Reviewed-by: Ewan D. Milne <emilne(a)redhat.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
diff --git a/drivers/scsi/qla2xxx/qla_nvme.c b/drivers/scsi/qla2xxx/qla_nvme.c
index 42dc846cc8dd..ad923965be3c 100644
--- a/drivers/scsi/qla2xxx/qla_nvme.c
+++ b/drivers/scsi/qla2xxx/qla_nvme.c
@@ -607,7 +607,7 @@ void qla_nvme_abort(struct qla_hw_data *ha, struct srb *sp, int res)
{
int rval;
- if (!test_bit(ABORT_ISP_ACTIVE, &sp->vha->dpc_flags)) {
+ if (ha->flags.fw_started) {
rval = ha->isp_ops->abort_command(sp);
if (!rval && !qla_nvme_wait_on_command(sp))
ql_log(ql_log_warn, NULL, 0x2112,
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 641a41dbba217ee5bd26abe6be77f8cead9cd00e Mon Sep 17 00:00:00 2001
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Date: Tue, 30 Oct 2018 15:13:35 +0900
Subject: [PATCH] serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeout
This patch fixes an issue that the sci_remove() could not remove
dev_attr_rx_fifo_timeout because uart_remove_one_port() set
the port->port.type to PORT_UNKNOWN.
Reported-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym(a)renesas.com>
Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
Reviewed-by: Ulrich Hecht <uli+renesas(a)fpond.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e19bfbba8a01..effba6ce0caa 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3102,6 +3102,7 @@ static struct uart_driver sci_uart_driver = {
static int sci_remove(struct platform_device *dev)
{
struct sci_port *port = platform_get_drvdata(dev);
+ unsigned int type = port->port.type; /* uart_remove_... clears it */
sci_ports_in_use &= ~BIT(port->port.line);
uart_remove_one_port(&sci_uart_driver, &port->port);
@@ -3112,8 +3113,7 @@ static int sci_remove(struct platform_device *dev)
sysfs_remove_file(&dev->dev.kobj,
&dev_attr_rx_fifo_trigger.attr);
}
- if (port->port.type == PORT_SCIFA || port->port.type == PORT_SCIFB ||
- port->port.type == PORT_HSCIF) {
+ if (type == PORT_SCIFA || type == PORT_SCIFB || type == PORT_HSCIF) {
sysfs_remove_file(&dev->dev.kobj,
&dev_attr_rx_fifo_timeout.attr);
}
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 5e1275808630ea3b2c97c776f40e475017535f72 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Wed, 31 Oct 2018 12:15:23 +0100
Subject: [PATCH] ovl: check whiteout in ovl_create_over_whiteout()
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia <xiakaixu1987(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: <stable(a)vger.kernel.org> # v3.18
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index ce1857fb5434..c6289147c787 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -462,6 +462,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry, struct inode *inode,
if (IS_ERR(upper))
goto out_unlock;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput;
+
newdentry = ovl_create_temp(workdir, cattr);
err = PTR_ERR(newdentry);
if (IS_ERR(newdentry))
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6cd078702f2f33cb6b19a682de3e9184112f1a46 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Thu, 18 Oct 2018 09:45:49 +0300
Subject: [PATCH] ovl: fix recursive oi->lock in ovl_link()
linking a non-copied-up file into a non-copied-up parent results in a
nested call to mutex_lock_interruptible(&oi->lock). Fix this by copying up
target parent before ovl_nlink_start(), same as done in ovl_rename().
~/unionmount-testsuite$ ./run --ov -s
~/unionmount-testsuite$ ln /mnt/a/foo100 /mnt/a/dir100/
WARNING: possible recursive locking detected
--------------------------------------------
ln/1545 is trying to acquire lock:
00000000bcce7c4c (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_copy_up_start+0x28/0x7d
but task is already holding lock:
0000000026d73d5b (&ovl_i_lock_key[depth]){+.+.}, at:
ovl_nlink_start+0x3c/0xc1
[SzM: this seems to be a false positive, but doing the copy-up first is
harmless and removes the lockdep splat]
Reported-by: syzbot+3ef5c0d1a5cb0b21e6be(a)syzkaller.appspotmail.com
Fixes: 5f8415d6b87e ("ovl: persistent overlay inode nlink for...")
Cc: <stable(a)vger.kernel.org> # v4.13
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 276914ae3c60..e1a55ecb7aba 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -663,6 +663,10 @@ static int ovl_link(struct dentry *old, struct inode *newdir,
if (err)
goto out_drop_write;
+ err = ovl_copy_up(new->d_parent);
+ if (err)
+ goto out_drop_write;
+
if (ovl_is_metacopy_dentry(old)) {
err = ovl_set_redirect(old, false);
if (err)
Currently, when checking to see if accessing n bytes starting at
address "ptr" will cause a wraparound in the memory addresses,
the check in check_bogus_address() adds an extra byte, which is
incorrect, as the range of addresses that will be accessed is
[ptr, ptr + (n - 1)].
This can lead to incorrectly detecting a wraparound in the
memory address, when trying to read 4 KB from memory that is
mapped to the the last possible page in the virtual address
space, when in fact, accessing that range of memory would not
cause a wraparound to occur.
Use the memory range that will actually be accessed when
considering if accessing a certain amount of bytes will cause
the memory address to wrap around.
Change-Id: I2563a5988e41122727ede17180f365e999b953e6
Fixes: f5509cc18daa ("mm: Hardened usercopy")
Co-Developed-by: Prasad Sodagudi <psodagud(a)codeaurora.org>
Signed-off-by: Prasad Sodagudi <psodagud(a)codeaurora.org>
Signed-off-by: Isaac J. Manjarres <isaacm(a)codeaurora.org>
Cc: stable(a)vger.kernel.org
---
mm/usercopy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/usercopy.c b/mm/usercopy.c
index 852eb4e..0293645 100644
--- a/mm/usercopy.c
+++ b/mm/usercopy.c
@@ -151,7 +151,7 @@ static inline void check_bogus_address(const unsigned long ptr, unsigned long n,
bool to_user)
{
/* Reject if object wraps past end of memory. */
- if (ptr + n < ptr)
+ if (ptr + (n - 1) < ptr)
usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);
/* Reject if NULL or ZERO-allocation. */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
stable-rc/linux-3.18.y build: 183 builds: 0 failed, 183 passed, 291 warnings (v3.18.125-63-g90468834bfa7)
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.125-6…
Tree: stable-rc
Branch: linux-3.18.y
Git Describe: v3.18.125-63-g90468834bfa7
Git Commit: 90468834bfa76d1ba14ad2fd13e65fef3f3f3c77
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Built: 4 unique architectures
Warnings Detected:
arm64: gcc version 7.3.0 (Debian 7.3.0-28)
allnoconfig: 2 warnings
defconfig: 2 warnings
tinyconfig: 2 warnings
arm: gcc version 7.3.0 (Debian 7.3.0-28)
acs5k_defconfig: 2 warnings
acs5k_tiny_defconfig: 2 warnings
allnoconfig: 2 warnings
am200epdkit_defconfig: 2 warnings
ape6evm_defconfig: 2 warnings
armadillo800eva_defconfig: 2 warnings
assabet_defconfig: 2 warnings
at91_dt_defconfig: 2 warnings
at91rm9200_defconfig: 2 warnings
at91sam9260_9g20_defconfig: 2 warnings
at91sam9261_9g10_defconfig: 2 warnings
at91sam9263_defconfig: 2 warnings
at91sam9g45_defconfig: 2 warnings
at91sam9rl_defconfig: 2 warnings
at91x40_defconfig: 2 warnings
axm55xx_defconfig: 2 warnings
badge4_defconfig: 2 warnings
bcm2835_defconfig: 2 warnings
bcm_defconfig: 2 warnings
bockw_defconfig: 2 warnings
cerfcube_defconfig: 2 warnings
clps711x_defconfig: 2 warnings
cm_x2xx_defconfig: 2 warnings
cm_x300_defconfig: 2 warnings
cns3420vb_defconfig: 2 warnings
colibri_pxa270_defconfig: 2 warnings
colibri_pxa300_defconfig: 2 warnings
collie_defconfig: 2 warnings
corgi_defconfig: 2 warnings
davinci_all_defconfig: 2 warnings
dove_defconfig: 2 warnings
ebsa110_defconfig: 2 warnings
efm32_defconfig: 2 warnings
em_x270_defconfig: 2 warnings
ep93xx_defconfig: 2 warnings
eseries_pxa_defconfig: 2 warnings
exynos_defconfig: 2 warnings
ezx_defconfig: 2 warnings
footbridge_defconfig: 2 warnings
h3600_defconfig: 2 warnings
h5000_defconfig: 2 warnings
hackkit_defconfig: 2 warnings
hisi_defconfig: 2 warnings
imote2_defconfig: 2 warnings
imx_v4_v5_defconfig: 2 warnings
imx_v6_v7_defconfig: 2 warnings
integrator_defconfig: 2 warnings
iop13xx_defconfig: 2 warnings
iop32x_defconfig: 2 warnings
iop33x_defconfig: 2 warnings
ixp4xx_defconfig: 2 warnings
jornada720_defconfig: 2 warnings
keystone_defconfig: 2 warnings
koelsch_defconfig: 2 warnings
ks8695_defconfig: 2 warnings
kzm9g_defconfig: 2 warnings
lager_defconfig: 2 warnings
lart_defconfig: 2 warnings
lpc32xx_defconfig: 2 warnings
lpd270_defconfig: 2 warnings
lubbock_defconfig: 2 warnings
mackerel_defconfig: 2 warnings
magician_defconfig: 2 warnings
mainstone_defconfig: 2 warnings
marzen_defconfig: 2 warnings
mini2440_defconfig: 2 warnings
mmp2_defconfig: 2 warnings
moxart_defconfig: 2 warnings
msm_defconfig: 2 warnings
multi_v5_defconfig: 2 warnings
multi_v7_defconfig: 2 warnings
mv78xx0_defconfig: 2 warnings
mvebu_v5_defconfig: 2 warnings
mvebu_v7_defconfig: 2 warnings
mxs_defconfig: 2 warnings
neponset_defconfig: 2 warnings
netwinder_defconfig: 2 warnings
netx_defconfig: 2 warnings
nhk8815_defconfig: 2 warnings
nuc910_defconfig: 2 warnings
nuc950_defconfig: 2 warnings
nuc960_defconfig: 2 warnings
omap1_defconfig: 2 warnings
omap2plus_defconfig: 2 warnings
orion5x_defconfig: 2 warnings
palmz72_defconfig: 2 warnings
pcm027_defconfig: 2 warnings
pleb_defconfig: 2 warnings
prima2_defconfig: 2 warnings
pxa168_defconfig: 2 warnings
pxa255-idp_defconfig: 2 warnings
pxa3xx_defconfig: 2 warnings
pxa910_defconfig: 2 warnings
qcom_defconfig: 2 warnings
raumfeld_defconfig: 2 warnings
realview-smp_defconfig: 2 warnings
realview_defconfig: 2 warnings
rpc_defconfig: 2 warnings
s3c2410_defconfig: 2 warnings
s3c6400_defconfig: 2 warnings
s5pv210_defconfig: 2 warnings
sama5_defconfig: 2 warnings
shannon_defconfig: 2 warnings
shmobile_defconfig: 2 warnings
simpad_defconfig: 2 warnings
socfpga_defconfig: 2 warnings
spear13xx_defconfig: 2 warnings
spear3xx_defconfig: 2 warnings
spear6xx_defconfig: 2 warnings
spitz_defconfig: 2 warnings
sunxi_defconfig: 2 warnings
tct_hammer_defconfig: 2 warnings
tegra_defconfig: 2 warnings
tinyconfig: 2 warnings
trizeps4_defconfig: 2 warnings
u300_defconfig: 2 warnings
u8500_defconfig: 2 warnings
versatile_defconfig: 2 warnings
vexpress_defconfig: 2 warnings
viper_defconfig: 2 warnings
vt8500_v6_v7_defconfig: 2 warnings
xcep_defconfig: 2 warnings
zeus_defconfig: 2 warnings
x86: gcc version 7.3.0 (Debian 7.3.0-29)
allnoconfig: 3 warnings
i386_defconfig: 3 warnings
tinyconfig: 3 warnings
x86_64_defconfig: 30 warnings
Warnings summary:
126 scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
126 scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
3 arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
3 arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
2 include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
1 net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
1 lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
1 kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
1 drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
1 drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
1 drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
1 drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
1 block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
1 block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
1 block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
allnoconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ape6evm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
armadillo800eva_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
assabet_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91_dt_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91rm9200_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9260_9g20_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9261_9g10_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9263_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9g45_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91sam9rl_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
at91x40_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ath79_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
badge4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm2835_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
bigsur_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bockw_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
capcella_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
clps711x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cm_x300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cns3420vb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
cobalt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
collie_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
corgi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
davinci_all_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
db1xxx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
dove_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
e55_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
efm32_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
em_x270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ep93xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
exynos_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ezx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
footbridge_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
h5000_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hackkit_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
hisi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
i386_defconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
imote2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
integrator_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop32x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
iop33x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ip22_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
jazz_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
keystone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
koelsch_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ks8695_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
kzm9g_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lager_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lasat_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
lpd270_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
ls1b_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mackerel_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
magician_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mainstone_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
malta_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
marzen_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mini2440_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
moxart_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mpc30x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msm_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
msp71xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mv78xx0_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
mxs_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
neponset_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netwinder_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
netx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nhk8815_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc950_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
nuc960_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap1_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
omap2plus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
orion5x_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
palmz72_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pcm027_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pleb_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa168_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
pxa910_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qcom_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
raumfeld_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rb532_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview-smp_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
realview_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rm200_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
rt305x_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c2410_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s3c6400_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
s5pv210_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sama5_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sead3micro_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
shmobile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
simpad_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
socfpga_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear13xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear3xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spear6xx_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
spitz_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
sunxi_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tb0219_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tegra_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (arm64) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (x86) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/head_32.S:672: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:677: Warning: ignoring fill value in section `.bss..page_aligned'
arch/x86/kernel/head_32.S:679: Warning: ignoring fill value in section `.bss..page_aligned'
--------------------------------------------------------------------------------
tinyconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
tinyconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u300_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
u8500_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
versatile_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vexpress_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
viper_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
workpad_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86) — PASS, 0 errors, 30 warnings, 0 section mismatches
Warnings:
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
block/elevator.c:841:14: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
kernel/relay.c:423:35: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
block/partition-generic.c:39:36: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=]
block/partition-generic.c:41:37: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
fs/nfs/client.c:1380:23: warning: '%u' directive output may be truncated writing between 1 and 7 bytes into a region of size between 3 and 6 [-Wformat-truncation=]
drivers/ata/libata-core.c:2962:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2963:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2964:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2965:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2966:31: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2967:32: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2968:35: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2969:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2970:30: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
drivers/ata/libata-core.c:2141:42: warning: '%d' directive output may be truncated writing between 1 and 2 bytes into a region of size between 1 and 11 [-Wformat-truncation=]
lib/string_helpers.c:64:33: warning: '%03lld' directive output may be truncated writing between 3 and 13 bytes into a region of size 7 [-Wformat-truncation=]
drivers/input/keyboard/atkbd.c:1069:7: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/psmouse-base.c:1466:52: warning: '/input0' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/alps.c:2418:46: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/input/mouse/lifebook.c:287:7: warning: '/input1' directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11175:9: warning: '-txrx-' directive output may be truncated writing 6 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11178:9: warning: '-tx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11181:9: warning: '-rx-' directive output may be truncated writing 4 bytes into a region of size between 1 and 16 [-Wformat-truncation=]
drivers/net/ethernet/broadcom/tg3.c:11184:10: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
net/sunrpc/clnt.c:527:46: warning: '%s' directive output may be truncated writing up to 107 bytes into a region of size 48 [-Wformat-truncation=]
drivers/usb/core/usb.c:471:9: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 15 [-Wformat-truncation=]
drivers/usb/core/hcd.c:450:34: warning: '%s' directive output may be truncated writing up to 64 bytes into a region of size between 35 and 99 [-Wformat-truncation=]
drivers/video/fbdev/core/../edid.h:74:72: warning: '*' in boolean context, suggest '&&' instead [-Wint-in-bool-context]
--------------------------------------------------------------------------------
xcep_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
--------------------------------------------------------------------------------
xway_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
scripts/kconfig/confdata.c:767:19: warning: '%s' directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
scripts/kconfig/confdata.c:770:20: warning: '.tmpconfig.' directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
---
For more info write to <info(a)kernelci.org>
This is a note to let you know that I've just added the patch titled
usb: core: Fix hub port connection events lost
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 22454b79e6de05fa61a2a72d00d2eed798abbb75 Mon Sep 17 00:00:00 2001
From: Dennis Wassenberg <dennis.wassenberg(a)secunet.com>
Date: Tue, 13 Nov 2018 14:40:34 +0100
Subject: usb: core: Fix hub port connection events lost
This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset
only if a device is was attached to the hub port before resetting the hub port.
Using a Lenovo T480s attached to the ultra dock it was not possible to detect
some usb-c devices at the dock usb-c ports because the hub_port_reset code
will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset.
Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the
actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit.
This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the
new device was attached such that it was not detected.
This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is
currently no device attached to the port before the hub port reset.
This will avoid clearing the connection bit for new attached devices.
Signed-off-by: Dennis Wassenberg <dennis.wassenberg(a)secunet.com>
Acked-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d9bd7576786a..0f9381b69a3b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2850,7 +2850,9 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
- usb_clear_port_feature(hub->hdev, port1,
+
+ if (udev)
+ usb_clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
/*
--
2.19.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 2fc6d4be35fb1e262f209758e25bfe2b7a113a7f Mon Sep 17 00:00:00 2001
From: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Date: Wed, 1 Aug 2018 09:37:34 +0300
Subject: usb: dwc3: gadget: fix ISOC TRB type on unaligned transfers
When chaining ISOC TRBs together, only the first ISOC TRB should be of
type ISOC_FIRST, all others should be of type ISOC. This patch fixes
that.
Fixes: c6267a51639b ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Cc: <stable(a)vger.kernel.org> # v4.11+
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/gadget.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 06e22afdf3d1..9faad896b3a1 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1081,7 +1081,7 @@ static void dwc3_prepare_one_trb_sg(struct dwc3_ep *dep,
/* Now prepare one extra TRB to align transfer size */
trb = &dep->trb_pool[dep->trb_enqueue];
__dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr,
- maxp - rem, false, 0,
+ maxp - rem, false, 1,
req->request.stream_id,
req->request.short_not_ok,
req->request.no_interrupt);
@@ -1125,7 +1125,7 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
/* Now prepare one extra TRB to align transfer size */
trb = &dep->trb_pool[dep->trb_enqueue];
__dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr, maxp - rem,
- false, 0, req->request.stream_id,
+ false, 1, req->request.stream_id,
req->request.short_not_ok,
req->request.no_interrupt);
} else if (req->request.zero && req->request.length &&
@@ -1141,7 +1141,7 @@ static void dwc3_prepare_one_trb_linear(struct dwc3_ep *dep,
/* Now prepare one extra TRB to handle ZLP */
trb = &dep->trb_pool[dep->trb_enqueue];
__dwc3_prepare_one_trb(dep, trb, dwc->bounce_addr, 0,
- false, 0, req->request.stream_id,
+ false, 1, req->request.stream_id,
req->request.short_not_ok,
req->request.no_interrupt);
} else {
--
2.19.1