2015-06-03 11:46:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 00/46] 3.10.80-stable review

This is the start of the stable review cycle for the 3.10.80 release.
There are 46 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 Fri Jun 5 06:33:14 UTC 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.80-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 3.10.80-rc1

Andrew Morton <[email protected]>
fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

Sasha Levin <[email protected]>
vfs: read file_handle only once in handle_to_path

Rafael J. Wysocki <[email protected]>
ACPI / init: Fix the ordering of acpi_reserve_resources()

Benjamin Tissoires <[email protected]>
Input: elantech - fix semi-mt protocol for v3 HW

Larry Finger <[email protected]>
rtlwifi: rtl8192cu: Fix kernel deadlock

NeilBrown <[email protected]>
md/raid5: don't record new size if resize_stripes fails.

Scott Mayhew <[email protected]>
svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures

Russell King <[email protected]>
ARM: fix missing syscall trace exit

Philippe Reynes <[email protected]>
ARM: dts: imx27: only map 4 Kbyte for fec registers

Harald Freudenberger <[email protected]>
crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

Scott Branden <[email protected]>
rt2x00: add new rt2800usb device DWA 130

Gabriele Mazzotta <[email protected]>
libata: Ignore spurious PHY event on LPM policy change

Gabriele Mazzotta <[email protected]>
libata: Add helper to determine when PHY events should be ignored

Eryu Guan <[email protected]>
ext4: check for zero length extent explicitly

Dmitry Monakhov <[email protected]>
ext4: convert write_begin methods to stable_page_writes semantics

Ludovic Desroches <[email protected]>
mmc: atmel-mci: fix bad variable type for clkdiv

Anton Blanchard <[email protected]>
powerpc: Align TOC to 256 bytes

Krzysztof Opasiak <[email protected]>
usb: gadget: configfs: Fix interfaces array NULL-termination

Hans de Goede <[email protected]>
usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices

Mark Edwards <[email protected]>
USB: cp210x: add ID for KCF Technologies PRN device

Jason A. Donenfeld <[email protected]>
USB: pl2303: Remove support for Samsung I330

Jason A. Donenfeld <[email protected]>
USB: visor: Match I330 phone more precisely

Joe Lawrence <[email protected]>
xhci: gracefully handle xhci_irq dead device

Mathias Nyman <[email protected]>
xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256

Mathias Nyman <[email protected]>
xhci: fix isoc endpoint dequeue from advancing too far on transaction error

Andy Grover <[email protected]>
target/pscsi: Don't leak scsi_host if hba is VIRTUAL_HOST

Zidan Wang <[email protected]>
ASoC: wm8994: correct BCLK DIV 348 to 384

Zidan Wang <[email protected]>
ASoC: wm8960: fix "RINPUT3" audio route error

Vasily Khoruzhick <[email protected]>
ASoC: uda1380: Avoid accessing i2c bus when codec is disabled

Axel Lin <[email protected]>
ASoC: mc13783: Fix wrong mask value used in mc13xxx_reg_rmw() calls

Takashi Iwai <[email protected]>
ALSA: hda - Add headphone quirk for Lifebook E752

David Henningsson <[email protected]>
ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724

Al Viro <[email protected]>
d_walk() might skip too much

Jan Kara <[email protected]>
lib: Fix strnlen_user() to not touch memory after specified maximum

Chris Lesiak <[email protected]>
hwmon: (ntc_thermistor) Ensure iio channel is of type IIO_VOLTAGE

Ilya Dryomov <[email protected]>
libceph: request a new osdmap if lingering request maps to no osd

Rusty Russell <[email protected]>
lguest: fix out-by-one error in address checking.

Sasha Levin <[email protected]>
fs, omfs: add NULL terminator in the end up the token list

Paolo Bonzini <[email protected]>
KVM: MMU: fix CR4.SMEP=1, CR0.WP=0 with shadow pages

Junling Zheng <[email protected]>
net: socket: Fix the wrong returns for recvmsg and sendmsg

Kirill A. Shutemov <[email protected]>
kernel: use the gnu89 standard explicitly

Behan Webster <[email protected]>
staging, rtl8192e, LLVMLinux: Remove unused inline prototype

Arnd Bergmann <[email protected]>
staging: rtl8712, rtl8712: avoid lots of build warnings

Behan Webster <[email protected]>
staging, rtl8192e, LLVMLinux: Change extern inline to static inline

Jan-Simon Möller <[email protected]>
drm/i915: Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid}

Greg Kroah-Hartman <[email protected]>
staging: wlags49_h2: fix extern inline functions


-------------

Diffstat:

Makefile | 10 ++++----
arch/arm/boot/dts/imx27.dtsi | 2 +-
arch/arm/kernel/entry-common.S | 4 +++-
arch/powerpc/kernel/vmlinux.lds.S | 1 +
arch/s390/crypto/ghash_s390.c | 25 +++++++++----------
arch/x86/kvm/mmu.c | 2 +-
drivers/acpi/osl.c | 6 ++---
drivers/ata/libahci.c | 3 +--
drivers/ata/libata-core.c | 32 +++++++++++++++++++++++++
drivers/ata/libata-eh.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/hwmon/ntc_thermistor.c | 9 +++++++
drivers/input/mouse/elantech.c | 2 +-
drivers/lguest/core.c | 2 +-
drivers/md/raid5.c | 3 ++-
drivers/mmc/host/atmel-mci.c | 9 +++++--
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/rtlwifi/usb.c | 2 +-
drivers/staging/rtl8187se/ieee80211/ieee80211.h | 4 ++--
drivers/staging/rtl8192e/rtllib.h | 5 ++--
drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 10 ++++----
drivers/staging/rtl8712/ieee80211.h | 4 ++--
drivers/staging/wlags49_h2/wl_internal.h | 4 ++--
drivers/target/target_core_pscsi.c | 3 +++
drivers/target/target_core_pscsi.h | 1 +
drivers/usb/gadget/configfs.c | 1 +
drivers/usb/host/xhci-ring.c | 7 +++++-
drivers/usb/host/xhci.h | 2 +-
drivers/usb/serial/cp210x.c | 1 +
drivers/usb/serial/pl2303.c | 1 -
drivers/usb/serial/pl2303.h | 4 ----
drivers/usb/serial/visor.c | 2 +-
drivers/usb/storage/unusual_devs.h | 7 ++++++
fs/binfmt_elf.c | 2 +-
fs/dcache.c | 8 +++----
fs/ext4/extents.c | 2 +-
fs/ext4/inode.c | 5 ++--
fs/fhandle.c | 5 ++--
fs/omfs/inode.c | 3 ++-
include/linux/libata.h | 10 ++++++++
lib/strnlen_user.c | 3 ++-
net/ceph/osd_client.c | 31 +++++++++++++++---------
net/socket.c | 24 ++++++++-----------
net/sunrpc/auth_gss/gss_rpc_xdr.c | 23 ++++++++++++------
sound/pci/hda/patch_conexant.c | 12 ++++++++++
sound/pci/hda/patch_realtek.c | 1 +
sound/soc/codecs/mc13783.c | 4 ++--
sound/soc/codecs/uda1380.c | 2 +-
sound/soc/codecs/wm8960.c | 2 +-
sound/soc/codecs/wm8994.c | 2 +-
51 files changed, 212 insertions(+), 105 deletions(-)


2015-06-03 11:43:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 01/46] staging: wlags49_h2: fix extern inline functions

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Greg Kroah-Hartman <[email protected]>

Patch not upstream as this driver is deleted there.

Fix up some "extern inline" functions as they break the build when using
a "modern" complier (i.e. gcc5).

Signed-off-by: Greg Kroah-Hartman <[email protected]>

diff --git a/drivers/staging/wlags49_h2/wl_internal.h b/drivers/staging/wlags49_h2/wl_internal.h
index b23078164149..11b00c39a98c 100644
--- a/drivers/staging/wlags49_h2/wl_internal.h
+++ b/drivers/staging/wlags49_h2/wl_internal.h
@@ -1014,7 +1014,7 @@ static inline void wl_unlock(struct wl_private *lp,
/* Interrupt enable disable functions */
/********************************************************************/

-extern inline void wl_act_int_on(struct wl_private *lp)
+static inline void wl_act_int_on(struct wl_private *lp)
{
/*
* Only do something when the driver is handling
@@ -1026,7 +1026,7 @@ extern inline void wl_act_int_on(struct wl_private *lp)
}
}

-extern inline void wl_act_int_off(struct wl_private *lp)
+static inline void wl_act_int_off(struct wl_private *lp)
{
/*
* Only do something when the driver is handling

2015-06-03 11:53:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 03/46] staging, rtl8192e, LLVMLinux: Change extern inline to static inline

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Behan Webster <[email protected]>

commit 6d91857d4826b382b3fd4fad95f52713be646f96 upstream.

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the opposite thing from older versions of gcc
(emits code for an externally linkable version of the inline function).

"static inline" does the intended behavior in all cases instead.

Signed-off-by: Behan Webster <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/rtl8192e/rtllib.h | 4 ++--
drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -2943,12 +2943,12 @@ void rtllib_softmac_scan_syncro(struct r

extern const long rtllib_wlan_frequencies[];

-extern inline void rtllib_increment_scans(struct rtllib_device *ieee)
+static inline void rtllib_increment_scans(struct rtllib_device *ieee)
{
ieee->scans++;
}

-extern inline int rtllib_get_scans(struct rtllib_device *ieee)
+static inline int rtllib_get_scans(struct rtllib_device *ieee)
{
return ieee->scans;
}
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -341,7 +341,7 @@ inline void softmac_ps_mgmt_xmit(struct
}
}

-inline struct sk_buff *rtllib_probe_req(struct rtllib_device *ieee)
+static inline struct sk_buff *rtllib_probe_req(struct rtllib_device *ieee)
{
unsigned int len, rate_len;
u8 *tag;

2015-06-03 11:51:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 04/46] staging: rtl8712, rtl8712: avoid lots of build warnings

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Arnd Bergmann <[email protected]>

commit 0c9f3a65c5eb7fe1fc611a22eb8a8b71ea865998 upstream.

The rtl8712 driver has an 'extern inline' function that contains an
'if', which causes lots of warnings with CONFIG_PROFILE_ALL_BRANCHES
overriding the definition of 'if':

drivers/staging/rtl8712/ieee80211.h:759:229: warning: '______f' is static but declared in inline function 'ieee80211_get_hdrlen' which is not static [enabled by default]

This changes the driver to use 'static inline' instead, which happens
to be the correct annotation anyway.

Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Larry Finger <[email protected]>
Cc: Florian Schilhabel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/rtl8187se/ieee80211/ieee80211.h | 4 ++--
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 10 +++++-----
drivers/staging/rtl8712/ieee80211.h | 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/staging/rtl8187se/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8187se/ieee80211/ieee80211.h
@@ -1447,12 +1447,12 @@ extern void ieee80211_sta_ps_send_null_f

extern const long ieee80211_wlan_frequencies[];

-extern inline void ieee80211_increment_scans(struct ieee80211_device *ieee)
+static inline void ieee80211_increment_scans(struct ieee80211_device *ieee)
{
ieee->scans++;
}

-extern inline int ieee80211_get_scans(struct ieee80211_device *ieee)
+static inline int ieee80211_get_scans(struct ieee80211_device *ieee)
{
return ieee->scans;
}
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -2250,7 +2250,7 @@ static inline void *ieee80211_priv(struc
return ((struct ieee80211_device *)netdev_priv(dev))->priv;
}

-extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len)
+static inline int ieee80211_is_empty_essid(const char *essid, int essid_len)
{
/* Single white space is for Linksys APs */
if (essid_len == 1 && essid[0] == ' ')
@@ -2266,7 +2266,7 @@ extern inline int ieee80211_is_empty_ess
return 1;
}

-extern inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode)
+static inline int ieee80211_is_valid_mode(struct ieee80211_device *ieee, int mode)
{
/*
* It is possible for both access points and our device to support
@@ -2292,7 +2292,7 @@ extern inline int ieee80211_is_valid_mod
return 0;
}

-extern inline int ieee80211_get_hdrlen(u16 fc)
+static inline int ieee80211_get_hdrlen(u16 fc)
{
int hdrlen = IEEE80211_3ADDR_LEN;

@@ -2578,12 +2578,12 @@ void ieee80211_softmac_scan_syncro(struc

extern const long ieee80211_wlan_frequencies[];

-extern inline void ieee80211_increment_scans(struct ieee80211_device *ieee)
+static inline void ieee80211_increment_scans(struct ieee80211_device *ieee)
{
ieee->scans++;
}

-extern inline int ieee80211_get_scans(struct ieee80211_device *ieee)
+static inline int ieee80211_get_scans(struct ieee80211_device *ieee)
{
return ieee->scans;
}
--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -734,7 +734,7 @@ enum ieee80211_state {
#define IEEE_G (1<<2)
#define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G)

-extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len)
+static inline int ieee80211_is_empty_essid(const char *essid, int essid_len)
{
/* Single white space is for Linksys APs */
if (essid_len == 1 && essid[0] == ' ')
@@ -748,7 +748,7 @@ extern inline int ieee80211_is_empty_ess
return 1;
}

