On Wed, Feb 28, 2018 at 1:12 PM, Olof's autobuilder <build(a)lixom.net> wrote:
> Here are the build results from automated periodic testing.
> Warnings:
>
> arm64.allmodconfig:
> WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/qualcomm/phy-qcom-ufs.o
Hi Greg,
It seems we're still missing one backport for a clean allmodconfig build:
59fba0869aca phy: qcom-ufs: add MODULE_LICENSE tag
Arnd
Dear Greg,
a fix for a voltage instability on our rk3399-puma board went into 4.15
(commit 87eba0716011, quoted below). As we have users who prefer to stay
on longterm 4.14, would you consider cherry-picking the commit into
4.14.y? It applies cleanly and has no effect outside of our rk3399-puma
board, where it fixes the instability.
Thank you and best regards,
Jakob
> commit 87eba0716011e528f7841026f2cc65683219d0ad
> Author: Klaus Goger <klaus.goger(a)theobroma-systems.com>
> Date: Tue Dec 5 08:11:58 2017 +0100
>
> arm64: dts: rockchip: remove vdd_log from rk3399-puma
>
> vdd_log has no consumer and therefore will not be set to a specific
> voltage. Still the PWM output pin gets configured and thence the vdd_log
> output voltage will changed from it's default. Depending on the idle
> state of the PWM this will slightly over or undervoltage the logic supply
> of the RK3399 and cause instability with GbE (undervoltage) and PCIe
> (overvoltage). Since the default value set by a voltage divider is the
> correct supply voltage and we don't need to change it during runtime we
> remove the rail from the devicetree completely so the PWM pin will not
> be configured.
>
> Signed-off-by: Klaus Goger <klaus.goger(a)theobroma-systems.com>
> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
>
> arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 11 -----------
> 1 file changed, 11 deletions(-)
From: Robert Kolchmeyer <rkolchmeyer(a)google.com>
BugLink: http://bugs.launchpad.net/bugs/1765564
fsnotify() acquires a reference to a fsnotify_mark_connector through
the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
appears that no precautions are taken in fsnotify_put_mark() to
ensure that fsnotify() drops its reference to this
fsnotify_mark_connector before assigning a value to its 'destroy_next'
field. This can result in fsnotify_put_mark() assigning a value
to a connector's 'destroy_next' field right before fsnotify() tries to
traverse the linked list referenced by the connector's 'list' field.
Since these two fields are members of the same union, this behavior
results in a kernel panic.
This issue is resolved by moving the connector's 'destroy_next' field
into the object pointer union. This should work since the object pointer
access is protected by both a spinlock and the value of the 'flags'
field, and the 'flags' field is cleared while holding the spinlock in
fsnotify_put_mark() before 'destroy_next' is updated. It shouldn't be
possible for another thread to accidentally read from the object pointer
after the 'destroy_next' field is updated.
The offending behavior here is extremely unlikely; since
fsnotify_put_mark() removes references to a connector (specifically,
it ensures that the connector is unreachable from the inode it was
formerly attached to) before updating its 'destroy_next' field, a
sizeable chunk of code in fsnotify_put_mark() has to execute in the
short window between when fsnotify() acquires the connector reference
and saves the value of its 'list' field. On the HEAD kernel, I've only
been able to reproduce this by inserting a udelay(1) in fsnotify().
However, I've been able to reproduce this issue without inserting a
udelay(1) anywhere on older unmodified release kernels, so I believe
it's worth fixing at HEAD.
References: https://bugzilla.kernel.org/show_bug.cgi?id=199437
Fixes: 08991e83b7286635167bab40927665a90fb00d81
CC: stable(a)vger.kernel.org
Signed-off-by: Robert Kolchmeyer <rkolchmeyer(a)google.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
(cherry picked from commit d90a10e2444ba5a351fa695917258ff4c5709fa5)
Signed-off-by: Seyeong Kim <seyeong.kim(a)canonical.com>
---
include/linux/fsnotify_backend.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index 067d52e..d719194 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -217,12 +217,10 @@ struct fsnotify_mark_connector {
union { /* Object pointer [lock] */
struct inode *inode;
struct vfsmount *mnt;
- };
- union {
- struct hlist_head list;
/* Used listing heads to free after srcu period expires */
struct fsnotify_mark_connector *destroy_next;
};
+ struct hlist_head list;
};
/*
--
2.7.4
From: Sean Wang <sean.wang(a)mediatek.com>
Recently kernelCI reported the board mt7622-rfb1 has a fail test with
kernel: ERROR: did not start booting whose details could be seen at [1].
The cause is that UART0 can't output anything when it's missing a proper
pin setup with current DTS, so the essential driver is always getting
enabled to fix up the issue.
[1] https://kernelci.org/boot/id/5ad7d62759b51461bfb1f829/
Cc: Kevin Hilman <khilman(a)baylibre.com>
Cc: stable(a)vger.kernel.org
Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..fe005df 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -320,6 +320,7 @@ CONFIG_PINCTRL_MAX77620=y
CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_MSM8994=y
CONFIG_PINCTRL_MSM8996=y
+CONFIG_PINCTRL_MT7622=y
CONFIG_PINCTRL_QDF2XXX=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_GPIO_DWAPB=y
--
2.7.4
Hi Greg,
Upstream commit 821cdad5c46c ("PCI: Wait up to 60 seconds for
device to become ready after FLR") fixes a virtualization issue
for Intel 750 NVMe drive and potentially other PCIe devices taking
longer to recover from functional resets.
problem description below from the commit:
'Sporadic reset issues have been observed with an Intel 750 NVMe drive while
assigning the physical function to the guest machine. The sequence of
events observed is as follows:
- perform a Function Level Reset (FLR)
- sleep up to 1000ms total
- read ~0 from PCI_COMMAND (CRS completion for config read)
- warn that the device didn't return from FLR
- touch the device before it's ready
- device drops config writes when we restore register settings (there's
no mechanism for software to learn about CRS completions for writes)
- incomplete register restore leaves device in inconsistent state
- device probe fails because device is in inconsistent state
After reset, an endpoint may respond to config requests with Configuration
Request Retry Status (CRS) to indicate that it is not ready to accept new
requests. See PCIe r3.1, sec 2.3.1 and 6.6.2.'
Please apply commit 821cdad5c46c to fix the resulting regression.
Thanks,
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Memory hotplug, and hotremove operate with per-block granularity. If
machine has large amount of memory (more than 64G), the size of memory
block can span multiple sections. By mistake, during hotremove we set
only the first section to offline state.
The bug was discovered because kernel selftest started to fail:
https://lkml.kernel.org/r/20180423011247.GK5563@yexl-desktop
After commit, "mm/memory_hotplug: optimize probe routine". But, the bug is
older than this commit. In this optimization we also added a check for
sections to be in a proper state during hotplug operation.
Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes")
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
---
mm/sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 62eef264a7bd..73dc2fcc0eab 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -629,7 +629,7 @@ void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
unsigned long pfn;
for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
- unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ unsigned long section_nr = pfn_to_section_nr(pfn);
struct mem_section *ms;
/*
--
2.17.0