This is the start of the stable review cycle for the 3.4.36 release.
There are 40 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 14 22:31:37 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.36-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.4.36-rc1
Greg Kroah-Hartman <[email protected]>
Revert "ALSA: hda - hdmi: Make jacks phantom, if they're not detectable"
Sarah Sharp <[email protected]>
USB: Rip out recursive call on warm port reset.
Sarah Sharp <[email protected]>
USB: Prepare for refactoring by adding extra udev checks.
Sarah Sharp <[email protected]>
USB: Don't use EHCI port sempahore for USB 3.0 hubs.
Ben Hutchings <[email protected]>
dmi_scan: fix missing check for _DMI_ signature in smbios_present()
Steven Rostedt <[email protected]>
ftrace: Update the kconfig for DYNAMIC_FTRACE
Tu, Xiaobing <[email protected]>
Fix memory leak in cpufreq stats.
Andrew Lunn <[email protected]>
rtc: rtc-mv: Add support for clk to avoid lockups
Al Viro <[email protected]>
vfs: fix pipe counter breakage
Mathieu Desnoyers <[email protected]>
Fix: compat_rw_copy_check_uvector() misuse in aio, readv, writev, and security keys
David Howells <[email protected]>
keys: fix race with concurrent install_user_keyrings()
Mathias Krause <[email protected]>
crypto: user - fix info leaks in report API
Konrad Rzeszutek Wilk <[email protected]>
xen/pat: Disable PAT using pat_enabled value.
Benjamin Tissoires <[email protected]>
HID: logitech-dj: do not directly call hid_output_raw_report() during probe
Konstantin Khlebnikov <[email protected]>
e1000e: fix pci-device enable-counter balance
Takashi Iwai <[email protected]>
ALSA: vmaster: Fix slave change notification
Sean Connor <[email protected]>
ALSA: ice1712: Initialize card->private_data properly
Will Deacon <[email protected]>
ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit
Alex Deucher <[email protected]>
drm/radeon: add primary dac adj quirk for R200 board
Guenter Roeck <[email protected]>
hwmon: (pmbus/ltc2978) Use detected chip ID to select supported functionality
Guenter Roeck <[email protected]>
hwmon: (pmbus/ltc2978) Fix peak attribute handling
Mark Brown <[email protected]>
hwmon: (sht15) Check return value of regulator_enable()
NeilBrown <[email protected]>
md: raid0: fix error return from create_stripe_zones.
NeilBrown <[email protected]>
md: fix two bugs when attempting to resize RAID0 array.
Sebastian Riemer <[email protected]>
md: protect against crash upon fsync on ro array
Felix Fietkau <[email protected]>
ath9k_hw: improve reset reliability after errors
Felix Fietkau <[email protected]>
ath9k: fix RSSI dummy marker value
Avinash Patil <[email protected]>
mwifiex: correct sleep delay counter
Rusty Russell <[email protected]>
hw_random: make buffer usable in scatterlist.
Olaf Hering <[email protected]>
ata_piix: reenable MS Virtual PC guests
Trond Myklebust <[email protected]>
SUNRPC: Don't start the retransmission timer when out of socket space
Trond Myklebust <[email protected]>
NFS: Don't allow NFS silly-renamed files to be deleted, no signal
Jeff Layton <[email protected]>
cifs: ensure that cifs_get_root() only traverses directories
Thomas Gleixner <[email protected]>
btrfs: Init io_lock after cloning btrfs device struct
Asias He <[email protected]>
target/pscsi: Fix page increment
K. Y. Srinivasan <[email protected]>
SCSI: storvsc: Initialize the sglist
Dan Carpenter <[email protected]>
SCSI: dc395x: uninitialized variable in device_alloc()
Konrad Rzeszutek Wilk <[email protected]>
xen/pci: We don't do multiple MSI's.
Russell King <[email protected]>
ARM: fix scheduling while atomic warning in alignment handling code
Russell King <[email protected]>
ARM: VFP: fix emulation of second VFP instruction
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/kirkwood.dtsi | 1 +
arch/arm/kernel/perf_event_v7.c | 2 +-
arch/arm/mm/alignment.c | 11 +--
arch/arm/vfp/vfpmodule.c | 2 +-
arch/x86/pci/xen.c | 9 ++
arch/x86/xen/enlighten.c | 10 +-
crypto/ablkcipher.c | 12 +--
crypto/aead.c | 9 +-
crypto/ahash.c | 2 +-
crypto/blkcipher.c | 6 +-
crypto/crypto_user.c | 22 ++---
crypto/pcompress.c | 3 +-
crypto/rng.c | 2 +-
crypto/shash.c | 3 +-
drivers/ata/ata_piix.c | 25 ++++-
drivers/char/hw_random/core.c | 19 +++-
drivers/cpufreq/cpufreq_stats.c | 1 +
drivers/firmware/dmi_scan.c | 5 +-
drivers/gpu/drm/radeon/radeon_combios.c | 9 ++
drivers/hid/hid-logitech-dj.c | 22 +++--
drivers/hwmon/pmbus/ltc2978.c | 30 +++---
drivers/hwmon/sht15.c | 8 +-
drivers/md/md.c | 7 ++
drivers/md/raid0.c | 5 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/wireless/ath/ath9k/common.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 4 +-
drivers/net/wireless/mwifiex/pcie.c | 2 +-
drivers/rtc/rtc-mv.c | 28 +++++-
drivers/scsi/dc395x.c | 2 +-
drivers/scsi/storvsc_drv.c | 1 +
drivers/target/target_core_pscsi.c | 1 -
drivers/usb/core/hub.c | 148 ++++++++++++++---------------
fs/btrfs/volumes.c | 1 +
fs/cifs/cifsfs.c | 5 +
fs/compat.c | 15 ++-
fs/nfs/unlink.c | 20 ++--
fs/pipe.c | 3 +
kernel/trace/Kconfig | 24 +++--
mm/process_vm_access.c | 8 --
net/sunrpc/xprt.c | 6 +-
security/keys/compat.c | 4 +-
security/keys/process_keys.c | 2 +-
sound/core/vmaster.c | 5 +-
sound/pci/hda/patch_hdmi.c | 3 -
sound/pci/ice1712/ice1712.c | 2 +
47 files changed, 311 insertions(+), 206 deletions(-)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit 5e4ba617c1b584b2e376f31a63bd4e734109318a upstream.
Martin Storsjö reports that the sequence:
ee312ac1 vsub.f32 s4, s3, s2
ee702ac0 vsub.f32 s5, s1, s0
e59f0028 ldr r0, [pc, #40]
ee111a90 vmov r1, s3
on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:
VFP: bounce: trigger ee111a90 fpexc d0000780
VFP: emulate: INST=0xee312ac1 SCR=0x00000000
...
As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC. This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.
Reported-by: Martin Storsjö <[email protected]>
Tested-by: Martin Storsjö <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/vfp/vfpmodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -413,7 +413,7 @@ void VFP_bounce(u32 trigger, u32 fpexc,
* If there isn't a second FP instruction, exit now. Note that
* the FPEXC.FP2V bit is valid only if FPEXC.EX is 1.
*/
- if (fpexc ^ (FPEXC_EX | FPEXC_FP2V))
+ if ((fpexc & (FPEXC_EX | FPEXC_FP2V)) != (FPEXC_EX | FPEXC_FP2V))
goto exit;
/*
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 3412f2f086ea7531378fabe756bd4a1109994ae6 upstream.
On many different chips, important aspects of the MAC state are not
fully cleared by a warm reset. This can show up as tx/rx hangs, those
annoying "DMA failed to stop in 10 ms..." messages or other quirks.
On AR933x, the chip can occasionally get stuck in a way that only a
driver unload/reload or a reboot would bring it back to life.
With this patch, a full reset is issued when bringing the chip out of
FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down
properly. This makes the DMA related error messages disappear completely
in my tests on AR933x, and the chip does not get stuck anymore.
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath9k/hw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1404,7 +1404,9 @@ static bool ath9k_hw_chip_reset(struct a
reset_type = ATH9K_RESET_POWER_ON;
else
reset_type = ATH9K_RESET_COLD;
- }
+ } else if (ah->chip_fullsleep || REG_READ(ah, AR_Q_TXE) ||
+ (REG_READ(ah, AR_CR) & AR_CR_RXE))
+ reset_type = ATH9K_RESET_COLD;
if (!ath9k_hw_set_reset_reg(ah, reset_type))
return false;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit f2fe09b055e2549de41fb107b34c60bac4a1b0cf upstream.
Masked out PMXEVTYPER.NSH means that we can't enable profiling at PL2,
regardless of the settings in the HDCR.
This patch fixes the broken mask.
Reported-by: Christoffer Dall <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/kernel/perf_event_v7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -775,7 +775,7 @@ static const unsigned armv7_a7_perf_cach
/*
* PMXEVTYPER: Event selection reg
*/
-#define ARMV7_EVTYPE_MASK 0xc00000ff /* Mask for writable bits */
+#define ARMV7_EVTYPE_MASK 0xc80000ff /* Mask for writable bits */
#define ARMV7_EVTYPE_EVENT 0xff /* Mask for EVENT bits */
/*
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit db05021d49a994ee40a9735d9c3cb0060c9babb8 upstream.
The prompt to enable DYNAMIC_FTRACE (the ability to nop and
enable function tracing at run time) had a confusing statement:
"enable/disable ftrace tracepoints dynamically"
This was written before tracepoints were added to the kernel,
but now that tracepoints have been added, this is very confusing
and has confused people enough to give wrong information during
presentations.
Not only that, I looked at the help text, and it still references
that dreaded daemon that use to wake up once a second to update
the nop locations and brick NICs, that hasn't been around for over
five years.
Time to bring the text up to the current decade.
Reported-by: Ezequiel Garcia <[email protected]>
Signed-off-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/Kconfig | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -386,24 +386,28 @@ config KPROBE_EVENT
If you want to use perf tools, this option is strongly recommended.
config DYNAMIC_FTRACE
- bool "enable/disable ftrace tracepoints dynamically"
+ bool "enable/disable function tracing dynamically"
depends on FUNCTION_TRACER
depends on HAVE_DYNAMIC_FTRACE
default y
help
- This option will modify all the calls to ftrace dynamically
- (will patch them out of the binary image and replace them
- with a No-Op instruction) as they are called. A table is
- created to dynamically enable them again.
+ This option will modify all the calls to function tracing
+ dynamically (will patch them out of the binary image and
+ replace them with a No-Op instruction) on boot up. During
+ compile time, a table is made of all the locations that ftrace
+ can function trace, and this table is linked into the kernel
+ image. When this is enabled, functions can be individually
+ enabled, and the functions not enabled will not affect
+ performance of the system.
+
+ See the files in /sys/kernel/debug/tracing:
+ available_filter_functions
+ set_ftrace_filter
+ set_ftrace_notrace
This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but
otherwise has native performance as long as no tracing is active.
- The changes to the code are done by a kernel thread that
- wakes up once a second and checks to see if any ftrace calls
- were made. If so, it runs stop_machine (stops all CPUS)
- and modifies the code to jump over the call to ftrace.
-
config FUNCTION_PROFILER
bool "Kernel function profiler"
depends on FUNCTION_TRACER
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
This reverts commit 30efd8debd1ef30be342d374f01e993509f5b76b upstream
(dd54ec4067a23236736afecbda120030d7ce8fe9 in this tree) as it is not
needed for the 3.4-stable tree.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Cc: David Henningsson <[email protected]>
Cc: Takashi Iwai <[email protected]>
---
sound/pci/hda/patch_hdmi.c | 3 ---
1 file changed, 3 deletions(-)
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1244,9 +1244,6 @@ static int generic_hdmi_build_jack(struc
if (pcmdev > 0)
sprintf(hdmi_str + strlen(hdmi_str), ",pcm=%d", pcmdev);
- if (!is_jack_detectable(codec, per_pin->pin_nid))
- strncat(hdmi_str, " Phantom",
- sizeof(hdmi_str) - strlen(hdmi_str) - 1);
return snd_hda_jack_add_kctl(codec, per_pin->pin_nid, hdmi_str, 0);
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
[This is upstream commit 24a6078754f28528bc91e7e7b3e6ae86bd936d8.
It needs to be backported to kernels as old as 3.2, because it fixes the
buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm
reset failure on empty port."]
When a hot reset fails on a USB 3.0 port, the current port reset code
recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
ideal, since we should avoid recursive calls in the kernel, and it also
doesn't allow us to issue multiple warm resets on reset failures.
Rip out the recursive call. Instead, add code to hub_port_reset to
issue a warm reset if the hot reset fails, and try multiple warm resets
before giving up on the port.
In hub_port_wait_reset, remove the recursive call and re-indent. The
code is basically the same, except:
1. It bails out early if the port has transitioned to Inactive or
Compliance Mode after the reset completed.
2. It doesn't consider a connect status change to be a failed reset. If
multiple warm resets needed to be issued, the connect status may have
changed, so we need to ignore that and look at the port link state
instead. hub_port_reset will now do that.
3. It unconditionally sets udev->speed on all types of successful
resets. The old recursive code would set the port speed when the second
hub_port_reset returned.
The old code did not handle connected devices needing a warm reset well.
There were only two situations that the old code handled correctly: an
empty port needing a warm reset, and a hot reset that migrated to a warm
reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
In hub_port_finish_reset, unconditionally clear the connect status
change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
had to issue multiple warm resets for a device, that bit may have been
set if the device went into SS.Inactive and then was successfully warm
reset.
Signed-off-by: Sarah Sharp <[email protected]>
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/hub.c | 148 ++++++++++++++++++++++---------------------------
1 file changed, 67 insertions(+), 81 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2207,73 +2207,35 @@ static int hub_port_wait_reset(struct us
if ((portstatus & USB_PORT_STAT_RESET))
goto delay;
- /*
- * Some buggy devices require a warm reset to be issued even
- * when the port appears not to be connected.
+ if (hub_port_warm_reset_required(hub, portstatus))
+ return -ENOTCONN;
+
+ /* Device went away? */
+ if (!(portstatus & USB_PORT_STAT_CONNECTION))
+ return -ENOTCONN;
+
+ /* bomb out completely if the connection bounced. A USB 3.0
+ * connection may bounce if multiple warm resets were issued,
+ * but the device may have successfully re-connected. Ignore it.
*/
- if (!warm) {
- /*
- * Some buggy devices can cause an NEC host controller
- * to transition to the "Error" state after a hot port
- * reset. This will show up as the port state in
- * "Inactive", and the port may also report a
- * disconnect. Forcing a warm port reset seems to make
- * the device work.
- *
- * See https://bugzilla.kernel.org/show_bug.cgi?id=41752
- */
- if (hub_port_warm_reset_required(hub, portstatus)) {
- int ret;
+ if (!hub_is_superspeed(hub->hdev) &&
+ (portchange & USB_PORT_STAT_C_CONNECTION))
+ return -ENOTCONN;
- if ((portchange & USB_PORT_STAT_C_CONNECTION))
- clear_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_C_CONNECTION);
- if (portchange & USB_PORT_STAT_C_LINK_STATE)
- clear_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_C_PORT_LINK_STATE);
- if (portchange & USB_PORT_STAT_C_RESET)
- clear_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_C_RESET);
- dev_dbg(hub->intfdev, "hot reset failed, warm reset port %d\n",
- port1);
- ret = hub_port_reset(hub, port1,
- udev, HUB_BH_RESET_TIME,
- true);
- if ((portchange & USB_PORT_STAT_C_CONNECTION))
- clear_port_feature(hub->hdev, port1,
- USB_PORT_FEAT_C_CONNECTION);
- return ret;
- }
- /* Device went away? */
- if (!(portstatus & USB_PORT_STAT_CONNECTION))
- return -ENOTCONN;
-
- /* bomb out completely if the connection bounced */
- if ((portchange & USB_PORT_STAT_C_CONNECTION))
- return -ENOTCONN;
-
- if ((portstatus & USB_PORT_STAT_ENABLE)) {
- if (!udev)
- return 0;
-
- if (hub_is_wusb(hub))
- udev->speed = USB_SPEED_WIRELESS;
- else if (hub_is_superspeed(hub->hdev))
- udev->speed = USB_SPEED_SUPER;
- else if (portstatus & USB_PORT_STAT_HIGH_SPEED)
- udev->speed = USB_SPEED_HIGH;
- else if (portstatus & USB_PORT_STAT_LOW_SPEED)
- udev->speed = USB_SPEED_LOW;
- else
- udev->speed = USB_SPEED_FULL;
+ if ((portstatus & USB_PORT_STAT_ENABLE)) {
+ if (!udev)
return 0;
- }
- } else {
- if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
- hub_port_warm_reset_required(hub,
- portstatus))
- return -ENOTCONN;
+ if (hub_is_wusb(hub))
+ udev->speed = USB_SPEED_WIRELESS;
+ else if (hub_is_superspeed(hub->hdev))
+ udev->speed = USB_SPEED_SUPER;
+ else if (portstatus & USB_PORT_STAT_HIGH_SPEED)
+ udev->speed = USB_SPEED_HIGH;
+ else if (portstatus & USB_PORT_STAT_LOW_SPEED)
+ udev->speed = USB_SPEED_LOW;
+ else
+ udev->speed = USB_SPEED_FULL;
return 0;
}
@@ -2291,23 +2253,21 @@ delay:
}
static void hub_port_finish_reset(struct usb_hub *hub, int port1,
- struct usb_device *udev, int *status, bool warm)
+ struct usb_device *udev, int *status)
{
switch (*status) {
case 0:
- if (!warm) {
- struct usb_hcd *hcd;
- /* TRSTRCY = 10 ms; plus some extra */
- msleep(10 + 40);
- if (udev) {
- update_devnum(udev, 0);
- hcd = bus_to_hcd(udev->bus);
- /* The xHC may think the device is already
- * reset, so ignore the status.
- */
- if (hcd->driver->reset_device)
- hcd->driver->reset_device(hcd, udev);
- }
+ /* TRSTRCY = 10 ms; plus some extra */
+ msleep(10 + 40);
+ if (udev) {
+ struct usb_hcd *hcd = bus_to_hcd(udev->bus);
+
+ update_devnum(udev, 0);
+ /* The xHC may think the device is already reset,
+ * so ignore the status.
+ */
+ if (hcd->driver->reset_device)
+ hcd->driver->reset_device(hcd, udev);
}
/* FALL THROUGH */
case -ENOTCONN:
@@ -2320,8 +2280,10 @@ static void hub_port_finish_reset(struct
USB_PORT_FEAT_C_BH_PORT_RESET);
clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
+ clear_port_feature(hub->hdev, port1,
+ USB_PORT_FEAT_C_CONNECTION);
}
- if (!warm && udev)
+ if (udev)
usb_set_device_state(udev, *status
? USB_STATE_NOTATTACHED
: USB_STATE_DEFAULT);
@@ -2334,6 +2296,7 @@ static int hub_port_reset(struct usb_hub
struct usb_device *udev, unsigned int delay, bool warm)
{
int i, status;
+ u16 portchange, portstatus;
if (!hub_is_superspeed(hub->hdev)) {
if (warm) {
@@ -2365,10 +2328,33 @@ static int hub_port_reset(struct usb_hub
status);
}
- /* return on disconnect or reset */
+ /* Check for disconnect or reset */
if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
- hub_port_finish_reset(hub, port1, udev, &status, warm);
- goto done;
+ hub_port_finish_reset(hub, port1, udev, &status);
+
+ if (!hub_is_superspeed(hub->hdev))
+ goto done;
+
+ /*
+ * If a USB 3.0 device migrates from reset to an error
+ * state, re-issue the warm reset.
+ */
+ if (hub_port_status(hub, port1,
+ &portstatus, &portchange) < 0)
+ goto done;
+
+ if (!hub_port_warm_reset_required(hub, portstatus))
+ goto done;
+
+ /*
+ * If the port is in SS.Inactive or Compliance Mode, the
+ * hot or warm reset failed. Try another warm reset.
+ */
+ if (!warm) {
+ dev_dbg(hub->intfdev, "hot reset failed, warm reset port %d\n",
+ port1);
+ warm = true;
+ }
}
dev_dbg (hub->intfdev,
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 2069d483b39a603a5f3428a19d3b4ac89aa97f48 upstream.
When a value of a vmaster slave control is changed, the ctl change
notification is sometimes ignored. This happens when the master
control overrides, e.g. when the corresponding master control is
muted. The reason is that slave_put() returns the value of the actual
slave put callback, and it doesn't reflect the virtual slave value
change.
This patch fixes the function just to return 1 whenever a slave value
is changed.
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/vmaster.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/sound/core/vmaster.c
+++ b/sound/core/vmaster.c
@@ -213,7 +213,10 @@ static int slave_put(struct snd_kcontrol
}
if (!changed)
return 0;
- return slave_put_val(slave, ucontrol);
+ err = slave_put_val(slave, ucontrol);
+ if (err < 0)
+ return err;
+ return 1;
}
static int slave_tlv_cmd(struct snd_kcontrol *kcontrol,
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
[This is upstream commit 2d4fa940f99663c82ba55b2244638833b388e4e2.
It needs to be backported to kernels as old as 3.2, because it fixes the
buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm
reset failure on empty port."]
The next patch will refactor the hub port code to rip out the recursive
call to hub_port_reset on a failed hot reset. In preparation for that,
make sure all code paths can deal with being called with a NULL udev.
The usb_device will not be valid if warm reset was issued because a port
transitioned to the Inactive or Compliance Mode on a device connect.
This patch should have no effect on current behavior.
Signed-off-by: Sarah Sharp <[email protected]>
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/hub.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2253,6 +2253,9 @@ static int hub_port_wait_reset(struct us
return -ENOTCONN;
if ((portstatus & USB_PORT_STAT_ENABLE)) {
+ if (!udev)
+ return 0;
+
if (hub_is_wusb(hub))
udev->speed = USB_SPEED_WIRELESS;
else if (hub_is_superspeed(hub->hdev))
@@ -2296,13 +2299,15 @@ static void hub_port_finish_reset(struct
struct usb_hcd *hcd;
/* TRSTRCY = 10 ms; plus some extra */
msleep(10 + 40);
- update_devnum(udev, 0);
- hcd = bus_to_hcd(udev->bus);
- /* The xHC may think the device is already reset,
- * so ignore the status.
- */
- if (hcd->driver->reset_device)
- hcd->driver->reset_device(hcd, udev);
+ if (udev) {
+ update_devnum(udev, 0);
+ hcd = bus_to_hcd(udev->bus);
+ /* The xHC may think the device is already
+ * reset, so ignore the status.
+ */
+ if (hcd->driver->reset_device)
+ hcd->driver->reset_device(hcd, udev);
+ }
}
/* FALL THROUGH */
case -ENOTCONN:
@@ -2316,7 +2321,7 @@ static void hub_port_finish_reset(struct
clear_port_feature(hub->hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
}
- if (!warm)
+ if (!warm && udev)
usb_set_device_state(udev, *status
? USB_STATE_NOTATTACHED
: USB_STATE_DEFAULT);
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit a40e7cf8f06b4e322ba902e4e9f6a6b0c2daa907 upstream.
Commit 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version
from SMBIOS if it exists") hoisted the check for "_DMI_" into
dmi_scan_machine(), which means that we don't bother to check for
"_DMI_" at offset 16 in an SMBIOS entry. smbios_present() may also call
dmi_present() for an address where we found "_SM_", if it failed further
validation.
Check for "_DMI_" in smbios_present() before calling dmi_present().
[[email protected]: fix build]
Signed-off-by: Ben Hutchings <[email protected]>
Reported-by: Tim McGrath <[email protected]>
Tested-by: Tim Mcgrath <[email protected]>
Cc: Zhenzhong Duan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/firmware/dmi_scan.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -442,7 +442,6 @@ static int __init dmi_present(const char
static int __init smbios_present(const char __iomem *p)
{
u8 buf[32];
- int offset = 0;
memcpy_fromio(buf, p, 32);
if ((buf[5] < 32) && dmi_checksum(buf, buf[5])) {
@@ -461,9 +460,9 @@ static int __init smbios_present(const c
dmi_ver = 0x0206;
break;
}
- offset = 16;
+ return memcmp(p + 16, "_DMI_", 5) || dmi_present(p + 16);
}
- return dmi_present(buf + offset);
+ return 1;
}
void __init dmi_scan_machine(void)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
[This is upstream commit 0fe51aa5eee51db7c7ecd201d42a977ad79c58b6.
It needs to be backported to kernels as old as 3.2, because it fixes the
buggy commit 9dbcaec830cd97f44a0b91b315844e0d7144746b "USB: Handle warm
reset failure on empty port."]
The EHCI host controller needs to prevent EHCI initialization when the
UHCI or OHCI companion controller is in the middle of a port reset. It
uses ehci_cf_port_reset_rwsem to do this. USB 3.0 hubs can't be under
an EHCI host controller, so it makes no sense to down the semaphore for
USB 3.0 hubs. It also makes the warm port reset code more complex.
Don't down ehci_cf_port_reset_rwsem for USB 3.0 hubs.
Signed-off-by: Sarah Sharp <[email protected]>
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/core/hub.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2330,17 +2330,16 @@ static int hub_port_reset(struct usb_hub
{
int i, status;
- if (!warm) {
- /* Block EHCI CF initialization during the port reset.
- * Some companion controllers don't like it when they mix.
- */
- down_read(&ehci_cf_port_reset_rwsem);
- } else {
- if (!hub_is_superspeed(hub->hdev)) {
+ if (!hub_is_superspeed(hub->hdev)) {
+ if (warm) {
dev_err(hub->intfdev, "only USB3 hub support "
"warm reset\n");
return -EINVAL;
}
+ /* Block EHCI CF initialization during the port reset.
+ * Some companion controllers don't like it when they mix.
+ */
+ down_read(&ehci_cf_port_reset_rwsem);
}
/* Reset the port */
@@ -2378,7 +2377,7 @@ static int hub_port_reset(struct usb_hub
port1);
done:
- if (!warm)
+ if (!hub_is_superspeed(hub->hdev))
up_read(&ehci_cf_port_reset_rwsem);
return status;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Tu, Xiaobing" <[email protected]>
commit e37736777254ce1abc85493a5cacbefe5983b896 upstream.
When system enters sleep, non-boot CPUs will be disabled.
Cpufreq stats sysfs is created when the CPU is up, but it is not
freed when the CPU is going down. This will cause memory leak.
Signed-off-by: xiaobing tu <[email protected]>
Signed-off-by: guifang tang <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Cc: Colin Cross <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpufreq/cpufreq_stats.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -328,6 +328,7 @@ static int __cpuinit cpufreq_stat_cpu_ca
cpufreq_update_policy(cpu);
break;
case CPU_DOWN_PREPARE:
+ case CPU_DOWN_PREPARE_FROZEN:
cpufreq_stats_free_sysfs(cpu);
break;
case CPU_DEAD:
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Connor <[email protected]>
commit 69a4cfdd444d1fe5c24d29b3a063964ac165d2cd upstream.
Set card->private_data in snd_ice1712_create for fixing NULL
dereference in snd_ice1712_remove().
Signed-off-by: Sean Connor <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/pci/ice1712/ice1712.c | 2 ++
1 file changed, 2 insertions(+)
--- a/sound/pci/ice1712/ice1712.c
+++ b/sound/pci/ice1712/ice1712.c
@@ -2595,6 +2595,8 @@ static int __devinit snd_ice1712_create(
snd_ice1712_proc_init(ice);
synchronize_irq(pci->irq);
+ card->private_data = ice;
+
err = pci_request_regions(pci, "ICE1712");
if (err < 0) {
kfree(ice);
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Lunn <[email protected]>
commit 89c58c198b252f2bc20657fdd72a2aea788c435c upstream.
The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the
driver clk_prepare_enable() this clock, otherwise there is a danger
the SoC will lockup when accessing RTC registers with the clock
disabled.
Reported-by: Simon Baatz <[email protected]>
Signed-off-by: Andrew Lunn <[email protected]>
Tested-by: Simon Baatz <[email protected]>
Signed-off-by: Jason Cooper <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/boot/dts/kirkwood.dtsi | 1 +
drivers/rtc/rtc-mv.c | 28 ++++++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -31,6 +31,7 @@
compatible = "mrvl,kirkwood-rtc", "mrvl,orion-rtc";
reg = <0x10300 0x20>;
interrupts = <53>;
+ clocks = <&gate_clk 7>;
};
};
};
--- a/drivers/rtc/rtc-mv.c
+++ b/drivers/rtc/rtc-mv.c
@@ -14,6 +14,7 @@
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/delay.h>
+#include <linux/clk.h>
#include <linux/gfp.h>
#include <linux/module.h>
@@ -41,6 +42,7 @@ struct rtc_plat_data {
struct rtc_device *rtc;
void __iomem *ioaddr;
int irq;
+ struct clk *clk;
};
static int mv_rtc_set_time(struct device *dev, struct rtc_time *tm)
@@ -221,6 +223,7 @@ static int __devinit mv_rtc_probe(struct
struct rtc_plat_data *pdata;
resource_size_t size;
u32 rtc_time;
+ int ret = 0;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
@@ -239,11 +242,17 @@ static int __devinit mv_rtc_probe(struct
if (!pdata->ioaddr)
return -ENOMEM;
+ pdata->clk = devm_clk_get(&pdev->dev, NULL);
+ /* Not all SoCs require a clock.*/
+ if (!IS_ERR(pdata->clk))
+ clk_prepare_enable(pdata->clk);
+
/* make sure the 24 hours mode is enabled */
rtc_time = readl(pdata->ioaddr + RTC_TIME_REG_OFFS);
if (rtc_time & RTC_HOURS_12H_MODE) {
dev_err(&pdev->dev, "24 Hours mode not supported.\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
/* make sure it is actually functional */
@@ -252,7 +261,8 @@ static int __devinit mv_rtc_probe(struct
rtc_time = readl(pdata->ioaddr + RTC_TIME_REG_OFFS);
if (rtc_time == 0x01000000) {
dev_err(&pdev->dev, "internal RTC not ticking\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto out;
}
}
@@ -268,8 +278,10 @@ static int __devinit mv_rtc_probe(struct
} else
pdata->rtc = rtc_device_register(pdev->name, &pdev->dev,
&mv_rtc_ops, THIS_MODULE);
- if (IS_ERR(pdata->rtc))
- return PTR_ERR(pdata->rtc);
+ if (IS_ERR(pdata->rtc)) {
+ ret = PTR_ERR(pdata->rtc);
+ goto out;
+ }
if (pdata->irq >= 0) {
writel(0, pdata->ioaddr + RTC_ALARM_INTERRUPT_MASK_REG_OFFS);
@@ -282,6 +294,11 @@ static int __devinit mv_rtc_probe(struct
}
return 0;
+out:
+ if (!IS_ERR(pdata->clk))
+ clk_disable_unprepare(pdata->clk);
+
+ return ret;
}
static int __exit mv_rtc_remove(struct platform_device *pdev)
@@ -292,6 +309,9 @@ static int __exit mv_rtc_remove(struct p
device_init_wakeup(&pdev->dev, 0);
rtc_device_unregister(pdata->rtc);
+ if (!IS_ERR(pdata->clk))
+ clk_disable_unprepare(pdata->clk);
+
return 0;
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit a930d8790552658140d7d0d2e316af4f0d76a512 upstream.
If you open a pipe for neither read nor write, the pipe code will not
add any usage counters to the pipe, causing the 'struct pipe_inode_info"
to be potentially released early.
That doesn't normally matter, since you cannot actually use the pipe,
but the pipe release code - particularly fasync handling - still expects
the actual pipe infrastructure to all be there. And rather than adding
NULL pointer checks, let's just disallow this case, the same way we
already do for the named pipe ("fifo") case.
This is ancient going back to pre-2.4 days, and until trinity, nobody
naver noticed.
Reported-by: Dave Jones <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/pipe.c | 3 +++
1 file changed, 3 insertions(+)
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -860,6 +860,9 @@ pipe_rdwr_open(struct inode *inode, stru
{
int ret = -ENOENT;
+ if (!(filp->f_mode & (FMODE_READ|FMODE_WRITE)))
+ return -EINVAL;
+
mutex_lock(&inode->i_mutex);
if (inode->i_pipe) {
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream.
RSSI is being stored internally as s8 in several places. The indication
of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
set to 127, but ended up being set to 0x127 because of a code cleanup
mistake. This could lead to invalid signal strength values in a few
places.
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath9k/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/ath/ath9k/common.h
+++ b/drivers/net/wireless/ath/ath9k/common.h
@@ -35,7 +35,7 @@
#define WME_AC_BK 3
#define WME_NUM_AC 4
-#define ATH_RSSI_DUMMY_MARKER 0x127
+#define ATH_RSSI_DUMMY_MARKER 127
#define ATH_RSSI_LPF_LEN 10
#define RSSI_LPF_THRESHOLD -20
#define ATH_RSSI_EP_MULTIPLIER (1<<7)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathieu Desnoyers <[email protected]>
commit 8aec0f5d4137532de14e6554fd5dd201ff3a3c49 upstream.
Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to
compat_process_vm_rw() shows that the compatibility code requires an
explicit "access_ok()" check before calling
compat_rw_copy_check_uvector(). The same difference seems to appear when
we compare fs/read_write.c:do_readv_writev() to
fs/compat.c:compat_do_readv_writev().
This subtle difference between the compat and non-compat requirements
should probably be debated, as it seems to be error-prone. In fact,
there are two others sites that use this function in the Linux kernel,
and they both seem to get it wrong:
Now shifting our attention to fs/aio.c, we see that aio_setup_iocb()
also ends up calling compat_rw_copy_check_uvector() through
aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to
be missing. Same situation for
security/keys/compat.c:compat_keyctl_instantiate_key_iov().
I propose that we add the access_ok() check directly into
compat_rw_copy_check_uvector(), so callers don't have to worry about it,
and it therefore makes the compat call code similar to its non-compat
counterpart. Place the access_ok() check in the same location where
copy_from_user() can trigger a -EFAULT error in the non-compat code, so
the ABI behaviors are alike on both compat and non-compat.
While we are here, fix compat_do_readv_writev() so it checks for
compat_rw_copy_check_uvector() negative return values.
And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error
handling.
Acked-by: Linus Torvalds <[email protected]>
Acked-by: Al Viro <[email protected]>
Signed-off-by: Mathieu Desnoyers <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/compat.c | 15 +++++++--------
mm/process_vm_access.c | 8 --------
security/keys/compat.c | 4 ++--
3 files changed, 9 insertions(+), 18 deletions(-)
--- a/fs/compat.c
+++ b/fs/compat.c
@@ -558,6 +558,10 @@ ssize_t compat_rw_copy_check_uvector(int
}
*ret_pointer = iov;
+ ret = -EFAULT;
+ if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
+ goto out;
+
/*
* Single unix specification:
* We should -EINVAL if an element length is not >= 0 and fitting an
@@ -1089,17 +1093,12 @@ static ssize_t compat_do_readv_writev(in
if (!file->f_op)
goto out;
- ret = -EFAULT;
- if (!access_ok(VERIFY_READ, uvector, nr_segs*sizeof(*uvector)))
- goto out;
-
- tot_len = compat_rw_copy_check_uvector(type, uvector, nr_segs,
+ ret = compat_rw_copy_check_uvector(type, uvector, nr_segs,
UIO_FASTIOV, iovstack, &iov, 1);
- if (tot_len == 0) {
- ret = 0;
+ if (ret <= 0)
goto out;
- }
+ tot_len = ret;
ret = rw_verify_area(type, file, pos, tot_len);
if (ret < 0)
goto out;
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -429,12 +429,6 @@ compat_process_vm_rw(compat_pid_t pid,
if (flags != 0)
return -EINVAL;
- if (!access_ok(VERIFY_READ, lvec, liovcnt * sizeof(*lvec)))
- goto out;
-
- if (!access_ok(VERIFY_READ, rvec, riovcnt * sizeof(*rvec)))
- goto out;
-
if (vm_write)
rc = compat_rw_copy_check_uvector(WRITE, lvec, liovcnt,
UIO_FASTIOV, iovstack_l,
@@ -459,8 +453,6 @@ free_iovecs:
kfree(iov_r);
if (iov_l != iovstack_l)
kfree(iov_l);
-
-out:
return rc;
}
--- a/security/keys/compat.c
+++ b/security/keys/compat.c
@@ -40,12 +40,12 @@ long compat_keyctl_instantiate_key_iov(
ARRAY_SIZE(iovstack),
iovstack, &iov, 1);
if (ret < 0)
- return ret;
+ goto err;
if (ret == 0)
goto no_payload_free;
ret = keyctl_instantiate_key_common(id, iov, ioc, ret, ringid);
-
+err:
if (iov != iovstack)
kfree(iov);
return ret;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Krause <[email protected]>
commit 9a5467bf7b6e9e02ec9c3da4e23747c05faeaac6 upstream.
Three errors resulting in kernel memory disclosure:
1/ The structures used for the netlink based crypto algorithm report API
are located on the stack. As snprintf() does not fill the remainder of
the buffer with null bytes, those stack bytes will be disclosed to users
of the API. Switch to strncpy() to fix this.
2/ crypto_report_one() does not initialize all field of struct
crypto_user_alg. Fix this to fix the heap info leak.
3/ For the module name we should copy only as many bytes as
module_name() returns -- not as much as the destination buffer could
hold. But the current code does not and therefore copies random data
from behind the end of the module name, as the module name is always
shorter than CRYPTO_MAX_ALG_NAME.
Also switch to use strncpy() to copy the algorithm's name and
driver_name. They are strings, after all.
Signed-off-by: Mathias Krause <[email protected]>
Cc: Steffen Klassert <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
crypto/ablkcipher.c | 12 ++++++------
crypto/aead.c | 9 ++++-----
crypto/ahash.c | 2 +-
crypto/blkcipher.c | 6 +++---
crypto/crypto_user.c | 20 ++++++++++----------
crypto/pcompress.c | 3 +--
crypto/rng.c | 2 +-
crypto/shash.c | 3 ++-
8 files changed, 28 insertions(+), 29 deletions(-)
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -388,9 +388,9 @@ static int crypto_ablkcipher_report(stru
{
struct crypto_report_blkcipher rblkcipher;
- snprintf(rblkcipher.type, CRYPTO_MAX_ALG_NAME, "%s", "ablkcipher");
- snprintf(rblkcipher.geniv, CRYPTO_MAX_ALG_NAME, "%s",
- alg->cra_ablkcipher.geniv ?: "<default>");
+ strncpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
+ strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<default>",
+ sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize;
@@ -469,9 +469,9 @@ static int crypto_givcipher_report(struc
{
struct crypto_report_blkcipher rblkcipher;
- snprintf(rblkcipher.type, CRYPTO_MAX_ALG_NAME, "%s", "givcipher");
- snprintf(rblkcipher.geniv, CRYPTO_MAX_ALG_NAME, "%s",
- alg->cra_ablkcipher.geniv ?: "<built-in>");
+ strncpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
+ strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "<built-in>",
+ sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
rblkcipher.min_keysize = alg->cra_ablkcipher.min_keysize;
--- a/crypto/aead.c
+++ b/crypto/aead.c
@@ -117,9 +117,8 @@ static int crypto_aead_report(struct sk_
struct crypto_report_aead raead;
struct aead_alg *aead = &alg->cra_aead;
- snprintf(raead.type, CRYPTO_MAX_ALG_NAME, "%s", "aead");
- snprintf(raead.geniv, CRYPTO_MAX_ALG_NAME, "%s",
- aead->geniv ?: "<built-in>");
+ strncpy(raead.type, "aead", sizeof(raead.type));
+ strncpy(raead.geniv, aead->geniv ?: "<built-in>", sizeof(raead.geniv));
raead.blocksize = alg->cra_blocksize;
raead.maxauthsize = aead->maxauthsize;
@@ -203,8 +202,8 @@ static int crypto_nivaead_report(struct
struct crypto_report_aead raead;
struct aead_alg *aead = &alg->cra_aead;
- snprintf(raead.type, CRYPTO_MAX_ALG_NAME, "%s", "nivaead");
- snprintf(raead.geniv, CRYPTO_MAX_ALG_NAME, "%s", aead->geniv);
+ strncpy(raead.type, "nivaead", sizeof(raead.type));
+ strncpy(raead.geniv, aead->geniv, sizeof(raead.geniv));
raead.blocksize = alg->cra_blocksize;
raead.maxauthsize = aead->maxauthsize;
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -404,7 +404,7 @@ static int crypto_ahash_report(struct sk
{
struct crypto_report_hash rhash;
- snprintf(rhash.type, CRYPTO_MAX_ALG_NAME, "%s", "ahash");
+ strncpy(rhash.type, "ahash", sizeof(rhash.type));
rhash.blocksize = alg->cra_blocksize;
rhash.digestsize = __crypto_hash_alg_common(alg)->digestsize;
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -499,9 +499,9 @@ static int crypto_blkcipher_report(struc
{
struct crypto_report_blkcipher rblkcipher;
- snprintf(rblkcipher.type, CRYPTO_MAX_ALG_NAME, "%s", "blkcipher");
- snprintf(rblkcipher.geniv, CRYPTO_MAX_ALG_NAME, "%s",
- alg->cra_blkcipher.geniv ?: "<default>");
+ strncpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
+ strncpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "<default>",
+ sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
rblkcipher.min_keysize = alg->cra_blkcipher.min_keysize;
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -75,7 +75,7 @@ static int crypto_report_cipher(struct s
{
struct crypto_report_cipher rcipher;
- snprintf(rcipher.type, CRYPTO_MAX_ALG_NAME, "%s", "cipher");
+ strncpy(rcipher.type, "cipher", sizeof(rcipher.type));
rcipher.blocksize = alg->cra_blocksize;
rcipher.min_keysize = alg->cra_cipher.cia_min_keysize;
@@ -94,8 +94,7 @@ static int crypto_report_comp(struct sk_
{
struct crypto_report_comp rcomp;
- snprintf(rcomp.type, CRYPTO_MAX_ALG_NAME, "%s", "compression");
-
+ strncpy(rcomp.type, "compression", sizeof(rcomp.type));
NLA_PUT(skb, CRYPTOCFGA_REPORT_COMPRESS,
sizeof(struct crypto_report_comp), &rcomp);
@@ -108,12 +107,14 @@ nla_put_failure:
static int crypto_report_one(struct crypto_alg *alg,
struct crypto_user_alg *ualg, struct sk_buff *skb)
{
- memcpy(&ualg->cru_name, &alg->cra_name, sizeof(ualg->cru_name));
- memcpy(&ualg->cru_driver_name, &alg->cra_driver_name,
- sizeof(ualg->cru_driver_name));
- memcpy(&ualg->cru_module_name, module_name(alg->cra_module),
- CRYPTO_MAX_ALG_NAME);
+ strncpy(ualg->cru_name, alg->cra_name, sizeof(ualg->cru_name));
+ strncpy(ualg->cru_driver_name, alg->cra_driver_name,
+ sizeof(ualg->cru_driver_name));
+ strncpy(ualg->cru_module_name, module_name(alg->cra_module),
+ sizeof(ualg->cru_module_name));
+ ualg->cru_type = 0;
+ ualg->cru_mask = 0;
ualg->cru_flags = alg->cra_flags;
ualg->cru_refcnt = atomic_read(&alg->cra_refcnt);
@@ -122,8 +123,7 @@ static int crypto_report_one(struct cryp
if (alg->cra_flags & CRYPTO_ALG_LARVAL) {
struct crypto_report_larval rl;
- snprintf(rl.type, CRYPTO_MAX_ALG_NAME, "%s", "larval");
-
+ strncpy(rl.type, "larval", sizeof(rl.type));
NLA_PUT(skb, CRYPTOCFGA_REPORT_LARVAL,
sizeof(struct crypto_report_larval), &rl);
--- a/crypto/pcompress.c
+++ b/crypto/pcompress.c
@@ -53,8 +53,7 @@ static int crypto_pcomp_report(struct sk
{
struct crypto_report_comp rpcomp;
- snprintf(rpcomp.type, CRYPTO_MAX_ALG_NAME, "%s", "pcomp");
-
+ strncpy(rpcomp.type, "pcomp", sizeof(rpcomp.type));
NLA_PUT(skb, CRYPTOCFGA_REPORT_COMPRESS,
sizeof(struct crypto_report_comp), &rpcomp);
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -65,7 +65,7 @@ static int crypto_rng_report(struct sk_b
{
struct crypto_report_rng rrng;
- snprintf(rrng.type, CRYPTO_MAX_ALG_NAME, "%s", "rng");
+ strncpy(rrng.type, "rng", sizeof(rrng.type));
rrng.seedsize = alg->cra_rng.seedsize;
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -530,7 +530,8 @@ static int crypto_shash_report(struct sk
struct crypto_report_hash rhash;
struct shash_alg *salg = __crypto_shash_alg(alg);
- snprintf(rhash.type, CRYPTO_MAX_ALG_NAME, "%s", "shash");
+ strncpy(rhash.type, "shash", sizeof(rhash.type));
+
rhash.blocksize = alg->cra_blocksize;
rhash.digestsize = salg->digestsize;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Howells <[email protected]>
commit 0da9dfdd2cd9889201bc6f6f43580c99165cd087 upstream.
This fixes CVE-2013-1792.
There is a race in install_user_keyrings() that can cause a NULL pointer
dereference when called concurrently for the same user if the uid and
uid-session keyrings are not yet created. It might be possible for an
unprivileged user to trigger this by calling keyctl() from userspace in
parallel immediately after logging in.
Assume that we have two threads both executing lookup_user_key(), both
looking for KEY_SPEC_USER_SESSION_KEYRING.
THREAD A THREAD B
=============================== ===============================
==>call install_user_keyrings();
if (!cred->user->session_keyring)
==>call install_user_keyrings()
...
user->uid_keyring = uid_keyring;
if (user->uid_keyring)
return 0;
<==
key = cred->user->session_keyring [== NULL]
user->session_keyring = session_keyring;
atomic_inc(&key->usage); [oops]
At the point thread A dereferences cred->user->session_keyring, thread B
hasn't updated user->session_keyring yet, but thread A assumes it is
populated because install_user_keyrings() returned ok.
The race window is really small but can be exploited if, for example,
thread B is interrupted or preempted after initializing uid_keyring, but
before doing setting session_keyring.
This couldn't be reproduced on a stock kernel. However, after placing
systemtap probe on 'user->session_keyring = session_keyring;' that
introduced some delay, the kernel could be crashed reliably.
Fix this by checking both pointers before deciding whether to return.
Alternatively, the test could be done away with entirely as it is checked
inside the mutex - but since the mutex is global, that may not be the best
way.
Signed-off-by: David Howells <[email protected]>
Reported-by: Mateusz Guzik <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: James Morris <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
security/keys/process_keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -54,7 +54,7 @@ int install_user_keyrings(void)
kenter("%p{%u}", user, user->uid);
- if (user->uid_keyring) {
+ if (user->uid_keyring && user->session_keyring) {
kleave(" = 0 [exist]");
return 0;
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Rzeszutek Wilk <[email protected]>
commit c79c49826270b8b0061b2fca840fc3f013c8a78a upstream.
The git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
(xen/pat: Disable PAT support for now) explains in details why
we want to disable PAT for right now. However that
change was not enough and we should have also disabled
the pat_enabled value. Otherwise we end up with:
mmap-example:3481 map pfn expected mapping type write-back for
[mem 0x00010000-0x00010fff], got uncached-minus
------------[ cut here ]------------
WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0()
mem 0x00010000-0x00010fff], got uncached-minus
------------[ cut here ]------------
WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774
untrack_pfn+0xb8/0xd0()
...
Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu
Call Trace:
[<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0
[<ffffffff81156c1c>] unmap_single_vma+0xac/0x100
[<ffffffff81157459>] unmap_vmas+0x49/0x90
[<ffffffff8115f808>] exit_mmap+0x98/0x170
[<ffffffff810559a4>] mmput+0x64/0x100
[<ffffffff810560f5>] dup_mm+0x445/0x660
[<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510
[<ffffffff81057931>] do_fork+0x91/0x350
[<ffffffff81057c76>] sys_clone+0x16/0x20
[<ffffffff816ccbf9>] stub_clone+0x69/0x90
[<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f
---[ end trace 4918cdd0a4c9fea4 ]---
(a similar message shows up if you end up launching 'mcelog')
The call chain is (as analyzed by Liu, Jinsong):
do_fork
--> copy_process
--> dup_mm
--> dup_mmap
--> copy_page_range
--> track_pfn_copy
--> reserve_pfn_range
--> line 624: flags != want_flags
It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR
(_PAGE_CACHE_UC_MINUS).
Stefan Bader dug in this deep and found out that:
"That makes it clearer as this will do
reserve_memtype(...)
--> pat_x_mtrr_type
--> mtrr_type_lookup
--> __mtrr_type_lookup
And that can return -1/0xff in case of MTRR not being enabled/initialized. Which
is not the case (given there are no messages for it in dmesg). This is not equal
to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS.
It looks like the problem starts early in reserve_memtype:
if (!pat_enabled) {
/* This is identical to page table setting without PAT */
if (new_type) {
if (req_type == _PAGE_CACHE_WC)
*new_type = _PAGE_CACHE_UC_MINUS;
else
*new_type = req_type & _PAGE_CACHE_MASK;
}
return 0;
}
This would be what we want, that is clearing the PWT and PCD flags from the
supported flags - if pat_enabled is disabled."
This patch does that - disabling PAT.
Reported-by: Sander Eikelenboom <[email protected]>
Reported-and-Tested-by: Konrad Rzeszutek Wilk <[email protected]>
Reported-and-Tested-by: Stefan Bader <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/xen/enlighten.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -64,6 +64,7 @@
#include <asm/hypervisor.h>
#include <asm/mwait.h>
#include <asm/pci_x86.h>
+#include <asm/pat.h>
#ifdef CONFIG_ACPI
#include <linux/acpi.h>
@@ -1355,7 +1356,14 @@ asmlinkage void __init xen_start_kernel(
*/
acpi_numa = -1;
#endif
-
+#ifdef CONFIG_X86_PAT
+ /*
+ * For right now disable the PAT. We should remove this once
+ * git commit 8eaffa67b43e99ae581622c5133e20b0f48bcef1
+ * (xen/pat: Disable PAT support for now) is reverted.
+ */
+ pat_enabled = 0;
+#endif
pgd = (pgd_t *)xen_start_info->pt_base;
/* Don't do the full vcpu_info placement stuff until we have a
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <[email protected]>
commit 4e0855dff094b0d56d6b5b271e0ce7851cc1e063 upstream.
This patch removes redundant and unbalanced pci_disable_device() from
__e1000_shutdown(). pci_clear_master() is enough, device can go into
suspended state with elevated enable_cnt.
Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35
Signed-off-by: Konstantin Khlebnikov <[email protected]>
Cc: Bruce Allan <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Tested-by: Borislav Petkov <[email protected]>
Tested-by: Aaron Brown <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5535,7 +5535,7 @@ static int __e1000_shutdown(struct pci_d
*/
e1000e_release_hw_control(adapter);
- pci_disable_device(pdev);
+ pci_clear_master(pdev);
return 0;
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <[email protected]>
commit dcd9006b1b053c7b1cebe81333261d4fd492ffeb upstream.
hid_output_raw_report() makes a direct call to usb_control_msg(). However,
some USB3 boards have shown that the usb device is not ready during the
.probe(). This blocks the entire usb device, and the paired mice, keyboards
are not functional. The dmesg output is the following:
[ 11.912287] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-2/input2
[ 11.912537] logitech-djreceiver 0003:046D:C52B.0003: logi_dj_probe:logi_dj_recv_query_paired_devices error:-32
[ 11.912636] logitech-djreceiver: probe of 0003:046D:C52B.0003 failed with error -32
Relying on the scheduled call to usbhid_submit_report() fixes the problem.
related bugs:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072082
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1039143
https://bugzilla.redhat.com/show_bug.cgi?id=840391
https://bugzilla.kernel.org/show_bug.cgi?id=49781
Reported-and-tested-by: Bob Bowles <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-logitech-dj.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -451,19 +451,25 @@ static int logi_dj_recv_send_report(stru
struct dj_report *dj_report)
{
struct hid_device *hdev = djrcv_dev->hdev;
- int sent_bytes;
+ struct hid_report *report;
+ struct hid_report_enum *output_report_enum;
+ u8 *data = (u8 *)(&dj_report->device_index);
+ int i;
- if (!hdev->hid_output_raw_report) {
- dev_err(&hdev->dev, "%s:"
- "hid_output_raw_report is null\n", __func__);
+ output_report_enum = &hdev->report_enum[HID_OUTPUT_REPORT];
+ report = output_report_enum->report_id_hash[REPORT_ID_DJ_SHORT];
+
+ if (!report) {
+ dev_err(&hdev->dev, "%s: unable to find dj report\n", __func__);
return -ENODEV;
}
- sent_bytes = hdev->hid_output_raw_report(hdev, (u8 *) dj_report,
- sizeof(struct dj_report),
- HID_OUTPUT_REPORT);
+ for (i = 0; i < report->field[0]->report_count; i++)
+ report->field[0]->value[i] = data[i];
+
+ usbhid_submit_report(hdev, report, USB_DIR_OUT);
- return (sent_bytes < 0) ? sent_bytes : 0;
+ return 0;
}
static int logi_dj_recv_query_paired_devices(struct dj_receiver_dev *djrcv_dev)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit e8fc41377f5037ff7a661ea06adc05f1daec1548 upstream.
vbios values are wrong leading to colors that are
too bright. Use the default values instead.
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/radeon_combios.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -958,6 +958,15 @@ struct radeon_encoder_primary_dac *radeo
found = 1;
}
+ /* quirks */
+ /* Radeon 9100 (R200) */
+ if ((dev->pdev->device == 0x514D) &&
+ (dev->pdev->subsystem_vendor == 0x174B) &&
+ (dev->pdev->subsystem_device == 0x7149)) {
+ /* vbios value is bad, use the default */
+ found = 0;
+ }
+
if (!found) /* fallback to defaults */
radeon_legacy_get_primary_dac_info_from_table(rdev, p_dac);
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit f366fccd0809f13ba20d64cae3c83f7338c88af7 upstream.
We read the chip ID from the chip, use it to determine if the chip ID provided
to the driver is correct, and report it if wrong. We should also use the
correct chip ID to select supported functionality.
Signed-off-by: Guenter Roeck <[email protected]>
Acked-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/pmbus/ltc2978.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -326,7 +326,7 @@ static int ltc2978_probe(struct i2c_clie
data->temp_max = 0x7c00;
data->temp2_max = 0x7c00;
- switch (id->driver_data) {
+ switch (data->id) {
case ltc2978:
info->read_word_data = ltc2978_read_word_data;
info->pages = 8;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit dbd712c2272764a536e29ad6841dba74989a39d9 upstream.
Peak attributes were not initialized and cleared correctly.
Also, temp2_max is only supported on page 0 and thus does not need to be
an array.
Signed-off-by: Guenter Roeck <[email protected]>
Acked-by: Jean Delvare <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/pmbus/ltc2978.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -62,7 +62,7 @@ struct ltc2978_data {
int temp_min, temp_max;
int vout_min[8], vout_max[8];
int iout_max[2];
- int temp2_max[2];
+ int temp2_max;
struct pmbus_driver_info info;
};
@@ -204,10 +204,9 @@ static int ltc3880_read_word_data(struct
ret = pmbus_read_word_data(client, page,
LTC3880_MFR_TEMPERATURE2_PEAK);
if (ret >= 0) {
- if (lin11_to_val(ret)
- > lin11_to_val(data->temp2_max[page]))
- data->temp2_max[page] = ret;
- ret = data->temp2_max[page];
+ if (lin11_to_val(ret) > lin11_to_val(data->temp2_max))
+ data->temp2_max = ret;
+ ret = data->temp2_max;
}
break;
case PMBUS_VIRT_READ_VIN_MIN:
@@ -248,11 +247,11 @@ static int ltc2978_write_word_data(struc
switch (reg) {
case PMBUS_VIRT_RESET_IOUT_HISTORY:
- data->iout_max[page] = 0x7fff;
+ data->iout_max[page] = 0x7c00;
ret = ltc2978_clear_peaks(client, page, data->id);
break;
case PMBUS_VIRT_RESET_TEMP2_HISTORY:
- data->temp2_max[page] = 0x7fff;
+ data->temp2_max = 0x7c00;
ret = ltc2978_clear_peaks(client, page, data->id);
break;
case PMBUS_VIRT_RESET_VOUT_HISTORY:
@@ -262,12 +261,12 @@ static int ltc2978_write_word_data(struc
break;
case PMBUS_VIRT_RESET_VIN_HISTORY:
data->vin_min = 0x7bff;
- data->vin_max = 0;
+ data->vin_max = 0x7c00;
ret = ltc2978_clear_peaks(client, page, data->id);
break;
case PMBUS_VIRT_RESET_TEMP_HISTORY:
data->temp_min = 0x7bff;
- data->temp_max = 0x7fff;
+ data->temp_max = 0x7c00;
ret = ltc2978_clear_peaks(client, page, data->id);
break;
default:
@@ -321,10 +320,11 @@ static int ltc2978_probe(struct i2c_clie
info = &data->info;
info->write_word_data = ltc2978_write_word_data;
- data->vout_min[0] = 0xffff;
data->vin_min = 0x7bff;
+ data->vin_max = 0x7c00;
data->temp_min = 0x7bff;
- data->temp_max = 0x7fff;
+ data->temp_max = 0x7c00;
+ data->temp2_max = 0x7c00;
switch (id->driver_data) {
case ltc2978:
@@ -336,7 +336,6 @@ static int ltc2978_probe(struct i2c_clie
for (i = 1; i < 8; i++) {
info->func[i] = PMBUS_HAVE_VOUT
| PMBUS_HAVE_STATUS_VOUT;
- data->vout_min[i] = 0xffff;
}
break;
case ltc3880:
@@ -352,11 +351,14 @@ static int ltc2978_probe(struct i2c_clie
| PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT
| PMBUS_HAVE_POUT
| PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
- data->vout_min[1] = 0xffff;
+ data->iout_max[0] = 0x7c00;
+ data->iout_max[1] = 0x7c00;
break;
default:
return -ENODEV;
}
+ for (i = 0; i < info->pages; i++)
+ data->vout_min[i] = 0xffff;
return pmbus_do_probe(client, id, info);
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
commit ce2ac52105aa663056dfc17966ebed1bf93e6e64 upstream.
Kjell Braden reported this oops:
[ 833.211970] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 833.212816] IP: [< (null)>] (null)
[ 833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0
[ 833.213874] Oops: 0010 [#1] SMP
[ 833.214344] CPU 0
[ 833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000
[ 833.215629]
[ 833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox
[ 833.215629] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
[ 833.215629] RSP: 0018:ffff8800119c9c50 EFLAGS: 00010282
[ 833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000
[ 833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8
[ 833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7
[ 833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8
[ 833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6
[ 833.215629] FS: 00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
[ 833.215629] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0
[ 833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0)
[ 833.215629] Stack:
[ 833.215629] ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286
[ 833.215629] 0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8
[ 833.215629] ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0
[ 833.215629] Call Trace:
[ 833.215629] [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90
[ 833.215629] [<ffffffff81178075>] ? d_lookup+0x35/0x60
[ 833.215629] [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0
[ 833.215629] [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0
[ 833.215629] [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20
[ 833.215629] [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs]
[ 833.215629] [<ffffffff81163bd3>] mount_fs+0x43/0x1b0
[ 833.215629] [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0
[ 833.215629] [<ffffffff8117e584>] do_kern_mount+0x54/0x110
[ 833.215629] [<ffffffff8117fdc2>] do_mount+0x262/0x840
[ 833.215629] [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50
[ 833.215629] [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180
[ 833.215629] [<ffffffff8118075d>] sys_mount+0x8d/0xe0
[ 833.215629] [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b
[ 833.215629] Code: Bad RIP value.
[ 833.215629] RIP [< (null)>] (null)
[ 833.215629] RSP <ffff8800119c9c50>
[ 833.215629] CR2: 0000000000000000
[ 833.238525] ---[ end trace ec00758b8d44f529 ]---
When walking down the path on the server, it's possible to hit a
symlink. The path walking code assumes that the caller will handle that
situation properly, but cifs_get_root() isn't set up for it. This patch
prevents the oops by simply returning an error.
A better solution would be to try and chase the symlinks here, but that's
fairly complicated to handle.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=53221
Reported-and-tested-by: Kjell Braden <[email protected]>
Signed-off-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/cifs/cifsfs.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -557,6 +557,11 @@ cifs_get_root(struct smb_vol *vol, struc
dentry = ERR_PTR(-ENOENT);
break;
}
+ if (!S_ISDIR(dir->i_mode)) {
+ dput(dentry);
+ dentry = ERR_PTR(-ENOTDIR);
+ break;
+ }
/* skip separators */
while (*s == sep)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit 3e78080f81481aa8340374d5a37ae033c1cf4272 upstream.
Not having power is a pretty serious error so check that we are able to
enable the supply and error out if we can't.
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
---
drivers/hwmon/sht15.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/hwmon/sht15.c
+++ b/drivers/hwmon/sht15.c
@@ -926,7 +926,13 @@ static int __devinit sht15_probe(struct
if (voltage)
data->supply_uV = voltage;
- regulator_enable(data->reg);
+ ret = regulator_enable(data->reg);
+ if (ret != 0) {
+ dev_err(&pdev->dev,
+ "failed to enable regulator: %d\n", ret);
+ return ret;
+ }
+
/*
* Setup a notifier block to update this if another device
* causes the voltage to change
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit 58ebb34c49fcfcaa029e4b1c1453d92583900f9a upstream.
Create_stripe_zones returns an error slightly differently to
raid0_run and to raid0_takeover_*.
The error returned used by the second was wrong and an error would
result in mddev->private being set to NULL and sooner or later a
crash.
So never return NULL, return ERR_PTR(err), not NULL from
create_stripe_zones.
This bug has been present since 2.6.35 so the fix is suitable
for any kernel since then.
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -280,7 +280,7 @@ abort:
kfree(conf->strip_zone);
kfree(conf->devlist);
kfree(conf);
- *private_conf = NULL;
+ *private_conf = ERR_PTR(err);
return err;
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit a64685399181780998281fe07309a94b25dd24c3 upstream.
You cannot resize a RAID0 array (in terms of making the devices
bigger), but the code doesn't entirely stop you.
So:
disable setting of the available size on each device for
RAID0 and Linear devices. This must not change as doing so
can change the effective layout of data.
Make sure that the size that raid0_size() reports is accurate,
but rounding devices sizes to chunk sizes. As the device sizes
cannot change now, this isn't so important, but it is best to be
safe.
Without this change:
mdadm --grow /dev/md0 -z max
mdadm --grow /dev/md0 -Z max
then read to the end of the array
can cause a BUG in a RAID0 array.
These bugs have been present ever since it became possible
to resize any device, which is a long time. So the fix is
suitable for any -stable kerenl.
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/md.c | 3 +++
drivers/md/raid0.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -2886,6 +2886,9 @@ rdev_size_store(struct md_rdev *rdev, co
} else if (!sectors)
sectors = (i_size_read(rdev->bdev->bd_inode) >> 9) -
rdev->data_offset;
+ if (!my_mddev->pers->resize)
+ /* Cannot change size for RAID0 or Linear etc */
+ return -EINVAL;
}
if (sectors < my_mddev->dev_sectors)
return -EINVAL; /* component must fit device */
--- a/drivers/md/raid0.c
+++ b/drivers/md/raid0.c
@@ -402,7 +402,8 @@ static sector_t raid0_size(struct mddev
"%s does not support generic reshape\n", __func__);
rdev_for_each(rdev, mddev)
- array_sectors += rdev->sectors;
+ array_sectors += (rdev->sectors &
+ ~(sector_t)(mddev->chunk_sectors-1));
return array_sectors;
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit 5a7a613a47a715711b3f2d3322a0eac21d459166 upstream.
Commit 73ca100 broke the code that prevents the client from deleting
a silly renamed dentry. This affected "delete on last close"
semantics as after that commit, nothing prevented removal of
silly-renamed files. As a result, a process holding a file open
could easily get an ESTALE on the file in a directory where some
other process issued 'rm -rf some_dir_containing_the_file' twice.
Before the commit, any attempt at unlinking silly renamed files would
fail inside may_delete() with -EBUSY because of the
DCACHE_NFSFS_RENAMED flag. The following testcase demonstrates
the problem:
tail -f /nfsmnt/dir/file &
rm -rf /nfsmnt/dir
rm -rf /nfsmnt/dir
# second removal does not fail, 'tail' process receives ESTALE
The problem with the above commit is that it unhashes the old and
new dentries from the lookup path, even in the normal case when
a signal is not encountered and it would have been safe to call
d_move. Unfortunately the old dentry has the special
DCACHE_NFSFS_RENAMED flag set on it. Unhashing has the
side-effect that future lookups call d_alloc(), allocating a new
dentry without the special flag for any silly-renamed files. As a
result, subsequent calls to unlink silly renamed files do not fail
but allow the removal to go through. This will result in ESTALE
errors for any other process doing operations on the file.
To fix this, go back to using d_move on success.
For the signal case, it's unclear what we may safely do beyond d_drop.
Reported-by: Dave Wysochanski <[email protected]>
Signed-off-by: Trond Myklebust <[email protected]>
Acked-by: Jeff Layton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/nfs/unlink.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -336,20 +336,14 @@ static void nfs_async_rename_done(struct
struct inode *old_dir = data->old_dir;
struct inode *new_dir = data->new_dir;
struct dentry *old_dentry = data->old_dentry;
- struct dentry *new_dentry = data->new_dentry;
if (!NFS_PROTO(old_dir)->rename_done(task, old_dir, new_dir)) {
rpc_restart_call_prepare(task);
return;
}
- if (task->tk_status != 0) {
+ if (task->tk_status != 0)
nfs_cancel_async_unlink(old_dentry);
- return;
- }
-
- d_drop(old_dentry);
- d_drop(new_dentry);
}
/**
@@ -550,6 +544,18 @@ nfs_sillyrename(struct inode *dir, struc
error = rpc_wait_for_completion_task(task);
if (error == 0)
error = task->tk_status;
+ switch (error) {
+ case 0:
+ /* The rename succeeded */
+ nfs_set_verifier(dentry, nfs_save_change_attribute(dir));
+ d_move(dentry, sdentry);
+ break;
+ case -ERESTARTSYS:
+ /* The result of the rename is unknown. Play it safe by
+ * forcing a new lookup */
+ d_drop(dentry);
+ d_drop(sdentry);
+ }
rpc_put_task(task);
out_dput:
dput(sdentry);
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Riemer <[email protected]>
commit bbfa57c0f2243a7c31fd248d22e9861a2802cad5 upstream.
If an fsync occurs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.
By advice of Christoph Hellwig we return success upon a flush
request but we return -EROFS for other writes.
We detect flush requests by checking if the bio has zero sectors.
This patch is suitable to any -stable kernel to which it applies.
Signed-off-by: Sebastian Riemer <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Ben Hutchings <[email protected]>
Cc: NeilBrown <[email protected]>
Reported-by: Ben Hutchings <[email protected]>
Acked-by: Paul Menzel <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/md.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -344,6 +344,10 @@ static void md_make_request(struct reque
bio_io_error(bio);
return;
}
+ if (mddev->ro == 1 && unlikely(rw == WRITE)) {
+ bio_endio(bio, bio_sectors(bio) == 0 ? 0 : -EROFS);
+ return;
+ }
smp_rmb(); /* Ensure implications of 'active' are visible */
rcu_read_lock();
if (mddev->suspended) {
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Avinash Patil <[email protected]>
commit 3e7a4ff7c5b6423ddb644df9c41b8b6d2fb79d30 upstream.
Maximum delay for waking up card is 50 ms. Because of typo in
counter, this delay goes to 500ms. This patch fixes the bug.
Signed-off-by: Avinash Patil <[email protected]>
Signed-off-by: Amitkumar Karwar <[email protected]>
Signed-off-by: Yogesh Ashok Powar <[email protected]>
Signed-off-by: Bing Zhao <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/mwifiex/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -288,7 +288,7 @@ static int mwifiex_pm_wakeup_card(struct
i++;
usleep_range(10, 20);
/* 50ms max wait */
- if (i == 50000)
+ if (i == 5000)
break;
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
commit a9a6b52ee1baa865283a91eb8d443ee91adfca56 upstream.
If the socket is full, we're better off just waiting until it empties,
or until the connection is broken. The reason why we generally don't
want to time out is that the call to xprt->ops->release_xprt() will
trigger a connection reset, which isn't helpful...
Let's make an exception for soft RPC calls, since they have to provide
timeout guarantees.
Signed-off-by: Trond Myklebust <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sunrpc/xprt.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -485,13 +485,17 @@ EXPORT_SYMBOL_GPL(xprt_wake_pending_task
* xprt_wait_for_buffer_space - wait for transport output buffer to clear
* @task: task to be put to sleep
* @action: function pointer to be executed after wait
+ *
+ * Note that we only set the timer for the case of RPC_IS_SOFT(), since
+ * we don't in general want to force a socket disconnection due to
+ * an incomplete RPC call transmission.
*/
void xprt_wait_for_buffer_space(struct rpc_task *task, rpc_action action)
{
struct rpc_rqst *req = task->tk_rqstp;
struct rpc_xprt *xprt = req->rq_xprt;
- task->tk_timeout = req->rq_timeout;
+ task->tk_timeout = RPC_IS_SOFT(task) ? req->rq_timeout : 0;
rpc_sleep_on(&xprt->pending, task, action);
}
EXPORT_SYMBOL_GPL(xprt_wait_for_buffer_space);
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 208afec4f3be8c51ad6eebe6611dd6d2ad2fa298 upstream.
This bug was introduced back in bitkeeper days in 2003. We use
"dcb->dev_mode" before it has been initialized.
Signed-off-by: Dan Carpenter <[email protected]>
Acked-by: Oliver Neukum <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/dc395x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -3747,13 +3747,13 @@ static struct DeviceCtlBlk *device_alloc
dcb->max_command = 1;
dcb->target_id = target;
dcb->target_lun = lun;
+ dcb->dev_mode = eeprom->target[target].cfg0;
#ifndef DC395x_NO_DISCONNECT
dcb->identify_msg =
IDENTIFY(dcb->dev_mode & NTC_DO_DISCONNECT, lun);
#else
dcb->identify_msg = IDENTIFY(0, lun);
#endif
- dcb->dev_mode = eeprom->target[target].cfg0;
dcb->inquiry7 = 0;
dcb->sync_mode = 0;
dcb->min_nego_period = clock_period[period_index];
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olaf Hering <[email protected]>
commit d9904344fc4052fbe7e4dc137eba0dcdadf326bd upstream.
An earlier commit cd006086fa5d91414d8ff9ff2b78fbb593878e3c ("ata_piix:
defer disks to the Hyper-V drivers by default") broke MS Virtual PC
guests. Hyper-V guests and Virtual PC guests have nearly identical DMI
info. As a result the driver does currently ignore the emulated hardware
in Virtual PC guests and defers the handling to hv_blkvsc. Since Virtual
PC does not offer paravirtualized drivers no disks will be found in the
guest.
One difference in the DMI info is the product version. This patch adds a
match for MS Virtual PC 2007 and "unignores" the emulated hardware.
This was reported for openSuSE 12.1 in bugzilla:
https://bugzilla.novell.com/show_bug.cgi?id=737532
Here is a detailed list of DMI info from example guests:
hwinfo --bios:
virtual pc guest:
System Info: #1
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "VS2005R2"
Serial: "3178-9905-1533-4840-9282-0569-59"
UUID: undefined, but settable
Wake-up: 0x06 (Power Switch)
Board Info: #2
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "5.0"
Serial: "3178-9905-1533-4840-9282-0569-59"
Chassis Info: #3
Manufacturer: "Microsoft Corporation"
Version: "5.0"
Serial: "3178-9905-1533-4840-9282-0569-59"
Asset Tag: "7188-3705-6309-9738-9645-0364-00"
Type: 0x03 (Desktop)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x01 (Other)
Security Status: 0x01 (Other)
win2k8 guest:
System Info: #1
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "9106-3420-9819-5495-1514-2075-48"
UUID: undefined, but settable
Wake-up: 0x06 (Power Switch)
Board Info: #2
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "9106-3420-9819-5495-1514-2075-48"
Chassis Info: #3
Manufacturer: "Microsoft Corporation"
Version: "7.0"
Serial: "9106-3420-9819-5495-1514-2075-48"
Asset Tag: "7076-9522-6699-1042-9501-1785-77"
Type: 0x03 (Desktop)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x01 (Other)
Security Status: 0x01 (Other)
win2k12 guest:
System Info: #1
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "8179-1954-0187-0085-3868-2270-14"
UUID: undefined, but settable
Wake-up: 0x06 (Power Switch)
Board Info: #2
Manufacturer: "Microsoft Corporation"
Product: "Virtual Machine"
Version: "7.0"
Serial: "8179-1954-0187-0085-3868-2270-14"
Chassis Info: #3
Manufacturer: "Microsoft Corporation"
Version: "7.0"
Serial: "8179-1954-0187-0085-3868-2270-14"
Asset Tag: "8374-0485-4557-6331-0620-5845-25"
Type: 0x03 (Desktop)
Bootup State: 0x03 (Safe)
Power Supply State: 0x03 (Safe)
Thermal State: 0x01 (Other)
Security Status: 0x01 (Other)
Signed-off-by: Olaf Hering <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/ata/ata_piix.c | 25 ++++++++++++++++++++++---
1 file changed, 22 insertions(+), 3 deletions(-)
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1594,12 +1594,31 @@ static void piix_ignore_devices_quirk(st
},
{ } /* terminate list */
};
- const struct dmi_system_id *dmi = dmi_first_match(ignore_hyperv);
+ static const struct dmi_system_id allow_virtual_pc[] = {
+ {
+ /* In MS Virtual PC guests the DMI ident is nearly
+ * identical to a Hyper-V guest. One difference is the
+ * product version which is used here to identify
+ * a Virtual PC guest. This entry allows ata_piix to
+ * drive the emulated hardware.
+ */
+ .ident = "MS Virtual PC 2007",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR,
+ "Microsoft Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "VS2005R2"),
+ },
+ },
+ { } /* terminate list */
+ };
+ const struct dmi_system_id *ignore = dmi_first_match(ignore_hyperv);
+ const struct dmi_system_id *allow = dmi_first_match(allow_virtual_pc);
- if (dmi && prefer_ms_hyperv) {
+ if (ignore && !allow && prefer_ms_hyperv) {
host->flags |= ATA_HOST_IGNORE_ATA;
dev_info(host->dev, "%s detected, ATA device ignore set\n",
- dmi->ident);
+ ignore->ident);
}
#endif
}
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rusty Russell <[email protected]>
commit f7f154f1246ccc5a0a7e9ce50932627d60a0c878 upstream.
virtio_rng feeds the randomness buffer handed by the core directly
into the scatterlist, since commit bb347d98079a547e80bd4722dee1de61e4dca0e8.
However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
(at least on most archs). We could fix this in virtio_rng, but it's actually
far easier to just do it in the core as virtio_rng would have to allocate
a buffer every time (it doesn't know how much the core will want to read).
Reported-by: Aurelien Jarno <[email protected]>
Tested-by: Aurelien Jarno <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/hw_random/core.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -40,6 +40,7 @@
#include <linux/init.h>
#include <linux/miscdevice.h>
#include <linux/delay.h>
+#include <linux/slab.h>
#include <asm/uaccess.h>
@@ -52,8 +53,12 @@ static struct hwrng *current_rng;
static LIST_HEAD(rng_list);
static DEFINE_MUTEX(rng_mutex);
static int data_avail;
-static u8 rng_buffer[SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES]
- __cacheline_aligned;
+static u8 *rng_buffer;
+
+static size_t rng_buffer_size(void)
+{
+ return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES;
+}
static inline int hwrng_init(struct hwrng *rng)
{
@@ -116,7 +121,7 @@ static ssize_t rng_dev_read(struct file
if (!data_avail) {
bytes_read = rng_get_data(current_rng, rng_buffer,
- sizeof(rng_buffer),
+ rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
if (bytes_read < 0) {
err = bytes_read;
@@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
mutex_lock(&rng_mutex);
+ /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
+ err = -ENOMEM;
+ if (!rng_buffer) {
+ rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
+ if (!rng_buffer)
+ goto out_unlock;
+ }
+
/* Must not register two RNGs with the same name. */
err = -EEXIST;
list_for_each_entry(tmp, &rng_list, list) {
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 1cba0cdf5e4dbcd9e5fa5b54d7a028e55e2ca057 upstream.
__btrfs_close_devices() clones btrfs device structs with
memcpy(). Some of the fields in the clone are reinitialized, but it's
missing to init io_lock. In mainline this goes unnoticed, but on RT it
leaves the plist pointing to the original about to be freed lock
struct.
Initialize io_lock after cloning, so no references to the original
struct are left.
Reported-and-tested-by: Mike Galbraith <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -557,6 +557,7 @@ static int __btrfs_close_devices(struct
new_device->writeable = 0;
new_device->in_fs_metadata = 0;
new_device->can_discard = 0;
+ spin_lock_init(&new_device->io_lock);
list_replace_rcu(&device->dev_list, &new_device->dev_list);
call_rcu(&device->rcu, free_device);
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Asias He <[email protected]>
commit 472b72f2db7831d7dbe22ffdff4adee3bd49b05d upstream.
The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page
address if the 'while (len > 0 && data_len > 0) { ... }' loop is
executed more than one once.
Signed-off-by: Asias He <[email protected]>
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/target_core_pscsi.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1042,7 +1042,6 @@ static int pscsi_map_sg(struct se_task *
bio = NULL;
}
- page++;
len -= bytes;
data_len -= bytes;
off = 0;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "K. Y. Srinivasan" <[email protected]>
commit 9d2696e658ef4f209955ddaa987d43f1a1bd81a1 upstream.
Properly initialize scatterlist before using it.
Signed-off-by: K. Y. Srinivasan <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/storvsc_drv.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -467,6 +467,7 @@ static struct scatterlist *create_bounce
if (!bounce_sgl)
return NULL;
+ sg_init_table(bounce_sgl, num_pages);
for (i = 0; i < num_pages; i++) {
page_buf = alloc_page(GFP_ATOMIC);
if (!page_buf)
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Rzeszutek Wilk <[email protected]>
commit 884ac2978a295b7df3c4a686d3bff6932bbbb460 upstream.
There is no hypercall to setup multiple MSI per PCI device.
As such with these two new commits:
- 08261d87f7d1b6253ab3223756625a5c74532293
PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto()
- 5ca72c4f7c412c2002363218901eba5516c476b1
AHCI: Support multiple MSIs
we would call the PHYSDEVOP_map_pirq 'nvec' times with the same
contents of the PCI device. Sander discovered that we would get
the same PIRQ value 'nvec' times and return said values to the
caller. That of course meant that the device was configured only
with one MSI and AHCI would fail with:
ahci 0000:00:11.0: version 3.0
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
(XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
ahci: probe of 0000:00:11.0 failed with error -22
That is b/c in ahci_host_activate the second call to
devm_request_threaded_irq would return -EINVAL as we passed in
(on the second run) an IRQ that was never initialized.
Reported-and-Tested-by: Sander Eikelenboom <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/pci/xen.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -162,6 +162,9 @@ static int xen_setup_msi_irqs(struct pci
struct msi_desc *msidesc;
int *v;
+ if (type == PCI_CAP_ID_MSI && nvec > 1)
+ return 1;
+
v = kzalloc(sizeof(int) * max(1, nvec), GFP_KERNEL);
if (!v)
return -ENOMEM;
@@ -220,6 +223,9 @@ static int xen_hvm_setup_msi_irqs(struct
struct msi_desc *msidesc;
struct msi_msg msg;
+ if (type == PCI_CAP_ID_MSI && nvec > 1)
+ return 1;
+
list_for_each_entry(msidesc, &dev->msi_list, list) {
__read_msi_msg(msidesc, &msg);
pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
@@ -263,6 +269,9 @@ static int xen_initdom_setup_msi_irqs(st
int ret = 0;
struct msi_desc *msidesc;
+ if (type == PCI_CAP_ID_MSI && nvec > 1)
+ return 1;
+
list_for_each_entry(msidesc, &dev->msi_list, list) {
struct physdev_map_pirq map_irq;
domid_t domid;
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
commit b255188f90e2bade1bd11a986dd1ca4861869f4d upstream.
Paolo Pisati reports that IPv6 triggers this warning:
BUG: scheduling while atomic: swapper/0/0/0x40000100
Modules linked in:
[<c001b1c4>] (unwind_backtrace+0x0/0xf0) from [<c0503c5c>] (__schedule_bug+0x48/0x5c)
[<c0503c5c>] (__schedule_bug+0x48/0x5c) from [<c0508608>] (__schedule+0x700/0x740)
[<c0508608>] (__schedule+0x700/0x740) from [<c007007c>] (__cond_resched+0x24/0x34)
[<c007007c>] (__cond_resched+0x24/0x34) from [<c05086dc>] (_cond_resched+0x3c/0x44)
[<c05086dc>] (_cond_resched+0x3c/0x44) from [<c0021f6c>] (do_alignment+0x178/0x78c)
[<c0021f6c>] (do_alignment+0x178/0x78c) from [<c00083e0>] (do_DataAbort+0x34/0x98)
[<c00083e0>] (do_DataAbort+0x34/0x98) from [<c0509a60>] (__dabt_svc+0x40/0x60)
Exception stack(0xc0763d70 to 0xc0763db8)
3d60: e97e805e e97e806e 2c000000 11000000
3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c
3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff
[<c0509a60>] (__dabt_svc+0x40/0x60) from [<c02a8490>] (__csum_ipv6_magic+0x8/0xc8)
Fix this by using probe_kernel_address() stead of __get_user().
Reported-by: Paolo Pisati <[email protected]>
Tested-by: Paolo Pisati <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/mm/alignment.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -750,7 +750,6 @@ do_alignment(unsigned long addr, unsigne
unsigned long instr = 0, instrptr;
int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs *regs);
unsigned int type;
- mm_segment_t fs;
unsigned int fault;
u16 tinstr = 0;
int isize = 4;
@@ -761,16 +760,15 @@ do_alignment(unsigned long addr, unsigne
instrptr = instruction_pointer(regs);
- fs = get_fs();
- set_fs(KERNEL_DS);
if (thumb_mode(regs)) {
- fault = __get_user(tinstr, (u16 *)(instrptr & ~1));
+ u16 *ptr = (u16 *)(instrptr & ~1);
+ fault = probe_kernel_address(ptr, tinstr);
if (!fault) {
if (cpu_architecture() >= CPU_ARCH_ARMv7 &&
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = __get_user(tinst2, (u16 *)(instrptr+2));
+ fault = probe_kernel_address(ptr + 1, tinst2);
instr = (tinstr << 16) | tinst2;
thumb2_32b = 1;
} else {
@@ -779,8 +777,7 @@ do_alignment(unsigned long addr, unsigne
}
}
} else
- fault = __get_user(instr, (u32 *)instrptr);
- set_fs(fs);
+ fault = probe_kernel_address(instrptr, instr);
if (fault) {
type = TYPE_FAULT;
Greg,
On Tue, Mar 12, 2013 at 03:43:54PM -0700, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Andrew Lunn <[email protected]>
>
> commit 89c58c198b252f2bc20657fdd72a2aea788c435c upstream.
>
> The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the
> driver clk_prepare_enable() this clock, otherwise there is a danger
> the SoC will lockup when accessing RTC registers with the clock
> disabled.
>
> Reported-by: Simon Baatz <[email protected]>
> Signed-off-by: Andrew Lunn <[email protected]>
> Tested-by: Simon Baatz <[email protected]>
> Signed-off-by: Jason Cooper <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> arch/arm/boot/dts/kirkwood.dtsi | 1 +
> drivers/rtc/rtc-mv.c | 28 ++++++++++++++++++++++++----
> 2 files changed, 25 insertions(+), 4 deletions(-)
Please drop from 3.4-stable. devm_clk_get() wasn't available.
thx,
Jason.
>
> --- a/arch/arm/boot/dts/kirkwood.dtsi
> +++ b/arch/arm/boot/dts/kirkwood.dtsi
> @@ -31,6 +31,7 @@
> compatible = "mrvl,kirkwood-rtc", "mrvl,orion-rtc";
> reg = <0x10300 0x20>;
> interrupts = <53>;
> + clocks = <&gate_clk 7>;
> };
> };
> };
> --- a/drivers/rtc/rtc-mv.c
> +++ b/drivers/rtc/rtc-mv.c
> @@ -14,6 +14,7 @@
> #include <linux/platform_device.h>
> #include <linux/of.h>
> #include <linux/delay.h>
> +#include <linux/clk.h>
> #include <linux/gfp.h>
> #include <linux/module.h>
>
> @@ -41,6 +42,7 @@ struct rtc_plat_data {
> struct rtc_device *rtc;
> void __iomem *ioaddr;
> int irq;
> + struct clk *clk;
> };
>
> static int mv_rtc_set_time(struct device *dev, struct rtc_time *tm)
> @@ -221,6 +223,7 @@ static int __devinit mv_rtc_probe(struct
> struct rtc_plat_data *pdata;
> resource_size_t size;
> u32 rtc_time;
> + int ret = 0;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res)
> @@ -239,11 +242,17 @@ static int __devinit mv_rtc_probe(struct
> if (!pdata->ioaddr)
> return -ENOMEM;
>
> + pdata->clk = devm_clk_get(&pdev->dev, NULL);
> + /* Not all SoCs require a clock.*/
> + if (!IS_ERR(pdata->clk))
> + clk_prepare_enable(pdata->clk);
> +
> /* make sure the 24 hours mode is enabled */
> rtc_time = readl(pdata->ioaddr + RTC_TIME_REG_OFFS);
> if (rtc_time & RTC_HOURS_12H_MODE) {
> dev_err(&pdev->dev, "24 Hours mode not supported.\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto out;
> }
>
> /* make sure it is actually functional */
> @@ -252,7 +261,8 @@ static int __devinit mv_rtc_probe(struct
> rtc_time = readl(pdata->ioaddr + RTC_TIME_REG_OFFS);
> if (rtc_time == 0x01000000) {
> dev_err(&pdev->dev, "internal RTC not ticking\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto out;
> }
> }
>
> @@ -268,8 +278,10 @@ static int __devinit mv_rtc_probe(struct
> } else
> pdata->rtc = rtc_device_register(pdev->name, &pdev->dev,
> &mv_rtc_ops, THIS_MODULE);
> - if (IS_ERR(pdata->rtc))
> - return PTR_ERR(pdata->rtc);
> + if (IS_ERR(pdata->rtc)) {
> + ret = PTR_ERR(pdata->rtc);
> + goto out;
> + }
>
> if (pdata->irq >= 0) {
> writel(0, pdata->ioaddr + RTC_ALARM_INTERRUPT_MASK_REG_OFFS);
> @@ -282,6 +294,11 @@ static int __devinit mv_rtc_probe(struct
> }
>
> return 0;
> +out:
> + if (!IS_ERR(pdata->clk))
> + clk_disable_unprepare(pdata->clk);
> +
> + return ret;
> }
>
> static int __exit mv_rtc_remove(struct platform_device *pdev)
> @@ -292,6 +309,9 @@ static int __exit mv_rtc_remove(struct p
> device_init_wakeup(&pdev->dev, 0);
>
> rtc_device_unregister(pdata->rtc);
> + if (!IS_ERR(pdata->clk))
> + clk_disable_unprepare(pdata->clk);
> +
> return 0;
> }
>
>
>
On Tue, Mar 12, 2013 at 07:08:43PM -0400, Jason Cooper wrote:
> Greg,
>
> On Tue, Mar 12, 2013 at 03:43:54PM -0700, Greg Kroah-Hartman wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Andrew Lunn <[email protected]>
> >
> > commit 89c58c198b252f2bc20657fdd72a2aea788c435c upstream.
> >
> > The Marvell RTC on Kirkwood makes use of the runit clock. Ensure the
> > driver clk_prepare_enable() this clock, otherwise there is a danger
> > the SoC will lockup when accessing RTC registers with the clock
> > disabled.
> >
> > Reported-by: Simon Baatz <[email protected]>
> > Signed-off-by: Andrew Lunn <[email protected]>
> > Tested-by: Simon Baatz <[email protected]>
> > Signed-off-by: Jason Cooper <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > ---
> > arch/arm/boot/dts/kirkwood.dtsi | 1 +
> > drivers/rtc/rtc-mv.c | 28 ++++++++++++++++++++++++----
> > 2 files changed, 25 insertions(+), 4 deletions(-)
>
> Please drop from 3.4-stable. devm_clk_get() wasn't available.
Now dropped.
On Tue, Mar 12, 2013 at 4:43 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> This is the start of the stable review cycle for the 3.4.36 release.
> There are 40 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 14 22:31:37 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.36-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Patches applied cleanly to 3.0.68, 3.4.35, and 3.8.2
Compiled and booted on the following systems:
HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.
Cross-compile tests results:
alpha: defconfig passed on all
arm: defconfig passed on all
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.8.y
c6x: not applicable to 3.0.y, defconfig passed on 3.4.y, and 3.8.y.
mips: defconfig passed on all
mipsel: defconfig passed on all
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
-- Shuah
Hi Rusty,
At Tue, 12 Mar 2013 15:43:33 -0700,
Greg Kroah-Hartman wrote:
>
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Rusty Russell <[email protected]>
>
> commit f7f154f1246ccc5a0a7e9ce50932627d60a0c878 upstream.
>
> virtio_rng feeds the randomness buffer handed by the core directly
> into the scatterlist, since commit bb347d98079a547e80bd4722dee1de61e4dca0e8.
>
> However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
> (at least on most archs). We could fix this in virtio_rng, but it's actually
> far easier to just do it in the core as virtio_rng would have to allocate
> a buffer every time (it doesn't know how much the core will want to read).
>
> Reported-by: Aurelien Jarno <[email protected]>
> Tested-by: Aurelien Jarno <[email protected]>
> Signed-off-by: Rusty Russell <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/char/hw_random/core.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -40,6 +40,7 @@
> #include <linux/init.h>
> #include <linux/miscdevice.h>
> #include <linux/delay.h>
> +#include <linux/slab.h>
> #include <asm/uaccess.h>
>
>
> @@ -52,8 +53,12 @@ static struct hwrng *current_rng;
> static LIST_HEAD(rng_list);
> static DEFINE_MUTEX(rng_mutex);
> static int data_avail;
> -static u8 rng_buffer[SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES]
> - __cacheline_aligned;
> +static u8 *rng_buffer;
> +
> +static size_t rng_buffer_size(void)
> +{
> + return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES;
> +}
>
> static inline int hwrng_init(struct hwrng *rng)
> {
> @@ -116,7 +121,7 @@ static ssize_t rng_dev_read(struct file
>
> if (!data_avail) {
> bytes_read = rng_get_data(current_rng, rng_buffer,
> - sizeof(rng_buffer),
> + rng_buffer_size(),
> !(filp->f_flags & O_NONBLOCK));
> if (bytes_read < 0) {
> err = bytes_read;
> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>
> mutex_lock(&rng_mutex);
>
> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> + err = -ENOMEM;
> + if (!rng_buffer) {
> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
at hwrng_unregister()? If my suspect is correct, the same problem is
in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
some hours.
Corecct me if I'm wrong.
Thanks,
Satoru
> + if (!rng_buffer)
> + goto out_unlock;
> + }
> +
> /* Must not register two RNGs with the same name. */
> err = -EEXIST;
> list_for_each_entry(tmp, &rng_list, list) {
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Satoru Takeuchi <[email protected]> writes:
> Hi Rusty,
>
> At Tue, 12 Mar 2013 15:43:33 -0700,
> Greg Kroah-Hartman wrote:
>> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>>
>> mutex_lock(&rng_mutex);
>>
>> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> + err = -ENOMEM;
>> + if (!rng_buffer) {
>> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
>
> rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
> at hwrng_unregister()? If my suspect is correct, the same problem is
> in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
> some hours.
>
> Corecct me if I'm wrong.
Yes, it would be nice to free it, but it really makes sense to free it
in module_cleanup() (which would have to be written, as the module
currently doesn't have one).
Cheers,
Rusty.
At Thu, 14 Mar 2013 17:11:21 +1030,
Rusty Russell wrote:
>
> Satoru Takeuchi <[email protected]> writes:
> > Hi Rusty,
> >
> > At Tue, 12 Mar 2013 15:43:33 -0700,
> > Greg Kroah-Hartman wrote:
> >> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
> >>
> >> mutex_lock(&rng_mutex);
> >>
> >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> >> + err = -ENOMEM;
> >> + if (!rng_buffer) {
> >> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
> >
> > rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
> > at hwrng_unregister()? If my suspect is correct, the same problem is
> > in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
> > some hours.
> >
> > Corecct me if I'm wrong.
>
> Yes, it would be nice to free it, but it really makes sense to free it
> in module_cleanup() (which would have to be written, as the module
> currently doesn't have one).
>
> Cheers,
> Rusty.
From: Satoru Takeuchi <[email protected]>
rng-core module allocates rng_buffer by kmalloc() since commit
f7f154f1246ccc5a0a7e9ce50932627d60a0c878. But this buffer won't be
freed and there is a memory leak possibility at module exit.
Signed-off-by: Satoru Takeuchi <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: Matt Mackall <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Aurelien Jarno <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
---
drivers/char/hw_random/core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 69ae597..a0f7724 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -380,6 +380,15 @@ void hwrng_unregister(struct hwrng *rng)
}
EXPORT_SYMBOL_GPL(hwrng_unregister);
+static void __exit hwrng_exit(void)
+{
+ mutex_lock(&rng_mutex);
+ BUG_ON(current_rng);
+ kfree(rng_buffer);
+ mutex_unlock(&rng_mutex);
+}
+
+module_exit(hwrng_exit);
MODULE_DESCRIPTION("H/W Random Number Generator (RNG) driver");
MODULE_LICENSE("GPL");
--
1.7.10.4
At Tue, 12 Mar 2013 15:43:21 -0700,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.36 release.
> There are 40 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 14 22:31:37 UTC 2013.
> Anything received after that time might be too late.
This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.
- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
I reviewed the following patches.
> Rusty Russell <[email protected]>
> hw_random: make buffer usable in scatterlist.
There is a memory leak possibility at unloding rng-core.ko as I replied
to this patch. However I consider it doesn't need to be dropped here since
this memory leak only happen with CONFIG_HW_RANDOM=m and unloading
rng-core.ko seldom happens.
> Steven Rostedt <[email protected]>
> ftrace: Update the kconfig for DYNAMIC_FTRACE
>
> Tu, Xiaobing <[email protected]>
> Fix memory leak in cpufreq stats.
...
> Al Viro <[email protected]>
> vfs: fix pipe counter breakage
Theese patches looks good to me.
Thanks,
Satoru
Satoru Takeuchi <[email protected]> writes:
> At Thu, 14 Mar 2013 17:11:21 +1030,
> Rusty Russell wrote:
>>
>> Satoru Takeuchi <[email protected]> writes:
>> > Hi Rusty,
>> >
>> > At Tue, 12 Mar 2013 15:43:33 -0700,
>> > Greg Kroah-Hartman wrote:
>> >> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>> >>
>> >> mutex_lock(&rng_mutex);
>> >>
>> >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> >> + err = -ENOMEM;
>> >> + if (!rng_buffer) {
>> >> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
>> >
>> > rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
>> > at hwrng_unregister()? If my suspect is correct, the same problem is
>> > in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
>> > some hours.
>> >
>> > Corecct me if I'm wrong.
>>
>> Yes, it would be nice to free it, but it really makes sense to free it
>> in module_cleanup() (which would have to be written, as the module
>> currently doesn't have one).
>>
>> Cheers,
>> Rusty.
>
> From: Satoru Takeuchi <[email protected]>
>
> rng-core module allocates rng_buffer by kmalloc() since commit
> f7f154f1246ccc5a0a7e9ce50932627d60a0c878. But this buffer won't be
> freed and there is a memory leak possibility at module exit.
>
> Signed-off-by: Satoru Takeuchi <[email protected]>
> Cc: Rusty Russell <[email protected]>
> Cc: Matt Mackall <[email protected]>
> Cc: Herbert Xu <[email protected]>
> Cc: Aurelien Jarno <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: [email protected]
Cc: stable might be overkill, but I've tested it and put it in my patch
queue, and will push it to Linus once it's survived linux-next.
Thanks,
Rusty.
On Fri, 2013-03-15 at 15:35 +1030, Rusty Russell wrote:
> Satoru Takeuchi <[email protected]> writes:
> > At Thu, 14 Mar 2013 17:11:21 +1030,
> > Rusty Russell wrote:
> >>
> >> Satoru Takeuchi <[email protected]> writes:
> >> > Hi Rusty,
> >> >
> >> > At Tue, 12 Mar 2013 15:43:33 -0700,
> >> > Greg Kroah-Hartman wrote:
> >> >> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
> >> >>
> >> >> mutex_lock(&rng_mutex);
> >> >>
> >> >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> >> >> + err = -ENOMEM;
> >> >> + if (!rng_buffer) {
> >> >> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
> >> >
> >> > rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
> >> > at hwrng_unregister()? If my suspect is correct, the same problem is
> >> > in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
> >> > some hours.
> >> >
> >> > Corecct me if I'm wrong.
> >>
> >> Yes, it would be nice to free it, but it really makes sense to free it
> >> in module_cleanup() (which would have to be written, as the module
> >> currently doesn't have one).
> >>
> >> Cheers,
> >> Rusty.
> >
> > From: Satoru Takeuchi <[email protected]>
> >
> > rng-core module allocates rng_buffer by kmalloc() since commit
> > f7f154f1246ccc5a0a7e9ce50932627d60a0c878. But this buffer won't be
> > freed and there is a memory leak possibility at module exit.
> >
> > Signed-off-by: Satoru Takeuchi <[email protected]>
> > Cc: Rusty Russell <[email protected]>
> > Cc: Matt Mackall <[email protected]>
> > Cc: Herbert Xu <[email protected]>
> > Cc: Aurelien Jarno <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: [email protected]
>
> Cc: stable might be overkill, but I've tested it and put it in my patch
> queue, and will push it to Linus once it's survived linux-next.
If the module cannot be removed currently, it does not leak. Making it
removable is a feature addition and I think you're right that it's not
suitable for stable.
Ben.
--
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
- Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
Ben Hutchings <[email protected]> writes:
> On Fri, 2013-03-15 at 15:35 +1030, Rusty Russell wrote:
>> Satoru Takeuchi <[email protected]> writes:
>> > At Thu, 14 Mar 2013 17:11:21 +1030,
>> > Rusty Russell wrote:
>> >>
>> >> Satoru Takeuchi <[email protected]> writes:
>> >> > Hi Rusty,
>> >> >
>> >> > At Tue, 12 Mar 2013 15:43:33 -0700,
>> >> > Greg Kroah-Hartman wrote:
>> >> >> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
>> >> >>
>> >> >> mutex_lock(&rng_mutex);
>> >> >>
>> >> >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
>> >> >> + err = -ENOMEM;
>> >> >> + if (!rng_buffer) {
>> >> >> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
>> >> >
>> >> > rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
>> >> > at hwrng_unregister()? If my suspect is correct, the same problem is
>> >> > in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
>> >> > some hours.
>> >> >
>> >> > Corecct me if I'm wrong.
>> >>
>> >> Yes, it would be nice to free it, but it really makes sense to free it
>> >> in module_cleanup() (which would have to be written, as the module
>> >> currently doesn't have one).
>> >>
>> >> Cheers,
>> >> Rusty.
>> >
>> > From: Satoru Takeuchi <[email protected]>
>> >
>> > rng-core module allocates rng_buffer by kmalloc() since commit
>> > f7f154f1246ccc5a0a7e9ce50932627d60a0c878. But this buffer won't be
>> > freed and there is a memory leak possibility at module exit.
>> >
>> > Signed-off-by: Satoru Takeuchi <[email protected]>
>> > Cc: Rusty Russell <[email protected]>
>> > Cc: Matt Mackall <[email protected]>
>> > Cc: Herbert Xu <[email protected]>
>> > Cc: Aurelien Jarno <[email protected]>
>> > Cc: Greg Kroah-Hartman <[email protected]>
>> > Cc: [email protected]
>>
>> Cc: stable might be overkill, but I've tested it and put it in my patch
>> queue, and will push it to Linus once it's survived linux-next.
>
> If the module cannot be removed currently, it does not leak. Making it
> removable is a feature addition and I think you're right that it's not
> suitable for stable.
No, the module has always been removable, but the tiny leak is more a
theoretical problem I'd say. AFAICT udev never removes modules, so even
if you have a randomness device which bounces in and out every second,
it still won't leak 5MB a day.
Cheers,
Rusty.
At Mon, 18 Mar 2013 13:10:29 +1030,
Rusty Russell wrote:
>
> Ben Hutchings <[email protected]> writes:
> > On Fri, 2013-03-15 at 15:35 +1030, Rusty Russell wrote:
> >> Satoru Takeuchi <[email protected]> writes:
> >> > At Thu, 14 Mar 2013 17:11:21 +1030,
> >> > Rusty Russell wrote:
> >> >>
> >> >> Satoru Takeuchi <[email protected]> writes:
> >> >> > Hi Rusty,
> >> >> >
> >> >> > At Tue, 12 Mar 2013 15:43:33 -0700,
> >> >> > Greg Kroah-Hartman wrote:
> >> >> >> @@ -307,6 +312,14 @@ int hwrng_register(struct hwrng *rng)
> >> >> >>
> >> >> >> mutex_lock(&rng_mutex);
> >> >> >>
> >> >> >> + /* kmalloc makes this safe for virt_to_page() in virtio_rng.c */
> >> >> >> + err = -ENOMEM;
> >> >> >> + if (!rng_buffer) {
> >> >> >> + rng_buffer = kmalloc(rng_buffer_size(), GFP_KERNEL);
> >> >> >
> >> >> > rng_buffer is now kmalloc-ed, but not kfree-ed. Shoudn't it be kfree-ed
> >> >> > at hwrng_unregister()? If my suspect is correct, the same problem is
> >> >> > in 3.8.3-rc1 and 3.0.69-rc1. I'm OK to make a patch, but it'll be after
> >> >> > some hours.
> >> >> >
> >> >> > Corecct me if I'm wrong.
> >> >>
> >> >> Yes, it would be nice to free it, but it really makes sense to free it
> >> >> in module_cleanup() (which would have to be written, as the module
> >> >> currently doesn't have one).
> >> >>
> >> >> Cheers,
> >> >> Rusty.
> >> >
> >> > From: Satoru Takeuchi <[email protected]>
> >> >
> >> > rng-core module allocates rng_buffer by kmalloc() since commit
> >> > f7f154f1246ccc5a0a7e9ce50932627d60a0c878. But this buffer won't be
> >> > freed and there is a memory leak possibility at module exit.
> >> >
> >> > Signed-off-by: Satoru Takeuchi <[email protected]>
> >> > Cc: Rusty Russell <[email protected]>
> >> > Cc: Matt Mackall <[email protected]>
> >> > Cc: Herbert Xu <[email protected]>
> >> > Cc: Aurelien Jarno <[email protected]>
> >> > Cc: Greg Kroah-Hartman <[email protected]>
> >> > Cc: [email protected]
> >>
> >> Cc: stable might be overkill, but I've tested it and put it in my patch
> >> queue, and will push it to Linus once it's survived linux-next.
> >
> > If the module cannot be removed currently, it does not leak. Making it
> > removable is a feature addition and I think you're right that it's not
> > suitable for stable.
>
> No, the module has always been removable, but the tiny leak is more a
> theoretical problem I'd say. AFAICT udev never removes modules, so even
> if you have a randomness device which bounces in and out every second,
> it still won't leak 5MB a day.
I changed my mind. This patch is not suitable for stable because of the
following reasons.
- Admins (or udev) don't nomally unload hw_random drivers.
- It's hard for attackers to abuse this bug. Triggering rng-core module
unload is difficult for non-root users.
- It leaks few memory (in my system 64byte per load/unload) as Rusty said.
Documentation/stable_kernel_rules.txt
===============================================================================
...
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, something
critical.
...
===============================================================================
It doesn't match the above-mentioned description. It's not critical.
Thanks,
Satoru