-extern inline int ieee80211_get_hdrlen(u16 fc)
+static inline int ieee80211_get_hdrlen(u16 fc)
{
int hdrlen = 24;


2015-06-03 11:51:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 05/46] staging, rtl8192e, LLVMLinux: Remove unused inline prototype

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Behan Webster <[email protected]>

commit 62ec95f86d2850b7ce6d73fb236a6fcf48411aea upstream.

rtllib_probe_req is defined as "static inline" in rtllib_softmac.c however it
is declared differently as "extern inline" in rtllib_softmac.h. Since it isn't
used outside of the scope of rtllib_softmac, it makes sense to remove the
incorrect declaration.

Signed-off-by: Behan Webster <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/staging/rtl8192e/rtllib.h | 1 -
1 file changed, 1 deletion(-)

--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -2761,7 +2761,6 @@ extern void rtllib_stop_scan(struct rtll
extern bool rtllib_act_scanning(struct rtllib_device *ieee, bool sync_scan);
extern void rtllib_stop_scan_syncro(struct rtllib_device *ieee);
extern void rtllib_start_scan_syncro(struct rtllib_device *ieee, u8 is_mesh);
-extern inline struct sk_buff *rtllib_probe_req(struct rtllib_device *ieee);
extern u8 MgntQuery_MgntFrameTxRate(struct rtllib_device *ieee);
extern void rtllib_sta_ps_send_null_frame(struct rtllib_device *ieee,
short pwr);

2015-06-03 11:46:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 06/46] kernel: use the gnu89 standard explicitly

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Kirill A. Shutemov" <[email protected]>

commit 51b97e354ba9fce1890cf38ecc754aa49677fc89 upstream.

Sasha Levin reports:
"gcc5 changes the default standard to c11, which makes kernel build
unhappy

Explicitly define the kernel standard to be gnu89 which should keep
everything working exactly like it was before gcc5"

There are multiple small issues with the new default, but the biggest
issue seems to be that the old - and very useful - GNU extension to
allow a cast in front of an initializer has gone away.

Patch updated by Kirill:
"I'm pretty sure all gcc versions you can build kernel with supports
-std=gnu89. cc-option is redunrant.

We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me"

Note by Andrew Pinski:
"Yes it was reported and both problems relating to this extension has
been added to gnu99 and gnu11. Though there are other issues with the
kernel dealing with extern inline have different semantics between
gnu89 and gnu99/11"

End result: we may be able to move up to a newer stdc model eventually,
but right now the newer models have some annoying deficiencies, so the
traditional "gnu89" model ends up being the preferred one.

Signed-off-by: Sasha Levin <[email protected]>
Singed-off-by: Kirill A. Shutemov <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
Makefile | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/Makefile
+++ b/Makefile
@@ -241,7 +241,7 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH"

HOSTCC = gcc
HOSTCXX = g++
-HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
HOSTCXXFLAGS = -O2

# Decide whether to build built-in, modular, or both.
@@ -373,7 +373,9 @@ KBUILD_CFLAGS := -Wall -Wundef -Wstric
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security \
- -fno-delete-null-pointer-checks
+ -fno-delete-null-pointer-checks \
+ -std=gnu89
+
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
KBUILD_AFLAGS := -D__ASSEMBLY__

2015-06-03 11:46:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 07/46] net: socket: Fix the wrong returns for recvmsg and sendmsg

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Junling Zheng <[email protected]>

Based on 08adb7dabd4874cc5666b4490653b26534702ce0 upstream.

We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL
was expected.

We tested it through the recvmsg01 testcase come from LTP testsuit. It set
msg->msg_namelen to -1 and the recvmsg syscall returned errno 14, which is
unexpected (errno 22 is expected):

recvmsg01 4 TFAIL : invalid socket length ; returned -1 (expected -1),
errno 14 (expected 22)

Linux mainline has no this bug for commit 08adb7dab fixes it accidentally.
However, it is too large and complex to be backported to LTS 3.10.

Commit 281c9c36 (net: compat: Update get_compat_msghdr() to match
copy_msghdr_from_user() behaviour) made get_compat_msghdr() return
error if msg_sys->msg_namelen was negative, which changed the behaviors
of recvmsg and sendmsg syscall in a lib32 system:

Before commit 281c9c36, get_compat_msghdr() wouldn't fail and it would
return -EINVAL in move_addr_to_user() or somewhere if msg_sys->msg_namelen
was invalid and then syscall returned -EINVAL, which is correct.

And now, when msg_sys->msg_namelen is negative, get_compat_msghdr() will
fail and wants to return -EINVAL, however, the outer syscall will return
-EFAULT directly, which is unexpected.

This patch gets the return value of get_compat_msghdr() as well as
copy_msghdr_from_user(), then returns this expected value if
get_compat_msghdr() fails.

Fixes: 281c9c36 (net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour)
Signed-off-by: Junling Zheng <[email protected]>
Signed-off-by: Hanbing Xu <[email protected]>
Cc: Li Zefan <[email protected]>
Cc: Al Viro <[email protected]>
Cc: David Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/socket.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)

