This is the start of the stable review cycle for the 3.18.7 release.
There are 39 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 Feb 11 08:33:11 UTC 2015.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.18.7-rc1
Steven Rostedt (Red Hat) <[email protected]>
x86/tlb/trace: Do not trace on CPU that is offline
Steven Rostedt (Red Hat) <[email protected]>
tracing: Add condition check to RCU lockdep checks
John Stultz <[email protected]>
hrtimer: Fix incorrect tai offset calculation for non high-res timer systems
Lai Jiangshan <[email protected]>
smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()
Boris Ostrovsky <[email protected]>
x86, microcode: Return error from driver init code when loader is disabled
Sylwester Nawrocki <[email protected]>
ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs
Takashi Iwai <[email protected]>
ALSA: ak411x: Fix stall in work callback
Eric Nelson <[email protected]>
ASoC: sgtl5000: add delay before first I2C access
Bo Shen <[email protected]>
ASoC: atmel_ssc_dai: fix start event for I2S mode
karl beldan <[email protected]>
lib/checksum.c: fix build for generic csum_tcpudp_nofold
Mark Rutland <[email protected]>
arm64: Fix up /proc/cpuinfo
Peter Kümmel <[email protected]>
kconfig: Fix warning "‘jump’ may be used uninitialized"
Alex Deucher <[email protected]>
drm/radeon: properly set vm fragment size for TN/RL
Ilija Hadzic <[email protected]>
drm/radeon: fix the crash in test functions
Ilija Hadzic <[email protected]>
drm/radeon: fix the crash in benchmark functions
Christian König <[email protected]>
drm/radeon: fix PLLs on RS880 and older v2
Alex Deucher <[email protected]>
drm/radeon: don't init gpuvm if accel is disabled (v3)
Ryusuke Konishi <[email protected]>
nilfs2: fix deadlock of segment constructor over I_SYNC flag
Michal Hocko <[email protected]>
memcg, shmem: fix shmem migration to use lrucare
karl beldan <[email protected]>
lib/checksum.c: fix carry in csum_tcpudp_nofold
Shiraz Hashim <[email protected]>
mm: pagewalk: call pte_hole() for VM_PFNMAP during walk_page_range
NeilBrown <[email protected]>
md/raid5: fix another livelock caused by non-aligned writes.
Sachin Prabhu <[email protected]>
Complete oplock break jobs before closing file handle
Will Deacon <[email protected]>
ARM: 8299/1: mm: ensure local active ASID is marked as allocated on rollover
James Hogan <[email protected]>
MIPS: traps: Fix inline asm ctc1 missing .set hardfloat
James Hogan <[email protected]>
MIPS: mipsregs.h: Add write_32bit_cp1_register()
Hemmo Nieminen <[email protected]>
MIPS: Fix kernel lockup or crash after CPU offline/online
Aaro Koskinen <[email protected]>
MIPS: OCTEON: fix kernel crash when offlining a CPU
Felix Fietkau <[email protected]>
MIPS: IRQ: Fix disable_irq on CPU IRQs
David Daney <[email protected]>
MIPS: Fix C0_Pagegrain[IEC] support.
Brian King <[email protected]>
sd: Fix max transfer length for 4k disks
Robin Gong <[email protected]>
spi: imx: use pio mode for i.mx6dl
Bhuvanchandra DV <[email protected]>
spi: spi-fsl-dspi: Remove usage of devm_kzalloc
Myron Stowe <[email protected]>
PCI: Handle read-only BARs on AMD CS553x devices
Charlotte Richardson <[email protected]>
PCI: Add NEC variants to Stratus ftServer PCIe DMI check
Lucas Stach <[email protected]>
PCI: designware: Reject MSI-X IRQs
Sonic Zhang <[email protected]>
gpio: mcp23s08: handle default gpio base
Johan Hovold <[email protected]>
gpio: sysfs: fix memory leak in gpiod_sysfs_set_active_low
Johan Hovold <[email protected]>
gpio: sysfs: fix memory leak in gpiod_export_link
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/exynos4.dtsi | 4 +-
arch/arm/mm/context.c | 26 ++++-----
arch/arm64/kernel/setup.c | 96 +++++++++++++++++++++++--------
arch/mips/cavium-octeon/smp.c | 2 -
arch/mips/include/asm/mipsregs.h | 15 +++++
arch/mips/kernel/irq_cpu.c | 4 ++
arch/mips/kernel/smp.c | 2 +-
arch/mips/kernel/traps.c | 3 +-
arch/mips/mm/tlb-r4k.c | 2 +
arch/x86/kernel/cpu/microcode/core.c | 2 +-
arch/x86/pci/common.c | 16 ++++++
drivers/gpio/gpio-mcp23s08.c | 17 +++---
drivers/gpio/gpiolib-sysfs.c | 3 +-
drivers/gpu/drm/radeon/radeon_benchmark.c | 13 +++--
drivers/gpu/drm/radeon/radeon_display.c | 3 +
drivers/gpu/drm/radeon/radeon_gem.c | 6 +-
drivers/gpu/drm/radeon/radeon_kms.c | 16 +++---
drivers/gpu/drm/radeon/radeon_test.c | 8 +--
drivers/gpu/drm/radeon/radeon_vm.c | 6 +-
drivers/md/raid5.c | 5 ++
drivers/pci/host/pcie-designware.c | 3 +
drivers/pci/quirks.c | 40 ++++++++++++-
drivers/scsi/sd.c | 6 +-
drivers/spi/spi-fsl-dspi.c | 14 ++++-
drivers/spi/spi-imx.c | 4 ++
fs/cifs/file.c | 6 +-
fs/nilfs2/nilfs.h | 2 -
fs/nilfs2/segment.c | 44 ++++++++++++--
fs/nilfs2/segment.h | 5 ++
include/linux/tracepoint.h | 2 +-
include/sound/ak4113.h | 2 +-
include/sound/ak4114.h | 2 +-
include/trace/events/tlb.h | 4 +-
kernel/smpboot.c | 2 +
kernel/time/hrtimer.c | 2 +-
lib/checksum.c | 12 +++-
mm/memcontrol.c | 2 +-
mm/pagewalk.c | 5 +-
mm/shmem.c | 2 +-
scripts/kconfig/menu.c | 4 +-
sound/i2c/other/ak4113.c | 17 +++---
sound/i2c/other/ak4114.c | 18 +++---
sound/soc/atmel/atmel_ssc_dai.c | 18 ++----
sound/soc/codecs/sgtl5000.c | 3 +
45 files changed, 335 insertions(+), 137 deletions(-)
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.
Fixes: a4177ee7f1a8 ("gpiolib: allow exported GPIO nodes to be named using sysfs links")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpio/gpiolib-sysfs.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -630,6 +630,7 @@ int gpiod_export_link(struct device *dev
if (tdev != NULL) {
status = sysfs_create_link(&dev->kobj, &tdev->kobj,
name);
+ put_device(tdev);
} else {
status = -ENODEV;
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.
Fixes: 0769746183ca ("gpiolib: add support for changing value polarity in sysfs")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpio/gpiolib-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpio/gpiolib-sysfs.c
+++ b/drivers/gpio/gpiolib-sysfs.c
@@ -678,7 +678,7 @@ int gpiod_sysfs_set_active_low(struct gp
}
status = sysfs_set_active_low(desc, dev, value);
-
+ put_device(dev);
unlock:
mutex_unlock(&sysfs_lock);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sonic Zhang <[email protected]>
commit b184c388f773f30b6c707d3d4599b2db80f4390c upstream.
Create default gpio base if neither device node nor
platform data is defined.
Signed-off-by: Sonic Zhang <[email protected]>
Reviewed-by: Alexandre Courbot <[email protected]>
Tested-by: Antonio Fiol <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpio/gpio-mcp23s08.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/gpio/gpio-mcp23s08.c
+++ b/drivers/gpio/gpio-mcp23s08.c
@@ -785,9 +785,11 @@ static int mcp230xx_probe(struct i2c_cli
client->irq = irq_of_parse_and_map(client->dev.of_node, 0);
} else {
pdata = dev_get_platdata(&client->dev);
- if (!pdata || !gpio_is_valid(pdata->base)) {
- dev_dbg(&client->dev, "invalid platform data\n");
- return -EINVAL;
+ if (!pdata) {
+ pdata = devm_kzalloc(&client->dev,
+ sizeof(struct mcp23s08_platform_data),
+ GFP_KERNEL);
+ pdata->base = -1;
}
}
@@ -908,10 +910,11 @@ static int mcp23s08_probe(struct spi_dev
} else {
type = spi_get_device_id(spi)->driver_data;
pdata = dev_get_platdata(&spi->dev);
- if (!pdata || !gpio_is_valid(pdata->base)) {
- dev_dbg(&spi->dev,
- "invalid or missing platform data\n");
- return -EINVAL;
+ if (!pdata) {
+ pdata = devm_kzalloc(&spi->dev,
+ sizeof(struct mcp23s08_platform_data),
+ GFP_KERNEL);
+ pdata->base = -1;
}
for (addr = 0; addr < ARRAY_SIZE(pdata->chip); addr++) {
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas Stach <[email protected]>
commit 19c5392eb1c1e81188e898400c0e8258827eb160 upstream.
The DesignWare PCIe MSI hardware does not support MSI-X IRQs. Setting
those up failed as a side effect of a bug which was fixed by 91f8ae823f2b
("PCI: designware: Setup and clear exactly one MSI at a time").
Now that this bug is fixed, MSI-X IRQs need to be rejected explicitly;
otherwise devices trying to use them may end up with incorrectly working
interrupts.
Fixes: 91f8ae823f2b ("PCI: designware: Setup and clear exactly one MSI at a time")
Signed-off-by: Lucas Stach <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Acked-by: Jingoo Han <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/host/pcie-designware.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -283,6 +283,9 @@ static int dw_msi_setup_irq(struct msi_c
struct msi_msg msg;
struct pcie_port *pp = sys_to_pcie(pdev->bus->sysdata);
+ if (desc->msi_attrib.is_msix)
+ return -EINVAL;
+
irq = assign_irq(1, desc, &pos);
if (irq < 0)
return irq;
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charlotte Richardson <[email protected]>
commit 51ac3d2f0c505ca36ffc9715ffd518d756589ef8 upstream.
NEC OEMs the same platforms as Stratus does, which have multiple devices on
some PCIe buses under downstream ports.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331
Fixes: 1278998f8ff6 ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)")
Signed-off-by: Charlotte Richardson <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
CC: Myron Stowe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/pci/common.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -448,6 +448,22 @@ static const struct dmi_system_id pcipro
DMI_MATCH(DMI_PRODUCT_NAME, "ftServer"),
},
},
+ {
+ .callback = set_scan_all,
+ .ident = "Stratus/NEC ftServer",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Express5800/R32"),
+ },
+ },
+ {
+ .callback = set_scan_all,
+ .ident = "Stratus/NEC ftServer",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "NEC"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Express5800/R31"),
+ },
+ },
{}
};
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Myron Stowe <[email protected]>
commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.
Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e8164882ca ("PCI: Restore detection of read-only
BARs"). Prior to 36e8164882ca, we filled in res->start; afterwards we
leave it zeroed out. The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.
Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.
On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e8164882ca,
we interpret that as a 512-byte BAR based on the lowest-order bit set. Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.
[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
Reported-and-tested-by: Nix <[email protected]>
Signed-off-by: Myron Stowe <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/quirks.c | 40 +++++++++++++++++++++++++++++++++++++---
1 file changed, 37 insertions(+), 3 deletions(-)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -324,18 +324,52 @@ static void quirk_s3_64M(struct pci_dev
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S3, PCI_DEVICE_ID_S3_868, quirk_s3_64M);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S3, PCI_DEVICE_ID_S3_968, quirk_s3_64M);
+static void quirk_io(struct pci_dev *dev, int pos, unsigned size,
+ const char *name)
+{
+ u32 region;
+ struct pci_bus_region bus_region;
+ struct resource *res = dev->resource + pos;
+
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0 + (pos << 2), ®ion);
+
+ if (!region)
+ return;
+
+ res->name = pci_name(dev);
+ res->flags = region & ~PCI_BASE_ADDRESS_IO_MASK;
+ res->flags |=
+ (IORESOURCE_IO | IORESOURCE_PCI_FIXED | IORESOURCE_SIZEALIGN);
+ region &= ~(size - 1);
+
+ /* Convert from PCI bus to resource space */
+ bus_region.start = region;
+ bus_region.end = region + size - 1;
+ pcibios_bus_to_resource(dev->bus, res, &bus_region);
+
+ dev_info(&dev->dev, FW_BUG "%s quirk: reg 0x%x: %pR\n",
+ name, PCI_BASE_ADDRESS_0 + (pos << 2), res);
+}
+
/*
* Some CS5536 BIOSes (for example, the Soekris NET5501 board w/ comBIOS
* ver. 1.33 20070103) don't set the correct ISA PCI region header info.
* BAR0 should be 8 bytes; instead, it may be set to something like 8k
* (which conflicts w/ BAR1's memory range).
+ *
+ * CS553x's ISA PCI BARs may also be read-only (ref:
+ * https://bugzilla.kernel.org/show_bug.cgi?id=85991 - Comment #4 forward).
*/
static void quirk_cs5536_vsa(struct pci_dev *dev)
{
+ static char *name = "CS5536 ISA bridge";
+
if (pci_resource_len(dev, 0) != 8) {
- struct resource *res = &dev->resource[0];
- res->end = res->start + 8 - 1;
- dev_info(&dev->dev, "CS5536 ISA bridge bug detected (incorrect header); workaround applied\n");
+ quirk_io(dev, 0, 8, name); /* SMB */
+ quirk_io(dev, 1, 256, name); /* GPIO */
+ quirk_io(dev, 2, 64, name); /* MFGPT */
+ dev_info(&dev->dev, "%s bug detected (incorrect header); workaround applied\n",
+ name);
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_ISA, quirk_cs5536_vsa);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bhuvanchandra DV <[email protected]>
commit 973fbce69ed8e79b5fe3ad19cfecb581a7ef8048 upstream.
devm_* API was supposed to be used only in probe function call.
Memory is allocated at 'probe' and free automatically at 'remove'.
Usage of devm_* functions outside probe sometimes leads to memory leak.
Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead.
Also add the dspi_cleanup function to free the controller data upon
cleanup.
Acked-by: Stefan Agner <[email protected]>
Signed-off-by: Bhuvanchandra DV <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spi-fsl-dspi.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -342,8 +342,7 @@ static int dspi_setup_transfer(struct sp
/* Only alloc on first setup */
chip = spi_get_ctldata(spi);
if (chip == NULL) {
- chip = devm_kzalloc(&spi->dev, sizeof(struct chip_data),
- GFP_KERNEL);
+ chip = kzalloc(sizeof(struct chip_data), GFP_KERNEL);
if (!chip)
return -ENOMEM;
}
@@ -382,6 +381,16 @@ static int dspi_setup(struct spi_device
return dspi_setup_transfer(spi, NULL);
}
+static void dspi_cleanup(struct spi_device *spi)
+{
+ struct chip_data *chip = spi_get_ctldata((struct spi_device *)spi);
+
+ dev_dbg(&spi->dev, "spi_device %u.%u cleanup\n",
+ spi->master->bus_num, spi->chip_select);
+
+ kfree(chip);
+}
+
static irqreturn_t dspi_interrupt(int irq, void *dev_id)
{
struct fsl_dspi *dspi = (struct fsl_dspi *)dev_id;
@@ -467,6 +476,7 @@ static int dspi_probe(struct platform_de
dspi->bitbang.master->setup = dspi_setup;
dspi->bitbang.master->dev.of_node = pdev->dev.of_node;
+ master->cleanup = dspi_cleanup;
master->mode_bits = SPI_CPOL | SPI_CPHA;
master->bits_per_word_mask = SPI_BPW_MASK(4) | SPI_BPW_MASK(8) |
SPI_BPW_MASK(16);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robin Gong <[email protected]>
commit a02bb401f8ae264be782ee57d98bdd99f14c8022 upstream.
For TKT238285 hardware issue which may cause txfifo store data twice can only
be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.
Fixes: f62caccd12c17e4 (spi: spi-imx: add DMA support)
Signed-off-by: Robin Gong <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spi-imx.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -823,6 +823,10 @@ static int spi_imx_sdma_init(struct devi
struct dma_slave_config slave_config = {};
int ret;
+ /* use pio mode for i.mx6dl chip TKT238285 */
+ if (of_machine_is_compatible("fsl,imx6dl"))
+ return 0;
+
/* Prepare for TX DMA: */
master->dma_tx = dma_request_slave_channel(dev, "tx");
if (!master->dma_tx) {
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian King <[email protected]>
commit 3a9794d32984b67a6d8992226918618f0e51e5d5 upstream.
The following patch fixes an issue observed with 4k sector disks
where the max_hw_sectors attribute was getting set too large in
sd_revalidate_disk. Since sdkp->max_xfer_blocks is in units
of SCSI logical blocks and queue_max_hw_sectors is in units of
512 byte blocks, on a 4k sector disk, every time we went through
sd_revalidate_disk, we were taking the current value of
queue_max_hw_sectors and increasing it by a factor of 8. Fix
this by only shifting sdkp->max_xfer_blocks.
Signed-off-by: Brian King <[email protected]>
Reviewed-by: Paolo Bonzini <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/sd.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2818,9 +2818,11 @@ static int sd_revalidate_disk(struct gen
*/
sd_set_flush_flag(sdkp);
- max_xfer = min_not_zero(queue_max_hw_sectors(sdkp->disk->queue),
- sdkp->max_xfer_blocks);
+ max_xfer = sdkp->max_xfer_blocks;
max_xfer <<= ilog2(sdp->sector_size) - 9;
+
+ max_xfer = min_not_zero(queue_max_hw_sectors(sdkp->disk->queue),
+ max_xfer);
blk_queue_max_hw_sectors(sdkp->disk->queue, max_xfer);
set_capacity(disk, sdkp->capacity);
sd_config_write_same(sdkp);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Daney <[email protected]>
commit 9ead8632bbf454cfc709b6205dc9cd8582fb0d64 upstream.
The following commits:
5890f70f15c52d (MIPS: Use dedicated exception handler if CPU supports RI/XI exceptions)
6575b1d4173eae (MIPS: kernel: cpu-probe: Detect unique RI/XI exceptions)
break the kernel for *all* existing MIPS CPUs that implement the
CP0_PageGrain[IEC] bit. They cause the TLB exception handlers to be
generated without the legacy execute-inhibit handling, but never set
the CP0_PageGrain[IEC] bit to activate the use of dedicated exception
vectors for execute-inhibit exceptions. The result is that upon
detection of an execute-inhibit violation, we loop forever in the TLB
exception handlers instead of sending SIGSEGV to the task.
If we are generating TLB exception handlers expecting separate
vectors, we must also enable the CP0_PageGrain[IEC] feature.
The bug was introduced in kernel version 3.17.
Signed-off-by: David Daney <[email protected]>
Cc: Leonid Yegoshin <[email protected]>
Cc: [email protected]
Patchwork: http://patchwork.linux-mips.org/patch/8880/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/mm/tlb-r4k.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -489,6 +489,8 @@ static void r4k_tlb_configure(void)
#ifdef CONFIG_64BIT
pg |= PG_ELPA;
#endif
+ if (cpu_has_rixiex)
+ pg |= PG_IEC;
write_c0_pagegrain(pg);
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit a3e6c1eff54878506b2dddcc202df9cc8180facb upstream.
If the irq_chip does not define .irq_disable, any call to disable_irq
will defer disabling the IRQ until it fires while marked as disabled.
This assumes that the handler function checks for this condition, which
handle_percpu_irq does not. In this case, calling disable_irq leads to
an IRQ storm, if the interrupt fires while disabled.
This optimization is only useful when disabling the IRQ is slow, which
is not true for the MIPS CPU IRQ.
Disable this optimization by implementing .irq_disable and .irq_enable
Signed-off-by: Felix Fietkau <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/8949/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/kernel/irq_cpu.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -56,6 +56,8 @@ static struct irq_chip mips_cpu_irq_cont
.irq_mask_ack = mask_mips_irq,
.irq_unmask = unmask_mips_irq,
.irq_eoi = unmask_mips_irq,
+ .irq_disable = mask_mips_irq,
+ .irq_enable = unmask_mips_irq,
};
/*
@@ -92,6 +94,8 @@ static struct irq_chip mips_mt_cpu_irq_c
.irq_mask_ack = mips_mt_cpu_irq_ack,
.irq_unmask = unmask_mips_irq,
.irq_eoi = unmask_mips_irq,
+ .irq_disable = mask_mips_irq,
+ .irq_enable = unmask_mips_irq,
};
void __init mips_cpu_irq_init(void)
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaro Koskinen <[email protected]>
commit 63a87fe0d0de2ce126a8cec9a299a133cfd5658e upstream.
octeon_cpu_disable() will unconditionally enable interrupts when called.
We can assume that the routine is always called with interrupts disabled,
so just delete the incorrect local_irq_disable/enable().
The patch fixes the following crash when offlining a CPU:
[ 93.818785] ------------[ cut here ]------------
[ 93.823421] WARNING: CPU: 1 PID: 10 at kernel/smp.c:231 flush_smp_call_function_queue+0x1c4/0x1d0()
[ 93.836215] Modules linked in:
[ 93.839287] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.19.0-rc4-octeon-los_b5f0 #1
[ 93.847212] Stack : 0000000000000001 ffffffff81b2cf90 0000000000000004 ffffffff81630000
0000000000000000 0000000000000000 0000000000000000 000000000000004a
0000000000000006 ffffffff8117e550 0000000000000000 0000000000000000
ffffffff81b30000 ffffffff81b26808 8000000032c77748 ffffffff81627e07
ffffffff81595ec8 ffffffff81b26808 000000000000000a 0000000000000001
0000000000000001 0000000000000003 0000000010008ce1 ffffffff815030c8
8000000032cbbb38 ffffffff8113d42c 0000000010008ce1 ffffffff8117f36c
8000000032c77300 8000000032cbba50 0000000000000001 ffffffff81503984
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 ffffffff81121668 0000000000000000 0000000000000000
...
[ 93.912819] Call Trace:
[ 93.915273] [<ffffffff81121668>] show_stack+0x68/0x80
[ 93.920335] [<ffffffff81503984>] dump_stack+0x6c/0x90
[ 93.925395] [<ffffffff8113d58c>] warn_slowpath_common+0x94/0xd8
[ 93.931324] [<ffffffff811a402c>] flush_smp_call_function_queue+0x1c4/0x1d0
[ 93.938208] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108
[ 93.943444] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8
[ 93.949286] [<ffffffff8113d704>] cpu_notify+0x24/0x60
[ 93.954348] [<ffffffff81501738>] take_cpu_down+0x38/0x58
[ 93.959670] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180
[ 93.965250] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160
[ 93.971093] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8
[ 93.976936] [<ffffffff8115ab04>] kthread+0xd4/0xf0
[ 93.981735] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c
[ 93.987835]
[ 93.989326] ---[ end trace c9e3815ee655bda9 ]---
[ 93.993951] Kernel bug detected[#1]:
[ 93.997533] CPU: 1 PID: 10 Comm: migration/1 Tainted: G W 3.19.0-rc4-octeon-los_b5f0 #1
[ 94.006591] task: 8000000032c77300 ti: 8000000032cb8000 task.ti: 8000000032cb8000
[ 94.014081] $ 0 : 0000000000000000 0000000010000ce1 0000000000000001 ffffffff81620000
[ 94.022146] $ 4 : 8000000002c72ac0 0000000000000000 00000000000001a7 ffffffff813b06f0
[ 94.030210] $ 8 : ffffffff813b20d8 0000000000000000 0000000000000000 ffffffff81630000
[ 94.038275] $12 : 0000000000000087 0000000000000000 0000000000000086 0000000000000000
[ 94.046339] $16 : ffffffff81623168 0000000000000001 0000000000000000 0000000000000008
[ 94.054405] $20 : 0000000000000001 0000000000000001 0000000000000001 0000000000000003
[ 94.062470] $24 : 0000000000000038 ffffffff813b7f10
[ 94.070536] $28 : 8000000032cb8000 8000000032cbbc20 0000000010008ce1 ffffffff811bcaf4
[ 94.078601] Hi : 0000000000f188e8
[ 94.082179] Lo : d4fdf3b646c09d55
[ 94.085760] epc : ffffffff811bc9d0 irq_work_run_list+0x8/0xf8
[ 94.091686] Tainted: G W
[ 94.095613] ra : ffffffff811bcaf4 irq_work_run+0x34/0x60
[ 94.101192] Status: 10000ce3 KX SX UX KERNEL EXL IE
[ 94.106235] Cause : 40808034
[ 94.109119] PrId : 000d9301 (Cavium Octeon II)
[ 94.113653] Modules linked in:
[ 94.116721] Process migration/1 (pid: 10, threadinfo=8000000032cb8000, task=8000000032c77300, tls=0000000000000000)
[ 94.127168] Stack : 8000000002c74c80 ffffffff811a4128 0000000000000001 ffffffff81635720
fffffffffffffff2 ffffffff8115bacc 80000000320fbce0 80000000320fbca4
80000000320fbc80 0000000000000002 0000000000000004 ffffffff8113d704
80000000320fbce0 ffffffff81501738 0000000000000003 ffffffff811b343c
8000000002c72aa0 8000000002c72aa8 ffffffff8159cae8 ffffffff8159caa0
ffffffff81650000 80000000320fbbf0 80000000320fbc80 ffffffff811b32e8
0000000000000000 ffffffff811b3768 ffffffff81622b80 ffffffff815148a8
8000000032c77300 8000000002c73e80 ffffffff815148a8 8000000032c77300
ffffffff81622b80 ffffffff815148a8 8000000032c77300 ffffffff81503f48
ffffffff8115ea0c ffffffff81620000 0000000000000000 ffffffff81174d64
...
[ 94.192771] Call Trace:
[ 94.195222] [<ffffffff811bc9d0>] irq_work_run_list+0x8/0xf8
[ 94.200802] [<ffffffff811bcaf4>] irq_work_run+0x34/0x60
[ 94.206036] [<ffffffff811a4128>] hotplug_cfd+0xf0/0x108
[ 94.211269] [<ffffffff8115bacc>] notifier_call_chain+0x5c/0xb8
[ 94.217111] [<ffffffff8113d704>] cpu_notify+0x24/0x60
[ 94.222171] [<ffffffff81501738>] take_cpu_down+0x38/0x58
[ 94.227491] [<ffffffff811b343c>] multi_cpu_stop+0x154/0x180
[ 94.233072] [<ffffffff811b3768>] cpu_stopper_thread+0xd8/0x160
[ 94.238914] [<ffffffff8115ea4c>] smpboot_thread_fn+0x1ec/0x1f8
[ 94.244757] [<ffffffff8115ab04>] kthread+0xd4/0xf0
[ 94.249555] [<ffffffff8111c4f0>] ret_from_kernel_thread+0x14/0x1c
[ 94.255654]
[ 94.257146]
Code: a2423c40 40026000 30420001 <00020336> dc820000 10400037 00000000 0000010f 0000010f
[ 94.267183] ---[ end trace c9e3815ee655bdaa ]---
[ 94.271804] Fatal exception: panic in 5 seconds
Reported-by: Hemmo Nieminen <[email protected]>
Signed-off-by: Aaro Koskinen <[email protected]>
Acked-by: David Daney <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/8952/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/cavium-octeon/smp.c | 2 --
1 file changed, 2 deletions(-)
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -240,9 +240,7 @@ static int octeon_cpu_disable(void)
set_cpu_online(cpu, false);
cpu_clear(cpu, cpu_callin_map);
- local_irq_disable();
octeon_fixup_irqs();
- local_irq_enable();
flush_cache_all();
local_flush_tlb_all();
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hemmo Nieminen <[email protected]>
commit c7754e75100ed5e3068ac5085747f2bfc386c8d6 upstream.
As printk() invocation can cause e.g. a TLB miss, printk() cannot be
called before the exception handlers have been properly initialized.
This can happen e.g. when netconsole has been loaded as a kernel module
and the TLB table has been cleared when a CPU was offline.
Call cpu_report() in start_secondary() only after the exception handlers
have been initialized to fix this.
Without the patch the kernel will randomly either lockup or crash
after a CPU is onlined and the console driver is a module.
Signed-off-by: Hemmo Nieminen <[email protected]>
Signed-off-by: Aaro Koskinen <[email protected]>
Cc: David Daney <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/8953/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -123,10 +123,10 @@ asmlinkage void start_secondary(void)
unsigned int cpu;
cpu_probe();
- cpu_report();
per_cpu_trap_init(false);
mips_clockevent_init();
mp_ops->init_secondary();
+ cpu_report();
/*
* XXX parity protection should be folded in here when it's converted
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit 5e32033e14ca9c7f7341cb383f5a05699b0b5382 upstream.
Add a write_32bit_cp1_register() macro to compliment the
read_32bit_cp1_register() macro. This is to abstract whether .set
hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT.
The implementation of _read_32bit_cp1_register() .sets mips1 due to
failure of gas v2.19 to assemble cfc1 for Octeon (see commit
25c300030016 ("MIPS: Override assembler target architecture for
octeon.")). I haven't copied this over to _write_32bit_cp1_register() as
I'm uncertain whether it applies to ctc1 too, or whether anybody cares
about that version of binutils any longer.
Signed-off-by: James Hogan <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: David Daney <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/9172/
Signed-off-by: Ralf Baechle <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/include/asm/mipsregs.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -1343,12 +1343,27 @@ do { \
__res; \
})
+#define _write_32bit_cp1_register(dest, val, gas_hardfloat) \
+do { \
+ __asm__ __volatile__( \
+ " .set push \n" \
+ " .set reorder \n" \
+ " "STR(gas_hardfloat)" \n" \
+ " ctc1 %0,"STR(dest)" \n" \
+ " .set pop \n" \
+ : : "r" (val)); \
+} while (0)
+
#ifdef GAS_HAS_SET_HARDFLOAT
#define read_32bit_cp1_register(source) \
_read_32bit_cp1_register(source, .set hardfloat)
+#define write_32bit_cp1_register(dest, val) \
+ _write_32bit_cp1_register(dest, val, .set hardfloat)
#else
#define read_32bit_cp1_register(source) \
_read_32bit_cp1_register(source, )
+#define write_32bit_cp1_register(dest, val) \
+ _write_32bit_cp1_register(dest, val, )
#endif
#ifdef HAVE_AS_DSP
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
commit d76e9b9fc5de7e8fc4fd0e72a94e8c723929ffea upstream.
Commit 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+") in v3.18
enabled -msoft-float and sprinkled ".set hardfloat" where necessary to
use FP instructions. However it missed enable_restore_fp_context() which
since v3.17 does a ctc1 with inline assembly, causing the following
assembler errors on Mentor's 2014.05 toolchain:
{standard input}: Assembler messages:
{standard input}:2913: Error: opcode not supported on this processor: mips32r2 (mips32r2) `ctc1 $2,$31'
scripts/Makefile.build:257: recipe for target 'arch/mips/kernel/traps.o' failed
Fix that to use the new write_32bit_cp1_register() macro so that ".set
hardfloat" is automatically added when -msoft-float is in use.
Fixes 842dfc11ea9a ("MIPS: Fix build with binutils 2.24.51+")
Signed-off-by: James Hogan <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/9173/
Signed-off-by: Ralf Baechle <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/mips/kernel/traps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1184,7 +1184,8 @@ static int enable_restore_fp_context(int
/* Restore the scalar FP control & status register */
if (!was_fpu_owner)
- asm volatile("ctc1 %0, $31" : : "r"(current->thread.fpu.fcr31));
+ write_32bit_cp1_register(CP1_STATUS,
+ current->thread.fpu.fcr31);
}
out:
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 8e64806672466392acf19e14427d1c29df3e58b9 upstream.
Commit e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0
when running with LPAE") removed the use of the reserved TTBR0 value
for LPAE systems, since the ASID is held in the TTBR and can be updated
atomicly with the pgd of the next mm.
Unfortunately, this patch forgot to update flush_context, which
deliberately avoids marking the local active ASID as allocated, since we
used to switch via ASID zero and didn't need to allocate the ASID of
the previous mm. The side-effect of this is that we can allocate the
same ASID to the next mm and, between flushing the local TLB and updating
TTBR0, we can perform speculative TLB fills for userspace nG mappings
using the page table of the previous mm.
The consequence of this is that the next mm can erroneously hit some
mappings of the previous mm. Note that this was made significantly
harder to hit by a391263cd84e ("ARM: 8203/1: mm: try to re-use old ASID
assignments following a rollover") but is still theoretically possible.
This patch fixes the problem by removing the code from flush_context
that forces the allocated ASID to zero for the local CPU. Many thanks
to the Broadcom guys for tracking this one down.
Fixes: e1a5848e3398 ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE")
Reported-by: Raymond Ngun <[email protected]>
Tested-by: Raymond Ngun <[email protected]>
Reviewed-by: Gregory Fong <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mm/context.c | 26 +++++++++++---------------
1 file changed, 11 insertions(+), 15 deletions(-)
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -144,21 +144,17 @@ static void flush_context(unsigned int c
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
for_each_possible_cpu(i) {
- if (i == cpu) {
- asid = 0;
- } else {
- asid = atomic64_xchg(&per_cpu(active_asids, i), 0);
- /*
- * If this CPU has already been through a
- * rollover, but hasn't run another task in
- * the meantime, we must preserve its reserved
- * ASID, as this is the only trace we have of
- * the process it is still running.
- */
- if (asid == 0)
- asid = per_cpu(reserved_asids, i);
- __set_bit(asid & ~ASID_MASK, asid_map);
- }
+ asid = atomic64_xchg(&per_cpu(active_asids, i), 0);
+ /*
+ * If this CPU has already been through a
+ * rollover, but hasn't run another task in
+ * the meantime, we must preserve its reserved
+ * ASID, as this is the only trace we have of
+ * the process it is still running.
+ */
+ if (asid == 0)
+ asid = per_cpu(reserved_asids, i);
+ __set_bit(asid & ~ASID_MASK, asid_map);
per_cpu(reserved_asids, i) = asid;
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sachin Prabhu <[email protected]>
commit ca7df8e0bb2a5ec79691de8a1a4c0e611fe04e60 upstream.
Commit
c11f1df5003d534fd067f0168bfad7befffb3b5c
requires writers to wait for any pending oplock break handler to
complete before proceeding to write. This is done by waiting on bit
CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is
cleared by the oplock break handler job queued on the workqueue once it
has completed handling the oplock break allowing writers to proceed with
writing to the file.
While testing, it was noticed that the filehandle could be closed while
there is a pending oplock break which results in the oplock break
handler on the cifsiod workqueue being cancelled before it has had a
chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit.
Any subsequent attempt to write to this file hangs waiting for the
CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared.
We fix this by ensuring that we also clear the bit
CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler
from the workqueue.
The bug was found by Red Hat QA while testing using ltp's fsstress
command.
Signed-off-by: Sachin Prabhu <[email protected]>
Acked-by: Shirish Pargaonkar <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/file.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -366,6 +366,7 @@ void cifsFileInfo_put(struct cifsFileInf
struct cifsLockInfo *li, *tmp;
struct cifs_fid fid;
struct cifs_pending_open open;
+ bool oplock_break_cancelled;
spin_lock(&cifs_file_list_lock);
if (--cifs_file->count > 0) {
@@ -397,7 +398,7 @@ void cifsFileInfo_put(struct cifsFileInf
}
spin_unlock(&cifs_file_list_lock);
- cancel_work_sync(&cifs_file->oplock_break);
+ oplock_break_cancelled = cancel_work_sync(&cifs_file->oplock_break);
if (!tcon->need_reconnect && !cifs_file->invalidHandle) {
struct TCP_Server_Info *server = tcon->ses->server;
@@ -409,6 +410,9 @@ void cifsFileInfo_put(struct cifsFileInf
_free_xid(xid);
}
+ if (oplock_break_cancelled)
+ cifs_done_oplock_break(cifsi);
+
cifs_del_pending_open(&open);
/*
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit b1b02fe97f75b12ab34b2303bfd4e3526d903a58 upstream.
If a non-page-aligned write is destined for a device which
is missing/faulty, we can deadlock.
As the target device is missing, a read-modify-write cycle
is not possible.
As the write is not for a full-page, a recontruct-write cycle
is not possible.
This should be handled by logic in fetch_block() which notices
there is a non-R5_OVERWRITE write to a missing device, and so
loads all blocks.
However since commit 67f455486d2ea2, that code requires
STRIPE_PREREAD_ACTIVE before it will active, and those circumstances
never set STRIPE_PREREAD_ACTIVE.
So: in handle_stripe_dirtying, if neither rmw or rcw was possible,
set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set
after a suitable delay.
Fixes: 67f455486d2ea20b2d94d6adf5b9b783d079e321
Reported-by: Mikulas Patocka <[email protected]>
Tested-by: Heinz Mauelshagen <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid5.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3195,6 +3195,11 @@ static void handle_stripe_dirtying(struc
(unsigned long long)sh->sector,
rcw, qread, test_bit(STRIPE_DELAYED, &sh->state));
}
+
+ if (rcw > disks && rmw > disks &&
+ !test_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
+ set_bit(STRIPE_DELAYED, &sh->state);
+
/* now if nothing is locked, and if we have enough data,
* we can start a write request
*/
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shiraz Hashim <[email protected]>
commit 23aaed6659df9adfabe9c583e67a36b54e21df46 upstream.
walk_page_range() silently skips vma having VM_PFNMAP set, which leads
to undesirable behaviour at client end (who called walk_page_range).
Userspace applications get the wrong data, so the effect is like just
confusing users (if the applications just display the data) or sometimes
killing the processes (if the applications do something with
misunderstanding virtual addresses due to the wrong data.)
For example for pagemap_read, when no callbacks are called against
VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual
address range at wrong index.
Eventually userspace may get wrong pagemap data for a task.
Corresponding to a VM_PFNMAP marked vma region, kernel may report
mappings from subsequent vma regions. User space in turn may account
more pages (than really are) to the task.
In my case I was using procmem, procrack (Android utility) which uses
pagemap interface to account RSS pages of a task. Due to this bug it
was giving a wrong picture for vmas (with VM_PFNMAP set).
Fixes: a9ff785e4437 ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas")
Signed-off-by: Shiraz Hashim <[email protected]>
Acked-by: Naoya Horiguchi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/pagewalk.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -199,7 +199,10 @@ int walk_page_range(unsigned long addr,
*/
if ((vma->vm_start <= addr) &&
(vma->vm_flags & VM_PFNMAP)) {
- next = vma->vm_end;
+ if (walk->pte_hole)
+ err = walk->pte_hole(addr, next, walk);
+ if (err)
+ break;
pgd = pgd_offset(walk->mm, next);
continue;
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: karl beldan <[email protected]>
commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream.
The carry from the 64->32bits folding was dropped, e.g with:
saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1,
csum_tcpudp_nofold returned 0 instead of 1.
Signed-off-by: Karl Beldan <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Mike Frysinger <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/checksum.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,6 +47,15 @@ static inline unsigned short from32to16(
return x;
}
+static inline u32 from64to32(u64 x)
+{
+ /* add up 32-bit and 32-bit for 32+c bit */
+ x = (x & 0xffffffff) + (x >> 32);
+ /* add up carry.. */
+ x = (x & 0xffffffff) + (x >> 32);
+ return (u32)x;
+}
+
static unsigned int do_csum(const unsigned char *buff, int len)
{
int odd;
@@ -195,8 +204,7 @@ __wsum csum_tcpudp_nofold(__be32 saddr,
#else
s += (proto + len) << 8;
#endif
- s += (s >> 32);
- return (__force __wsum)s;
+ return (__force __wsum)from64to32(s);
}
EXPORT_SYMBOL(csum_tcpudp_nofold);
#endif
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <[email protected]>
commit f5e03a4989e80a86f8b514659dca8539132e6e09 upstream.
It has been reported that 965GM might trigger
VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage)
in mem_cgroup_migrate when shmem wants to replace a swap cache page
because of shmem_should_replace_page (the page is allocated from an
inappropriate zone). shmem_replace_page expects that the oldpage is not
on LRU list and calls mem_cgroup_migrate without lrucare. This is
obviously incorrect because swapcache pages might be on the LRU list
(e.g. swapin readahead page).
Fix this by enabling lrucare for the migration in shmem_replace_page.
Also clarify that lrucare should be used even if one of the pages might
be on LRU list.
The BUG_ON will trigger only when CONFIG_DEBUG_VM is enabled but even
without that the migration code might leave the old page on an
inappropriate memcg' LRU which is not that critical because the page
would get removed with its last reference but it is still confusing.
Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")
Signed-off-by: Michal Hocko <[email protected]>
Reported-by: Chris Wilson <[email protected]>
Reported-by: Dave Airlie <[email protected]>
Acked-by: Hugh Dickins <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
mm/memcontrol.c | 2 +-
mm/shmem.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6589,7 +6589,7 @@ void mem_cgroup_uncharge_list(struct lis
* mem_cgroup_migrate - migrate a charge to another page
* @oldpage: currently charged page
* @newpage: page to transfer the charge to
- * @lrucare: both pages might be on the LRU already
+ * @lrucare: either or both pages might be on the LRU already
*
* Migrate the charge from @oldpage to @newpage.
*
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1013,7 +1013,7 @@ static int shmem_replace_page(struct pag
*/
oldpage = newpage;
} else {
- mem_cgroup_migrate(oldpage, newpage, false);
+ mem_cgroup_migrate(oldpage, newpage, true);
lru_cache_add_anon(newpage);
*pagep = newpage;
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <[email protected]>
commit 7ef3ff2fea8bf5e4a21cef47ad87710a3d0fdb52 upstream.
Nilfs2 eventually hangs in a stress test with fsstress program. This
issue was caused by the following deadlock over I_SYNC flag between
nilfs_segctor_thread() and writeback_sb_inodes():
nilfs_segctor_thread()
nilfs_segctor_thread_construct()
nilfs_segctor_unlock()
nilfs_dispose_list()
iput()
iput_final()
evict()
inode_wait_for_writeback() * wait for I_SYNC flag
writeback_sb_inodes()
* set I_SYNC flag on inode->i_state
__writeback_single_inode()
do_writepages()
nilfs_writepages()
nilfs_construct_dsync_segment()
nilfs_segctor_sync()
* wait for completion of segment constructor
inode_sync_complete()
* clear I_SYNC flag after __writeback_single_inode() completed
writeback_sb_inodes() calls do_writepages() for dirty inodes after
setting I_SYNC flag on inode->i_state. do_writepages() in turn calls
nilfs_writepages(), which can run segment constructor and wait for its
completion. On the other hand, segment constructor calls iput(), which
can call evict() and wait for the I_SYNC flag on
inode_wait_for_writeback().
Since segment constructor doesn't know when I_SYNC will be set, it
cannot know whether iput() will block or not unless inode->i_nlink has a
non-zero count. We can prevent evict() from being called in iput() by
implementing sop->drop_inode(), but it's not preferable to leave inodes
with i_nlink == 0 for long periods because it even defers file
truncation and inode deallocation. So, this instead resolves the
deadlock by calling iput() asynchronously with a workqueue for inodes
with i_nlink == 0.
Signed-off-by: Ryusuke Konishi <[email protected]>
Cc: Al Viro <[email protected]>
Tested-by: Ryusuke Konishi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nilfs2/nilfs.h | 2 --
fs/nilfs2/segment.c | 44 +++++++++++++++++++++++++++++++++++++++-----
fs/nilfs2/segment.h | 5 +++++
3 files changed, 44 insertions(+), 7 deletions(-)
--- a/fs/nilfs2/nilfs.h
+++ b/fs/nilfs2/nilfs.h
@@ -141,7 +141,6 @@ enum {
* @ti_save: Backup of journal_info field of task_struct
* @ti_flags: Flags
* @ti_count: Nest level
- * @ti_garbage: List of inode to be put when releasing semaphore
*/
struct nilfs_transaction_info {
u32 ti_magic;
@@ -150,7 +149,6 @@ struct nilfs_transaction_info {
one of other filesystems has a bug. */
unsigned short ti_flags;
unsigned short ti_count;
- struct list_head ti_garbage;
};
/* ti_magic */
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -305,7 +305,6 @@ static void nilfs_transaction_lock(struc
ti->ti_count = 0;
ti->ti_save = cur_ti;
ti->ti_magic = NILFS_TI_MAGIC;
- INIT_LIST_HEAD(&ti->ti_garbage);
current->journal_info = ti;
for (;;) {
@@ -332,8 +331,6 @@ static void nilfs_transaction_unlock(str
up_write(&nilfs->ns_segctor_sem);
current->journal_info = ti->ti_save;
- if (!list_empty(&ti->ti_garbage))
- nilfs_dispose_list(nilfs, &ti->ti_garbage, 0);
}
static void *nilfs_segctor_map_segsum_entry(struct nilfs_sc_info *sci,
@@ -746,6 +743,15 @@ static void nilfs_dispose_list(struct th
}
}
+static void nilfs_iput_work_func(struct work_struct *work)
+{
+ struct nilfs_sc_info *sci = container_of(work, struct nilfs_sc_info,
+ sc_iput_work);
+ struct the_nilfs *nilfs = sci->sc_super->s_fs_info;
+
+ nilfs_dispose_list(nilfs, &sci->sc_iput_queue, 0);
+}
+
static int nilfs_test_metadata_dirty(struct the_nilfs *nilfs,
struct nilfs_root *root)
{
@@ -1900,8 +1906,8 @@ static int nilfs_segctor_collect_dirty_f
static void nilfs_segctor_drop_written_files(struct nilfs_sc_info *sci,
struct the_nilfs *nilfs)
{
- struct nilfs_transaction_info *ti = current->journal_info;
struct nilfs_inode_info *ii, *n;
+ int defer_iput = false;
spin_lock(&nilfs->ns_inode_lock);
list_for_each_entry_safe(ii, n, &sci->sc_dirty_files, i_dirty) {
@@ -1912,9 +1918,24 @@ static void nilfs_segctor_drop_written_f
clear_bit(NILFS_I_BUSY, &ii->i_state);
brelse(ii->i_bh);
ii->i_bh = NULL;
- list_move_tail(&ii->i_dirty, &ti->ti_garbage);
+ list_del_init(&ii->i_dirty);
+ if (!ii->vfs_inode.i_nlink) {
+ /*
+ * Defer calling iput() to avoid a deadlock
+ * over I_SYNC flag for inodes with i_nlink == 0
+ */
+ list_add_tail(&ii->i_dirty, &sci->sc_iput_queue);
+ defer_iput = true;
+ } else {
+ spin_unlock(&nilfs->ns_inode_lock);
+ iput(&ii->vfs_inode);
+ spin_lock(&nilfs->ns_inode_lock);
+ }
}
spin_unlock(&nilfs->ns_inode_lock);
+
+ if (defer_iput)
+ schedule_work(&sci->sc_iput_work);
}
/*
@@ -2583,6 +2604,8 @@ static struct nilfs_sc_info *nilfs_segct
INIT_LIST_HEAD(&sci->sc_segbufs);
INIT_LIST_HEAD(&sci->sc_write_logs);
INIT_LIST_HEAD(&sci->sc_gc_inodes);
+ INIT_LIST_HEAD(&sci->sc_iput_queue);
+ INIT_WORK(&sci->sc_iput_work, nilfs_iput_work_func);
init_timer(&sci->sc_timer);
sci->sc_interval = HZ * NILFS_SC_DEFAULT_TIMEOUT;
@@ -2609,6 +2632,8 @@ static void nilfs_segctor_write_out(stru
ret = nilfs_segctor_construct(sci, SC_LSEG_SR);
nilfs_transaction_unlock(sci->sc_super);
+ flush_work(&sci->sc_iput_work);
+
} while (ret && retrycount-- > 0);
}
@@ -2633,6 +2658,9 @@ static void nilfs_segctor_destroy(struct
|| sci->sc_seq_request != sci->sc_seq_done);
spin_unlock(&sci->sc_state_lock);
+ if (flush_work(&sci->sc_iput_work))
+ flag = true;
+
if (flag || !nilfs_segctor_confirm(sci))
nilfs_segctor_write_out(sci);
@@ -2642,6 +2670,12 @@ static void nilfs_segctor_destroy(struct
nilfs_dispose_list(nilfs, &sci->sc_dirty_files, 1);
}
+ if (!list_empty(&sci->sc_iput_queue)) {
+ nilfs_warning(sci->sc_super, __func__,
+ "iput queue is not empty\n");
+ nilfs_dispose_list(nilfs, &sci->sc_iput_queue, 1);
+ }
+
WARN_ON(!list_empty(&sci->sc_segbufs));
WARN_ON(!list_empty(&sci->sc_write_logs));
--- a/fs/nilfs2/segment.h
+++ b/fs/nilfs2/segment.h
@@ -26,6 +26,7 @@
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/buffer_head.h>
+#include <linux/workqueue.h>
#include <linux/nilfs2_fs.h>
#include "nilfs.h"
@@ -92,6 +93,8 @@ struct nilfs_segsum_pointer {
* @sc_nblk_inc: Block count of current generation
* @sc_dirty_files: List of files to be written
* @sc_gc_inodes: List of GC inodes having blocks to be written
+ * @sc_iput_queue: list of inodes for which iput should be done
+ * @sc_iput_work: work struct to defer iput call
* @sc_freesegs: array of segment numbers to be freed
* @sc_nfreesegs: number of segments on @sc_freesegs
* @sc_dsync_inode: inode whose data pages are written for a sync operation
@@ -135,6 +138,8 @@ struct nilfs_sc_info {
struct list_head sc_dirty_files;
struct list_head sc_gc_inodes;
+ struct list_head sc_iput_queue;
+ struct work_struct sc_iput_work;
__u64 *sc_freesegs;
size_t sc_nfreesegs;
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream.
If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it. Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.
v2: handle vm_fini as well
v3: handle bo_open/close as well
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/radeon_gem.c | 6 ++++--
drivers/gpu/drm/radeon/radeon_kms.c | 16 ++++++++--------
2 files changed, 12 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -146,7 +146,8 @@ int radeon_gem_object_open(struct drm_ge
struct radeon_bo_va *bo_va;
int r;
- if (rdev->family < CHIP_CAYMAN) {
+ if ((rdev->family < CHIP_CAYMAN) ||
+ (!rdev->accel_working)) {
return 0;
}
@@ -176,7 +177,8 @@ void radeon_gem_object_close(struct drm_
struct radeon_bo_va *bo_va;
int r;
- if (rdev->family < CHIP_CAYMAN) {
+ if ((rdev->family < CHIP_CAYMAN) ||
+ (!rdev->accel_working)) {
return;
}
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -598,14 +598,14 @@ int radeon_driver_open_kms(struct drm_de
return -ENOMEM;
}
- vm = &fpriv->vm;
- r = radeon_vm_init(rdev, vm);
- if (r) {
- kfree(fpriv);
- return r;
- }
-
if (rdev->accel_working) {
+ vm = &fpriv->vm;
+ r = radeon_vm_init(rdev, vm);
+ if (r) {
+ kfree(fpriv);
+ return r;
+ }
+
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (r) {
radeon_vm_fini(rdev, vm);
@@ -663,9 +663,9 @@ void radeon_driver_postclose_kms(struct
radeon_vm_bo_rmv(rdev, vm->ib_bo_va);
radeon_bo_unreserve(rdev->ring_tmp_bo.bo);
}
+ radeon_vm_fini(rdev, vm);
}
- radeon_vm_fini(rdev, vm);
kfree(fpriv);
file_priv->driver_priv = NULL;
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit a124d068bf5be6be2ff4b9fab77b1b7509107e68 upstream.
Should be the same as cayman. We don't use VM by default
on NI parts so this isn't critical.
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/radeon_vm.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -753,9 +753,11 @@ static void radeon_vm_frag_ptes(struct r
*/
/* NI is optimized for 256KB fragments, SI and newer for 64KB */
- uint64_t frag_flags = rdev->family == CHIP_CAYMAN ?
+ uint64_t frag_flags = ((rdev->family == CHIP_CAYMAN) ||
+ (rdev->family == CHIP_ARUBA)) ?
R600_PTE_FRAG_256KB : R600_PTE_FRAG_64KB;
- uint64_t frag_align = rdev->family == CHIP_CAYMAN ? 0x200 : 0x80;
+ uint64_t frag_align = ((rdev->family == CHIP_CAYMAN) ||
+ (rdev->family == CHIP_ARUBA)) ? 0x200 : 0x80;
uint64_t frag_start = ALIGN(pe_start, frag_align);
uint64_t frag_end = pe_end & ~(frag_align - 1);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").
There are two major issues with the arm64 /proc/cpuinfo format
currently:
* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.
Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.
* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.
This patch attempts to solve these issues. The following changes are
made:
* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.
The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).
* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.
The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.
* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- Serial
No software has yet been identified for which these remaining
differences are problematic.
Cc: Greg Hackmann <[email protected]>
Cc: Ian Campbell <[email protected]>
Cc: Serban Constantinescu <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Mark Rutland <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm64/kernel/setup.c | 94 ++++++++++++++++++++++++++++++++++------------
1 file changed, 71 insertions(+), 23 deletions(-)
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
#include <linux/efi.h>
+#include <linux/personality.h>
#include <asm/fixmap.h>
#include <asm/cpu.h>
@@ -79,7 +80,6 @@ unsigned int compat_elf_hwcap2 __read_mo
#endif
static const char *cpu_name;
-static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
/*
@@ -311,8 +311,6 @@ static void __init setup_machine_fdt(phy
while (true)
cpu_relax();
}
-
- machine_name = of_flat_dt_get_machine_name();
}
/*
@@ -449,14 +447,50 @@ static const char *hwcap_str[] = {
NULL
};
+#ifdef CONFIG_COMPAT
+static const char *compat_hwcap_str[] = {
+ "swp",
+ "half",
+ "thumb",
+ "26bit",
+ "fastmult",
+ "fpa",
+ "vfp",
+ "edsp",
+ "java",
+ "iwmmxt",
+ "crunch",
+ "thumbee",
+ "neon",
+ "vfpv3",
+ "vfpv3d16",
+ "tls",
+ "vfpv4",
+ "idiva",
+ "idivt",
+ "vfpd32",
+ "lpae",
+ "evtstrm"
+};
+
+static const char *compat_hwcap2_str[] = {
+ "aes",
+ "pmull",
+ "sha1",
+ "sha2",
+ "crc32",
+ NULL
+};
+#endif /* CONFIG_COMPAT */
+
static int c_show(struct seq_file *m, void *v)
{
- int i;
-
- seq_printf(m, "Processor\t: %s rev %d (%s)\n",
- cpu_name, read_cpuid_id() & 15, ELF_PLATFORM);
+ int i, j;
for_each_online_cpu(i) {
+ struct cpuinfo_arm64 *cpuinfo = &per_cpu(cpu_data, i);
+ u32 midr = cpuinfo->reg_midr;
+
/*
* glibc reads /proc/cpuinfo to determine the number of
* online processors, looking for lines beginning with
@@ -465,24 +499,38 @@ static int c_show(struct seq_file *m, vo
#ifdef CONFIG_SMP
seq_printf(m, "processor\t: %d\n", i);
#endif
- }
-
- /* dump out the processor features */
- seq_puts(m, "Features\t: ");
-
- for (i = 0; hwcap_str[i]; i++)
- if (elf_hwcap & (1 << i))
- seq_printf(m, "%s ", hwcap_str[i]);
-
- seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
- seq_printf(m, "CPU architecture: AArch64\n");
- seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15);
- seq_printf(m, "CPU part\t: 0x%03x\n", (read_cpuid_id() >> 4) & 0xfff);
- seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
- seq_puts(m, "\n");
+ /*
+ * Dump out the common processor features in a single line.
+ * Userspace should read the hwcaps with getauxval(AT_HWCAP)
+ * rather than attempting to parse this, but there's a body of
+ * software which does already (at least for 32-bit).
+ */
+ seq_puts(m, "Features\t:");
+ if (personality(current->personality) == PER_LINUX32) {
+#ifdef CONFIG_COMPAT
+ for (j = 0; compat_hwcap_str[j]; j++)
+ if (compat_elf_hwcap & (1 << j))
+ seq_printf(m, " %s", compat_hwcap_str[j]);
+
+ for (j = 0; compat_hwcap2_str[j]; j++)
+ if (compat_elf_hwcap2 & (1 << j))
+ seq_printf(m, " %s", compat_hwcap2_str[j]);
+#endif /* CONFIG_COMPAT */
+ } else {
+ for (j = 0; hwcap_str[j]; j++)
+ if (elf_hwcap & (1 << j))
+ seq_printf(m, " %s", hwcap_str[j]);
+ }
+ seq_puts(m, "\n");
- seq_printf(m, "Hardware\t: %s\n", machine_name);
+ seq_printf(m, "CPU implementer\t: 0x%02x\n",
+ MIDR_IMPLEMENTOR(midr));
+ seq_printf(m, "CPU architecture: 8\n");
+ seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr));
+ seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr));
+ seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr));
+ }
return 0;
}
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: karl beldan <[email protected]>
commit 9ce357795ef208faa0d59894d9d119a7434e37f3 upstream.
Fixed commit added from64to32 under _#ifndef do_csum_ but used it
under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
robot reported TILEGX's). Move from64to32 under the latter.
Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Karl Beldan <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Cc: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/checksum.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -47,15 +47,6 @@ static inline unsigned short from32to16(
return x;
}
-static inline u32 from64to32(u64 x)
-{
- /* add up 32-bit and 32-bit for 32+c bit */
- x = (x & 0xffffffff) + (x >> 32);
- /* add up carry.. */
- x = (x & 0xffffffff) + (x >> 32);
- return (u32)x;
-}
-
static unsigned int do_csum(const unsigned char *buff, int len)
{
int odd;
@@ -190,6 +181,15 @@ csum_partial_copy(const void *src, void
EXPORT_SYMBOL(csum_partial_copy);
#ifndef csum_tcpudp_nofold
+static inline u32 from64to32(u64 x)
+{
+ /* add up 32-bit and 32-bit for 32+c bit */
+ x = (x & 0xffffffff) + (x >> 32);
+ /* add up carry.. */
+ x = (x & 0xffffffff) + (x >> 32);
+ return (u32)x;
+}
+
__wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
unsigned short len,
unsigned short proto,
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bo Shen <[email protected]>
commit a43bd7e125143b875caae6d4f9938855b440faaf upstream.
According to the I2S specification information as following:
- WS = 0, channel 1 (left)
- WS = 1, channel 2 (right)
So, the start event should be TF/RF falling edge.
Reported-by: Songjun Wu <[email protected]>
Signed-off-by: Bo Shen <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/atmel/atmel_ssc_dai.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -345,7 +345,6 @@ static int atmel_ssc_hw_params(struct sn
struct atmel_pcm_dma_params *dma_params;
int dir, channels, bits;
u32 tfmr, rfmr, tcmr, rcmr;
- int start_event;
int ret;
int fslen, fslen_ext;
@@ -454,19 +453,10 @@ static int atmel_ssc_hw_params(struct sn
* The SSC transmit clock is obtained from the BCLK signal on
* on the TK line, and the SSC receive clock is
* generated from the transmit clock.
- *
- * For single channel data, one sample is transferred
- * on the falling edge of the LRC clock.
- * For two channel data, one sample is
- * transferred on both edges of the LRC clock.
*/
- start_event = ((channels == 1)
- ? SSC_START_FALLING_RF
- : SSC_START_EDGE_RF);
-
rcmr = SSC_BF(RCMR_PERIOD, 0)
| SSC_BF(RCMR_STTDLY, START_DELAY)
- | SSC_BF(RCMR_START, start_event)
+ | SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
| SSC_BF(RCMR_CKO, SSC_CKO_NONE)
| SSC_BF(RCMR_CKS, ssc->clk_from_rk_pin ?
@@ -475,14 +465,14 @@ static int atmel_ssc_hw_params(struct sn
rfmr = SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
| SSC_BF(RFMR_FSLEN, 0)
- | SSC_BF(RFMR_DATNB, 0)
+ | SSC_BF(RFMR_DATNB, (channels - 1))
| SSC_BIT(RFMR_MSBF)
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
tcmr = SSC_BF(TCMR_PERIOD, 0)
| SSC_BF(TCMR_STTDLY, START_DELAY)
- | SSC_BF(TCMR_START, start_event)
+ | SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
| SSC_BF(TCMR_CKO, SSC_CKO_NONE)
| SSC_BF(TCMR_CKS, ssc->clk_from_rk_pin ?
@@ -492,7 +482,7 @@ static int atmel_ssc_hw_params(struct sn
| SSC_BF(TFMR_FSDEN, 0)
| SSC_BF(TFMR_FSOS, SSC_FSOS_NONE)
| SSC_BF(TFMR_FSLEN, 0)
- | SSC_BF(TFMR_DATNB, 0)
+ | SSC_BF(TFMR_DATNB, (channels - 1))
| SSC_BIT(TFMR_MSBF)
| SSC_BF(TFMR_DATDEF, 0)
| SSC_BF(TFMR_DATLEN, (bits - 1));
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Nelson <[email protected]>
commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream.
To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted
8 SYS_MCLK cycles after all power rails have been brought
up. After this time, communication can start
...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.
Signed-off-by: Eric Nelson <[email protected]>
Reviewed-by: Fabio Estevam <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/sgtl5000.c | 3 +++
1 file changed, 3 insertions(+)
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -1452,6 +1452,9 @@ static int sgtl5000_i2c_probe(struct i2c
if (ret)
return ret;
+ /* Need 8 clocks before I2C accesses */
+ udelay(1);
+
/* read chip information */
ret = regmap_read(sgtl5000->regmap, SGTL5000_CHIP_ID, ®);
if (ret)
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream.
When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding
this, control the reentrance by introducing a refcount. Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().
The exactly same bug is present in ak4113.c and fixed as well.
Reported-by: Pavel Hofman <[email protected]>
Acked-by: Jaroslav Kysela <[email protected]>
Tested-by: Pavel Hofman <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/sound/ak4113.h | 2 +-
include/sound/ak4114.h | 2 +-
sound/i2c/other/ak4113.c | 17 ++++++++---------
sound/i2c/other/ak4114.c | 18 ++++++++----------
4 files changed, 18 insertions(+), 21 deletions(-)
--- a/include/sound/ak4113.h
+++ b/include/sound/ak4113.h
@@ -286,7 +286,7 @@ struct ak4113 {
ak4113_write_t *write;
ak4113_read_t *read;
void *private_data;
- unsigned int init:1;
+ atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[AK4113_WRITABLE_REGS];
struct snd_kcontrol *kctls[AK4113_CONTROLS];
--- a/include/sound/ak4114.h
+++ b/include/sound/ak4114.h
@@ -168,7 +168,7 @@ struct ak4114 {
ak4114_write_t * write;
ak4114_read_t * read;
void * private_data;
- unsigned int init: 1;
+ atomic_t wq_processing;
spinlock_t lock;
unsigned char regmap[6];
unsigned char txcsb[5];
--- a/sound/i2c/other/ak4113.c
+++ b/sound/i2c/other/ak4113.c
@@ -56,8 +56,7 @@ static inline unsigned char reg_read(str
static void snd_ak4113_free(struct ak4113 *chip)
{
- chip->init = 1; /* don't schedule new work */
- mb();
+ atomic_inc(&chip->wq_processing); /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
}
@@ -89,6 +88,7 @@ int snd_ak4113_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4113_stats);
+ atomic_set(&chip->wq_processing, 0);
for (reg = 0; reg < AK4113_WRITABLE_REGS ; reg++)
chip->regmap[reg] = pgm[reg];
@@ -139,13 +139,11 @@ static void ak4113_init_regs(struct ak41
void snd_ak4113_reinit(struct ak4113 *chip)
{
- chip->init = 1;
- mb();
- flush_delayed_work(&chip->work);
+ if (atomic_inc_return(&chip->wq_processing) == 1)
+ cancel_delayed_work_sync(&chip->work);
ak4113_init_regs(chip);
/* bring up statistics / event queing */
- chip->init = 0;
- if (chip->kctls[0])
+ if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
}
EXPORT_SYMBOL_GPL(snd_ak4113_reinit);
@@ -632,8 +630,9 @@ static void ak4113_stats(struct work_str
{
struct ak4113 *chip = container_of(work, struct ak4113, work.work);
- if (!chip->init)
+ if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4113_check_rate_and_errors(chip, chip->check_flags);
- schedule_delayed_work(&chip->work, HZ / 10);
+ if (atomic_dec_and_test(&chip->wq_processing))
+ schedule_delayed_work(&chip->work, HZ / 10);
}
--- a/sound/i2c/other/ak4114.c
+++ b/sound/i2c/other/ak4114.c
@@ -66,8 +66,7 @@ static void reg_dump(struct ak4114 *ak41
static void snd_ak4114_free(struct ak4114 *chip)
{
- chip->init = 1; /* don't schedule new work */
- mb();
+ atomic_inc(&chip->wq_processing); /* don't schedule new work */
cancel_delayed_work_sync(&chip->work);
kfree(chip);
}
@@ -100,6 +99,7 @@ int snd_ak4114_create(struct snd_card *c
chip->write = write;
chip->private_data = private_data;
INIT_DELAYED_WORK(&chip->work, ak4114_stats);
+ atomic_set(&chip->wq_processing, 0);
for (reg = 0; reg < 6; reg++)
chip->regmap[reg] = pgm[reg];
@@ -152,13 +152,11 @@ static void ak4114_init_regs(struct ak41
void snd_ak4114_reinit(struct ak4114 *chip)
{
- chip->init = 1;
- mb();
- flush_delayed_work(&chip->work);
+ if (atomic_inc_return(&chip->wq_processing) == 1)
+ cancel_delayed_work_sync(&chip->work);
ak4114_init_regs(chip);
/* bring up statistics / event queing */
- chip->init = 0;
- if (chip->kctls[0])
+ if (atomic_dec_and_test(&chip->wq_processing))
schedule_delayed_work(&chip->work, HZ / 10);
}
@@ -612,10 +610,10 @@ static void ak4114_stats(struct work_str
{
struct ak4114 *chip = container_of(work, struct ak4114, work.work);
- if (!chip->init)
+ if (atomic_inc_return(&chip->wq_processing) == 1)
snd_ak4114_check_rate_and_errors(chip, chip->check_flags);
-
- schedule_delayed_work(&chip->work, HZ / 10);
+ if (atomic_dec_and_test(&chip->wq_processing))
+ schedule_delayed_work(&chip->work, HZ / 10);
}
EXPORT_SYMBOL(snd_ak4114_create);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sylwester Nawrocki <[email protected]>
commit fddcd300732dad5b822d27de7aa78998dca43162 upstream.
I2S1, I2S2 on Exynos4 SoC series have limited functionality compared
to I2S0, "samsung,s3c6410-i2s" compatible should be used for them.
Signed-off-by: Sylwester Nawrocki <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/exynos4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -368,7 +368,7 @@
};
i2s1: i2s@13960000 {
- compatible = "samsung,s5pv210-i2s";
+ compatible = "samsung,s3c6410-i2s";
reg = <0x13960000 0x100>;
clocks = <&clock CLK_I2S1>;
clock-names = "iis";
@@ -378,7 +378,7 @@
};
i2s2: i2s@13970000 {
- compatible = "samsung,s5pv210-i2s";
+ compatible = "samsung,s3c6410-i2s";
reg = <0x13970000 0x100>;
clocks = <&clock CLK_I2S2>;
clock-names = "iis";
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky <[email protected]>
commit da63865a01c6384d459464e5165d95d4f04878d8 upstream.
Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and
a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
paravirt") allow microcode driver skip initialization when microcode
loading is not permitted.
However, they don't prevent the driver from being loaded since the
init code returns 0. If at some point later the driver gets unloaded
this will result in an oops while trying to deregister the (never
registered) device.
To avoid this, make init code return an error on paravirt or when
microcode loading is disabled. The driver will then never be loaded.
Signed-off-by: Boris Ostrovsky <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Reported-by: James Digwall <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/cpu/microcode/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -552,7 +552,7 @@ static int __init microcode_init(void)
int error;
if (paravirt_enabled() || dis_ucode_ldr)
- return 0;
+ return -EINVAL;
if (c->x86_vendor == X86_VENDOR_INTEL)
microcode_ops = init_intel_microcode();
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lai Jiangshan <[email protected]>
commit 4bee96860a65c3a62d332edac331b3cf936ba3ad upstream.
The following race exists in the smpboot percpu threads management:
CPU0 CPU1
cpu_up(2)
get_online_cpus();
smpboot_create_threads(2);
smpboot_register_percpu_thread();
for_each_online_cpu();
__smpboot_create_thread();
__cpu_up(2);
This results in a missing per cpu thread for the newly onlined cpu2 and
in a NULL pointer dereference on a consecutive offline of that cpu.
Proctect smpboot_register_percpu_thread() with get_online_cpus() to
prevent that.
[ tglx: Massaged changelog and removed the change in
smpboot_unregister_percpu_thread() because that's an
optimization and therefor not stable material. ]
Signed-off-by: Lai Jiangshan <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Srivatsa S. Bhat <[email protected]>
Cc: David Rientjes <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -279,6 +279,7 @@ int smpboot_register_percpu_thread(struc
unsigned int cpu;
int ret = 0;
+ get_online_cpus();
mutex_lock(&smpboot_threads_lock);
for_each_online_cpu(cpu) {
ret = __smpboot_create_thread(plug_thread, cpu);
@@ -291,6 +292,7 @@ int smpboot_register_percpu_thread(struc
list_add(&plug_thread->list, &hotplug_threads);
out:
mutex_unlock(&smpboot_threads_lock);
+ put_online_cpus();
return ret;
}
EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: John Stultz <[email protected]>
commit 2d926c15d629a13914ce3e5f26354f6a0ac99e70 upstream.
I noticed some CLOCK_TAI timer test failures on one of my
less-frequently used configurations. And after digging in I
found in 76f4108892d9 (Cleanup hrtimer accessors to the
timekepeing state), the hrtimer_get_softirq_time tai offset
calucation was incorrectly rewritten, as the tai offset we
return shold be from CLOCK_MONOTONIC, and not CLOCK_REALTIME.
This results in CLOCK_TAI timers expiring early on non-highres
capable machines.
This patch fixes the issue, calculating the tai time properly
from the monotonic base.
Signed-off-by: John Stultz <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -122,7 +122,7 @@ static void hrtimer_get_softirq_time(str
mono = ktime_get_update_offsets_tick(&off_real, &off_boot, &off_tai);
boot = ktime_add(mono, off_boot);
xtim = ktime_add(mono, off_real);
- tai = ktime_add(xtim, off_tai);
+ tai = ktime_add(mono, off_tai);
base->clock_base[HRTIMER_BASE_REALTIME].softirq_time = xtim;
base->clock_base[HRTIMER_BASE_MONOTONIC].softirq_time = mono;
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <[email protected]>
commit a05d59a5673339ef6936d6940cdf68172ce75b9f upstream.
The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
When a CPU is offline, RCU is no longer watching that CPU and since the
tracepoint is protected by RCU, it must not be called. To prevent the
tlb_flush tracepoint from being called when the CPU is offline, it was
converted to a TRACE_EVENT_CONDITION where the condition checks if the
CPU is online before calling the tracepoint.
Unfortunately, this was not enough to stop lockdep from complaining about
it. Even though the RCU protected code of the tracepoint will never be
called, the condition is hidden within the tracepoint, and even though the
condition prevents RCU code from being called, the lockdep checks are
outside the tracepoint (this is to test tracepoints even when they are not
enabled).
Even though tracepoints should be checked to be RCU safe when they are not
enabled, the condition should still be considered when checking RCU.
Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com
Fixes: 3a630178fd5f "tracing: generate RCU warnings even when tracepoints are disabled"
Acked-by: Dave Hansen <[email protected]>
Reported-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index e08e21e5f601..c72851328ca9 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -173,7 +173,7 @@ extern void syscall_unregfunc(void);
TP_PROTO(data_proto), \
TP_ARGS(data_args), \
TP_CONDITION(cond),,); \
- if (IS_ENABLED(CONFIG_LOCKDEP)) { \
+ if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \
rcu_read_lock_sched_notrace(); \
rcu_dereference_sched(__tracepoint_##name.funcs);\
rcu_read_unlock_sched_notrace(); \
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <[email protected]>
commit 6c8465a82a605bc692304bab42703017dcfff013 upstream.
When taking a CPU down for suspend and resume, a tracepoint may be called
when the CPU has been designated offline. As tracepoints require RCU for
protection, they must not be called if the current CPU is offline.
Unfortunately, trace_tlb_flush() is called in this scenario as was noted
by LOCKDEP:
...
Disabling non-boot CPUs ...
intel_pstate CPU 1 exiting
===============================
smpboot: CPU 1 didn't die...
[ INFO: suspicious RCU usage. ]
3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
-------------------------------
include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 0
no locks held by swapper/1/0.
stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011
ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600
0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78
Call Trace:
[<ffffffff817e370d>] dump_stack+0x4c/0x65
[<ffffffff810d6847>] lockdep_rcu_suspicious+0xe7/0x120
[<ffffffff810b71a5>] idle_task_exit+0x205/0x2c0
[<ffffffff81054c4e>] play_dead_common+0xe/0x50
[<ffffffff81054ca5>] native_play_dead+0x15/0x140
[<ffffffff8102963f>] arch_cpu_idle_dead+0xf/0x20
[<ffffffff810cd89e>] cpu_startup_entry+0x37e/0x580
[<ffffffff81053e20>] start_secondary+0x140/0x150
intel_pstate CPU 2 exiting
...
By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected
code when the CPU is offline.
Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com
Fixes: d17d8f9dedb9 "x86/mm: Add tracepoints for TLB flushes"
Reported-by: Sedat Dilek <[email protected]>
Tested-by: Sedat Dilek <[email protected]>
Suggested-by: Paul E. McKenney <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Dave Hansen <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
diff --git a/include/trace/events/tlb.h b/include/trace/events/tlb.h
index 13391d288107..0e7635765153 100644
--- a/include/trace/events/tlb.h
+++ b/include/trace/events/tlb.h
@@ -13,11 +13,13 @@
{ TLB_LOCAL_SHOOTDOWN, "local shootdown" }, \
{ TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" }
-TRACE_EVENT(tlb_flush,
+TRACE_EVENT_CONDITION(tlb_flush,
TP_PROTO(int reason, unsigned long pages),
TP_ARGS(reason, pages),
+ TP_CONDITION(cpu_online(smp_processor_id())),
+
TP_STRUCT__entry(
__field( int, reason)
__field(unsigned long, pages)
Hi Greg,
nice to see the kbuild and trace patches I was involved are in this series.
Unfortunately, I see the following in my logs...
[ 2.117022] Request for unknown module key 'Magrathea: Glacier
signing key: 009aa341bb673735a51dc34b238a0ca481d68098' err -11
[ 2.117114] mii: module verification failed: signature and/or
required key missing - tainting kernel
Not sure whom to CC.
I CCed Jeff as he worked on MII.
Signing key ---> Dave Howells?
Attached are my kernel-config and dmesg output.
Hope this helps.
BTW, with v3.18.6 I haven't seen such output.
Regards,
- Sedat -
On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote:
> Hi Greg,
>
> nice to see the kbuild and trace patches I was involved are in this series.
>
> Unfortunately, I see the following in my logs...
>
> [ 2.117022] Request for unknown module key 'Magrathea: Glacier
> signing key: 009aa341bb673735a51dc34b238a0ca481d68098' err -11
> [ 2.117114] mii: module verification failed: signature and/or
> required key missing - tainting kernel
>
> Not sure whom to CC.
> I CCed Jeff as he worked on MII.
> Signing key ---> Dave Howells?
>
> Attached are my kernel-config and dmesg output.
>
> Hope this helps.
>
> BTW, with v3.18.6 I haven't seen such output.
Any way you could take the patches at
https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/
in the queue-3.18 directory and bisect them to see which patch causes
the problem? I don't see any obvious patch in this series that would be
the issue.
thanks,
greg k-h
On Mon, Feb 9, 2015 at 4:44 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote:
>> Hi Greg,
>>
>> nice to see the kbuild and trace patches I was involved are in this series.
>>
>> Unfortunately, I see the following in my logs...
>>
>> [ 2.117022] Request for unknown module key 'Magrathea: Glacier
>> signing key: 009aa341bb673735a51dc34b238a0ca481d68098' err -11
>> [ 2.117114] mii: module verification failed: signature and/or
>> required key missing - tainting kernel
>>
>> Not sure whom to CC.
>> I CCed Jeff as he worked on MII.
>> Signing key ---> Dave Howells?
>>
>> Attached are my kernel-config and dmesg output.
>>
>> Hope this helps.
>>
>> BTW, with v3.18.6 I haven't seen such output.
>
> Any way you could take the patches at
> https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/
> in the queue-3.18 directory and bisect them to see which patch causes
> the problem? I don't see any obvious patch in this series that would be
> the issue.
>
[ CC Dave Howells ]
Unfortunately, I make-distclean-ed my build-dir.
Is simply the sign-key missing?
> mii: module verification failed: signature and/or required key missing <
Documentation/module-signing.txt lists Magrathea, so I CCed Dave.
Let's see what he says before doing a git-bisect session.
I wanted to trough out the complete module-signing kernel-options for
a long time.
For test kernels it is simply not needed here.
Sorry, for resending my files - build-log is attached as a new file.
Hope this helps.
BTW, why is there no MII maintainer listed in MAINTAINERS?
( No clue what MII has to do with module-signing, can someone explain? )
- Sedat -
P.S.: Check the logs for mii and x509 patterns.
$ egrep 'mii|x509' build-log_3.18.7-rc1-1-iniza-small.txt
ASN.1 crypto/asymmetric_keys/x509-asn1.c
ASN.1 crypto/asymmetric_keys/x509_rsakey-asn1.c
CC crypto/asymmetric_keys/x509_public_key.o
CC crypto/asymmetric_keys/x509-asn1.o
CC crypto/asymmetric_keys/x509_rsakey-asn1.o
CC crypto/asymmetric_keys/x509_cert_parser.o
LD crypto/asymmetric_keys/x509_key_parser.o
-batch -x509 -config x509.genkey \
-outform DER -out signing_key.x509 \
CERTS kernel/x509_certificate_list
- Including cert ./signing_key.x509
CC [M] drivers/net/mii.o
CC drivers/net/mii.mod.o
LD [M] drivers/net/mii.ko
INSTALL drivers/net/mii.ko
- EOT -
On Mon, Feb 9, 2015 at 4:58 PM, Sedat Dilek <[email protected]> wrote:
> On Mon, Feb 9, 2015 at 4:44 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
>> On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote:
>>> Hi Greg,
>>>
>>> nice to see the kbuild and trace patches I was involved are in this series.
>>>
>>> Unfortunately, I see the following in my logs...
>>>
>>> [ 2.117022] Request for unknown module key 'Magrathea: Glacier
>>> signing key: 009aa341bb673735a51dc34b238a0ca481d68098' err -11
>>> [ 2.117114] mii: module verification failed: signature and/or
>>> required key missing - tainting kernel
>>>
>>> Not sure whom to CC.
>>> I CCed Jeff as he worked on MII.
>>> Signing key ---> Dave Howells?
>>>
>>> Attached are my kernel-config and dmesg output.
>>>
>>> Hope this helps.
>>>
>>> BTW, with v3.18.6 I haven't seen such output.
>>
>> Any way you could take the patches at
>> https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/
>> in the queue-3.18 directory and bisect them to see which patch causes
>> the problem? I don't see any obvious patch in this series that would be
>> the issue.
>>
>
> [ CC Dave Howells ]
>
> Unfortunately, I make-distclean-ed my build-dir.
>
> Is simply the sign-key missing?
>
>> mii: module verification failed: signature and/or required key missing <
>
To name it's called "x509.genkey".
>From [1]:
[ QUOTE ]
Most notably, in the x509.genkey file, the req_distinguished_name section
should be altered from the default:
[ req_distinguished_name ]
O = Magrathea
CN = Glacier signing key
emailAddress = [email protected]
[ /QUOTE ]
- Sedat -
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/module-signing.txt#n118
> Documentation/module-signing.txt lists Magrathea, so I CCed Dave.
> Let's see what he says before doing a git-bisect session.
>
> I wanted to trough out the complete module-signing kernel-options for
> a long time.
> For test kernels it is simply not needed here.
>
> Sorry, for resending my files - build-log is attached as a new file.
>
> Hope this helps.
>
> BTW, why is there no MII maintainer listed in MAINTAINERS?
>
> ( No clue what MII has to do with module-signing, can someone explain? )
>
> - Sedat -
>
> P.S.: Check the logs for mii and x509 patterns.
>
> $ egrep 'mii|x509' build-log_3.18.7-rc1-1-iniza-small.txt
> ASN.1 crypto/asymmetric_keys/x509-asn1.c
> ASN.1 crypto/asymmetric_keys/x509_rsakey-asn1.c
> CC crypto/asymmetric_keys/x509_public_key.o
> CC crypto/asymmetric_keys/x509-asn1.o
> CC crypto/asymmetric_keys/x509_rsakey-asn1.o
> CC crypto/asymmetric_keys/x509_cert_parser.o
> LD crypto/asymmetric_keys/x509_key_parser.o
> -batch -x509 -config x509.genkey \
> -outform DER -out signing_key.x509 \
> CERTS kernel/x509_certificate_list
> - Including cert ./signing_key.x509
> CC [M] drivers/net/mii.o
> CC drivers/net/mii.mod.o
> LD [M] drivers/net/mii.ko
> INSTALL drivers/net/mii.ko
>
> - EOT -
On Mon, Feb 09, 2015 at 04:33:43PM +0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.7 release.
> There are 39 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 Feb 11 08:33:11 UTC 2015.
> Anything received after that time might be too late.
>
Build results:
total: 121 pass: 121 fail: 0
Qemu tests:
total: 30 pass: 30 fail: 0
Details are available at http://server.roeck-us.net:8010/builders.
Guenter
On 02/09/2015 01:33 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.7 release.
> There are 39 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 Feb 11 08:33:11 UTC 2015.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system.
I am seeing the following mei_me messages:
mei_me 0000:00:16.0: version message write failed: ret = -5
mei_me 0000:00:16.0: hbm_start failed ret = -5
mei_me 0000:00:16.0: version message write failed: ret = -5
mei_me 0000:00:16.0: hbm_start failed ret = -5
Not concerned - maybe Alexander Usyskin and Tomas Winkler
can take a look and see if this looks ok.
Could this be related to:
mei: clean reset bit before reset
commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
On Mon, Feb 09, 2015 at 11:27:10AM -0700, Shuah Khan wrote:
> On 02/09/2015 01:33 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.7 release.
> > There are 39 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 Feb 11 08:33:11 UTC 2015.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system.
>
> I am seeing the following mei_me messages:
>
> mei_me 0000:00:16.0: version message write failed: ret = -5
> mei_me 0000:00:16.0: hbm_start failed ret = -5
> mei_me 0000:00:16.0: version message write failed: ret = -5
> mei_me 0000:00:16.0: hbm_start failed ret = -5
>
> Not concerned - maybe Alexander Usyskin and Tomas Winkler
> can take a look and see if this looks ok.
>
> Could this be related to:
>
> mei: clean reset bit before reset
>
> commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.
Odd, I wouldn't think that this commit would cause those errors to show
up, if so, that's not good.
Alexander, any thoughts?
thanks,
greg k-h
On Tue, Feb 10, 2015 at 05:37:36AM +0800, Greg Kroah-Hartman wrote:
> On Mon, Feb 09, 2015 at 11:27:10AM -0700, Shuah Khan wrote:
> > On 02/09/2015 01:33 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 3.18.7 release.
> > > There are 39 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 Feb 11 08:33:11 UTC 2015.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > Compiled and booted on my test system.
> >
> > I am seeing the following mei_me messages:
> >
> > mei_me 0000:00:16.0: version message write failed: ret = -5
> > mei_me 0000:00:16.0: hbm_start failed ret = -5
> > mei_me 0000:00:16.0: version message write failed: ret = -5
> > mei_me 0000:00:16.0: hbm_start failed ret = -5
> >
> > Not concerned - maybe Alexander Usyskin and Tomas Winkler
> > can take a look and see if this looks ok.
> >
> > Could this be related to:
> >
> > mei: clean reset bit before reset
> >
> > commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.
>
> Odd, I wouldn't think that this commit would cause those errors to show
> up, if so, that's not good.
>
> Alexander, any thoughts?
>
mei_hbm_reset() is called just before the above message. Maybe the reset is not
complete ? The comment associated with the commit suggests that this can happen.
If so, there should also be warning "H_RST is set = 0x%08X" in the log.
Guenter
>
> On Tue, Feb 10, 2015 at 05:37:36AM +0800, Greg Kroah-Hartman wrote:
> > On Mon, Feb 09, 2015 at 11:27:10AM -0700, Shuah Khan wrote:
> > > On 02/09/2015 01:33 AM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 3.18.7 release.
> > > > There are 39 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 Feb 11 08:33:11 UTC 2015.
> > > > Anything received after that time might be too late.
> > > >
> > > > The whole patch series can be found in one patch at:
> > > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > >
> > > Compiled and booted on my test system.
> > >
> > > I am seeing the following mei_me messages:
> > >
> > > mei_me 0000:00:16.0: version message write failed: ret = -5
> > > mei_me 0000:00:16.0: hbm_start failed ret = -5
> > > mei_me 0000:00:16.0: version message write failed: ret = -5
> > > mei_me 0000:00:16.0: hbm_start failed ret = -5
> > >
> > > Not concerned - maybe Alexander Usyskin and Tomas Winkler
> > > can take a look and see if this looks ok.
> > >
> > > Could this be related to:
> > >
> > > mei: clean reset bit before reset
> > >
> > > commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.
> >
> > Odd, I wouldn't think that this commit would cause those errors to show
> > up, if so, that's not good.
> >
> > Alexander, any thoughts?
> >
> mei_hbm_reset() is called just before the above message. Maybe the reset is not
> complete ? The comment associated with the commit suggests that this can
> happen.
> If so, there should also be warning "H_RST is set = 0x%08X" in the log.
Can you please provide details of your system + lspci -vn output
The complete log would helpful and if you can enable dynamic debug on mei and mei_me modules it would be the best.
Thanks
Tomas
On 02/09/2015 03:24 PM, Winkler, Tomas wrote:
>
>
>>
>> On Tue, Feb 10, 2015 at 05:37:36AM +0800, Greg Kroah-Hartman wrote:
>>> On Mon, Feb 09, 2015 at 11:27:10AM -0700, Shuah Khan wrote:
>>>> On 02/09/2015 01:33 AM, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 3.18.7 release.
>>>>> There are 39 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 Feb 11 08:33:11 UTC 2015.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.7-rc1.gz
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>
>>>> Compiled and booted on my test system.
>>>>
>>>> I am seeing the following mei_me messages:
>>>>
>>>> mei_me 0000:00:16.0: version message write failed: ret = -5
>>>> mei_me 0000:00:16.0: hbm_start failed ret = -5
>>>> mei_me 0000:00:16.0: version message write failed: ret = -5
>>>> mei_me 0000:00:16.0: hbm_start failed ret = -5
>>>>
>>>> Not concerned - maybe Alexander Usyskin and Tomas Winkler
>>>> can take a look and see if this looks ok.
>>>>
>>>> Could this be related to:
>>>>
>>>> mei: clean reset bit before reset
>>>>
>>>> commit b13a65ef190e488e2761d65bdd2e1fe8a3a125f5 upstream.
>>>
>>> Odd, I wouldn't think that this commit would cause those errors to show
>>> up, if so, that's not good.
>>>
>>> Alexander, any thoughts?
>>>
>> mei_hbm_reset() is called just before the above message. Maybe the reset is not
>> complete ? The comment associated with the commit suggests that this can
>> happen.
>> If so, there should also be warning "H_RST is set = 0x%08X" in the log.
>
> Can you please provide details of your system + lspci -vn output
> The complete log would helpful and if you can enable dynamic debug on mei and mei_me modules it would be the best.
>
> Thanks
> Tomas
>
Hi Tomas,
Please see attached dmidecode output, the original dmesg from when
I saw the problem, and dmesg after enabling dynamic debug on mei.
I can't reproduce the problem with dynamic debug enabled, tried a
couple of reboots.
Please let me know you need more information.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
On Mon, Feb 9, 2015 at 5:02 PM, Sedat Dilek <[email protected]> wrote:
> On Mon, Feb 9, 2015 at 4:58 PM, Sedat Dilek <[email protected]> wrote:
>> On Mon, Feb 9, 2015 at 4:44 PM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>>> On Mon, Feb 09, 2015 at 04:35:53PM +0100, Sedat Dilek wrote:
>>>> Hi Greg,
>>>>
>>>> nice to see the kbuild and trace patches I was involved are in this series.
>>>>
>>>> Unfortunately, I see the following in my logs...
>>>>
>>>> [ 2.117022] Request for unknown module key 'Magrathea: Glacier
>>>> signing key: 009aa341bb673735a51dc34b238a0ca481d68098' err -11
>>>> [ 2.117114] mii: module verification failed: signature and/or
>>>> required key missing - tainting kernel
>>>>
>>>> Not sure whom to CC.
>>>> I CCed Jeff as he worked on MII.
>>>> Signing key ---> Dave Howells?
>>>>
>>>> Attached are my kernel-config and dmesg output.
>>>>
>>>> Hope this helps.
>>>>
>>>> BTW, with v3.18.6 I haven't seen such output.
>>>
>>> Any way you could take the patches at
>>> https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/
>>> in the queue-3.18 directory and bisect them to see which patch causes
>>> the problem? I don't see any obvious patch in this series that would be
>>> the issue.
>>>
>>
>> [ CC Dave Howells ]
>>
>> Unfortunately, I make-distclean-ed my build-dir.
>>
>> Is simply the sign-key missing?
>>
>>> mii: module verification failed: signature and/or required key missing <
>>
>
> To name it's called "x509.genkey".
>
> From [1]:
>
> [ QUOTE ]
>
> Most notably, in the x509.genkey file, the req_distinguished_name section
> should be altered from the default:
>
> [ req_distinguished_name ]
> O = Magrathea
> CN = Glacier signing key
> emailAddress = [email protected]
>
> [ /QUOTE ]
>
> - Sedat -
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/module-signing.txt#n118
>
>
>> Documentation/module-signing.txt lists Magrathea, so I CCed Dave.
>> Let's see what he says before doing a git-bisect session.
>>
>> I wanted to trough out the complete module-signing kernel-options for
>> a long time.
>> For test kernels it is simply not needed here.
>>
>> Sorry, for resending my files - build-log is attached as a new file.
>>
>> Hope this helps.
>>
>> BTW, why is there no MII maintainer listed in MAINTAINERS?
>>
>> ( No clue what MII has to do with module-signing, can someone explain? )
>>
>> - Sedat -
>>
>> P.S.: Check the logs for mii and x509 patterns.
>>
>> $ egrep 'mii|x509' build-log_3.18.7-rc1-1-iniza-small.txt
>> ASN.1 crypto/asymmetric_keys/x509-asn1.c
>> ASN.1 crypto/asymmetric_keys/x509_rsakey-asn1.c
>> CC crypto/asymmetric_keys/x509_public_key.o
>> CC crypto/asymmetric_keys/x509-asn1.o
>> CC crypto/asymmetric_keys/x509_rsakey-asn1.o
>> CC crypto/asymmetric_keys/x509_cert_parser.o
>> LD crypto/asymmetric_keys/x509_key_parser.o
>> -batch -x509 -config x509.genkey \
>> -outform DER -out signing_key.x509 \
>> CERTS kernel/x509_certificate_list
>> - Including cert ./signing_key.x509
>> CC [M] drivers/net/mii.o
>> CC drivers/net/mii.mod.o
>> LD [M] drivers/net/mii.ko
>> INSTALL drivers/net/mii.ko
>>
>> - EOT -
I have rebuilt a -2 kernel and take care that the x509 files are shipped...
$ LC_ALL=C ll x509-files_3.18.7-rc1-2-iniza-small/*x509*
-rw-r--r-- 1 wearefam wearefam 1446 Feb 10 08:02
x509-files_3.18.7-rc1-2-iniza-small/signing_key.x509
-rw-r--r-- 1 wearefam wearefam 372 Feb 10 08:01
x509-files_3.18.7-rc1-2-iniza-small/x509.genkey
...and the warnings are gone.
So, indeed these files were missing or one of them.
- Sedat -