* [PATCH 4.4 01/43] MIPS: ralink: Remove ralink_halt()
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 02/43] iio: st_pressure: st_accel: pass correct platform data to init Greg Kroah-Hartman
` (47 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, NeilBrown, John Crispin,
Ralf Baechle, linux-mips, James Hogan
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <neil@brown.name>
commit 891731f6a5dbe508d12443175a7e166a2fba616a upstream.
ralink_halt() does nothing that machine_halt() doesn't already do, so it
adds no value.
It actually causes incorrect behaviour due to the "unreachable()" at the
end. This tells the compiler that the end of the function will never be
reached, which isn't true. The compiler responds by not adding a
'return' instruction, so control simply moves on to whatever bytes come
afterwards in memory. In my tested, that was the ralink_restart()
function. This means that an attempt to 'halt' the machine would
actually cause a reboot.
So remove ralink_halt() so that a 'halt' really does halt.
Fixes: c06e836ada59 ("MIPS: ralink: adds reset code")
Signed-off-by: NeilBrown <neil@brown.name>
Cc: John Crispin <john@phrozen.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.9+
Patchwork: https://patchwork.linux-mips.org/patch/18851/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/ralink/reset.c | 7 -------
1 file changed, 7 deletions(-)
--- a/arch/mips/ralink/reset.c
+++ b/arch/mips/ralink/reset.c
@@ -96,16 +96,9 @@ static void ralink_restart(char *command
unreachable();
}
-static void ralink_halt(void)
-{
- local_irq_disable();
- unreachable();
-}
-
static int __init mips_reboot_setup(void)
{
_machine_restart = ralink_restart;
- _machine_halt = ralink_halt;
return 0;
}
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 02/43] iio: st_pressure: st_accel: pass correct platform data to init
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 01/43] MIPS: ralink: Remove ralink_halt() Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 03/43] ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit Greg Kroah-Hartman
` (46 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Nosthoff, Jonathan Cameron
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Nosthoff <committed@heine.so>
commit 8b438686a001db64c21782d04ef68111e53c45d9 upstream.
Commit 7383d44b added a pointer pdata which get set to the default
platform_data when non was defined in the device. But it did not
pass this pointer to the st_sensors_init_sensor call but still
used the maybe uninitialized platform_data from dev.
This breaks initialization when no platform_data is given and
the optional st,drdy-int-pin devicetree option is not set.
This commit fixes this.
Cc: stable@vger.kernel.org
Fixes: 7383d44b ("iio: st_pressure: st_accel: Initialise sensor platform data properly")
Signed-off-by: Michael Nosthoff <committed@heine.so>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/accel/st_accel_core.c | 2 +-
drivers/iio/pressure/st_pressure_core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -657,7 +657,7 @@ int st_accel_common_probe(struct iio_dev
if (!pdata)
pdata = (struct st_sensors_platform_data *)&default_accel_pdata;
- err = st_sensors_init_sensor(indio_dev, adata->dev->platform_data);
+ err = st_sensors_init_sensor(indio_dev, pdata);
if (err < 0)
return err;
--- a/drivers/iio/pressure/st_pressure_core.c
+++ b/drivers/iio/pressure/st_pressure_core.c
@@ -469,7 +469,7 @@ int st_press_common_probe(struct iio_dev
if (!pdata && press_data->sensor_settings->drdy_irq.addr)
pdata = (struct st_sensors_platform_data *)&default_press_pdata;
- err = st_sensors_init_sensor(indio_dev, press_data->dev->platform_data);
+ err = st_sensors_init_sensor(indio_dev, pdata);
if (err < 0)
return err;
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 03/43] ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 01/43] MIPS: ralink: Remove ralink_halt() Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 02/43] iio: st_pressure: st_accel: pass correct platform data to init Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 04/43] ALSA: aloop: Sync stale timer before release Greg Kroah-Hartman
` (45 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kirill Marinushkin, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill Marinushkin <k.marinushkin@gmail.com>
commit a6618f4aedb2b60932d766bd82ae7ce866e842aa upstream.
Currently, the offsets in the UAC2 processing unit descriptor are
calculated incorrectly. It causes an issue when connecting the device which
provides such a feature:
~~~~
[84126.724420] usb 1-1.3.1: invalid Processing Unit descriptor (id 18)
~~~~
After this patch is applied, the UAC2 processing unit inits w/o this error.
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/linux/usb/audio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/uapi/linux/usb/audio.h
+++ b/include/uapi/linux/usb/audio.h
@@ -369,7 +369,7 @@ static inline __u8 uac_processing_unit_b
{
return (protocol == UAC_VERSION_1) ?
desc->baSourceID[desc->bNrInPins + 4] :
- desc->baSourceID[desc->bNrInPins + 6];
+ 2; /* in UAC2, this value is constant */
}
static inline __u8 *uac_processing_unit_bmControls(struct uac_processing_unit_descriptor *desc,
@@ -377,7 +377,7 @@ static inline __u8 *uac_processing_unit_
{
return (protocol == UAC_VERSION_1) ?
&desc->baSourceID[desc->bNrInPins + 5] :
- &desc->baSourceID[desc->bNrInPins + 7];
+ &desc->baSourceID[desc->bNrInPins + 6];
}
static inline __u8 uac_processing_unit_iProcessing(struct uac_processing_unit_descriptor *desc,
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 04/43] ALSA: aloop: Sync stale timer before release
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 03/43] ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 05/43] ALSA: aloop: Fix access to not-yet-ready substream via cable Greg Kroah-Hartman
` (44 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 67a01afaf3d34893cf7d2ea19b34555d6abb7cb0 upstream.
The aloop driver tries to stop the pending timer via timer_del() in
the trigger callback and in the close callback. The former is
correct, as it's an atomic operation, while the latter expects that
the timer gets really removed and proceeds the resource releases after
that. But timer_del() doesn't synchronize, hence the running timer
may still access the released resources.
A similar situation can be also seen in the prepare callback after
trigger(STOP) where the prepare tries to re-initialize the things
while a timer is still running.
The problems like the above are seen indirectly in some syzkaller
reports (although it's not 100% clear whether this is the only cause,
as the race condition is quite narrow and not always easy to
trigger).
For addressing these issues, this patch adds the explicit alls of
timer_del_sync() in some places, so that the pending timer is properly
killed / synced.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/drivers/aloop.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -192,6 +192,11 @@ static inline void loopback_timer_stop(s
dpcm->timer.expires = 0;
}
+static inline void loopback_timer_stop_sync(struct loopback_pcm *dpcm)
+{
+ del_timer_sync(&dpcm->timer);
+}
+
#define CABLE_VALID_PLAYBACK (1 << SNDRV_PCM_STREAM_PLAYBACK)
#define CABLE_VALID_CAPTURE (1 << SNDRV_PCM_STREAM_CAPTURE)
#define CABLE_VALID_BOTH (CABLE_VALID_PLAYBACK|CABLE_VALID_CAPTURE)
@@ -326,6 +331,8 @@ static int loopback_prepare(struct snd_p
struct loopback_cable *cable = dpcm->cable;
int bps, salign;
+ loopback_timer_stop_sync(dpcm);
+
salign = (snd_pcm_format_width(runtime->format) *
runtime->channels) / 8;
bps = salign * runtime->rate;
@@ -745,7 +752,7 @@ static int loopback_close(struct snd_pcm
struct loopback *loopback = substream->private_data;
struct loopback_pcm *dpcm = substream->runtime->private_data;
- loopback_timer_stop(dpcm);
+ loopback_timer_stop_sync(dpcm);
mutex_lock(&loopback->cable_lock);
free_cable(substream);
mutex_unlock(&loopback->cable_lock);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 05/43] ALSA: aloop: Fix access to not-yet-ready substream via cable
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 04/43] ALSA: aloop: Sync stale timer before release Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 06/43] ALSA: hda/realtek - Always immediately update mute LED with pin VREF Greg Kroah-Hartman
` (43 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 8e6b1a72a75bb5067ccb6b56d8ca4aa3a300a64e upstream.
In loopback_open() and loopback_close(), we assign and release the
substream object to the corresponding cable in a racy way. It's
neither locked nor done in the right position. The open callback
assigns the substream before its preparation finishes, hence the other
side of the cable may pick it up, which may lead to the invalid memory
access.
This patch addresses these: move the assignment to the end of the open
callback, and wrap with cable->lock for avoiding concurrent accesses.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/drivers/aloop.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/sound/drivers/aloop.c
+++ b/sound/drivers/aloop.c
@@ -666,7 +666,9 @@ static void free_cable(struct snd_pcm_su
return;
if (cable->streams[!substream->stream]) {
/* other stream is still alive */
+ spin_lock_irq(&cable->lock);
cable->streams[substream->stream] = NULL;
+ spin_unlock_irq(&cable->lock);
} else {
/* free the cable */
loopback->cables[substream->number][dev] = NULL;
@@ -706,7 +708,6 @@ static int loopback_open(struct snd_pcm_
loopback->cables[substream->number][dev] = cable;
}
dpcm->cable = cable;
- cable->streams[substream->stream] = dpcm;
snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
@@ -738,6 +739,11 @@ static int loopback_open(struct snd_pcm_
runtime->hw = loopback_pcm_hardware;
else
runtime->hw = cable->hw;
+
+ spin_lock_irq(&cable->lock);
+ cable->streams[substream->stream] = dpcm;
+ spin_unlock_irq(&cable->lock);
+
unlock:
if (err < 0) {
free_cable(substream);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 06/43] ALSA: hda/realtek - Always immediately update mute LED with pin VREF
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 05/43] ALSA: aloop: Fix access to not-yet-ready substream via cable Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 07/43] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs Greg Kroah-Hartman
` (42 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c upstream.
Some HP laptops have a mute mute LED controlled by a pin VREF. The
Realtek codec driver updates the VREF via vmaster hook by calling
snd_hda_set_pin_ctl_cache().
This works fine as long as the driver is running in a normal mode.
However, when the VREF change happens during the codec being in
runtime PM suspend, the regmap access will skip and postpone the
actual register change. This ends up with the unchanged LED status
until the next runtime PM resume even if you change the Master mute
switch. (Interestingly, the machine keeps the LED status even after
the codec goes into D3 -- but it's another story.)
For improving this usability, let the driver temporarily powering up /
down only during the pin VREF change. This can be achieved easily by
wrapping the call with snd_hda_power_up_pm() / *_down_pm().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3261,8 +3261,12 @@ static void alc269_fixup_mic_mute_hook(v
pinval = snd_hda_codec_get_pin_target(codec, spec->mute_led_nid);
pinval &= ~AC_PINCTL_VREFEN;
pinval |= enabled ? AC_PINCTL_VREF_HIZ : AC_PINCTL_VREF_80;
- if (spec->mute_led_nid)
+ if (spec->mute_led_nid) {
+ /* temporarily power up/down for setting VREF */
+ snd_hda_power_up_pm(codec);
snd_hda_set_pin_ctl_cache(codec, spec->mute_led_nid, pinval);
+ snd_hda_power_down_pm(codec);
+ }
}
/* Make sure the led works even in runtime suspend */
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 07/43] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 06/43] ALSA: hda/realtek - Always immediately update mute LED with pin VREF Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 08/43] PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L Greg Kroah-Hartman
` (41 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Evgeniy Didin, Jaehoon Chung,
Ulf Hansson, Andy Shevchenko, Jisheng Zhang, Shawn Lin,
Alexey Brodkin, Eugeniy Paltsev, linux-snps-arc
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
commit 47b7de2f6c18f75d1f2716efe752cba43f32a626 upstream.
It was found that in IDMAC mode after soft-reset driver switches
to PIO mode.
That's what happens in case of DTO timeout overflow calculation failure:
1. soft-reset is called
2. driver restarts dma
3. descriptors states are checked, one of descriptor is owned by the IDMAC.
4. driver can't use DMA and then switches to PIO mode.
Failure was already fixed in:
https://www.spinics.net/lists/linux-mmc/msg48125.html.
Behaviour while soft-reset is not something we except or
even want to happen. So we switch from dw_mci_idmac_reset
to dw_mci_idmac_init, so descriptors are cleaned before starting dma.
And while at it explicitly zero des0 which otherwise might
contain garbage as being allocated by dmam_alloc_coherent().
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: <stable@vger.kernel.org> # 4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -619,6 +619,7 @@ static int dw_mci_idmac_init(struct dw_m
(sizeof(struct idmac_desc_64addr) *
(i + 1))) >> 32;
/* Initialize reserved and buffer size fields to "0" */
+ p->des0 = 0;
p->des1 = 0;
p->des2 = 0;
p->des3 = 0;
@@ -640,6 +641,7 @@ static int dw_mci_idmac_init(struct dw_m
i++, p++) {
p->des3 = cpu_to_le32(host->sg_dma +
(sizeof(struct idmac_desc) * (i + 1)));
+ p->des0 = 0;
p->des1 = 0;
}
@@ -2807,8 +2809,8 @@ static bool dw_mci_reset(struct dw_mci *
}
if (host->use_dma == TRANS_MODE_IDMAC)
- /* It is also recommended that we reset and reprogram idmac */
- dw_mci_idmac_reset(host);
+ /* It is also required that we reinit idmac */
+ dw_mci_idmac_init(host);
ret = true;
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 08/43] PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 07/43] mmc: dw_mmc: fix falling from idmac to PIO mode when dw_mci_reset occurs Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 09/43] ahci: Add PCI-id for the Highpoint Rocketraid 644L card Greg Kroah-Hartman
` (40 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Bjorn Helgaas, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 1903be8222b7c278ca897c129ce477c1dd6403a8 upstream.
The Highpoint RocketRAID 644L uses a Marvel 88SE9235 controller, as with
other Marvel controllers this needs a function 1 DMA alias quirk.
Note the RocketRAID 642L uses the same Marvel 88SE9235 controller and
already is listed with a function 1 DMA alias quirk.
Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3631,6 +3631,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
quirk_dma_func1_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0642,
quirk_dma_func1_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0645,
+ quirk_dma_func1_alias);
/* https://bugs.gentoo.org/show_bug.cgi?id=497630 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
PCI_DEVICE_ID_JMICRON_JMB388_ESD,
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 09/43] ahci: Add PCI-id for the Highpoint Rocketraid 644L card
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 08/43] PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 10/43] clk: bcm2835: Protect sections updating shared registers Greg Kroah-Hartman
` (39 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Tejun Heo, Bjorn Helgaas
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 28b2182dad43f6f8fcbd167539a26714fd12bd64 upstream.
Like the Highpoint Rocketraid 642L and cards using a Marvel 88SE9235
controller in general, this RAID card also supports AHCI mode and short
of a custom driver, this is the only way to make it work under Linux.
Note that even though the card is called to 644L, it has a product-id
of 0x0645.
Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/ahci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -538,7 +538,9 @@ static const struct pci_device_id ahci_p
.driver_data = board_ahci_yes_fbs },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9230),
.driver_data = board_ahci_yes_fbs },
- { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642),
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642), /* highpoint rocketraid 642L */
+ .driver_data = board_ahci_yes_fbs },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0645), /* highpoint rocketraid 644L */
.driver_data = board_ahci_yes_fbs },
/* Promise */
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 10/43] clk: bcm2835: Protect sections updating shared registers
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 09/43] ahci: Add PCI-id for the Highpoint Rocketraid 644L card Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 11/43] Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 Greg Kroah-Hartman
` (38 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Boris Brezillon, Eric Anholt, Stephen Boyd
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <boris.brezillon@bootlin.com>
commit 7997f3b2df751aab0b8e60149b226a32966c41ac upstream.
CM_PLLx and A2W_XOSC_CTRL registers are accessed by different clock
handlers and must be accessed with ->regs_lock held.
Update the sections where this protection is missing.
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Cc: <stable@vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/clk/bcm/clk-bcm2835.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -912,8 +912,10 @@ static int bcm2835_pll_on(struct clk_hw
~A2W_PLL_CTRL_PWRDN);
/* Take the PLL out of reset. */
+ spin_lock(&cprman->regs_lock);
cprman_write(cprman, data->cm_ctrl_reg,
cprman_read(cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST);
+ spin_unlock(&cprman->regs_lock);
/* Wait for the PLL to lock. */
timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
@@ -997,9 +999,11 @@ static int bcm2835_pll_set_rate(struct c
}
/* Unmask the reference clock from the oscillator. */
+ spin_lock(&cprman->regs_lock);
cprman_write(cprman, A2W_XOSC_CTRL,
cprman_read(cprman, A2W_XOSC_CTRL) |
data->reference_enable_mask);
+ spin_unlock(&cprman->regs_lock);
if (do_ana_setup_first)
bcm2835_pll_write_ana(cprman, data->ana_reg_base, ana);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 11/43] Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 10/43] clk: bcm2835: Protect sections updating shared registers Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 12/43] libata: fix length validation of ATAPI-relayed SCSI commands Greg Kroah-Hartman
` (37 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ivan Levshin, Takashi Iwai, Marcel Holtmann
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit f44cb4b19ed40b655c2d422c9021ab2c2625adb6 upstream.
The Atheros 1525/QCA6174 BT doesn't seem working properly on the
recent kernels, as it tries to load a wrong firmware
ar3k/AthrBT_0x00000200.dfu and it fails.
This seems to have been a problem for some time, and the known
workaround is to apply BTUSB_QCA_ROM quirk instead of BTUSB_ATH3012.
The device in question is:
T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=3004 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
Reported-by: Ivan Levshin <ivan.levshin@microfocus.com>
Tested-by: Ivan Levshin <ivan.levshin@microfocus.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -216,7 +216,6 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 },
- { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0x311e), .driver_info = BTUSB_ATH3012 },
@@ -247,6 +246,7 @@ static const struct usb_device_id blackl
{ USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 },
/* QCA ROME chipset */
+ { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x0cf3, 0xe007), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x0cf3, 0xe300), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x0cf3, 0xe360), .driver_info = BTUSB_QCA_ROME },
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 12/43] libata: fix length validation of ATAPI-relayed SCSI commands
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 11/43] Bluetooth: btusb: Fix quirk for Atheros 1525/QCA6174 Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 13/43] libata: remove WARN() for DMA or PIO command without data Greg Kroah-Hartman
` (36 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable,
syzbot+1ff6f9fcc3c35f1c72a95e26528c8e7e3276e4da, Eric Biggers,
Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 058f58e235cbe03e923b30ea7c49995a46a8725f upstream.
syzkaller reported a crash in ata_bmdma_fill_sg() when writing to
/dev/sg1. The immediate cause was that the ATA command's scatterlist
was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in a
write to 'qc->ap->bmdma_prd[0xffffffff]'.
Strangely though, the flag ATA_QCFLAG_DMAMAP was set in qc->flags. The
root cause is that when __ata_scsi_queuecmd() is preparing to relay a
SCSI command to an ATAPI device, it doesn't correctly validate the CDB
length before copying it into the 16-byte buffer 'cdb' in 'struct
ata_queued_cmd'. Namely, it validates the fixed CDB length expected
based on the SCSI opcode but not the actual CDB length, which can be
larger due to the use of the SG_NEXT_CMD_LEN ioctl. Since 'flags' is
the next member in ata_queued_cmd, a buffer overflow corrupts it.
Fix it by requiring that the actual CDB length be <= 16 (ATAPI_CDB_LEN).
[Really it seems the length should be required to be <= dev->cdb_len,
but the current behavior seems to have been intentionally introduced by
commit 607126c2a21c ("libata-scsi: be tolerant of 12-byte ATAPI commands
in 16-byte CDBs") to work around a userspace bug in mplayer. Probably
the workaround is no longer needed (mplayer was fixed in 2007), but
continuing to allow lengths to up 16 appears harmless for now.]
Here's a reproducer that works in QEMU when /dev/sg1 refers to the
CD-ROM drive that qemu-system-x86_64 creates by default:
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
#define SG_NEXT_CMD_LEN 0x2283
int main()
{
char buf[53] = { [36] = 0x7e, [52] = 0x02 };
int fd = open("/dev/sg1", O_RDWR);
ioctl(fd, SG_NEXT_CMD_LEN, &(int){ 17 });
write(fd, buf, sizeof(buf));
}
The crash was:
BUG: unable to handle kernel paging request at ffff8cb97db37ffc
IP: ata_bmdma_fill_sg drivers/ata/libata-sff.c:2623 [inline]
IP: ata_bmdma_qc_prep+0xa4/0xc0 drivers/ata/libata-sff.c:2727
PGD fb6c067 P4D fb6c067 PUD 0
Oops: 0002 [#1] SMP
CPU: 1 PID: 150 Comm: syz_ata_bmdma_q Not tainted 4.15.0-next-20180202 #99
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[...]
Call Trace:
ata_qc_issue+0x100/0x1d0 drivers/ata/libata-core.c:5421
ata_scsi_translate+0xc9/0x1a0 drivers/ata/libata-scsi.c:2024
__ata_scsi_queuecmd drivers/ata/libata-scsi.c:4326 [inline]
ata_scsi_queuecmd+0x8c/0x210 drivers/ata/libata-scsi.c:4375
scsi_dispatch_cmd+0xa2/0xe0 drivers/scsi/scsi_lib.c:1727
scsi_request_fn+0x24c/0x530 drivers/scsi/scsi_lib.c:1865
__blk_run_queue_uncond block/blk-core.c:412 [inline]
__blk_run_queue+0x3a/0x60 block/blk-core.c:432
blk_execute_rq_nowait+0x93/0xc0 block/blk-exec.c:78
sg_common_write.isra.7+0x272/0x5a0 drivers/scsi/sg.c:806
sg_write+0x1ef/0x340 drivers/scsi/sg.c:677
__vfs_write+0x31/0x160 fs/read_write.c:480
vfs_write+0xa7/0x160 fs/read_write.c:544
SYSC_write fs/read_write.c:589 [inline]
SyS_write+0x4d/0xc0 fs/read_write.c:581
do_syscall_64+0x5e/0x110 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x21/0x86
Fixes: 607126c2a21c ("libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs")
Reported-by: syzbot+1ff6f9fcc3c35f1c72a95e26528c8e7e3276e4da@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> # v2.6.24+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-scsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3472,7 +3472,9 @@ static inline int __ata_scsi_queuecmd(st
if (likely((scsi_op != ATA_16) || !atapi_passthru16)) {
/* relay SCSI command to ATAPI device */
int len = COMMAND_SIZE(scsi_op);
- if (unlikely(len > scmd->cmd_len || len > dev->cdb_len))
+ if (unlikely(len > scmd->cmd_len ||
+ len > dev->cdb_len ||
+ scmd->cmd_len > ATAPI_CDB_LEN))
goto bad_cdb_len;
xlat_func = atapi_xlat;
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 13/43] libata: remove WARN() for DMA or PIO command without data
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 12/43] libata: fix length validation of ATAPI-relayed SCSI commands Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 14/43] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs Greg Kroah-Hartman
` (35 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable,
syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f, Eric Biggers,
Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 9173e5e80729c8434b8d27531527c5245f4a5594 upstream.
syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This
happened because it issued a READ_6 command with no data buffer.
Just remove the WARN(), as it doesn't appear indicate a kernel bug. The
expected behavior is to fail the command, which the code does.
Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
the default type ("82371SB PIIX3 IDE"):
#include <fcntl.h>
#include <unistd.h>
int main()
{
char buf[42] = { [36] = 0x8 /* READ_6 */ };
write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
}
Fixes: f92a26365a72 ("libata: change ATA_QCFLAG_DMAMAP semantics")
Reported-by: syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> # v2.6.25+
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -5077,8 +5077,7 @@ void ata_qc_issue(struct ata_queued_cmd
* We guarantee to LLDs that they will have at least one
* non-zero sg if the command is a data command.
*/
- if (WARN_ON_ONCE(ata_is_data(prot) &&
- (!qc->sg || !qc->n_elem || !qc->nbytes)))
+ if (ata_is_data(prot) && (!qc->sg || !qc->n_elem || !qc->nbytes))
goto sys_err;
if (ata_is_dma(prot) || (ata_is_pio(prot) &&
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 14/43] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 13/43] libata: remove WARN() for DMA or PIO command without data Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 15/43] libata: disable LPM for Crucial BX100 SSD 500GB drive Greg Kroah-Hartman
` (34 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 upstream.
Various people have reported the Crucial MX100 512GB model not working
with LPM set to min_power. I've now received a report that it also does
not work with the new med_power_with_dipm level.
It does work with medium_power, but that has no measurable power-savings
and given the amount of people being bitten by the other levels not
working, this commit just disables LPM altogether.
Note all reporters of this have either the 512GB model (max capacity), or
are not specifying their SSD's size. So for now this quirk assumes this is
a problem with the 512GB model only.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=89261
Buglink: https://github.com/linrunner/TLP/issues/84
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4224,6 +4224,11 @@ static const struct ata_blacklist_entry
{ "PIONEER DVD-RW DVR-212D", NULL, ATA_HORKAGE_NOSETXFER },
{ "PIONEER DVD-RW DVR-216D", NULL, ATA_HORKAGE_NOSETXFER },
+ /* The 512GB version of the MX100 has both queued TRIM and LPM issues */
+ { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 15/43] libata: disable LPM for Crucial BX100 SSD 500GB drive
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 14/43] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 16/43] libata: Enable queued TRIM for Samsung SSD 860 Greg Kroah-Hartman
` (33 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit b17e5729a630d8326a48ec34ef02e6b4464a6aef upstream.
After Laptop Mode Tools starts to use min_power for LPM, a user found
out Crucial BX100 SSD can't get mounted.
Crucial BX100 SSD 500GB drive don't work well with min_power. This also
happens to med_power_with_dipm.
So let's disable LPM for Crucial BX100 SSD 500GB drive.
BugLink: https://bugs.launchpad.net/bugs/1726930
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4224,6 +4224,9 @@ static const struct ata_blacklist_entry
{ "PIONEER DVD-RW DVR-212D", NULL, ATA_HORKAGE_NOSETXFER },
{ "PIONEER DVD-RW DVR-216D", NULL, ATA_HORKAGE_NOSETXFER },
+ /* Crucial BX100 SSD 500GB has broken LPM support */
+ { "CT500BX100SSD1", "MU02", ATA_HORKAGE_NOLPM },
+
/* The 512GB version of the MX100 has both queued TRIM and LPM issues */
{ "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM |
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 16/43] libata: Enable queued TRIM for Samsung SSD 860
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 15/43] libata: disable LPM for Crucial BX100 SSD 500GB drive Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 17/43] libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs Greg Kroah-Hartman
` (32 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Park Ju Hyung, Martin K. Petersen, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ju Hyung Park <qkrwngud825@gmail.com>
commit ca6bfcb2f6d9deab3924bf901e73622a94900473 upstream.
Samsung explicitly states that queued TRIM is supported for Linux with
860 PRO and 860 EVO.
Make the previous blacklist to cover only 840 and 850 series.
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4243,7 +4243,9 @@ static const struct ata_blacklist_entry
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
- { "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ { "Samsung SSD 840*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM, },
+ { "Samsung SSD 850*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "FCCT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 17/43] libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 16/43] libata: Enable queued TRIM for Samsung SSD 860 Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 18/43] libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions Greg Kroah-Hartman
` (31 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 62ac3f7305470e3f52f159de448bc1a771717e88 upstream.
There have been reports of the Crucial M500 480GB model not working
with LPM set to min_power / med_power_with_dipm level.
It has not been tested with medium_power, but that typically has no
measurable power-savings.
Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
and there is a MU05 update available, but that update does not mention any
LPM fixes in its changelog, so the quirk matches all firmware versions.
In my experience the LPM problems with (older) Crucial SSDs seem to be
limited to higher capacity versions of the SSDs (different firmware?),
so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
M500, to avoid LPM causing issues with these SSDs.
Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin Steigerwald <martin@lichtvoll.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4232,6 +4232,14 @@ static const struct ata_blacklist_entry
ATA_HORKAGE_ZERO_AFTER_TRIM |
ATA_HORKAGE_NOLPM, },
+ /* 480GB+ M500 SSDs have both queued TRIM and LPM issues */
+ { "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+ { "Crucial_CT960M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 18/43] libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 17/43] libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 19/43] libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version Greg Kroah-Hartman
` (30 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Hans de Goede, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f upstream.
Commit b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB
drive"), introduced a ATA_HORKAGE_NOLPM quirk for Crucial BX100 500GB SSDs
but limited this to the MU02 firmware version, according to:
http://www.crucial.com/usa/en/support-ssd-firmware
MU02 is the last version, so there are no newer possibly fixed versions
and if the MU02 version has broken LPM then the MU01 almost certainly
also has broken LPM, so this commit changes the quirk to apply to all
firmware versions.
Fixes: b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB...")
Cc: stable@vger.kernel.org
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4225,7 +4225,7 @@ static const struct ata_blacklist_entry
{ "PIONEER DVD-RW DVR-216D", NULL, ATA_HORKAGE_NOSETXFER },
/* Crucial BX100 SSD 500GB has broken LPM support */
- { "CT500BX100SSD1", "MU02", ATA_HORKAGE_NOLPM },
+ { "CT500BX100SSD1", NULL, ATA_HORKAGE_NOLPM },
/* The 512GB version of the MX100 has both queued TRIM and LPM issues */
{ "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 19/43] libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 18/43] libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table Greg Kroah-Hartman
` (29 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Tejun Heo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
commit d418ff56b8f2d2b296daafa8da151fe27689b757 upstream.
When commit 9c7be59fc519af ("libata: Apply NOLPM quirk to Crucial MX100
512GB SSDs") was added it inherited the ATA_HORKAGE_NO_NCQ_TRIM quirk
from the existing "Crucial_CT*MX100*" entry, but that entry sets model_rev
to "MU01", where as the entry adding the NOLPM quirk sets it to NULL.
This means that after this commit we no apply the NO_NCQ_TRIM quirk to
all "Crucial_CT512MX100*" SSDs even if they have the fixed "MU02"
firmware. This commit splits the "Crucial_CT512MX100*" quirk into 2
quirks, one for the "MU01" firmware and one for all other firmware
versions, so that we once again only apply the NO_NCQ_TRIM quirk to the
"MU01" firmware version.
Fixes: 9c7be59fc519af ("libata: Apply NOLPM quirk to ... MX100 512GB SSDs")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4227,10 +4227,13 @@ static const struct ata_blacklist_entry
/* Crucial BX100 SSD 500GB has broken LPM support */
{ "CT500BX100SSD1", NULL, ATA_HORKAGE_NOLPM },
- /* The 512GB version of the MX100 has both queued TRIM and LPM issues */
- { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ /* 512GB MX100 with MU01 firmware has both queued TRIM and LPM issues */
+ { "Crucial_CT512MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM |
ATA_HORKAGE_NOLPM, },
+ /* 512GB MX100 with newer firmware has only LPM issues */
+ { "Crucial_CT512MX100*", NULL, ATA_HORKAGE_ZERO_AFTER_TRIM |
+ ATA_HORKAGE_NOLPM, },
/* 480GB+ M500 SSDs have both queued TRIM and LPM issues */
{ "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 19/43] libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 20:17 ` Dan Rue
2018-03-27 16:27 ` [PATCH 4.4 21/43] x86/mm: implement free pmd/pte page interfaces Greg Kroah-Hartman
` (28 subsequent siblings)
48 siblings, 1 reply; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lei Li, Toshi Kani, Catalin Marinas,
Wang Xuefeng, Will Deacon, Hanjun Guo, Michal Hocko,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Borislav Petkov,
Matthew Wilcox, Chintan Pandya, Andrew Morton, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toshi Kani <toshi.kani@hpe.com>
commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
create pud/pmd mappings. A kernel panic was observed on arm64 systems
with Cortex-A75 in the following steps as described by Hanjun Guo.
1. ioremap a 4K size, valid page table will build,
2. iounmap it, pte0 will set to 0;
3. ioremap the same address with 2M size, pgd/pmd is unchanged,
then set the a new value for pmd;
4. pte0 is leaked;
5. CPU may meet exception because the old pmd is still in TLB,
which will lead to kernel panic.
This panic is not reproducible on x86. INVLPG, called from iounmap,
purges all levels of entries associated with purged address on x86. x86
still has memory leak.
The patch changes the ioremap path to free unmapped page table(s) since
doing so in the unmap path has the following issues:
- The iounmap() path is shared with vunmap(). Since vmap() only
supports pte mappings, making vunmap() to free a pte page is an
overhead for regular vmap users as they do not need a pte page freed
up.
- Checking if all entries in a pte page are cleared in the unmap path
is racy, and serializing this check is expensive.
- The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
purge.
Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
clear a given pud/pmd entry and free up a page for the lower level
entries.
This patch implements their stub functions on x86 and arm64, which work
as workaround.
[akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
Reported-by: Lei Li <lious.lilei@hisilicon.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/mmu.c | 10 ++++++++++
arch/x86/mm/pgtable.c | 24 ++++++++++++++++++++++++
include/asm-generic/pgtable.h | 10 ++++++++++
lib/ioremap.c | 6 ++++--
4 files changed, 48 insertions(+), 2 deletions(-)
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -697,3 +697,13 @@ void *__init fixmap_remap_fdt(phys_addr_
return dt_virt;
}
+
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -666,4 +666,28 @@ int pmd_clear_huge(pmd_t *pmd)
return 0;
}
+
+/**
+ * pud_free_pmd_page - Clear pud entry and free pmd page.
+ * @pud: Pointer to a PUD.
+ *
+ * Context: The pud range has been unmaped and TLB purged.
+ * Return: 1 if clearing the entry succeeded. 0 otherwise.
+ */
+int pud_free_pmd_page(pud_t *pud)
+{
+ return pud_none(*pud);
+}
+
+/**
+ * pmd_free_pte_page - Clear pmd entry and free pte page.
+ * @pmd: Pointer to a PMD.
+ *
+ * Context: The pmd range has been unmaped and TLB purged.
+ * Return: 1 if clearing the entry succeeded. 0 otherwise.
+ */
+int pmd_free_pte_page(pmd_t *pmd)
+{
+ return pmd_none(*pmd);
+}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -755,6 +755,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t
int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
int pud_clear_huge(pud_t *pud);
int pmd_clear_huge(pmd_t *pmd);
+int pud_free_pmd_page(pud_t *pud);
+int pmd_free_pte_page(pmd_t *pmd);
#else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
static inline int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
{
@@ -772,6 +774,14 @@ static inline int pmd_clear_huge(pmd_t *
{
return 0;
}
+static inline int pud_free_pmd_page(pud_t *pud)
+{
+ return 0;
+}
+static inline int pmd_free_pte_page(pmd_t *pmd)
+{
+ return 0;
+}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
#endif /* !__ASSEMBLY__ */
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -83,7 +83,8 @@ static inline int ioremap_pmd_range(pud_
if (ioremap_pmd_enabled() &&
((next - addr) == PMD_SIZE) &&
- IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
+ IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
+ pmd_free_pte_page(pmd)) {
if (pmd_set_huge(pmd, phys_addr + addr, prot))
continue;
}
@@ -109,7 +110,8 @@ static inline int ioremap_pud_range(pgd_
if (ioremap_pud_enabled() &&
((next - addr) == PUD_SIZE) &&
- IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
+ IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
+ pud_free_pmd_page(pud)) {
if (pud_set_huge(pud, phys_addr + addr, prot))
continue;
}
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 16:27 ` [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table Greg Kroah-Hartman
@ 2018-03-27 20:17 ` Dan Rue
2018-03-27 20:27 ` Kani, Toshi
2018-03-27 20:31 ` Nathan Chancellor
0 siblings, 2 replies; 64+ messages in thread
From: Dan Rue @ 2018-03-27 20:17 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Lei Li, Toshi Kani, Catalin Marinas,
Wang Xuefeng, Will Deacon, Hanjun Guo, Michal Hocko,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Borislav Petkov,
Matthew Wilcox, Chintan Pandya, Andrew Morton, Linus Torvalds
On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Toshi Kani <toshi.kani@hpe.com>
>
> commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
>
> On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
> create pud/pmd mappings. A kernel panic was observed on arm64 systems
> with Cortex-A75 in the following steps as described by Hanjun Guo.
>
> 1. ioremap a 4K size, valid page table will build,
> 2. iounmap it, pte0 will set to 0;
> 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
> then set the a new value for pmd;
> 4. pte0 is leaked;
> 5. CPU may meet exception because the old pmd is still in TLB,
> which will lead to kernel panic.
>
> This panic is not reproducible on x86. INVLPG, called from iounmap,
> purges all levels of entries associated with purged address on x86. x86
> still has memory leak.
>
> The patch changes the ioremap path to free unmapped page table(s) since
> doing so in the unmap path has the following issues:
>
> - The iounmap() path is shared with vunmap(). Since vmap() only
> supports pte mappings, making vunmap() to free a pte page is an
> overhead for regular vmap users as they do not need a pte page freed
> up.
>
> - Checking if all entries in a pte page are cleared in the unmap path
> is racy, and serializing this check is expensive.
>
> - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
> Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
> purge.
>
> Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
> clear a given pud/pmd entry and free up a page for the lower level
> entries.
>
> This patch implements their stub functions on x86 and arm64, which work
> as workaround.
>
> [akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
> Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
> Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
> Reported-by: Lei Li <lious.lilei@hisilicon.com>
> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <guohanjun@huawei.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Chintan Pandya <cpandya@codeaurora.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch causes the following build error on 4.4 arm64:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
CC arch/arm64/mm/mmu.o
../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
int pud_free_pmd_page(pud_t *pud)
^~~~~~~~~~~~~~~~~
In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
from ../include/linux/mm.h:55,
from ../include/linux/mman.h:4,
from ../arch/arm64/mm/mmu.c:25:
../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
static inline int pud_free_pmd_page(pud_t *pud)
^~~~~~~~~~~~~~~~~
../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
int pmd_free_pte_page(pmd_t *pmd)
^~~~~~~~~~~~~~~~~
In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
from ../include/linux/mm.h:55,
from ../include/linux/mman.h:4,
from ../arch/arm64/mm/mmu.c:25:
../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
static inline int pmd_free_pte_page(pmd_t *pmd)
^~~~~~~~~~~~~~~~~
make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
make: *** [Makefile:152: sub-make] Error 2
>
> ---
> arch/arm64/mm/mmu.c | 10 ++++++++++
> arch/x86/mm/pgtable.c | 24 ++++++++++++++++++++++++
> include/asm-generic/pgtable.h | 10 ++++++++++
> lib/ioremap.c | 6 ++++--
> 4 files changed, 48 insertions(+), 2 deletions(-)
>
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -697,3 +697,13 @@ void *__init fixmap_remap_fdt(phys_addr_
>
> return dt_virt;
> }
> +
> +int pud_free_pmd_page(pud_t *pud)
> +{
> + return pud_none(*pud);
> +}
> +
> +int pmd_free_pte_page(pmd_t *pmd)
> +{
> + return pmd_none(*pmd);
> +}
> --- a/arch/x86/mm/pgtable.c
> +++ b/arch/x86/mm/pgtable.c
> @@ -666,4 +666,28 @@ int pmd_clear_huge(pmd_t *pmd)
>
> return 0;
> }
> +
> +/**
> + * pud_free_pmd_page - Clear pud entry and free pmd page.
> + * @pud: Pointer to a PUD.
> + *
> + * Context: The pud range has been unmaped and TLB purged.
> + * Return: 1 if clearing the entry succeeded. 0 otherwise.
> + */
> +int pud_free_pmd_page(pud_t *pud)
> +{
> + return pud_none(*pud);
> +}
> +
> +/**
> + * pmd_free_pte_page - Clear pmd entry and free pte page.
> + * @pmd: Pointer to a PMD.
> + *
> + * Context: The pmd range has been unmaped and TLB purged.
> + * Return: 1 if clearing the entry succeeded. 0 otherwise.
> + */
> +int pmd_free_pte_page(pmd_t *pmd)
> +{
> + return pmd_none(*pmd);
> +}
> #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -755,6 +755,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t
> int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot);
> int pud_clear_huge(pud_t *pud);
> int pmd_clear_huge(pmd_t *pmd);
> +int pud_free_pmd_page(pud_t *pud);
> +int pmd_free_pte_page(pmd_t *pmd);
> #else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
> static inline int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
> {
> @@ -772,6 +774,14 @@ static inline int pmd_clear_huge(pmd_t *
> {
> return 0;
> }
> +static inline int pud_free_pmd_page(pud_t *pud)
> +{
> + return 0;
> +}
> +static inline int pmd_free_pte_page(pmd_t *pmd)
> +{
> + return 0;
> +}
> #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
>
> #endif /* !__ASSEMBLY__ */
> --- a/lib/ioremap.c
> +++ b/lib/ioremap.c
> @@ -83,7 +83,8 @@ static inline int ioremap_pmd_range(pud_
>
> if (ioremap_pmd_enabled() &&
> ((next - addr) == PMD_SIZE) &&
> - IS_ALIGNED(phys_addr + addr, PMD_SIZE)) {
> + IS_ALIGNED(phys_addr + addr, PMD_SIZE) &&
> + pmd_free_pte_page(pmd)) {
> if (pmd_set_huge(pmd, phys_addr + addr, prot))
> continue;
> }
> @@ -109,7 +110,8 @@ static inline int ioremap_pud_range(pgd_
>
> if (ioremap_pud_enabled() &&
> ((next - addr) == PUD_SIZE) &&
> - IS_ALIGNED(phys_addr + addr, PUD_SIZE)) {
> + IS_ALIGNED(phys_addr + addr, PUD_SIZE) &&
> + pud_free_pmd_page(pud)) {
> if (pud_set_huge(pud, phys_addr + addr, prot))
> continue;
> }
>
>
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 20:17 ` Dan Rue
@ 2018-03-27 20:27 ` Kani, Toshi
2018-03-27 20:31 ` Nathan Chancellor
1 sibling, 0 replies; 64+ messages in thread
From: Kani, Toshi @ 2018-03-27 20:27 UTC (permalink / raw)
To: gregkh, dan.rue
Cc: linux-kernel, torvalds, bp, tglx, lious.lilei, guohanjun,
wxf.wang, stable, akpm, hpa, catalin.marinas, will.deacon, mingo,
Hocko, Michal, cpandya, willy
On Tue, 2018-03-27 at 15:17 -0500, Dan Rue wrote:
> On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Toshi Kani <toshi.kani@hpe.com>
> >
> > commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
> >
> > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
> > create pud/pmd mappings. A kernel panic was observed on arm64 systems
> > with Cortex-A75 in the following steps as described by Hanjun Guo.
> >
> > 1. ioremap a 4K size, valid page table will build,
> > 2. iounmap it, pte0 will set to 0;
> > 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
> > then set the a new value for pmd;
> > 4. pte0 is leaked;
> > 5. CPU may meet exception because the old pmd is still in TLB,
> > which will lead to kernel panic.
> >
> > This panic is not reproducible on x86. INVLPG, called from iounmap,
> > purges all levels of entries associated with purged address on x86. x86
> > still has memory leak.
> >
> > The patch changes the ioremap path to free unmapped page table(s) since
> > doing so in the unmap path has the following issues:
> >
> > - The iounmap() path is shared with vunmap(). Since vmap() only
> > supports pte mappings, making vunmap() to free a pte page is an
> > overhead for regular vmap users as they do not need a pte page freed
> > up.
> >
> > - Checking if all entries in a pte page are cleared in the unmap path
> > is racy, and serializing this check is expensive.
> >
> > - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
> > Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
> > purge.
> >
> > Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
> > clear a given pud/pmd entry and free up a page for the lower level
> > entries.
> >
> > This patch implements their stub functions on x86 and arm64, which work
> > as workaround.
> >
> > [akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
> > Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
> > Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
> > Reported-by: Lei Li <lious.lilei@hisilicon.com>
> > Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Hanjun Guo <guohanjun@huawei.com>
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Borislav Petkov <bp@suse.de>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Chintan Pandya <cpandya@codeaurora.org>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> This patch causes the following build error on 4.4 arm64:
>
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
>
> CC arch/arm64/mm/mmu.o
> ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> int pud_free_pmd_page(pud_t *pud)
> ^~~~~~~~~~~~~~~~~
> In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> from ../include/linux/mm.h:55,
> from ../include/linux/mman.h:4,
> from ../arch/arm64/mm/mmu.c:25:
> ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> static inline int pud_free_pmd_page(pud_t *pud)
> ^~~~~~~~~~~~~~~~~
> ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> int pmd_free_pte_page(pmd_t *pmd)
> ^~~~~~~~~~~~~~~~~
> In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> from ../include/linux/mm.h:55,
> from ../include/linux/mman.h:4,
> from ../arch/arm64/mm/mmu.c:25:
> ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> static inline int pmd_free_pte_page(pmd_t *pmd)
> ^~~~~~~~~~~~~~~~~
> make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> make: *** [Makefile:152: sub-make] Error 2
>
>
> >
> > ---
> > arch/arm64/mm/mmu.c | 10 ++++++++++
> > arch/x86/mm/pgtable.c | 24 ++++++++++++++++++++++++
> > include/asm-generic/pgtable.h | 10 ++++++++++
> > lib/ioremap.c | 6 ++++--
> > 4 files changed, 48 insertions(+), 2 deletions(-)
> >
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -697,3 +697,13 @@ void *__init fixmap_remap_fdt(phys_addr_
> >
> > return dt_virt;
> > }
> > +
> > +int pud_free_pmd_page(pud_t *pud)
> > +{
> > + return pud_none(*pud);
> > +}
> > +
> > +int pmd_free_pte_page(pmd_t *pmd)
> > +{
> > + return pmd_none(*pmd);
> > +}
Sorry for the trouble. For 4.4, we need to simply drop the change in
the arch/arm64/mm/mmu.c file since arm64 gets the funcs from
include/asm-generic/pgtable.h.
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 20:17 ` Dan Rue
2018-03-27 20:27 ` Kani, Toshi
@ 2018-03-27 20:31 ` Nathan Chancellor
2018-03-27 20:40 ` Kani, Toshi
1 sibling, 1 reply; 64+ messages in thread
From: Nathan Chancellor @ 2018-03-27 20:31 UTC (permalink / raw)
To: Dan Rue
Cc: Greg Kroah-Hartman, linux-kernel, stable, Lei Li, Toshi Kani,
Catalin Marinas, Wang Xuefeng, Will Deacon, Hanjun Guo,
Michal Hocko, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Borislav Petkov, Matthew Wilcox, Chintan Pandya, Andrew Morton,
Linus Torvalds
On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Toshi Kani <toshi.kani@hpe.com>
> >
> > commit b6bdb7517c3d3f41f20e5c2948d6bc3f8897394e upstream.
> >
> > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
> > create pud/pmd mappings. A kernel panic was observed on arm64 systems
> > with Cortex-A75 in the following steps as described by Hanjun Guo.
> >
> > 1. ioremap a 4K size, valid page table will build,
> > 2. iounmap it, pte0 will set to 0;
> > 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
> > then set the a new value for pmd;
> > 4. pte0 is leaked;
> > 5. CPU may meet exception because the old pmd is still in TLB,
> > which will lead to kernel panic.
> >
> > This panic is not reproducible on x86. INVLPG, called from iounmap,
> > purges all levels of entries associated with purged address on x86. x86
> > still has memory leak.
> >
> > The patch changes the ioremap path to free unmapped page table(s) since
> > doing so in the unmap path has the following issues:
> >
> > - The iounmap() path is shared with vunmap(). Since vmap() only
> > supports pte mappings, making vunmap() to free a pte page is an
> > overhead for regular vmap users as they do not need a pte page freed
> > up.
> >
> > - Checking if all entries in a pte page are cleared in the unmap path
> > is racy, and serializing this check is expensive.
> >
> > - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
> > Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
> > purge.
> >
> > Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
> > clear a given pud/pmd entry and free up a page for the lower level
> > entries.
> >
> > This patch implements their stub functions on x86 and arm64, which work
> > as workaround.
> >
> > [akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
> > Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
> > Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
> > Reported-by: Lei Li <lious.lilei@hisilicon.com>
> > Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Hanjun Guo <guohanjun@huawei.com>
> > Cc: Michal Hocko <mhocko@suse.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: Borislav Petkov <bp@suse.de>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Chintan Pandya <cpandya@codeaurora.org>
> > Cc: <stable@vger.kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> This patch causes the following build error on 4.4 arm64:
>
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
>
> CC arch/arm64/mm/mmu.o
> ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> int pud_free_pmd_page(pud_t *pud)
> ^~~~~~~~~~~~~~~~~
> In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> from ../include/linux/mm.h:55,
> from ../include/linux/mman.h:4,
> from ../arch/arm64/mm/mmu.c:25:
> ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> static inline int pud_free_pmd_page(pud_t *pud)
> ^~~~~~~~~~~~~~~~~
> ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> int pmd_free_pte_page(pmd_t *pmd)
> ^~~~~~~~~~~~~~~~~
> In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> from ../include/linux/mm.h:55,
> from ../include/linux/mman.h:4,
> from ../arch/arm64/mm/mmu.c:25:
> ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> static inline int pmd_free_pte_page(pmd_t *pmd)
> ^~~~~~~~~~~~~~~~~
> make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> make: *** [Makefile:152: sub-make] Error 2
>
>
Both of my arm64 devices built fine with this patch... It seems like
the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
which seems impossible since it is selected by ARM64...
Someone smarter than I might have more insight but this patch is
unchanged from upstream so I can only assume that this error would
manifest there as well.
Cheers!
Nathan
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 20:31 ` Nathan Chancellor
@ 2018-03-27 20:40 ` Kani, Toshi
2018-03-27 20:47 ` Nathan Chancellor
0 siblings, 1 reply; 64+ messages in thread
From: Kani, Toshi @ 2018-03-27 20:40 UTC (permalink / raw)
To: dan.rue, natechancellor
Cc: linux-kernel, torvalds, bp, tglx, lious.lilei, guohanjun,
wxf.wang, stable, akpm, hpa, will.deacon, catalin.marinas, mingo,
gregkh, Hocko, Michal, cpandya, willy
On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > >
:
> >
> > This patch causes the following build error on 4.4 arm64:
> >
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> >
> > CC arch/arm64/mm/mmu.o
> > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > int pud_free_pmd_page(pud_t *pud)
> > ^~~~~~~~~~~~~~~~~
> > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > from ../include/linux/mm.h:55,
> > from ../include/linux/mman.h:4,
> > from ../arch/arm64/mm/mmu.c:25:
> > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > static inline int pud_free_pmd_page(pud_t *pud)
> > ^~~~~~~~~~~~~~~~~
> > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > int pmd_free_pte_page(pmd_t *pmd)
> > ^~~~~~~~~~~~~~~~~
> > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > from ../include/linux/mm.h:55,
> > from ../include/linux/mman.h:4,
> > from ../arch/arm64/mm/mmu.c:25:
> > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > static inline int pmd_free_pte_page(pmd_t *pmd)
> > ^~~~~~~~~~~~~~~~~
> > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > make: *** [Makefile:152: sub-make] Error 2
> >
> >
>
> Both of my arm64 devices built fine with this patch... It seems like
> the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> which seems impossible since it is selected by ARM64...
>
> Someone smarter than I might have more insight but this patch is
> unchanged from upstream so I can only assume that this error would
> manifest there as well.
It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
Hence the problem in 4.4.
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 20:40 ` Kani, Toshi
@ 2018-03-27 20:47 ` Nathan Chancellor
2018-03-28 6:32 ` gregkh
0 siblings, 1 reply; 64+ messages in thread
From: Nathan Chancellor @ 2018-03-27 20:47 UTC (permalink / raw)
To: Kani, Toshi
Cc: dan.rue, linux-kernel, torvalds, bp, tglx, lious.lilei,
guohanjun, wxf.wang, stable, akpm, hpa, will.deacon,
catalin.marinas, mingo, gregkh, Hocko, Michal, cpandya, willy
On Tue, Mar 27, 2018 at 08:40:56PM +0000, Kani, Toshi wrote:
> On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> > On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > >
> :
> > >
> > > This patch causes the following build error on 4.4 arm64:
> > >
> > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> > >
> > > CC arch/arm64/mm/mmu.o
> > > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > > int pud_free_pmd_page(pud_t *pud)
> > > ^~~~~~~~~~~~~~~~~
> > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > from ../include/linux/mm.h:55,
> > > from ../include/linux/mman.h:4,
> > > from ../arch/arm64/mm/mmu.c:25:
> > > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > > static inline int pud_free_pmd_page(pud_t *pud)
> > > ^~~~~~~~~~~~~~~~~
> > > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > > int pmd_free_pte_page(pmd_t *pmd)
> > > ^~~~~~~~~~~~~~~~~
> > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > from ../include/linux/mm.h:55,
> > > from ../include/linux/mman.h:4,
> > > from ../arch/arm64/mm/mmu.c:25:
> > > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > > static inline int pmd_free_pte_page(pmd_t *pmd)
> > > ^~~~~~~~~~~~~~~~~
> > > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > > make: *** [Makefile:152: sub-make] Error 2
> > >
> > >
> >
> > Both of my arm64 devices built fine with this patch... It seems like
> > the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> > which seems impossible since it is selected by ARM64...
> >
> > Someone smarter than I might have more insight but this patch is
> > unchanged from upstream so I can only assume that this error would
> > manifest there as well.
>
> It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
> Hence the problem in 4.4.
>
> Thanks,
> -Toshi
>
Ah, thanks for the heads up, since I have 324420bf91f6 ("arm64: add
support for ioremap() block mappings") in my tree due to Linaro's
backport of it for their Linaro Stable Kernel, which serves as a base
for most Android kernels. My apologies for not digging deeper and sorry
for the noise!
Cheers!
Nathan
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-27 20:47 ` Nathan Chancellor
@ 2018-03-28 6:32 ` gregkh
2018-03-28 6:47 ` Nathan Chancellor
0 siblings, 1 reply; 64+ messages in thread
From: gregkh @ 2018-03-28 6:32 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Kani, Toshi, dan.rue, linux-kernel, torvalds, bp, tglx,
lious.lilei, guohanjun, wxf.wang, stable, akpm, hpa, will.deacon,
catalin.marinas, mingo, Hocko, Michal, cpandya, willy
On Tue, Mar 27, 2018 at 01:47:55PM -0700, Nathan Chancellor wrote:
> On Tue, Mar 27, 2018 at 08:40:56PM +0000, Kani, Toshi wrote:
> > On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> > > On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > > > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > > >
> > :
> > > >
> > > > This patch causes the following build error on 4.4 arm64:
> > > >
> > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> > > >
> > > > CC arch/arm64/mm/mmu.o
> > > > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > > > int pud_free_pmd_page(pud_t *pud)
> > > > ^~~~~~~~~~~~~~~~~
> > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > from ../include/linux/mm.h:55,
> > > > from ../include/linux/mman.h:4,
> > > > from ../arch/arm64/mm/mmu.c:25:
> > > > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > > > static inline int pud_free_pmd_page(pud_t *pud)
> > > > ^~~~~~~~~~~~~~~~~
> > > > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > > > int pmd_free_pte_page(pmd_t *pmd)
> > > > ^~~~~~~~~~~~~~~~~
> > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > from ../include/linux/mm.h:55,
> > > > from ../include/linux/mman.h:4,
> > > > from ../arch/arm64/mm/mmu.c:25:
> > > > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > > > static inline int pmd_free_pte_page(pmd_t *pmd)
> > > > ^~~~~~~~~~~~~~~~~
> > > > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > > > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > > > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > > > make: *** [Makefile:152: sub-make] Error 2
> > > >
> > > >
> > >
> > > Both of my arm64 devices built fine with this patch... It seems like
> > > the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> > > which seems impossible since it is selected by ARM64...
> > >
> > > Someone smarter than I might have more insight but this patch is
> > > unchanged from upstream so I can only assume that this error would
> > > manifest there as well.
> >
> > It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
> > Hence the problem in 4.4.
> >
> > Thanks,
> > -Toshi
> >
>
> Ah, thanks for the heads up, since I have 324420bf91f6 ("arm64: add
> support for ioremap() block mappings") in my tree due to Linaro's
> backport of it for their Linaro Stable Kernel, which serves as a base
> for most Android kernels. My apologies for not digging deeper and sorry
> for the noise!
So should I just drop this patch?
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-28 6:32 ` gregkh
@ 2018-03-28 6:47 ` Nathan Chancellor
2018-03-28 9:58 ` gregkh
0 siblings, 1 reply; 64+ messages in thread
From: Nathan Chancellor @ 2018-03-28 6:47 UTC (permalink / raw)
To: gregkh
Cc: Kani, Toshi, dan.rue, linux-kernel, torvalds, bp, tglx,
lious.lilei, guohanjun, wxf.wang, stable, akpm, hpa, will.deacon,
catalin.marinas, mingo, Hocko, Michal, cpandya, willy
On Wed, Mar 28, 2018 at 08:32:02AM +0200, gregkh@linuxfoundation.org wrote:
> On Tue, Mar 27, 2018 at 01:47:55PM -0700, Nathan Chancellor wrote:
> > On Tue, Mar 27, 2018 at 08:40:56PM +0000, Kani, Toshi wrote:
> > > On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> > > > On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > > > > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > > > >
> > > :
> > > > >
> > > > > This patch causes the following build error on 4.4 arm64:
> > > > >
> > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> > > > >
> > > > > CC arch/arm64/mm/mmu.o
> > > > > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > > > > int pud_free_pmd_page(pud_t *pud)
> > > > > ^~~~~~~~~~~~~~~~~
> > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > from ../include/linux/mm.h:55,
> > > > > from ../include/linux/mman.h:4,
> > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > > > > static inline int pud_free_pmd_page(pud_t *pud)
> > > > > ^~~~~~~~~~~~~~~~~
> > > > > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > > > > int pmd_free_pte_page(pmd_t *pmd)
> > > > > ^~~~~~~~~~~~~~~~~
> > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > from ../include/linux/mm.h:55,
> > > > > from ../include/linux/mman.h:4,
> > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > > > > static inline int pmd_free_pte_page(pmd_t *pmd)
> > > > > ^~~~~~~~~~~~~~~~~
> > > > > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > > > > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > > > > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > > > > make: *** [Makefile:152: sub-make] Error 2
> > > > >
> > > > >
> > > >
> > > > Both of my arm64 devices built fine with this patch... It seems like
> > > > the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> > > > which seems impossible since it is selected by ARM64...
> > > >
> > > > Someone smarter than I might have more insight but this patch is
> > > > unchanged from upstream so I can only assume that this error would
> > > > manifest there as well.
> > >
> > > It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
> > > Hence the problem in 4.4.
> > >
> > > Thanks,
> > > -Toshi
> > >
> >
> > Ah, thanks for the heads up, since I have 324420bf91f6 ("arm64: add
> > support for ioremap() block mappings") in my tree due to Linaro's
> > backport of it for their Linaro Stable Kernel, which serves as a base
> > for most Android kernels. My apologies for not digging deeper and sorry
> > for the noise!
>
> So should I just drop this patch?
Unless I am reading the commit message wrong and ignoring the fact that
the mainling commit applied cleanly to 4.4.124, it seems like this is
still relevant for x86.
Toshi suggested dropping the changes to arch/arm64/mm/mmu.c, which won't
be a problem for arm64 devices running the stable kernels as they come
because they don't have HAVE_ARCH_HUGE_VMAP so they shouldn't be hitting
the bug mentioned in the commit message anyways.
However, for Android devices which have the mainline commit I mentioned
above introducing HAVE_ARCH_HUGE_VMAP, dropping those changes would mean
this commit isn't fixing the issue it mentions, which they would be able
to hit in theory.
I don't know how you want to handle that but a simple suggestion that
would not change the end result of the patch for both the stable tree
and frankenkernels would be to add a simple
#ifdef CONFIG_ARCH_HAVE_HUGE_VMAP
around the changes in arch/arm64/mm/mmu.c.
I'll let you be the final judge though! Cheers,
Nathan
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-28 6:47 ` Nathan Chancellor
@ 2018-03-28 9:58 ` gregkh
2018-03-28 15:06 ` Kani, Toshi
0 siblings, 1 reply; 64+ messages in thread
From: gregkh @ 2018-03-28 9:58 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Kani, Toshi, dan.rue, linux-kernel, torvalds, bp, tglx,
lious.lilei, guohanjun, wxf.wang, stable, akpm, hpa, will.deacon,
catalin.marinas, mingo, Hocko, Michal, cpandya, willy
On Tue, Mar 27, 2018 at 11:47:18PM -0700, Nathan Chancellor wrote:
> On Wed, Mar 28, 2018 at 08:32:02AM +0200, gregkh@linuxfoundation.org wrote:
> > On Tue, Mar 27, 2018 at 01:47:55PM -0700, Nathan Chancellor wrote:
> > > On Tue, Mar 27, 2018 at 08:40:56PM +0000, Kani, Toshi wrote:
> > > > On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> > > > > On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > > > > > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > > > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > > > > >
> > > > :
> > > > > >
> > > > > > This patch causes the following build error on 4.4 arm64:
> > > > > >
> > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> > > > > >
> > > > > > CC arch/arm64/mm/mmu.o
> > > > > > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > > > > > int pud_free_pmd_page(pud_t *pud)
> > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > > from ../include/linux/mm.h:55,
> > > > > > from ../include/linux/mman.h:4,
> > > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > > > > > static inline int pud_free_pmd_page(pud_t *pud)
> > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > > > > > int pmd_free_pte_page(pmd_t *pmd)
> > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > > from ../include/linux/mm.h:55,
> > > > > > from ../include/linux/mman.h:4,
> > > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > > > > > static inline int pmd_free_pte_page(pmd_t *pmd)
> > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > > > > > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > > > > > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > > > > > make: *** [Makefile:152: sub-make] Error 2
> > > > > >
> > > > > >
> > > > >
> > > > > Both of my arm64 devices built fine with this patch... It seems like
> > > > > the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> > > > > which seems impossible since it is selected by ARM64...
> > > > >
> > > > > Someone smarter than I might have more insight but this patch is
> > > > > unchanged from upstream so I can only assume that this error would
> > > > > manifest there as well.
> > > >
> > > > It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
> > > > Hence the problem in 4.4.
> > > >
> > > > Thanks,
> > > > -Toshi
> > > >
> > >
> > > Ah, thanks for the heads up, since I have 324420bf91f6 ("arm64: add
> > > support for ioremap() block mappings") in my tree due to Linaro's
> > > backport of it for their Linaro Stable Kernel, which serves as a base
> > > for most Android kernels. My apologies for not digging deeper and sorry
> > > for the noise!
> >
> > So should I just drop this patch?
>
> Unless I am reading the commit message wrong and ignoring the fact that
> the mainling commit applied cleanly to 4.4.124, it seems like this is
> still relevant for x86.
>
> Toshi suggested dropping the changes to arch/arm64/mm/mmu.c, which won't
> be a problem for arm64 devices running the stable kernels as they come
> because they don't have HAVE_ARCH_HUGE_VMAP so they shouldn't be hitting
> the bug mentioned in the commit message anyways.
>
> However, for Android devices which have the mainline commit I mentioned
> above introducing HAVE_ARCH_HUGE_VMAP, dropping those changes would mean
> this commit isn't fixing the issue it mentions, which they would be able
> to hit in theory.
>
> I don't know how you want to handle that but a simple suggestion that
> would not change the end result of the patch for both the stable tree
> and frankenkernels would be to add a simple
>
> #ifdef CONFIG_ARCH_HAVE_HUGE_VMAP
>
> around the changes in arch/arm64/mm/mmu.c.
>
> I'll let you be the final judge though! Cheers,
That's a good idea about the #ifdef, I've updated the patch to be like
this, and pushed out a -rc2 with that change in it.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-28 9:58 ` gregkh
@ 2018-03-28 15:06 ` Kani, Toshi
2018-03-28 16:16 ` gregkh
0 siblings, 1 reply; 64+ messages in thread
From: Kani, Toshi @ 2018-03-28 15:06 UTC (permalink / raw)
To: gregkh, natechancellor
Cc: linux-kernel, torvalds, tglx, lious.lilei, dan.rue, wxf.wang,
guohanjun, bp, stable, akpm, hpa, will.deacon, catalin.marinas,
mingo, Hocko, Michal, cpandya, willy
On Wed, 2018-03-28 at 11:58 +0200, gregkh@linuxfoundation.org wrote:
> On Tue, Mar 27, 2018 at 11:47:18PM -0700, Nathan Chancellor wrote:
> > On Wed, Mar 28, 2018 at 08:32:02AM +0200, gregkh@linuxfoundation.org wrote:
> > > On Tue, Mar 27, 2018 at 01:47:55PM -0700, Nathan Chancellor wrote:
> > > > On Tue, Mar 27, 2018 at 08:40:56PM +0000, Kani, Toshi wrote:
> > > > > On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> > > > > > On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > > > > > > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > > > > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > > > > > >
> > > > >
> > > > > :
> > > > > > >
> > > > > > > This patch causes the following build error on 4.4 arm64:
> > > > > > >
> > > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> > > > > > >
> > > > > > > CC arch/arm64/mm/mmu.o
> > > > > > > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > > > > > > int pud_free_pmd_page(pud_t *pud)
> > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > > > from ../include/linux/mm.h:55,
> > > > > > > from ../include/linux/mman.h:4,
> > > > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > > > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > > > > > > static inline int pud_free_pmd_page(pud_t *pud)
> > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > > > > > > int pmd_free_pte_page(pmd_t *pmd)
> > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > > > from ../include/linux/mm.h:55,
> > > > > > > from ../include/linux/mman.h:4,
> > > > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > > > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > > > > > > static inline int pmd_free_pte_page(pmd_t *pmd)
> > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > > > > > > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > > > > > > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > > > > > > make: *** [Makefile:152: sub-make] Error 2
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Both of my arm64 devices built fine with this patch... It seems like
> > > > > > the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> > > > > > which seems impossible since it is selected by ARM64...
> > > > > >
> > > > > > Someone smarter than I might have more insight but this patch is
> > > > > > unchanged from upstream so I can only assume that this error would
> > > > > > manifest there as well.
> > > > >
> > > > > It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
> > > > > Hence the problem in 4.4.
> > > > >
> > > > > Thanks,
> > > > > -Toshi
> > > > >
> > > >
> > > > Ah, thanks for the heads up, since I have 324420bf91f6 ("arm64: add
> > > > support for ioremap() block mappings") in my tree due to Linaro's
> > > > backport of it for their Linaro Stable Kernel, which serves as a base
> > > > for most Android kernels. My apologies for not digging deeper and sorry
> > > > for the noise!
> > >
> > > So should I just drop this patch?
> >
> > Unless I am reading the commit message wrong and ignoring the fact that
> > the mainling commit applied cleanly to 4.4.124, it seems like this is
> > still relevant for x86.
> >
> > Toshi suggested dropping the changes to arch/arm64/mm/mmu.c, which won't
> > be a problem for arm64 devices running the stable kernels as they come
> > because they don't have HAVE_ARCH_HUGE_VMAP so they shouldn't be hitting
> > the bug mentioned in the commit message anyways.
> >
> > However, for Android devices which have the mainline commit I mentioned
> > above introducing HAVE_ARCH_HUGE_VMAP, dropping those changes would mean
> > this commit isn't fixing the issue it mentions, which they would be able
> > to hit in theory.
> >
> > I don't know how you want to handle that but a simple suggestion that
> > would not change the end result of the patch for both the stable tree
> > and frankenkernels would be to add a simple
> >
> > #ifdef CONFIG_ARCH_HAVE_HUGE_VMAP
> >
> > around the changes in arch/arm64/mm/mmu.c.
Agreed.
> > I'll let you be the final judge though! Cheers,
>
> That's a good idea about the #ifdef, I've updated the patch to be like
> this, and pushed out a -rc2 with that change in it.
Great! Please note that Patch 4.4 21/43 applies on top of this 20/43
patch.
Thanks!
-Toshi
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table
2018-03-28 15:06 ` Kani, Toshi
@ 2018-03-28 16:16 ` gregkh
0 siblings, 0 replies; 64+ messages in thread
From: gregkh @ 2018-03-28 16:16 UTC (permalink / raw)
To: Kani, Toshi
Cc: natechancellor, linux-kernel, torvalds, tglx, lious.lilei,
dan.rue, wxf.wang, guohanjun, bp, stable, akpm, hpa, will.deacon,
catalin.marinas, mingo, Hocko, Michal, cpandya, willy
On Wed, Mar 28, 2018 at 03:06:38PM +0000, Kani, Toshi wrote:
> On Wed, 2018-03-28 at 11:58 +0200, gregkh@linuxfoundation.org wrote:
> > On Tue, Mar 27, 2018 at 11:47:18PM -0700, Nathan Chancellor wrote:
> > > On Wed, Mar 28, 2018 at 08:32:02AM +0200, gregkh@linuxfoundation.org wrote:
> > > > On Tue, Mar 27, 2018 at 01:47:55PM -0700, Nathan Chancellor wrote:
> > > > > On Tue, Mar 27, 2018 at 08:40:56PM +0000, Kani, Toshi wrote:
> > > > > > On Tue, 2018-03-27 at 13:31 -0700, Nathan Chancellor wrote:
> > > > > > > On Tue, Mar 27, 2018 at 03:17:00PM -0500, Dan Rue wrote:
> > > > > > > > On Tue, Mar 27, 2018 at 06:27:24PM +0200, Greg Kroah-Hartman wrote:
> > > > > > > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > > > > > > >
> > > > > >
> > > > > > :
> > > > > > > >
> > > > > > > > This patch causes the following build error on 4.4 arm64:
> > > > > > > >
> > > > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64 defconfig
> > > > > > > > $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=build-arm64
> > > > > > > >
> > > > > > > > CC arch/arm64/mm/mmu.o
> > > > > > > > ../arch/arm64/mm/mmu.c:701:5: error: redefinition of ‘pud_free_pmd_page’
> > > > > > > > int pud_free_pmd_page(pud_t *pud)
> > > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > > > > from ../include/linux/mm.h:55,
> > > > > > > > from ../include/linux/mman.h:4,
> > > > > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > > > > ../include/asm-generic/pgtable.h:777:19: note: previous definition of ‘pud_free_pmd_page’ was here
> > > > > > > > static inline int pud_free_pmd_page(pud_t *pud)
> > > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > > ../arch/arm64/mm/mmu.c:706:5: error: redefinition of ‘pmd_free_pte_page’
> > > > > > > > int pmd_free_pte_page(pmd_t *pmd)
> > > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > > In file included from ../arch/arm64/include/asm/pgtable.h:682:0,
> > > > > > > > from ../include/linux/mm.h:55,
> > > > > > > > from ../include/linux/mman.h:4,
> > > > > > > > from ../arch/arm64/mm/mmu.c:25:
> > > > > > > > ../include/asm-generic/pgtable.h:781:19: note: previous definition of ‘pmd_free_pte_page’ was here
> > > > > > > > static inline int pmd_free_pte_page(pmd_t *pmd)
> > > > > > > > ^~~~~~~~~~~~~~~~~
> > > > > > > > make[2]: *** [../scripts/Makefile.build:270: arch/arm64/mm/mmu.o] Error 1
> > > > > > > > make[1]: *** [/home/drue/src/linux/4.4-rc/Makefile:969: arch/arm64/mm] Error 2
> > > > > > > > make[1]: Leaving directory '/home/drue/src/linux/4.4-rc/build-arm64'
> > > > > > > > make: *** [Makefile:152: sub-make] Error 2
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Both of my arm64 devices built fine with this patch... It seems like
> > > > > > > the only way to hit that error is if HAVE_ARCH_HUGE_VMAP isn't set,
> > > > > > > which seems impossible since it is selected by ARM64...
> > > > > > >
> > > > > > > Someone smarter than I might have more insight but this patch is
> > > > > > > unchanged from upstream so I can only assume that this error would
> > > > > > > manifest there as well.
> > > > > >
> > > > > > It appears that HAVE_ARCH_HUGE_VMAP was introduced in 4.6 on arm64.
> > > > > > Hence the problem in 4.4.
> > > > > >
> > > > > > Thanks,
> > > > > > -Toshi
> > > > > >
> > > > >
> > > > > Ah, thanks for the heads up, since I have 324420bf91f6 ("arm64: add
> > > > > support for ioremap() block mappings") in my tree due to Linaro's
> > > > > backport of it for their Linaro Stable Kernel, which serves as a base
> > > > > for most Android kernels. My apologies for not digging deeper and sorry
> > > > > for the noise!
> > > >
> > > > So should I just drop this patch?
> > >
> > > Unless I am reading the commit message wrong and ignoring the fact that
> > > the mainling commit applied cleanly to 4.4.124, it seems like this is
> > > still relevant for x86.
> > >
> > > Toshi suggested dropping the changes to arch/arm64/mm/mmu.c, which won't
> > > be a problem for arm64 devices running the stable kernels as they come
> > > because they don't have HAVE_ARCH_HUGE_VMAP so they shouldn't be hitting
> > > the bug mentioned in the commit message anyways.
> > >
> > > However, for Android devices which have the mainline commit I mentioned
> > > above introducing HAVE_ARCH_HUGE_VMAP, dropping those changes would mean
> > > this commit isn't fixing the issue it mentions, which they would be able
> > > to hit in theory.
> > >
> > > I don't know how you want to handle that but a simple suggestion that
> > > would not change the end result of the patch for both the stable tree
> > > and frankenkernels would be to add a simple
> > >
> > > #ifdef CONFIG_ARCH_HAVE_HUGE_VMAP
> > >
> > > around the changes in arch/arm64/mm/mmu.c.
>
> Agreed.
>
> > > I'll let you be the final judge though! Cheers,
> >
> > That's a good idea about the #ifdef, I've updated the patch to be like
> > this, and pushed out a -rc2 with that change in it.
>
> Great! Please note that Patch 4.4 21/43 applies on top of this 20/43
> patch.
Yes, that patch did not get modified and sayed as-is.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4.4 21/43] x86/mm: implement free pmd/pte page interfaces
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 20/43] mm/vmalloc: add interfaces to free unmapped page table Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 22/43] drm/vmwgfx: Fix a destoy-while-held mutex problem Greg Kroah-Hartman
` (27 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Toshi Kani, Lei Li, Michal Hocko,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Borislav Petkov,
Matthew Wilcox, Andrew Morton, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toshi Kani <toshi.kani@hpe.com>
commit 28ee90fe6048fa7b7ceaeb8831c0e4e454a4cf89 upstream.
Implement pud_free_pmd_page() and pmd_free_pte_page() on x86, which
clear a given pud/pmd entry and free up lower level page table(s).
The address range associated with the pud/pmd entry must have been
purged by INVLPG.
Link: http://lkml.kernel.org/r/20180314180155.19492-3-toshi.kani@hpe.com
Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings")
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Reported-by: Lei Li <lious.lilei@hisilicon.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/mm/pgtable.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -676,7 +676,22 @@ int pmd_clear_huge(pmd_t *pmd)
*/
int pud_free_pmd_page(pud_t *pud)
{
- return pud_none(*pud);
+ pmd_t *pmd;
+ int i;
+
+ if (pud_none(*pud))
+ return 1;
+
+ pmd = (pmd_t *)pud_page_vaddr(*pud);
+
+ for (i = 0; i < PTRS_PER_PMD; i++)
+ if (!pmd_free_pte_page(&pmd[i]))
+ return 0;
+
+ pud_clear(pud);
+ free_page((unsigned long)pmd);
+
+ return 1;
}
/**
@@ -688,6 +703,15 @@ int pud_free_pmd_page(pud_t *pud)
*/
int pmd_free_pte_page(pmd_t *pmd)
{
- return pmd_none(*pmd);
+ pte_t *pte;
+
+ if (pmd_none(*pmd))
+ return 1;
+
+ pte = (pte_t *)pmd_page_vaddr(*pmd);
+ pmd_clear(pmd);
+ free_page((unsigned long)pte);
+
+ return 1;
}
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 22/43] drm/vmwgfx: Fix a destoy-while-held mutex problem.
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 21/43] x86/mm: implement free pmd/pte page interfaces Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 23/43] drm/radeon: Dont turn off DP sink when disconnected Greg Kroah-Hartman
` (26 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Hellstrom, Brian Paul, Sinclair Yeh
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Hellstrom <thellstrom@vmware.com>
commit 73a88250b70954a8f27c2444e1c2411bba3c29d9 upstream.
When validating legacy surfaces, the backup bo might be destroyed at
surface validate time. However, the kms resource validation code may have
the bo reserved, so we will destroy a locked mutex. While there shouldn't
be any other users of that mutex when it is destroyed, it causes a lock
leak and thus throws a lockdep error.
Fix this by having the kms resource validation code hold a reference to
the bo while we have it reserved. We do this by introducing a validation
context which might come in handy when the kms code is extended to validate
multiple resources or buffers.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 +++++++++++++++++++---------
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 12 +++++++++---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +++--
4 files changed, 34 insertions(+), 16 deletions(-)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -27,7 +27,6 @@
#include "vmwgfx_kms.h"
-
/* Might need a hrtimer here? */
#define VMWGFX_PRESENT_RATE ((HZ / 60 > 0) ? HZ / 60 : 1)
@@ -1910,9 +1909,12 @@ void vmw_kms_helper_buffer_finish(struct
* Helper to be used if an error forces the caller to undo the actions of
* vmw_kms_helper_resource_prepare.
*/
-void vmw_kms_helper_resource_revert(struct vmw_resource *res)
+void vmw_kms_helper_resource_revert(struct vmw_validation_ctx *ctx)
{
- vmw_kms_helper_buffer_revert(res->backup);
+ struct vmw_resource *res = ctx->res;
+
+ vmw_kms_helper_buffer_revert(ctx->buf);
+ vmw_dmabuf_unreference(&ctx->buf);
vmw_resource_unreserve(res, false, NULL, 0);
mutex_unlock(&res->dev_priv->cmdbuf_mutex);
}
@@ -1929,10 +1931,14 @@ void vmw_kms_helper_resource_revert(stru
* interrupted by a signal.
*/
int vmw_kms_helper_resource_prepare(struct vmw_resource *res,
- bool interruptible)
+ bool interruptible,
+ struct vmw_validation_ctx *ctx)
{
int ret = 0;
+ ctx->buf = NULL;
+ ctx->res = res;
+
if (interruptible)
ret = mutex_lock_interruptible(&res->dev_priv->cmdbuf_mutex);
else
@@ -1951,6 +1957,8 @@ int vmw_kms_helper_resource_prepare(stru
res->dev_priv->has_mob);
if (ret)
goto out_unreserve;
+
+ ctx->buf = vmw_dmabuf_reference(res->backup);
}
ret = vmw_resource_validate(res);
if (ret)
@@ -1958,7 +1966,7 @@ int vmw_kms_helper_resource_prepare(stru
return 0;
out_revert:
- vmw_kms_helper_buffer_revert(res->backup);
+ vmw_kms_helper_buffer_revert(ctx->buf);
out_unreserve:
vmw_resource_unreserve(res, false, NULL, 0);
out_unlock:
@@ -1974,11 +1982,13 @@ out_unlock:
* @out_fence: Optional pointer to a fence pointer. If non-NULL, a
* ref-counted fence pointer is returned here.
*/
-void vmw_kms_helper_resource_finish(struct vmw_resource *res,
- struct vmw_fence_obj **out_fence)
+void vmw_kms_helper_resource_finish(struct vmw_validation_ctx *ctx,
+ struct vmw_fence_obj **out_fence)
{
- if (res->backup || out_fence)
- vmw_kms_helper_buffer_finish(res->dev_priv, NULL, res->backup,
+ struct vmw_resource *res = ctx->res;
+
+ if (ctx->buf || out_fence)
+ vmw_kms_helper_buffer_finish(res->dev_priv, NULL, ctx->buf,
out_fence, NULL);
vmw_resource_unreserve(res, false, NULL, 0);
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -180,6 +180,11 @@ struct vmw_display_unit {
bool is_implicit;
};
+struct vmw_validation_ctx {
+ struct vmw_resource *res;
+ struct vmw_dma_buffer *buf;
+};
+
#define vmw_crtc_to_du(x) \
container_of(x, struct vmw_display_unit, crtc)
#define vmw_connector_to_du(x) \
@@ -230,9 +235,10 @@ void vmw_kms_helper_buffer_finish(struct
struct drm_vmw_fence_rep __user *
user_fence_rep);
int vmw_kms_helper_resource_prepare(struct vmw_resource *res,
- bool interruptible);
-void vmw_kms_helper_resource_revert(struct vmw_resource *res);
-void vmw_kms_helper_resource_finish(struct vmw_resource *res,
+ bool interruptible,
+ struct vmw_validation_ctx *ctx);
+void vmw_kms_helper_resource_revert(struct vmw_validation_ctx *ctx);
+void vmw_kms_helper_resource_finish(struct vmw_validation_ctx *ctx,
struct vmw_fence_obj **out_fence);
int vmw_kms_readback(struct vmw_private *dev_priv,
struct drm_file *file_priv,
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -841,12 +841,13 @@ int vmw_kms_sou_do_surface_dirty(struct
struct vmw_framebuffer_surface *vfbs =
container_of(framebuffer, typeof(*vfbs), base);
struct vmw_kms_sou_surface_dirty sdirty;
+ struct vmw_validation_ctx ctx;
int ret;
if (!srf)
srf = &vfbs->surface->res;
- ret = vmw_kms_helper_resource_prepare(srf, true);
+ ret = vmw_kms_helper_resource_prepare(srf, true, &ctx);
if (ret)
return ret;
@@ -865,7 +866,7 @@ int vmw_kms_sou_do_surface_dirty(struct
ret = vmw_kms_helper_dirty(dev_priv, framebuffer, clips, vclips,
dest_x, dest_y, num_clips, inc,
&sdirty.base);
- vmw_kms_helper_resource_finish(srf, out_fence);
+ vmw_kms_helper_resource_finish(&ctx, out_fence);
return ret;
}
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1003,12 +1003,13 @@ int vmw_kms_stdu_surface_dirty(struct vm
struct vmw_framebuffer_surface *vfbs =
container_of(framebuffer, typeof(*vfbs), base);
struct vmw_stdu_dirty sdirty;
+ struct vmw_validation_ctx ctx;
int ret;
if (!srf)
srf = &vfbs->surface->res;
- ret = vmw_kms_helper_resource_prepare(srf, true);
+ ret = vmw_kms_helper_resource_prepare(srf, true, &ctx);
if (ret)
return ret;
@@ -1031,7 +1032,7 @@ int vmw_kms_stdu_surface_dirty(struct vm
dest_x, dest_y, num_clips, inc,
&sdirty.base);
out_finish:
- vmw_kms_helper_resource_finish(srf, out_fence);
+ vmw_kms_helper_resource_finish(&ctx, out_fence);
return ret;
}
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 23/43] drm/radeon: Dont turn off DP sink when disconnected
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 22/43] drm/vmwgfx: Fix a destoy-while-held mutex problem Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 24/43] drm: udl: Properly check framebuffer mmap offsets Greg Kroah-Hartman
` (25 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher, Michel Dänzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michel Dänzer <michel.daenzer@amd.com>
commit 2681bc79eeb640562c932007bfebbbdc55bf6a7d upstream.
Turning off the sink in this case causes various issues, because
userspace expects it to stay on until it turns it off explicitly.
Instead, turn the sink off and back on when a display is connected
again. This dance seems necessary for link training to work correctly.
Bugzilla: https://bugs.freedesktop.org/105308
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_connectors.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -89,25 +89,18 @@ void radeon_connector_hotplug(struct drm
/* don't do anything if sink is not display port, i.e.,
* passive dp->(dvi|hdmi) adaptor
*/
- if (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) {
- int saved_dpms = connector->dpms;
- /* Only turn off the display if it's physically disconnected */
- if (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd)) {
- drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
- } else if (radeon_dp_needs_link_train(radeon_connector)) {
- /* Don't try to start link training before we
- * have the dpcd */
- if (!radeon_dp_getdpcd(radeon_connector))
- return;
+ if (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT &&
+ radeon_hpd_sense(rdev, radeon_connector->hpd.hpd) &&
+ radeon_dp_needs_link_train(radeon_connector)) {
+ /* Don't start link training before we have the DPCD */
+ if (!radeon_dp_getdpcd(radeon_connector))
+ return;
- /* set it to OFF so that drm_helper_connector_dpms()
- * won't return immediately since the current state
- * is ON at this point.
- */
- connector->dpms = DRM_MODE_DPMS_OFF;
- drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
- }
- connector->dpms = saved_dpms;
+ /* Turn the connector off and back on immediately, which
+ * will trigger link training
+ */
+ drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+ drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON);
}
}
}
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 24/43] drm: udl: Properly check framebuffer mmap offsets
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 23/43] drm/radeon: Dont turn off DP sink when disconnected Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 25/43] acpi, numa: fix pxm to online numa node associations Greg Kroah-Hartman
` (24 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Eyal Itkin, Daniel Vetter
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3b82a4db8eaccce735dffd50b4d4e1578099b8e8 upstream.
The memmap options sent to the udl framebuffer driver were not being
checked for all sets of possible crazy values. Fix this up by properly
bounding the allowed values.
Reported-by: Eyal Itkin <eyalit@checkpoint.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180321154553.GA18454@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/udl/udl_fb.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -256,10 +256,15 @@ static int udl_fb_mmap(struct fb_info *i
{
unsigned long start = vma->vm_start;
unsigned long size = vma->vm_end - vma->vm_start;
- unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
+ unsigned long offset;
unsigned long page, pos;
- if (offset + size > info->fix.smem_len)
+ if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
+ return -EINVAL;
+
+ offset = vma->vm_pgoff << PAGE_SHIFT;
+
+ if (offset > info->fix.smem_len || size > info->fix.smem_len - offset)
return -EINVAL;
pos = (unsigned long)info->fix.smem_start + offset;
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 25/43] acpi, numa: fix pxm to online numa node associations
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 24/43] drm: udl: Properly check framebuffer mmap offsets Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 26/43] brcmfmac: fix P2P_DEVICE ethernet address generation Greg Kroah-Hartman
` (23 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Toshi Kani, Dan Williams
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit dc9e0a9347e932e3fd3cd03e7ff241022ed6ea8a upstream.
Commit 99759869faf1 "acpi: Add acpi_map_pxm_to_online_node()" added
support for mapping a given proximity to its nearest, by SLIT distance,
online node. However, it sometimes returns unexpected results due to the
fact that it switches from comparing the PXM node to the last node that
was closer than the current max.
for_each_online_node(n) {
dist = node_distance(node, n);
if (dist < min_dist) {
min_dist = dist;
node = n; <---- from this point we're using the
wrong node for node_distance()
Fixes: 99759869faf1 ("acpi: Add acpi_map_pxm_to_online_node()")
Cc: <stable@vger.kernel.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/numa.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -103,25 +103,27 @@ int acpi_map_pxm_to_node(int pxm)
*/
int acpi_map_pxm_to_online_node(int pxm)
{
- int node, n, dist, min_dist;
+ int node, min_node;
node = acpi_map_pxm_to_node(pxm);
if (node == NUMA_NO_NODE)
node = 0;
+ min_node = node;
if (!node_online(node)) {
- min_dist = INT_MAX;
+ int min_dist = INT_MAX, dist, n;
+
for_each_online_node(n) {
dist = node_distance(node, n);
if (dist < min_dist) {
min_dist = dist;
- node = n;
+ min_node = n;
}
}
}
- return node;
+ return min_node;
}
EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 26/43] brcmfmac: fix P2P_DEVICE ethernet address generation
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 25/43] acpi, numa: fix pxm to online numa node associations Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 27/43] rtlwifi: rtl8723be: Fix loss of signal Greg Kroah-Hartman
` (22 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, Arend van Spriel, Kalle Valo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arend Van Spriel <arend.vanspriel@broadcom.com>
commit 455f3e76cfc0d893585a5f358b9ddbe9c1e1e53b upstream.
The firmware has a requirement that the P2P_DEVICE address should
be different from the address of the primary interface. When not
specified by user-space, the driver generates the MAC address for
the P2P_DEVICE interface using the MAC address of the primary
interface and setting the locally administered bit. However, the MAC
address of the primary interface may already have that bit set causing
the creation of the P2P_DEVICE interface to fail with -EBUSY. Fix this
by using a random address instead to determine the P2P_DEVICE address.
Cc: stable@vger.kernel.org # 3.10.y
Reported-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
--- a/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/p2p.c
@@ -461,25 +461,23 @@ static int brcmf_p2p_set_firmware(struct
* @dev_addr: optional device address.
*
* P2P needs mac addresses for P2P device and interface. If no device
- * address it specified, these are derived from the primary net device, ie.
- * the permanent ethernet address of the device.
+ * address it specified, these are derived from a random ethernet
+ * address.
*/
static void brcmf_p2p_generate_bss_mac(struct brcmf_p2p_info *p2p, u8 *dev_addr)
{
- struct brcmf_if *pri_ifp = p2p->bss_idx[P2PAPI_BSSCFG_PRIMARY].vif->ifp;
- bool local_admin = false;
+ bool random_addr = false;
- if (!dev_addr || is_zero_ether_addr(dev_addr)) {
- dev_addr = pri_ifp->mac_addr;
- local_admin = true;
- }
+ if (!dev_addr || is_zero_ether_addr(dev_addr))
+ random_addr = true;
- /* Generate the P2P Device Address. This consists of the device's
- * primary MAC address with the locally administered bit set.
+ /* Generate the P2P Device Address obtaining a random ethernet
+ * address with the locally administered bit set.
*/
- memcpy(p2p->dev_addr, dev_addr, ETH_ALEN);
- if (local_admin)
- p2p->dev_addr[0] |= 0x02;
+ if (random_addr)
+ eth_random_addr(p2p->dev_addr);
+ else
+ memcpy(p2p->dev_addr, dev_addr, ETH_ALEN);
/* Generate the P2P Interface Address. If the discovery and connection
* BSSCFGs need to simultaneously co-exist, then this address must be
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 27/43] rtlwifi: rtl8723be: Fix loss of signal
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 26/43] brcmfmac: fix P2P_DEVICE ethernet address generation Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 28/43] tracing: probeevent: Fix to support minus offset from symbol Greg Kroah-Hartman
` (21 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Larry Finger, James Cameron, Kalle Valo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <Larry.Finger@lwfinger.net>
commit 78dc897b7ee67205423dbbc6b56be49fb18d15b5 upstream.
In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Tested-by: James Cameron <quozl@laptop.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1123,7 +1123,8 @@ static void _rtl8723be_enable_aspm_back_
/* Configuration Space offset 0x70f BIT7 is used to control L0S */
tmp8 = _rtl8723be_dbi_read(rtlpriv, 0x70f);
- _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7));
+ _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7) |
+ ASPM_L1_LATENCY << 3);
/* Configuration Space offset 0x719 Bit3 is for L1
* BIT4 is for clock request
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 28/43] tracing: probeevent: Fix to support minus offset from symbol
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 27/43] rtlwifi: rtl8723be: Fix loss of signal Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 29/43] mtd: nand: fsl_ifc: Fix nand waitfunc return value Greg Kroah-Hartman
` (20 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ingo Molnar, Tom Zanussi,
Arnaldo Carvalho de Melo, Ravi Bangoria, Namhyung Kim,
Masami Hiramatsu, Steven Rostedt (VMware)
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masami Hiramatsu <mhiramat@kernel.org>
commit c5d343b6b7badd1f5fe0873eff2e8d63a193e732 upstream.
In Documentation/trace/kprobetrace.txt, it says
@SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol)
However, the parser doesn't parse minus offset correctly, since
commit 2fba0c8867af ("tracing/kprobes: Fix probe offset to be
unsigned") drops minus ("-") offset support for kprobe probe
address usage.
This fixes the traceprobe_split_symbol_offset() to parse minus
offset again with checking the offset range, and add a minus
offset check in kprobe probe address usage.
Link: http://lkml.kernel.org/r/152129028983.31874.13419301530285775521.stgit@devbox
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Fixes: 2fba0c8867af ("tracing/kprobes: Fix probe offset to be unsigned")
Acked-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/trace_kprobe.c | 4 ++--
kernel/trace/trace_probe.c | 8 +++-----
kernel/trace/trace_probe.h | 2 +-
3 files changed, 6 insertions(+), 8 deletions(-)
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -599,7 +599,7 @@ static int create_trace_kprobe(int argc,
bool is_return = false, is_delete = false;
char *symbol = NULL, *event = NULL, *group = NULL;
char *arg;
- unsigned long offset = 0;
+ long offset = 0;
void *addr = NULL;
char buf[MAX_EVENT_NAME_LEN];
@@ -667,7 +667,7 @@ static int create_trace_kprobe(int argc,
symbol = argv[1];
/* TODO: support .init module functions */
ret = traceprobe_split_symbol_offset(symbol, &offset);
- if (ret) {
+ if (ret || offset < 0 || offset > UINT_MAX) {
pr_info("Failed to parse either an address or a symbol.\n");
return ret;
}
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -293,7 +293,7 @@ static fetch_func_t get_fetch_size_funct
}
/* Split symbol and offset. */
-int traceprobe_split_symbol_offset(char *symbol, unsigned long *offset)
+int traceprobe_split_symbol_offset(char *symbol, long *offset)
{
char *tmp;
int ret;
@@ -301,13 +301,11 @@ int traceprobe_split_symbol_offset(char
if (!offset)
return -EINVAL;
- tmp = strchr(symbol, '+');
+ tmp = strpbrk(symbol, "+-");
if (tmp) {
- /* skip sign because kstrtoul doesn't accept '+' */
- ret = kstrtoul(tmp + 1, 0, offset);
+ ret = kstrtol(tmp, 0, offset);
if (ret)
return ret;
-
*tmp = '\0';
} else
*offset = 0;
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -335,7 +335,7 @@ extern int traceprobe_conflict_field_nam
extern void traceprobe_update_arg(struct probe_arg *arg);
extern void traceprobe_free_probe_arg(struct probe_arg *arg);
-extern int traceprobe_split_symbol_offset(char *symbol, unsigned long *offset);
+extern int traceprobe_split_symbol_offset(char *symbol, long *offset);
extern ssize_t traceprobe_probes_write(struct file *file,
const char __user *buffer, size_t count, loff_t *ppos,
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 29/43] mtd: nand: fsl_ifc: Fix nand waitfunc return value
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 28/43] tracing: probeevent: Fix to support minus offset from symbol Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 30/43] staging: ncpfs: memory corruption in ncp_read_kernel() Greg Kroah-Hartman
` (19 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jagdish Gediya, Prabhakar Kushwaha,
Boris Brezillon
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jagdish Gediya <jagdish.gediya@nxp.com>
commit fa8e6d58c5bc260f4369c6699683d69695daed0a upstream.
As per the IFC hardware manual, Most significant 2 bytes in
nand_fsr register are the outcome of NAND READ STATUS command.
So status value need to be shifted and aligned as per the nand
framework requirement.
Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller")
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Jagdish Gediya <jagdish.gediya@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mtd/nand/fsl_ifc_nand.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -726,6 +726,7 @@ static int fsl_ifc_wait(struct mtd_info
struct fsl_ifc_ctrl *ctrl = priv->ctrl;
struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
u32 nand_fsr;
+ int status;
/* Use READ_STATUS command, but wait for the device to be ready */
ifc_out32((IFC_FIR_OP_CW0 << IFC_NAND_FIR0_OP0_SHIFT) |
@@ -740,12 +741,12 @@ static int fsl_ifc_wait(struct mtd_info
fsl_ifc_run_command(mtd);
nand_fsr = ifc_in32(&ifc->ifc_nand.nand_fsr);
-
+ status = nand_fsr >> 24;
/*
* The chip always seems to report that it is
* write-protected, even when it is not.
*/
- return nand_fsr | NAND_STATUS_WP;
+ return status | NAND_STATUS_WP;
}
static int fsl_ifc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 30/43] staging: ncpfs: memory corruption in ncp_read_kernel()
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 29/43] mtd: nand: fsl_ifc: Fix nand waitfunc return value Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 31/43] can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack Greg Kroah-Hartman
` (18 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 4c41aa24baa4ed338241d05494f2c595c885af8f upstream.
If the server is malicious then *bytes_read could be larger than the
size of the "target" buffer. It would lead to memory corruption when we
do the memcpy().
Reported-by: Dr Silvio Cesare of InfoSect <Silvio Cesare <silvio.cesare@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ncpfs/ncplib_kernel.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/ncpfs/ncplib_kernel.c
+++ b/fs/ncpfs/ncplib_kernel.c
@@ -980,6 +980,10 @@ ncp_read_kernel(struct ncp_server *serve
goto out;
}
*bytes_read = ncp_reply_be16(server, 0);
+ if (*bytes_read > to_read) {
+ result = -EINVAL;
+ goto out;
+ }
source = ncp_reply_data(server, 2 + (offset & 1));
memcpy(target, source, *bytes_read);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 31/43] can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 30/43] staging: ncpfs: memory corruption in ncp_read_kernel() Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 32/43] can: cc770: Fix queue stall & dropped RTR reply Greg Kroah-Hartman
` (17 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Richard Weinberger, Andri Yngvason,
Marc Kleine-Budde
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andri Yngvason <andri.yngvason@marel.com>
commit f4353daf4905c0099fd25fa742e2ffd4a4bab26a upstream.
This has been reported to cause stalls on rt-linux.
Suggested-by: Richard Weinberger <richard@nod.at>
Tested-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andri Yngvason <andri.yngvason@marel.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/can/cc770/cc770.c | 15 ---------------
1 file changed, 15 deletions(-)
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -447,15 +447,6 @@ static netdev_tx_t cc770_start_xmit(stru
stats->tx_bytes += dlc;
-
- /*
- * HM: We had some cases of repeated IRQs so make sure the
- * INT is acknowledged I know it's already further up, but
- * doing again fixed the issue
- */
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_UNC | TXIE_UNC | RXIE_UNC | INTPND_RES);
-
return NETDEV_TX_OK;
}
@@ -684,12 +675,6 @@ static void cc770_tx_interrupt(struct ne
/* Nothing more to send, switch off interrupts */
cc770_write_reg(priv, msgobj[mo].ctrl0,
MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
- /*
- * We had some cases of repeated IRQ so make sure the
- * INT is acknowledged
- */
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_UNC | TXIE_UNC | RXIE_UNC | INTPND_RES);
stats->tx_packets++;
can_get_echo_skb(dev, 0);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 32/43] can: cc770: Fix queue stall & dropped RTR reply
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 31/43] can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 33/43] can: cc770: Fix use after free in cc770_tx_interrupt() Greg Kroah-Hartman
` (16 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andri Yngvason, Richard Weinberger,
Marc Kleine-Budde
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andri Yngvason <andri.yngvason@marel.com>
commit 746201235b3f876792099079f4c6fea941d76183 upstream.
While waiting for the TX object to send an RTR, an external message with a
matching id can overwrite the TX data. In this case we must call the rx
routine and then try transmitting the message that was overwritten again.
The queue was being stalled because the RX event did not generate an
interrupt to wake up the queue again and the TX event did not happen
because the TXRQST flag is reset by the chip when new data is received.
According to the CC770 datasheet the id of a message object should not be
changed while the MSGVAL bit is set. This has been fixed by resetting the
MSGVAL bit before modifying the object in the transmit function and setting
it after. It is not enough to set & reset CPUUPD.
It is important to keep the MSGVAL bit reset while the message object is
being modified. Otherwise, during RTR transmission, a frame with matching
id could trigger an rx-interrupt, which would cause a race condition
between the interrupt routine and the transmit function.
Signed-off-by: Andri Yngvason <andri.yngvason@marel.com>
Tested-by: Richard Weinberger <richard@nod.at>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/can/cc770/cc770.c | 94 +++++++++++++++++++++++++++++-------------
drivers/net/can/cc770/cc770.h | 2
2 files changed, 68 insertions(+), 28 deletions(-)
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -390,37 +390,23 @@ static int cc770_get_berr_counter(const
return 0;
}
-static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static void cc770_tx(struct net_device *dev, int mo)
{
struct cc770_priv *priv = netdev_priv(dev);
- struct net_device_stats *stats = &dev->stats;
- struct can_frame *cf = (struct can_frame *)skb->data;
- unsigned int mo = obj2msgobj(CC770_OBJ_TX);
+ struct can_frame *cf = (struct can_frame *)priv->tx_skb->data;
u8 dlc, rtr;
u32 id;
int i;
- if (can_dropped_invalid_skb(dev, skb))
- return NETDEV_TX_OK;
-
- if ((cc770_read_reg(priv,
- msgobj[mo].ctrl1) & TXRQST_UNC) == TXRQST_SET) {
- netdev_err(dev, "TX register is still occupied!\n");
- return NETDEV_TX_BUSY;
- }
-
- netif_stop_queue(dev);
-
dlc = cf->can_dlc;
id = cf->can_id;
- if (cf->can_id & CAN_RTR_FLAG)
- rtr = 0;
- else
- rtr = MSGCFG_DIR;
+ rtr = cf->can_id & CAN_RTR_FLAG ? 0 : MSGCFG_DIR;
+
+ cc770_write_reg(priv, msgobj[mo].ctrl0,
+ MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
cc770_write_reg(priv, msgobj[mo].ctrl1,
RMTPND_RES | TXRQST_RES | CPUUPD_SET | NEWDAT_RES);
- cc770_write_reg(priv, msgobj[mo].ctrl0,
- MSGVAL_SET | TXIE_SET | RXIE_RES | INTPND_RES);
+
if (id & CAN_EFF_FLAG) {
id &= CAN_EFF_MASK;
cc770_write_reg(priv, msgobj[mo].config,
@@ -439,13 +425,30 @@ static netdev_tx_t cc770_start_xmit(stru
for (i = 0; i < dlc; i++)
cc770_write_reg(priv, msgobj[mo].data[i], cf->data[i]);
- /* Store echo skb before starting the transfer */
- can_put_echo_skb(skb, dev, 0);
-
cc770_write_reg(priv, msgobj[mo].ctrl1,
- RMTPND_RES | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
+ RMTPND_UNC | TXRQST_SET | CPUUPD_RES | NEWDAT_UNC);
+ cc770_write_reg(priv, msgobj[mo].ctrl0,
+ MSGVAL_SET | TXIE_SET | RXIE_SET | INTPND_UNC);
+}
+
+static netdev_tx_t cc770_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct cc770_priv *priv = netdev_priv(dev);
+ unsigned int mo = obj2msgobj(CC770_OBJ_TX);
+
+ if (can_dropped_invalid_skb(dev, skb))
+ return NETDEV_TX_OK;
+
+ netif_stop_queue(dev);
+
+ if ((cc770_read_reg(priv,
+ msgobj[mo].ctrl1) & TXRQST_UNC) == TXRQST_SET) {
+ netdev_err(dev, "TX register is still occupied!\n");
+ return NETDEV_TX_BUSY;
+ }
- stats->tx_bytes += dlc;
+ priv->tx_skb = skb;
+ cc770_tx(dev, mo);
return NETDEV_TX_OK;
}
@@ -671,13 +674,47 @@ static void cc770_tx_interrupt(struct ne
struct cc770_priv *priv = netdev_priv(dev);
struct net_device_stats *stats = &dev->stats;
unsigned int mo = obj2msgobj(o);
+ struct can_frame *cf;
+ u8 ctrl1;
+
+ ctrl1 = cc770_read_reg(priv, msgobj[mo].ctrl1);
- /* Nothing more to send, switch off interrupts */
cc770_write_reg(priv, msgobj[mo].ctrl0,
MSGVAL_RES | TXIE_RES | RXIE_RES | INTPND_RES);
+ cc770_write_reg(priv, msgobj[mo].ctrl1,
+ RMTPND_RES | TXRQST_RES | MSGLST_RES | NEWDAT_RES);
- stats->tx_packets++;
+ if (unlikely(!priv->tx_skb)) {
+ netdev_err(dev, "missing tx skb in tx interrupt\n");
+ return;
+ }
+
+ if (unlikely(ctrl1 & MSGLST_SET)) {
+ stats->rx_over_errors++;
+ stats->rx_errors++;
+ }
+
+ /* When the CC770 is sending an RTR message and it receives a regular
+ * message that matches the id of the RTR message, it will overwrite the
+ * outgoing message in the TX register. When this happens we must
+ * process the received message and try to transmit the outgoing skb
+ * again.
+ */
+ if (unlikely(ctrl1 & NEWDAT_SET)) {
+ cc770_rx(dev, mo, ctrl1);
+ cc770_tx(dev, mo);
+ return;
+ }
+
+ can_put_echo_skb(priv->tx_skb, dev, 0);
can_get_echo_skb(dev, 0);
+
+ cf = (struct can_frame *)priv->tx_skb->data;
+ stats->tx_bytes += cf->can_dlc;
+ stats->tx_packets++;
+
+ priv->tx_skb = NULL;
+
netif_wake_queue(dev);
}
@@ -789,6 +826,7 @@ struct net_device *alloc_cc770dev(int si
priv->can.do_set_bittiming = cc770_set_bittiming;
priv->can.do_set_mode = cc770_set_mode;
priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES;
+ priv->tx_skb = NULL;
memcpy(priv->obj_flags, cc770_obj_flags, sizeof(cc770_obj_flags));
--- a/drivers/net/can/cc770/cc770.h
+++ b/drivers/net/can/cc770/cc770.h
@@ -193,6 +193,8 @@ struct cc770_priv {
u8 cpu_interface; /* CPU interface register */
u8 clkout; /* Clock out register */
u8 bus_config; /* Bus conffiguration register */
+
+ struct sk_buff *tx_skb;
};
struct net_device *alloc_cc770dev(int sizeof_priv);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 33/43] can: cc770: Fix use after free in cc770_tx_interrupt()
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 32/43] can: cc770: Fix queue stall & dropped RTR reply Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 34/43] tty: vt: fix up tabstops properly Greg Kroah-Hartman
` (15 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andri Yngvason, Marc Kleine-Budde
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andri Yngvason <andri.yngvason@marel.com>
commit 9ffd7503944ec7c0ef41c3245d1306c221aef2be upstream.
This fixes use after free introduced by the last cc770 patch.
Signed-off-by: Andri Yngvason <andri.yngvason@marel.com>
Fixes: 746201235b3f ("can: cc770: Fix queue stall & dropped RTR reply")
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/can/cc770/cc770.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/can/cc770/cc770.c
+++ b/drivers/net/can/cc770/cc770.c
@@ -706,13 +706,12 @@ static void cc770_tx_interrupt(struct ne
return;
}
- can_put_echo_skb(priv->tx_skb, dev, 0);
- can_get_echo_skb(dev, 0);
-
cf = (struct can_frame *)priv->tx_skb->data;
stats->tx_bytes += cf->can_dlc;
stats->tx_packets++;
+ can_put_echo_skb(priv->tx_skb, dev, 0);
+ can_get_echo_skb(dev, 0);
priv->tx_skb = NULL;
netif_wake_queue(dev);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 34/43] tty: vt: fix up tabstops properly
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 33/43] can: cc770: Fix use after free in cc770_tx_interrupt() Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 35/43] kvm/x86: fix icebp instruction handling Greg Kroah-Hartman
` (14 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, James Holderness, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
commit f1869a890cdedb92a3fab969db5d0fd982850273 upstream.
Tabs on a console with long lines do not wrap properly, so correctly
account for the line length when computing the tab placement location.
Reported-by: James Holderness <j4_james@hotmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1725,7 +1725,7 @@ static void reset_terminal(struct vc_dat
default_attr(vc);
update_attr(vc);
- vc->vc_tab_stop[0] = 0x01010100;
+ vc->vc_tab_stop[0] =
vc->vc_tab_stop[1] =
vc->vc_tab_stop[2] =
vc->vc_tab_stop[3] =
@@ -1769,7 +1769,7 @@ static void do_con_trol(struct tty_struc
vc->vc_pos -= (vc->vc_x << 1);
while (vc->vc_x < vc->vc_cols - 1) {
vc->vc_x++;
- if (vc->vc_tab_stop[vc->vc_x >> 5] & (1 << (vc->vc_x & 31)))
+ if (vc->vc_tab_stop[7 & (vc->vc_x >> 5)] & (1 << (vc->vc_x & 31)))
break;
}
vc->vc_pos += (vc->vc_x << 1);
@@ -1829,7 +1829,7 @@ static void do_con_trol(struct tty_struc
lf(vc);
return;
case 'H':
- vc->vc_tab_stop[vc->vc_x >> 5] |= (1 << (vc->vc_x & 31));
+ vc->vc_tab_stop[7 & (vc->vc_x >> 5)] |= (1 << (vc->vc_x & 31));
return;
case 'Z':
respond_ID(tty);
@@ -2022,7 +2022,7 @@ static void do_con_trol(struct tty_struc
return;
case 'g':
if (!vc->vc_par[0])
- vc->vc_tab_stop[vc->vc_x >> 5] &= ~(1 << (vc->vc_x & 31));
+ vc->vc_tab_stop[7 & (vc->vc_x >> 5)] &= ~(1 << (vc->vc_x & 31));
else if (vc->vc_par[0] == 3) {
vc->vc_tab_stop[0] =
vc->vc_tab_stop[1] =
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 35/43] kvm/x86: fix icebp instruction handling
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 34/43] tty: vt: fix up tabstops properly Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 36/43] x86/build/64: Force the linker to use 2MB page size Greg Kroah-Hartman
` (13 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Lutomirski, Paolo Bonzini,
Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
commit 32d43cd391bacb5f0814c2624399a5dad3501d09 upstream.
The undocumented 'icebp' instruction (aka 'int1') works pretty much like
'int3' in the absense of in-circuit probing equipment (except,
obviously, that it raises #DB instead of raising #BP), and is used by
some validation test-suites as such.
But Andy Lutomirski noticed that his test suite acted differently in kvm
than on bare hardware.
The reason is that kvm used an inexact test for the icebp instruction:
it just assumed that an all-zero VM exit qualification value meant that
the VM exit was due to icebp.
That is not unlike the guess that do_debug() does for the actual
exception handling case, but it's purely a heuristic, not an absolute
rule. do_debug() does it because it wants to ascribe _some_ reasons to
the #DB that happened, and an empty %dr6 value means that 'icebp' is the
most likely casue and we have no better information.
But kvm can just do it right, because unlike the do_debug() case, kvm
actually sees the real reason for the #DB in the VM-exit interruption
information field.
So instead of relying on an inexact heuristic, just use the actual VM
exit information that says "it was 'icebp'".
Right now the 'icebp' instruction isn't technically documented by Intel,
but that will hopefully change. The special "privileged software
exception" information _is_ actually mentioned in the Intel SDM, even
though the cause of it isn't enumerated.
Reported-by: Andy Lutomirski <luto@kernel.org>
Tested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/vmx.h | 1 +
arch/x86/kvm/vmx.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -310,6 +310,7 @@ enum vmcs_field {
#define INTR_TYPE_NMI_INTR (2 << 8) /* NMI */
#define INTR_TYPE_HARD_EXCEPTION (3 << 8) /* processor exception */
#define INTR_TYPE_SOFT_INTR (4 << 8) /* software interrupt */
+#define INTR_TYPE_PRIV_SW_EXCEPTION (5 << 8) /* ICE breakpoint - undocumented */
#define INTR_TYPE_SOFT_EXCEPTION (6 << 8) /* software exception */
/* GUEST_INTERRUPTIBILITY_INFO flags. */
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1011,6 +1011,13 @@ static inline bool is_machine_check(u32
(INTR_TYPE_HARD_EXCEPTION | MC_VECTOR | INTR_INFO_VALID_MASK);
}
+/* Undocumented: icebp/int1 */
+static inline bool is_icebp(u32 intr_info)
+{
+ return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
+ == (INTR_TYPE_PRIV_SW_EXCEPTION | INTR_INFO_VALID_MASK);
+}
+
static inline bool cpu_has_vmx_msr_bitmap(void)
{
return vmcs_config.cpu_based_exec_ctrl & CPU_BASED_USE_MSR_BITMAPS;
@@ -5333,7 +5340,7 @@ static int handle_exception(struct kvm_v
(KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))) {
vcpu->arch.dr6 &= ~15;
vcpu->arch.dr6 |= dr6 | DR6_RTM;
- if (!(dr6 & ~DR6_RESERVED)) /* icebp */
+ if (is_icebp(intr_info))
skip_emulated_instruction(vcpu);
kvm_queue_exception(vcpu, DB_VECTOR);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 36/43] x86/build/64: Force the linker to use 2MB page size
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 35/43] kvm/x86: fix icebp instruction handling Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 37/43] x86/boot/64: Verify alignment of the LOAD segment Greg Kroah-Hartman
` (12 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, H.J. Lu, Andy Shevchenko,
Eric Biederman, H. Peter Anvin, Juergen Gross, Kees Cook,
Kirill A. Shutemov, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: H.J. Lu <hjl.tools@gmail.com>
commit e3d03598e8ae7d195af5d3d049596dec336f569f upstream.
Binutils 2.31 will enable -z separate-code by default for x86 to avoid
mixing code pages with data to improve cache performance as well as
security. To reduce x86-64 executable and shared object sizes, the
maximum page size is reduced from 2MB to 4KB. But x86-64 kernel must
be aligned to 2MB. Pass -z max-page-size=0x200000 to linker to force
2MB page size regardless of the default page size used by linker.
Tested with Linux kernel 4.15.6 on x86-64.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/CAMe9rOp4_%3D_8twdpTyAP2DhONOCeaTOsniJLoppzhoNptL8xzA@mail.gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -179,6 +179,15 @@ KBUILD_CFLAGS += $(cfi) $(cfi-sigframe)
LDFLAGS := -m elf_$(UTS_MACHINE)
+#
+# The 64-bit kernel must be aligned to 2MB. Pass -z max-page-size=0x200000 to
+# the linker to force 2MB page size regardless of the default page size used
+# by the linker.
+#
+ifdef CONFIG_X86_64
+LDFLAGS += $(call ld-option, -z max-page-size=0x200000)
+endif
+
# Speed up the build
KBUILD_CFLAGS += -pipe
# Workaround for a gcc prelease that unfortunately was shipped in a suse release
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 37/43] x86/boot/64: Verify alignment of the LOAD segment
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 36/43] x86/build/64: Force the linker to use 2MB page size Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 38/43] x86/entry/64: Dont use IST entry for #BP stack Greg Kroah-Hartman
` (11 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, H.J. Lu, Andy Shevchenko,
Eric Biederman, H. Peter Anvin, Juergen Gross, Kees Cook,
Kirill A. Shutemov, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner, Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: H.J. Lu <hjl.tools@gmail.com>
commit c55b8550fa57ba4f5e507be406ff9fc2845713e8 upstream.
Since the x86-64 kernel must be aligned to 2MB, refuse to boot the
kernel if the alignment of the LOAD segment isn't a multiple of 2MB.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/CAMe9rOrR7xSJgUfiCoZLuqWUwymRxXPoGBW38%2BpN%3D9g%2ByKNhZw@mail.gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/boot/compressed/misc.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -366,6 +366,10 @@ static void parse_elf(void *output)
switch (phdr->p_type) {
case PT_LOAD:
+#ifdef CONFIG_X86_64
+ if ((phdr->p_align % 0x200000) != 0)
+ error("Alignment of LOAD segment isn't multiple of 2MB");
+#endif
#ifdef CONFIG_RELOCATABLE
dest = output;
dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR);
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 38/43] x86/entry/64: Dont use IST entry for #BP stack
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 37/43] x86/boot/64: Verify alignment of the LOAD segment Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 39/43] perf/x86/intel: Dont accidentally clear high bits in bdw_limit_period() Greg Kroah-Hartman
` (10 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andy Lutomirski, Linus Torvalds,
Thomas Gleixner
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <luto@kernel.org>
commit d8ba61ba58c88d5207c1ba2f7d9a2280e7d03be9 upstream.
There's nothing IST-worthy about #BP/int3. We don't allow kprobes
in the small handful of places in the kernel that run at CPL0 with
an invalid stack, and 32-bit kernels have used normal interrupt
gates for #BP forever.
Furthermore, we don't allow kprobes in places that have usergs while
in kernel mode, so "paranoid" is also unnecessary.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/entry/entry_64.S | 2 +-
arch/x86/kernel/traps.c | 24 +++++++++++-------------
2 files changed, 12 insertions(+), 14 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1018,7 +1018,7 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTO
#endif /* CONFIG_HYPERV */
idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
-idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
+idtentry int3 do_int3 has_error_code=0
idtentry stack_segment do_stack_segment has_error_code=1
#ifdef CONFIG_XEN
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -480,7 +480,6 @@ do_general_protection(struct pt_regs *re
}
NOKPROBE_SYMBOL(do_general_protection);
-/* May run on IST stack. */
dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
{
#ifdef CONFIG_DYNAMIC_FTRACE
@@ -495,7 +494,15 @@ dotraplinkage void notrace do_int3(struc
if (poke_int3_handler(regs))
return;
+ /*
+ * Use ist_enter despite the fact that we don't use an IST stack.
+ * We can be called from a kprobe in non-CONTEXT_KERNEL kernel
+ * mode or even during context tracking state changes.
+ *
+ * This means that we can't schedule. That's okay.
+ */
ist_enter(regs);
+
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
@@ -512,15 +519,9 @@ dotraplinkage void notrace do_int3(struc
SIGTRAP) == NOTIFY_STOP)
goto exit;
- /*
- * Let others (NMI) know that the debug stack is in use
- * as we may switch to the interrupt stack.
- */
- debug_stack_usage_inc();
preempt_conditional_sti(regs);
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
preempt_conditional_cli(regs);
- debug_stack_usage_dec();
exit:
ist_exit(regs);
}
@@ -886,19 +887,16 @@ void __init trap_init(void)
cpu_init();
/*
- * X86_TRAP_DB and X86_TRAP_BP have been set
- * in early_trap_init(). However, ITS works only after
- * cpu_init() loads TSS. See comments in early_trap_init().
+ * X86_TRAP_DB was installed in early_trap_init(). However,
+ * IST works only after cpu_init() loads TSS. See comments
+ * in early_trap_init().
*/
set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK);
- /* int3 can be called from all */
- set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK);
x86_init.irqs.trap_init();
#ifdef CONFIG_X86_64
memcpy(&debug_idt_table, &idt_table, IDT_ENTRIES * 16);
set_nmi_gate(X86_TRAP_DB, &debug);
- set_nmi_gate(X86_TRAP_BP, &int3);
#endif
}
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 39/43] perf/x86/intel: Dont accidentally clear high bits in bdw_limit_period()
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 38/43] x86/entry/64: Dont use IST entry for #BP stack Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 40/43] staging: lustre: ptlrpc: kfree used instead of kvfree Greg Kroah-Hartman
` (9 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Peter Zijlstra (Intel),
Alexander Shishkin, Arnaldo Carvalho de Melo, H. Peter Anvin,
Jiri Olsa, Kan Liang, Linus Torvalds, Sebastian Andrzej Siewior,
Stephane Eranian, Thomas Gleixner, Vince Weaver, Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit e5ea9b54a055619160bbfe527ebb7d7191823d66 upstream.
We intended to clear the lowest 6 bits but because of a type bug we
clear the high 32 bits as well. Andi says that periods are rarely more
than U32_MAX so this bug probably doesn't have a huge runtime impact.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: 294fe0f52a44 ("perf/x86/intel: Add INST_RETIRED.ALL workarounds")
Link: http://lkml.kernel.org/r/20180317115216.GB4035@mwanda
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2716,7 +2716,7 @@ static unsigned bdw_limit_period(struct
X86_CONFIG(.event=0xc0, .umask=0x01)) {
if (left < 128)
left = 128;
- left &= ~0x3fu;
+ left &= ~0x3fULL;
}
return left;
}
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 40/43] staging: lustre: ptlrpc: kfree used instead of kvfree
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 39/43] perf/x86/intel: Dont accidentally clear high bits in bdw_limit_period() Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 41/43] kbuild: disable clangs default use of -fmerge-all-constants Greg Kroah-Hartman
` (8 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peng Tao, Oleg Drokin, James Simmons,
Nadav Amit, Andreas Dilger
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nadav Amit <namit@vmware.com>
commit c3eec59659cf25916647d2178c541302bb4822ad upstream.
rq_reqbuf is allocated using kvmalloc() but released in one occasion
using kfree() instead of kvfree().
The issue was found using grep based on a similar bug.
Fixes: d7e09d0397e8 ("add Lustre file system client support")
Fixes: ee0ec1946ec2 ("lustre: ptlrpc: Replace uses of OBD_{ALLOC,FREE}_LARGE")
Cc: Peng Tao <bergwolf@gmail.com>
Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: Nadav Amit <namit@vmware.com>
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/lustre/lustre/ptlrpc/sec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/lustre/lustre/ptlrpc/sec.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec.c
@@ -824,7 +824,7 @@ void sptlrpc_request_out_callback(struct
if (req->rq_pool || !req->rq_reqbuf)
return;
- kfree(req->rq_reqbuf);
+ kvfree(req->rq_reqbuf);
req->rq_reqbuf = NULL;
req->rq_reqbuf_len = 0;
}
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 41/43] kbuild: disable clangs default use of -fmerge-all-constants
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 40/43] staging: lustre: ptlrpc: kfree used instead of kvfree Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 42/43] bpf: skip unnecessary capability check Greg Kroah-Hartman
` (7 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Prasad Sodagudi, Daniel Borkmann,
Linus Torvalds, Chenbo Feng, Richard Smith, Chandler Carruth,
Alexei Starovoitov
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <daniel@iogearbox.net>
commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 upstream.
Prasad reported that he has seen crashes in BPF subsystem with netd
on Android with arm64 in the form of (note, the taint is unrelated):
[ 4134.721483] Unable to handle kernel paging request at virtual address 800000001
[ 4134.820925] Mem abort info:
[ 4134.901283] Exception class = DABT (current EL), IL = 32 bits
[ 4135.016736] SET = 0, FnV = 0
[ 4135.119820] EA = 0, S1PTW = 0
[ 4135.201431] Data abort info:
[ 4135.301388] ISV = 0, ISS = 0x00000021
[ 4135.359599] CM = 0, WnR = 0
[ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000
[ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000
[ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP
[ 4135.674610] Modules linked in:
[ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1
[ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000
[ 4135.731599] PC is at bpf_prog_add+0x20/0x68
[ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c
[ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145
[ 4135.769062] sp : ffffff801d4e3ce0
[...]
[ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000)
[ 4136.273746] Call trace:
[...]
[ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006
[ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584
[ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68
[ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c
[ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c
[ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88
Android's netd was basically pinning the uid cookie BPF map in BPF
fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it
again resulting in above panic. Issue is that the map was wrongly
identified as a prog! Above kernel was compiled with clang 4.0,
and it turns out that clang decided to merge the bpf_prog_iops and
bpf_map_iops into a single memory location, such that the two i_ops
could then not be distinguished anymore.
Reason for this miscompilation is that clang has the more aggressive
-fmerge-all-constants enabled by default. In fact, clang source code
has a comment about it in lib/AST/ExprConstant.cpp on why it is okay
to do so:
Pointers with different bases cannot represent the same object.
(Note that clang defaults to -fmerge-all-constants, which can
lead to inconsistent results for comparisons involving the address
of a constant; this generally doesn't matter in practice.)
The issue never appeared with gcc however, since gcc does not enable
-fmerge-all-constants by default and even *explicitly* states in
it's option description that using this flag results in non-conforming
behavior, quote from man gcc:
Languages like C or C++ require each variable, including multiple
instances of the same variable in recursive calls, to have distinct
locations, so using this option results in non-conforming behavior.
There are also various clang bug reports open on that matter [1],
where clang developers acknowledge the non-conforming behavior,
and refer to disabling it with -fno-merge-all-constants. But even
if this gets fixed in clang today, there are already users out there
that triggered this. Thus, fix this issue by explicitly adding
-fno-merge-all-constants to the kernel's Makefile to generically
disable this optimization, since potentially other places in the
kernel could subtly break as well.
Note, there is also a flag called -fmerge-constants (not supported
by clang), which is more conservative and only applies to strings
and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In
gcc's code, the two flags -fmerge-{all-,}constants share the same
variable internally, so when disabling it via -fno-merge-all-constants,
then we really don't merge any const data (e.g. strings), and text
size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o).
$ gcc -fverbose-asm -O2 foo.c -S -o foo.S
-> foo.S lists -fmerge-constants under options enabled
$ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S
-> foo.S doesn't list -fmerge-constants under options enabled
$ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S
-> foo.S lists -fmerge-constants under options enabled
Thus, as a workaround we need to set both -fno-merge-all-constants
*and* -fmerge-constants in the Makefile in order for text size to
stay as is.
[1] https://bugs.llvm.org/show_bug.cgi?id=18538
Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Richard Smith <richard-llvm@metafoo.co.uk>
Cc: Chandler Carruth <chandlerc@gmail.com>
Cc: linux-kernel@vger.kernel.org
Tested-by: Prasad Sodagudi <psodagud@codeaurora.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/Makefile
+++ b/Makefile
@@ -784,6 +784,15 @@ KBUILD_CFLAGS += $(call cc-disable-warni
# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
+# clang sets -fmerge-all-constants by default as optimization, but this
+# is non-conforming behavior for C and in fact breaks the kernel, so we
+# need to disable it here generally.
+KBUILD_CFLAGS += $(call cc-option,-fno-merge-all-constants)
+
+# for gcc -fno-merge-all-constants disables everything, but it is fine
+# to have actual conforming behavior enabled.
+KBUILD_CFLAGS += $(call cc-option,-fmerge-constants)
+
# Make sure -fstack-check isn't enabled (like gentoo apparently did)
KBUILD_CFLAGS += $(call cc-option,-fno-stack-check,)
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 42/43] bpf: skip unnecessary capability check
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 41/43] kbuild: disable clangs default use of -fmerge-all-constants Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 16:27 ` [PATCH 4.4 43/43] bpf, x64: increase number of passes Greg Kroah-Hartman
` (6 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chenbo Feng, Lorenzo Colitti,
Daniel Borkmann
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chenbo Feng <fengc@google.com>
commit 0fa4fe85f4724fff89b09741c437cbee9cf8b008 upstream.
The current check statement in BPF syscall will do a capability check
for CAP_SYS_ADMIN before checking sysctl_unprivileged_bpf_disabled. This
code path will trigger unnecessary security hooks on capability checking
and cause false alarms on unprivileged process trying to get CAP_SYS_ADMIN
access. This can be resolved by simply switch the order of the statement
and CAP_SYS_ADMIN is not required anyway if unprivileged bpf syscall is
allowed.
Signed-off-by: Chenbo Feng <fengc@google.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -673,7 +673,7 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf
union bpf_attr attr = {};
int err;
- if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled)
+ if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
return -EPERM;
if (!access_ok(VERIFY_READ, uattr, 1))
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 4.4 43/43] bpf, x64: increase number of passes
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 42/43] bpf: skip unnecessary capability check Greg Kroah-Hartman
@ 2018-03-27 16:27 ` Greg Kroah-Hartman
2018-03-27 18:24 ` [PATCH 4.4 00/43] 4.4.125-stable review Nathan Chancellor
` (5 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-27 16:27 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Borkmann, Alexei Starovoitov,
Eric Dumazet
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <daniel@iogearbox.net>
commit 6007b080d2e2adb7af22bf29165f0594ea12b34c upstream.
In Cilium some of the main programs we run today are hitting 9 passes
on x64's JIT compiler, and we've had cases already where we surpassed
the limit where the JIT then punts the program to the interpreter
instead, leading to insertion failures due to CONFIG_BPF_JIT_ALWAYS_ON
or insertion failures due to the prog array owner being JITed but the
program to insert not (both must have the same JITed/non-JITed property).
One concrete case the program image shrunk from 12,767 bytes down to
10,288 bytes where the image converged after 16 steps. I've measured
that this took 340us in the JIT until it converges on my i7-6600U. Thus,
increase the original limit we had from day one where the JIT covered
cBPF only back then before we run into the case (as similar with the
complexity limit) where we trip over this and hit program rejections.
Also add a cond_resched() into the compilation loop, the JIT process
runs without any locks and may sleep anyway.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/net/bpf_jit_comp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -1077,7 +1077,7 @@ void bpf_int_jit_compile(struct bpf_prog
* may converge on the last pass. In such case do one more
* pass to emit the final image
*/
- for (pass = 0; pass < 10 || image; pass++) {
+ for (pass = 0; pass < 20 || image; pass++) {
proglen = do_jit(prog, addrs, image, oldproglen, &ctx);
if (proglen <= 0) {
image = NULL;
@@ -1100,6 +1100,7 @@ void bpf_int_jit_compile(struct bpf_prog
goto out;
}
oldproglen = proglen;
+ cond_resched();
}
if (bpf_jit_enable > 1)
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2018-03-27 16:27 ` [PATCH 4.4 43/43] bpf, x64: increase number of passes Greg Kroah-Hartman
@ 2018-03-27 18:24 ` Nathan Chancellor
2018-03-28 10:04 ` Greg Kroah-Hartman
2018-03-27 20:21 ` Dan Rue
` (4 subsequent siblings)
48 siblings, 1 reply; 64+ messages in thread
From: Nathan Chancellor @ 2018-03-27 18:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
On Tue, Mar 27, 2018 at 06:27:04PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.125 release.
> There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
No initial issues noticed in dmesg or general usage.
Thanks!
Nathan
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 18:24 ` [PATCH 4.4 00/43] 4.4.125-stable review Nathan Chancellor
@ 2018-03-28 10:04 ` Greg Kroah-Hartman
0 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-28 10:04 UTC (permalink / raw)
To: Nathan Chancellor
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
On Tue, Mar 27, 2018 at 11:24:44AM -0700, Nathan Chancellor wrote:
> On Tue, Mar 27, 2018 at 06:27:04PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.125 release.
> > There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.
>
> No initial issues noticed in dmesg or general usage.
Oops, responded to the wrong email...
thanks for testing this and letting me know, and glad you got your pixel
2 xl back :)
greg k-h
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2018-03-27 18:24 ` [PATCH 4.4 00/43] 4.4.125-stable review Nathan Chancellor
@ 2018-03-27 20:21 ` Dan Rue
2018-03-28 10:03 ` Greg Kroah-Hartman
2018-03-27 22:59 ` Shuah Khan
` (3 subsequent siblings)
48 siblings, 1 reply; 64+ messages in thread
From: Dan Rue @ 2018-03-27 20:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
On Tue, Mar 27, 2018 at 06:27:04PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.125 release.
> There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
...
> Toshi Kani <toshi.kani@hpe.com>
> mm/vmalloc: add interfaces to free unmapped page table
Fails to build on 4.4/arm64 due to
f2ef4616ccfd ("mm/vmalloc: add interfaces to free unmapped page table")
See my reply to the patch for specifics,
Thanks,
Dan
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 20:21 ` Dan Rue
@ 2018-03-28 10:03 ` Greg Kroah-Hartman
0 siblings, 0 replies; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-28 10:03 UTC (permalink / raw)
To: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
On Tue, Mar 27, 2018 at 03:21:20PM -0500, Dan Rue wrote:
> On Tue, Mar 27, 2018 at 06:27:04PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.125 release.
> > There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> > and the diffstat can be found below.
>
> ...
>
> > Toshi Kani <toshi.kani@hpe.com>
> > mm/vmalloc: add interfaces to free unmapped page table
>
> Fails to build on 4.4/arm64 due to
>
> f2ef4616ccfd ("mm/vmalloc: add interfaces to free unmapped page table")
>
> See my reply to the patch for specifics,
Should now be fixed, thanks.
greg k-h
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2018-03-27 20:21 ` Dan Rue
@ 2018-03-27 22:59 ` Shuah Khan
2018-03-28 0:21 ` kernelci.org bot
` (2 subsequent siblings)
48 siblings, 0 replies; 64+ messages in thread
From: Shuah Khan @ 2018-03-27 22:59 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, Shuah Khan
On 03/27/2018 10:27 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.125 release.
> There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2018-03-27 22:59 ` Shuah Khan
@ 2018-03-28 0:21 ` kernelci.org bot
2018-03-30 23:56 ` Kevin Hilman
2018-03-28 9:58 ` Greg Kroah-Hartman
2018-03-28 13:38 ` Guenter Roeck
48 siblings, 1 reply; 64+ messages in thread
From: kernelci.org bot @ 2018-03-28 0:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: Greg Kroah-Hartman, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
stable-rc/linux-4.4.y boot: 98 boots: 2 failed, 37 passed with 56 offline, 3 untried/unknown (v4.4.124-44-g9d0ab5d17182)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.124-44-g9d0ab5d17182/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.124-44-g9d0ab5d17182/
Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.124-44-g9d0ab5d17182
Git Commit: 9d0ab5d17182f9bbe3a4c1d8412f387302bc82d0
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 51 unique boards, 20 SoC families, 15 builds out of 174
Boot Regressions Detected:
arm:
at91_dt_defconfig:
at91sam9261ek:
lab-free-electrons: failing since 5 days (last pass: v4.4.123 - first fail: v4.4.123-97-g3054df73e9af)
sama5_defconfig:
sama5d36ek:
lab-free-electrons: new failure (last pass: v4.4.124)
Boot Failures Detected:
arm:
sama5_defconfig
sama5d36ek: 1 failed lab
at91_dt_defconfig
at91sam9261ek: 1 failed lab
Offline Platforms:
arm:
sunxi_defconfig:
sun4i-a10-cubieboard: 1 offline lab
sun5i-r8-chip: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
sun7i-a20-cubietruck: 1 offline lab
bcm2835_defconfig:
bcm2835-rpi-b: 1 offline lab
sama5_defconfig:
at91-sama5d4_xplained: 1 offline lab
multi_v7_defconfig:
alpine-db: 1 offline lab
am335x-boneblack: 1 offline lab
armada-xp-openblocks-ax3-4: 1 offline lab
at91-sama5d4_xplained: 1 offline lab
bcm4708-smartrg-sr400ac: 1 offline lab
bcm72521-bcm97252sffe: 1 offline lab
bcm7445-bcm97445c: 1 offline lab
exynos5250-arndale: 1 offline lab
exynos5410-odroidxu: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5422-odroidxu3: 1 offline lab
exynos5800-peach-pi: 1 offline lab
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
meson8b-odroidc1: 1 offline lab
omap3-beagle: 1 offline lab
omap3-beagle-xm: 1 offline lab
omap4-panda: 1 offline lab
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
socfpga_cyclone5_de0_sockit: 1 offline lab
stih410-b2120: 1 offline lab
sun4i-a10-cubieboard: 1 offline lab
sun5i-r8-chip: 1 offline lab
sun7i-a20-bananapi: 1 offline lab
sun7i-a20-cubietruck: 1 offline lab
tegra124-jetson-tk1: 1 offline lab
tegra20-iris-512: 1 offline lab
tegra30-beaver: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab
zynq-zc702: 1 offline lab
tegra_defconfig:
tegra124-jetson-tk1: 1 offline lab
tegra20-iris-512: 1 offline lab
tegra30-beaver: 1 offline lab
imx_v6_v7_defconfig:
imx6dl-wandboard_dual: 1 offline lab
imx6dl-wandboard_solo: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab
exynos_defconfig:
exynos5250-arndale: 1 offline lab
exynos5410-odroidxu: 1 offline lab
exynos5420-arndale-octa: 1 offline lab
exynos5422-odroidxu3: 1 offline lab
exynos5800-peach-pi: 1 offline lab
qcom_defconfig:
qcom-apq8064-cm-qs600: 1 offline lab
qcom-apq8064-ifc6410: 1 offline lab
omap2plus_defconfig:
am335x-boneblack: 1 offline lab
omap3-beagle: 1 offline lab
omap3-beagle-xm: 1 offline lab
omap4-panda: 1 offline lab
davinci_all_defconfig:
dm365evm,legacy: 1 offline lab
mvebu_v7_defconfig:
armada-xp-openblocks-ax3-4: 1 offline lab
---
For more info write to <info@kernelci.org>
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-28 0:21 ` kernelci.org bot
@ 2018-03-30 23:56 ` Kevin Hilman
0 siblings, 0 replies; 64+ messages in thread
From: Kevin Hilman @ 2018-03-30 23:56 UTC (permalink / raw)
To: kernelci.org bot
Cc: Greg Kroah-Hartman, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, lkft-triage, stable, kernelci
kernelci.org bot <bot@kernelci.org> writes:
> stable-rc/linux-4.4.y boot: 98 boots: 2 failed, 37 passed with 56 offline, 3 untried/unknown (v4.4.124-44-g9d0ab5d17182)
>
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.124-44-g9d0ab5d17182/
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.124-44-g9d0ab5d17182/
>
> Tree: stable-rc
> Branch: linux-4.4.y
> Git Describe: v4.4.124-44-g9d0ab5d17182
> Git Commit: 9d0ab5d17182f9bbe3a4c1d8412f387302bc82d0
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 51 unique boards, 20 SoC families, 15 builds out of 174
TL;DR; All is well.
> Boot Regressions Detected:
>
> arm:
>
> at91_dt_defconfig:
> at91sam9261ek:
> lab-free-electrons: failing since 5 days (last pass: v4.4.123 - first fail: v4.4.123-97-g3054df73e9af)
>
> sama5_defconfig:
> sama5d36ek:
> lab-free-electrons: new failure (last pass: v4.4.124)
These have been reported to Bootlin lab awhile back and appear to be lab
issues, but haven't heard back from them yet.
Kevin
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2018-03-28 0:21 ` kernelci.org bot
@ 2018-03-28 9:58 ` Greg Kroah-Hartman
2018-03-28 15:42 ` Dan Rue
2018-03-28 13:38 ` Guenter Roeck
48 siblings, 1 reply; 64+ messages in thread
From: Greg Kroah-Hartman @ 2018-03-28 9:58 UTC (permalink / raw)
To: linux-kernel
Cc: torvalds, akpm, linux, shuahkh, patches, ben.hutchings,
lkft-triage, stable
On Tue, Mar 27, 2018 at 06:27:04PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.125 release.
> There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
-rc2 is out to fix an arm64 build breakage:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc2.gz
^ permalink raw reply [flat|nested] 64+ messages in thread* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-28 9:58 ` Greg Kroah-Hartman
@ 2018-03-28 15:42 ` Dan Rue
0 siblings, 0 replies; 64+ messages in thread
From: Dan Rue @ 2018-03-28 15:42 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, lkft-triage, stable
On Wed, Mar 28, 2018 at 11:58:47AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Mar 27, 2018 at 06:27:04PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.125 release.
> > There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> > and the diffstat can be found below.
>
> -rc2 is out to fix an arm64 build breakage:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.125-rc2.gz
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.4.125-rc2
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 6d103166a63a0a6f0eb313f608b08c52beb14a11
git describe: v4.4.124-44-g6d103166a63a
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.124-44-g6d103166a63a
No regressions (compared to build v4.4.124-44-g9d0ab5d17182)
Boards, architectures and test suites:
-------------------------------------
juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 29, pass: 34
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-timers-tests - skip: 1, pass: 12
qemu_x86_64
* boot - pass: 22
* kselftest - skip: 33, pass: 47
* kselftest-vsyscall-mode-native - skip: 33, pass: 47
* kselftest-vsyscall-mode-none - skip: 33, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 149, pass: 1001
* ltp-timers-tests - skip: 1, pass: 12
x15 - arm
* boot - pass: 20
* kselftest - skip: 29, pass: 33
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 98, pass: 1052
* ltp-timers-tests - skip: 1, pass: 12
x86_64
* boot - pass: 22
* kselftest - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-native - skip: 31, fail: 1, pass: 48
* kselftest-vsyscall-mode-none - skip: 31, fail: 2, pass: 47
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 120, pass: 1030
* ltp-timers-tests - skip: 1, pass: 12
Summary
------------------------------------------------------------------------
kernel: 4.4.125-rc2
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.125-rc2-hikey-20180328-160
git commit: 127b04544014992026cee300d0c88a8eaf834b52
git describe: 4.4.125-rc2-hikey-20180328-160
Test details:
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.125-rc2-hikey-20180328-160
No regressions (compared to build 4.4.124-rc1-hikey-20180323-157)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 32, pass: 30
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 53, pass: 28
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 154, pass: 996
* ltp-timers-tests - skip: 1, pass: 12
--
Linaro QA (beta)
https://qa-reports.linaro.org
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4.4 00/43] 4.4.125-stable review
2018-03-27 16:27 [PATCH 4.4 00/43] 4.4.125-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2018-03-28 9:58 ` Greg Kroah-Hartman
@ 2018-03-28 13:38 ` Guenter Roeck
48 siblings, 0 replies; 64+ messages in thread
From: Guenter Roeck @ 2018-03-28 13:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, lkft-triage, stable
On 03/27/2018 09:27 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.125 release.
> There are 43 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 Thu Mar 29 16:27:00 UTC 2018.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 127 pass: 127 fail: 0
Guenter
^ permalink raw reply [flat|nested] 64+ messages in thread