--- a/net/socket.c
+++ b/net/socket.c
@@ -1988,14 +1988,12 @@ static int ___sys_sendmsg(struct socket
int err, ctl_len, total_len;

err = -EFAULT;
- if (MSG_CMSG_COMPAT & flags) {
- if (get_compat_msghdr(msg_sys, msg_compat))
- return -EFAULT;
- } else {
+ if (MSG_CMSG_COMPAT & flags)
+ err = get_compat_msghdr(msg_sys, msg_compat);
+ else
err = copy_msghdr_from_user(msg_sys, msg);
- if (err)
- return err;
- }
+ if (err)
+ return err;

if (msg_sys->msg_iovlen > UIO_FASTIOV) {
err = -EMSGSIZE;
@@ -2200,14 +2198,12 @@ static int ___sys_recvmsg(struct socket
struct sockaddr __user *uaddr;
int __user *uaddr_len;

- if (MSG_CMSG_COMPAT & flags) {
- if (get_compat_msghdr(msg_sys, msg_compat))
- return -EFAULT;
- } else {
+ if (MSG_CMSG_COMPAT & flags)
+ err = get_compat_msghdr(msg_sys, msg_compat);
+ else
err = copy_msghdr_from_user(msg_sys, msg);
- if (err)
- return err;
- }
+ if (err)
+ return err;

if (msg_sys->msg_iovlen > UIO_FASTIOV) {
err = -EMSGSIZE;

2015-06-03 11:46:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 08/46] KVM: MMU: fix CR4.SMEP=1, CR0.WP=0 with shadow pages

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paolo Bonzini <[email protected]>

commit 898761158be7682082955e3efa4ad24725305fc7 upstream.

smep_andnot_wp is initialized in kvm_init_shadow_mmu and shadow pages
should not be reused for different values of it. Thus, it has to be
added to the mask in kvm_mmu_pte_write.

Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kvm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3975,7 +3975,7 @@ void kvm_mmu_pte_write(struct kvm_vcpu *
++vcpu->kvm->stat.mmu_pte_write;
kvm_mmu_audit(vcpu, AUDIT_PRE_PTE_WRITE);

- mask.cr0_wp = mask.cr4_pae = mask.nxe = 1;
+ mask.cr0_wp = mask.cr4_pae = mask.nxe = mask.smep_andnot_wp = 1;
for_each_gfn_indirect_valid_sp(vcpu->kvm, sp, gfn) {
if (detect_write_misaligned(sp, gpa, bytes) ||
detect_write_flooding(sp)) {

2015-06-03 11:46:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 09/46] fs, omfs: add NULL terminator in the end up the token list

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sasha Levin <[email protected]>

commit dcbff39da3d815f08750552fdd04f96b51751129 upstream.

match_token() expects a NULL terminator at the end of the token list so
that it would know where to stop. Not having one causes it to overrun
to invalid memory.

In practice, passing a mount option that omfs didn't recognize would
sometimes panic the system.

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Bob Copeland <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/omfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/omfs/inode.c
+++ b/fs/omfs/inode.c
@@ -361,7 +361,7 @@ nomem:
}

enum {
- Opt_uid, Opt_gid, Opt_umask, Opt_dmask, Opt_fmask
+ Opt_uid, Opt_gid, Opt_umask, Opt_dmask, Opt_fmask, Opt_err
};

static const match_table_t tokens = {
@@ -370,6 +370,7 @@ static const match_table_t tokens = {
{Opt_umask, "umask=%o"},
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
+ {Opt_err, NULL},
};

static int parse_options(char *options, struct omfs_sb_info *sbi)

2015-06-03 11:43:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 10/46] lguest: fix out-by-one error in address checking.

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Rusty Russell <[email protected]>

commit 83a35114d0e4583e6b0ca39502e68b6a92e2910c upstream.

This bug has been there since day 1; addresses in the top guest physical
page weren't considered valid. You could map that page (the check in
check_gpte() is correct), but if a guest tried to put a pagetable there
we'd check that address manually when walking it, and kill the guest.

Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/lguest/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -176,7 +176,7 @@ static void unmap_switcher(void)
bool lguest_address_ok(const struct lguest *lg,
unsigned long addr, unsigned long len)
{
- return (addr+len) / PAGE_SIZE < lg->pfn_limit && (addr+len >= addr);
+ return addr+len <= lg->pfn_limit * PAGE_SIZE && (addr+len >= addr);
}

/*

2015-06-03 11:44:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 11/46] libceph: request a new osdmap if lingering request maps to no osd

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilya Dryomov <[email protected]>

commit b0494532214bdfbf241e94fabab5dd46f7b82631 upstream.

This commit does two things. First, if there are any homeless
lingering requests, we now request a new osdmap even if the osdmap that
is being processed brought no changes, i.e. if a given lingering
request turned homeless in one of the previous epochs and remained
homeless in the current epoch. Not doing so leaves us with a stale
osdmap and as a result we may miss our window for reestablishing the
watch and lose notifies.

MON=1 OSD=1:

# cat linger-needmap.sh
#!/bin/bash
rbd create --size 1 test
DEV=$(rbd map test)
ceph osd out 0
rbd map dne/dne # obtain a new osdmap as a side effect (!)
sleep 1
ceph osd in 0
rbd resize --size 2 test
# rbd info test | grep size -> 2M
# blockdev --getsize $DEV -> 1M

N.B.: Not obtaining a new osdmap in between "osd out" and "osd in"
above is enough to make it miss that resize notify, but that is a
bug^Wlimitation of ceph watch/notify v1.

Second, homeless lingering requests are now kicked just like those
lingering requests whose mapping has changed. This is mainly to
recognize that a homeless lingering request makes no sense and to
preserve the invariant that a registered lingering request is not
sitting on any of r_req_lru_item lists. This spares us a WARN_ON,
which commit ba9d114ec557 ("libceph: clear r_req_lru_item in
__unregister_linger_request()") tried to fix the _wrong_ way.

Signed-off-by: Ilya Dryomov <[email protected]>
Reviewed-by: Sage Weil <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/ceph/osd_client.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)

--- a/net/ceph/osd_client.c
+++ b/net/ceph/osd_client.c
@@ -1702,20 +1702,29 @@ static void kick_requests(struct ceph_os
err = __map_request(osdc, req,
force_resend || force_resend_writes);
dout("__map_request returned %d\n", err);
- if (err == 0)
- continue; /* no change and no osd was specified */
if (err < 0)
continue; /* hrm! */
- if (req->r_osd == NULL) {
- dout("tid %llu maps to no valid osd\n", req->r_tid);
- needmap++; /* request a newer map */
- continue;
- }
+ if (req->r_osd == NULL || err > 0) {
+ if (req->r_osd == NULL) {
+ dout("lingering %p tid %llu maps to no osd\n",
+ req, req->r_tid);
+ /*
+ * A homeless lingering request makes
+ * no sense, as it's job is to keep
+ * a particular OSD connection open.
+ * Request a newer map and kick the
+ * request, knowing that it won't be
+ * resent until we actually get a map
+ * that can tell us where to send it.
+ */
+ needmap++;
+ }

- dout("kicking lingering %p tid %llu osd%d\n", req, req->r_tid,
- req->r_osd ? req->r_osd->o_osd : -1);
- __register_request(osdc, req);
- __unregister_linger_request(osdc, req);
+ dout("kicking lingering %p tid %llu osd%d\n", req,
+ req->r_tid, req->r_osd ? req->r_osd->o_osd : -1);
+ __register_request(osdc, req);
+ __unregister_linger_request(osdc, req);
+ }
}
reset_changed_osds(osdc);
mutex_unlock(&osdc->request_mutex);

2015-06-03 11:44:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 12/46] hwmon: (ntc_thermistor) Ensure iio channel is of type IIO_VOLTAGE

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Chris Lesiak <[email protected]>

commit adba657533bdd255f7b78bc8a324091f46b294cd upstream.

When configured via device tree, the associated iio device needs to be
measuring voltage for the conversion to resistance to be correct.
Return -EINVAL if that is not the case.

Signed-off-by: Chris Lesiak <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/hwmon/ntc_thermistor.c | 9 +++++++++
1 file changed, 9 insertions(+)

--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -181,8 +181,10 @@ static struct ntc_thermistor_platform_da
ntc_thermistor_parse_dt(struct platform_device *pdev)
{
struct iio_channel *chan;
+ enum iio_chan_type type;
struct device_node *np = pdev->dev.of_node;
struct ntc_thermistor_platform_data *pdata;
+ int ret;

if (!np)
return NULL;
@@ -195,6 +197,13 @@ ntc_thermistor_parse_dt(struct platform_
if (IS_ERR(chan))
return ERR_CAST(chan);

+ ret = iio_get_channel_type(chan, &type);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ if (type != IIO_VOLTAGE)
+ return ERR_PTR(-EINVAL);
+
if (of_property_read_u32(np, "pullup-uv", &pdata->pullup_uv))
return ERR_PTR(-ENODEV);
if (of_property_read_u32(np, "pullup-ohm", &pdata->pullup_ohm))

2015-06-03 11:56:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 13/46] lib: Fix strnlen_user() to not touch memory after specified maximum

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit f18c34e483ff6b1d9866472221e4015b3a4698e4 upstream.

If the specified maximum length of the string is a multiple of unsigned
long, we would load one long behind the specified maximum. If that
happens to be in a next page, we can hit a page fault although we were
not expected to.

Fix the off-by-one bug in the test whether we are at the end of the
specified range.

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
lib/strnlen_user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/lib/strnlen_user.c
+++ b/lib/strnlen_user.c
@@ -57,7 +57,8 @@ static inline long do_strnlen_user(const
return res + find_zero(data) + 1 - align;
}
res += sizeof(unsigned long);
- if (unlikely(max < sizeof(unsigned long)))
+ /* We already handled 'unsigned long' bytes. Did we do it all ? */
+ if (unlikely(max <= sizeof(unsigned long)))
break;
max -= sizeof(unsigned long);
if (unlikely(__get_user(c,(unsigned long __user *)(src+res))))

2015-06-03 11:44:23

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 14/46] d_walk() might skip too much

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Al Viro <[email protected]>

commit 2159184ea01e4ae7d15f2017e296d4bc82d5aeb0 upstream.

when we find that a child has died while we'd been trying to ascend,
we should go into the first live sibling itself, rather than its sibling.

Off-by-one in question had been introduced in "deal with deadlock in
d_walk()" and the fix needs to be backported to all branches this one
has been backported to.

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/dcache.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1179,13 +1179,13 @@ ascend:
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == &this_parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}

2015-06-03 11:44:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 15/46] ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: David Henningsson <[email protected]>

commit 6ffc0898b29a2811a6c0569c5dd9b581980110df upstream.

This patch adds support for Conexant HD Audio codecs
CX20721, CX20722, CX20723 and CX20724.

BugLink: https://bugs.launchpad.net/bugs/1454656
Signed-off-by: David Henningsson <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_conexant.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -3490,6 +3490,14 @@ static const struct hda_codec_preset snd
.patch = patch_conexant_auto },
{ .id = 0x14f150b9, .name = "CX20665",
.patch = patch_conexant_auto },
+ { .id = 0x14f150f1, .name = "CX20721",
+ .patch = patch_conexant_auto },
+ { .id = 0x14f150f2, .name = "CX20722",
+ .patch = patch_conexant_auto },
+ { .id = 0x14f150f3, .name = "CX20723",
+ .patch = patch_conexant_auto },
+ { .id = 0x14f150f4, .name = "CX20724",
+ .patch = patch_conexant_auto },
{ .id = 0x14f1510f, .name = "CX20751/2",
.patch = patch_conexant_auto },
{ .id = 0x14f15110, .name = "CX20751/2",
@@ -3524,6 +3532,10 @@ MODULE_ALIAS("snd-hda-codec-id:14f150ab"
MODULE_ALIAS("snd-hda-codec-id:14f150ac");
MODULE_ALIAS("snd-hda-codec-id:14f150b8");
MODULE_ALIAS("snd-hda-codec-id:14f150b9");
+MODULE_ALIAS("snd-hda-codec-id:14f150f1");
+MODULE_ALIAS("snd-hda-codec-id:14f150f2");
+MODULE_ALIAS("snd-hda-codec-id:14f150f3");
+MODULE_ALIAS("snd-hda-codec-id:14f150f4");
MODULE_ALIAS("snd-hda-codec-id:14f1510f");
MODULE_ALIAS("snd-hda-codec-id:14f15110");
MODULE_ALIAS("snd-hda-codec-id:14f15111");

2015-06-03 11:44:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 16/46] ALSA: hda - Add headphone quirk for Lifebook E752

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <[email protected]>

commit 88776f366ede7d9cdce60bd2c9753dd6d6fa8b77 upstream.

Fujitsu Lifebook E752 laptop needs a similar quirk done for Lifebook
T731. Otherwise the headphone is always muted.

Reported-and-tested-by: Christian Weber <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3736,6 +3736,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK_VENDOR(0x1025, "Acer Aspire", ALC271_FIXUP_DMIC),
SND_PCI_QUIRK(0x10cf, 0x1475, "Lifebook", ALC269_FIXUP_LIFEBOOK),
SND_PCI_QUIRK(0x10cf, 0x15dc, "Lifebook T731", ALC269_FIXUP_LIFEBOOK_HP_PIN),
+ SND_PCI_QUIRK(0x10cf, 0x1757, "Lifebook E752", ALC269_FIXUP_LIFEBOOK_HP_PIN),
SND_PCI_QUIRK(0x10cf, 0x1845, "Lifebook U904", ALC269_FIXUP_LIFEBOOK_EXTMIC),
SND_PCI_QUIRK(0x17aa, 0x20f2, "Thinkpad SL410/510", ALC269_FIXUP_SKU_IGNORE),
SND_PCI_QUIRK(0x17aa, 0x215e, "Thinkpad L512", ALC269_FIXUP_SKU_IGNORE),

2015-06-03 11:56:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 17/46] ASoC: mc13783: Fix wrong mask value used in mc13xxx_reg_rmw() calls

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Axel Lin <[email protected]>

commit 545774bd6e1427d98dde77244329d2311c5eca6f upstream.

mc13xxx_reg_rmw() won't change any bit if passing 0 to the mask field.
Pass AUDIO_SSI_SEL instead of 0 for the mask field to set AUDIO_SSI_SEL
bit.

Signed-off-by: Axel Lin <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/codecs/mc13783.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/soc/codecs/mc13783.c
+++ b/sound/soc/codecs/mc13783.c
@@ -604,14 +604,14 @@ static int mc13783_probe(struct snd_soc_
AUDIO_SSI_SEL, 0);
else
mc13xxx_reg_rmw(priv->mc13xxx, MC13783_AUDIO_CODEC,
- 0, AUDIO_SSI_SEL);
+ AUDIO_SSI_SEL, AUDIO_SSI_SEL);

if (priv->dac_ssi_port == MC13783_SSI1_PORT)
mc13xxx_reg_rmw(priv->mc13xxx, MC13783_AUDIO_DAC,
AUDIO_SSI_SEL, 0);
else
mc13xxx_reg_rmw(priv->mc13xxx, MC13783_AUDIO_DAC,
- 0, AUDIO_SSI_SEL);
+ AUDIO_SSI_SEL, AUDIO_SSI_SEL);

