[PATCH 4.4 082/160] arm64: dts: stratix10: Correct System Manager register size
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Thor Thayer
commit 74121b9aa3cd571ddfff014a9f47db36cae3cda9 upstream.
Correct the register size of the System Manager node.
Cc: sta...@vger.kernel.org
Fixes: 78cd6a9d8e154 ("arm64: dts: Add base stratix 10 dtsi")
Signed-off-by: Thor Thayer
Signed-off-by: Dinh Nguyen
Signed-off-by: Greg Kroah-Hartman
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -249,7 +249,7 @@
sysmgr: sysmgr@ffd12000 {
compatible = "altr,sys-mgr", "syscon";
- reg = <0xffd12000 0x1000>;
+ reg = <0xffd12000 0x228>;
};
/* Local timer */
[PATCH 4.4 079/160] media: em28xx: make v4l2-compliance happier by starting sequence on zero
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Mauro Carvalho Chehab
commit afeaade90db4c5dab93f326d9582be1d5954a198 upstream.
The v4l2-compliance tool complains if a video doesn't start
with a zero sequence number.
While this shouldn't cause any real problem for apps, let's
make it happier, in order to better check the v4l2-compliance
differences before and after patchsets.
This is actually an old issue. It is there since at least its
videobuf2 conversion, e. g. changeset 3829fadc461 ("[media]
em28xx: convert to videobuf2"), if VB1 wouldn't suffer from
the same issue.
Cc: sta...@vger.kernel.org
Fixes: d3829fadc461 ("[media] em28xx: convert to videobuf2")
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/usb/em28xx/em28xx-video.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1149,6 +1149,8 @@ static void em28xx_ctrl_notify(struct v4
{
struct em28xx *dev = priv;
+ dev->v4l2->field_count = 0;
+
/*
* In the case of non-AC97 volume controls, we still need
* to do some setups at em28xx, in order to mute/unmute
[PATCH 4.4 080/160] ext4: avoid running out of journal credits when appending to an inline file
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
commit 8bc1379b82b8e809eef77a9fedbb75c6c297be19 upstream.
Use a separate journal transaction if it turns out that we need to
convert an inline file to use an data block. Otherwise we could end
up failing due to not having journal credits.
This addresses CVE-2018-10883.
https://bugzilla.kernel.org/show_bug.cgi?id=200071
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org
[fe...@google.com: 4.4 backport: adjust context]
Signed-off-by: Chenbo Feng
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ext4.h |3 ---
fs/ext4/inline.c | 38 +-
fs/ext4/xattr.c | 18 ++
3 files changed, 3 insertions(+), 56 deletions(-)
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3039,9 +3039,6 @@ extern struct buffer_head *ext4_get_firs
extern int ext4_inline_data_fiemap(struct inode *inode,
struct fiemap_extent_info *fieinfo,
int *has_inline, __u64 start, __u64 len);
-extern int ext4_try_to_evict_inline_data(handle_t *handle,
-struct inode *inode,
-int needed);
extern void ext4_inline_data_truncate(struct inode *inode, int *has_inline);
extern int ext4_convert_inline_data(struct inode *inode);
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -888,11 +888,11 @@ retry_journal:
flags |= AOP_FLAG_NOFS;
if (ret == -ENOSPC) {
+ ext4_journal_stop(handle);
ret = ext4_da_convert_inline_data_to_extent(mapping,
inode,
flags,
fsdata);
- ext4_journal_stop(handle);
if (ret == -ENOSPC &&
ext4_should_retry_alloc(inode->i_sb, &retries))
goto retry_journal;
@@ -1867,42 +1867,6 @@ out:
return (error < 0 ? error : 0);
}
-/*
- * Called during xattr set, and if we can sparse space 'needed',
- * just create the extent tree evict the data to the outer block.
- *
- * We use jbd2 instead of page cache to move data to the 1st block
- * so that the whole transaction can be committed as a whole and
- * the data isn't lost because of the delayed page cache write.
- */
-int ext4_try_to_evict_inline_data(handle_t *handle,
- struct inode *inode,
- int needed)
-{
- int error;
- struct ext4_xattr_entry *entry;
- struct ext4_inode *raw_inode;
- struct ext4_iloc iloc;
-
- error = ext4_get_inode_loc(inode, &iloc);
- if (error)
- return error;
-
- raw_inode = ext4_raw_inode(&iloc);
- entry = (struct ext4_xattr_entry *)((void *)raw_inode +
- EXT4_I(inode)->i_inline_off);
- if (EXT4_XATTR_LEN(entry->e_name_len) +
- EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size)) < needed) {
- error = -ENOSPC;
- goto out;
- }
-
- error = ext4_convert_inline_data_nolock(handle, inode, &iloc);
-out:
- brelse(iloc.bh);
- return error;
-}
-
void ext4_inline_data_truncate(struct inode *inode, int *has_inline)
{
handle_t *handle;
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1044,22 +1044,8 @@ int ext4_xattr_ibody_inline_set(handle_t
if (EXT4_I(inode)->i_extra_isize == 0)
return -ENOSPC;
error = ext4_xattr_set_entry(i, s, inode);
- if (error) {
- if (error == -ENOSPC &&
- ext4_has_inline_data(inode)) {
- error = ext4_try_to_evict_inline_data(handle, inode,
- EXT4_XATTR_LEN(strlen(i->name) +
- EXT4_XATTR_SIZE(i->value_len)));
- if (error)
- return error;
- error = ext4_xattr_ibody_find(inode, i, is);
- if (error)
- return error;
- error = ext4_xattr_set_entry(i, s, inode);
- }
- if (error)
- return error;
- }
+ if (error)
+ return error;
header = IHDR(inode, ext4_raw_inode(&is->iloc));
if (!IS_LAST_ENTRY(s->first)) {
header->h_magic = cpu_to_le32(EXT4_XATTR_MAGIC);
[PATCH 4.4 081/160] Cramfs: fix abad comparison when wrap-arounds occur
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Nicolas Pitre commit 672ca9dd13f1aca0c17516f76fc5b0e8344b3e46 upstream. It is possible for corrupted filesystem images to produce very large block offsets that may wrap when a length is added, and wrongly pass the buffer size test. Reported-by: Anatoly Trosinenko Signed-off-by: Nicolas Pitre Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/cramfs/inode.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/cramfs/inode.c +++ b/fs/cramfs/inode.c @@ -185,7 +185,8 @@ static void *cramfs_read(struct super_bl continue; blk_offset = (blocknr - buffer_blocknr[i]) << PAGE_CACHE_SHIFT; blk_offset += offset; - if (blk_offset + len > BUFFER_SIZE) + if (blk_offset > BUFFER_SIZE || + blk_offset + len > BUFFER_SIZE) continue; return read_buffers[i] + blk_offset; }
[PATCH 4.4 065/160] smb3: on kerberos mount if server doesnt specify auth type use krb5
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit 926674de6705f0f1dbf29a62fd758d0977f535d6 upstream.
Some servers (e.g. Azure) do not include a spnego blob in the SMB3
negotiate protocol response, so on kerberos mounts ("sec=krb5")
we can fail, as we expected the server to list its supported
auth types (OIDs in the spnego blob in the negprot response).
Change this so that on krb5 mounts we default to trying krb5 if the
server doesn't list its supported protocol mechanisms.
Signed-off-by: Steve French
Reviewed-by: Ronnie Sahlberg
CC: Stable
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/cifs_spnego.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/cifs/cifs_spnego.c
+++ b/fs/cifs/cifs_spnego.c
@@ -143,8 +143,10 @@ cifs_get_spnego_key(struct cifs_ses *ses
sprintf(dp, ";sec=krb5");
else if (server->sec_mskerberos)
sprintf(dp, ";sec=mskrb5");
- else
- goto out;
+ else {
+ cifs_dbg(VFS, "unknown or missing server auth type, use
krb5\n");
+ sprintf(dp, ";sec=krb5");
+ }
dp = description + strlen(description);
sprintf(dp, ";uid=0x%x",
[PATCH 4.4 077/160] media: em28xx: use a default format if TRY_FMT fails
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Mauro Carvalho Chehab
commit f823ce2a1202d47110a7ef86b65839f0be8adc38 upstream.
Follow the V4L2 spec, as warned by v4l2-compliance:
warn: v4l2-test-formats.cpp(732): TRY_FMT cannot handle an invalid
pixelformat.
warn: v4l2-test-formats.cpp(733): This may or may not be a problem. For
more information see:
warn: v4l2-test-formats.cpp(734):
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html
Cc: sta...@vger.kernel.org
Fixes: bddcf63313c6 ("V4L/DVB (9927): em28xx: use a more standard way to
specify video formats")
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman
---
drivers/media/usb/em28xx/em28xx-video.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1288,9 +1288,9 @@ static int vidioc_try_fmt_vid_cap(struct
fmt = format_by_fourcc(f->fmt.pix.pixelformat);
if (!fmt) {
- em28xx_videodbg("Fourcc format (%08x) invalid.\n",
- f->fmt.pix.pixelformat);
- return -EINVAL;
+ fmt = &format[0];
+ em28xx_videodbg("Fourcc format (%08x) invalid. Using default
(%08x).\n",
+ f->fmt.pix.pixelformat, fmt->fourcc);
}
if (dev->board.is_em2800) {
[PATCH 4.4 075/160] kgdboc: Passing ekgdboc to command line causes panic
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: He Zhe
commit 1bd54d851f50dea6af30c3e6ff4f3e9aab5558f9 upstream.
kgdboc_option_setup does not check input argument before passing it
to strlen. The argument would be a NULL pointer if "ekgdboc", without
its value, is set in command line and thus cause the following panic.
PANIC: early exception 0xe3 IP 10:8fbbb620 error 0 cr2 0x0
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #1
[0.00] RIP: 0010:strlen+0x0/0x20
...
[0.00] Call Trace
[0.00] ? kgdboc_option_setup+0x9/0xa0
[0.00] ? kgdboc_early_init+0x6/0x1b
[0.00] ? do_early_param+0x4d/0x82
[0.00] ? parse_args+0x212/0x330
[0.00] ? rdinit_setup+0x26/0x26
[0.00] ? parse_early_options+0x20/0x23
[0.00] ? rdinit_setup+0x26/0x26
[0.00] ? parse_early_param+0x2d/0x39
[0.00] ? setup_arch+0x2f7/0xbf4
[0.00] ? start_kernel+0x5e/0x4c2
[0.00] ? load_ucode_bsp+0x113/0x12f
[0.00] ? secondary_startup_64+0xa5/0xb0
This patch adds a check to prevent the panic.
Cc: sta...@vger.kernel.org
Cc: jason.wes...@windriver.com
Cc: gre...@linuxfoundation.org
Cc: jsl...@suse.com
Signed-off-by: He Zhe
Reviewed-by: Daniel Thompson
Signed-off-by: Greg Kroah-Hartman
---
drivers/tty/serial/kgdboc.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/tty/serial/kgdboc.c
+++ b/drivers/tty/serial/kgdboc.c
@@ -133,6 +133,11 @@ static void kgdboc_unregister_kbd(void)
static int kgdboc_option_setup(char *opt)
{
+ if (!opt) {
+ pr_err("kgdboc: config string not provided\n");
+ return -EINVAL;
+ }
+
if (strlen(opt) >= MAX_CONFIG_LEN) {
printk(KERN_ERR "kgdboc: config string too long\n");
return -ENOSPC;
[PATCH 4.4 074/160] TC: Set DMA masks for devices
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Maciej W. Rozycki
commit 3f2aa244ee1a0d17ed5b6c86564d2c1b24d1c96b upstream.
Fix a TURBOchannel support regression with commit 205e1b7f51e4
("dma-mapping: warn when there is no coherent_dma_mask") that caused
coherent DMA allocations to produce a warning such as:
defxx: v1.11 2014/07/01 Lawrence V. Stefani and others
tc1: DEFTA at MMIO addr = 0x1e90, IRQ = 20, Hardware addr =
08-00-2b-a3-a3-29
[ cut here ]
WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
dfx_dev_register+0x670/0x678
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc6 #2
Stack : 8009ffc0 fec0 80647650
806f5f80
0001 8065d4e8
9800031b6300 80563478 805685b0
805d6720 0204 80388df8
0009 8053efd0 806657d0
803177f8 806d
980003078000 98000307b9e0 1e90 80067940
805d6720 0204 80388df8
805176c0 8004dc78 80067940
...
Call Trace:
[] show_stack+0xa0/0x130
[] __warn+0x128/0x170
---[ end trace b1d1e094f67f3bb2 ]---
This is because the TURBOchannel bus driver fails to set the coherent
DMA mask for devices enumerated.
Set the regular and coherent DMA masks for TURBOchannel devices then,
observing that the bus protocol supports a 34-bit (16GiB) DMA address
space, by interpreting the value presented in the address cycle across
the 32 `ad' lines as a 32-bit word rather than byte address[1]. The
architectural size of the TURBOchannel DMA address space exceeds the
maximum amount of RAM any actual TURBOchannel system in existence may
have, hence both masks are the same.
This removes the warning shown above.
References:
[1] "TURBOchannel Hardware Specification", EK-369AA-OD-007B, Digital
Equipment Corporation, January 1993, Section "DMA", pp. 1-15 -- 1-17
Signed-off-by: Maciej W. Rozycki
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/20835/
Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
Cc: sta...@vger.kernel.org # 4.16+
Cc: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman
---
drivers/tc/tc.c|8 +++-
include/linux/tc.h |1 +
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/tc/tc.c
+++ b/drivers/tc/tc.c
@@ -2,7 +2,7 @@
* TURBOchannel bus services.
*
* Copyright (c) Harald Koerfgen, 1998
- * Copyright (c) 2001, 2003, 2005, 2006 Maciej W. Rozycki
+ * Copyright (c) 2001, 2003, 2005, 2006, 2018 Maciej W. Rozycki
* Copyright (c) 2005 James Simmons
*
* This file is subject to the terms and conditions of the GNU
@@ -10,6 +10,7 @@
* directory of this archive for more details.
*/
#include
+#include
#include
#include
#include
@@ -92,6 +93,11 @@ static void __init tc_bus_add_devices(st
tdev->dev.bus = &tc_bus_type;
tdev->slot = slot;
+ /* TURBOchannel has 34-bit DMA addressing (16GiB space). */
+ tdev->dma_mask = DMA_BIT_MASK(34);
+ tdev->dev.dma_mask = &tdev->dma_mask;
+ tdev->dev.coherent_dma_mask = DMA_BIT_MASK(34);
+
for (i = 0; i < 8; i++) {
tdev->firmware[i] =
readb(module + offset + TC_FIRM_VER + 4 * i);
--- a/include/linux/tc.h
+++ b/include/linux/tc.h
@@ -84,6 +84,7 @@ struct tc_dev {
device. */
struct device dev;/* Generic device interface. */
struct resource resource; /* Address space of this device. */
+ u64 dma_mask; /* DMA addressable range. */
charvendor[9];
charname[9];
charfirmware[9];
[PATCH 4.4 023/160] Bluetooth: btbcm: Add entry for BCM4335C0 UART bluetooth
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Christian Hewitt
[ Upstream commit a357ea098c9605f60d92a66a9073f56ce25726da ]
This patch adds the device ID for the AMPAK AP6335 combo module used
in the 1st generation WeTek Hub Android/LibreELEC HTPC box. The WiFI
chip identifies itself as BCM4339, while Bluetooth identifies itself
as BCM4335 (rev C0):
```
[4.864248] Bluetooth: hci0: BCM: chip id 86
[4.866388] Bluetooth: hci0: BCM: features 0x2f
[4.889317] Bluetooth: hci0: BCM4335C0
[4.889332] Bluetooth: hci0: BCM4335C0 (003.001.009) build
[9.778383] Bluetooth: hci0: BCM4335C0 (003.001.009) build 0268
```
Output from hciconfig:
```
hci0: Type: Primary Bus: UART
BD Address: 43:39:00:00:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:7567 acl:234 sco:0 events:386 errors:0
TX bytes:53844 acl:77 sco:0 commands:304 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Name: 'HUB'
Class: 0x0c
Service Classes: Rendering, Capturing
Device Class: Miscellaneous,
HCI Version: 4.0 (0x6) Revision: 0x10c
LMP Version: 4.0 (0x6) Subversion: 0x6109
Manufacturer: Broadcom Corporation (15)
```
Signed-off-by: Christian Hewitt
Signed-off-by: Marcel Holtmann
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/bluetooth/btbcm.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/bluetooth/btbcm.c
+++ b/drivers/bluetooth/btbcm.c
@@ -270,6 +270,7 @@ static const struct {
{ 0x4103, "BCM4330B1" }, /* 002.001.003 */
{ 0x410e, "BCM43341B0" }, /* 002.001.014 */
{ 0x4406, "BCM4324B3" }, /* 002.004.006 */
+ { 0x6109, "BCM4335C0" }, /* 003.001.009 */
{ 0x610c, "BCM4354" }, /* 003.001.012 */
{ }
};
[PATCH 4.4 073/160] MIPS: OCTEON: fix out of bounds array access on CN68XX
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Aaro Koskinen
commit c0fae7e2452b90c31edd2d25eb3baf0c76b400ca upstream.
The maximum number of interfaces is returned by
cvmx_helper_get_number_of_interfaces(), and the value is used to access
interface_port_count[]. When CN68XX support was added, we forgot
to increase the array size. Fix that.
Fixes: 2c8c3f0201333 ("MIPS: Octeon: Support additional interfaces on CN68XX")
Signed-off-by: Aaro Koskinen
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/20949/
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org # v4.3+
Signed-off-by: Greg Kroah-Hartman
---
arch/mips/cavium-octeon/executive/cvmx-helper.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/cavium-octeon/executive/cvmx-helper.c
+++ b/arch/mips/cavium-octeon/executive/cvmx-helper.c
@@ -67,7 +67,7 @@ void (*cvmx_override_pko_queue_priority)
void (*cvmx_override_ipd_port_setup) (int ipd_port);
/* Port count per interface */
-static int interface_port_count[5];
+static int interface_port_count[9];
/* Port last configured link info index by IPD/PKO port */
static cvmx_helper_link_info_t
[PATCH 4.4 064/160] smb3: do not attempt cifs operation in smb3 query info error path
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Steve French
commit 1e77a8c204c9d1b655c61751b8ad0fde22421dbb upstream.
If backupuid mount option is sent, we can incorrectly retry
(on access denied on query info) with a cifs (FindFirst) operation
on an smb3 mount which causes the server to force the session close.
We set backup intent on open so no need for this fallback.
See kernel bugzilla 201435
Signed-off-by: Steve French
CC: Stable
Reviewed-by: Ronnie Sahlberg
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/inode.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -756,7 +756,15 @@ cifs_get_inode_info(struct inode **inode
} else if (rc == -EREMOTE) {
cifs_create_dfs_fattr(&fattr, sb);
rc = 0;
- } else if (rc == -EACCES && backup_cred(cifs_sb)) {
+ } else if ((rc == -EACCES) && backup_cred(cifs_sb) &&
+ (strcmp(server->vals->version_string, SMB1_VERSION_STRING)
+ == 0)) {
+ /*
+* For SMB2 and later the backup intent flag is already
+* sent if needed on open and there is no path based
+* FindFirst operation to use to retry with
+*/
+
srchinf = kzalloc(sizeof(struct cifs_search_info),
GFP_KERNEL);
if (srchinf == NULL) {
[PATCH 4.4 058/160] hugetlbfs: dirty pages as they are added to pagecache
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Kravetz
commit 22146c3ce98962436e401f7b7016a6f664c9ffb5 upstream.
Some test systems were experiencing negative huge page reserve counts and
incorrect file block counts. This was traced to /proc/sys/vm/drop_caches
removing clean pages from hugetlbfs file pagecaches. When non-hugetlbfs
explicit code removes the pages, the appropriate accounting is not
performed.
This can be recreated as follows:
fallocate -l 2M /dev/hugepages/foo
echo 1 > /proc/sys/vm/drop_caches
fallocate -l 2M /dev/hugepages/foo
grep -i huge /proc/meminfo
AnonHugePages: 0 kB
ShmemHugePages:0 kB
HugePages_Total:2048
HugePages_Free: 2047
HugePages_Rsvd:18446744073709551615
HugePages_Surp:0
Hugepagesize: 2048 kB
Hugetlb: 4194304 kB
ls -lsh /dev/hugepages/foo
4.0M -rw-r--r--. 1 root root 2.0M Oct 17 20:05 /dev/hugepages/foo
To address this issue, dirty pages as they are added to pagecache. This
can easily be reproduced with fallocate as shown above. Read faulted
pages will eventually end up being marked dirty. But there is a window
where they are clean and could be impacted by code such as drop_caches.
So, just dirty them all as they are added to the pagecache.
Link: http://lkml.kernel.org/r/b5be45b8-5afe-56cd-9482-28384699a...@oracle.com
Fixes: 6bda666a03f0 ("hugepages: fold find_or_alloc_pages into huge_no_page()")
Signed-off-by: Mike Kravetz
Acked-by: Mihcla Hocko
Reviewed-by: Khalid Aziz
Cc: Hugh Dickins
Cc: Naoya Horiguchi
Cc: "Aneesh Kumar K . V"
Cc: Andrea Arcangeli
Cc: "Kirill A . Shutemov"
Cc: Davidlohr Bueso
Cc: Alexander Viro
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/hugetlb.c |6 ++
1 file changed, 6 insertions(+)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3537,6 +3537,12 @@ int huge_add_to_page_cache(struct page *
return err;
ClearPagePrivate(page);
+ /*
+* set page dirty so that it will not be removed from cache/file
+* by non-hugetlbfs specific code paths.
+*/
+ set_page_dirty(page);
+
spin_lock(&inode->i_lock);
inode->i_blocks += blocks_per_huge_page(h);
spin_unlock(&inode->i_lock);
[PATCH 4.4 061/160] iio: adc: at91: fix wrong channel number in triggered buffer mode
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eugen Hristev
commit aea835f2dc8a682942b859179c49ad1841a6c8b9 upstream.
When channels are registered, the hardware channel number is not the
actual iio channel number.
This is because the driver is probed with a certain number of accessible
channels. Some pins are routed and some not, depending on the description of
the board in the DT.
Because of that, channels 0,1,2,3 can correspond to hardware channels
2,3,4,5 for example.
In the buffered triggered case, we need to do the translation accordingly.
Fixed the channel number to stop reading the wrong channel.
Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard
Signed-off-by: Eugen Hristev
Acked-by: Ludovic Desroches
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
---
drivers/iio/adc/at91_adc.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -245,12 +245,14 @@ static irqreturn_t at91_adc_trigger_hand
struct iio_poll_func *pf = p;
struct iio_dev *idev = pf->indio_dev;
struct at91_adc_state *st = iio_priv(idev);
+ struct iio_chan_spec const *chan;
int i, j = 0;
for (i = 0; i < idev->masklength; i++) {
if (!test_bit(i, idev->active_scan_mask))
continue;
- st->buffer[j] = at91_adc_readl(st, AT91_ADC_CHAN(st, i));
+ chan = idev->channels + i;
+ st->buffer[j] = at91_adc_readl(st, AT91_ADC_CHAN(st,
chan->channel));
j++;
}
[PATCH 4.4 028/160] pinctrl: qcom: spmi-mpp: Fix drive strength setting
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Stephen Boyd
[ Upstream commit 89c68b102f13f123aaef22b292526d6b92501334 ]
It looks like we parse the drive strength setting here, but never
actually write it into the hardware to update it. Parse the setting and
then write it at the end of the pinconf setting function so that it
actually sticks in the hardware.
Fixes: 0e948042c420 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode")
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -459,7 +459,7 @@ static int pmic_mpp_config_set(struct pi
pad->dtest = arg;
break;
case PIN_CONFIG_DRIVE_STRENGTH:
- arg = pad->drive_strength;
+ pad->drive_strength = arg;
break;
case PMIC_MPP_CONF_AMUX_ROUTE:
if (arg >= PMIC_MPP_AMUX_ROUTE_ABUS4)
@@ -503,6 +503,10 @@ static int pmic_mpp_config_set(struct pi
if (ret < 0)
return ret;
+ ret = pmic_mpp_write(state, pad, PMIC_MPP_REG_SINK_CTL,
pad->drive_strength);
+ if (ret < 0)
+ return ret;
+
val = pad->is_enabled << PMIC_MPP_REG_MASTER_EN_SHIFT;
return pmic_mpp_write(state, pad, PMIC_MPP_REG_EN_CTL, val);
[PATCH 4.4 027/160] ACPI / LPSS: Add alternative ACPI HIDs for Cherry Trail DMA controllers
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Hans de Goede
[ Upstream commit 240714061c58e6b1abfb3322398a7634151c06cb ]
Bay and Cherry Trail DSTDs represent a different set of devices depending
on which OS the device think it is booting. One set of decices for Windows
and another set of devices for Android which targets the Android-x86 Linux
kernel fork (which e.g. used to have its own display driver instead of
using the i915 driver).
Which set of devices we are actually going to get is out of our control,
this is controlled by the ACPI OSID variable, which gets either set through
an EFI setup option, or sometimes is autodetected. So we need to support
both.
This commit adds support for the 80862286 and 808622C0 ACPI HIDs which we
get for the first resp. second DMA controller on Cherry Trail devices when
OSID is set to Android.
Signed-off-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/acpi/acpi_lpss.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -235,9 +235,11 @@ static const struct acpi_device_id acpi_
{ "INT33FC", },
/* Braswell LPSS devices */
+ { "80862286", LPSS_ADDR(lpss_dma_desc) },
{ "80862288", LPSS_ADDR(bsw_pwm_dev_desc) },
{ "8086228A", LPSS_ADDR(bsw_uart_dev_desc) },
{ "8086228E", LPSS_ADDR(bsw_spi_dev_desc) },
+ { "808622C0", LPSS_ADDR(lpss_dma_desc) },
{ "808622C1", LPSS_ADDR(bsw_i2c_dev_desc) },
/* Broadwell LPSS devices */
[PATCH 4.4 060/160] iio: adc: at91: fix acking DRDY irq on simple conversions
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eugen Hristev
commit bc1b45326223e7e890053cf6266357adfa61942d upstream.
When doing simple conversions, the driver did not acknowledge the DRDY irq.
If this irq status is not acked, it will be left pending, and as soon as a
trigger is enabled, the irq handler will be called, it doesn't know why
this status has occurred because no channel is pending, and then it will go
int a irq loop and board will hang.
To avoid this situation, read the LCDR after a raw conversion is done.
Fixes: 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard
Signed-off-by: Eugen Hristev
Acked-by: Ludovic Desroches
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman
---
drivers/iio/adc/at91_adc.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -276,6 +276,8 @@ static void handle_adc_eoc_trigger(int i
iio_trigger_poll(idev->trig);
} else {
st->last_value = at91_adc_readl(st, AT91_ADC_CHAN(st,
st->chnb));
+ /* Needed to ACK the DRDY interruption */
+ at91_adc_readl(st, AT91_ADC_LCDR);
st->done = true;
wake_up_interruptible(&st->wq_data_avail);
}
[PATCH 4.4 059/160] kbuild: fix kernel/bounds.c W=1 warning
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit 6a32c2469c3fbfee8f25bcd20af647326650a6cf upstream.
Building any configuration with 'make W=1' produces a warning:
kernel/bounds.c:16:6: warning: no previous prototype for 'foo'
[-Wmissing-prototypes]
When also passing -Werror, this prevents us from building any other files.
Nobody ever calls the function, but we can't make it 'static' either
since we want the compiler output.
Calling it 'main' instead however avoids the warning, because gcc
does not insist on having a declaration for main.
Link: http://lkml.kernel.org/r/20181005083313.2088252-1-a...@arndb.de
Signed-off-by: Arnd Bergmann
Reported-by: Kieran Bingham
Reviewed-by: Kieran Bingham
Cc: David Laight
Cc: Masahiro Yamada
Cc: Greg Kroah-Hartman
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
kernel/bounds.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/kernel/bounds.c
+++ b/kernel/bounds.c
@@ -12,7 +12,7 @@
#include
#include
-void foo(void)
+int main(void)
{
/* The enum constants to put into include/generated/bounds.h */
DEFINE(NR_PAGEFLAGS, __NR_PAGEFLAGS);
@@ -22,4 +22,6 @@ void foo(void)
#endif
DEFINE(SPINLOCK_SIZE, sizeof(spinlock_t));
/* End of constants */
+
+ return 0;
}
[PATCH 4.4 030/160] pinctrl: ssbi-gpio: Fix pm8xxx_pin_config_get() to be compliant
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Douglas Anderson
[ Upstream commit b432414b996d32a1bd9afe2bd595bd5729c1477f ]
If you look at "pinconf-groups" in debugfs for ssbi-gpio you'll notice
it looks like nonsense.
The problem is fairly well described in commit 1cf86bc21257 ("pinctrl:
qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and
commit 05e0c828955c ("pinctrl: msm: Fix msm_config_group_get() to be
compliant"), but it was pointed out that ssbi-gpio has the same
problem. Let's fix it there too.
Fixes: b4c45fe974bc ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
@@ -259,22 +259,32 @@ static int pm8xxx_pin_config_get(struct
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- arg = pin->bias == PM8XXX_GPIO_BIAS_NP;
+ if (pin->bias != PM8XXX_GPIO_BIAS_NP)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- arg = pin->bias == PM8XXX_GPIO_BIAS_PD;
+ if (pin->bias != PM8XXX_GPIO_BIAS_PD)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- arg = pin->bias <= PM8XXX_GPIO_BIAS_PU_1P5_30;
+ if (pin->bias > PM8XXX_GPIO_BIAS_PU_1P5_30)
+ return -EINVAL;
+ arg = 1;
break;
case PM8XXX_QCOM_PULL_UP_STRENGTH:
arg = pin->pull_up_strength;
break;
case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
- arg = pin->disable;
+ if (!pin->disable)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_INPUT_ENABLE:
- arg = pin->mode == PM8XXX_GPIO_MODE_INPUT;
+ if (pin->mode != PM8XXX_GPIO_MODE_INPUT)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_OUTPUT:
if (pin->mode & PM8XXX_GPIO_MODE_OUTPUT)
@@ -289,10 +299,14 @@ static int pm8xxx_pin_config_get(struct
arg = pin->output_strength;
break;
case PIN_CONFIG_DRIVE_PUSH_PULL:
- arg = !pin->open_drain;
+ if (pin->open_drain)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_DRIVE_OPEN_DRAIN:
- arg = pin->open_drain;
+ if (!pin->open_drain)
+ return -EINVAL;
+ arg = 1;
break;
default:
return -EINVAL;
[PATCH 4.4 031/160] ath10k: schedule hardware restart if WMI command times out
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Martin Willi
[ Upstream commit a9911937e7d332761e8c4fcbc7ba0426bdc3956f ]
When running in AP mode, ath10k sometimes suffers from TX credit
starvation. The issue is hard to reproduce and shows up once in a
few days, but has been repeatedly seen with QCA9882 and a large
range of firmwares, including 10.2.4.70.67.
Once the module is in this state, TX credits are never replenished,
which results in "SWBA overrun" errors, as no beacons can be sent.
Even worse, WMI commands run in a timeout while holding the conf
mutex for three seconds each, making any further operations slow
and the whole system unresponsive.
The firmware/driver never recovers from that state automatically,
and triggering TX flush or warm restarts won't work over WMI. So
issue a hardware restart if a WMI command times out due to missing
TX credits. This implies a connectivity outage of about 1.4s in AP
mode, but brings back the interface and the whole system to a usable
state. WMI command timeouts have not been seen in absent of this
specific issue, so taking such drastic actions seems legitimate.
Signed-off-by: Martin Willi
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/wireless/ath/ath10k/wmi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1749,6 +1749,12 @@ int ath10k_wmi_cmd_send(struct ath10k *a
if (ret)
dev_kfree_skb_any(skb);
+ if (ret == -EAGAIN) {
+ ath10k_warn(ar, "wmi command %d timeout, restarting hardware\n",
+ cmd_id);
+ queue_work(ar->workqueue, &ar->restart_work);
+ }
+
return ret;
}
[PATCH 4.4 032/160] scsi: esp_scsi: Track residual for PIO transfers
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Finn Thain
[ Upstream commit fd47d919d0c336e7c22862b51ee94927ffea227a ]
If a target disconnects during a PIO data transfer the command may fail
when the target reconnects:
scsi host1: DMA length is zero!
scsi host1: cur adr[0438] len[]
The scsi bus is then reset. This happens because the residual reached
zero before the transfer was completed.
The usual residual calculation relies on the Transfer Count registers.
That works for DMA transfers but not for PIO transfers. Fix the problem
by storing the PIO transfer residual and using that to correctly
calculate bytes_sent.
Fixes: 6fe07aaffbf0 ("[SCSI] m68k: new mac_esp scsi driver")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
Tested-by: Michael Schmitz
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/esp_scsi.c |1 +
drivers/scsi/esp_scsi.h |2 ++
drivers/scsi/mac_esp.c |2 ++
3 files changed, 5 insertions(+)
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -1349,6 +1349,7 @@ static int esp_data_bytes_sent(struct es
bytes_sent = esp->data_dma_len;
bytes_sent -= ecount;
+ bytes_sent -= esp->send_cmd_residual;
/*
* The am53c974 has a DMA 'pecularity'. The doc states:
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -540,6 +540,8 @@ struct esp {
void*dma;
int dmarev;
+
+ u32 send_cmd_residual;
};
/* A front-end driver for the ESP chip should do the following in
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -426,6 +426,8 @@ static void mac_esp_send_pio_cmd(struct
scsi_esp_cmd(esp, ESP_CMD_TI);
}
}
+
+ esp->send_cmd_residual = esp_count;
}
static int mac_esp_irq_pending(struct esp *esp)
[PATCH 4.4 029/160] pinctrl: spmi-mpp: Fix pmic_mpp_config_get() to be compliant
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Douglas Anderson
[ Upstream commit 0d5b476f8f57fcb06c45fe27681ac47254f63fd2 ]
If you look at "pinconf-groups" in debugfs for ssbi-mpp you'll notice
it looks like nonsense.
The problem is fairly well described in commit 1cf86bc21257 ("pinctrl:
qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and
commit 05e0c828955c ("pinctrl: msm: Fix msm_config_group_get() to be
compliant"), but it was pointed out that ssbi-mpp has the same
problem. Let's fix it there too.
NOTE: in case it's helpful to someone reading this, the way to tell
whether to do the -EINVAL or not is to look at the PCONFDUMP for a
given attribute. If the last element (has_arg) is false then you need
to do the -EINVAL trick.
ALSO NOTE: it seems unlikely that the values returned when we try to
get PIN_CONFIG_BIAS_PULL_UP will actually be printed since "has_arg"
is false for that one, but I guess it's still fine to return different
values so I kept doing that. It seems like another driver (ssbi-gpio)
uses a custom attribute (PM8XXX_QCOM_PULL_UP_STRENGTH) for something
similar so maybe a future change should do that here too.
Fixes: cfb24f6ebd38 ("pinctrl: Qualcomm SPMI PMIC MPP pin controller driver")
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -347,13 +347,12 @@ static int pmic_mpp_config_get(struct pi
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- arg = pad->pullup == PMIC_MPP_PULL_UP_OPEN;
+ if (pad->pullup != PMIC_MPP_PULL_UP_OPEN)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_BIAS_PULL_UP:
switch (pad->pullup) {
- case PMIC_MPP_PULL_UP_OPEN:
- arg = 0;
- break;
case PMIC_MPP_PULL_UP_0P6KOHM:
arg = 600;
break;
@@ -368,13 +367,17 @@ static int pmic_mpp_config_get(struct pi
}
break;
case PIN_CONFIG_BIAS_HIGH_IMPEDANCE:
- arg = !pad->is_enabled;
+ if (pad->is_enabled)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_POWER_SOURCE:
arg = pad->power_source;
break;
case PIN_CONFIG_INPUT_ENABLE:
- arg = pad->input_enabled;
+ if (!pad->input_enabled)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_OUTPUT:
arg = pad->out_value;
@@ -386,7 +389,9 @@ static int pmic_mpp_config_get(struct pi
arg = pad->amux_input;
break;
case PMIC_MPP_CONF_PAIRED:
- arg = pad->paired;
+ if (!pad->paired)
+ return -EINVAL;
+ arg = 1;
break;
case PIN_CONFIG_DRIVE_STRENGTH:
arg = pad->drive_strength;
[PATCH 4.4 062/160] w1: omap-hdq: fix missing bus unregister at removal
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Andreas Kemnade commit a007734618fee1bf35556c04fa498d41d42c7301 upstream. The bus master was not removed after unloading the module or unbinding the driver. That lead to oopses like this [ 127.842987] Unable to handle kernel paging request at virtual address bf01d04c [ 127.850646] pgd = 70e3cd9a [ 127.853698] [bf01d04c] *pgd=8f908811, *pte=, *ppte= [ 127.860412] Internal error: Oops: 8007 [#1] PREEMPT SMP ARM [ 127.88] Modules linked in: bq27xxx_battery overlay [last unloaded: omap_hdq] [ 127.874542] CPU: 0 PID: 1022 Comm: w1_bus_master1 Not tainted 4.19.0-rc4-1-g2d51da718324 #12 [ 127.883819] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 127.890441] PC is at 0xbf01d04c [ 127.893798] LR is at w1_search_process_cb+0x4c/0xfc [ 127.898956] pc : []lr : []psr: a0070013 [ 127.905609] sp : cf885f48 ip : bf01d04c fp : ddf1e11c [ 127.911132] r10: cf8fe040 r9 : c05f8d00 r8 : cf8fe040 [ 127.916656] r7 : 00f0 r6 : cf8fe02c r5 : cf8fe000 r4 : cf8fe01c [ 127.923553] r3 : c05f8d00 r2 : 00f0 r1 : cf8fe000 r0 : dde1ef10 [ 127.930450] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 127.938018] Control: 10c5387d Table: 8f8f0019 DAC: 0051 [ 127.944091] Process w1_bus_master1 (pid: 1022, stack limit = 0x9135699f) [ 127.951171] Stack: (0xcf885f48 to 0xcf886000) [ 127.955810] 5f40: cf8fe000 cf884000 cf8fe090 03e8 c05f8d00 [ 127.964477] 5f60: dde5fc34 c05f9700 ddf1e100 ddf1e540 cf884000 cf8fe000 c05f9694 [ 127.973114] 5f80: dde5fc34 c01499a4 ddf1e540 c0149874 [ 127.981781] 5fa0: c01010e8 [ 127.990447] 5fc0: [ 127.999114] 5fe0: 0013 [ 128.007781] [] (w1_search_process_cb) from [] (w1_process+0x6c/0x118) [ 128.016479] [] (w1_process) from [] (kthread+0x130/0x148) [ 128.024047] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 128.031677] Exception stack(0xcf885fb0 to 0xcf885ff8) [ 128.037017] 5fa0: [ 128.045684] 5fc0: [ 128.054351] 5fe0: 0013 [ 128.061340] Code: bad PC value [ 128.064697] ---[ end trace af066e33c0e14119 ]--- Cc: Signed-off-by: Andreas Kemnade Signed-off-by: Greg Kroah-Hartman --- drivers/w1/masters/omap_hdq.c |2 ++ 1 file changed, 2 insertions(+) --- a/drivers/w1/masters/omap_hdq.c +++ b/drivers/w1/masters/omap_hdq.c @@ -785,6 +785,8 @@ static int omap_hdq_remove(struct platfo /* remove module dependency */ pm_runtime_disable(&pdev->dev); + w1_remove_master_device(&omap_w1_master); + return 0; }
[PATCH 4.4 056/160] crypto: lrw - Fix out-of bounds access on counter overflow
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Ondrej Mosnacek
commit fbe1a850b3b1522e9fc22319ccbbcd2ab05328d2 upstream.
When the LRW block counter overflows, the current implementation returns
128 as the index to the precomputed multiplication table, which has 128
entries. This patch fixes it to return the correct value (127).
Fixes: 64470f1b8510 ("[CRYPTO] lrw: Liskov Rivest Wagner, a tweakable narrow
block cipher mode")
Cc: # 2.6.20+
Reported-by: Eric Biggers
Signed-off-by: Ondrej Mosnacek
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
---
crypto/lrw.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -132,7 +132,12 @@ static inline int get_index128(be128 *bl
return x + ffz(val);
}
- return x;
+ /*
+* If we get here, then x == 128 and we are incrementing the counter
+* from all ones to all zeros. This means we must return index 127, i.e.
+* the one corresponding to key2*{ 1,...,1 }.
+*/
+ return 127;
}
static int crypt(struct blkcipher_desc *d,
[PATCH 4.4 053/160] HID: hiddev: fix potential Spectre v1
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Breno Leitao
commit f11274396a538b31bc010f782e05c2ce3f804c13 upstream.
uref->usage_index can be indirectly controlled by userspace, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This field is used as an array index by the hiddev_ioctl_usage() function,
when 'cmd' is either HIDIOCGCOLLECTIONINDEX, HIDIOCGUSAGES or
HIDIOCSUSAGES.
For cmd == HIDIOCGCOLLECTIONINDEX case, uref->usage_index is compared to
field->maxusage and then used as an index to dereference field->usage
array. The same thing happens to the cmd == HIDIOC{G,S}USAGES cases, where
uref->usage_index is checked against an array maximum value and then it is
used as an index in an array.
This is a summary of the HIDIOCGCOLLECTIONINDEX case, which matches the
traditional Spectre V1 first load:
copy_from_user(uref, user_arg, sizeof(*uref))
if (uref->usage_index >= field->maxusage)
goto inval;
i = field->usage[uref->usage_index].collection_index;
return i;
This patch fixes this by sanitizing field uref->usage_index before using it
to index field->usage (HIDIOCGCOLLECTIONINDEX) or field->value in
HIDIOC{G,S}USAGES arrays, thus, avoiding speculation in the first load.
Cc:
Signed-off-by: Breno Leitao
v2: Contemplate cmd == HIDIOC{G,S}USAGES case
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/usbhid/hiddev.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -521,14 +521,24 @@ static noinline int hiddev_ioctl_usage(s
if (cmd == HIDIOCGCOLLECTIONINDEX) {
if (uref->usage_index >= field->maxusage)
goto inval;
+ uref->usage_index =
+ array_index_nospec(uref->usage_index,
+ field->maxusage);
} else if (uref->usage_index >= field->report_count)
goto inval;
}
- if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) &&
- (uref_multi->num_values > HID_MAX_MULTI_USAGES ||
-uref->usage_index + uref_multi->num_values >
field->report_count))
- goto inval;
+ if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
+ if (uref_multi->num_values > HID_MAX_MULTI_USAGES ||
+ uref->usage_index + uref_multi->num_values >
+ field->report_count)
+ goto inval;
+
+ uref->usage_index =
+ array_index_nospec(uref->usage_index,
+ field->report_count -
+ uref_multi->num_values);
+ }
switch (cmd) {
case HIDIOCGUSAGE:
[PATCH 4.4 055/160] signal/GenWQE: Fix sending of SIGKILL
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric W. Biederman
commit 0ab93e9c99f8208c0a1a7b7170c827936268c996 upstream.
The genweq_add_file and genwqe_del_file by caching current without
using reference counting embed the assumption that a file descriptor
will never be passed from one process to another. It even embeds the
assumption that the the thread that opened the file will be in
existence when the process terminates. Neither of which are
guaranteed to be true.
Therefore replace caching the task_struct of the opener with
pid of the openers thread group id. All the knowledge of the
opener is used for is as the target of SIGKILL and a SIGKILL
will kill the entire process group.
Rename genwqe_force_sig to genwqe_terminate, remove it's unncessary
signal argument, update it's ownly caller, and use kill_pid
instead of force_sig.
The work force_sig does in changing signal handling state is not
relevant to SIGKILL sent as SEND_SIG_PRIV. The exact same processess
will be killed just with less work, and less confusion. The work done
by force_sig is really only needed for handling syncrhonous
exceptions.
It will still be possible to cause genwqe_device_remove to wait
8 seconds by passing a file descriptor to another process but
the possible user after free is fixed.
Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue")
Cc: sta...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: Frank Haverkamp
Cc: Joerg-Stephan Vogt
Cc: Michael Jung
Cc: Michael Ruettger
Cc: Kleber Sacilotto de Souza
Cc: Sebastian Ott
Cc: Eberhard S. Amann
Cc: Gabriel Krisman Bertazi
Cc: Guilherme G. Piccoli
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman
---
drivers/misc/genwqe/card_base.h |2 +-
drivers/misc/genwqe/card_dev.c |9 +
2 files changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/misc/genwqe/card_base.h
+++ b/drivers/misc/genwqe/card_base.h
@@ -404,7 +404,7 @@ struct genwqe_file {
struct file *filp;
struct fasync_struct *async_queue;
- struct task_struct *owner;
+ struct pid *opener;
struct list_head list; /* entry in list of open files */
spinlock_t map_lock;/* lock for dma_mappings */
--- a/drivers/misc/genwqe/card_dev.c
+++ b/drivers/misc/genwqe/card_dev.c
@@ -52,7 +52,7 @@ static void genwqe_add_file(struct genwq
{
unsigned long flags;
- cfile->owner = current;
+ cfile->opener = get_pid(task_tgid(current));
spin_lock_irqsave(&cd->file_lock, flags);
list_add(&cfile->list, &cd->file_list);
spin_unlock_irqrestore(&cd->file_lock, flags);
@@ -65,6 +65,7 @@ static int genwqe_del_file(struct genwqe
spin_lock_irqsave(&cd->file_lock, flags);
list_del(&cfile->list);
spin_unlock_irqrestore(&cd->file_lock, flags);
+ put_pid(cfile->opener);
return 0;
}
@@ -275,7 +276,7 @@ static int genwqe_kill_fasync(struct gen
return files;
}
-static int genwqe_force_sig(struct genwqe_dev *cd, int sig)
+static int genwqe_terminate(struct genwqe_dev *cd)
{
unsigned int files = 0;
unsigned long flags;
@@ -283,7 +284,7 @@ static int genwqe_force_sig(struct genwq
spin_lock_irqsave(&cd->file_lock, flags);
list_for_each_entry(cfile, &cd->file_list, list) {
- force_sig(sig, cfile->owner);
+ kill_pid(cfile->opener, SIGKILL, 1);
files++;
}
spin_unlock_irqrestore(&cd->file_lock, flags);
@@ -1356,7 +1357,7 @@ static int genwqe_inform_and_stop_proces
dev_warn(&pci_dev->dev,
"[%s] send SIGKILL and wait ...\n", __func__);
- rc = genwqe_force_sig(cd, SIGKILL); /* force terminate */
+ rc = genwqe_terminate(cd);
if (rc) {
/* Give kill_timout more seconds to end processes */
for (i = 0; (i < genwqe_kill_timeout) &&
[PATCH 4.4 057/160] ima: fix showing large violations or runtime_measurements_count
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit 1e4c8dafbb6bf72fb5eca035b861e39c5896c2b7 upstream.
The 12 character temporary buffer is not necessarily long enough to hold
a 'long' value. Increase it.
Signed-off-by: Eric Biggers
Cc: sta...@vger.kernel.org
Signed-off-by: Mimi Zohar
Signed-off-by: Greg Kroah-Hartman
---
security/integrity/ima/ima_fs.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -26,14 +26,14 @@
#include "ima.h"
static int valid_policy = 1;
-#define TMPBUFLEN 12
+
static ssize_t ima_show_htable_value(char __user *buf, size_t count,
loff_t *ppos, atomic_long_t *val)
{
- char tmpbuf[TMPBUFLEN];
+ char tmpbuf[32];/* greater than largest 'long' string value */
ssize_t len;
- len = scnprintf(tmpbuf, TMPBUFLEN, "%li\n", atomic_long_read(val));
+ len = scnprintf(tmpbuf, sizeof(tmpbuf), "%li\n", atomic_long_read(val));
return simple_read_from_buffer(buf, count, ppos, tmpbuf, len);
}
[PATCH 4.4 026/160] kprobes: Return error if we fail to reuse kprobe instead of BUG_ON()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
[ Upstream commit 819319fc93461c07b9cdb3064f154bd8cfd48172 ]
Make reuse_unused_kprobe() to return error code if
it fails to reuse unused kprobe for optprobe instead
of calling BUG_ON().
Signed-off-by: Masami Hiramatsu
Cc: Anil S Keshavamurthy
Cc: David S . Miller
Cc: Linus Torvalds
Cc: Naveen N . Rao
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/153666124040.21306.14150398706331307654.stgit@devbox
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/kprobes.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -665,9 +665,10 @@ static void unoptimize_kprobe(struct kpr
}
/* Cancel unoptimizing for reusing */
-static void reuse_unused_kprobe(struct kprobe *ap)
+static int reuse_unused_kprobe(struct kprobe *ap)
{
struct optimized_kprobe *op;
+ int ret;
BUG_ON(!kprobe_unused(ap));
/*
@@ -681,8 +682,12 @@ static void reuse_unused_kprobe(struct k
/* Enable the probe again */
ap->flags &= ~KPROBE_FLAG_DISABLED;
/* Optimize it again (remove from op->list) */
- BUG_ON(!kprobe_optready(ap));
+ ret = kprobe_optready(ap);
+ if (ret)
+ return ret;
+
optimize_kprobe(ap);
+ return 0;
}
/* Remove optimized instructions */
@@ -894,11 +899,16 @@ static void __disarm_kprobe(struct kprob
#define kprobe_disarmed(p) kprobe_disabled(p)
#define wait_for_kprobe_optimizer()do {} while (0)
-/* There should be no unused kprobes can be reused without optimization */
-static void reuse_unused_kprobe(struct kprobe *ap)
+static int reuse_unused_kprobe(struct kprobe *ap)
{
+ /*
+* If the optimized kprobe is NOT supported, the aggr kprobe is
+* released at the same time that the last aggregated kprobe is
+* unregistered.
+* Thus there should be no chance to reuse unused kprobe.
+*/
printk(KERN_ERR "Error: There should be no unused kprobe here.\n");
- BUG_ON(kprobe_unused(ap));
+ return -EINVAL;
}
static void free_aggr_kprobe(struct kprobe *p)
@@ -1276,9 +1286,12 @@ static int register_aggr_kprobe(struct k
goto out;
}
init_aggr_kprobe(ap, orig_p);
- } else if (kprobe_unused(ap))
+ } else if (kprobe_unused(ap)) {
/* This probe is going to die. Rescue it */
- reuse_unused_kprobe(ap);
+ ret = reuse_unused_kprobe(ap);
+ if (ret)
+ goto out;
+ }
if (kprobe_gone(ap)) {
/*
[PATCH 4.4 054/160] PCI: Add Device IDs for Intel GPU "spurious interrupt" quirk
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Bin Meng
commit d0c9606b31a21028fb5b753c8ad79626292accfd upstream.
Add Device IDs to the Intel GPU "spurious interrupt" quirk table.
For these devices, unplugging the VGA cable and plugging it in again causes
spurious interrupts from the IGD. Linux eventually disables the interrupt,
but of course that disables any other devices sharing the interrupt.
The theory is that this is a VGA BIOS defect: it should have disabled the
IGD interrupt but failed to do so.
See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel
Sandy Bridge GPUs") and 7c82126a94e6 ("PCI: Add new ID for Intel GPU
"spurious interrupt" quirk") for some history.
[bhelgaas: See link below for discussion about how to fix this more
generically instead of adding device IDs for every new Intel GPU. I hope
this is the last patch to add device IDs.]
Link:
https://lore.kernel.org/linux-pci/1537974841-29928-1-git-send-email-bmeng...@gmail.com
Signed-off-by: Bin Meng
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas
Cc: sta...@vger.kernel.org # v3.4+
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/quirks.c |4
1 file changed, 4 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3061,7 +3061,11 @@ static void disable_igfx_irq(struct pci_
pci_iounmap(dev, regs);
}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0042, disable_igfx_irq);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0046, disable_igfx_irq);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x004a, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0106, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0152, disable_igfx_irq);
[PATCH 4.4 042/160] dmaengine: dma-jz4780: Return error if not probed from DT
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Paul Cercueil
[ Upstream commit 54f919a04cf221bc1601d1193682d4379dacacbd ]
The driver calls clk_get() with the clock name set to NULL, which means
that the driver could only work when probed from devicetree. From now
on, we explicitly require the driver to be probed from devicetree.
Signed-off-by: Paul Cercueil
Tested-by: Mathieu Malaterre
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/dma/dma-jz4780.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/dma/dma-jz4780.c
+++ b/drivers/dma/dma-jz4780.c
@@ -750,6 +750,11 @@ static int jz4780_dma_probe(struct platf
struct resource *res;
int i, ret;
+ if (!dev->of_node) {
+ dev_err(dev, "This driver must be probed from devicetree\n");
+ return -EINVAL;
+ }
+
jzdma = devm_kzalloc(dev, sizeof(*jzdma), GFP_KERNEL);
if (!jzdma)
return -ENOMEM;
[PATCH 4.4 044/160] xen-swiotlb: use actually allocated size on check physical continuous
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Joe Jin
commit 7250f422da0480d8512b756640f131b9b893ccda upstream.
xen_swiotlb_{alloc,free}_coherent() allocate/free memory based on the
order of the pages and not size argument (bytes). This is inconsistent with
range_straddles_page_boundary and memset which use the 'size' value,
which may lead to not exchanging memory with Xen
(range_straddles_page_boundary()
returned true). And then the call to xen_swiotlb_free_coherent() would
actually try to exchange the memory with Xen, leading to the kernel
hitting an BUG (as the hypercall returned an error).
This patch fixes it by making the 'size' variable be of the same size
as the amount of memory allocated.
CC: sta...@vger.kernel.org
Signed-off-by: Joe Jin
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: Christoph Helwig
Cc: Dongli Zhang
Cc: John Sobecki
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman
---
drivers/xen/swiotlb-xen.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -310,6 +310,9 @@ xen_swiotlb_alloc_coherent(struct device
*/
flags &= ~(__GFP_DMA | __GFP_HIGHMEM);
+ /* Convert the size to actually allocated. */
+ size = 1UL << (order + XEN_PAGE_SHIFT);
+
/* On ARM this function returns an ioremap'ped virtual address for
* which virt_to_phys doesn't return the corresponding physical
* address. In fact on ARM virt_to_phys only works for kernel direct
@@ -359,6 +362,9 @@ xen_swiotlb_free_coherent(struct device
* physical address */
phys = xen_bus_to_phys(dev_addr);
+ /* Convert the size to actually allocated. */
+ size = 1UL << (order + XEN_PAGE_SHIFT);
+
if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size))
xen_destroy_contiguous_region(phys, order);
[PATCH 4.4 047/160] xen: make xen_qlock_wait() nestable
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit a856531951dc8094359dfdac21d59cee5969c18e upstream.
xen_qlock_wait() isn't safe for nested calls due to interrupts. A call
of xen_qlock_kick() might be ignored in case a deeper nesting level
was active right before the call of xen_poll_irq():
CPU 1: CPU 2:
spin_lock(lock1)
spin_lock(lock1)
-> xen_qlock_wait()
-> xen_clear_irq_pending()
Interrupt happens
spin_unlock(lock1)
-> xen_qlock_kick(CPU 2)
spin_lock_irqsave(lock2)
spin_lock_irqsave(lock2)
-> xen_qlock_wait()
-> xen_clear_irq_pending()
clears kick for lock1
-> xen_poll_irq()
spin_unlock_irq_restore(lock2)
-> xen_qlock_kick(CPU 2)
wakes up
spin_unlock_irq_restore(lock2)
IRET
resumes in xen_qlock_wait()
-> xen_poll_irq()
never wakes up
The solution is to disable interrupts in xen_qlock_wait() and not to
poll for the irq in case xen_qlock_wait() is called in nmi context.
Cc: sta...@vger.kernel.org
Cc: waiman.l...@hp.com
Cc: pet...@infradead.org
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/spinlock.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -41,29 +41,25 @@ static void xen_qlock_kick(int cpu)
*/
static void xen_qlock_wait(u8 *byte, u8 val)
{
+ unsigned long flags;
int irq = __this_cpu_read(lock_kicker_irq);
/* If kicker interrupts not initialized yet, just spin */
- if (irq == -1)
+ if (irq == -1 || in_nmi())
return;
- /* If irq pending already clear it and return. */
+ /* Guard against reentry. */
+ local_irq_save(flags);
+
+ /* If irq pending already clear it. */
if (xen_test_irq_pending(irq)) {
xen_clear_irq_pending(irq);
- return;
+ } else if (READ_ONCE(*byte) == val) {
+ /* Block until irq becomes pending (or a spurious wakeup) */
+ xen_poll_irq(irq);
}
- if (READ_ONCE(*byte) != val)
- return;
-
- /*
-* If an interrupt happens here, it will leave the wakeup irq
-* pending, which will cause xen_poll_irq() to return
-* immediately.
-*/
-
- /* Block until irq becomes pending (or perhaps a spurious wakeup) */
- xen_poll_irq(irq);
+ local_irq_restore(flags);
}
#else /* CONFIG_QUEUED_SPINLOCKS */
[PATCH 4.4 052/160] ext4: initialize retries variable in ext4_da_write_inline_data_begin()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Czerner
commit 625ef8a3acd111d5f496d190baf99d1a815bd03e upstream.
Variable retries is not initialized in ext4_da_write_inline_data_begin()
which can lead to nondeterministic number of retries in case we hit
ENOSPC. Initialize retries to zero as we do everywhere else.
Signed-off-by: Lukas Czerner
Signed-off-by: Theodore Ts'o
Fixes: bc0ca9df3b2a ("ext4: retry allocation when inline->extent conversion
failed")
Cc: sta...@kernel.org
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/inline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -859,7 +859,7 @@ int ext4_da_write_inline_data_begin(stru
handle_t *handle;
struct page *page;
struct ext4_iloc iloc;
- int retries;
+ int retries = 0;
ret = ext4_get_inode_loc(inode, &iloc);
if (ret)
[PATCH 4.4 045/160] tpm: Restore functionality to xen vtpm driver.
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dr. Greg Wettstein
commit e487a0f52301293152a6f8c4e217f2a11dd808e3 upstream.
Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in commit ccc9d90a9a8b
("xenbus_client: Extend interface to support multi-page ring").
In this commit pointer to location of where the shared page address
is stored was being passed to the xenbus_grant_ring() function rather
then the address of the shared page itself. This resulted in a situation
where the driver would attach to the vtpm-stubdom but any attempt
to send a command to the stub domain would timeout.
A diagnostic finding for this regression is the following error
message being generated when the xen-tpmfront driver probes for a
device:
<3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62
<3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine
the timeouts
This fix is relevant to all kernels from 4.1 forward which is the
release in which multi-page xenbus support was introduced.
Daniel De Graaf formulated the fix by code inspection after the
regression point was located.
Fixes: ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page
ring")
Signed-off-by: Dr. Greg Wettstein
Signed-off-by: Greg Kroah-Hartman
[boris: Updated commit message, added Fixes tag]
Signed-off-by: Boris Ostrovsky
Cc: sta...@vger.kernel.org # v4.1+
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/xen-tpmfront.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -201,7 +201,7 @@ static int setup_ring(struct xenbus_devi
return -ENOMEM;
}
- rv = xenbus_grant_ring(dev, &priv->shr, 1, &gref);
+ rv = xenbus_grant_ring(dev, priv->shr, 1, &gref);
if (rv < 0)
return rv;
[PATCH 4.4 046/160] xen: fix race in xen_qlock_wait()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Juergen Gross
commit 2ac2a7d4d9ff4e01e36f9c3d116582f6f655ab47 upstream.
In the following situation a vcpu waiting for a lock might not be
woken up from xen_poll_irq():
CPU 1:CPU 2: CPU 3:
takes a spinlock
tries to get lock
-> xen_qlock_wait()
frees the lock
-> xen_qlock_kick(cpu2)
-> xen_clear_irq_pending()
takes lock again
tries to get lock
-> *lock = _Q_SLOW_VAL
-> *lock == _Q_SLOW_VAL ?
-> xen_poll_irq()
frees the lock
-> xen_qlock_kick(cpu3)
And cpu 2 will sleep forever.
This can be avoided easily by modifying xen_qlock_wait() to call
xen_poll_irq() only if the related irq was not pending and to call
xen_clear_irq_pending() only if it was pending.
Cc: sta...@vger.kernel.org
Cc: waiman.l...@hp.com
Cc: pet...@infradead.org
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/xen/spinlock.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -47,17 +47,12 @@ static void xen_qlock_wait(u8 *byte, u8
if (irq == -1)
return;
- /* clear pending */
- xen_clear_irq_pending(irq);
- barrier();
+ /* If irq pending already clear it and return. */
+ if (xen_test_irq_pending(irq)) {
+ xen_clear_irq_pending(irq);
+ return;
+ }
- /*
-* We check the byte value after clearing pending IRQ to make sure
-* that we won't miss a wakeup event because of the clearing.
-*
-* The sync_clear_bit() call in xen_clear_irq_pending() is atomic.
-* So it is effectively a memory barrier for x86.
-*/
if (READ_ONCE(*byte) != val)
return;
[PATCH 4.4 051/160] gfs2_meta: ->mount() can get NULL dev_name
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit 3df629d873f8683af6f0d34dfc743f637966d483 upstream.
get in sync with mount_bdev() handling of the same
Reported-by: syzbot+c54f8e94e6bba03b0...@syzkaller.appspotmail.com
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman
---
fs/gfs2/ops_fstype.c |3 +++
1 file changed, 3 insertions(+)
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -1353,6 +1353,9 @@ static struct dentry *gfs2_mount_meta(st
struct path path;
int error;
+ if (!dev_name || !*dev_name)
+ return ERR_PTR(-EINVAL);
+
error = kern_path(dev_name, LOOKUP_FOLLOW, &path);
if (error) {
pr_warn("path_lookup on %s returned error %d\n",
[PATCH 4.4 025/160] pinctrl: qcom: spmi-mpp: Fix err handling of pmic_mpp_set_mux
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: YueHaibing
[ Upstream commit 69f8455f6cc78fa6cdf80d0105d7a748106271dc ]
'ret' should be returned while pmic_mpp_write_mode_ctl fails.
Fixes: 0e948042c420 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode")
Signed-off-by: YueHaibing
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -321,6 +321,8 @@ static int pmic_mpp_set_mux(struct pinct
pad->function = function;
ret = pmic_mpp_write_mode_ctl(state, pad);
+ if (ret < 0)
+ return ret;
val = pad->is_enabled << PMIC_MPP_REG_MASTER_EN_SHIFT;
[PATCH 4.4 043/160] ALSA: hda: Check the non-cached stream buffers more explicitly
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
[ Upstream commit 78c9be61c3a5cd9e2439fd27a5ffad73a81958c7 ]
Introduce a new flag, uc_buffer, to indicate that the controller
requires the non-cached pages for stream buffers, either as a
chip-specific requirement or specified via snoop=0 option.
This improves the code-readability.
Also, this patch fixes the incorrect behavior for C-Media chip where
the stream buffers were never handled as non-cached due to the check
of driver_type even if you pass snoop=0 option.
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
sound/pci/hda/hda_controller.h |1 +
sound/pci/hda/hda_intel.c | 11 ---
2 files changed, 9 insertions(+), 3 deletions(-)
--- a/sound/pci/hda/hda_controller.h
+++ b/sound/pci/hda/hda_controller.h
@@ -151,6 +151,7 @@ struct azx {
unsigned int msi:1;
unsigned int probing:1; /* codec probing phase */
unsigned int snoop:1;
+ unsigned int uc_buffer:1; /* non-cached pages for stream buffers */
unsigned int align_buffer_size:1;
unsigned int region_requested:1;
unsigned int disabled:1; /* disabled by vga_switcheroo */
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -401,7 +401,7 @@ static void __mark_pages_wc(struct azx *
#ifdef CONFIG_SND_DMA_SGBUF
if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_SG) {
struct snd_sg_buf *sgbuf = dmab->private_data;
- if (chip->driver_type == AZX_DRIVER_CMEDIA)
+ if (!chip->uc_buffer)
return; /* deal with only CORB/RIRB buffers */
if (on)
set_pages_array_wc(sgbuf->page_table, sgbuf->pages);
@@ -1538,6 +1538,7 @@ static void azx_check_snoop_available(st
dev_info(chip->card->dev, "Force to %s mode by module option\n",
snoop ? "snoop" : "non-snoop");
chip->snoop = snoop;
+ chip->uc_buffer = !snoop;
return;
}
@@ -1558,8 +1559,12 @@ static void azx_check_snoop_available(st
snoop = false;
chip->snoop = snoop;
- if (!snoop)
+ if (!snoop) {
dev_info(chip->card->dev, "Force to non-snoop mode\n");
+ /* C-Media requires non-cached pages only for CORB/RIRB */
+ if (chip->driver_type != AZX_DRIVER_CMEDIA)
+ chip->uc_buffer = true;
+ }
}
static void azx_probe_work(struct work_struct *work)
@@ -1958,7 +1963,7 @@ static void pcm_mmap_prepare(struct snd_
#ifdef CONFIG_X86
struct azx_pcm *apcm = snd_pcm_substream_chip(substream);
struct azx *chip = apcm->chip;
- if (!azx_snoop(chip) && chip->driver_type != AZX_DRIVER_CMEDIA)
+ if (chip->uc_buffer)
area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
#endif
}
[PATCH 4.4 040/160] scsi: lpfc: Correct soft lockup when running mds diagnostics
4.4-stable review patch. If anyone has any objections, please let me know. -- From: James Smart [ Upstream commit 0ef01a2d95fd62bb4f536e7ce4d5e8e74b97a244 ] When running an mds diagnostic that passes frames with the switch, soft lockups are detected. The driver is in a CQE processing loop and has sufficient amount of traffic that it never exits the ring processing routine, thus the "lockup". Cap the number of elements in the work processing routine to 64 elements. This ensures that the cpu will be given up and the handler reschedule to process additional items. Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/scsi/lpfc/lpfc_sli.c |7 +++ 1 file changed, 7 insertions(+) --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -3485,6 +3485,7 @@ lpfc_sli_handle_slow_ring_event_s4(struc struct hbq_dmabuf *dmabuf; struct lpfc_cq_event *cq_event; unsigned long iflag; + int count = 0; spin_lock_irqsave(&phba->hbalock, iflag); phba->hba_flag &= ~HBA_SP_QUEUE_EVT; @@ -3506,16 +3507,22 @@ lpfc_sli_handle_slow_ring_event_s4(struc if (irspiocbq) lpfc_sli_sp_handle_rspiocb(phba, pring, irspiocbq); + count++; break; case CQE_CODE_RECEIVE: case CQE_CODE_RECEIVE_V1: dmabuf = container_of(cq_event, struct hbq_dmabuf, cq_event); lpfc_sli4_handle_received_buffer(phba, dmabuf); + count++; break; default: break; } + + /* Limit the number of events to 64 to avoid soft lockups */ + if (count == 64) + break; } }
[PATCH 4.4 041/160] signal: Always deliver the kernels SIGKILL and SIGSTOP to a pid namespace init
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "Eric W. Biederman"
[ Upstream commit 3597dfe01d12f570bc739da67f857fd222a3ea66 ]
Instead of playing whack-a-mole and changing SEND_SIG_PRIV to
SEND_SIG_FORCED throughout the kernel to ensure a pid namespace init
gets signals sent by the kernel, stop allowing a pid namespace init to
ignore SIGKILL or SIGSTOP sent by the kernel. A pid namespace init is
only supposed to be able to ignore signals sent from itself and
children with SIG_DFL.
Fixes: 921cf9f63089 ("signals: protect cinit from unblocked SIG_DFL signals")
Reviewed-by: Thomas Gleixner
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/signal.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -991,7 +991,7 @@ static int __send_signal(int sig, struct
result = TRACE_SIGNAL_IGNORED;
if (!prepare_signal(sig, t,
- from_ancestor_ns || (info == SEND_SIG_FORCED)))
+ from_ancestor_ns || (info == SEND_SIG_PRIV) || (info ==
SEND_SIG_FORCED)))
goto ret;
pending = group ? &t->signal->shared_pending : &t->pending;
[PATCH 4.4 050/160] jbd2: fix use after free in jbd2_log_do_checkpoint()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Jan Kara
commit ccd3c4373eacb044eb3832966299d13d2631f66f upstream.
The code cleaning transaction's lists of checkpoint buffers has a bug
where it increases bh refcount only after releasing
journal->j_list_lock. Thus the following race is possible:
CPU0CPU1
jbd2_log_do_checkpoint()
jbd2_journal_try_to_free_buffers()
__journal_try_to_free_buffer(bh)
...
while (transaction->t_checkpoint_io_list)
...
if (buffer_locked(bh)) {
<-- IO completes now, buffer gets unlocked -->
spin_unlock(&journal->j_list_lock);
spin_lock(&journal->j_list_lock);
__jbd2_journal_remove_checkpoint(jh);
spin_unlock(&journal->j_list_lock);
try_to_free_buffers(page);
get_bh(bh) <-- accesses freed bh
Fix the problem by grabbing bh reference before unlocking
journal->j_list_lock.
Fixes: dc6e8d669cf5 ("jbd2: don't call get_bh() before calling
__jbd2_journal_remove_checkpoint()")
Fixes: be1158cc615f ("jbd2: fold __process_buffer() into
jbd2_log_do_checkpoint()")
Reported-by: syzbot+7f4a27091759e2fe7...@syzkaller.appspotmail.com
CC: sta...@vger.kernel.org
Reviewed-by: Lukas Czerner
Signed-off-by: Jan Kara
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman
---
fs/jbd2/checkpoint.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -254,8 +254,8 @@ restart:
bh = jh2bh(jh);
if (buffer_locked(bh)) {
- spin_unlock(&journal->j_list_lock);
get_bh(bh);
+ spin_unlock(&journal->j_list_lock);
wait_on_buffer(bh);
/* the journal_head may have gone by now */
BUFFER_TRACE(bh, "brelse");
@@ -336,8 +336,8 @@ restart2:
jh = transaction->t_checkpoint_io_list;
bh = jh2bh(jh);
if (buffer_locked(bh)) {
- spin_unlock(&journal->j_list_lock);
get_bh(bh);
+ spin_unlock(&journal->j_list_lock);
wait_on_buffer(bh);
/* the journal_head may have gone by now */
BUFFER_TRACE(bh, "brelse");
[PATCH 4.4 048/160] net/ipv4: defensive cipso option parsing
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Stefan Nuernberger
commit 076ed3da0c9b2f88d9157dbe7044a45641ae369e upstream.
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.
Signed-off-by: Stefan Nuernberger
Cc: David Woodhouse
Cc: Simon Veith
Cc: sta...@vger.kernel.org
Acked-by: Paul Moore
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/cipso_ipv4.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1582,7 +1582,7 @@ static int cipso_v4_parsetag_loc(const s
*
* Description:
* Parse the packet's IP header looking for a CIPSO option. Returns a pointer
- * to the start of the CIPSO option on success, NULL if one if not found.
+ * to the start of the CIPSO option on success, NULL if one is not found.
*
*/
unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
@@ -1592,10 +1592,8 @@ unsigned char *cipso_v4_optptr(const str
int optlen;
int taglen;
- for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
+ for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 1; ) {
switch (optptr[0]) {
- case IPOPT_CIPSO:
- return optptr;
case IPOPT_END:
return NULL;
case IPOPT_NOOP:
@@ -1604,6 +1602,11 @@ unsigned char *cipso_v4_optptr(const str
default:
taglen = optptr[1];
}
+ if (!taglen || taglen > optlen)
+ return NULL;
+ if (optptr[0] == IPOPT_CIPSO)
+ return optptr;
+
optlen -= taglen;
optptr += taglen;
}
[PATCH 4.4 049/160] libnvdimm: Hold reference on parent while scheduling async init
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alexander Duyck
commit b6eae0f61db27748606cc00dafcfd1e2c032f0a5 upstream.
Unlike asynchronous initialization in the core we have not yet associated
the device with the parent, and as such the device doesn't hold a reference
to the parent.
In order to resolve that we should be holding a reference on the parent
until the asynchronous initialization has completed.
Cc:
Fixes: 4d88a97aa9e8 ("libnvdimm: ...base ... infrastructure")
Signed-off-by: Alexander Duyck
Signed-off-by: Dan Williams
Signed-off-by: Greg Kroah-Hartman
---
drivers/nvdimm/bus.c |4
1 file changed, 4 insertions(+)
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -158,6 +158,8 @@ static void nd_async_device_register(voi
put_device(dev);
}
put_device(dev);
+ if (dev->parent)
+ put_device(dev->parent);
}
static void nd_async_device_unregister(void *d, async_cookie_t cookie)
@@ -175,6 +177,8 @@ static void nd_async_device_unregister(v
void __nd_device_register(struct device *dev)
{
dev->bus = &nvdimm_bus_type;
+ if (dev->parent)
+ get_device(dev->parent);
get_device(dev);
async_schedule_domain(nd_async_device_register, dev,
&nd_async_domain);
[PATCH 4.4 008/160] ALSA: hda - Add mic quirk for the Lenovo G50-30 (17aa:3905)
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jeremy Cline commit e7bb6ad5685f05685dd8a6a5eda7bfcd14d5f95b upstream. The Lenovo G50-30, like other G50 models, has a Conexant codec that requires a quirk for its inverted stereo dmic. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1249364 Reported-by: Alexander Ploumistos Tested-by: Alexander Ploumistos Cc: sta...@vger.kernel.org Signed-off-by: Jeremy Cline Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/hda/patch_conexant.c |1 + 1 file changed, 1 insertion(+) --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -867,6 +867,7 @@ static const struct snd_pci_quirk cxt506 SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD), + SND_PCI_QUIRK(0x17aa, 0x3905, "Lenovo G50-30", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
[PATCH 4.4 034/160] tpm: suppress transmit cmd error logs when TPM 1.2 is disabled/deactivated
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Javier Martinez Canillas
[ Upstream commit 0d6d0d62d9505a9816716aa484ebd0b04c795063 ]
For TPM 1.2 chips the system setup utility allows to set the TPM device in
one of the following states:
* Active: Security chip is functional
* Inactive: Security chip is visible, but is not functional
* Disabled: Security chip is hidden and is not functional
When choosing the "Inactive" state, the TPM 1.2 device is enumerated and
registered, but sending TPM commands fail with either TPM_DEACTIVATED or
TPM_DISABLED depending if the firmware deactivated or disabled the TPM.
Since these TPM 1.2 error codes don't have special treatment, inactivating
the TPM leads to a very noisy kernel log buffer that shows messages like
the following:
tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78)
tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
tpm tpm0: TPM is disabled/deactivated (0x6)
tpm tpm0: A TPM error (6) occurred attempting get random
tpm tpm0: A TPM error (6) occurred attempting to read a pcr value
ima: No TPM chip found, activating TPM-bypass! (rc=6)
tpm tpm0: A TPM error (6) occurred attempting get random
tpm tpm0: A TPM error (6) occurred attempting get random
tpm tpm0: A TPM error (6) occurred attempting get random
tpm tpm0: A TPM error (6) occurred attempting get random
Let's just suppress error log messages for the TPM_{DEACTIVATED,DISABLED}
return codes, since this is expected when the TPM 1.2 is set to Inactive.
In that case the kernel log is cleaner and less confusing for users, i.e:
tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78)
tpm tpm0: TPM is disabled/deactivated (0x6)
ima: No TPM chip found, activating TPM-bypass! (rc=6)
Reported-by: Hans de Goede
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/char/tpm/tpm-interface.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -415,7 +415,8 @@ ssize_t tpm_transmit_cmd(struct tpm_chip
header = cmd;
err = be32_to_cpu(header->return_code);
- if (err != 0 && desc)
+ if (err != 0 && err != TPM_ERR_DISABLED && err != TPM_ERR_DEACTIVATED
+ && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
[PATCH 4.4 039/160] uio: ensure class is registered before devices
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Alexandre Belloni
[ Upstream commit ae61cf5b9913027c6953a79ed3894da4f47061bd ]
When both uio and the uio drivers are built in the kernel, it is possible
for a driver to register devices before the uio class is registered.
This may result in a NULL pointer dereference later on in
get_device_parent() when accessing the class glue_dirs spinlock.
The trace looks like that:
Unable to handle kernel NULL pointer dereference at virtual address 0140
[...]
[] _raw_spin_lock+0x14/0x48
[] device_add+0x154/0x6a0
[] device_create_groups_vargs+0x120/0x128
[] device_create+0x54/0x60
[] __uio_register_device+0x120/0x4a8
[] jaguar2_pci_probe+0x2d4/0x558
[] local_pci_probe+0x3c/0xb8
[] pci_device_probe+0x11c/0x180
[] driver_probe_device+0x22c/0x2d8
[] __driver_attach+0xbc/0xc0
[] bus_for_each_dev+0x4c/0x98
[] driver_attach+0x20/0x28
[] bus_add_driver+0x1b8/0x228
[] driver_register+0x60/0xf8
[] __pci_register_driver+0x40/0x48
Return EPROBE_DEFER in that case so the driver can register the device
later.
Signed-off-by: Alexandre Belloni
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/uio/uio.c |9 +
1 file changed, 9 insertions(+)
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -249,6 +249,8 @@ static struct class uio_class = {
.dev_groups = uio_groups,
};
+bool uio_class_registered;
+
/*
* device functions
*/
@@ -772,6 +774,9 @@ static int init_uio_class(void)
printk(KERN_ERR "class_register failed for uio\n");
goto err_class_register;
}
+
+ uio_class_registered = true;
+
return 0;
err_class_register:
@@ -782,6 +787,7 @@ exit:
static void release_uio_class(void)
{
+ uio_class_registered = false;
class_unregister(&uio_class);
uio_major_cleanup();
}
@@ -801,6 +807,9 @@ int __uio_register_device(struct module
struct uio_device *idev;
int ret = 0;
+ if (!uio_class_registered)
+ return -EPROBE_DEFER;
+
if (!parent || !info || !info->name || !info->version)
return -EINVAL;
[PATCH 4.4 006/160] parisc: Fix address in HPMC IVA
4.4-stable review patch. If anyone has any objections, please let me know. -- From: John David Anglin commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream. Helge noticed that the address of the os_hpmc handler was not being correctly calculated in the hpmc macro. As a result, PDCE_CHECK would fail to call os_hpmc: e89802e0 CC_ERR_CHECK_HPMC 37000f7302e0 80400040 CC_ERR_CPU_CHECK_SUMMARY f600105e02e0 fff0f0c0 CC_MC_HPMC_MONARCH_SELECTED 140003b202e0 000b CC_ERR_HPMC_STATE_ENTRY 5600100b02e0 01a0 CC_MC_OS_HPMC_LEN_ERR 5600106402e0 fff0f0438e70 CC_MC_BR_TO_OS_HPMC_FAILED e89802e0 CC_ERR_CHECK_HPMC 37000f7302e0 80400040 CC_ERR_CPU_CHECK_SUMMARY 4000109f02e0 CC_MC_HPMC_INITIATED 4000101902e0 CC_MC_MULTIPLE_HPMCS 030010d502e0 CC_CPU_STOP The address problem can be seen by dumping the fault vector: 40159000 : 40159000: 63 6f 77 73 stb r15,-2447(dp) 40159004: 20 63 61 6e ldil L%b747000,r3 40159008: 20 66 6c 79 ldil L%-1c3b3000,r3 ... 40159020: 08 00 02 40 nop 40159024: 20 6e 60 02 ldil L%15d000,r3 40159028: 34 63 00 00 ldo 0(r3),r3 4015902c: e8 60 c0 02 bv,n r0(r3) 40159030: 08 00 02 40 nop 40159034: 00 00 00 00 break 0,0 40159038: c0 00 70 00 bb,*< r0,sar,40159840 4015903c: 00 00 00 00 break 0,0 Location 40159038 should contain the physical address of os_hpmc: 4015d000 : 4015d000: 08 1a 02 43 copy r26,r3 4015d004: 01 c0 08 a4 mfctl iva,r4 4015d008: 48 85 00 68 ldw 34(r4),r5 This patch moves the address setup into initialize_ivt to resolve the above problem. I tested the change by dumping the HPMC entry after setup: 40209020: 8000240 40209024: 206a2004 40209028: 34630ac0 4020902c: e860c002 40209030: 8000240 40209034: 1bdddce6 40209038: 15d000 4020903c: 1a0 Signed-off-by: John David Anglin Cc: Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman --- arch/parisc/kernel/entry.S |2 +- arch/parisc/kernel/traps.c |3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) --- a/arch/parisc/kernel/entry.S +++ b/arch/parisc/kernel/entry.S @@ -185,7 +185,7 @@ bv,n0(%r3) nop .word 0 /* checksum (will be patched) */ - .word PA(os_hpmc) /* address of handler */ + .word 0 /* address of handler */ .word 0 /* length of handler */ .endm --- a/arch/parisc/kernel/traps.c +++ b/arch/parisc/kernel/traps.c @@ -829,7 +829,8 @@ void __init initialize_ivt(const void *i for (i = 0; i < 8; i++) *ivap++ = 0; - /* Compute Checksum for HPMC handler */ + /* Setup IVA and compute checksum for HPMC handler */ + ivap[6] = (u32)__pa(os_hpmc); length = os_hpmc_size; ivap[7] = length;
[PATCH 4.4 037/160] usb: chipidea: Prevent unbalanced IRQ disable
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Loic Poulain
[ Upstream commit 8b97d73c4d72a2abf58f8e49062a7ee1e5f1334e ]
The ChipIdea IRQ is disabled before scheduling the otg work and
re-enabled on otg work completion. However if the job is already
scheduled we have to undo the effect of disable_irq int order to
balance the IRQ disable-depth value.
Fixes: be6b0c1bd0be ("usb: chipidea: using one inline function to cover queue
work operations")
Signed-off-by: Loic Poulain
Signed-off-by: Peter Chen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/chipidea/otg.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -20,7 +20,8 @@ void ci_handle_vbus_change(struct ci_hdr
static inline void ci_otg_queue_work(struct ci_hdrc *ci)
{
disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ if (queue_work(ci->wq, &ci->work) == false)
+ enable_irq(ci->irq);
}
#endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
[PATCH 4.4 007/160] parisc: Fix map_pages() to not overwrite existing pte entries
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Helge Deller
commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream.
Fix a long-existing small nasty bug in the map_pages() implementation which
leads to overwriting already written pte entries with zero, *if* map_pages() is
called a second time with an end address which isn't aligned on a pmd boundry.
This happens for example if we want to remap only the text segment read/write
in order to run alternative patching on the code. Exiting the loop when we
reach the end address fixes this.
Cc: sta...@vger.kernel.org
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman
---
arch/parisc/mm/init.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -491,12 +491,8 @@ static void __init map_pages(unsigned lo
pte = pte_mkhuge(pte);
}
- if (address >= end_paddr) {
- if (force)
- break;
- else
- pte_val(pte) = 0;
- }
+ if (address >= end_paddr)
+ break;
set_pte(pg_table, pte);
[PATCH 4.4 000/160] 4.4.164-stable review
This is the start of the stable review cycle for the 4.4.164 release. There are 160 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 21 16:25:20 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.164-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.4.164-rc1 Clint Taylor drm/i915/hdmi: Add HDMI 2.0 audio clock recovery N values Stanislav Lisovskiy drm/dp_mst: Check if primary mstb is null Marc Zyngier drm/rockchip: Allow driver to be shutdown on reboot/kexec Mike Kravetz mm: migration: fix migration of huge PMD shared pages Mike Kravetz hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444! Guenter Roeck configfs: replace strncpy with memcpy Miklos Szeredi fuse: fix leaked notify reply Maciej W. Rozycki rtc: hctosys: Add missing range error reporting Frank Sorenson sunrpc: correct the computation for page_ptr when truncating Eric W. Biederman mount: Prevent MNT_DETACH from disconnecting locked mounts Eric W. Biederman mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts Eric W. Biederman mount: Retest MNT_LOCKED in do_umount Vasily Averin ext4: fix buffer leak in __ext4_read_dirblock() on error path Vasily Averin ext4: fix buffer leak in ext4_xattr_move_to_block() on error path Vasily Averin ext4: release bs.bh before re-using in ext4_xattr_block_find() Theodore Ts'o ext4: fix possible leak of sbi->s_group_desc_leak in error path Theodore Ts'o ext4: avoid possible double brelse() in add_new_gdb() on error path Vasily Averin ext4: fix missing cleanup if ext4_alloc_flex_bg_array() fails while resizing Vasily Averin ext4: avoid buffer leak in ext4_orphan_add() after prior errors Vasily Averin ext4: fix possible inode leak in the retry loop of ext4_resize_fs() Vasily Averin ext4: avoid potential extra brelse in setup_new_flex_group_blocks() Vasily Averin ext4: add missing brelse() add_new_gdb_meta_bg()'s error path Vasily Averin ext4: add missing brelse() in set_flexbg_block_bitmap()'s error path Vasily Averin ext4: add missing brelse() update_backups()'s error path Michael Kelley clockevents/drivers/i8253: Add support for PIT shutdown quirk Filipe Manana Btrfs: fix data corruption due to cloning of eof block H. Peter Anvin (Intel) arch/alpha, termios: implement BOTHER, IBSHIFT and termios2 H. Peter Anvin termios, tty/tty_baudrate.c: fix buffer overrun Arnd Bergmann mtd: docg3: don't set conflicting BCH_CONST_PARAMS option Andrea Arcangeli mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings Changwei Ge ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry Greg Edwards vhost/scsi: truncate T10 PI iov_iter to prot_bytes Mikulas Patocka mach64: fix image corruption due to reading accelerator registers Mikulas Patocka mach64: fix display corruption on big endian machines Ilya Dryomov libceph: bump CEPH_MSG_MAX_DATA_LEN Krzysztof Kozlowski clk: s2mps11: Fix matching when built as module and DT node contains compatible Max Filippov xtensa: fix boot parameters address translation Max Filippov xtensa: make sure bFLT stack is 16 byte aligned Max Filippov xtensa: add NOTES section to the linker script Huacai Chen MIPS: Loongson-3: Fix BRIDGE irq delivery problem Huacai Chen MIPS: Loongson-3: Fix CPU UART irq delivery problem Kees Cook bna: ethtool: Avoid reading past end of buffer Vincenzo Maffione e1000: fix race condition between e1000_down() and e1000_watchdog Colin Ian King e1000: avoid null pointer dereference on invalid stat type Michal Hocko mm: do not bug_on on incorrect length in __mm_populate() Oscar Salvador fs, elf: make sure to page align bss in load_elf_library Kees Cook mm: refuse wrapped vm_brk requests Kees Cook binfmt_elf: fix calculations for bss padding Michal Hocko mm, elf: handle vm_brk error Miklos Szeredi fuse: set FR_SENT while locked Miklos Szeredi fuse: fix blocked_waitq wakeup Kirill Tkhai fuse: Fix use-after-free in fuse_dev_do_write() Kirill Tkhai fuse: Fix use-after-free in fuse_dev_do_read() Himanshu Madhani scsi: qla2xxx: Fix incorrect port speed being set for FC adapters Young_X cdrom: fix improper type cast, which can leat to information leak. Dominique Martinet 9p: clear dangling pointers in p9stat_free Dominique Martinet 9p locks: fix glo
[PATCH 4.4 038/160] driver/dma/ioat: Call del_timer_sync() without holding prep_lock
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Waiman Long
[ Upstream commit cfb03be6c7e8a1591285849c361d67b09f5149f7 ]
The following lockdep splat was observed:
[ 1222.241750] ==
[ 1222.271301] WARNING: possible circular locking dependency detected
[ 1222.301060] 4.16.0-10.el8+5.x86_64+debug #1 Not tainted
[ 1222.326659] --
[ 1222.356565] systemd-shutdow/1 is trying to acquire lock:
[ 1222.382660] ((&ioat_chan->timer)){+.-.}, at: []
del_timer_sync+0x5/0xf0
[ 1222.422928]
[ 1222.422928] but task is already holding lock:
[ 1222.451743] (&(&ioat_chan->prep_lock)->rlock){+.-.}, at:
[<8ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma]
:
[ 1223.524987] Chain exists of:
[ 1223.524987] (&ioat_chan->timer) --> &(&ioat_chan->cleanup_lock)->rlock -->
&(&ioat_chan->prep_lock)->rlock
[ 1223.524987]
[ 1223.594082] Possible unsafe locking scenario:
[ 1223.594082]
[ 1223.622630]CPU0CPU1
[ 1223.645080]
[ 1223.667404] lock(&(&ioat_chan->prep_lock)->rlock);
[ 1223.691535]
lock(&(&ioat_chan->cleanup_lock)->rlock);
[ 1223.728657]
lock(&(&ioat_chan->prep_lock)->rlock);
[ 1223.765122] lock((&ioat_chan->timer));
[ 1223.784095]
[ 1223.784095] *** DEADLOCK ***
[ 1223.784095]
[ 1223.813492] 4 locks held by systemd-shutdow/1:
[ 1223.834677] #0: (reboot_mutex){+.+.}, at: [<56d33456>]
SYSC_reboot+0x10f/0x300
[ 1223.873310] #1: (&dev->mutex){}, at: [<258dfdd7>]
device_shutdown+0x1c8/0x660
[ 1223.913604] #2: (&dev->mutex){}, at: [<68331147>]
device_shutdown+0x1d6/0x660
[ 1223.954000] #3: (&(&ioat_chan->prep_lock)->rlock){+.-.}, at:
[<8ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma]
In the ioat_shutdown() function:
spin_lock_bh(&ioat_chan->prep_lock);
set_bit(IOAT_CHAN_DOWN, &ioat_chan->state);
del_timer_sync(&ioat_chan->timer);
spin_unlock_bh(&ioat_chan->prep_lock);
According to the synchronization rule for the del_timer_sync() function,
the caller must not hold locks which would prevent completion of the
timer's handler.
The timer structure has its own lock that manages its synchronization.
Setting the IOAT_CHAN_DOWN bit should prevent other CPUs from
trying to use that device anyway, there is probably no need to call
del_timer_sync() while holding the prep_lock. So the del_timer_sync()
call is now moved outside of the prep_lock critical section to prevent
the circular lock dependency.
Signed-off-by: Waiman Long
Reviewed-by: Dave Jiang
Signed-off-by: Vinod Koul
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/dma/ioat/init.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -1210,8 +1210,15 @@ static void ioat_shutdown(struct pci_dev
spin_lock_bh(&ioat_chan->prep_lock);
set_bit(IOAT_CHAN_DOWN, &ioat_chan->state);
- del_timer_sync(&ioat_chan->timer);
spin_unlock_bh(&ioat_chan->prep_lock);
+ /*
+* Synchronization rule for del_timer_sync():
+* - The caller must not hold locks which would prevent
+*completion of the timer's handler.
+* So prep_lock cannot be held before calling it.
+*/
+ del_timer_sync(&ioat_chan->timer);
+
/* this should quiesce then reset */
ioat_reset_hw(ioat_chan);
}
[PATCH 4.4 005/160] ipmi: Fix timer race with module unload
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Jan Glauber commit 0711e8c1b4572d076264e71b0002d223f2666ed7 upstream. Please note that below oops is from an older kernel, but the same race seems to be present in the upstream kernel too. ---8<--- The following panic was encountered during removing the ipmi_ssif module: [ 526.352555] Unable to handle kernel paging request at virtual address 06923090 [ 526.360464] Mem abort info: [ 526.363257] ESR = 0x8607 [ 526.366304] Exception class = IABT (current EL), IL = 32 bits [ 526.372221] SET = 0, FnV = 0 [ 526.375269] EA = 0, S1PTW = 0 [ 526.378405] swapper pgtable: 4k pages, 48-bit VAs, pgd = 8ae60416 [ 526.385185] [06923090] *pgd=00bffcffe803, *pud=00bffcffd803, *pmd=009f4731a003, *pte= [ 526.396141] Internal error: Oops: 8607 [#1] SMP [ 526.401008] Modules linked in: nls_iso8859_1 ipmi_devintf joydev input_leds ipmi_msghandler shpchp sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear i2c_smbus hid_generic usbhid uas hid usb_storage ast aes_ce_blk i2c_algo_bit aes_ce_cipher qede ttm crc32_ce ptp crct10dif_ce drm_kms_helper ghash_ce syscopyarea sha2_ce sysfillrect sysimgblt pps_core fb_sys_fops sha256_arm64 sha1_ce mpt3sas qed drm raid_class ahci scsi_transport_sas libahci gpio_xlp i2c_xlp9xx aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [last unloaded: ipmi_ssif] [ 526.468085] CPU: 125 PID: 0 Comm: swapper/125 Not tainted 4.15.0-35-generic #38~lp1775396+build.1 [ 526.476942] Hardware name: To be filled by O.E.M. Saber/Saber, BIOS 0ACKL022 08/14/2018 [ 526.484932] pstate: 0049 (nzcv daif +PAN -UAO) [ 526.489713] pc : 0x06923090 [ 526.493198] lr : call_timer_fn+0x34/0x178 [ 526.497194] sp : 09b0bdd0 [ 526.500496] x29: 09b0bdd0 x28: 0082 [ 526.505796] x27: 0002 x26: 09515188 [ 526.511096] x25: 09515180 x24: 090f1018 [ 526.516396] x23: 09519660 x22: dead0200 [ 526.521696] x21: 06923090 x20: 0100 [ 526.526995] x19: 809eeb466a40 x18: [ 526.532295] x17: 000e x16: 0007 [ 526.537594] x15: x14: 071c71c71c71c71c [ 526.542894] x13: x12: [ 526.548193] x11: 0001 x10: 09b0be88 [ 526.553493] x9 : x8 : 0005 [ 526.558793] x7 : 80befc1f8528 x6 : 0020 [ 526.564092] x5 : 0040 x4 : 20001b20 [ 526.569392] x3 : x2 : 809eeb466a40 [ 526.574692] x1 : 06923090 x0 : 809eeb466a40 [ 526.579992] Process swapper/125 (pid: 0, stack limit = 0x2eb50acc) [ 526.586854] Call trace: [ 526.589289] 0x06923090 [ 526.592419] expire_timers+0xc8/0x130 [ 526.596070] run_timer_softirq+0xec/0x1b0 [ 526.600070] __do_softirq+0x134/0x328 [ 526.603726] irq_exit+0xc8/0xe0 [ 526.606857] __handle_domain_irq+0x6c/0xc0 [ 526.610941] gic_handle_irq+0x84/0x188 [ 526.614679] el1_irq+0xe8/0x180 [ 526.617822] cpuidle_enter_state+0xa0/0x328 [ 526.621993] cpuidle_enter+0x34/0x48 [ 526.625564] call_cpuidle+0x44/0x70 [ 526.629040] do_idle+0x1b8/0x1f0 [ 526.632256] cpu_startup_entry+0x2c/0x30 [ 526.636174] secondary_start_kernel+0x11c/0x130 [ 526.640694] Code: bad PC value [ 526.643800] ---[ end trace d020b0b8417c2498 ]--- [ 526.648404] Kernel panic - not syncing: Fatal exception in interrupt [ 526.654778] SMP: stopping secondary CPUs [ 526.658734] Kernel Offset: disabled [ 526.662211] CPU features: 0x5800c38 [ 526.665688] Memory Limit: none [ 526.668768] ---[ end Kernel panic - not syncing: Fatal exception in interrupt Prevent mod_timer from arming a timer that was already removed by del_timer during module unload. Signed-off-by: Jan Glauber Cc: # 3.19 Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman --- drivers/char/ipmi/ipmi_ssif.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) --- a/drivers/char/ipmi/ipmi_ssif.c +++ b/drivers/char/ipmi/ipmi_ssif.c @@ -613,8 +613,9 @@ static void msg_done_handler(struct ssif flags = ipmi_ssif_lock_cond(ssif_info, &oflags); ssif_info->waiting_alert = true; ssif_info->rtc_us_timer = SSIF_MSG_USEC; - mod_timer(&ssif_info->retry_timer, - jiffies + SSIF_MSG_JIFFIES); + if (!ssif_info->stopping) + mod_timer(&ssif_info->retry_timer, + jiffies + SSIF_MSG_JIFFIES); ipmi_ssif_unlock_cond(ssif_info, flags);
[PATCH 4.4 004/160] pcmcia: Implement CLKRUN protocol disabling for Ricoh bridges
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Maciej S. Szmigiero
commit 95691e3eddc41da2d1cd3cca51fecdfb46bd85bc upstream.
Currently, "disable_clkrun" yenta_socket module parameter is only
implemented for TI CardBus bridges.
Add also an implementation for Ricoh bridges that have the necessary
setting documented in publicly available datasheets.
Tested on a RL5C476II with a Sunrich C-160 CardBus NIC that doesn't work
correctly unless the CLKRUN protocol is disabled.
Let's also make it clear in its description that the "disable_clkrun"
module parameter only works on these two previously mentioned brands of
CardBus bridges.
Signed-off-by: Maciej S. Szmigiero
Cc: sta...@vger.kernel.org
Signed-off-by: Dominik Brodowski
Signed-off-by: Greg Kroah-Hartman
---
drivers/pcmcia/ricoh.h| 35 +++
drivers/pcmcia/yenta_socket.c |3 ++-
2 files changed, 37 insertions(+), 1 deletion(-)
--- a/drivers/pcmcia/ricoh.h
+++ b/drivers/pcmcia/ricoh.h
@@ -119,6 +119,10 @@
#define RL5C4XX_MISC_CONTROL 0x2F /* 8 bit */
#define RL5C4XX_ZV_ENABLE 0x08
+/* Misc Control 3 Register */
+#define RL5C4XX_MISC3 0x00A2 /* 16 bit */
+#define RL5C47X_MISC3_CB_CLKRUN_DIS BIT(1)
+
#ifdef __YENTA_H
#define rl_misc(socket)((socket)->private[0])
@@ -156,6 +160,35 @@ static void ricoh_set_zv(struct yenta_so
}
}
+static void ricoh_set_clkrun(struct yenta_socket *socket, bool quiet)
+{
+ u16 misc3;
+
+ /*
+* RL5C475II likely has this setting, too, however no datasheet
+* is publicly available for this chip
+*/
+ if (socket->dev->device != PCI_DEVICE_ID_RICOH_RL5C476 &&
+ socket->dev->device != PCI_DEVICE_ID_RICOH_RL5C478)
+ return;
+
+ if (socket->dev->revision < 0x80)
+ return;
+
+ misc3 = config_readw(socket, RL5C4XX_MISC3);
+ if (misc3 & RL5C47X_MISC3_CB_CLKRUN_DIS) {
+ if (!quiet)
+ dev_dbg(&socket->dev->dev,
+ "CLKRUN feature already disabled\n");
+ } else if (disable_clkrun) {
+ if (!quiet)
+ dev_info(&socket->dev->dev,
+"Disabling CLKRUN feature\n");
+ misc3 |= RL5C47X_MISC3_CB_CLKRUN_DIS;
+ config_writew(socket, RL5C4XX_MISC3, misc3);
+ }
+}
+
static void ricoh_save_state(struct yenta_socket *socket)
{
rl_misc(socket) = config_readw(socket, RL5C4XX_MISC);
@@ -172,6 +205,7 @@ static void ricoh_restore_state(struct y
config_writew(socket, RL5C4XX_16BIT_IO_0, rl_io(socket));
config_writew(socket, RL5C4XX_16BIT_MEM_0, rl_mem(socket));
config_writew(socket, RL5C4XX_CONFIG, rl_config(socket));
+ ricoh_set_clkrun(socket, true);
}
@@ -197,6 +231,7 @@ static int ricoh_override(struct yenta_s
config_writew(socket, RL5C4XX_CONFIG, config);
ricoh_set_zv(socket);
+ ricoh_set_clkrun(socket, false);
return 0;
}
--- a/drivers/pcmcia/yenta_socket.c
+++ b/drivers/pcmcia/yenta_socket.c
@@ -26,7 +26,8 @@
static bool disable_clkrun;
module_param(disable_clkrun, bool, 0444);
-MODULE_PARM_DESC(disable_clkrun, "If PC card doesn't function properly, please
try this option");
+MODULE_PARM_DESC(disable_clkrun,
+"If PC card doesn't function properly, please try this option
(TI and Ricoh bridges only)");
static bool isa_probe = 1;
module_param(isa_probe, bool, 0444);
[PATCH 4.4 009/160] ALSA: ca0106: Disable IZD on SB0570 DAC to fix audio pops
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Alex Stanoev commit ac237c28d5ac1b241d58b1b7b4b9fa10efb22fb5 upstream. The Creative Audigy SE (SB0570) card currently exhibits an audible pop whenever playback is stopped or resumed, or during silent periods of an audio stream. Initialise the IZD bit to the 0 to eliminate these pops. The Infinite Zero Detection (IZD) feature on the DAC causes the output to be shunted to Vcap after 2048 samples of silence. This discharges the AC coupling capacitor through the output and causes the aforementioned pop/click noise. The behaviour of the IZD bit is described on page 15 of the WM8768GEDS datasheet: "With IZD=1, applying MUTE for 1024 consecutive input samples will cause all outputs to be connected directly to VCAP. This also happens if 2048 consecutive zero input samples are applied to all 6 channels, and IZD=0. It will be removed as soon as any channel receives a non-zero input". I believe the second sentence might be referring to IZD=1 instead of IZD=0 given the observed behaviour of the card. This change should make the DAC initialisation consistent with Creative's Windows driver, as this popping persists when initialising the card in Linux and soft rebooting into Windows, but is not present on a cold boot to Windows. Signed-off-by: Alex Stanoev Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman --- sound/pci/ca0106/ca0106.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/pci/ca0106/ca0106.h +++ b/sound/pci/ca0106/ca0106.h @@ -582,7 +582,7 @@ #define SPI_PL_BIT_R_R (2<<7) /* right channel = right */ #define SPI_PL_BIT_R_C (3<<7) /* right channel = (L+R)/2 */ #define SPI_IZD_REG2 -#define SPI_IZD_BIT(1<<4) /* infinite zero detect */ +#define SPI_IZD_BIT(0<<4) /* infinite zero detect */ #define SPI_FMT_REG3 #define SPI_FMT_BIT_RJ (0<<0) /* right justified mode */
[PATCH 4.4 035/160] ext4: fix argument checking in EXT4_IOC_MOVE_EXT
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Theodore Ts'o
[ Upstream commit f18b2b83a727a3db208308057d2c7945f368e625 ]
If the starting block number of either the source or destination file
exceeds the EOF, EXT4_IOC_MOVE_EXT should return EINVAL.
Also fixed the helper function mext_check_coverage() so that if the
logical block is beyond EOF, make it return immediately, instead of
looping until the block number wraps all the away around. This takes
long enough that if there are multiple threads trying to do pound on
an the same inode doing non-sensical things, it can end up triggering
the kernel's soft lockup detector.
Reported-by: syzbot+c61979f6f2cba5cb3...@syzkaller.appspotmail.com
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/move_extent.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/fs/ext4/move_extent.c
+++ b/fs/ext4/move_extent.c
@@ -526,9 +526,13 @@ mext_check_arguments(struct inode *orig_
orig_inode->i_ino, donor_inode->i_ino);
return -EINVAL;
}
- if (orig_eof < orig_start + *len - 1)
+ if (orig_eof <= orig_start)
+ *len = 0;
+ else if (orig_eof < orig_start + *len - 1)
*len = orig_eof - orig_start;
- if (donor_eof < donor_start + *len - 1)
+ if (donor_eof <= donor_start)
+ *len = 0;
+ else if (donor_eof < donor_start + *len - 1)
*len = donor_eof - donor_start;
if (!*len) {
ext4_debug("ext4 move extent: len should not be 0 "
[PATCH 4.4 033/160] scsi: megaraid_sas: fix a missing-check bug
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Wenwen Wang
[ Upstream commit 47db7873136a9c57c45390a53b57019cf73c8259 ]
In megasas_mgmt_compat_ioctl_fw(), to handle the structure
compat_megasas_iocpacket 'cioc', a user-space structure megasas_iocpacket
'ioc' is allocated before megasas_mgmt_ioctl_fw() is invoked to handle
the packet. Since the two data structures have different fields, the data
is copied from 'cioc' to 'ioc' field by field. In the copy process,
'sense_ptr' is prepared if the field 'sense_len' is not null, because it
will be used in megasas_mgmt_ioctl_fw(). To prepare 'sense_ptr', the
user-space data 'ioc->sense_off' and 'cioc->sense_off' are copied and
saved to kernel-space variables 'local_sense_off' and 'user_sense_off'
respectively. Given that 'ioc->sense_off' is also copied from
'cioc->sense_off', 'local_sense_off' and 'user_sense_off' should have the
same value. However, 'cioc' is in the user space and a malicious user can
race to change the value of 'cioc->sense_off' after it is copied to
'ioc->sense_off' but before it is copied to 'user_sense_off'. By doing
so, the attacker can inject different values into 'local_sense_off' and
'user_sense_off'. This can cause undefined behavior in the following
execution, because the two variables are supposed to be same.
This patch enforces a check on the two kernel variables 'local_sense_off'
and 'user_sense_off' to make sure they are the same after the copy. In
case they are not, an error code EINVAL will be returned.
Signed-off-by: Wenwen Wang
Acked-by: Sumit Saxena
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/megaraid/megaraid_sas_base.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -6510,6 +6510,9 @@ static int megasas_mgmt_compat_ioctl_fw(
get_user(user_sense_off, &cioc->sense_off))
return -EFAULT;
+ if (local_sense_off != user_sense_off)
+ return -EINVAL;
+
if (local_sense_len) {
void __user **sense_ioc_ptr =
(void __user **)((u8 *)((unsigned long)&ioc->frame.raw)
+ local_sense_off);
[PATCH 4.4 024/160] x86: boot: Fix EFI stub alignment
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
[ Upstream commit 9c1442a9d039a1a3302fa93e9a11001c5f23b624 ]
We currently align the end of the compressed image to a multiple of
16. However, the PE-COFF header included in the EFI stub says that
the file alignment is 32 bytes, and when adding an EFI signature to
the file it must first be padded to this alignment.
sbsigntool commands warn about this:
warning: file-aligned section .text extends beyond end of file
warning: checksum areas are greater than image size. Invalid section table?
Worse, pesign -at least when creating a detached signature- uses the
hash of the unpadded file, resulting in an invalid signature if
padding is required.
Avoid both these problems by increasing alignment to 32 bytes when
CONFIG_EFI_STUB is enabled.
Signed-off-by: Ben Hutchings
Signed-off-by: Ard Biesheuvel
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/boot/tools/build.c |7 +++
1 file changed, 7 insertions(+)
--- a/arch/x86/boot/tools/build.c
+++ b/arch/x86/boot/tools/build.c
@@ -391,6 +391,13 @@ int main(int argc, char ** argv)
die("Unable to mmap '%s': %m", argv[2]);
/* Number of 16-byte paragraphs, including space for a 4-byte CRC */
sys_size = (sz + 15 + 4) / 16;
+#ifdef CONFIG_EFI_STUB
+ /*
+* COFF requires minimum 32-byte alignment of sections, and
+* adding a signature is problematic without that alignment.
+*/
+ sys_size = (sys_size + 1) & ~1;
+#endif
/* Patch the setup code with the appropriate size parameters */
buf[0x1f1] = setup_sectors-1;
[PATCH 4.4 015/160] selftests: ftrace: Add synthetic event syntax testcase
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
[ Upstream commit ba0e41ca81b935b958006c7120466e2217357827 ]
Add a testcase to check the syntax and field types for
synthetic_events interface.
Link:
http://lkml.kernel.org/r/153986838264.18251.16627517536956299922.stgit@devbox
Acked-by: Shuah Khan
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-syntax.tc
| 80 ++
1 file changed, 80 insertions(+)
create mode 100644
tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-syntax.tc
--- /dev/null
+++
b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic-event-syntax.tc
@@ -0,0 +1,80 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: event trigger - test synthetic_events syntax parser
+
+do_reset() {
+reset_trigger
+echo > set_event
+clear_trace
+}
+
+fail() { #msg
+do_reset
+echo $1
+exit_fail
+}
+
+if [ ! -f set_event ]; then
+echo "event tracing is not supported"
+exit_unsupported
+fi
+
+if [ ! -f synthetic_events ]; then
+echo "synthetic event is not supported"
+exit_unsupported
+fi
+
+reset_tracer
+do_reset
+
+echo "Test synthetic_events syntax parser"
+
+echo > synthetic_events
+
+# synthetic event must have a field
+! echo "myevent" >> synthetic_events
+echo "myevent u64 var1" >> synthetic_events
+
+# synthetic event must be found in synthetic_events
+grep "myevent[[:space:]]u64 var1" synthetic_events
+
+# it is not possible to add same name event
+! echo "myevent u64 var2" >> synthetic_events
+
+# Non-append open will cleanup all events and add new one
+echo "myevent u64 var2" > synthetic_events
+
+# multiple fields with different spaces
+echo "myevent u64 var1; u64 var2;" > synthetic_events
+grep "myevent[[:space:]]u64 var1; u64 var2" synthetic_events
+echo "myevent u64 var1 ; u64 var2 ;" > synthetic_events
+grep "myevent[[:space:]]u64 var1; u64 var2" synthetic_events
+echo "myevent u64 var1 ;u64 var2" > synthetic_events
+grep "myevent[[:space:]]u64 var1; u64 var2" synthetic_events
+
+# test field types
+echo "myevent u32 var" > synthetic_events
+echo "myevent u16 var" > synthetic_events
+echo "myevent u8 var" > synthetic_events
+echo "myevent s64 var" > synthetic_events
+echo "myevent s32 var" > synthetic_events
+echo "myevent s16 var" > synthetic_events
+echo "myevent s8 var" > synthetic_events
+
+echo "myevent char var" > synthetic_events
+echo "myevent int var" > synthetic_events
+echo "myevent long var" > synthetic_events
+echo "myevent pid_t var" > synthetic_events
+
+echo "myevent unsigned char var" > synthetic_events
+echo "myevent unsigned int var" > synthetic_events
+echo "myevent unsigned long var" > synthetic_events
+grep "myevent[[:space:]]unsigned long var" synthetic_events
+
+# test string type
+echo "myevent char var[10]" > synthetic_events
+grep "myevent[[:space:]]char\[10\] var" synthetic_events
+
+do_reset
+
+exit 0
[PATCH 4.4 002/160] hwmon: (pmbus) Fix page count auto-detection.
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Bazhenov
commit e7c6a55606b5c46b449d76588968b4d8caae903f upstream.
Devices with compatible="pmbus" field have zero initial page count,
and pmbus_clear_faults() being called before the page count auto-
detection does not actually clear faults because it depends on the
page count. Non-cleared faults in its turn may fail the subsequent
page count auto-detection.
This patch fixes this problem by calling pmbus_clear_fault_page()
for currently set page and calling pmbus_clear_faults() after the
page count was detected.
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Bazhenov
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/hwmon/pmbus/pmbus.c |2 ++
drivers/hwmon/pmbus/pmbus_core.c |5 -
2 files changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/hwmon/pmbus/pmbus.c
+++ b/drivers/hwmon/pmbus/pmbus.c
@@ -117,6 +117,8 @@ static int pmbus_identify(struct i2c_cli
} else {
info->pages = 1;
}
+
+ pmbus_clear_faults(client);
}
if (pmbus_check_byte_register(client, 0, PMBUS_VOUT_MODE)) {
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -1759,7 +1759,10 @@ static int pmbus_init_common(struct i2c_
if (ret >= 0 && (ret & PB_CAPABILITY_ERROR_CHECK))
client->flags |= I2C_CLIENT_PEC;
- pmbus_clear_faults(client);
+ if (data->info->pages)
+ pmbus_clear_faults(client);
+ else
+ pmbus_clear_fault_page(client, -1);
if (info->identify) {
ret = (*info->identify)(client, info);
[PATCH 4.4 021/160] perf tools: Cleanup trace-event-info tdata leak
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sanskriti Sharma
[ Upstream commit faedbf3fd19f2511a39397f76359e4cc6ee93072 ]
Free tracing_data structure in tracing_data_get() error paths.
Fixes the following coverity complaint:
Error: RESOURCE_LEAK (CWE-772):
leaked_storage: Variable "tdata" going out of scope leaks the storage
Signed-off-by: Sanskriti Sharma
Reviewed-by: Jiri Olsa
Cc: Joe Lawrence
Link:
http://lkml.kernel.org/r/1538490554-8161-3-git-send-email-sansh...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/trace-event-info.c |2 ++
1 file changed, 2 insertions(+)
--- a/tools/perf/util/trace-event-info.c
+++ b/tools/perf/util/trace-event-info.c
@@ -507,12 +507,14 @@ struct tracing_data *tracing_data_get(st
"/tmp/perf-XX");
if (!mkstemp(tdata->temp_file)) {
pr_debug("Can't make temp file");
+ free(tdata);
return NULL;
}
temp_fd = open(tdata->temp_file, O_RDWR);
if (temp_fd < 0) {
pr_debug("Can't read '%s'", tdata->temp_file);
+ free(tdata);
return NULL;
}
[PATCH 4.4 022/160] mmc: sdhci-pci-o2micro: Add quirk for O2 Micro dev 0x8620 rev 0x01
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Yu Zhao [ Upstream commit 5169894982bb67486d93cc1e10151712bb86bcb6 ] This device reports SDHCI_CLOCK_INT_STABLE even though it's not ready to take SDHCI_CLOCK_CARD_EN. The symptom is that reading SDHCI_CLOCK_CONTROL after enabling the clock shows absence of the bit from the register (e.g. expecting 0xfa07 = 0xfa03 | SDHCI_CLOCK_CARD_EN but only observed the first operand). mmc1: Timeout waiting for hardware cmd interrupt. mmc1: sdhci: SDHCI REGISTER DUMP === mmc1: sdhci: Sys addr: 0x | Version: 0x0603 mmc1: sdhci: Blk size: 0x | Blk cnt: 0x mmc1: sdhci: Argument: 0x | Trn mode: 0x mmc1: sdhci: Present: 0x01ff0001 | Host ctl: 0x0001 mmc1: sdhci: Power: 0x000f | Blk gap: 0x mmc1: sdhci: Wake-up: 0x | Clock:0xfa03 mmc1: sdhci: Timeout: 0x | Int stat: 0x mmc1: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 mmc1: sdhci: AC12 err: 0x | Slot int: 0x mmc1: sdhci: Caps: 0x25fcc8bf | Caps_1: 0x2077 mmc1: sdhci: Cmd: 0x | Max curr: 0x005800c8 mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x mmc1: sdhci: Host ctl2: 0x0008 mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x mmc1: sdhci: The problem happens during wakeup from S3. Adding a delay quirk after power up reliably fixes the problem. Signed-off-by: Yu Zhao Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/mmc/host/sdhci-pci-o2micro.c |3 +++ 1 file changed, 3 insertions(+) --- a/drivers/mmc/host/sdhci-pci-o2micro.c +++ b/drivers/mmc/host/sdhci-pci-o2micro.c @@ -334,6 +334,9 @@ int sdhci_pci_o2_probe(struct sdhci_pci_ pci_write_config_byte(chip->pdev, O2_SD_LOCK_WP, scratch); break; case PCI_DEVICE_ID_O2_SEABIRD0: + if (chip->pdev->revision == 0x01) + chip->quirks |= SDHCI_QUIRK_DELAY_AFTER_POWER; + /* fall through */ case PCI_DEVICE_ID_O2_SEABIRD1: /* UnLock WP */ ret = pci_read_config_byte(chip->pdev,
[PATCH 4.4 016/160] locking/lockdep: Fix debug_locks off performance problem
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Waiman Long
[ Upstream commit 9506a7425b094d2f1d9c877ed5a78f416669269b ]
It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For instance, parallel kernel build time on a 4-socket x86-64
server nearly doubled.
Further analysis into the cause of the slowdown traced back to the
frequent call to debug_locks_off() from the __lock_acquired() function
probably due to some inconsistent lockdep states with debug_locks
off. The debug_locks_off() function did an unconditional atomic xchg
to write a 0 value into debug_locks which had already been set to 0.
This led to severe cacheline contention in the cacheline that held
debug_locks. As debug_locks is being referenced in quite a few different
places in the kernel, this greatly slow down the system performance.
To prevent that trashing of debug_locks cacheline, lock_acquired()
and lock_contended() now checks the state of debug_locks before
proceeding. The debug_locks_off() function is also modified to check
debug_locks before calling __debug_locks_off().
Signed-off-by: Waiman Long
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Link:
http://lkml.kernel.org/r/1539913518-15598-1-git-send-email-long...@redhat.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
kernel/locking/lockdep.c |4 ++--
lib/debug_locks.c|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3826,7 +3826,7 @@ void lock_contended(struct lockdep_map *
{
unsigned long flags;
- if (unlikely(!lock_stat))
+ if (unlikely(!lock_stat || !debug_locks))
return;
if (unlikely(current->lockdep_recursion))
@@ -3846,7 +3846,7 @@ void lock_acquired(struct lockdep_map *l
{
unsigned long flags;
- if (unlikely(!lock_stat))
+ if (unlikely(!lock_stat || !debug_locks))
return;
if (unlikely(current->lockdep_recursion))
--- a/lib/debug_locks.c
+++ b/lib/debug_locks.c
@@ -37,7 +37,7 @@ EXPORT_SYMBOL_GPL(debug_locks_silent);
*/
int debug_locks_off(void)
{
- if (__debug_locks_off()) {
+ if (debug_locks && __debug_locks_off()) {
if (!debug_locks_silent) {
console_verbose();
return 1;
Re: [PATCH 0/2] PCI/AER: Consistently use _OSC to determine who owns AER
On Mon, Nov 19, 2018 at 11:53:05AM -0500, Tyler Baicar wrote: > On Thu, Nov 15, 2018 at 8:49 PM Sinan Kaya wrote: > > > > On 11/15/2018 3:16 PM, Alexandru Gagniuc wrote: > > > I've asked around a few people at Dell and they unanimously agree that > > > _OSC is the correct way to determine ownership of AER. In linux, we > > > use the result of _OSC to enable AER services, but we use HEST to > > > determine AER ownership. That's inconsistent. This series drops the > > > use of HEST in favor of _OSC. > > > > > > [1]https://lkml.org/lkml/2018/11/15/62 > > > > This change breaks the existing systems that rely on the HEST table > > telling the operating system about firmware first presence. > > > > Besides, HEST table has much more granularity about which PCI component > > needs firmware such as global/device/switch. > > > > You should probably circulate these ideas for wider consumption in UEFI > > forum as UEFI owns the HEST table definition. > > I agree with Sinan, this will break existing systems, and the granularity of > the > HEST definition is more useful than the single bit in _OSC. But we're not using HEST as a fine grain control. We disable native AER handling if *any* device has FF set in HEST, and that just forces people to use pcie_ports=native to get around that.
[PATCH 4.4 003/160] jffs2: free jffs2_sb_info through jffs2_kill_sb()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Hou Tao
commit 92e2921f7eee63450a5f953f4b15dc6210219430 upstream.
When an invalid mount option is passed to jffs2, jffs2_parse_options()
will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
Fix it by removing the buggy invocation of kfree() when getting invalid
mount options.
Fixes: 92abc475d8de ("jffs2: implement mount option parsing and compression
overriding")
Cc: sta...@kernel.org
Signed-off-by: Hou Tao
Reviewed-by: Richard Weinberger
Signed-off-by: Boris Brezillon
Signed-off-by: Greg Kroah-Hartman
---
fs/jffs2/super.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -285,10 +285,8 @@ static int jffs2_fill_super(struct super
sb->s_fs_info = c;
ret = jffs2_parse_options(c, data);
- if (ret) {
- kfree(c);
+ if (ret)
return -EINVAL;
- }
/* Initialize JFFS2 superblock locks, the further initialization will
* be done later */
[PATCH 4.4 017/160] ataflop: fix error handling during setup
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Omar Sandoval
[ Upstream commit 71327f547ee3a46ec5c39fdbbd268401b2578d0e ]
Move queue allocation next to disk allocation to fix a couple of issues:
- If add_disk() hasn't been called, we should clear disk->queue before
calling put_disk().
- If we fail to allocate a request queue, we still need to put all of
the disks, not just the ones that we allocated queues for.
Signed-off-by: Omar Sandoval
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/ataflop.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
--- a/drivers/block/ataflop.c
+++ b/drivers/block/ataflop.c
@@ -1933,6 +1933,11 @@ static int __init atari_floppy_init (voi
unit[i].disk = alloc_disk(1);
if (!unit[i].disk)
goto Enomem;
+
+ unit[i].disk->queue = blk_init_queue(do_fd_request,
+&ataflop_lock);
+ if (!unit[i].disk->queue)
+ goto Enomem;
}
if (UseTrackbuffer < 0)
@@ -1964,10 +1969,6 @@ static int __init atari_floppy_init (voi
sprintf(unit[i].disk->disk_name, "fd%d", i);
unit[i].disk->fops = &floppy_fops;
unit[i].disk->private_data = &unit[i];
- unit[i].disk->queue = blk_init_queue(do_fd_request,
- &ataflop_lock);
- if (!unit[i].disk->queue)
- goto Enomem;
set_capacity(unit[i].disk, MAX_DISK_SIZE * 2);
add_disk(unit[i].disk);
}
@@ -1982,13 +1983,17 @@ static int __init atari_floppy_init (voi
return 0;
Enomem:
- while (i--) {
- struct request_queue *q = unit[i].disk->queue;
+ do {
+ struct gendisk *disk = unit[i].disk;
- put_disk(unit[i].disk);
- if (q)
- blk_cleanup_queue(q);
- }
+ if (disk) {
+ if (disk->queue) {
+ blk_cleanup_queue(disk->queue);
+ disk->queue = NULL;
+ }
+ put_disk(unit[i].disk);
+ }
+ } while (i--);
unregister_blkdev(FLOPPY_MAJOR, "fd");
return -ENOMEM;
[PATCH 4.4 014/160] net: qla3xxx: Remove overflowing shift statement
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Nathan Chancellor [ Upstream commit 8c3bf9b62b667456a57aefcf1689e826df146159 ] Clang currently warns: drivers/net/ethernet/qlogic/qla3xxx.c:384:24: warning: signed shift result (0xF) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] ((ISP_NVRAM_MASK << 16) | qdev->eeprom_cmd_data)); ~~ ^ ~~ 1 warning generated. The warning is certainly accurate since ISP_NVRAM_MASK is defined as (0x000F << 16) which is then shifted by 16, resulting in 64424509440, well above UINT_MAX. Given that this is the only location in this driver where ISP_NVRAM_MASK is shifted again, it seems likely that ISP_NVRAM_MASK was originally defined without a shift and during the move of the shift to the definition, this statement wasn't properly removed (since ISP_NVRAM_MASK is used in the statenent right above this). Only the maintainers can confirm this since this statment has been here since the driver was first added to the kernel. Link: https://github.com/ClangBuiltLinux/linux/issues/127 Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/net/ethernet/qlogic/qla3xxx.c |2 -- 1 file changed, 2 deletions(-) --- a/drivers/net/ethernet/qlogic/qla3xxx.c +++ b/drivers/net/ethernet/qlogic/qla3xxx.c @@ -380,8 +380,6 @@ static void fm93c56a_select(struct ql3_a qdev->eeprom_cmd_data = AUBURN_EEPROM_CS_1; ql_write_nvram_reg(qdev, spir, ISP_NVRAM_MASK | qdev->eeprom_cmd_data); - ql_write_nvram_reg(qdev, spir, - ((ISP_NVRAM_MASK << 16) | qdev->eeprom_cmd_data)); } /*
[PATCH 4.4 020/160] perf tools: Free temporary sys string in read_event_files()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sanskriti Sharma
[ Upstream commit 1e44224fb0528b4c0cc176bde2bb31e9127eb14b ]
For each system in a given pevent, read_event_files() reads in a
temporary 'sys' string. Be sure to free this string before moving onto
to the next system and/or leaving read_event_files().
Fixes the following coverity complaints:
Error: RESOURCE_LEAK (CWE-772):
tools/perf/util/trace-event-read.c:343: overwrite_var: Overwriting
"sys" in "sys = read_string()" leaks the storage that "sys" points to.
tools/perf/util/trace-event-read.c:353: leaked_storage: Variable "sys"
going out of scope leaks the storage it points to.
Signed-off-by: Sanskriti Sharma
Reviewed-by: Jiri Olsa
Cc: Joe Lawrence
Link:
http://lkml.kernel.org/r/1538490554-8161-6-git-send-email-sansh...@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
tools/perf/util/trace-event-read.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -334,9 +334,12 @@ static int read_event_files(struct peven
for (x=0; x < count; x++) {
size = read8(pevent);
ret = read_event_file(pevent, sys, size);
- if (ret)
+ if (ret) {
+ free(sys);
return ret;
+ }
}
+ free(sys);
}
return 0;
}
[PATCH 4.4 019/160] tun: Consistently configure generic netdev params via rtnetlink
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Serhey Popovych
[ Upstream commit df52eab23d703142c766ac00bdb8db19d71238d0 ]
Configuring generic network device parameters on tun will fail in
presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
since tun_validate() always return failure.
This can be visualized with following ip-link(8) command sequences:
# ip link set dev tun0 group 100
# ip link set dev tun0 group 100 type tun
RTNETLINK answers: Invalid argument
with contrast to dummy and veth drivers:
# ip link set dev dummy0 group 100
# ip link set dev dummy0 type dummy
# ip link set dev veth0 group 100
# ip link set dev veth0 group 100 type veth
Fix by returning zero in tun_validate() when @data is NULL that is
always in case since rtnl_link_ops->maxtype is zero in tun driver.
Fixes: f019a7a594d9 ("tun: Implement ip link del tunXXX")
Signed-off-by: Serhey Popovych
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/tun.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1475,6 +1475,8 @@ static void tun_setup(struct net_device
*/
static int tun_validate(struct nlattr *tb[], struct nlattr *data[])
{
+ if (!data)
+ return 0;
return -EINVAL;
}
[PATCH 4.4 011/160] x86/kconfig: Fall back to ticket spinlocks
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Daniel Wagner Sebastian writes: """ We reproducibly observe cache line starvation on a Core2Duo E6850 (2 cores), a i5-6400 SKL (4 cores) and on a NXP LS2044A ARM Cortex-A72 (4 cores). The problem can be triggered with a v4.9-RT kernel by starting cyclictest -S -p98 -m -i2000 -b 200 and as "load" stress-ng --ptrace 4 The reported maximal latency is usually less than 60us. If the problem triggers then values around 400us, 800us or even more are reported. The upperlimit is the -i parameter. Reproduction with 4.9-RT is almost immediate on Core2Duo, ARM64 and SKL, but it took 7.5 hours to trigger on v4.14-RT on the Core2Duo. Instrumentation show always the picture: CPU0 CPU1 => do_syscall_64 => do_syscall_64 => SyS_ptrace => syscall_slow_exit_work => ptrace_check_attach => ptrace_do_notify / rt_read_unlock => wait_task_inactive rt_spin_lock_slowunlock() -> while task_running() __rt_mutex_unlock_common() / check_task_state() mark_wakeup_next_waiter() | raw_spin_lock_irq(&p->pi_lock); raw_spin_lock(¤t->pi_lock); | . . | raw_spin_unlock_irq(&p->pi_lock); . \ cpu_relax() . - . *IRQ* In the error case we observe that the while() loop is repeated more than 5000 times which indicates that the pi_lock can be acquired. CPU1 on the other side does not make progress waiting for the same lock with interrupts disabled. This continues until an IRQ hits CPU0. Once CPU0 starts processing the IRQ the other CPU is able to acquire pi_lock and the situation relaxes. """ This matches with the observeration for v4.4-rt on a Core2Duo E6850: CPU 0: - no progress for a very long time in rt_mutex_dequeue_pi): stress-n-19310d..11 5060.891219: function: __try_to_take_rt_mutex stress-n-19310d..11 5060.891219: function:rt_mutex_dequeue stress-n-19310d..21 5060.891220: function: rt_mutex_enqueue_pi stress-n-193102 5060.891220: signal_generate: sig=17 errno=0 code=262148 comm=stress-ng-ptrac pid=1928 grp=1 res=1 stress-n-19310d..21 5060.894114: function: rt_mutex_dequeue_pi stress-n-19310d.h11 5060.894115: local_timer_entry:vector=239 CPU 1: - IRQ at 5060.894114 on CPU 1 followed by the IRQ on CPU 0 stress-n-192810 5060.891215: sys_enter:NR 101 (18, 78b, 0, 0, 17, 788) stress-n-19281d..11 5060.891216: function: __try_to_take_rt_mutex stress-n-19281d..21 5060.891216: function: rt_mutex_enqueue_pi stress-n-19281d..21 5060.891217: function: rt_mutex_dequeue_pi stress-n-192811 5060.891217: function: rt_mutex_adjust_prio stress-n-19281d..11 5060.891218: function: __rt_mutex_adjust_prio stress-n-19281d.h10 5060.894114: local_timer_entry:vector=239 Thomas writes: """ This has nothing to do with RT. RT is merily exposing the problem in an observable way. The same issue happens with upstream, it's harder to trigger and it's harder to observe for obvious reasons. If you read through the discussions [see the links below] then you really see that there is an upstream issue with the x86 qrlock implementation and Peter has posted fixes which resolve it, both at the practical and the theoretical level. """ Backporting all qspinlock related patches is very likely to introduce regressions on v4.4. Therefore, the recommended solution by Peter and Thomas is to drop back to ticket spinlocks for v4.4. Link :https://lkml.kernel.org/r/20180921120226.6xjgr4oiho22e...@linutronix.de Link: https://lkml.kernel.org/r/20180926110117.405325...@infradead.org Cc: Sebastian Andrzej Siewior Acked-by: Peter Zijlstra Acked-by: Thomas Gleixner Signed-off-by: Daniel Wagner Signed-off-by: Greg Kroah-Hartman --- Thomas suggest following plan for fixing the issues on the varous stable trees: 4.4: Trivial by switching back to ticket locks. 4.9: Decide whether bringing back ticket locks or backporting all qrlock fixes. Sebastian has done the latter already and it's probably the right solution 4.14: 4.18: Backporting the qrlock fixes 4.19: Either the fix ends up in 4.19 final or it needs to be backported arch/x86/Kconfig |1 - 1 file changed, 1 deletion(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -41,7 +41,6 @@ config X86 select ARCH_USE_BUILTIN_BSWAP select ARCH_USE_CMPXCHG_LOCKREF if X86_64 select A
[PATCH 4.4 012/160] sparc: Fix single-pcr perf event counter management.
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: "David S. Miller"
[ Upstream commit cfdc3170d214046b9509183fe9b9544dc644d40b ]
It is important to clear the hw->state value for non-stopped events
when they are added into the PMU. Otherwise when the event is
scheduled out, we won't read the counter because HES_UPTODATE is still
set. This breaks 'perf stat' and similar use cases, causing all the
events to show zero.
This worked for multi-pcr because we make explicit sparc_pmu_start()
calls in calculate_multiple_pcrs(). calculate_single_pcr() doesn't do
this because the idea there is to accumulate all of the counter
settings into the single pcr value. So we have to add explicit
hw->state handling there.
Like x86, we use the PERF_HES_ARCH bit to track truly stopped events
so that we don't accidently start them on a reload.
Related to all of this, sparc_pmu_start() is missing a userpage update
so add it.
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/sparc/kernel/perf_event.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
--- a/arch/sparc/kernel/perf_event.c
+++ b/arch/sparc/kernel/perf_event.c
@@ -926,6 +926,8 @@ static void read_in_all_counters(struct
sparc_perf_event_update(cp, &cp->hw,
cpuc->current_idx[i]);
cpuc->current_idx[i] = PIC_NO_INDEX;
+ if (cp->hw.state & PERF_HES_STOPPED)
+ cp->hw.state |= PERF_HES_ARCH;
}
}
}
@@ -958,10 +960,12 @@ static void calculate_single_pcr(struct
enc = perf_event_get_enc(cpuc->events[i]);
cpuc->pcr[0] &= ~mask_for_index(idx);
- if (hwc->state & PERF_HES_STOPPED)
+ if (hwc->state & PERF_HES_ARCH) {
cpuc->pcr[0] |= nop_for_index(idx);
- else
+ } else {
cpuc->pcr[0] |= event_encoding(enc, idx);
+ hwc->state = 0;
+ }
}
out:
cpuc->pcr[0] |= cpuc->event[0]->hw.config_base;
@@ -987,6 +991,9 @@ static void calculate_multiple_pcrs(stru
cpuc->current_idx[i] = idx;
+ if (cp->hw.state & PERF_HES_ARCH)
+ continue;
+
sparc_pmu_start(cp, PERF_EF_RELOAD);
}
out:
@@ -1078,6 +1085,8 @@ static void sparc_pmu_start(struct perf_
event->hw.state = 0;
sparc_pmu_enable_event(cpuc, &event->hw, idx);
+
+ perf_event_update_userpage(event);
}
static void sparc_pmu_stop(struct perf_event *event, int flags)
@@ -1370,9 +1379,9 @@ static int sparc_pmu_add(struct perf_eve
cpuc->events[n0] = event->hw.event_base;
cpuc->current_idx[n0] = PIC_NO_INDEX;
- event->hw.state = PERF_HES_UPTODATE;
+ event->hw.state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
if (!(ef_flags & PERF_EF_START))
- event->hw.state |= PERF_HES_STOPPED;
+ event->hw.state |= PERF_HES_ARCH;
/*
* If group events scheduling transaction was started,
[PATCH 4.4 013/160] x86/fpu: Remove second definition of fpu in __fpu__restore_sig()
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
[ Upstream commit 6aa676761d4c1acfa31320e55fa1f83f3fcbbc7a ]
Commit:
c5bedc6847c3b ("x86/fpu: Get rid of PF_USED_MATH usage, convert it to
fpu->fpstate_active")
introduced the 'fpu' variable at top of __restore_xstate_sig(),
which now shadows the other definition:
arch/x86/kernel/fpu/signal.c:318:28: warning: symbol 'fpu' shadows an earlier
one
arch/x86/kernel/fpu/signal.c:271:20: originally declared here
Remove the shadowed definition of 'fpu', as the two definitions are the same.
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: c5bedc6847c3b ("x86/fpu: Get rid of PF_USED_MATH usage, convert it to
fpu->fpstate_active")
Link: http://lkml.kernel.org/r/20181016202525.29437-3-bige...@linutronix.de
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/fpu/signal.c |1 -
1 file changed, 1 deletion(-)
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -294,7 +294,6 @@ static int __fpu__restore_sig(void __use
* thread's fpu state, reconstruct fxstate from the fsave
* header. Sanitize the copied state etc.
*/
- struct fpu *fpu = &tsk->thread.fpu;
struct user_i387_ia32_struct env;
int err = 0;
[PATCH 4.4 010/160] x86/corruption-check: Fix panic in memory_corruption_check() when boot option without value is provided
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: He Zhe
commit ccde460b9ae5c2bd5e4742af0a7f623c2daad566 upstream.
memory_corruption_check[{_period|_size}]()'s handlers do not check input
argument before passing it to kstrtoul() or simple_strtoull(). The argument
would be a NULL pointer if each of the kernel parameters, without its
value, is set in command line and thus cause the following panic.
PANIC: early exception 0xe3 IP 10:73587c22 error 0 cr2 0x0
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #2
[0.00] RIP: 0010:kstrtoull+0x2/0x10
...
[0.00] Call Trace
[0.00] ? set_corruption_check+0x21/0x49
[0.00] ? do_early_param+0x4d/0x82
[0.00] ? parse_args+0x212/0x330
[0.00] ? rdinit_setup+0x26/0x26
[0.00] ? parse_early_options+0x20/0x23
[0.00] ? rdinit_setup+0x26/0x26
[0.00] ? parse_early_param+0x2d/0x39
[0.00] ? setup_arch+0x2f7/0xbf4
[0.00] ? start_kernel+0x5e/0x4c2
[0.00] ? load_ucode_bsp+0x113/0x12f
[0.00] ? secondary_startup_64+0xa5/0xb0
This patch adds checks to prevent the panic.
Signed-off-by: He Zhe
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: gre...@linuxfoundation.org
Cc: kstew...@linuxfoundation.org
Cc: pombreda...@nexb.com
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1534260823-87917-1-git-send-email-zhe...@windriver.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/check.c | 15 +++
1 file changed, 15 insertions(+)
--- a/arch/x86/kernel/check.c
+++ b/arch/x86/kernel/check.c
@@ -30,6 +30,11 @@ static __init int set_corruption_check(c
ssize_t ret;
unsigned long val;
+ if (!arg) {
+ pr_err("memory_corruption_check config string not provided\n");
+ return -EINVAL;
+ }
+
ret = kstrtoul(arg, 10, &val);
if (ret)
return ret;
@@ -44,6 +49,11 @@ static __init int set_corruption_check_p
ssize_t ret;
unsigned long val;
+ if (!arg) {
+ pr_err("memory_corruption_check_period config string not
provided\n");
+ return -EINVAL;
+ }
+
ret = kstrtoul(arg, 10, &val);
if (ret)
return ret;
@@ -58,6 +68,11 @@ static __init int set_corruption_check_s
char *end;
unsigned size;
+ if (!arg) {
+ pr_err("memory_corruption_check_size config string not
provided\n");
+ return -EINVAL;
+ }
+
size = memparse(arg, &end);
if (*end == '\0')
[PATCH 4.4 001/160] bcache: fix miss key refill->end in writeback
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Tang Junhui
commit 2d6cb6edd2c7fb4f40998895bda45006281b1ac5 upstream.
refill->end record the last key of writeback, for example, at the first
time, keys (1,128K) to (1,1024K) are flush to the backend device, but
the end key (1,1024K) is not included, since the bellow code:
if (bkey_cmp(k, refill->end) >= 0) {
ret = MAP_DONE;
goto out;
}
And in the next time when we refill writeback keybuf again, we searched
key start from (1,1024K), and got a key bigger than it, so the key
(1,1024K) missed.
This patch modify the above code, and let the end key to be included to
the writeback key buffer.
Signed-off-by: Tang Junhui
Cc: sta...@vger.kernel.org
Signed-off-by: Coly Li
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/bcache/btree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -2372,7 +2372,7 @@ static int refill_keybuf_fn(struct btree
struct keybuf *buf = refill->buf;
int ret = MAP_CONTINUE;
- if (bkey_cmp(k, refill->end) >= 0) {
+ if (bkey_cmp(k, refill->end) > 0) {
ret = MAP_DONE;
goto out;
}
[PATCH 4.9 78/83] drm/rockchip: Allow driver to be shutdown on reboot/kexec
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
commit 7f3ef5dedb146e3d5063b6845781ad1bb59b92b5 upstream.
Leaving the DRM driver enabled on reboot or kexec has the annoying
effect of leaving the display generating transactions whilst the
IOMMU has been shut down.
In turn, the IOMMU driver (which shares its interrupt line with
the VOP) starts warning either on shutdown or when entering the
secondary kernel in the kexec case (nothing is expected on that
front).
A cheap way of ensuring that things are nicely shut down is to
register a shutdown callback in the platform driver.
Signed-off-by: Marc Zyngier
Tested-by: Vicente Bergas
Signed-off-by: Heiko Stuebner
Link:
https://patchwork.freedesktop.org/patch/msgid/20180805124807.18169-1-marc.zyng...@arm.com
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -478,6 +478,11 @@ static int rockchip_drm_platform_remove(
return 0;
}
+static void rockchip_drm_platform_shutdown(struct platform_device *pdev)
+{
+ rockchip_drm_platform_remove(pdev);
+}
+
static const struct of_device_id rockchip_drm_dt_ids[] = {
{ .compatible = "rockchip,display-subsystem", },
{ /* sentinel */ },
@@ -487,6 +492,7 @@ MODULE_DEVICE_TABLE(of, rockchip_drm_dt_
static struct platform_driver rockchip_drm_platform_driver = {
.probe = rockchip_drm_platform_probe,
.remove = rockchip_drm_platform_remove,
+ .shutdown = rockchip_drm_platform_shutdown,
.driver = {
.name = "rockchip-drm",
.of_match_table = rockchip_drm_dt_ids,
[PATCH 4.9 77/83] mm: migration: fix migration of huge PMD shared pages
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Kravetz
commit 017b1660df89f5fb4bfe66c34e35f7d2031100c7 upstream.
The page migration code employs try_to_unmap() to try and unmap the source
page. This is accomplished by using rmap_walk to find all vmas where the
page is mapped. This search stops when page mapcount is zero. For shared
PMD huge pages, the page map count is always 1 no matter the number of
mappings. Shared mappings are tracked via the reference count of the PMD
page. Therefore, try_to_unmap stops prematurely and does not completely
unmap all mappings of the source page.
This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the target
page. Hence, data is lost.
This problem was originally seen as DB corruption of shared global areas
after a huge page was soft offlined due to ECC memory errors. DB
developers noticed they could reproduce the issue by (hotplug) offlining
memory used to back huge pages. A simple testcase can reproduce the
problem by creating a shared PMD mapping (note that this must be at least
PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using
migrate_pages() to migrate process pages between nodes while continually
writing to the huge pages being migrated.
To fix, have the try_to_unmap_one routine check for huge PMD sharing by
calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared
mapping it will be 'unshared' which removes the page table entry and drops
the reference on the PMD page. After this, flush caches and TLB.
mmu notifiers are called before locking page tables, but we can not be
sure of PMD sharing until page tables are locked. Therefore, check for
the possibility of PMD sharing before locking so that notifiers can
prepare for the worst possible case.
Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.krav...@oracle.com
[mike.krav...@oracle.com: make _range_in_vma() a static inline]
Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc9...@oracle.com
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
Acked-by: Kirill A. Shutemov
Reviewed-by: Naoya Horiguchi
Acked-by: Michal Hocko
Cc: Vlastimil Babka
Cc: Davidlohr Bueso
Cc: Jerome Glisse
Cc: Mike Kravetz
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Mike Kravetz
Reviewed-by: Jérôme Glisse
Acked-by: Michal Hocko
Signed-off-by: Greg Kroah-Hartman
---
include/linux/hugetlb.h | 14
include/linux/mm.h |6 +
mm/hugetlb.c| 37 ++-
mm/rmap.c | 56
4 files changed, 111 insertions(+), 2 deletions(-)
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -109,6 +109,8 @@ pte_t *huge_pte_alloc(struct mm_struct *
unsigned long addr, unsigned long sz);
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr);
int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep);
+void adjust_range_if_pmd_sharing_possible(struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end);
struct page *follow_huge_addr(struct mm_struct *mm, unsigned long address,
int write);
struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
@@ -131,6 +133,18 @@ static inline unsigned long hugetlb_tota
return 0;
}
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+ pte_t *ptep)
+{
+ return 0;
+}
+
+static inline void adjust_range_if_pmd_sharing_possible(
+ struct vm_area_struct *vma,
+ unsigned long *start, unsigned long *end)
+{
+}
+
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w) ({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2187,6 +2187,12 @@ static inline struct vm_area_struct *fin
return vma;
}
+static inline bool range_in_vma(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ return (vma && vma->vm_start <= start && end <= vma->vm_end);
+}
+
#ifdef CONFIG_MMU
pgprot_t vm_get_page_prot(unsigned long vm_flags);
void vma_set_page_prot(struct vm_area_struct *vma);
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4333,13 +4333,41 @@ static bool vma_shareable(struct vm_area
/*
* check on proper vm_flags and page table alignment
*/
- if (vma->vm_flags & VM_MAYSHARE &&
- vma->vm_start <= base && end <= vma->vm_end)
+ if (vma->vm_flags & VM_MAYSHARE && range_in_vma(vma, base, end))
return true;
return
[PATCH 4.9 69/83] sunrpc: correct the computation for page_ptr when truncating
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Frank Sorenson
commit 5d7a5bcb67c70cbc904057ef52d3fcfeb24420bb upstream.
When truncating the encode buffer, the page_ptr is getting
advanced, causing the next page to be skipped while encoding.
The page is still included in the response, so the response
contains a page of bogus data.
We need to adjust the page_ptr backwards to ensure we encode
the next page into the correct place.
We saw this triggered when concurrent directory modifications caused
nfsd4_encode_direct_fattr() to return nfserr_noent, and the resulting
call to xdr_truncate_encode() corrupted the READDIR reply.
Signed-off-by: Frank Sorenson
Cc: sta...@vger.kernel.org
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman
---
net/sunrpc/xdr.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/sunrpc/xdr.c
+++ b/net/sunrpc/xdr.c
@@ -639,11 +639,10 @@ void xdr_truncate_encode(struct xdr_stre
WARN_ON_ONCE(xdr->iov);
return;
}
- if (fraglen) {
+ if (fraglen)
xdr->end = head->iov_base + head->iov_len;
- xdr->page_ptr--;
- }
/* (otherwise assume xdr->end is already set) */
+ xdr->page_ptr--;
head->iov_len = len;
buf->len = len;
xdr->p = head->iov_base + head->iov_len;
[PATCH 4.9 28/83] parisc: Fix exported address of os_hpmc handler
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 99a3ae51d557d8e38a7aece65678a31f9db215ee ]
In the C-code we need to put the physical address of the hpmc handler in
the interrupt vector table (IVA) in order to get HPMCs working. Since
on parisc64 function pointers are indirect (in fact they are function
descriptors) we instead export the address as variable and not as
function.
This reverts a small part of commit f39cce654f9a ("parisc: Add
cfi_startproc and cfi_endproc to assembly code").
Signed-off-by: Helge Deller
Cc: [4.9+]
Signed-off-by: Sasha Levin
---
arch/parisc/kernel/hpmc.S | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/parisc/kernel/hpmc.S b/arch/parisc/kernel/hpmc.S
index 407b3aa5aa07..e88f4e7f39f3 100644
--- a/arch/parisc/kernel/hpmc.S
+++ b/arch/parisc/kernel/hpmc.S
@@ -84,7 +84,7 @@ END(hpmc_pim_data)
.import intr_save, code
.align 16
-ENTRY_CFI(os_hpmc)
+ENTRY(os_hpmc)
.os_hpmc:
/*
@@ -301,7 +301,6 @@ os_hpmc_6:
b .
nop
.align 16 /* make function length multiple of 16 bytes */
-ENDPROC_CFI(os_hpmc)
.os_hpmc_end:
--
2.17.1
[PATCH 4.9 81/83] drm/i915/execlists: Force write serialisation into context image vs execution
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Chris Wilson commit 0a823e8fd4fd67726697854578f3584ee3a49b1d upstream. Ensure that the writes into the context image are completed prior to the register mmio to trigger execution. Although previously we were assured by the SDM that all writes are flushed before an uncached memory transaction (our mmio write to submit the context to HW for execution), we have empirical evidence to believe that this is not actually the case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656 References: https://bugs.freedesktop.org/show_bug.cgi?id=108315 References: https://bugs.freedesktop.org/show_bug.cgi?id=106887 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Acked-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20181108081740.25615-1-ch...@chris-wilson.co.uk Cc: sta...@vger.kernel.org (cherry picked from commit 987abd5c62f92ee4970b45aa077f47949974e615) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/intel_lrc.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -368,7 +368,8 @@ static u64 execlists_update_context(stru reg_state[CTX_RING_TAIL+1] = intel_ring_offset(rq->ring, rq->tail); - /* True 32b PPGTT with dynamic page allocation: update PDP + /* +* True 32b PPGTT with dynamic page allocation: update PDP * registers and point the unallocated PDPs to scratch page. * PML4 is allocated during ppgtt init, so this is not needed * in 48-bit mode. @@ -376,6 +377,17 @@ static u64 execlists_update_context(stru if (ppgtt && !USES_FULL_48BIT_PPGTT(ppgtt->base.dev)) execlists_update_context_pdps(ppgtt, reg_state); + /* +* Make sure the context image is complete before we submit it to HW. +* +* Ostensibly, writes (including the WCB) should be flushed prior to +* an uncached write such as our mmio register access, the empirical +* evidence (esp. on Braswell) suggests that the WC write into memory +* may not be visible to the HW prior to the completion of the UC +* register write and that we may begin execution from the context +* before its image is complete leading to invalid PD chasing. +*/ + wmb(); return ce->lrc_desc; }
[PATCH 4.9 72/83] fuse: fix use-after-free in fuse_direct_IO()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Lukas Czerner
commit ebacb81273599555a7a19f7754a1451206a5fc4f upstream.
In async IO blocking case the additional reference to the io is taken for
it to survive fuse_aio_complete(). In non blocking case this additional
reference is not needed, however we still reference io to figure out
whether to wait for completion or not. This is wrong and will lead to
use-after-free. Fix it by storing blocking information in separate
variable.
This was spotted by KASAN when running generic/208 fstest.
Signed-off-by: Lukas Czerner
Reported-by: Zorro Lang
Signed-off-by: Miklos Szeredi
Fixes: 744742d692e3 ("fuse: Add reference counting for fuse_io_priv")
Cc: # v4.6
Signed-off-by: Greg Kroah-Hartman
---
fs/fuse/file.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2900,10 +2900,12 @@ fuse_direct_IO(struct kiocb *iocb, struc
}
if (io->async) {
+ bool blocking = io->blocking;
+
fuse_aio_complete(io, ret < 0 ? ret : 0, -1);
/* we have a non-extending, async request, so return */
- if (!io->blocking)
+ if (!blocking)
return -EIOCBQUEUED;
wait_for_completion(&wait);
[PATCH 4.9 82/83] KVM: arm64: Fix caching of host MDCR_EL2 value
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Mark Rutland
commit da5a3ce66b8bb51b0ea8a89f42aac153903f90fb upstream.
At boot time, KVM stashes the host MDCR_EL2 value, but only does this
when the kernel is not running in hyp mode (i.e. is non-VHE). In these
cases, the stashed value of MDCR_EL2.HPMN happens to be zero, which can
lead to CONSTRAINED UNPREDICTABLE behaviour.
Since we use this value to derive the MDCR_EL2 value when switching
to/from a guest, after a guest have been run, the performance counters
do not behave as expected. This has been observed to result in accesses
via PMXEVTYPER_EL0 and PMXEVCNTR_EL0 not affecting the relevant
counters, resulting in events not being counted. In these cases, only
the fixed-purpose cycle counter appears to work as expected.
Fix this by always stashing the host MDCR_EL2 value, regardless of VHE.
Cc: Christopher Dall
Cc: James Morse
Cc: Will Deacon
Cc: sta...@vger.kernel.org
Fixes: 1e947bad0b63b351 ("arm64: KVM: Skip HYP setup when already running in
HYP")
Tested-by: Robin Murphy
Signed-off-by: Mark Rutland
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman
---
arch/arm/kvm/arm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1092,8 +1092,6 @@ static void cpu_init_hyp_mode(void *dumm
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
-
- kvm_arm_init_debug();
}
static void cpu_hyp_reinit(void)
@@ -1108,6 +1106,8 @@ static void cpu_hyp_reinit(void)
if (__hyp_get_vectors() == hyp_default_vectors)
cpu_init_hyp_mode(NULL);
}
+
+ kvm_arm_init_debug();
}
static void cpu_hyp_reset(void)
[PATCH 4.9 34/83] clk: s2mps11: Fix matching when built as module and DT node contains compatible
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Krzysztof Kozlowski
commit 8985167ecf57f97061599a155bb9652c84ea4913 upstream.
When driver is built as module and DT node contains clocks compatible
(e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
module aliases won't match.
The modalias from uevent: of:NclocksTCsamsung,s2mps11-clk
The modalias from driver: platform:s2mps11-clk
The devices are instantiated by parent's MFD. However both Device Tree
bindings and parent define the compatible for clocks devices. In case
of module matching this DT compatible will be used.
The issue will not happen if this is a built-in (no need for module
matching) or when clocks DT node does not contain compatible (not
correct from bindings perspective but working for driver).
Note when backporting to stable kernels: adjust the list of device ID
entries.
Cc:
Fixes: 53c31b3437a6 ("mfd: sec-core: Add of_compatible strings for clock MFD
cells")
Signed-off-by: Krzysztof Kozlowski
Acked-by: Stephen Boyd
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d44e0eea31ec..0934d3724495 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -245,6 +245,36 @@ static const struct platform_device_id s2mps11_clk_id[] = {
};
MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);
+#ifdef CONFIG_OF
+/*
+ * Device is instantiated through parent MFD device and device matching is done
+ * through platform_device_id.
+ *
+ * However if device's DT node contains proper clock compatible and driver is
+ * built as a module, then the *module* matching will be done trough DT
aliases.
+ * This requires of_device_id table. In the same time this will not change the
+ * actual *device* matching so do not add .of_match_table.
+ */
+static const struct of_device_id s2mps11_dt_match[] = {
+ {
+ .compatible = "samsung,s2mps11-clk",
+ .data = (void *)S2MPS11X,
+ }, {
+ .compatible = "samsung,s2mps13-clk",
+ .data = (void *)S2MPS13X,
+ }, {
+ .compatible = "samsung,s2mps14-clk",
+ .data = (void *)S2MPS14X,
+ }, {
+ .compatible = "samsung,s5m8767-clk",
+ .data = (void *)S5M8767X,
+ }, {
+ /* Sentinel */
+ },
+};
+MODULE_DEVICE_TABLE(of, s2mps11_dt_match);
+#endif
+
static struct platform_driver s2mps11_clk_driver = {
.driver = {
.name = "s2mps11-clk",
[PATCH 4.9 75/83] lib/ubsan.c: dont mark __ubsan_handle_builtin_unreachable as noreturn
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit 1c23b4108d716cc848b38532063a8aca4f86add8 upstream.
gcc-8 complains about the prototype for this function:
lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a
built-in function '__ubsan_handle_builtin_unreachable' because it conflicts
with attribute 'const' [-Werror=attributes]
This is actually a GCC's bug. In GCC internals
__ubsan_handle_builtin_unreachable() declared with both 'noreturn' and
'const' attributes instead of only 'noreturn':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84210
Workaround this by removing the noreturn attribute.
[aryabinin: add information about GCC bug in changelog]
Link: http://lkml.kernel.org/r/20181107144516.4587-1-aryabi...@virtuozzo.com
Signed-off-by: Arnd Bergmann
Signed-off-by: Andrey Ryabinin
Acked-by: Olof Johansson
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
lib/ubsan.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -451,8 +451,7 @@ void __ubsan_handle_shift_out_of_bounds(
EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds);
-void __noreturn
-__ubsan_handle_builtin_unreachable(struct unreachable_data *data)
+void __ubsan_handle_builtin_unreachable(struct unreachable_data *data)
{
unsigned long flags;
[PATCH 4.9 35/83] clk: at91: Fix division by zero in PLL recalc_rate()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ronald Wahl
commit 0f5cb0e6225cae2f029944cb8c74617aab6ddd49 upstream.
Commit a982e45dc150 ("clk: at91: PLL recalc_rate() now using cached MUL
and DIV values") removed a check that prevents a division by zero. This
now causes a stacktrace when booting the kernel on a at91 platform if
the PLL DIV register contains zero. This commit reintroduces this check.
Fixes: a982e45dc150 ("clk: at91: PLL recalc_rate() now using cached...")
Cc:
Signed-off-by: Ronald Wahl
Acked-by: Ludovic Desroches
Signed-off-by: Stephen Boyd
Signed-off-by: Greg Kroah-Hartman
---
drivers/clk/at91/clk-pll.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -133,6 +133,9 @@ static unsigned long clk_pll_recalc_rate
{
struct clk_pll *pll = to_clk_pll(hw);
+ if (!pll->div || !pll->mul)
+ return 0;
+
return (parent_rate / pll->div) * (pll->mul + 1);
}
[PATCH 4.9 79/83] drm/dp_mst: Check if primary mstb is null
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislav Lisovskiy
commit 23d8003907d094f77cf959228e2248d6db819fa7 upstream.
Unfortunately drm_dp_get_mst_branch_device which is called from both
drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
on that mgr->mst_primary is not NULL, which seem to be wrong as it can be
cleared with simultaneous mode set, if probing fails or in other case.
mgr->lock mutex doesn't protect against that as it might just get
assigned to NULL right before, not simultaneously.
There are currently bugs 107738, 108616 bugs which crash in
drm_dp_get_mst_branch_device, caused by this issue.
v2: Refactored the code, as it was nicely noticed.
Fixed Bugzilla bug numbers(second was 108616, but not 108816)
and added links.
[changed title and added stable cc]
Signed-off-by: Lyude Paul
Signed-off-by: Stanislav Lisovskiy
Cc: sta...@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738
Link:
https://patchwork.freedesktop.org/patch/msgid/20181109090012.24438-1-stanislav.lisovs...@intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_dp_mst_topology.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1230,6 +1230,9 @@ static struct drm_dp_mst_branch *drm_dp_
mutex_lock(&mgr->lock);
mstb = mgr->mst_primary;
+ if (!mstb)
+ goto out;
+
for (i = 0; i < lct - 1; i++) {
int shift = (i % 2) ? 0 : 4;
int port_num = (rad[i / 2] >> shift) & 0xf;
[PATCH 4.9 70/83] nfsd: COPY and CLONE operations require the saved filehandle to be set
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Scott Mayhew
commit 01310bb7c9c98752cc763b36532fab028e0f8f81 upstream.
Make sure we have a saved filehandle, otherwise we'll oops with a null
pointer dereference in nfs4_preprocess_stateid_op().
Signed-off-by: Scott Mayhew
Cc: sta...@vger.kernel.org
Signed-off-by: J. Bruce Fields
Signed-off-by: Greg Kroah-Hartman
---
fs/nfsd/nfs4proc.c |3 +++
1 file changed, 3 insertions(+)
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1016,6 +1016,9 @@ nfsd4_verify_copy(struct svc_rqst *rqstp
{
__be32 status;
+ if (!cstate->save_fh.fh_dentry)
+ return nfserr_nofilehandle;
+
status = nfs4_preprocess_stateid_op(rqstp, cstate, &cstate->save_fh,
src_stateid, RD_STATE, src, NULL);
if (status) {
[PATCH 4.9 66/83] mount: Retest MNT_LOCKED in do_umount
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric W. Biederman
commit 25d202ed820ee347edec0bf3bf553544556bf64b upstream.
It was recently pointed out that the one instance of testing MNT_LOCKED
outside of the namespace_sem is in ksys_umount.
Fix that by adding a test inside of do_umount with namespace_sem and
the mount_lock held. As it helps to fail fails the existing test is
maintained with an additional comment pointing out that it may be racy
because the locks are not held.
Cc: sta...@vger.kernel.org
Reported-by: Al Viro
Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman
---
fs/namespace.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1599,8 +1599,13 @@ static int do_umount(struct mount *mnt,
namespace_lock();
lock_mount_hash();
- event++;
+ /* Recheck MNT_LOCKED with the locks held */
+ retval = -EINVAL;
+ if (mnt->mnt.mnt_flags & MNT_LOCKED)
+ goto out;
+
+ event++;
if (flags & MNT_DETACH) {
if (!list_empty(&mnt->mnt_list))
umount_tree(mnt, UMOUNT_PROPAGATE);
@@ -1614,6 +1619,7 @@ static int do_umount(struct mount *mnt,
retval = 0;
}
}
+out:
unlock_mount_hash();
namespace_unlock();
return retval;
@@ -1704,7 +1710,7 @@ SYSCALL_DEFINE2(umount, char __user *, n
goto dput_and_out;
if (!check_mnt(mnt))
goto dput_and_out;
- if (mnt->mnt.mnt_flags & MNT_LOCKED)
+ if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */
goto dput_and_out;
retval = -EPERM;
if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN))
[PATCH 4.9 33/83] xtensa: fix boot parameters address translation
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Max Filippov commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream. The bootloader may pass physical address of the boot parameters structure to the MMUv3 kernel in the register a2. Code in the _SetupMMU block in the arch/xtensa/kernel/head.S is supposed to map that physical address to the virtual address in the configured virtual memory layout. This code haven't been updated when additional 256+256 and 512+512 memory layouts were introduced and it may produce wrong addresses when used with these layouts. Cc: sta...@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman --- arch/xtensa/kernel/head.S |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/arch/xtensa/kernel/head.S +++ b/arch/xtensa/kernel/head.S @@ -88,9 +88,12 @@ _SetupMMU: initialize_mmu #if defined(CONFIG_MMU) && XCHAL_HAVE_PTP_MMU && XCHAL_HAVE_SPANNING_WAY rsr a2, excsave1 - movia3, 0x0800 + movia3, XCHAL_KSEG_PADDR + bltua2, a3, 1f + sub a2, a2, a3 + movia3, XCHAL_KSEG_SIZE bgeua2, a3, 1f - movia3, 0xd000 + movia3, XCHAL_KSEG_CACHED_VADDR add a2, a2, a3 wsr a2, excsave1 1:
[PATCH 4.9 80/83] drm/i915/hdmi: Add HDMI 2.0 audio clock recovery N values
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Clint Taylor
commit 6503493145cba4413ecd3d4d153faeef4a1e9b85 upstream.
HDMI 2.0 594Mhz modes were incorrectly selecting 25.200Mhz Automatic N value
mode instead of HDMI specification values.
V2: Fix 88.2 Hz N value
Cc: Jani Nikula
Cc: sta...@vger.kernel.org
Signed-off-by: Clint Taylor
Signed-off-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/1540493521-1746-2-git-send-email-clinton.a.tay...@intel.com
(cherry picked from commit 5a400aa3c562c4a726b4da286e63c96db905ade1)
Signed-off-by: Joonas Lahtinen
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/intel_audio.c | 17 +
1 file changed, 17 insertions(+)
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -76,6 +76,9 @@ static const struct {
/* HDMI N/CTS table */
#define TMDS_297M 297000
#define TMDS_296M 296703
+#define TMDS_594M 594000
+#define TMDS_593M 593407
+
static const struct {
int sample_rate;
int clock;
@@ -96,6 +99,20 @@ static const struct {
{ 176400, TMDS_297M, 18816, 247500 },
{ 192000, TMDS_296M, 23296, 281250 },
{ 192000, TMDS_297M, 20480, 247500 },
+ { 44100, TMDS_593M, 8918, 937500 },
+ { 44100, TMDS_594M, 9408, 99 },
+ { 48000, TMDS_593M, 5824, 562500 },
+ { 48000, TMDS_594M, 6144, 594000 },
+ { 32000, TMDS_593M, 5824, 843750 },
+ { 32000, TMDS_594M, 3072, 445500 },
+ { 88200, TMDS_593M, 17836, 937500 },
+ { 88200, TMDS_594M, 18816, 99 },
+ { 96000, TMDS_593M, 11648, 562500 },
+ { 96000, TMDS_594M, 12288, 594000 },
+ { 176400, TMDS_593M, 35672, 937500 },
+ { 176400, TMDS_594M, 37632, 99 },
+ { 192000, TMDS_593M, 23296, 562500 },
+ { 192000, TMDS_594M, 24576, 594000 },
};
/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
[PATCH 4.9 68/83] mount: Prevent MNT_DETACH from disconnecting locked mounts
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric W. Biederman
commit 9c8e0a1b683525464a2abe9fb4b54404a50ed2b4 upstream.
Timothy Baldwin wrote:
> As per mount_namespaces(7) unprivileged users should not be able to look
> under mount points:
>
> Mounts that come as a single unit from more privileged mount are locked
> together and may not be separated in a less privileged mount namespace.
>
> However they can:
>
> 1. Create a mount namespace.
> 2. In the mount namespace open a file descriptor to the parent of a mount
> point.
> 3. Destroy the mount namespace.
> 4. Use the file descriptor to look under the mount point.
>
> I have reproduced this with Linux 4.16.18 and Linux 4.18-rc8.
>
> The setup:
>
> $ sudo sysctl kernel.unprivileged_userns_clone=1
> kernel.unprivileged_userns_clone = 1
> $ mkdir -p A/B/Secret
> $ sudo mount -t tmpfs hide A/B
>
>
> "Secret" is indeed hidden as expected:
>
> $ ls -lR A
> A:
> total 0
> drwxrwxrwt 2 root root 40 Feb 12 21:08 B
>
> A/B:
> total 0
>
>
> The attack revealing "Secret":
>
> $ unshare -Umr sh -c "exec unshare -m ls -lR /proc/self/fd/4/ 4 /proc/self/fd/4/:
> total 0
> drwxr-xr-x 3 root root 60 Feb 12 21:08 B
>
> /proc/self/fd/4/B:
> total 0
> drwxr-xr-x 2 root root 40 Feb 12 21:08 Secret
>
> /proc/self/fd/4/B/Secret:
> total 0
I tracked this down to put_mnt_ns running passing UMOUNT_SYNC and
disconnecting all of the mounts in a mount namespace. Fix this by
factoring drop_mounts out of drop_collected_mounts and passing
0 instead of UMOUNT_SYNC.
There are two possible behavior differences that result from this.
- No longer setting UMOUNT_SYNC will no longer set MNT_SYNC_UMOUNT on
the vfsmounts being unmounted. This effects the lazy rcu walk by
kicking the walk out of rcu mode and forcing it to be a non-lazy
walk.
- No longer disconnecting locked mounts will keep some mounts around
longer as they stay because the are locked to other mounts.
There are only two users of drop_collected mounts: audit_tree.c and
put_mnt_ns.
In audit_tree.c the mounts are private and there are no rcu lazy walks
only calls to iterate_mounts. So the changes should have no effect
except for a small timing effect as the connected mounts are disconnected.
In put_mnt_ns there may be references from process outside the mount
namespace to the mounts. So the mounts remaining connected will
be the bug fix that is needed. That rcu walks are allowed to continue
appears not to be a problem especially as the rcu walk change was about
an implementation detail not about semantics.
Cc: sta...@vger.kernel.org
Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
Reported-by: Timothy Baldwin
Tested-by: Timothy Baldwin
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman
---
fs/namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1848,7 +1848,7 @@ void drop_collected_mounts(struct vfsmou
{
namespace_lock();
lock_mount_hash();
- umount_tree(real_mount(mnt), UMOUNT_SYNC);
+ umount_tree(real_mount(mnt), 0);
unlock_mount_hash();
namespace_unlock();
}
[PATCH 4.9 67/83] mount: Dont allow copying MNT_UNBINDABLE|MNT_LOCKED mounts
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric W. Biederman
commit df7342b240185d58d3d9665c0bbf0a0f5570ec29 upstream.
Jonathan Calmels from NVIDIA reported that he's able to bypass the
mount visibility security check in place in the Linux kernel by using
a combination of the unbindable property along with the private mount
propagation option to allow a unprivileged user to see a path which
was purposefully hidden by the root user.
Reproducer:
# Hide a path to all users using a tmpfs
root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
root@castiana:~#
# As an unprivileged user, unshare user namespace and mount namespace
stgraber@castiana:~$ unshare -U -m -r
# Confirm the path is still not accessible
root@castiana:~# ls /sys/devices/
# Make /sys recursively unbindable and private
root@castiana:~# mount --make-runbindable /sys
root@castiana:~# mount --make-private /sys
# Recursively bind-mount the rest of /sys over to /mnnt
root@castiana:~# mount --rbind /sys/ /mnt
# Access our hidden /sys/device as an unprivileged user
root@castiana:~# ls /mnt/devices/
breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe
LNXSYSTM:00 msr pci:00 platform pnp0 power software system
tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual
Solve this by teaching copy_tree to fail if a mount turns out to be
both unbindable and locked.
Cc: sta...@vger.kernel.org
Fixes: 5ff9d8a65ce8 ("vfs: Lock in place mounts from more privileged users")
Reported-by: Jonathan Calmels
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman
---
fs/namespace.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1788,8 +1788,14 @@ struct mount *copy_tree(struct mount *mn
for (s = r; s; s = next_mnt(s, r)) {
if (!(flag & CL_COPY_UNBINDABLE) &&
IS_MNT_UNBINDABLE(s)) {
- s = skip_mnt_tree(s);
- continue;
+ if (s->mnt.mnt_flags & MNT_LOCKED) {
+ /* Both unbindable and locked. */
+ q = ERR_PTR(-EPERM);
+ goto out;
+ } else {
+ s = skip_mnt_tree(s);
+ continue;
+ }
}
if (!(flag & CL_COPY_MNT_NS_FILE) &&
is_mnt_ns_file(s->mnt.mnt_root)) {
[PATCH 4.9 71/83] rtc: hctosys: Add missing range error reporting
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Maciej W. Rozycki
commit 7ce9a992ffde8ce93d5ae5767362a5c7389ae895 upstream.
Fix an issue with the 32-bit range error path in `rtc_hctosys' where no
error code is set and consequently the successful preceding call result
from `rtc_read_time' is propagated to `rtc_hctosys_ret'. This in turn
makes any subsequent call to `hctosys_show' incorrectly report in sysfs
that the system time has been set from this RTC while it has not.
Set the error to ERANGE then if we can't express the result due to an
overflow.
Signed-off-by: Maciej W. Rozycki
Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Cc: sta...@vger.kernel.org # 4.17+
Signed-off-by: Alexandre Belloni
Signed-off-by: Greg Kroah-Hartman
---
drivers/rtc/hctosys.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/rtc/hctosys.c
+++ b/drivers/rtc/hctosys.c
@@ -50,8 +50,10 @@ static int __init rtc_hctosys(void)
tv64.tv_sec = rtc_tm_to_time64(&tm);
#if BITS_PER_LONG == 32
- if (tv64.tv_sec > INT_MAX)
+ if (tv64.tv_sec > INT_MAX) {
+ err = -ERANGE;
goto err_read;
+ }
#endif
err = do_settimeofday64(&tv64);
[PATCH 4.9 83/83] ovl: check whiteout in ovl_create_over_whiteout()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Miklos Szeredi
commit 5e1275808630ea3b2c97c776f40e475017535f72 upstream.
Kaixuxia repors that it's possible to crash overlayfs by removing the
whiteout on the upper layer before creating a directory over it. This is a
reproducer:
mkdir lower upper work merge
touch lower/file
mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge
rm merge/file
ls -al merge/file
rm upper/file
ls -al merge/
mkdir merge/file
Before commencing with a vfs_rename(..., RENAME_EXCHANGE) verify that the
lookup of "upper" is positive and is a whiteout, and return ESTALE
otherwise.
Reported by: kaixuxia
Signed-off-by: Miklos Szeredi
Fixes: e9be9d5e76e3 ("overlay filesystem")
Cc: # v3.18
Signed-off-by: Greg Kroah-Hartman
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -392,6 +392,10 @@ static int ovl_create_over_whiteout(struct dentry *dentry,
struct inode *inode,
if (IS_ERR(upper))
goto out_dput;
+ err = -ESTALE;
+ if (d_is_negative(upper) || !IS_WHITEOUT(d_inode(upper)))
+ goto out_dput2;
+
err = ovl_create_real(wdir, newdentry, cattr, hardlink, true);
if (err)
goto out_dput2;
--
2.14.5
[PATCH 4.9 37/83] libceph: bump CEPH_MSG_MAX_DATA_LEN
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ilya Dryomov
commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.
If the read is large enough, we end up spinning in the messenger:
libceph: osd0 192.168.122.1:6801 io error
libceph: osd0 192.168.122.1:6801 io error
libceph: osd0 192.168.122.1:6801 io error
This is a receive side limit, so only reads were affected.
Cc: sta...@vger.kernel.org
Signed-off-by: Ilya Dryomov
Signed-off-by: Greg Kroah-Hartman
---
include/linux/ceph/libceph.h |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/include/linux/ceph/libceph.h
+++ b/include/linux/ceph/libceph.h
@@ -77,7 +77,13 @@ struct ceph_options {
#define CEPH_MSG_MAX_FRONT_LEN (16*1024*1024)
#define CEPH_MSG_MAX_MIDDLE_LEN(16*1024*1024)
-#define CEPH_MSG_MAX_DATA_LEN (16*1024*1024)
+
+/*
+ * Handle the largest possible rbd object in one message.
+ * There is no limit on the size of cephfs objects, but it has to obey
+ * rsize and wsize mount options anyway.
+ */
+#define CEPH_MSG_MAX_DATA_LEN (32*1024*1024)
#define CEPH_AUTH_NAME_DEFAULT "guest"
[PATCH 4.9 32/83] xtensa: make sure bFLT stack is 16 byte aligned
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Max Filippov commit 0773495b1f5f1c5e23551843f87b5ff37e7af8f7 upstream. Xtensa ABI requires stack alignment to be at least 16. In noMMU configuration ARCH_SLAB_MINALIGN is used to align stack. Make it at least 16. This fixes the following runtime error in noMMU configuration, caused by interaction between insufficiently aligned stack and alloca function, that results in corruption of on-stack variable in the libc function glob: Caught unhandled exception in 'sh' (pid = 47, pc = 0x02d05d65) - should not happen EXCCAUSE is 15 Cc: sta...@vger.kernel.org Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman --- arch/xtensa/include/asm/processor.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/arch/xtensa/include/asm/processor.h +++ b/arch/xtensa/include/asm/processor.h @@ -24,7 +24,11 @@ # error Linux requires the Xtensa Windowed Registers Option. #endif -#define ARCH_SLAB_MINALIGN XCHAL_DATA_WIDTH +/* Xtensa ABI requires stack alignment to be at least 16 */ + +#define STACK_ALIGN (XCHAL_DATA_WIDTH > 16 ? XCHAL_DATA_WIDTH : 16) + +#define ARCH_SLAB_MINALIGN STACK_ALIGN /* * User space process size: 1 GB.
[PATCH 4.9 76/83] hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444!
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Mike Kravetz
commit 5e41540c8a0f0e98c337dda8b391e5dda0cde7cf upstream.
This bug has been experienced several times by the Oracle DB team. The
BUG is in remove_inode_hugepages() as follows:
/*
* If page is mapped, it was faulted in after being
* unmapped in caller. Unmap (again) now after taking
* the fault mutex. The mutex will prevent faults
* until we finish removing the page.
*
* This race can only happen in the hole punch case.
* Getting here in a truncate operation is a bug.
*/
if (unlikely(page_mapped(page))) {
BUG_ON(truncate_op);
In this case, the elevated map count is not the result of a race.
Rather it was incorrectly incremented as the result of a bug in the huge
pmd sharing code. Consider the following:
- Process A maps a hugetlbfs file of sufficient size and alignment
(PUD_SIZE) that a pmd page could be shared.
- Process B maps the same hugetlbfs file with the same size and
alignment such that a pmd page is shared.
- Process B then calls mprotect() to change protections for the mapping
with the shared pmd. As a result, the pmd is 'unshared'.
- Process B then calls mprotect() again to chage protections for the
mapping back to their original value. pmd remains unshared.
- Process B then forks and process C is created. During the fork
process, we do dup_mm -> dup_mmap -> copy_page_range to copy page
tables. Copying page tables for hugetlb mappings is done in the
routine copy_hugetlb_page_range.
In copy_hugetlb_page_range(), the destination pte is obtained by:
dst_pte = huge_pte_alloc(dst, addr, sz);
If pmd sharing is possible, the returned pointer will be to a pte in an
existing page table. In the situation above, process C could share with
either process A or process B. Since process A is first in the list,
the returned pte is a pointer to a pte in process A's page table.
However, the check for pmd sharing in copy_hugetlb_page_range is:
/* If the pagetables are shared don't copy or take references */
if (dst_pte == src_pte)
continue;
Since process C is sharing with process A instead of process B, the
above test fails. The code in copy_hugetlb_page_range which follows
assumes dst_pte points to a huge_pte_none pte. It copies the pte entry
from src_pte to dst_pte and increments this map count of the associated
page. This is how we end up with an elevated map count.
To solve, check the dst_pte entry for huge_pte_none. If !none, this
implies PMD sharing so do not copy.
Link: http://lkml.kernel.org/r/20181105212315.14125-1-mike.krav...@oracle.com
Fixes: c5c99429fa57 ("fix hugepages leak due to pagetable page sharing")
Signed-off-by: Mike Kravetz
Reviewed-by: Naoya Horiguchi
Cc: Michal Hocko
Cc: Hugh Dickins
Cc: Andrea Arcangeli
Cc: "Kirill A . Shutemov"
Cc: Davidlohr Bueso
Cc: Prakash Sangappa
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/hugetlb.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3220,7 +3220,7 @@ static int is_hugetlb_entry_hwpoisoned(p
int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
struct vm_area_struct *vma)
{
- pte_t *src_pte, *dst_pte, entry;
+ pte_t *src_pte, *dst_pte, entry, dst_entry;
struct page *ptepage;
unsigned long addr;
int cow;
@@ -3248,15 +3248,30 @@ int copy_hugetlb_page_range(struct mm_st
break;
}
- /* If the pagetables are shared don't copy or take references */
- if (dst_pte == src_pte)
+ /*
+* If the pagetables are shared don't copy or take references.
+* dst_pte == src_pte is the common case of src/dest sharing.
+*
+* However, src could have 'unshared' and dst shares with
+* another vma. If dst_pte !none, this implies sharing.
+* Check here before taking page table lock, and once again
+* after taking the lock below.
+*/
+ dst_entry = huge_ptep_get(dst_pte);
+ if ((dst_pte == src_pte) || !huge_pte_none(dst_entry))
continue;
dst_ptl = huge_pte_lock(h, dst, dst_pte);
src_ptl = huge_pte_lockptr(h, src, src_pte);
spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
entry = huge_ptep_get(src_pte);
- if (huge_pte_none(entry)) { /* skip none entry */
+ dst_entry = huge_ptep_get(dst_pte);
+ if (huge_pte_none(entry) || !huge_pte_none(dst_entry)) {
+ /*
+
[PATCH 4.9 73/83] fuse: fix leaked notify reply
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Miklos Szeredi
commit 7fabaf303458fcabb694999d6fa772cc13d4e217 upstream.
fuse_request_send_notify_reply() may fail if the connection was reset for
some reason (e.g. fs was unmounted). Don't leak request reference in this
case. Besides leaking memory, this resulted in fc->num_waiting not being
decremented and hence fuse_wait_aborted() left in a hanging and unkillable
state.
Fixes: 2d45ba381a74 ("fuse: add retrieve request")
Fixes: b8f95e5d13f5 ("fuse: umount should wait for all requests")
Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c...@syzkaller.appspotmail.com
Signed-off-by: Miklos Szeredi
Cc: #v2.6.36
Signed-off-by: Greg Kroah-Hartman
---
fs/fuse/dev.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -1715,8 +1715,10 @@ static int fuse_retrieve(struct fuse_con
req->in.args[1].size = total_len;
err = fuse_request_send_notify_reply(fc, req, outarg->notify_unique);
- if (err)
+ if (err) {
fuse_retrieve_end(fc, req);
+ fuse_put_request(fc, req);
+ }
return err;
}
[PATCH 4.9 74/83] configfs: replace strncpy with memcpy
4.9-stable review patch. If anyone has any objections, please let me know. -- From: Guenter Roeck commit 1823342a1f2b47a4e6f5667f67cd28ab6bc4d6cd upstream. gcc 8.1.0 complains: fs/configfs/symlink.c:67:3: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length fs/configfs/symlink.c: In function 'configfs_get_link': fs/configfs/symlink.c:63:13: note: length computed here Using strncpy() is indeed less than perfect since the length of data to be copied has already been determined with strlen(). Replace strncpy() with memcpy() to address the warning and optimize the code a little. Signed-off-by: Guenter Roeck Signed-off-by: Christoph Hellwig Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman --- fs/configfs/symlink.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/configfs/symlink.c +++ b/fs/configfs/symlink.c @@ -64,7 +64,7 @@ static void fill_item_path(struct config /* back up enough to print this bus id with '/' */ length -= cur; - strncpy(buffer + length,config_item_name(p),cur); + memcpy(buffer + length, config_item_name(p), cur); *(buffer + --length) = '/'; } }
[PATCH 4.9 65/83] ext4: fix buffer leak in __ext4_read_dirblock() on error path
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit de59fae0043f07de5d25e02ca360f7d57bfa5866 upstream.
Fixes: dc6982ff4db1 ("ext4: refactor code to read directory blocks ...")
Signed-off-by: Vasily Averin
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org # 3.9
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/namei.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -124,6 +124,7 @@ static struct buffer_head *__ext4_read_d
if (!is_dx_block && type == INDEX) {
ext4_error_inode(inode, func, line, block,
"directory leaf block found instead of index block");
+ brelse(bh);
return ERR_PTR(-EFSCORRUPTED);
}
if (!ext4_has_metadata_csum(inode->i_sb) ||
[PATCH 4.9 56/83] ext4: avoid potential extra brelse in setup_new_flex_group_blocks()
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit 9e4028935cca3f9ef9b6a90df9da6f1f94853536 upstream.
Currently bh is set to NULL only during first iteration of for cycle,
then this pointer is not cleared after end of using.
Therefore rollback after errors can lead to extra brelse(bh) call,
decrements bh counter and later trigger an unexpected warning in __brelse()
Patch moves brelse() calls in body of cycle to exclude requirement of
brelse() call in rollback.
Fixes: 33afdcc5402d ("ext4: add a function which sets up group blocks ...")
Signed-off-by: Vasily Averin
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org # 3.3+
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/resize.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -590,7 +590,6 @@ handle_bb:
bh = bclean(handle, sb, block);
if (IS_ERR(bh)) {
err = PTR_ERR(bh);
- bh = NULL;
goto out;
}
overhead = ext4_group_overhead_blocks(sb, group);
@@ -602,9 +601,9 @@ handle_bb:
ext4_mark_bitmap_end(group_data[i].blocks_count,
sb->s_blocksize * 8, bh->b_data);
err = ext4_handle_dirty_metadata(handle, NULL, bh);
+ brelse(bh);
if (err)
goto out;
- brelse(bh);
handle_ib:
if (bg_flags[i] & EXT4_BG_INODE_UNINIT)
@@ -619,18 +618,16 @@ handle_ib:
bh = bclean(handle, sb, block);
if (IS_ERR(bh)) {
err = PTR_ERR(bh);
- bh = NULL;
goto out;
}
ext4_mark_bitmap_end(EXT4_INODES_PER_GROUP(sb),
sb->s_blocksize * 8, bh->b_data);
err = ext4_handle_dirty_metadata(handle, NULL, bh);
+ brelse(bh);
if (err)
goto out;
- brelse(bh);
}
- bh = NULL;
/* Mark group tables in block bitmap */
for (j = 0; j < GROUP_TABLE_COUNT; j++) {
@@ -661,7 +658,6 @@ handle_ib:
}
out:
- brelse(bh);
err2 = ext4_journal_stop(handle);
if (err2 && !err)
err = err2;
[PATCH 4.9 30/83] MIPS: Loongson-3: Fix BRIDGE irq delivery problem
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 360fe725f8849aaddc53475fef5d4a0c439b05ae ]
After commit e509bd7da149dc349160 ("genirq: Allow migration of chained
interrupts by installing default action") Loongson-3 fails at here:
setup_irq(LOONGSON_HT1_IRQ, &cascade_irqaction);
This is because both chained_action and cascade_irqaction don't have
IRQF_SHARED flag. This will cause Loongson-3 resume fails because HPET
timer interrupt can't be delivered during S3. So we set the irqchip of
the chained irq to loongson_irq_chip which doesn't disable the chained
irq in CP0.Status.
Cc: sta...@vger.kernel.org
Signed-off-by: Huacai Chen
Signed-off-by: Paul Burton
Patchwork: https://patchwork.linux-mips.org/patch/20434/
Cc: Ralf Baechle
Cc: James Hogan
Cc: linux-m...@linux-mips.org
Cc: Fuxin Zhang
Cc: Zhangjin Wu
Cc: Huacai Chen
Signed-off-by: Sasha Levin
---
arch/mips/include/asm/mach-loongson64/irq.h | 2 +-
arch/mips/loongson64/loongson-3/irq.c | 13 +++--
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/irq.h
b/arch/mips/include/asm/mach-loongson64/irq.h
index d18c45c7c394..19ff9ce46c02 100644
--- a/arch/mips/include/asm/mach-loongson64/irq.h
+++ b/arch/mips/include/asm/mach-loongson64/irq.h
@@ -9,7 +9,7 @@
#define MIPS_CPU_IRQ_BASE 56
#define LOONGSON_UART_IRQ (MIPS_CPU_IRQ_BASE + 2) /* UART */
-#define LOONGSON_HT1_IRQ(MIPS_CPU_IRQ_BASE + 3) /* HT1 */
+#define LOONGSON_BRIDGE_IRQ (MIPS_CPU_IRQ_BASE + 3) /* CASCADE */
#define LOONGSON_TIMER_IRQ (MIPS_CPU_IRQ_BASE + 7) /* CPU Timer */
#define LOONGSON_HT1_CFG_BASE loongson_sysconf.ht_control_base
diff --git a/arch/mips/loongson64/loongson-3/irq.c
b/arch/mips/loongson64/loongson-3/irq.c
index ec5f2b30646c..027f53e3bc81 100644
--- a/arch/mips/loongson64/loongson-3/irq.c
+++ b/arch/mips/loongson64/loongson-3/irq.c
@@ -44,12 +44,6 @@ void mach_irq_dispatch(unsigned int pending)
}
}
-static struct irqaction cascade_irqaction = {
- .handler = no_action,
- .flags = IRQF_NO_SUSPEND,
- .name = "cascade",
-};
-
static inline void mask_loongson_irq(struct irq_data *d) { }
static inline void unmask_loongson_irq(struct irq_data *d) { }
@@ -90,11 +84,10 @@ void __init mach_init_irq(void)
init_i8259_irqs();
irq_set_chip_and_handler(LOONGSON_UART_IRQ,
&loongson_irq_chip, handle_percpu_irq);
+ irq_set_chip_and_handler(LOONGSON_BRIDGE_IRQ,
+ &loongson_irq_chip, handle_percpu_irq);
- /* setup HT1 irq */
- setup_irq(LOONGSON_HT1_IRQ, &cascade_irqaction);
-
- set_c0_status(STATUSF_IP2 | STATUSF_IP6);
+ set_c0_status(STATUSF_IP2 | STATUSF_IP3 | STATUSF_IP6);
}
#ifdef CONFIG_HOTPLUG_CPU
--
2.17.1
[PATCH 4.9 58/83] ext4: avoid buffer leak in ext4_orphan_add() after prior errors
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Vasily Averin
commit feaf264ce7f8d54582e2f66eb82dd9dd124c94f3 upstream.
Fixes: d745a8c20c1f ("ext4: reduce contention on s_orphan_lock")
Fixes: 6e3617e579e0 ("ext4: Handle non empty on-disk orphan link")
Cc: Dmitry Monakhov
Signed-off-by: Vasily Averin
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org # 2.6.34
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/namei.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2842,7 +2842,9 @@ int ext4_orphan_add(handle_t *handle, st
list_del_init(&EXT4_I(inode)->i_orphan);
mutex_unlock(&sbi->s_orphan_lock);
}
- }
+ } else
+ brelse(iloc.bh);
+
jbd_debug(4, "superblock will point to %lu\n", inode->i_ino);
jbd_debug(4, "orphan inode %lu will point to %d\n",
inode->i_ino, NEXT_ORPHAN(inode));