mc13xxx_unlock(priv->mc13xxx);


2015-06-03 11:44:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 18/46] ASoC: uda1380: Avoid accessing i2c bus when codec is disabled

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vasily Khoruzhick <[email protected]>

commit 810e4425c224af6be67dff68c8832af1b5a11f89 upstream.

set_dai_fmt_both() callback is called from snd_soc_runtime_set_dai_fmt()
which is called from snd_soc_register_card(), but at this time codec
is not powered on yet. Replace direct i2c write with regcache write.

Fixes: 5f0acedddf533c (ASoC: rx1950_uda1380: Use static DAI format setup)
Fixes: 5cc10b9b77c234 (ASoC: h1940_uda1380: Use static DAI format setup)
Signed-off-by: Vasily Khoruzhick <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/codecs/uda1380.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/uda1380.c
+++ b/sound/soc/codecs/uda1380.c
@@ -435,7 +435,7 @@ static int uda1380_set_dai_fmt_both(stru
if ((fmt & SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBS_CFS)
return -EINVAL;

- uda1380_write(codec, UDA1380_IFACE, iface);
+ uda1380_write_reg_cache(codec, UDA1380_IFACE, iface);

return 0;
}

2015-06-03 11:45:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 19/46] ASoC: wm8960: fix "RINPUT3" audio route error

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zidan Wang <[email protected]>

commit 85e36a1f4a735d991ba5106781ea48e89a0b8901 upstream.

It should be "RINPUT3" instead of "LINPUT3" route to "Right Input
Mixer".

Signed-off-by: Zidan Wang <[email protected]>
Acked-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/codecs/wm8960.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -392,7 +392,7 @@ static const struct snd_soc_dapm_route a
{ "Right Input Mixer", "Boost Switch", "Right Boost Mixer", },
{ "Right Input Mixer", NULL, "RINPUT1", }, /* Really Boost Switch */
{ "Right Input Mixer", NULL, "RINPUT2" },
- { "Right Input Mixer", NULL, "LINPUT3" },
+ { "Right Input Mixer", NULL, "RINPUT3" },

{ "Left ADC", NULL, "Left Input Mixer" },
{ "Right ADC", NULL, "Right Input Mixer" },

2015-06-03 11:55:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 20/46] ASoC: wm8994: correct BCLK DIV 348 to 384

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Zidan Wang <[email protected]>

commit 17fc2e0a3db11889e942c5ab15a1fcb876638f25 upstream.

According to the RM of wm8958, BCLK DIV 348 doesn't exist, correct it
to 384.

Signed-off-by: Zidan Wang <[email protected]>
Acked-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
sound/soc/codecs/wm8994.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/wm8994.c
+++ b/sound/soc/codecs/wm8994.c
@@ -2679,7 +2679,7 @@ static struct {
};

static int fs_ratios[] = {
- 64, 128, 192, 256, 348, 512, 768, 1024, 1408, 1536
+ 64, 128, 192, 256, 384, 512, 768, 1024, 1408, 1536
};

static int bclk_divs[] = {

2015-06-03 11:45:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 21/46] target/pscsi: Dont leak scsi_host if hba is VIRTUAL_HOST

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andy Grover <[email protected]>

commit 5a7125c64def3b21f8147eca8b54949a60963942 upstream.

See https://bugzilla.redhat.com/show_bug.cgi?id=1025672

We need to put() the reference to the scsi host that we got in
pscsi_configure_device(). In VIRTUAL_HOST mode it is associated with
the dev_virt, not the hba_virt.

Signed-off-by: Andy Grover <[email protected]>
Signed-off-by: Nicholas Bellinger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/target/target_core_pscsi.c | 3 +++
drivers/target/target_core_pscsi.h | 1 +
2 files changed, 4 insertions(+)

--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -520,6 +520,7 @@ static int pscsi_configure_device(struct
" pdv_host_id: %d\n", pdv->pdv_host_id);
return -EINVAL;
}
+ pdv->pdv_lld_host = sh;
}
} else {
if (phv->phv_mode == PHV_VIRTUAL_HOST_ID) {
@@ -602,6 +603,8 @@ static void pscsi_free_device(struct se_
if ((phv->phv_mode == PHV_LLD_SCSI_HOST_NO) &&
(phv->phv_lld_host != NULL))
scsi_host_put(phv->phv_lld_host);
+ else if (pdv->pdv_lld_host)
+ scsi_host_put(pdv->pdv_lld_host);

if ((sd->type == TYPE_DISK) || (sd->type == TYPE_ROM))
scsi_device_put(sd);
--- a/drivers/target/target_core_pscsi.h
+++ b/drivers/target/target_core_pscsi.h
@@ -45,6 +45,7 @@ struct pscsi_dev_virt {
int pdv_lun_id;
struct block_device *pdv_bd;
struct scsi_device *pdv_sd;
+ struct Scsi_Host *pdv_lld_host;
} ____cacheline_aligned;

typedef enum phv_modes {

2015-06-03 11:45:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 22/46] xhci: fix isoc endpoint dequeue from advancing too far on transaction error

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit d104d0152a97fade389f47635b73a9ccc7295d0b upstream.

Isoc TDs usually consist of one TRB, sometimes two. When all goes well we
receive only one success event for a TD, and move the dequeue pointer to
the next TD.

This fails if the TD consists of two TRBs and we get a transfer error
on the first TRB, we will then see two events for that TD.

Fix this by making sure the event we get is for the last TRB in that TD
before moving the dequeue pointer to the next TD. This will resolve some
of the uvc and dvb issues with the
"ERROR Transfer event TRB DMA ptr not part of current TD" error message

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-ring.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2144,8 +2144,13 @@ static int process_isoc_td(struct xhci_h
break;
case COMP_DEV_ERR:
case COMP_STALL:
+ frame->status = -EPROTO;
+ skip_td = true;
+ break;
case COMP_TX_ERR:
frame->status = -EPROTO;
+ if (event_trb != td->last_trb)
+ return 0;
skip_td = true;
break;
case COMP_STOP:

2015-06-03 11:45:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 23/46] xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit 18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream.

Our event ring consists of only one segment, and we risk filling
the event ring in case we get isoc transfers with short intervals
such as webcams that fill a TD every microframe (125us)

With 64 TRB segment size one usb camera could fill the event ring in 8ms.
A setup with several cameras and other devices can fill up the
event ring as it is shared between all devices.
This has occurred when uvcvideo queues 5 * 32TD URBs which then
get cancelled when the video mode changes. The cancelled URBs are returned
in the xhci interrupt context and blocks the interrupt handler from
handling the new events.

A full event ring will block xhci from scheduling traffic and affect all
devices conneted to the xhci, will see errors such as Missed Service
Intervals for isoc devices, and and Split transaction errors for LS/FS
interrupt devices.

Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring
size, which is welcome as for most isoc transfer we had to dynamically
expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo
queues.

The default size used to be 64 TRBs per segment

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1237,7 +1237,7 @@ union xhci_trb {
* since the command ring is 64-byte aligned.
* It must also be greater than 16.
*/
-#define TRBS_PER_SEGMENT 64
+#define TRBS_PER_SEGMENT 256
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)

2015-06-03 11:45:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 24/46] xhci: gracefully handle xhci_irq dead device

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joe Lawrence <[email protected]>

commit 948fa13504f80b9765d2b753691ab94c83a10341 upstream.

If the xHCI host controller has died (ie, device removed) or suffered
other serious fatal error (STS_FATAL), then xhci_irq should handle this
condition with IRQ_HANDLED instead of -ESHUTDOWN.

Signed-off-by: Joe Lawrence <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2767,7 +2767,7 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd
xhci_halt(xhci);
hw_died:
spin_unlock(&xhci->lock);
- return -ESHUTDOWN;
+ return IRQ_HANDLED;
}

/*

2015-06-03 11:55:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 25/46] USB: visor: Match I330 phone more precisely

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Jason A. Donenfeld" <[email protected]>

commit 82ee3aeb9295c5fc37fd2ddf20f13ac2b40ec97d upstream.

Samsung has just released a portable USB3 SSD, coming in a very small
and nice form factor. It's USB ID is 04e8:8001, which unfortunately is
already used by the Palm Visor driver for the Samsung I330 phone cradle.
Having pl2303 or visor pick up this device ID results in conflicts with
the usb-storage driver, which handles the newly released portable USB3
SSD.

To work around this conflict, I've dug up a mailing list post [1] from a
long time ago, in which a user posts the full USB descriptor
information. The most specific value in this appears to be the interface
class, which has value 255 (0xff). Since usb-storage requires an
interface class of 0x8, I believe it's correct to disambiguate the two
devices by matching on 0xff inside visor.

[1] http://permalink.gmane.org/gmane.linux.usb.user/4264

Signed-off-by: Jason A. Donenfeld <[email protected]>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/visor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/serial/visor.c
+++ b/drivers/usb/serial/visor.c
@@ -96,7 +96,7 @@ static struct usb_device_id id_table []
.driver_info = (kernel_ulong_t)&palm_os_4_probe },
{ USB_DEVICE(ACER_VENDOR_ID, ACER_S10_ID),
.driver_info = (kernel_ulong_t)&palm_os_4_probe },
- { USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_SCH_I330_ID),
+ { USB_DEVICE_INTERFACE_CLASS(SAMSUNG_VENDOR_ID, SAMSUNG_SCH_I330_ID, 0xff),
.driver_info = (kernel_ulong_t)&palm_os_4_probe },
{ USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_SPH_I500_ID),
.driver_info = (kernel_ulong_t)&palm_os_4_probe },

2015-06-03 11:55:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 26/46] USB: pl2303: Remove support for Samsung I330

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Jason A. Donenfeld" <[email protected]>

commit 48ef23a4f686b1e4519d4193c20d26834ff810ff upstream.

This phone is already supported by the visor driver.

Signed-off-by: Jason A. Donenfeld <[email protected]>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/pl2303.c | 1 -
drivers/usb/serial/pl2303.h | 4 ----
2 files changed, 5 deletions(-)

--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -63,7 +63,6 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(DCU10_VENDOR_ID, DCU10_PRODUCT_ID) },
{ USB_DEVICE(SITECOM_VENDOR_ID, SITECOM_PRODUCT_ID) },
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_ID) },
- { USB_DEVICE(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_ID) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_SX1) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X65) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, SIEMENS_PRODUCT_ID_X75) },
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -62,10 +62,6 @@
#define ALCATEL_VENDOR_ID 0x11f7
#define ALCATEL_PRODUCT_ID 0x02df

-/* Samsung I330 phone cradle */
-#define SAMSUNG_VENDOR_ID 0x04e8
-#define SAMSUNG_PRODUCT_ID 0x8001
-
#define SIEMENS_VENDOR_ID 0x11f5
#define SIEMENS_PRODUCT_ID_SX1 0x0001
#define SIEMENS_PRODUCT_ID_X65 0x0003

2015-06-03 11:55:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 27/46] USB: cp210x: add ID for KCF Technologies PRN device

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mark Edwards <[email protected]>

commit c735ed74d83f8ecb45c4c4c95a16853c9c3c8157 upstream.

Added the USB serial console device ID for KCF Technologies PRN device
which has a USB port for its serial console.

Signed-off-by: Mark Edwards <[email protected]>
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -127,6 +127,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x10C4, 0x88A5) }, /* Planet Innovation Ingeni ZigBee USB Device */
{ USB_DEVICE(0x10C4, 0x8946) }, /* Ketra N1 Wireless Interface */
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
+ { USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */

2015-06-03 11:45:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 28/46] usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Hans de Goede <[email protected]>

commit 172115090f5e739660b97694618a2ba86457063a upstream.

Without this flag some versions of these enclosures do not work.

Reported-and-tested-by: Christian Schaller <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/storage/unusual_devs.h | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -760,6 +760,13 @@ UNUSUAL_DEV( 0x059f, 0x0643, 0x0000, 0x
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_GO_SLOW ),

+/* Reported by Christian Schaller <[email protected]> */
+UNUSUAL_DEV( 0x059f, 0x0651, 0x0000, 0x0000,
+ "LaCie",
+ "External HDD",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_NO_WP_DETECT ),
+
/* Submitted by Joel Bourquard <[email protected]>
* Some versions of this device need the SubClass and Protocol overrides
* while others don't.

2015-06-03 11:53:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 29/46] usb: gadget: configfs: Fix interfaces array NULL-termination

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Krzysztof Opasiak <[email protected]>

commit 903124fe1aa284f61745a9dd4fbfa0184e569fff upstream.

memset() to 0 interfaces array before reusing
usb_configuration structure.

This commit fix bug:

ln -s functions/acm.1 configs/c.1
ln -s functions/acm.2 configs/c.1
ln -s functions/acm.3 configs/c.1
echo "UDC name" > UDC
echo "" > UDC
rm configs/c.1/acm.*
rmdir functions/*
mkdir functions/ecm.usb0
ln -s functions/ecm.usb0 configs/c.1
echo "UDC name" > UDC

[ 82.220969] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 82.229009] pgd = c0004000
[ 82.231698] [00000000] *pgd=00000000
[ 82.235260] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 82.240638] Modules linked in:
[ 82.243681] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.0.0-rc2 #39
[ 82.249926] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 82.256003] task: c07cd2f0 ti: c07c8000 task.ti: c07c8000
[ 82.261393] PC is at composite_setup+0xe3c/0x1674
[ 82.266073] LR is at composite_setup+0xf20/0x1674
[ 82.270760] pc : [<c03510d4>] lr : [<c03511b8>] psr: 600001d3
[ 82.270760] sp : c07c9df0 ip : c0806448 fp : ed8c9c9c
[ 82.282216] r10: 00000001 r9 : 00000000 r8 : edaae918
[ 82.287425] r7 : ed551cc0 r6 : 00007fff r5 : 00000000 r4 : ed799634
[ 82.293934] r3 : 00000003 r2 : 00010002 r1 : edaae918 r0 : 0000002e
[ 82.300446] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 82.307910] Control: 10c5387d Table: 6bc1804a DAC: 00000015
[ 82.313638] Process swapper/0 (pid: 0, stack limit = 0xc07c8210)
[ 82.319627] Stack: (0xc07c9df0 to 0xc07ca000)
[ 82.323969] 9de0: 00000000 c06e65f4 00000000 c07c9f68
[ 82.332130] 9e00: 00000067 c07c59ac 000003f7 edaae918 ed8c9c98 ed799690 eca2f140 200001d3
[ 82.340289] 9e20: ee79a2d8 c07c9e88 c07c5304 ffff55db 00010002 edaae810 edaae860 eda96d50
[ 82.348448] 9e40: 00000009 ee264510 00000007 c07ca444 edaae860 c0340890 c0827a40 ffff55e0
[ 82.356607] 9e60: c0827a40 eda96e40 ee264510 edaae810 00000000 edaae860 00000007 c07ca444
[ 82.364766] 9e80: edaae860 c0354170 c03407dc c033db4c edaae810 00000000 00000000 00000010
[ 82.372925] 9ea0: 00000032 c0341670 00000000 00000000 00000001 eda96e00 00000000 00000000
[ 82.381084] 9ec0: 00000000 00000032 c0803a23 ee1aa840 00000001 c005d54c 249e2450 00000000
[ 82.389244] 9ee0: 200001d3 ee1aa840 ee1aa8a0 ed84f4c0 00000000 c07c9f68 00000067 c07c59ac
[ 82.397403] 9f00: 00000000 c005d688 ee1aa840 ee1aa8a0 c07db4b4 c006009c 00000032 00000000
[ 82.405562] 9f20: 00000001 c005ce20 c07c59ac c005cf34 f002000c c07ca780 c07c9f68 00000057
[ 82.413722] 9f40: f0020000 413fc090 00000001 c00086b4 c000f804 60000053 ffffffff c07c9f9c
[ 82.421880] 9f60: c0803a20 c0011fc0 00000000 00000000 c07c9fb8 c001bee0 c07ca4f0 c057004c
[ 82.430040] 9f80: c07ca4fc c0803a20 c0803a20 413fc090 00000001 00000000 01000000 c07c9fb0
[ 82.438199] 9fa0: c000f800 c000f804 60000053 ffffffff 00000000 c0050e70 c0803bc0 c0783bd8
[ 82.446358] 9fc0: ffffffff ffffffff c0783664 00000000 00000000 c07b13e8 00000000 c0803e54
[ 82.454517] 9fe0: c07ca480 c07b13e4 c07ce40c 4000406a 00000000 40008074 00000000 00000000
[ 82.462689] [<c03510d4>] (composite_setup) from [<c0340890>] (s3c_hsotg_complete_setup+0xb4/0x418)
[ 82.471626] [<c0340890>] (s3c_hsotg_complete_setup) from [<c0354170>] (usb_gadget_giveback_request+0xc/0x10)
[ 82.481429] [<c0354170>] (usb_gadget_giveback_request) from [<c033db4c>] (s3c_hsotg_complete_request+0xcc/0x12c)
[ 82.491583] [<c033db4c>] (s3c_hsotg_complete_request) from [<c0341670>] (s3c_hsotg_irq+0x4fc/0x558)
[ 82.500614] [<c0341670>] (s3c_hsotg_irq) from [<c005d54c>] (handle_irq_event_percpu+0x50/0x150)
[ 82.509291] [<c005d54c>] (handle_irq_event_percpu) from [<c005d688>] (handle_irq_event+0x3c/0x5c)
[ 82.518145] [<c005d688>] (handle_irq_event) from [<c006009c>] (handle_fasteoi_irq+0xd4/0x18c)
[ 82.526650] [<c006009c>] (handle_fasteoi_irq) from [<c005ce20>] (generic_handle_irq+0x20/0x30)
[ 82.535242] [<c005ce20>] (generic_handle_irq) from [<c005cf34>] (__handle_domain_irq+0x6c/0xdc)
[ 82.543923] [<c005cf34>] (__handle_domain_irq) from [<c00086b4>] (gic_handle_irq+0x2c/0x6c)
[ 82.552256] [<c00086b4>] (gic_handle_irq) from [<c0011fc0>] (__irq_svc+0x40/0x74)
[ 82.559716] Exception stack(0xc07c9f68 to 0xc07c9fb0)
[ 82.564753] 9f60: 00000000 00000000 c07c9fb8 c001bee0 c07ca4f0 c057004c
[ 82.572913] 9f80: c07ca4fc c0803a20 c0803a20 413fc090 00000001 00000000 01000000 c07c9fb0
[ 82.581069] 9fa0: c000f800 c000f804 60000053 ffffffff
[ 82.586113] [<c0011fc0>] (__irq_svc) from [<c000f804>] (arch_cpu_idle+0x30/0x3c)
[ 82.593491] [<c000f804>] (arch_cpu_idle) from [<c0050e70>] (cpu_startup_entry+0x128/0x1a4)
[ 82.601740] [<c0050e70>] (cpu_startup_entry) from [<c0783bd8>] (start_kernel+0x350/0x3bc)
[ 82.609890] Code: 0a000002 e3530005 05975010 15975008 (e5953000)
[ 82.615965] ---[ end trace f57d5f599a5f1bfa ]---

Most of kernel code assume that interface array in
struct usb_configuration is NULL terminated.

When gadget is composed with configfs configuration
structure may be reused for different functions set.

This bug happens because purge_configs_funcs() sets
only next_interface_id to 0. Interface array still
contains pointers to already freed interfaces. If in
second try we add less interfaces than earlier we
may access unallocated memory when trying to get
interface descriptors.

Signed-off-by: Krzysztof Opasiak <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/configfs.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -757,6 +757,7 @@ static void purge_configs_funcs(struct g
}
}
c->next_interface_id = 0;
+ memset(c->interface, 0, sizeof(c->interface));
c->superspeed = 0;
c->highspeed = 0;
c->fullspeed = 0;

2015-06-03 11:53:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 30/46] powerpc: Align TOC to 256 bytes

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Anton Blanchard <[email protected]>

commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream.

Recent toolchains force the TOC to be 256 byte aligned. We need
to enforce this alignment in our linker script, otherwise pointers
to our TOC variables (__toc_start, __prom_init_toc_start) could
be incorrect.

If they are bad, we die a few hundred instructions into boot.

Signed-off-by: Anton Blanchard <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)

--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -213,6 +213,7 @@ SECTIONS
*(.opd)
}

+ . = ALIGN(256);
.got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
#ifndef CONFIG_RELOCATABLE

2015-06-03 11:45:45

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 31/46] mmc: atmel-mci: fix bad variable type for clkdiv

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ludovic Desroches <[email protected]>

commit 60c8f783a18feb95ad967c87e9660caf09fb4700 upstream.

clkdiv is declared as an u32 but it can be set to a negative value
causing a huge divisor value. Change its type to int to avoid this case.

Signed-off-by: Ludovic Desroches <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/mmc/host/atmel-mci.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -1295,7 +1295,7 @@ static void atmci_set_ios(struct mmc_hos

if (ios->clock) {
unsigned int clock_min = ~0U;
- u32 clkdiv;
+ int clkdiv;

spin_lock_bh(&host->lock);
if (!host->mode_reg) {
@@ -1320,7 +1320,12 @@ static void atmci_set_ios(struct mmc_hos
/* Calculate clock divider */
if (host->caps.has_odd_clk_div) {
clkdiv = DIV_ROUND_UP(host->bus_hz, clock_min) - 2;
- if (clkdiv > 511) {
+ if (clkdiv < 0) {
+ dev_warn(&mmc->class_dev,
+ "clock %u too fast; using %lu\n",
+ clock_min, host->bus_hz / 2);
+ clkdiv = 0;
+ } else if (clkdiv > 511) {
dev_warn(&mmc->class_dev,
"clock %u too slow; using %lu\n",
clock_min, host->bus_hz / (511 + 2));

2015-06-03 11:52:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 32/46] ext4: convert write_begin methods to stable_page_writes semantics

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Dmitry Monakhov <[email protected]>

commit 7afe5aa59ed3da7b6161617e7f157c7c680dc41e upstream.

Use wait_for_stable_page() instead of wait_on_page_writeback()

Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Cc: Alex Shi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/inode.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1032,7 +1032,8 @@ retry_journal:
ext4_journal_stop(handle);
goto retry_grab;
}
- wait_on_page_writeback(page);
+ /* In case writeback began while the page was unlocked */
+ wait_for_stable_page(page);

if (ext4_should_dioread_nolock(inode))
ret = __block_write_begin(page, pos, len, ext4_get_block_write);
@@ -2729,7 +2730,7 @@ retry_journal:
goto retry_grab;
}
/* In case writeback began while the page was unlocked */
- wait_on_page_writeback(page);
+ wait_for_stable_page(page);

ret = __block_write_begin(page, pos, len, ext4_da_get_block_prep);
if (ret < 0) {

2015-06-03 11:52:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 33/46] ext4: check for zero length extent explicitly

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Eryu Guan <[email protected]>

commit 2f974865ffdfe7b9f46a9940836c8b167342563d upstream.

The following commit introduced a bug when checking for zero length extent

5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()

Zero length extent could pass the check if lblock is zero.

Adding the explicit check for zero length back.

Signed-off-by: Eryu Guan <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/extents.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -363,7 +363,7 @@ static int ext4_valid_extent(struct inod
ext4_lblk_t lblock = le32_to_cpu(ext->ee_block);
ext4_lblk_t last = lblock + len - 1;

- if (lblock > last)
+ if (len == 0 || lblock > last)
return 0;
return ext4_data_block_valid(EXT4_SB(inode->i_sb), block, len);
}

2015-06-03 11:52:31

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 34/46] libata: Add helper to determine when PHY events should be ignored

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gabriele Mazzotta <[email protected]>

commit 8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/libahci.c | 3 +--
drivers/ata/libata-core.c | 19 +++++++++++++++++++
include/linux/libata.h | 1 +
3 files changed, 21 insertions(+), 2 deletions(-)

--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1684,8 +1684,7 @@ static void ahci_handle_port_interrupt(s
if (unlikely(resetting))
status &= ~PORT_IRQ_BAD_PMP;

- /* if LPM is enabled, PHYRDY doesn't mean anything */
- if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
+ if (sata_lpm_ignore_phy_events(&ap->link)) {
status &= ~PORT_IRQ_PHYRDY;
ahci_scr_write(&ap->link, SCR_ERROR, SERR_PHYRDY_CHG);
}
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6800,6 +6800,25 @@ u32 ata_wait_register(struct ata_port *a
return tmp;
}

+/**
+ * sata_lpm_ignore_phy_events - test if PHY event should be ignored
+ * @link: Link receiving the event
+ *
+ * Test whether the received PHY event has to be ignored or not.
+ *
+ * LOCKING:
+ * None:
+ *
+ * RETURNS:
+ * True if the event has to be ignored.
+ */
+bool sata_lpm_ignore_phy_events(struct ata_link *link)
+{
+ /* if LPM is enabled, PHYRDY doesn't mean anything */
+ return !!(link->lpm_policy > ATA_LPM_MAX_POWER);
+}
+EXPORT_SYMBOL_GPL(sata_lpm_ignore_phy_events);
+
/*
* Dummy port_ops
*/
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1085,6 +1085,7 @@ extern struct ata_device *ata_dev_pair(s
extern int ata_do_set_mode(struct ata_link *link, struct ata_device **r_failed_dev);
extern void ata_scsi_port_error_handler(struct Scsi_Host *host, struct ata_port *ap);
extern void ata_scsi_cmd_error_handler(struct Scsi_Host *host, struct ata_port *ap, struct list_head *eh_q);
+extern bool sata_lpm_ignore_phy_events(struct ata_link *link);

extern int ata_cable_40wire(struct ata_port *ap);
extern int ata_cable_80wire(struct ata_port *ap);

2015-06-03 11:45:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 35/46] libata: Ignore spurious PHY event on LPM policy change

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Gabriele Mazzotta <[email protected]>

commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/libata-core.c | 15 ++++++++++++++-
drivers/ata/libata-eh.c | 3 +++
include/linux/libata.h | 9 +++++++++
3 files changed, 26 insertions(+), 1 deletion(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6814,8 +6814,21 @@ u32 ata_wait_register(struct ata_port *a
*/
bool sata_lpm_ignore_phy_events(struct ata_link *link)
{
+ unsigned long lpm_timeout = link->last_lpm_change +
+ msecs_to_jiffies(ATA_TMOUT_SPURIOUS_PHY);
+
/* if LPM is enabled, PHYRDY doesn't mean anything */
- return !!(link->lpm_policy > ATA_LPM_MAX_POWER);
+ if (link->lpm_policy > ATA_LPM_MAX_POWER)
+ return true;
+
+ /* ignore the first PHY event after the LPM policy changed
+ * as it is might be spurious
+ */
+ if ((link->flags & ATA_LFLAG_CHANGED) &&
+ time_before(jiffies, lpm_timeout))
+ return true;
+
+ return false;
}
EXPORT_SYMBOL_GPL(sata_lpm_ignore_phy_events);

--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -3481,6 +3481,9 @@ static int ata_eh_set_lpm(struct ata_lin
}
}

+ link->last_lpm_change = jiffies;
+ link->flags |= ATA_LFLAG_CHANGED;
+
return 0;

fail:
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -187,6 +187,7 @@ enum {
ATA_LFLAG_SW_ACTIVITY = (1 << 7), /* keep activity stats */
ATA_LFLAG_NO_LPM = (1 << 8), /* disable LPM on this link */
ATA_LFLAG_RST_ONCE = (1 << 9), /* limit recovery to one reset */
+ ATA_LFLAG_CHANGED = (1 << 10), /* LPM state changed on this link */

/* struct ata_port flags */
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
@@ -289,6 +290,12 @@ enum {
*/
ATA_TMOUT_PMP_SRST_WAIT = 5000,

+ /* When the LPM policy is set to ATA_LPM_MAX_POWER, there might
+ * be a spurious PHY event, so ignore the first PHY event that
+ * occurs within 10s after the policy change.
+ */
+ ATA_TMOUT_SPURIOUS_PHY = 10000,
+
/* ATA bus states */
BUS_UNKNOWN = 0,
BUS_DMA = 1,
@@ -736,6 +743,8 @@ struct ata_link {
struct ata_eh_context eh_context;

struct ata_device device[ATA_MAX_DEVICES];
+
+ unsigned long last_lpm_change; /* when last LPM change happened */
};
#define ATA_LINK_CLEAR_BEGIN offsetof(struct ata_link, active_tag)
#define ATA_LINK_CLEAR_END offsetof(struct ata_link, device[0])

2015-06-03 11:45:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 36/46] rt2x00: add new rt2800usb device DWA 130

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Scott Branden <[email protected]>

commit ea345c145ff23197eab34d0c4d0c8a93d7bea8c6 upstream.

Add the USB Id to link the D-Link DWA 130 USB Wifi adapter
to the rt2830 driver.

Signed-off-by: Scott Branden <[email protected]>
Signed-off-by: Pieter Truter <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Cc: Larry Finger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1020,6 +1020,7 @@ static struct usb_device_id rt2800usb_de
{ USB_DEVICE(0x07d1, 0x3c16) },
{ USB_DEVICE(0x07d1, 0x3c17) },
{ USB_DEVICE(0x2001, 0x3c1b) },
+ { USB_DEVICE(0x2001, 0x3c25) },
/* Draytek */
{ USB_DEVICE(0x07fa, 0x7712) },
/* DVICO */

2015-06-03 11:46:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 37/46] crypto: s390/ghash - Fix incorrect ghash icv buffer handling.

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Harald Freudenberger <[email protected]>

commit a1cae34e23b1293eccbcc8ee9b39298039c3952a upstream.

Multitheaded tests showed that the icv buffer in the current ghash
implementation is not handled correctly. A move of this working ghash
buffer value to the descriptor context fixed this. Code is tested and
verified with an multithreaded application via af_alg interface.

Signed-off-by: Harald Freudenberger <[email protected]>
Signed-off-by: Gerald Schaefer <[email protected]>
Reported-by: Herbert Xu <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/s390/crypto/ghash_s390.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)

--- a/arch/s390/crypto/ghash_s390.c
+++ b/arch/s390/crypto/ghash_s390.c
@@ -16,11 +16,12 @@
#define GHASH_DIGEST_SIZE 16

struct ghash_ctx {
- u8 icv[16];
- u8 key[16];
+ u8 key[GHASH_BLOCK_SIZE];
};

struct ghash_desc_ctx {
+ u8 icv[GHASH_BLOCK_SIZE];
+ u8 key[GHASH_BLOCK_SIZE];
u8 buffer[GHASH_BLOCK_SIZE];
u32 bytes;
};
@@ -28,8 +29,10 @@ struct ghash_desc_ctx {
static int ghash_init(struct shash_desc *desc)
{
struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
+ struct ghash_ctx *ctx = crypto_shash_ctx(desc->tfm);

memset(dctx, 0, sizeof(*dctx));
+ memcpy(dctx->key, ctx->key, GHASH_BLOCK_SIZE);

return 0;
}
@@ -45,7 +48,6 @@ static int ghash_setkey(struct crypto_sh
}

memcpy(ctx->key, key, GHASH_BLOCK_SIZE);
- memset(ctx->icv, 0, GHASH_BLOCK_SIZE);

return 0;
}
@@ -54,7 +56,6 @@ static int ghash_update(struct shash_des
const u8 *src, unsigned int srclen)
{
struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- struct ghash_ctx *ctx = crypto_shash_ctx(desc->tfm);
unsigned int n;
u8 *buf = dctx->buffer;
int ret;
@@ -70,7 +71,7 @@ static int ghash_update(struct shash_des
src += n;

if (!dctx->bytes) {
- ret = crypt_s390_kimd(KIMD_GHASH, ctx, buf,
+ ret = crypt_s390_kimd(KIMD_GHASH, dctx, buf,
GHASH_BLOCK_SIZE);
if (ret != GHASH_BLOCK_SIZE)
return -EIO;
@@ -79,7 +80,7 @@ static int ghash_update(struct shash_des

n = srclen & ~(GHASH_BLOCK_SIZE - 1);
if (n) {
- ret = crypt_s390_kimd(KIMD_GHASH, ctx, src, n);
+ ret = crypt_s390_kimd(KIMD_GHASH, dctx, src, n);
if (ret != n)
return -EIO;
src += n;
@@ -94,7 +95,7 @@ static int ghash_update(struct shash_des
return 0;
}

-static int ghash_flush(struct ghash_ctx *ctx, struct ghash_desc_ctx *dctx)
+static int ghash_flush(struct ghash_desc_ctx *dctx)
{
u8 *buf = dctx->buffer;
int ret;
@@ -104,24 +105,24 @@ static int ghash_flush(struct ghash_ctx

memset(pos, 0, dctx->bytes);

- ret = crypt_s390_kimd(KIMD_GHASH, ctx, buf, GHASH_BLOCK_SIZE);
+ ret = crypt_s390_kimd(KIMD_GHASH, dctx, buf, GHASH_BLOCK_SIZE);
if (ret != GHASH_BLOCK_SIZE)
return -EIO;
+
+ dctx->bytes = 0;
}

- dctx->bytes = 0;
return 0;
}

static int ghash_final(struct shash_desc *desc, u8 *dst)
{
struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
- struct ghash_ctx *ctx = crypto_shash_ctx(desc->tfm);
int ret;

- ret = ghash_flush(ctx, dctx);
+ ret = ghash_flush(dctx);
if (!ret)
- memcpy(dst, ctx->icv, GHASH_BLOCK_SIZE);
+ memcpy(dst, dctx->icv, GHASH_BLOCK_SIZE);
return ret;
}


2015-06-03 11:50:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 39/46] ARM: fix missing syscall trace exit

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Russell King <[email protected]>

commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

I've discovered a case where both arm and arm64 will miss a ptrace
syscall-exit that they should report. If the syscall is entered
without TIF_SYSCALL_TRACE set, then it goes on the fast path. It's
then possible to have TIF_SYSCALL_TRACE added in the middle of the
syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm/kernel/entry-common.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -32,7 +32,9 @@ ret_fast_syscall:
UNWIND(.fnstart )
UNWIND(.cantunwind )
disable_irq @ disable interrupts
- ldr r1, [tsk, #TI_FLAGS]
+ ldr r1, [tsk, #TI_FLAGS] @ re-check for syscall tracing
+ tst r1, #_TIF_SYSCALL_WORK
+ bne __sys_trace_return
tst r1, #_TIF_WORK_MASK
bne fast_work_pending
asm_trace_hardirqs_on

2015-06-03 11:50:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 40/46] svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Scott Mayhew <[email protected]>

commit 9507271d960a1911a51683888837d75c171cd91f upstream.

In an environment where the KDC is running Active Directory, the
exported composite name field returned in the context could be large
enough to span a page boundary. Attaching a scratch buffer to the
decoding xdr_stream helps deal with those cases.

The case where we saw this was actually due to behavior that's been
fixed in newer gss-proxy versions, but we're fixing it here too.

Signed-off-by: Scott Mayhew <[email protected]>
Reviewed-by: Simo Sorce <[email protected]>
Signed-off-by: J. Bruce Fields <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
net/sunrpc/auth_gss/gss_rpc_xdr.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)

--- a/net/sunrpc/auth_gss/gss_rpc_xdr.c
+++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c
@@ -794,20 +794,26 @@ int gssx_dec_accept_sec_context(struct r
{
u32 value_follows;
int err;
+ struct page *scratch;
+
+ scratch = alloc_page(GFP_KERNEL);
+ if (!scratch)
+ return -ENOMEM;
+ xdr_set_scratch_buffer(xdr, page_address(scratch), PAGE_SIZE);

/* res->status */
err = gssx_dec_status(xdr, &res->status);
if (err)
- return err;
+ goto out_free;

/* res->context_handle */
err = gssx_dec_bool(xdr, &value_follows);
if (err)
- return err;
+ goto out_free;
if (value_follows) {
err = gssx_dec_ctx(xdr, res->context_handle);
if (err)
- return err;
+ goto out_free;
} else {
res->context_handle = NULL;
}
@@ -815,11 +821,11 @@ int gssx_dec_accept_sec_context(struct r
/* res->output_token */
err = gssx_dec_bool(xdr, &value_follows);
if (err)
- return err;
+ goto out_free;
if (value_follows) {
err = gssx_dec_buffer(xdr, res->output_token);
if (err)
- return err;
+ goto out_free;
} else {
res->output_token = NULL;
}
@@ -827,14 +833,17 @@ int gssx_dec_accept_sec_context(struct r
/* res->delegated_cred_handle */
err = gssx_dec_bool(xdr, &value_follows);
if (err)
- return err;
+ goto out_free;
if (value_follows) {
/* we do not support upcall servers sending this data. */
- return -EINVAL;
+ err = -EINVAL;
+ goto out_free;
}

/* res->options */
err = gssx_dec_option_array(xdr, &res->options);

+out_free:
+ __free_page(scratch);
return err;
}

2015-06-03 11:49:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 41/46] md/raid5: dont record new size if resize_stripes fails.

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: NeilBrown <[email protected]>

commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream.

If any memory allocation in resize_stripes fails we will return
-ENOMEM, but in some cases we update conf->pool_size anyway.

This means that if we try again, the allocations will be assumed
to be larger than they are, and badness results.

So only update pool_size if there is no error.

This bug was introduced in 2.6.17 and the patch is suitable for
-stable.

Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array")
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/raid5.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1701,7 +1701,8 @@ static int resize_stripes(struct r5conf

conf->slab_cache = sc;
conf->active_name = 1-conf->active_name;
- conf->pool_size = newsize;
+ if (!err)
+ conf->pool_size = newsize;
return err;
}


2015-06-03 11:47:07

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 42/46] rtlwifi: rtl8192cu: Fix kernel deadlock

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Larry Finger <[email protected]>

commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.

The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In some instances where the
interface is shutting down, this infinite wait results in a CPU deadlock. A
one second timeout fixes this problem without affecting any normal operations.

This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786.

Reported-by: Bernhard Wiedemann <[email protected]>
Tested-by: Bernhard Wiedemann <[email protected]>
Signed-off-by: Larry Finger <[email protected]>
Cc: Bernhard Wiedemann <[email protected]>
Cc: Takashi Iwai<[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/rtlwifi/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -119,7 +119,7 @@ static int _usbctrl_vendorreq_sync_read(

do {
status = usb_control_msg(udev, pipe, request, reqtype, value,
- index, pdata, len, 0); /*max. timeout*/
+ index, pdata, len, 1000);
if (status < 0) {
/* firmware download is checksumed, don't retry */
if ((value >= FW_8192C_START_ADDRESS &&

2015-06-03 11:47:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 43/46] Input: elantech - fix semi-mt protocol for v3 HW

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Benjamin Tissoires <[email protected]>

commit 3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream.

When the v3 hardware sees more than one finger, it uses the semi-mt
protocol to report the touches. However, it currently works when
num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1
finger as if num_fingers was 1.

This confuses userspace which knows how to deal with extra fingers
when all the slots are used, but not when some are missing.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101

Signed-off-by: Benjamin Tissoires <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/input/mouse/elantech.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -314,7 +314,7 @@ static void elantech_report_semi_mt_data
unsigned int x2, unsigned int y2)
{
elantech_set_slot(dev, 0, num_fingers != 0, x1, y1);
- elantech_set_slot(dev, 1, num_fingers == 2, x2, y2);
+ elantech_set_slot(dev, 1, num_fingers >= 2, x2, y2);
}

/*

2015-06-03 11:49:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 44/46] ACPI / init: Fix the ordering of acpi_reserve_resources()

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Rafael J. Wysocki" <[email protected]>

commit b9a5e5e18fbf223502c0b2264c15024e393da928 upstream.

Since acpi_reserve_resources() is defined as a device_initcall(),
there's no guarantee that it will be executed in the right order
with respect to the rest of the ACPI initialization code. On some
systems this leads to breakage if, for example, the address range
that should be reserved for the ACPI fixed registers is given to
the PCI host bridge instead if the race is won by the wrong code
path.

Fix this by turning acpi_reserve_resources() into a void function
and calling it directly from within the ACPI initialization sequence.

Reported-and-tested-by: George McCollister <[email protected]>
Link: http://marc.info/?t=143092384600002&r=1&w=2
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/osl.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -173,7 +173,7 @@ static void __init acpi_request_region (
request_mem_region(addr, length, desc);
}

-static int __init acpi_reserve_resources(void)
+static void __init acpi_reserve_resources(void)
{
acpi_request_region(&acpi_gbl_FADT.xpm1a_event_block, acpi_gbl_FADT.pm1_event_length,
"ACPI PM1a_EVT_BLK");
@@ -202,10 +202,7 @@ static int __init acpi_reserve_resources
if (!(acpi_gbl_FADT.gpe1_block_length & 0x1))
acpi_request_region(&acpi_gbl_FADT.xgpe1_block,
acpi_gbl_FADT.gpe1_block_length, "ACPI GPE1_BLK");
-
- return 0;
}
-device_initcall(acpi_reserve_resources);

void acpi_os_printf(const char *fmt, ...)
{
@@ -1727,6 +1724,7 @@ acpi_status __init acpi_os_initialize(vo

acpi_status __init acpi_os_initialize1(void)
{
+ acpi_reserve_resources();
kacpid_wq = alloc_workqueue("kacpid", 0, 1);
kacpi_notify_wq = alloc_workqueue("kacpi_notify", 0, 1);
kacpi_hotplug_wq = alloc_workqueue("kacpi_hotplug", 0, 1);

2015-06-03 11:49:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 45/46] vfs: read file_handle only once in handle_to_path

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Sasha Levin <[email protected]>

commit 161f873b89136eb1e69477c847d5a5033239d9ba upstream.

We used to read file_handle twice. Once to get the amount of extra
bytes, and once to fetch the entire structure.

This may be problematic since we do size verifications only after the
first read, so if the number of extra bytes changes in userspace between
the first and second calls, we'll have an incoherent view of
file_handle.

Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.

Signed-off-by: Sasha Levin <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/fhandle.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/fs/fhandle.c
+++ b/fs/fhandle.c
@@ -195,8 +195,9 @@ static int handle_to_path(int mountdirfd
goto out_err;
}
/* copy the full handle */
- if (copy_from_user(handle, ufh,
- sizeof(struct file_handle) +
+ *handle = f_handle;
+ if (copy_from_user(&handle->f_handle,
+ &ufh->f_handle,
f_handle.handle_bytes)) {
retval = -EFAULT;
goto out_handle;

2015-06-03 11:49:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.10 46/46] fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

3.10-stable review patch. If anyone has any objections, please let me know.

------------------

From: Andrew Morton <[email protected]>

commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.

load_elf_binary() returns `retval', not `error'.

Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan <[email protected]>
Cc: Michael Davidson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/binfmt_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -824,7 +824,7 @@ static int load_elf_binary(struct linux_
total_size = total_mapping_size(elf_phdata,
loc->elf_ex.e_phnum);
if (!total_size) {
- error = -EINVAL;
+ retval = -EINVAL;
goto out_free_dentry;
}
}

2015-06-03 16:53:03

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 3.10 00/46] 3.10.80-stable review

On 06/03/2015 05:42 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.80 release.
> There are 46 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 Fri Jun 5 06:33:14 UTC 2015.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.10.80-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

-- Shuah


--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978

2015-06-03 18:14:19

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.10 00/46] 3.10.80-stable review

On Wed, Jun 03, 2015 at 08:42:38PM +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.80 release.
> There are 46 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 Fri Jun 5 06:33:14 UTC 2015.
> Anything received after that time might be too late.
>
Build results:
total: 116 pass: 115 fail: 1
Failed builds:
s390:allmodconfig

Qemu test results:
total: 27 pass: 27 fail: 0

Results are as expected.
Details are available at http://server.roeck-us.net:8010/builders.

Guenter

2015-06-06 15:02:07

by Jari Ruusu

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

My understanding is that this patch is trying to fix bugs in this commit:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.10.y&id=5f03ac13d87590b0ee879c77e68df63a3d9b3e07

The 3.10.y branch applied the original patch to three different places.
Quote from original commit: "As we only have try_to_ascend() and not
d_walk(), apply this change to all callers of try_to_ascend()"

Shouldn't this "d_walk() might skip too much" fix to 3.10.y branch be
applied to all three places too?

--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

2015-06-13 16:01:43

by Jari Ruusu

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu <[email protected]>

--- linux-3.10.80/fs/dcache.c.OLD 2015-06-11 19:22:31.000000000 +0300
+++ linux-3.10.80/fs/dcache.c 2015-06-11 19:32:59.000000000 +0300
@@ -1053,13 +1053,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == &this_parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
@@ -2977,13 +2977,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == &this_parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}

--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

2015-06-13 17:11:39

by Willy Tarreau

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

Hi Jari,

On Sat, Jun 13, 2015 at 07:01:31PM +0300, Jari Ruusu wrote:
> When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
> backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
> was copied to 3 different places. Later, a bug in that code was discovered.
> Al Viro's fix involved fixing only one part of code in mainline kernel. That
> fix is called "d_walk() might skip too much".
>
> 3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
> different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
> too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
> fix.
>
> The patch below was not written by me. I only applied Al Viro's "d_walk()
> might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
> the fixes went to correct places. With this patch applied, all 3 places that
> I am aware of 3.10.y stable branch are now fixed.
>
> Signed-off-by: Jari Ruusu <[email protected]>

Next time, please don't forget to mention the mainline commit IDs in
addition to the message subjects, it helps a lot. The IDs from the
stable branches are less important since it's generally quite easy
to find them thanks to the mainline ID which appears in the message.
Just for reference :

- ca5358e ("deal with deadlock in d_walk()")
- 2159184 ("d_walk() might skip too much")

Thanks,
Willy

2015-06-19 19:54:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

On Sat, Jun 13, 2015 at 07:11:18PM +0200, Willy Tarreau wrote:
> Hi Jari,
>
> On Sat, Jun 13, 2015 at 07:01:31PM +0300, Jari Ruusu wrote:
> > When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
> > backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
> > was copied to 3 different places. Later, a bug in that code was discovered.
> > Al Viro's fix involved fixing only one part of code in mainline kernel. That
> > fix is called "d_walk() might skip too much".
> >
> > 3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
> > different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
> > too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
> > fix.
> >
> > The patch below was not written by me. I only applied Al Viro's "d_walk()
> > might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
> > the fixes went to correct places. With this patch applied, all 3 places that
> > I am aware of 3.10.y stable branch are now fixed.
> >
> > Signed-off-by: Jari Ruusu <[email protected]>
>
> Next time, please don't forget to mention the mainline commit IDs in
> addition to the message subjects, it helps a lot. The IDs from the
> stable branches are less important since it's generally quite easy
> to find them thanks to the mainline ID which appears in the message.
> Just for reference :
>
> - ca5358e ("deal with deadlock in d_walk()")
> - 2159184 ("d_walk() might skip too much")

I would much rather just include the "real" upstream patches, instead of
an odd backport.

Jari, can you just backport the above referenced patches instead and
provide those backports?

thanks,

greg k-h

2015-06-20 07:41:24

by Jari Ruusu

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

On 6/19/15, Greg Kroah-Hartman <[email protected]> wrote:
> I would much rather just include the "real" upstream patches, instead of
> an odd backport.
>
> Jari, can you just backport the above referenced patches instead and
> provide those backports?

I won't do that, sorry. It is more complicated than you think. It would
involve backporting more VFS-re-write-patch-bombs than would be acceptable
to stable kernel branch. Above mentioned d_walk() function that Al Viro
modified in mainline don't even exist in 3.10.y and older brances.

My understanding is that complete backport of above mentioned "deal with
deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
branch is to apply all these patches:

(a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
(b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
(c) Al Viro's "d_walk() might skip too much" applied THREE times.

Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
3.10.80 stable.

The problem is that you didn't realize that "deal with deadlock in d_walk()"
was applied to three different places in Ben Hutchings' backport, and that
latest Al Viro's fix had to be also applied to three different places.
Considering the sh*t that you have to deal with, nobody is blaming you for
that mistake.

I am asking that you apply Al Viro's original "d_walk() might skip too much"
patch TWO more times to 3.10.y stable branch. On both times, your patch tool
will find the correct place of source file to modify, but with different
offsets each time.

--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

2015-06-27 00:52:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> On 6/19/15, Greg Kroah-Hartman <[email protected]> wrote:
> > I would much rather just include the "real" upstream patches, instead of
> > an odd backport.
> >
> > Jari, can you just backport the above referenced patches instead and
> > provide those backports?
>
> I won't do that, sorry. It is more complicated than you think. It would
> involve backporting more VFS-re-write-patch-bombs than would be acceptable
> to stable kernel branch. Above mentioned d_walk() function that Al Viro
> modified in mainline don't even exist in 3.10.y and older brances.
>
> My understanding is that complete backport of above mentioned "deal with
> deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> branch is to apply all these patches:
>
> (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> (c) Al Viro's "d_walk() might skip too much" applied THREE times.
>
> Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> 3.10.80 stable.
>
> The problem is that you didn't realize that "deal with deadlock in d_walk()"
> was applied to three different places in Ben Hutchings' backport, and that
> latest Al Viro's fix had to be also applied to three different places.
> Considering the sh*t that you have to deal with, nobody is blaming you for
> that mistake.
>
> I am asking that you apply Al Viro's original "d_walk() might skip too much"
> patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> will find the correct place of source file to modify, but with different
> offsets each time.

That's insane, and not how my tools work :(

Can you provide the needed backport? If it was in an earlier email in
this series, sorry, it's long gone from my mailbox, can you resend it?

thanks,

greg k-h

2015-06-27 05:56:39

by Willy Tarreau

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

On Fri, Jun 26, 2015 at 05:52:16PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> > On 6/19/15, Greg Kroah-Hartman <[email protected]> wrote:
> > > I would much rather just include the "real" upstream patches, instead of
> > > an odd backport.
> > >
> > > Jari, can you just backport the above referenced patches instead and
> > > provide those backports?
> >
> > I won't do that, sorry. It is more complicated than you think. It would
> > involve backporting more VFS-re-write-patch-bombs than would be acceptable
> > to stable kernel branch. Above mentioned d_walk() function that Al Viro
> > modified in mainline don't even exist in 3.10.y and older brances.
> >
> > My understanding is that complete backport of above mentioned "deal with
> > deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> > branch is to apply all these patches:
> >
> > (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> > (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> > (c) Al Viro's "d_walk() might skip too much" applied THREE times.
> >
> > Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> > 3.10.80 stable.
> >
> > The problem is that you didn't realize that "deal with deadlock in d_walk()"
> > was applied to three different places in Ben Hutchings' backport, and that
> > latest Al Viro's fix had to be also applied to three different places.
> > Considering the sh*t that you have to deal with, nobody is blaming you for
> > that mistake.
> >
> > I am asking that you apply Al Viro's original "d_walk() might skip too much"
> > patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> > will find the correct place of source file to modify, but with different
> > offsets each time.
>
> That's insane, and not how my tools work :(

No but I think it's just the patch command who found the proper location
because the context was identical. That's what happens to me all the time
with very old kernels, which is the reason why I must absolutely build
them before the preview otherwise I'm sure to deliver something that
doesn't even build :-)

> Can you provide the needed backport? If it was in an earlier email in
> this series, sorry, it's long gone from my mailbox, can you resend it?

Yes it was in the thread earlier this month. I'm appending it below. The
following commits were referred to :
- ca5358e ("deal with deadlock in d_walk()")
- 2159184 ("d_walk() might skip too much")

Regards,
Willy

Date: Sat, 13 Jun 2015 19:01:31 +0300
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much
From: Jari Ruusu <[email protected]>

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu <[email protected]>

--- linux-3.10.80/fs/dcache.c.OLD 2015-06-11 19:22:31.000000000 +0300
+++ linux-3.10.80/fs/dcache.c 2015-06-11 19:32:59.000000000 +0300
@@ -1053,13 +1053,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == &this_parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}
@@ -2977,13 +2977,13 @@
/* might go back up the wrong parent if we have had a rename. */
if (!locked && read_seqretry(&rename_lock, seq))
goto rename_retry;
- next = child->d_child.next;
- while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+ /* go into the first sibling still alive */
+ do {
+ next = child->d_child.next;
if (next == &this_parent->d_subdirs)
goto ascend;
child = list_entry(next, struct dentry, d_child);
- next = next->next;
- }
+ } while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
rcu_read_unlock();
goto resume;
}

2015-06-28 08:57:05

by Jari Ruusu

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

On 6/27/15, Greg Kroah-Hartman <[email protected]> wrote:
> That's insane, and not how my tools work :(

I asked you to do that apply-patch-two-more-times thing because I
assumed that you trust Al Viro's Signed-off-by more than you trust
my Signed-off-by.

> Can you provide the needed backport? If it was in an earlier email in
> this series, sorry, it's long gone from my mailbox, can you resend it?

Willy Tarreau re-posted that patch to you yesterday.
No need for me to repeat that here.

--
Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

2015-06-30 00:37:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much

On Sat, Jun 27, 2015 at 07:56:19AM +0200, Willy Tarreau wrote:
> On Fri, Jun 26, 2015 at 05:52:16PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> > > On 6/19/15, Greg Kroah-Hartman <[email protected]> wrote:
> > > > I would much rather just include the "real" upstream patches, instead of
> > > > an odd backport.
> > > >
> > > > Jari, can you just backport the above referenced patches instead and
> > > > provide those backports?
> > >
> > > I won't do that, sorry. It is more complicated than you think. It would
> > > involve backporting more VFS-re-write-patch-bombs than would be acceptable
> > > to stable kernel branch. Above mentioned d_walk() function that Al Viro
> > > modified in mainline don't even exist in 3.10.y and older brances.
> > >
> > > My understanding is that complete backport of above mentioned "deal with
> > > deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> > > branch is to apply all these patches:
> > >
> > > (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> > > (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> > > (c) Al Viro's "d_walk() might skip too much" applied THREE times.
> > >
> > > Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> > > 3.10.80 stable.
> > >
> > > The problem is that you didn't realize that "deal with deadlock in d_walk()"
> > > was applied to three different places in Ben Hutchings' backport, and that
> > > latest Al Viro's fix had to be also applied to three different places.
> > > Considering the sh*t that you have to deal with, nobody is blaming you for
> > > that mistake.
> > >
> > > I am asking that you apply Al Viro's original "d_walk() might skip too much"
> > > patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> > > will find the correct place of source file to modify, but with different
> > > offsets each time.
> >
> > That's insane, and not how my tools work :(
>
> No but I think it's just the patch command who found the proper location
> because the context was identical. That's what happens to me all the time
> with very old kernels, which is the reason why I must absolutely build
> them before the preview otherwise I'm sure to deliver something that
> doesn't even build :-)
>
> > Can you provide the needed backport? If it was in an earlier email in
> > this series, sorry, it's long gone from my mailbox, can you resend it?
>
> Yes it was in the thread earlier this month. I'm appending it below. The
> following commits were referred to :
> - ca5358e ("deal with deadlock in d_walk()")
> - 2159184 ("d_walk() might skip too much")

Ok, that's a mess, thanks for clearing it up for me, I've now included
this in the 3.10-stable kernel.

greg k-h