* [PATCH 4.4 001/103] usb: misc: legousbtower: Fix buffers on stack
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 002/103] usb: misc: legousbtower: Fix memory leak Greg Kroah-Hartman
` (96 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maksim Salau, Alfredo Rafael Vicente Boix
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maksim Salau <maksim.salau@gmail.com>
commit 942a48730faf149ccbf3e12ac718aee120bb3529 upstream.
Allocate buffers on HEAP instead of STACK for local structures
that are to be received using usb_control_msg().
Signed-off-by: Maksim Salau <maksim.salau@gmail.com>
Tested-by: Alfredo Rafael Vicente Boix <alviboi@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/misc/legousbtower.c | 37 +++++++++++++++++++++++++++----------
1 file changed, 27 insertions(+), 10 deletions(-)
--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -317,9 +317,16 @@ static int tower_open (struct inode *ino
int subminor;
int retval = 0;
struct usb_interface *interface;
- struct tower_reset_reply reset_reply;
+ struct tower_reset_reply *reset_reply;
int result;
+ reset_reply = kmalloc(sizeof(*reset_reply), GFP_KERNEL);
+
+ if (!reset_reply) {
+ retval = -ENOMEM;
+ goto exit;
+ }
+
nonseekable_open(inode, file);
subminor = iminor(inode);
@@ -364,8 +371,8 @@ static int tower_open (struct inode *ino
USB_TYPE_VENDOR | USB_DIR_IN | USB_RECIP_DEVICE,
0,
0,
- &reset_reply,
- sizeof(reset_reply),
+ reset_reply,
+ sizeof(*reset_reply),
1000);
if (result < 0) {
dev_err(&dev->udev->dev,
@@ -406,6 +413,7 @@ unlock_exit:
mutex_unlock(&dev->lock);
exit:
+ kfree(reset_reply);
return retval;
}
@@ -808,7 +816,7 @@ static int tower_probe (struct usb_inter
struct lego_usb_tower *dev = NULL;
struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor* endpoint;
- struct tower_get_version_reply get_version_reply;
+ struct tower_get_version_reply *get_version_reply = NULL;
int i;
int retval = -ENOMEM;
int result;
@@ -898,6 +906,13 @@ static int tower_probe (struct usb_inter
dev->interrupt_in_interval = interrupt_in_interval ? interrupt_in_interval : dev->interrupt_in_endpoint->bInterval;
dev->interrupt_out_interval = interrupt_out_interval ? interrupt_out_interval : dev->interrupt_out_endpoint->bInterval;
+ get_version_reply = kmalloc(sizeof(*get_version_reply), GFP_KERNEL);
+
+ if (!get_version_reply) {
+ retval = -ENOMEM;
+ goto error;
+ }
+
/* get the firmware version and log it */
result = usb_control_msg (udev,
usb_rcvctrlpipe(udev, 0),
@@ -905,18 +920,19 @@ static int tower_probe (struct usb_inter
USB_TYPE_VENDOR | USB_DIR_IN | USB_RECIP_DEVICE,
0,
0,
- &get_version_reply,
- sizeof(get_version_reply),
+ get_version_reply,
+ sizeof(*get_version_reply),
1000);
if (result < 0) {
dev_err(idev, "LEGO USB Tower get version control request failed\n");
retval = result;
goto error;
}
- dev_info(&interface->dev, "LEGO USB Tower firmware version is %d.%d "
- "build %d\n", get_version_reply.major,
- get_version_reply.minor,
- le16_to_cpu(get_version_reply.build_no));
+ dev_info(&interface->dev,
+ "LEGO USB Tower firmware version is %d.%d build %d\n",
+ get_version_reply->major,
+ get_version_reply->minor,
+ le16_to_cpu(get_version_reply->build_no));
/* we can register the device now, as it is ready */
usb_set_intfdata (interface, dev);
@@ -940,6 +956,7 @@ exit:
return retval;
error:
+ kfree(get_version_reply);
tower_delete(dev);
return retval;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 002/103] usb: misc: legousbtower: Fix memory leak
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 001/103] usb: misc: legousbtower: Fix buffers on stack Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 003/103] USB: ene_usb6250: fix DMA to the stack Greg Kroah-Hartman
` (95 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Heikki Krogerus, Maksim Salau
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maksim Salau <maksim.salau@gmail.com>
commit 0bd193d62b4270a2a7a09da43ad1034c7ca5b3d3 upstream.
get_version_reply is not freed if function returns with success.
Fixes: 942a48730faf ("usb: misc: legousbtower: Fix buffers on stack")
Reported-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Maksim Salau <maksim.salau@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/misc/legousbtower.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/misc/legousbtower.c
+++ b/drivers/usb/misc/legousbtower.c
@@ -953,6 +953,7 @@ static int tower_probe (struct usb_inter
USB_MAJOR, dev->minor);
exit:
+ kfree(get_version_reply);
return retval;
error:
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 003/103] USB: ene_usb6250: fix DMA to the stack
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 001/103] usb: misc: legousbtower: Fix buffers on stack Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 002/103] usb: misc: legousbtower: Fix memory leak Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 004/103] watchdog: pcwd_usb: fix NULL-deref at probe Greg Kroah-Hartman
` (94 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alan Stern
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <stern@rowland.harvard.edu>
commit 628c2893d44876ddd11602400c70606ade62e129 upstream.
The ene_usb6250 sub-driver in usb-storage does USB I/O to buffers on
the stack, which doesn't work with vmapped stacks. This patch fixes
the problem by allocating a separate 512-byte buffer at probe time and
using it for all of the offending I/O operations.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/storage/ene_ub6250.c | 90 +++++++++++++++++++++++----------------
1 file changed, 55 insertions(+), 35 deletions(-)
--- a/drivers/usb/storage/ene_ub6250.c
+++ b/drivers/usb/storage/ene_ub6250.c
@@ -446,6 +446,10 @@ struct ms_lib_ctrl {
#define SD_BLOCK_LEN 9
struct ene_ub6250_info {
+
+ /* I/O bounce buffer */
+ u8 *bbuf;
+
/* for 6250 code */
struct SD_STATUS SD_Status;
struct MS_STATUS MS_Status;
@@ -493,8 +497,11 @@ static int ene_load_bincode(struct us_da
static void ene_ub6250_info_destructor(void *extra)
{
+ struct ene_ub6250_info *info = (struct ene_ub6250_info *) extra;
+
if (!extra)
return;
+ kfree(info->bbuf);
}
static int ene_send_scsi_cmd(struct us_data *us, u8 fDir, void *buf, int use_sg)
@@ -858,8 +865,9 @@ static int ms_read_readpage(struct us_da
u8 PageNum, u32 *PageBuf, struct ms_lib_type_extdat *ExtraDat)
{
struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
+ struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra;
+ u8 *bbuf = info->bbuf;
int result;
- u8 ExtBuf[4];
u32 bn = PhyBlockAddr * 0x20 + PageNum;
/* printk(KERN_INFO "MS --- MS_ReaderReadPage,
@@ -902,7 +910,7 @@ static int ms_read_readpage(struct us_da
bcb->CDB[2] = (unsigned char)(PhyBlockAddr>>16);
bcb->CDB[6] = 0x01;
- result = ene_send_scsi_cmd(us, FDIR_READ, &ExtBuf, 0);
+ result = ene_send_scsi_cmd(us, FDIR_READ, bbuf, 0);
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
@@ -911,9 +919,9 @@ static int ms_read_readpage(struct us_da
ExtraDat->status0 = 0x10; /* Not yet,fireware support */
ExtraDat->status1 = 0x00; /* Not yet,fireware support */
- ExtraDat->ovrflg = ExtBuf[0];
- ExtraDat->mngflg = ExtBuf[1];
- ExtraDat->logadr = memstick_logaddr(ExtBuf[2], ExtBuf[3]);
+ ExtraDat->ovrflg = bbuf[0];
+ ExtraDat->mngflg = bbuf[1];
+ ExtraDat->logadr = memstick_logaddr(bbuf[2], bbuf[3]);
return USB_STOR_TRANSPORT_GOOD;
}
@@ -1339,8 +1347,9 @@ static int ms_lib_read_extra(struct us_d
u8 PageNum, struct ms_lib_type_extdat *ExtraDat)
{
struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
+ struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra;
+ u8 *bbuf = info->bbuf;
int result;
- u8 ExtBuf[4];
/* printk("MS_LibReadExtra --- PhyBlock = %x, PageNum = %x\n", PhyBlock, PageNum); */
memset(bcb, 0, sizeof(struct bulk_cb_wrap));
@@ -1355,7 +1364,7 @@ static int ms_lib_read_extra(struct us_d
bcb->CDB[2] = (unsigned char)(PhyBlock>>16);
bcb->CDB[6] = 0x01;
- result = ene_send_scsi_cmd(us, FDIR_READ, &ExtBuf, 0);
+ result = ene_send_scsi_cmd(us, FDIR_READ, bbuf, 0);
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
@@ -1363,9 +1372,9 @@ static int ms_lib_read_extra(struct us_d
ExtraDat->intr = 0x80; /* Not yet, waiting for fireware support */
ExtraDat->status0 = 0x10; /* Not yet, waiting for fireware support */
ExtraDat->status1 = 0x00; /* Not yet, waiting for fireware support */
- ExtraDat->ovrflg = ExtBuf[0];
- ExtraDat->mngflg = ExtBuf[1];
- ExtraDat->logadr = memstick_logaddr(ExtBuf[2], ExtBuf[3]);
+ ExtraDat->ovrflg = bbuf[0];
+ ExtraDat->mngflg = bbuf[1];
+ ExtraDat->logadr = memstick_logaddr(bbuf[2], bbuf[3]);
return USB_STOR_TRANSPORT_GOOD;
}
@@ -1569,9 +1578,9 @@ static int ms_lib_scan_logicalblocknumbe
u16 PhyBlock, newblk, i;
u16 LogStart, LogEnde;
struct ms_lib_type_extdat extdat;
- u8 buf[0x200];
u32 count = 0, index = 0;
struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra;
+ u8 *bbuf = info->bbuf;
for (PhyBlock = 0; PhyBlock < info->MS_Lib.NumberOfPhyBlock;) {
ms_lib_phy_to_log_range(PhyBlock, &LogStart, &LogEnde);
@@ -1585,14 +1594,16 @@ static int ms_lib_scan_logicalblocknumbe
}
if (count == PhyBlock) {
- ms_lib_read_extrablock(us, PhyBlock, 0, 0x80, &buf);
+ ms_lib_read_extrablock(us, PhyBlock, 0, 0x80,
+ bbuf);
count += 0x80;
}
index = (PhyBlock % 0x80) * 4;
- extdat.ovrflg = buf[index];
- extdat.mngflg = buf[index+1];
- extdat.logadr = memstick_logaddr(buf[index+2], buf[index+3]);
+ extdat.ovrflg = bbuf[index];
+ extdat.mngflg = bbuf[index+1];
+ extdat.logadr = memstick_logaddr(bbuf[index+2],
+ bbuf[index+3]);
if ((extdat.ovrflg & MS_REG_OVR_BKST) != MS_REG_OVR_BKST_OK) {
ms_lib_setacquired_errorblock(us, PhyBlock);
@@ -2075,9 +2086,9 @@ static int ene_ms_init(struct us_data *u
{
struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
int result;
- u8 buf[0x200];
u16 MSP_BlockSize, MSP_UserAreaBlocks;
struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra;
+ u8 *bbuf = info->bbuf;
printk(KERN_INFO "transport --- ENE_MSInit\n");
@@ -2096,13 +2107,13 @@ static int ene_ms_init(struct us_data *u
bcb->CDB[0] = 0xF1;
bcb->CDB[1] = 0x01;
- result = ene_send_scsi_cmd(us, FDIR_READ, &buf, 0);
+ result = ene_send_scsi_cmd(us, FDIR_READ, bbuf, 0);
if (result != USB_STOR_XFER_GOOD) {
printk(KERN_ERR "Execution MS Init Code Fail !!\n");
return USB_STOR_TRANSPORT_ERROR;
}
/* the same part to test ENE */
- info->MS_Status = *(struct MS_STATUS *)&buf[0];
+ info->MS_Status = *(struct MS_STATUS *) bbuf;
if (info->MS_Status.Insert && info->MS_Status.Ready) {
printk(KERN_INFO "Insert = %x\n", info->MS_Status.Insert);
@@ -2111,15 +2122,15 @@ static int ene_ms_init(struct us_data *u
printk(KERN_INFO "IsMSPHG = %x\n", info->MS_Status.IsMSPHG);
printk(KERN_INFO "WtP= %x\n", info->MS_Status.WtP);
if (info->MS_Status.IsMSPro) {
- MSP_BlockSize = (buf[6] << 8) | buf[7];
- MSP_UserAreaBlocks = (buf[10] << 8) | buf[11];
+ MSP_BlockSize = (bbuf[6] << 8) | bbuf[7];
+ MSP_UserAreaBlocks = (bbuf[10] << 8) | bbuf[11];
info->MSP_TotalBlock = MSP_BlockSize * MSP_UserAreaBlocks;
} else {
ms_card_init(us); /* Card is MS (to ms.c)*/
}
usb_stor_dbg(us, "MS Init Code OK !!\n");
} else {
- usb_stor_dbg(us, "MS Card Not Ready --- %x\n", buf[0]);
+ usb_stor_dbg(us, "MS Card Not Ready --- %x\n", bbuf[0]);
return USB_STOR_TRANSPORT_ERROR;
}
@@ -2129,9 +2140,9 @@ static int ene_ms_init(struct us_data *u
static int ene_sd_init(struct us_data *us)
{
int result;
- u8 buf[0x200];
struct bulk_cb_wrap *bcb = (struct bulk_cb_wrap *) us->iobuf;
struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra;
+ u8 *bbuf = info->bbuf;
usb_stor_dbg(us, "transport --- ENE_SDInit\n");
/* SD Init Part-1 */
@@ -2165,17 +2176,17 @@ static int ene_sd_init(struct us_data *u
bcb->Flags = US_BULK_FLAG_IN;
bcb->CDB[0] = 0xF1;
- result = ene_send_scsi_cmd(us, FDIR_READ, &buf, 0);
+ result = ene_send_scsi_cmd(us, FDIR_READ, bbuf, 0);
if (result != USB_STOR_XFER_GOOD) {
usb_stor_dbg(us, "Execution SD Init Code Fail !!\n");
return USB_STOR_TRANSPORT_ERROR;
}
- info->SD_Status = *(struct SD_STATUS *)&buf[0];
+ info->SD_Status = *(struct SD_STATUS *) bbuf;
if (info->SD_Status.Insert && info->SD_Status.Ready) {
struct SD_STATUS *s = &info->SD_Status;
- ene_get_card_status(us, (unsigned char *)&buf);
+ ene_get_card_status(us, bbuf);
usb_stor_dbg(us, "Insert = %x\n", s->Insert);
usb_stor_dbg(us, "Ready = %x\n", s->Ready);
usb_stor_dbg(us, "IsMMC = %x\n", s->IsMMC);
@@ -2183,7 +2194,7 @@ static int ene_sd_init(struct us_data *u
usb_stor_dbg(us, "HiSpeed = %x\n", s->HiSpeed);
usb_stor_dbg(us, "WtP = %x\n", s->WtP);
} else {
- usb_stor_dbg(us, "SD Card Not Ready --- %x\n", buf[0]);
+ usb_stor_dbg(us, "SD Card Not Ready --- %x\n", bbuf[0]);
return USB_STOR_TRANSPORT_ERROR;
}
return USB_STOR_TRANSPORT_GOOD;
@@ -2193,13 +2204,15 @@ static int ene_sd_init(struct us_data *u
static int ene_init(struct us_data *us)
{
int result;
- u8 misc_reg03 = 0;
+ u8 misc_reg03;
struct ene_ub6250_info *info = (struct ene_ub6250_info *)(us->extra);
+ u8 *bbuf = info->bbuf;
- result = ene_get_card_type(us, REG_CARD_STATUS, &misc_reg03);
+ result = ene_get_card_type(us, REG_CARD_STATUS, bbuf);
if (result != USB_STOR_XFER_GOOD)
return USB_STOR_TRANSPORT_ERROR;
+ misc_reg03 = bbuf[0];
if (misc_reg03 & 0x01) {
if (!info->SD_Status.Ready) {
result = ene_sd_init(us);
@@ -2316,8 +2329,9 @@ static int ene_ub6250_probe(struct usb_i
const struct usb_device_id *id)
{
int result;
- u8 misc_reg03 = 0;
+ u8 misc_reg03;
struct us_data *us;
+ struct ene_ub6250_info *info;
result = usb_stor_probe1(&us, intf, id,
(id - ene_ub6250_usb_ids) + ene_ub6250_unusual_dev_list,
@@ -2326,11 +2340,16 @@ static int ene_ub6250_probe(struct usb_i
return result;
/* FIXME: where should the code alloc extra buf ? */
- if (!us->extra) {
- us->extra = kzalloc(sizeof(struct ene_ub6250_info), GFP_KERNEL);
- if (!us->extra)
- return -ENOMEM;
- us->extra_destructor = ene_ub6250_info_destructor;
+ us->extra = kzalloc(sizeof(struct ene_ub6250_info), GFP_KERNEL);
+ if (!us->extra)
+ return -ENOMEM;
+ us->extra_destructor = ene_ub6250_info_destructor;
+
+ info = (struct ene_ub6250_info *)(us->extra);
+ info->bbuf = kmalloc(512, GFP_KERNEL);
+ if (!info->bbuf) {
+ kfree(us->extra);
+ return -ENOMEM;
}
us->transport_name = "ene_ub6250";
@@ -2342,12 +2361,13 @@ static int ene_ub6250_probe(struct usb_i
return result;
/* probe card type */
- result = ene_get_card_type(us, REG_CARD_STATUS, &misc_reg03);
+ result = ene_get_card_type(us, REG_CARD_STATUS, info->bbuf);
if (result != USB_STOR_XFER_GOOD) {
usb_stor_disconnect(intf);
return USB_STOR_TRANSPORT_ERROR;
}
+ misc_reg03 = info->bbuf[0];
if (!(misc_reg03 & 0x01)) {
pr_info("ums_eneub6250: This driver only supports SD/MS cards. "
"It does not support SM cards.\n");
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 004/103] watchdog: pcwd_usb: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 003/103] USB: ene_usb6250: fix DMA to the stack Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 005/103] char: lp: fix possible integer overflow in lp_setup() Greg Kroah-Hartman
` (93 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johan Hovold, Guenter Roeck,
Wim Van Sebroeck
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 46c319b848268dab3f0e7c4a5b6e9146d3bca8a4 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/watchdog/pcwd_usb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/watchdog/pcwd_usb.c
+++ b/drivers/watchdog/pcwd_usb.c
@@ -630,6 +630,9 @@ static int usb_pcwd_probe(struct usb_int
return -ENODEV;
}
+ if (iface_desc->desc.bNumEndpoints < 1)
+ return -ENODEV;
+
/* check out the endpoint: it has to be Interrupt & IN */
endpoint = &iface_desc->endpoint[0].desc;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 005/103] char: lp: fix possible integer overflow in lp_setup()
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 004/103] watchdog: pcwd_usb: fix NULL-deref at probe Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 006/103] USB: core: replace %p with %pK Greg Kroah-Hartman
` (92 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roee Hay, Ben Hutchings, Willy Tarreau
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willy Tarreau <w@1wt.eu>
commit 3e21f4af170bebf47c187c1ff8bf155583c9f3b1 upstream.
The lp_setup() code doesn't apply any bounds checking when passing
"lp=none", and only in this case, resulting in an overflow of the
parport_nr[] array. All versions in Git history are affected.
Reported-By: Roee Hay <roee.hay@hcl.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/lp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -859,7 +859,11 @@ static int __init lp_setup (char *str)
} else if (!strcmp(str, "auto")) {
parport_nr[0] = LP_PARPORT_AUTO;
} else if (!strcmp(str, "none")) {
- parport_nr[parport_ptr++] = LP_PARPORT_NONE;
+ if (parport_ptr < LP_NO)
+ parport_nr[parport_ptr++] = LP_PARPORT_NONE;
+ else
+ printk(KERN_INFO "lp: too many ports, %s ignored.\n",
+ str);
} else if (!strcmp(str, "reset")) {
reset = 1;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 006/103] USB: core: replace %p with %pK
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 005/103] char: lp: fix possible integer overflow in lp_setup() Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 007/103] ARM: tegra: paz00: Mark panel regulator as enabled on boot Greg Kroah-Hartman
` (91 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Vamsi Krishna Samavedam
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
commit 2f964780c03b73de269b08d12aff96a9618d13f3 upstream.
Format specifier %p can leak kernel addresses while not valuing the
kptr_restrict system settings. When kptr_restrict is set to (1), kernel
pointers printed using the %pK format specifier will be replaced with
Zeros. Debugging Note : &pK prints only Zeros as address. If you need
actual address information, write 0 to kptr_restrict.
echo 0 > /proc/sys/kernel/kptr_restrict
[Found by poking around in a random vendor kernel tree, it would be nice
if someone would actually send these types of patches upstream - gkh]
Signed-off-by: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/devio.c | 4 ++--
drivers/usb/core/hcd.c | 4 ++--
drivers/usb/core/urb.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -373,11 +373,11 @@ static void snoop_urb(struct usb_device
if (userurb) { /* Async */
if (when == SUBMIT)
- dev_info(&udev->dev, "userurb %p, ep%d %s-%s, "
+ dev_info(&udev->dev, "userurb %pK, ep%d %s-%s, "
"length %u\n",
userurb, ep, t, d, length);
else
- dev_info(&udev->dev, "userurb %p, ep%d %s-%s, "
+ dev_info(&udev->dev, "userurb %pK, ep%d %s-%s, "
"actual_length %u status %d\n",
userurb, ep, t, d, length,
timeout_or_status);
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1696,7 +1696,7 @@ int usb_hcd_unlink_urb (struct urb *urb,
if (retval == 0)
retval = -EINPROGRESS;
else if (retval != -EIDRM && retval != -EBUSY)
- dev_dbg(&udev->dev, "hcd_unlink_urb %p fail %d\n",
+ dev_dbg(&udev->dev, "hcd_unlink_urb %pK fail %d\n",
urb, retval);
usb_put_dev(udev);
}
@@ -1863,7 +1863,7 @@ rescan:
/* kick hcd */
unlink1(hcd, urb, -ESHUTDOWN);
dev_dbg (hcd->self.controller,
- "shutdown urb %p ep%d%s%s\n",
+ "shutdown urb %pK ep%d%s%s\n",
urb, usb_endpoint_num(&ep->desc),
is_in ? "in" : "out",
({ char *s;
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -335,7 +335,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (!urb || !urb->complete)
return -EINVAL;
if (urb->hcpriv) {
- WARN_ONCE(1, "URB %p submitted while active\n", urb);
+ WARN_ONCE(1, "URB %pK submitted while active\n", urb);
return -EBUSY;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 007/103] ARM: tegra: paz00: Mark panel regulator as enabled on boot
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 006/103] USB: core: replace %p with %pK Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 008/103] tpm_crb: check for bad response size Greg Kroah-Hartman
` (90 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marc Dietrich, Misha Komarovskiy,
Thierry Reding
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Dietrich <marvin24@gmx.de>
commit 0c18927f51f4d390abdcf385bff5f995407ee732 upstream.
Current U-Boot enables the display already. Marking the regulator as
enabled on boot fixes sporadic panel initialization failures.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Tested-by: Misha Komarovskiy <zombah@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/tegra20-paz00.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -565,6 +565,7 @@
regulator-name = "+3VS,vdd_pnl";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
gpio = <&gpio TEGRA_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
enable-active-high;
};
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 008/103] tpm_crb: check for bad response size
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 007/103] ARM: tegra: paz00: Mark panel regulator as enabled on boot Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 009/103] infiniband: call ipv6 route lookup via the stub interface Greg Kroah-Hartman
` (89 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jerry Snitselaar, Jarkko Sakkinen
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerry Snitselaar <jsnitsel@redhat.com>
commit 8569defde8057258835c51ce01a33de82e14b148 upstream.
Make sure size of response buffer is at least 6 bytes, or
we will underflow and pass large size_t to memcpy_fromio().
This was encountered while testing earlier version of
locality patchset.
Fixes: 30fc8d138e912 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/tpm/tpm_crb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -118,8 +118,7 @@ static int crb_recv(struct tpm_chip *chi
memcpy_fromio(buf, priv->rsp, 6);
expected = be32_to_cpup((__be32 *) &buf[2]);
-
- if (expected > count)
+ if (expected > count || expected < 6)
return -EIO;
memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 009/103] infiniband: call ipv6 route lookup via the stub interface
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 008/103] tpm_crb: check for bad response size Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 010/103] dm btree: fix for dm_btree_find_lowest_key() Greg Kroah-Hartman
` (88 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Paolo Abeni, Doug Ledford
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <pabeni@redhat.com>
commit eea40b8f624f25cbc02d55f2d93203f60cee9341 upstream.
The infiniband address handle can be triggered to resolve an ipv6
address in response to MAD packets, regardless of the ipv6
module being disabled via the kernel command line argument.
That will cause a call into the ipv6 routing code, which is not
initialized, and a conseguent oops.
This commit addresses the above issue replacing the direct lookup
call with an indirect one via the ipv6 stub, which is properly
initialized according to the ipv6 status (e.g. if ipv6 is
disabled, the routing lookup fails gracefully)
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/core/addr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -277,8 +277,8 @@ static int addr6_resolve(struct sockaddr
fl6.saddr = src_in->sin6_addr;
fl6.flowi6_oif = addr->bound_dev_if;
- dst = ip6_route_output(addr->net, NULL, &fl6);
- if ((ret = dst->error))
+ ret = ipv6_stub->ipv6_dst_lookup(addr->net, NULL, &dst, &fl6);
+ if (ret < 0)
goto put;
if (ipv6_addr_any(&fl6.saddr)) {
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 010/103] dm btree: fix for dm_btree_find_lowest_key()
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 009/103] infiniband: call ipv6 route lookup via the stub interface Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 011/103] dm raid: select the Kconfig option CONFIG_MD_RAID0 Greg Kroah-Hartman
` (87 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Erez Zadok, Vinothkumar Raja,
Nidhi Panpalia, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vinothkumar Raja <vinraja@cs.stonybrook.edu>
commit 7d1fedb6e96a960aa91e4ff70714c3fb09195a5a upstream.
dm_btree_find_lowest_key() is giving incorrect results. find_key()
traverses the btree correctly for finding the highest key, but there is
an error in the way it traverses the btree for retrieving the lowest
key. dm_btree_find_lowest_key() fetches the first key of the rightmost
block of the btree instead of fetching the first key from the leftmost
block.
Fix this by conditionally passing the correct parameter to value64()
based on the @find_highest flag.
Signed-off-by: Erez Zadok <ezk@fsl.cs.sunysb.edu>
Signed-off-by: Vinothkumar Raja <vinraja@cs.stonybrook.edu>
Signed-off-by: Nidhi Panpalia <npanpalia@cs.stonybrook.edu>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-btree.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/md/persistent-data/dm-btree.c
+++ b/drivers/md/persistent-data/dm-btree.c
@@ -887,8 +887,12 @@ static int find_key(struct ro_spine *s,
else
*result_key = le64_to_cpu(ro_node(s)->keys[0]);
- if (next_block || flags & INTERNAL_NODE)
- block = value64(ro_node(s), i);
+ if (next_block || flags & INTERNAL_NODE) {
+ if (find_highest)
+ block = value64(ro_node(s), i);
+ else
+ block = value64(ro_node(s), 0);
+ }
} while (flags & INTERNAL_NODE);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 011/103] dm raid: select the Kconfig option CONFIG_MD_RAID0
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 010/103] dm btree: fix for dm_btree_find_lowest_key() Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 012/103] dm bufio: avoid a possible ABBA deadlock Greg Kroah-Hartman
` (86 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 7b81ef8b14f80033e4a4168d199a0f5fd79b9426 upstream.
Since the commit 0cf4503174c1 ("dm raid: add support for the MD RAID0
personality"), the dm-raid subsystem can activate a RAID-0 array.
Therefore, add MD_RAID0 to the dependencies of DM_RAID, so that MD_RAID0
will be selected when DM_RAID is selected.
Fixes: 0cf4503174c1 ("dm raid: add support for the MD RAID0 personality")
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -357,6 +357,7 @@ config DM_LOG_USERSPACE
config DM_RAID
tristate "RAID 1/4/5/6/10 target"
depends on BLK_DEV_DM
+ select MD_RAID0
select MD_RAID1
select MD_RAID10
select MD_RAID456
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 012/103] dm bufio: avoid a possible ABBA deadlock
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 011/103] dm raid: select the Kconfig option CONFIG_MD_RAID0 Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 013/103] dm bufio: check new buffer allocation watermark every 30 seconds Greg Kroah-Hartman
` (85 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 1b0fb5a5b2dc0dddcfa575060441a7176ba7ac37 upstream.
__get_memory_limit() tests if dm_bufio_cache_size changed and calls
__cache_size_refresh() if it did. It takes dm_bufio_clients_lock while
it already holds the client lock. However, lock ordering is violated
because in cleanup_old_buffers() dm_bufio_clients_lock is taken before
the client lock.
This results in a possible deadlock and lockdep engine warning.
Fix this deadlock by changing mutex_lock() to mutex_trylock(). If the
lock can't be taken, it will be re-checked next time when a new buffer
is allocated.
Also add "unlikely" to the if condition, so that the optimizer assumes
that the condition is false.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-bufio.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -914,10 +914,11 @@ static void __get_memory_limit(struct dm
{
unsigned long buffers;
- if (ACCESS_ONCE(dm_bufio_cache_size) != dm_bufio_cache_size_latch) {
- mutex_lock(&dm_bufio_clients_lock);
- __cache_size_refresh();
- mutex_unlock(&dm_bufio_clients_lock);
+ if (unlikely(ACCESS_ONCE(dm_bufio_cache_size) != dm_bufio_cache_size_latch)) {
+ if (mutex_trylock(&dm_bufio_clients_lock)) {
+ __cache_size_refresh();
+ mutex_unlock(&dm_bufio_clients_lock);
+ }
}
buffers = dm_bufio_cache_size_per_client >>
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 013/103] dm bufio: check new buffer allocation watermark every 30 seconds
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 012/103] dm bufio: avoid a possible ABBA deadlock Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 014/103] dm cache metadata: fail operations if fail_io mode has been established Greg Kroah-Hartman
` (84 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 390020ad2af9ca04844c4f3b1f299ad8746d84c8 upstream.
dm-bufio checks a watermark when it allocates a new buffer in
__bufio_new(). However, it doesn't check the watermark when the user
changes /sys/module/dm_bufio/parameters/max_cache_size_bytes.
This may result in a problem - if the watermark is high enough so that
all possible buffers are allocated and if the user lowers the value of
"max_cache_size_bytes", the watermark will never be checked against the
new value because no new buffer would be allocated.
To fix this, change __evict_old_buffers() so that it checks the
watermark. __evict_old_buffers() is called every 30 seconds, so if the
user reduces "max_cache_size_bytes", dm-bufio will react to this change
within 30 seconds and decrease memory consumption.
Depends-on: 1b0fb5a5b2 ("dm bufio: avoid a possible ABBA deadlock")
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-bufio.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -1755,9 +1755,17 @@ static void __evict_old_buffers(struct d
struct dm_buffer *b, *tmp;
unsigned retain_target = get_retain_buffers(c);
unsigned count;
+ LIST_HEAD(write_list);
dm_bufio_lock(c);
+ __check_watermark(c, &write_list);
+ if (unlikely(!list_empty(&write_list))) {
+ dm_bufio_unlock(c);
+ __flush_write_list(&write_list);
+ dm_bufio_lock(c);
+ }
+
count = c->n_buffers[LIST_CLEAN] + c->n_buffers[LIST_DIRTY];
list_for_each_entry_safe_reverse(b, tmp, &c->lru[LIST_CLEAN], lru_list) {
if (count <= retain_target)
@@ -1782,6 +1790,8 @@ static void cleanup_old_buffers(void)
mutex_lock(&dm_bufio_clients_lock);
+ __cache_size_refresh();
+
list_for_each_entry(c, &dm_bufio_all_clients, client_list)
__evict_old_buffers(c, max_age_hz);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 014/103] dm cache metadata: fail operations if fail_io mode has been established
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 013/103] dm bufio: check new buffer allocation watermark every 30 seconds Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 015/103] dm bufio: make the parameter "retain_bytes" unsigned long Greg Kroah-Hartman
` (83 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Snitzer <snitzer@redhat.com>
commit 10add84e276432d9dd8044679a1028dd4084117e upstream.
Otherwise it is possible to trigger crashes due to the metadata being
inaccessible yet these methods don't safely account for that possibility
without these checks.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-cache-metadata.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/md/dm-cache-metadata.c
+++ b/drivers/md/dm-cache-metadata.c
@@ -1326,17 +1326,19 @@ void dm_cache_metadata_set_stats(struct
int dm_cache_commit(struct dm_cache_metadata *cmd, bool clean_shutdown)
{
- int r;
+ int r = -EINVAL;
flags_mutator mutator = (clean_shutdown ? set_clean_shutdown :
clear_clean_shutdown);
WRITE_LOCK(cmd);
+ if (cmd->fail_io)
+ goto out;
+
r = __commit_transaction(cmd, mutator);
if (r)
goto out;
r = __begin_transaction(cmd);
-
out:
WRITE_UNLOCK(cmd);
return r;
@@ -1348,7 +1350,8 @@ int dm_cache_get_free_metadata_block_cou
int r = -EINVAL;
READ_LOCK(cmd);
- r = dm_sm_get_nr_free(cmd->metadata_sm, result);
+ if (!cmd->fail_io)
+ r = dm_sm_get_nr_free(cmd->metadata_sm, result);
READ_UNLOCK(cmd);
return r;
@@ -1360,7 +1363,8 @@ int dm_cache_get_metadata_dev_size(struc
int r = -EINVAL;
READ_LOCK(cmd);
- r = dm_sm_get_nr_blocks(cmd->metadata_sm, result);
+ if (!cmd->fail_io)
+ r = dm_sm_get_nr_blocks(cmd->metadata_sm, result);
READ_UNLOCK(cmd);
return r;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 015/103] dm bufio: make the parameter "retain_bytes" unsigned long
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 014/103] dm cache metadata: fail operations if fail_io mode has been established Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 016/103] dm thin metadata: call precommit before saving the roots Greg Kroah-Hartman
` (82 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mikulas Patocka, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit 13840d38016203f0095cd547b90352812d24b787 upstream.
Change the type of the parameter "retain_bytes" from unsigned to
unsigned long, so that on 64-bit machines the user can set more than
4GiB of data to be retained.
Also, change the type of the variable "count" in the function
"__evict_old_buffers" to unsigned long. The assignment
"count = c->n_buffers[LIST_CLEAN] + c->n_buffers[LIST_DIRTY];"
could result in unsigned long to unsigned overflow and that could result
in buffers not being freed when they should.
While at it, avoid division in get_retain_buffers(). Division is slow,
we can change it to shift because we have precalculated the log2 of
block size.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-bufio.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -222,7 +222,7 @@ static DEFINE_SPINLOCK(param_spinlock);
* Buffers are freed after this timeout
*/
static unsigned dm_bufio_max_age = DM_BUFIO_DEFAULT_AGE_SECS;
-static unsigned dm_bufio_retain_bytes = DM_BUFIO_DEFAULT_RETAIN_BYTES;
+static unsigned long dm_bufio_retain_bytes = DM_BUFIO_DEFAULT_RETAIN_BYTES;
static unsigned long dm_bufio_peak_allocated;
static unsigned long dm_bufio_allocated_kmem_cache;
@@ -1514,10 +1514,10 @@ static bool __try_evict_buffer(struct dm
return true;
}
-static unsigned get_retain_buffers(struct dm_bufio_client *c)
+static unsigned long get_retain_buffers(struct dm_bufio_client *c)
{
- unsigned retain_bytes = ACCESS_ONCE(dm_bufio_retain_bytes);
- return retain_bytes / c->block_size;
+ unsigned long retain_bytes = ACCESS_ONCE(dm_bufio_retain_bytes);
+ return retain_bytes >> (c->sectors_per_block_bits + SECTOR_SHIFT);
}
static unsigned long __scan(struct dm_bufio_client *c, unsigned long nr_to_scan,
@@ -1527,7 +1527,7 @@ static unsigned long __scan(struct dm_bu
struct dm_buffer *b, *tmp;
unsigned long freed = 0;
unsigned long count = nr_to_scan;
- unsigned retain_target = get_retain_buffers(c);
+ unsigned long retain_target = get_retain_buffers(c);
for (l = 0; l < LIST_SIZE; l++) {
list_for_each_entry_safe_reverse(b, tmp, &c->lru[l], lru_list) {
@@ -1753,8 +1753,8 @@ static bool older_than(struct dm_buffer
static void __evict_old_buffers(struct dm_bufio_client *c, unsigned long age_hz)
{
struct dm_buffer *b, *tmp;
- unsigned retain_target = get_retain_buffers(c);
- unsigned count;
+ unsigned long retain_target = get_retain_buffers(c);
+ unsigned long count;
LIST_HEAD(write_list);
dm_bufio_lock(c);
@@ -1915,7 +1915,7 @@ MODULE_PARM_DESC(max_cache_size_bytes, "
module_param_named(max_age_seconds, dm_bufio_max_age, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(max_age_seconds, "Max age of a buffer in seconds");
-module_param_named(retain_bytes, dm_bufio_retain_bytes, uint, S_IRUGO | S_IWUSR);
+module_param_named(retain_bytes, dm_bufio_retain_bytes, ulong, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(retain_bytes, "Try to keep at least this many bytes cached in memory");
module_param_named(peak_allocated_bytes, dm_bufio_peak_allocated, ulong, S_IRUGO | S_IWUSR);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 016/103] dm thin metadata: call precommit before saving the roots
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 015/103] dm bufio: make the parameter "retain_bytes" unsigned long Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 017/103] dm space map disk: fix some book keeping in the disk space map Greg Kroah-Hartman
` (81 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit 91bcdb92d39711d1adb40c26b653b7978d93eb98 upstream.
These calls were the wrong way round in __write_initial_superblock.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/dm-thin-metadata.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/dm-thin-metadata.c
+++ b/drivers/md/dm-thin-metadata.c
@@ -485,11 +485,11 @@ static int __write_initial_superblock(st
if (r < 0)
return r;
- r = save_sm_roots(pmd);
+ r = dm_tm_pre_commit(pmd->tm);
if (r < 0)
return r;
- r = dm_tm_pre_commit(pmd->tm);
+ r = save_sm_roots(pmd);
if (r < 0)
return r;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 017/103] dm space map disk: fix some book keeping in the disk space map
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 016/103] dm thin metadata: call precommit before saving the roots Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 018/103] md: update slab_cache before releasing new stripes when stripes resizing Greg Kroah-Hartman
` (80 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joe Thornber, Mike Snitzer
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Thornber <ejt@redhat.com>
commit 0377a07c7a035e0d033cd8b29f0cb15244c0916a upstream.
When decrementing the reference count for a block, the free count wasn't
being updated if the reference count went to zero.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/persistent-data/dm-space-map-disk.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/md/persistent-data/dm-space-map-disk.c
+++ b/drivers/md/persistent-data/dm-space-map-disk.c
@@ -142,10 +142,23 @@ static int sm_disk_inc_block(struct dm_s
static int sm_disk_dec_block(struct dm_space_map *sm, dm_block_t b)
{
+ int r;
+ uint32_t old_count;
enum allocation_event ev;
struct sm_disk *smd = container_of(sm, struct sm_disk, sm);
- return sm_ll_dec(&smd->ll, b, &ev);
+ r = sm_ll_dec(&smd->ll, b, &ev);
+ if (!r && (ev == SM_FREE)) {
+ /*
+ * It's only free if it's also free in the last
+ * transaction.
+ */
+ r = sm_ll_lookup(&smd->old_ll, b, &old_count);
+ if (!r && !old_count)
+ smd->nr_allocated_this_transaction--;
+ }
+
+ return r;
}
static int sm_disk_new_block(struct dm_space_map *sm, dm_block_t *b)
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 018/103] md: update slab_cache before releasing new stripes when stripes resizing
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 017/103] dm space map disk: fix some book keeping in the disk space map Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-30 13:16 ` Ben Hutchings
2017-05-23 20:08 ` [PATCH 4.4 019/103] rtlwifi: rtl8821ae: setup 8812ae RFE according to device type Greg Kroah-Hartman
` (79 subsequent siblings)
97 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dennis Yang, NeilBrown, Shaohua Li
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dennis Yang <dennisyang@qnap.com>
commit 583da48e388f472e8818d9bb60ef6a1d40ee9f9d upstream.
When growing raid5 device on machine with small memory, there is chance that
mdadm will be killed and the following bug report can be observed. The same
bug could also be reproduced in linux-4.10.6.
[57600.075774] BUG: unable to handle kernel NULL pointer dereference at (null)
[57600.083796] IP: [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
[57600.110378] PGD 421cf067 PUD 4442d067 PMD 0
[57600.114678] Oops: 0002 [#1] SMP
[57600.180799] CPU: 1 PID: 25990 Comm: mdadm Tainted: P O 4.2.8 #1
[57600.187849] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS QV05AR66 03/06/2013
[57600.197490] task: ffff880044e47240 ti: ffff880043070000 task.ti: ffff880043070000
[57600.204963] RIP: 0010:[<ffffffff81a6aa87>] [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
[57600.213057] RSP: 0018:ffff880043073810 EFLAGS: 00010046
[57600.218359] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffff88011e296dd0
[57600.225486] RDX: 0000000000000001 RSI: ffffe8ffffcb46c0 RDI: 0000000000000000
[57600.232613] RBP: ffff880043073878 R08: ffff88011e5f8170 R09: 0000000000000282
[57600.239739] R10: 0000000000000005 R11: 28f5c28f5c28f5c3 R12: ffff880043073838
[57600.246872] R13: ffffe8ffffcb46c0 R14: 0000000000000000 R15: ffff8800b9706a00
[57600.253999] FS: 00007f576106c700(0000) GS:ffff88011e280000(0000) knlGS:0000000000000000
[57600.262078] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[57600.267817] CR2: 0000000000000000 CR3: 00000000428fe000 CR4: 00000000001406e0
[57600.274942] Stack:
[57600.276949] ffffffff8114ee35 ffff880043073868 0000000000000282 000000000000eb3f
[57600.284383] ffffffff81119043 ffff880043073838 ffff880043073838 ffff88003e197b98
[57600.291820] ffffe8ffffcb46c0 ffff88003e197360 0000000000000286 ffff880043073968
[57600.299254] Call Trace:
[57600.301698] [<ffffffff8114ee35>] ? cache_flusharray+0x35/0xe0
[57600.307523] [<ffffffff81119043>] ? __page_cache_release+0x23/0x110
[57600.313779] [<ffffffff8114eb53>] kmem_cache_free+0x63/0xc0
[57600.319344] [<ffffffff81579942>] drop_one_stripe+0x62/0x90
[57600.324915] [<ffffffff81579b5b>] raid5_cache_scan+0x8b/0xb0
[57600.330563] [<ffffffff8111b98a>] shrink_slab.part.36+0x19a/0x250
[57600.336650] [<ffffffff8111e38c>] shrink_zone+0x23c/0x250
[57600.342039] [<ffffffff8111e4f3>] do_try_to_free_pages+0x153/0x420
[57600.348210] [<ffffffff8111e851>] try_to_free_pages+0x91/0xa0
[57600.353959] [<ffffffff811145b1>] __alloc_pages_nodemask+0x4d1/0x8b0
[57600.360303] [<ffffffff8157a30b>] check_reshape+0x62b/0x770
[57600.365866] [<ffffffff8157a4a5>] raid5_check_reshape+0x55/0xa0
[57600.371778] [<ffffffff81583df7>] update_raid_disks+0xc7/0x110
[57600.377604] [<ffffffff81592b73>] md_ioctl+0xd83/0x1b10
[57600.382827] [<ffffffff81385380>] blkdev_ioctl+0x170/0x690
[57600.388307] [<ffffffff81195238>] block_ioctl+0x38/0x40
[57600.393525] [<ffffffff811731c5>] do_vfs_ioctl+0x2b5/0x480
[57600.399010] [<ffffffff8115e07b>] ? vfs_write+0x14b/0x1f0
[57600.404400] [<ffffffff811733cc>] SyS_ioctl+0x3c/0x70
[57600.409447] [<ffffffff81a6ad97>] entry_SYSCALL_64_fastpath+0x12/0x6a
[57600.415875] Code: 00 00 00 00 55 48 89 e5 8b 07 85 c0 74 04 31 c0 5d c3 ba 01 00 00 00 f0 0f b1 17 85 c0 75 ef b0 01 5d c3 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 85 d1 63 ff 5d
[57600.435460] RIP [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
[57600.441208] RSP <ffff880043073810>
[57600.444690] CR2: 0000000000000000
[57600.448000] ---[ end trace cbc6b5cc4bf9831d ]---
The problem is that resize_stripes() releases new stripe_heads before assigning new
slab cache to conf->slab_cache. If the shrinker function raid5_cache_scan() gets called
after resize_stripes() starting releasing new stripes but right before new slab cache
being assigned, it is possible that these new stripe_heads will be freed with the old
slab_cache which was already been destoryed and that triggers this bug.
Signed-off-by: Dennis Yang <dennisyang@qnap.com>
Fixes: edbe83ab4c27 ("md/raid5: allow the stripe_cache to grow and shrink.")
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid5.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2232,6 +2232,10 @@ static int resize_stripes(struct r5conf
err = -ENOMEM;
mutex_unlock(&conf->cache_size_mutex);
+
+ conf->slab_cache = sc;
+ conf->active_name = 1-conf->active_name;
+
/* Step 4, return new stripes to service */
while(!list_empty(&newstripes)) {
nsh = list_entry(newstripes.next, struct stripe_head, lru);
@@ -2249,8 +2253,6 @@ static int resize_stripes(struct r5conf
}
/* critical section pass, GFP_NOIO no longer needed */
- conf->slab_cache = sc;
- conf->active_name = 1-conf->active_name;
if (!err)
conf->pool_size = newsize;
return err;
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 018/103] md: update slab_cache before releasing new stripes when stripes resizing
2017-05-23 20:08 ` [PATCH 4.4 018/103] md: update slab_cache before releasing new stripes when stripes resizing Greg Kroah-Hartman
@ 2017-05-30 13:16 ` Ben Hutchings
2017-05-30 17:27 ` Shaohua Li
0 siblings, 1 reply; 121+ messages in thread
From: Ben Hutchings @ 2017-05-30 13:16 UTC (permalink / raw)
To: Dennis Yang, NeilBrown, Shaohua Li
Cc: linux-kernel, stable, Greg Kroah-Hartman
On Tue, 2017-05-23 at 22:08 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Dennis Yang <dennisyang@qnap.com>
>
> commit 583da48e388f472e8818d9bb60ef6a1d40ee9f9d upstream.
>
> When growing raid5 device on machine with small memory, there is chance that
> mdadm will be killed and the following bug report can be observed. The same
> bug could also be reproduced in linux-4.10.6.
[...]
> The problem is that resize_stripes() releases new stripe_heads before assigning new
> slab cache to conf->slab_cache. If the shrinker function raid5_cache_scan() gets called
> after resize_stripes() starting releasing new stripes but right before new slab cache
> being assigned, it is possible that these new stripe_heads will be freed with the old
> slab_cache which was already been destoryed and that triggers this bug.
[...]
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -2232,6 +2232,10 @@ static int resize_stripes(struct r5conf
> err = -ENOMEM;
>
> mutex_unlock(&conf->cache_size_mutex);
> +
> + conf->slab_cache = sc;
> + conf->active_name = 1-conf->active_name;
> +
> /* Step 4, return new stripes to service */
> while(!list_empty(&newstripes)) {
> nsh = list_entry(newstripes.next, struct stripe_head, lru);
[...]
The assignments are still being done after conf->cache_size_mutex is
unlocked, so there still seems to be a race with raid5_cache_scan().
Shouldn't they be moved above the mutex_unlock()?
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 018/103] md: update slab_cache before releasing new stripes when stripes resizing
2017-05-30 13:16 ` Ben Hutchings
@ 2017-05-30 17:27 ` Shaohua Li
0 siblings, 0 replies; 121+ messages in thread
From: Shaohua Li @ 2017-05-30 17:27 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dennis Yang, NeilBrown, Shaohua Li, linux-kernel, stable,
Greg Kroah-Hartman
On Tue, May 30, 2017 at 02:16:53PM +0100, Ben Hutchings wrote:
> On Tue, 2017-05-23 at 22:08 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Dennis Yang <dennisyang@qnap.com>
> >
> > commit 583da48e388f472e8818d9bb60ef6a1d40ee9f9d upstream.
> >
> > When growing raid5 device on machine with small memory, there is chance that
> > mdadm will be killed and the following bug report can be observed. The same
> > bug could also be reproduced in linux-4.10.6.
> [...]
> > The problem is that resize_stripes() releases new stripe_heads before assigning new
> > slab cache to conf->slab_cache. If the shrinker function raid5_cache_scan() gets called
> > after resize_stripes() starting releasing new stripes but right before new slab cache
> > being assigned, it is possible that these new stripe_heads will be freed with the old
> > slab_cache which was already been destoryed and that triggers this bug.
> [...]
> > --- a/drivers/md/raid5.c
> > +++ b/drivers/md/raid5.c
> > @@ -2232,6 +2232,10 @@ static int resize_stripes(struct r5conf
> > err = -ENOMEM;
> >
> > mutex_unlock(&conf->cache_size_mutex);
> > +
> > + conf->slab_cache = sc;
> > + conf->active_name = 1-conf->active_name;
> > +
> > /* Step 4, return new stripes to service */
> > while(!list_empty(&newstripes)) {
> > nsh = list_entry(newstripes.next, struct stripe_head, lru);
> [...]
>
> The assignments are still being done after conf->cache_size_mutex is
> unlocked, so there still seems to be a race with raid5_cache_scan().
> Shouldn't they be moved above the mutex_unlock()?
Unnecessary. The raid5_cache_scan can't free any stripe to slab_cache before
the stripe is called with raid5_release_stripe.
Thanks,
SHaohua
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 019/103] rtlwifi: rtl8821ae: setup 8812ae RFE according to device type
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 018/103] md: update slab_cache before releasing new stripes when stripes resizing Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 020/103] mwifiex: pcie: fix cmd_buf use-after-free in remove/reset Greg Kroah-Hartman
` (78 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maxim Samoylov, Larry Finger,
Yan-Hsuan Chuang, Pkshih, Birming Chiu, Shaofu, Steven Ting,
Kalle Valo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <Larry.Finger@lwfinger.net>
commit 46cfa2148e7371c537efff1a1c693e58f523089d upstream.
Current channel switch implementation sets 8812ae RFE reg value assuming
that device always has type 2.
Extend possible RFE types set and write corresponding reg values.
Source for new code is
http://dlcdnet.asus.com/pub/ASUS/wireless/PCE-AC51/DR_PCE_AC51_20232801152016.zip
Signed-off-by: Maxim Samoylov <max7255@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Pkshih <pkshih@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 122 ++++++++++++++++---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/reg.h | 1
2 files changed, 107 insertions(+), 16 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -359,6 +359,107 @@ bool rtl8821ae_phy_rf_config(struct ieee
return rtl8821ae_phy_rf6052_config(hw);
}
+static void _rtl8812ae_phy_set_rfe_reg_24g(struct ieee80211_hw *hw)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ u8 tmp;
+
+ switch (rtlhal->rfe_type) {
+ case 3:
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD, 0x54337770);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x54337770);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x010);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x010);
+ rtl_set_bbreg(hw, 0x900, 0x00000303, 0x1);
+ break;
+ case 4:
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD, 0x77777777);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x77777777);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x001);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x001);
+ break;
+ case 5:
+ rtl_write_byte(rtlpriv, RA_RFE_PINMUX + 2, 0x77);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x77777777);
+ tmp = rtl_read_byte(rtlpriv, RA_RFE_INV + 3);
+ rtl_write_byte(rtlpriv, RA_RFE_INV + 3, tmp & ~0x1);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x000);
+ break;
+ case 1:
+ if (rtlpriv->btcoexist.bt_coexistence) {
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, 0xffffff, 0x777777);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD,
+ 0x77777777);
+ rtl_set_bbreg(hw, RA_RFE_INV, 0x33f00000, 0x000);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x000);
+ break;
+ }
+ case 0:
+ case 2:
+ default:
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD, 0x77777777);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x77777777);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x000);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x000);
+ break;
+ }
+}
+
+static void _rtl8812ae_phy_set_rfe_reg_5g(struct ieee80211_hw *hw)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+ u8 tmp;
+
+ switch (rtlhal->rfe_type) {
+ case 0:
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD, 0x77337717);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x77337717);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x010);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x010);
+ break;
+ case 1:
+ if (rtlpriv->btcoexist.bt_coexistence) {
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, 0xffffff, 0x337717);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD,
+ 0x77337717);
+ rtl_set_bbreg(hw, RA_RFE_INV, 0x33f00000, 0x000);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x000);
+ } else {
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD,
+ 0x77337717);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD,
+ 0x77337717);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x000);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x000);
+ }
+ break;
+ case 3:
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD, 0x54337717);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x54337717);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x010);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x010);
+ rtl_set_bbreg(hw, 0x900, 0x00000303, 0x1);
+ break;
+ case 5:
+ rtl_write_byte(rtlpriv, RA_RFE_PINMUX + 2, 0x33);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x77337777);
+ tmp = rtl_read_byte(rtlpriv, RA_RFE_INV + 3);
+ rtl_write_byte(rtlpriv, RA_RFE_INV + 3, tmp | 0x1);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x010);
+ break;
+ case 2:
+ case 4:
+ default:
+ rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD, 0x77337777);
+ rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD, 0x77337777);
+ rtl_set_bbreg(hw, RA_RFE_INV, BMASKRFEINV, 0x010);
+ rtl_set_bbreg(hw, RB_RFE_INV, BMASKRFEINV, 0x010);
+ break;
+ }
+}
+
u32 phy_get_tx_swing_8812A(struct ieee80211_hw *hw, u8 band,
u8 rf_path)
{
@@ -553,14 +654,9 @@ void rtl8821ae_phy_switch_wirelessband(s
/* 0x82C[1:0] = 2b'00 */
rtl_set_bbreg(hw, 0x82c, 0x3, 0);
}
- if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {
- rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD,
- 0x77777777);
- rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD,
- 0x77777777);
- rtl_set_bbreg(hw, RA_RFE_INV, 0x3ff00000, 0x000);
- rtl_set_bbreg(hw, RB_RFE_INV, 0x3ff00000, 0x000);
- }
+
+ if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE)
+ _rtl8812ae_phy_set_rfe_reg_24g(hw);
rtl_set_bbreg(hw, RTXPATH, 0xf0, 0x1);
rtl_set_bbreg(hw, RCCK_RX, 0x0f000000, 0x1);
@@ -615,14 +711,8 @@ void rtl8821ae_phy_switch_wirelessband(s
/* 0x82C[1:0] = 2'b00 */
rtl_set_bbreg(hw, 0x82c, 0x3, 1);
- if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {
- rtl_set_bbreg(hw, RA_RFE_PINMUX, BMASKDWORD,
- 0x77337777);
- rtl_set_bbreg(hw, RB_RFE_PINMUX, BMASKDWORD,
- 0x77337777);
- rtl_set_bbreg(hw, RA_RFE_INV, 0x3ff00000, 0x010);
- rtl_set_bbreg(hw, RB_RFE_INV, 0x3ff00000, 0x010);
- }
+ if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE)
+ _rtl8812ae_phy_set_rfe_reg_5g(hw);
rtl_set_bbreg(hw, RTXPATH, 0xf0, 0);
rtl_set_bbreg(hw, RCCK_RX, 0x0f000000, 0xf);
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/reg.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/reg.h
@@ -2424,6 +2424,7 @@
#define BMASKH4BITS 0xf0000000
#define BMASKOFDM_D 0xffc00000
#define BMASKCCK 0x3f3f3f3f
+#define BMASKRFEINV 0x3ff00000
#define BRFREGOFFSETMASK 0xfffff
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 020/103] mwifiex: pcie: fix cmd_buf use-after-free in remove/reset
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 019/103] rtlwifi: rtl8821ae: setup 8812ae RFE according to device type Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 024/103] regulator: tps65023: Fix inverted core enable logic Greg Kroah-Hartman
` (77 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Brian Norris, Kalle Valo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Norris <briannorris@chromium.org>
commit 3c8cb9ad032d737b874e402c59eb51e3c991a144 upstream.
Command buffers (skb's) are allocated by the main driver, and freed upon
the last use. That last use is often in mwifiex_free_cmd_buffer(). In
the meantime, if the command buffer gets used by the PCI driver, we map
it as DMA-able, and store the mapping information in the 'cb' memory.
However, if a command was in-flight when resetting the device (and
therefore was still mapped), we don't get a chance to unmap this memory
until after the core has cleaned up its command handling.
Let's keep a refcount within the PCI driver, so we ensure the memory
only gets freed after we've finished unmapping it.
Noticed by KASAN when forcing a reset via:
echo 1 > /sys/bus/pci/.../reset
The same code path can presumably be exercised in remove() and
shutdown().
[ 205.390377] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
[ 205.400393] ==================================================================
[ 205.407719] BUG: KASAN: use-after-free in mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie] at addr ffffffc0ad471b28
[ 205.419040] Read of size 16 by task bash/1913
[ 205.423421] =============================================================================
[ 205.431625] BUG skbuff_head_cache (Tainted: G B ): kasan: bad access detected
[ 205.439815] -----------------------------------------------------------------------------
[ 205.439815]
[ 205.449534] INFO: Allocated in __build_skb+0x48/0x114 age=1311 cpu=4 pid=1913
[ 205.456709] alloc_debug_processing+0x124/0x178
[ 205.461282] ___slab_alloc.constprop.58+0x528/0x608
[ 205.466196] __slab_alloc.isra.54.constprop.57+0x44/0x54
[ 205.471542] kmem_cache_alloc+0xcc/0x278
[ 205.475497] __build_skb+0x48/0x114
[ 205.479019] __netdev_alloc_skb+0xe0/0x170
[ 205.483244] mwifiex_alloc_cmd_buffer+0x68/0xdc [mwifiex]
[ 205.488759] mwifiex_init_fw+0x40/0x6cc [mwifiex]
[ 205.493584] _mwifiex_fw_dpc+0x158/0x520 [mwifiex]
[ 205.498491] mwifiex_reinit_sw+0x2c4/0x398 [mwifiex]
[ 205.503510] mwifiex_pcie_reset_notify+0x114/0x15c [mwifiex_pcie]
[ 205.509643] pci_reset_notify+0x5c/0x6c
[ 205.513519] pci_reset_function+0x6c/0x7c
[ 205.517567] reset_store+0x68/0x98
[ 205.521003] dev_attr_store+0x54/0x60
[ 205.524705] sysfs_kf_write+0x9c/0xb0
[ 205.528413] INFO: Freed in __kfree_skb+0xb0/0xbc age=131 cpu=4 pid=1913
[ 205.535064] free_debug_processing+0x264/0x370
[ 205.539550] __slab_free+0x84/0x40c
[ 205.543075] kmem_cache_free+0x1c8/0x2a0
[ 205.547030] __kfree_skb+0xb0/0xbc
[ 205.550465] consume_skb+0x164/0x178
[ 205.554079] __dev_kfree_skb_any+0x58/0x64
[ 205.558304] mwifiex_free_cmd_buffer+0xa0/0x158 [mwifiex]
[ 205.563817] mwifiex_shutdown_drv+0x578/0x5c4 [mwifiex]
[ 205.569164] mwifiex_shutdown_sw+0x178/0x310 [mwifiex]
[ 205.574353] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[ 205.580398] pci_reset_notify+0x5c/0x6c
[ 205.584274] pci_dev_save_and_disable+0x24/0x6c
[ 205.588837] pci_reset_function+0x30/0x7c
[ 205.592885] reset_store+0x68/0x98
[ 205.596324] dev_attr_store+0x54/0x60
[ 205.600017] sysfs_kf_write+0x9c/0xb0
...
[ 205.800488] Call trace:
[ 205.802980] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190
[ 205.808415] [<ffffffc00020a96c>] show_stack+0x20/0x28
[ 205.813506] [<ffffffc0005d020c>] dump_stack+0xa4/0xcc
[ 205.818598] [<ffffffc0003be44c>] print_trailer+0x158/0x168
[ 205.824120] [<ffffffc0003be5f0>] object_err+0x4c/0x5c
[ 205.829210] [<ffffffc0003c45bc>] kasan_report+0x334/0x500
[ 205.834641] [<ffffffc0003c3994>] check_memory_region+0x20/0x14c
[ 205.840593] [<ffffffc0003c3b14>] __asan_loadN+0x14/0x1c
[ 205.845879] [<ffffffbffc46171c>] mwifiex_unmap_pci_memory.isra.14+0x4c/0x100 [mwifiex_pcie]
[ 205.854282] [<ffffffbffc461864>] mwifiex_pcie_delete_cmdrsp_buf+0x94/0xa8 [mwifiex_pcie]
[ 205.862421] [<ffffffbffc462028>] mwifiex_pcie_free_buffers+0x11c/0x158 [mwifiex_pcie]
[ 205.870302] [<ffffffbffc4620d4>] mwifiex_pcie_down_dev+0x70/0x80 [mwifiex_pcie]
[ 205.877736] [<ffffffbffc1397a8>] mwifiex_shutdown_sw+0x190/0x310 [mwifiex]
[ 205.884658] [<ffffffbffc4606b4>] mwifiex_pcie_reset_notify+0xd4/0x15c [mwifiex_pcie]
[ 205.892446] [<ffffffc000635f54>] pci_reset_notify+0x5c/0x6c
[ 205.898048] [<ffffffc00063a044>] pci_dev_save_and_disable+0x24/0x6c
[ 205.904350] [<ffffffc00063cf0c>] pci_reset_function+0x30/0x7c
[ 205.910134] [<ffffffc000641118>] reset_store+0x68/0x98
[ 205.915312] [<ffffffc000771588>] dev_attr_store+0x54/0x60
[ 205.920750] [<ffffffc00046f53c>] sysfs_kf_write+0x9c/0xb0
[ 205.926182] [<ffffffc00046dfb0>] kernfs_fop_write+0x184/0x1f8
[ 205.931963] [<ffffffc0003d64f4>] __vfs_write+0x6c/0x17c
[ 205.937221] [<ffffffc0003d7164>] vfs_write+0xf0/0x1c4
[ 205.942310] [<ffffffc0003d7da0>] SyS_write+0x78/0xd8
[ 205.947312] [<ffffffc000204634>] el0_svc_naked+0x24/0x28
...
[ 205.998268] ==================================================================
This bug has been around in different forms for a while. It was sort of
noticed in commit 955ab095c51a ("mwifiex: Do not kfree cmd buf while
unregistering PCIe"), but it just fixed the double-free, without
acknowledging the potential for use-after-free.
Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/mwifiex/pcie.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -947,6 +947,7 @@ static int mwifiex_pcie_delete_cmdrsp_bu
if (card && card->cmd_buf) {
mwifiex_unmap_pci_memory(adapter, card->cmd_buf,
PCI_DMA_TODEVICE);
+ dev_kfree_skb_any(card->cmd_buf);
}
return 0;
}
@@ -1513,6 +1514,11 @@ mwifiex_pcie_send_cmd(struct mwifiex_ada
return -1;
card->cmd_buf = skb;
+ /*
+ * Need to keep a reference, since core driver might free up this
+ * buffer before we've unmapped it.
+ */
+ skb_get(skb);
/* To send a command, the driver will:
1. Write the 64bit physical address of the data buffer to
@@ -1610,6 +1616,7 @@ static int mwifiex_pcie_process_cmd_comp
if (card->cmd_buf) {
mwifiex_unmap_pci_memory(adapter, card->cmd_buf,
PCI_DMA_TODEVICE);
+ dev_kfree_skb_any(card->cmd_buf);
card->cmd_buf = NULL;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 024/103] regulator: tps65023: Fix inverted core enable logic.
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 020/103] mwifiex: pcie: fix cmd_buf use-after-free in remove/reset Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 025/103] s390/kdump: Add final note Greg Kroah-Hartman
` (76 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Richard Cochran, Mark Brown
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Cochran <rcochran@linutronix.de>
commit c90722b54a4f5e21ac59301ed9a6dbaa439bdb16 upstream.
Commit 43530b69d758328d3ffe6ab98fd640463e8e3667 ("regulator: Use
regmap_read/write(), regmap_update_bits functions directly") intended
to replace working inline helper functions with standard regmap
calls. However, it also inverted the set/clear logic of the "CORE ADJ
Allowed" bit. That patch was clearly never tested, since without that
bit cleared, the core VDCDC1 voltage output does not react to I2C
configuration changes.
This patch fixes the issue by clearing the bit as in the original,
correct implementation. Note for stable back porting that, due to
subsequent driver churn, this patch will not apply on every kernel
version.
Fixes: 43530b69d758 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly")
Signed-off-by: Richard Cochran <rcochran@linutronix.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/regulator/tps65023-regulator.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/regulator/tps65023-regulator.c
+++ b/drivers/regulator/tps65023-regulator.c
@@ -311,8 +311,7 @@ static int tps_65023_probe(struct i2c_cl
/* Enable setting output voltage by I2C */
regmap_update_bits(tps->regmap, TPS65023_REG_CON_CTRL2,
- TPS65023_REG_CTRL2_CORE_ADJ,
- TPS65023_REG_CTRL2_CORE_ADJ);
+ TPS65023_REG_CTRL2_CORE_ADJ, 0);
return 0;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 025/103] s390/kdump: Add final note
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 024/103] regulator: tps65023: Fix inverted core enable logic Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 026/103] s390/cputime: fix incorrect system time Greg Kroah-Hartman
` (75 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Holzheu, Martin Schwidefsky
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
commit dcc00b79fc3d076832f7240de8870f492629b171 upstream.
Since linux v3.14 with commit 38dfac843cb6d7be1 ("vmcore: prevent PT_NOTE
p_memsz overflow during header update") on s390 we get the following
message in the kdump kernel:
Warning: Exceeded p_memsz, dropping PT_NOTE entry n_namesz=0x6b6b6b6b,
n_descsz=0x6b6b6b6b
The reason for this is that we don't create a final zero note in
the ELF header which the proc/vmcore code uses to find out the end
of the notes section (see also kernel/kexec_core.c:final_note()).
It still worked on s390 by chance because we (most of the time?) have the
byte pattern 0x6b6b6b6b after the notes section which also makes the notes
parsing code stop in update_note_header_size_elf64() because 0x6b6b6b6b is
interpreded as note size:
if ((real_sz + sz) > max_sz) {
pr_warn("Warning: Exceeded p_memsz, dropping P ...);
break;
}
So fix this and add the missing final note to the ELF header.
We don't have to adjust the memory size for ELF header ("alloc_size")
because the new ELF note still fits into the 0x1000 base memory.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/kernel/crash_dump.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
--- a/arch/s390/kernel/crash_dump.c
+++ b/arch/s390/kernel/crash_dump.c
@@ -464,6 +464,20 @@ static void *nt_vmcoreinfo(void *ptr)
}
/*
+ * Initialize final note (needed for /proc/vmcore code)
+ */
+static void *nt_final(void *ptr)
+{
+ Elf64_Nhdr *note;
+
+ note = (Elf64_Nhdr *) ptr;
+ note->n_namesz = 0;
+ note->n_descsz = 0;
+ note->n_type = 0;
+ return PTR_ADD(ptr, sizeof(Elf64_Nhdr));
+}
+
+/*
* Initialize ELF header (new kernel)
*/
static void *ehdr_init(Elf64_Ehdr *ehdr, int mem_chunk_cnt)
@@ -553,6 +567,7 @@ static void *notes_init(Elf64_Phdr *phdr
ptr = fill_cpu_elf_notes(ptr, &sa_ext->sa, sa_ext->vx_regs);
}
ptr = nt_vmcoreinfo(ptr);
+ ptr = nt_final(ptr);
memset(phdr, 0, sizeof(*phdr));
phdr->p_type = PT_NOTE;
phdr->p_offset = notes_offset;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 026/103] s390/cputime: fix incorrect system time
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 025/103] s390/kdump: Add final note Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 027/103] ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device Greg Kroah-Hartman
` (74 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Borntraeger, Martin Schwidefsky
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
commit 07a63cbe8bcb6ba72fb989dcab1ec55ec6c36c7e upstream.
git commit c5328901aa1db134 "[S390] entry[64].S improvements" removed
the update of the exit_timer lowcore field from the critical section
cleanup of the .Lsysc_restore/.Lsysc_done and .Lio_restore/.Lio_done
blocks. If the PSW is updated by the critical section cleanup to point to
user space again, the interrupt entry code will do a vtime calculation
after the cleanup completed with an exit_timer value which has *not* been
updated. Due to this incorrect system time deltas are calculated.
If an interrupt occured with an old PSW between .Lsysc_restore/.Lsysc_done
or .Lio_restore/.Lio_done update __LC_EXIT_TIMER with the system entry
time of the interrupt.
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/kernel/entry.S | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@ -308,6 +308,7 @@ ENTRY(system_call)
lg %r14,__LC_VDSO_PER_CPU
lmg %r0,%r10,__PT_R0(%r11)
mvc __LC_RETURN_PSW(16),__PT_PSW(%r11)
+.Lsysc_exit_timer:
stpt __LC_EXIT_TIMER
mvc __VDSO_ECTG_BASE(16,%r14),__LC_EXIT_TIMER
lmg %r11,%r15,__PT_R11(%r11)
@@ -593,6 +594,7 @@ ENTRY(io_int_handler)
lg %r14,__LC_VDSO_PER_CPU
lmg %r0,%r10,__PT_R0(%r11)
mvc __LC_RETURN_PSW(16),__PT_PSW(%r11)
+.Lio_exit_timer:
stpt __LC_EXIT_TIMER
mvc __VDSO_ECTG_BASE(16,%r14),__LC_EXIT_TIMER
lmg %r11,%r15,__PT_R11(%r11)
@@ -1118,15 +1120,23 @@ cleanup_critical:
br %r14
.Lcleanup_sysc_restore:
+ # check if stpt has been executed
clg %r9,BASED(.Lcleanup_sysc_restore_insn)
+ jh 0f
+ mvc __LC_EXIT_TIMER(8),__LC_ASYNC_ENTER_TIMER
+ cghi %r11,__LC_SAVE_AREA_ASYNC
je 0f
+ mvc __LC_EXIT_TIMER(8),__LC_MCCK_ENTER_TIMER
+0: clg %r9,BASED(.Lcleanup_sysc_restore_insn+8)
+ je 1f
lg %r9,24(%r11) # get saved pointer to pt_regs
mvc __LC_RETURN_PSW(16),__PT_PSW(%r9)
mvc 0(64,%r11),__PT_R8(%r9)
lmg %r0,%r7,__PT_R0(%r9)
-0: lmg %r8,%r9,__LC_RETURN_PSW
+1: lmg %r8,%r9,__LC_RETURN_PSW
br %r14
.Lcleanup_sysc_restore_insn:
+ .quad .Lsysc_exit_timer
.quad .Lsysc_done - 4
.Lcleanup_io_tif:
@@ -1134,15 +1144,20 @@ cleanup_critical:
br %r14
.Lcleanup_io_restore:
+ # check if stpt has been executed
clg %r9,BASED(.Lcleanup_io_restore_insn)
- je 0f
+ jh 0f
+ mvc __LC_EXIT_TIMER(8),__LC_MCCK_ENTER_TIMER
+0: clg %r9,BASED(.Lcleanup_io_restore_insn+8)
+ je 1f
lg %r9,24(%r11) # get saved r11 pointer to pt_regs
mvc __LC_RETURN_PSW(16),__PT_PSW(%r9)
mvc 0(64,%r11),__PT_R8(%r9)
lmg %r0,%r7,__PT_R0(%r9)
-0: lmg %r8,%r9,__LC_RETURN_PSW
+1: lmg %r8,%r9,__LC_RETURN_PSW
br %r14
.Lcleanup_io_restore_insn:
+ .quad .Lio_exit_timer
.quad .Lio_done - 4
.Lcleanup_idle:
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 027/103] ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 026/103] s390/cputime: fix incorrect system time Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 028/103] ath9k_htc: fix NULL-deref at probe Greg Kroah-Hartman
` (73 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dmitry Tunin, Kalle Valo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Tunin <hanipouspilot@gmail.com>
commit 16ff1fb0e32f76a5d285a6f23b82d21aa52813c6 upstream.
T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 7 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1
P: Vendor=1eda ProdID=2315 Rev=01.08
S: Manufacturer=ATHEROS
S: Product=USB2.0 WLAN
S: SerialNumber=12345
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -37,6 +37,7 @@ static struct usb_device_id ath9k_hif_us
{ USB_DEVICE(0x0cf3, 0xb002) }, /* Ubiquiti WifiStation */
{ USB_DEVICE(0x057c, 0x8403) }, /* AVM FRITZ!WLAN 11N v2 USB */
{ USB_DEVICE(0x0471, 0x209e) }, /* Philips (or NXP) PTA01 */
+ { USB_DEVICE(0x1eda, 0x2315) }, /* AirTies */
{ USB_DEVICE(0x0cf3, 0x7015),
.driver_info = AR9287_USB }, /* Atheros */
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 028/103] ath9k_htc: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 027/103] ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 029/103] drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations Greg Kroah-Hartman
` (72 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold, Kalle Valo
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit ebeb36670ecac36c179b5fb5d5c88ff03ba191ec upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1217,6 +1217,9 @@ static int send_eject_command(struct usb
u8 bulk_out_ep;
int r;
+ if (iface_desc->desc.bNumEndpoints < 2)
+ return -ENODEV;
+
/* Find bulk out endpoint */
for (r = 1; r >= 0; r--) {
endpoint = &iface_desc->endpoint[r].desc;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 029/103] drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations.
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 028/103] ath9k_htc: fix NULL-deref at probe Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate Greg Kroah-Hartman
` (71 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher, Mario Kleiner
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Kleiner <mario.kleiner.de@gmail.com>
commit e190ed1ea7458e446230de4113cc5d53b8dc4ec8 upstream.
At dot clocks > approx. 250 Mhz, some of these calcs will overflow and
cause miscalculation of latency watermarks, and for some overflows also
divide-by-zero driver crash ("divide error: 0000 [#1] PREEMPT SMP" in
"dce_v10_0_latency_watermark+0x12d/0x190").
This zero-divide happened, e.g., on AMD Tonga Pro under DCE-10,
on a Displayport panel when trying to set a video mode of 2560x1440
at 165 Hz vrefresh with a dot clock of 635.540 Mhz.
Refine calculations to avoid the overflows.
Tested for DCE-10 with R9 380 Tonga + ASUS ROG PG279 panel.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 19 +++----------------
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 19 +++----------------
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 19 +++----------------
3 files changed, 9 insertions(+), 48 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1126,23 +1126,10 @@ static u32 dce_v10_0_latency_watermark(s
a.full = dfixed_const(available_bandwidth);
b.full = dfixed_const(wm->num_heads);
a.full = dfixed_div(a, b);
+ tmp = div_u64((u64) dmif_size * (u64) wm->disp_clk, mc_latency + 512);
+ tmp = min(dfixed_trunc(a), tmp);
- b.full = dfixed_const(mc_latency + 512);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(b, c);
-
- c.full = dfixed_const(dmif_size);
- b.full = dfixed_div(c, b);
-
- tmp = min(dfixed_trunc(a), dfixed_trunc(b));
-
- b.full = dfixed_const(1000);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(c, b);
- c.full = dfixed_const(wm->bytes_per_pixel);
- b.full = dfixed_mul(b, c);
-
- lb_fill_bw = min(tmp, dfixed_trunc(b));
+ lb_fill_bw = min(tmp, wm->disp_clk * wm->bytes_per_pixel / 1000);
a.full = dfixed_const(max_src_lines_per_dst_line * wm->src_width * wm->bytes_per_pixel);
b.full = dfixed_const(1000);
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1114,23 +1114,10 @@ static u32 dce_v11_0_latency_watermark(s
a.full = dfixed_const(available_bandwidth);
b.full = dfixed_const(wm->num_heads);
a.full = dfixed_div(a, b);
+ tmp = div_u64((u64) dmif_size * (u64) wm->disp_clk, mc_latency + 512);
+ tmp = min(dfixed_trunc(a), tmp);
- b.full = dfixed_const(mc_latency + 512);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(b, c);
-
- c.full = dfixed_const(dmif_size);
- b.full = dfixed_div(c, b);
-
- tmp = min(dfixed_trunc(a), dfixed_trunc(b));
-
- b.full = dfixed_const(1000);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(c, b);
- c.full = dfixed_const(wm->bytes_per_pixel);
- b.full = dfixed_mul(b, c);
-
- lb_fill_bw = min(tmp, dfixed_trunc(b));
+ lb_fill_bw = min(tmp, wm->disp_clk * wm->bytes_per_pixel / 1000);
a.full = dfixed_const(max_src_lines_per_dst_line * wm->src_width * wm->bytes_per_pixel);
b.full = dfixed_const(1000);
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1096,23 +1096,10 @@ static u32 dce_v8_0_latency_watermark(st
a.full = dfixed_const(available_bandwidth);
b.full = dfixed_const(wm->num_heads);
a.full = dfixed_div(a, b);
+ tmp = div_u64((u64) dmif_size * (u64) wm->disp_clk, mc_latency + 512);
+ tmp = min(dfixed_trunc(a), tmp);
- b.full = dfixed_const(mc_latency + 512);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(b, c);
-
- c.full = dfixed_const(dmif_size);
- b.full = dfixed_div(c, b);
-
- tmp = min(dfixed_trunc(a), dfixed_trunc(b));
-
- b.full = dfixed_const(1000);
- c.full = dfixed_const(wm->disp_clk);
- b.full = dfixed_div(c, b);
- c.full = dfixed_const(wm->bytes_per_pixel);
- b.full = dfixed_mul(b, c);
-
- lb_fill_bw = min(tmp, dfixed_trunc(b));
+ lb_fill_bw = min(tmp, wm->disp_clk * wm->bytes_per_pixel / 1000);
a.full = dfixed_const(max_src_lines_per_dst_line * wm->src_width * wm->bytes_per_pixel);
b.full = dfixed_const(1000);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 029/103] drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calculations Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-06-01 11:13 ` Ben Hutchings
2017-05-23 20:08 ` [PATCH 4.4 031/103] drm/nouveau/therm: remove ineffective workarounds for alarm bugs Greg Kroah-Hartman
` (70 subsequent siblings)
97 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alex Deucher, Mario Kleiner
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Kleiner <mario.kleiner.de@gmail.com>
commit d63c277dc672e0c568481af043359420fa9d4736 upstream.
Avoid big roundoff errors in scanline/hactive durations for
high pixel clocks, especially for >= 500 Mhz, and thereby
program more accurate display fifo watermarks.
Implemented here for DCE 6,8,10,11.
Successfully tested on DCE 10 with AMD R9 380 Tonga.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 10 +++++-----
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 10 +++++-----
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 10 +++++-----
3 files changed, 15 insertions(+), 15 deletions(-)
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1237,14 +1237,14 @@ static void dce_v10_0_program_watermarks
{
struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
struct dce10_wm_params wm_low, wm_high;
- u32 pixel_period;
+ u32 active_time;
u32 line_time = 0;
u32 latency_watermark_a = 0, latency_watermark_b = 0;
u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
if (amdgpu_crtc->base.enabled && num_heads && mode) {
- pixel_period = 1000000 / (u32)mode->clock;
- line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535);
+ active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock;
+ line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535);
/* watermark for high clocks */
if (adev->pm.dpm_enabled) {
@@ -1259,7 +1259,7 @@ static void dce_v10_0_program_watermarks
wm_high.disp_clk = mode->clock;
wm_high.src_width = mode->crtc_hdisplay;
- wm_high.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_high.active_time = active_time;
wm_high.blank_time = line_time - wm_high.active_time;
wm_high.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -1298,7 +1298,7 @@ static void dce_v10_0_program_watermarks
wm_low.disp_clk = mode->clock;
wm_low.src_width = mode->crtc_hdisplay;
- wm_low.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_low.active_time = active_time;
wm_low.blank_time = line_time - wm_low.active_time;
wm_low.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1225,14 +1225,14 @@ static void dce_v11_0_program_watermarks
{
struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
struct dce10_wm_params wm_low, wm_high;
- u32 pixel_period;
+ u32 active_time;
u32 line_time = 0;
u32 latency_watermark_a = 0, latency_watermark_b = 0;
u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
if (amdgpu_crtc->base.enabled && num_heads && mode) {
- pixel_period = 1000000 / (u32)mode->clock;
- line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535);
+ active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock;
+ line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535);
/* watermark for high clocks */
if (adev->pm.dpm_enabled) {
@@ -1247,7 +1247,7 @@ static void dce_v11_0_program_watermarks
wm_high.disp_clk = mode->clock;
wm_high.src_width = mode->crtc_hdisplay;
- wm_high.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_high.active_time = active_time;
wm_high.blank_time = line_time - wm_high.active_time;
wm_high.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -1286,7 +1286,7 @@ static void dce_v11_0_program_watermarks
wm_low.disp_clk = mode->clock;
wm_low.src_width = mode->crtc_hdisplay;
- wm_low.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_low.active_time = active_time;
wm_low.blank_time = line_time - wm_low.active_time;
wm_low.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -1207,14 +1207,14 @@ static void dce_v8_0_program_watermarks(
{
struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
struct dce8_wm_params wm_low, wm_high;
- u32 pixel_period;
+ u32 active_time;
u32 line_time = 0;
u32 latency_watermark_a = 0, latency_watermark_b = 0;
u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
if (amdgpu_crtc->base.enabled && num_heads && mode) {
- pixel_period = 1000000 / (u32)mode->clock;
- line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535);
+ active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock;
+ line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535);
/* watermark for high clocks */
if (adev->pm.dpm_enabled) {
@@ -1229,7 +1229,7 @@ static void dce_v8_0_program_watermarks(
wm_high.disp_clk = mode->clock;
wm_high.src_width = mode->crtc_hdisplay;
- wm_high.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_high.active_time = active_time;
wm_high.blank_time = line_time - wm_high.active_time;
wm_high.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -1268,7 +1268,7 @@ static void dce_v8_0_program_watermarks(
wm_low.disp_clk = mode->clock;
wm_low.src_width = mode->crtc_hdisplay;
- wm_low.active_time = mode->crtc_hdisplay * pixel_period;
+ wm_low.active_time = active_time;
wm_low.blank_time = line_time - wm_low.active_time;
wm_low.interlaced = false;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate
2017-05-23 20:08 ` [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate Greg Kroah-Hartman
@ 2017-06-01 11:13 ` Ben Hutchings
2017-06-06 17:46 ` Mario Kleiner
0 siblings, 1 reply; 121+ messages in thread
From: Ben Hutchings @ 2017-06-01 11:13 UTC (permalink / raw)
To: Alex Deucher, Mario Kleiner; +Cc: linux-kernel, stable, Greg Kroah-Hartman
On Tue, 2017-05-23 at 22:08 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Mario Kleiner <mario.kleiner.de@gmail.com>
>
> commit d63c277dc672e0c568481af043359420fa9d4736 upstream.
>
> Avoid big roundoff errors in scanline/hactive durations for
> high pixel clocks, especially for >= 500 Mhz, and thereby
> program more accurate display fifo watermarks.
[...]
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1237,14 +1237,14 @@ static void dce_v10_0_program_watermarks
> {
> struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
> struct dce10_wm_params wm_low, wm_high;
> - u32 pixel_period;
> + u32 active_time;
> u32 line_time = 0;
> u32 latency_watermark_a = 0, latency_watermark_b = 0;
> u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
>
> if (amdgpu_crtc->base.enabled && num_heads && mode) {
> - pixel_period = 1000000 / (u32)mode->clock;
> - line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535);
> + active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock;
> + line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535);
[...]
Won't these multiplications overflow if a >4K display is attached to a
32-bit machine?
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate
2017-06-01 11:13 ` Ben Hutchings
@ 2017-06-06 17:46 ` Mario Kleiner
2017-06-08 10:49 ` Ben Hutchings
0 siblings, 1 reply; 121+ messages in thread
From: Mario Kleiner @ 2017-06-06 17:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Alex Deucher, LKML, stable, Greg Kroah-Hartman
On Thu, Jun 1, 2017 at 1:13 PM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Tue, 2017-05-23 at 22:08 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Mario Kleiner <mario.kleiner.de@gmail.com>
>>
>> commit d63c277dc672e0c568481af043359420fa9d4736 upstream.
>>
>> Avoid big roundoff errors in scanline/hactive durations for
>> high pixel clocks, especially for >= 500 Mhz, and thereby
>> program more accurate display fifo watermarks.
> [...]
>> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
>> @@ -1237,14 +1237,14 @@ static void dce_v10_0_program_watermarks
>> {
>> struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
>> struct dce10_wm_params wm_low, wm_high;
>> - u32 pixel_period;
>> + u32 active_time;
>> u32 line_time = 0;
>> u32 latency_watermark_a = 0, latency_watermark_b = 0;
>> u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
>>
>> if (amdgpu_crtc->base.enabled && num_heads && mode) {
>> - pixel_period = 1000000 / (u32)mode->clock;
>> - line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535);
>> + active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock;
>> + line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535);
> [...]
>
> Won't these multiplications overflow if a >4K display is attached to a
> 32-bit machine?
>
> Ben.
>
Yes, indeed > 4k causes a new overflow problem! Thanks for catching this.
I will prepare a follow-up patch on top of this one, to use ...
active_time = (u32) div_u64((u64) mode->crtc_hdisplay * 1000000,
(u32)mode->clock);
line_time = (u32) div_u64((u64) mode->crtc_htotal * 1000000, (u32)mode->clock);
line_time = min(line_time, (u32) 65535);
...instead.
Ok?
-mario
> --
> Ben Hutchings
> Software Developer, Codethink Ltd.
>
>
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate
2017-06-06 17:46 ` Mario Kleiner
@ 2017-06-08 10:49 ` Ben Hutchings
0 siblings, 0 replies; 121+ messages in thread
From: Ben Hutchings @ 2017-06-08 10:49 UTC (permalink / raw)
To: Mario Kleiner; +Cc: Alex Deucher, LKML, stable, Greg Kroah-Hartman
On Tue, 2017-06-06 at 19:46 +0200, Mario Kleiner wrote:
> On Thu, Jun 1, 2017 at 1:13 PM, Ben Hutchings
> <ben.hutchings@codethink.co.uk> wrote:
> > On Tue, 2017-05-23 at 22:08 +0200, Greg Kroah-Hartman wrote:
> >> 4.4-stable review patch. If anyone has any objections, please let me know.
> >>
> >> ------------------
> >>
> >> From: Mario Kleiner <mario.kleiner.de@gmail.com>
> >>
> >> commit d63c277dc672e0c568481af043359420fa9d4736 upstream.
> >>
> >> Avoid big roundoff errors in scanline/hactive durations for
> >> high pixel clocks, especially for >= 500 Mhz, and thereby
> >> program more accurate display fifo watermarks.
> > [...]
> >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> >> @@ -1237,14 +1237,14 @@ static void dce_v10_0_program_watermarks
> >> {
> >> struct drm_display_mode *mode = &amdgpu_crtc->base.mode;
> >> struct dce10_wm_params wm_low, wm_high;
> >> - u32 pixel_period;
> >> + u32 active_time;
> >> u32 line_time = 0;
> >> u32 latency_watermark_a = 0, latency_watermark_b = 0;
> >> u32 tmp, wm_mask, lb_vblank_lead_lines = 0;
> >>
> >> if (amdgpu_crtc->base.enabled && num_heads && mode) {
> >> - pixel_period = 1000000 / (u32)mode->clock;
> >> - line_time = min((u32)mode->crtc_htotal * pixel_period, (u32)65535);
> >> + active_time = 1000000UL * (u32)mode->crtc_hdisplay / (u32)mode->clock;
> >> + line_time = min((u32) (1000000UL * (u32)mode->crtc_htotal / (u32)mode->clock), (u32)65535);
> > [...]
> >
> > Won't these multiplications overflow if a >4K display is attached to a
> > 32-bit machine?
> >
> > Ben.
> >
>
> Yes, indeed > 4k causes a new overflow problem! Thanks for catching this.
> I will prepare a follow-up patch on top of this one, to use ...
>
> active_time = (u32) div_u64((u64) mode->crtc_hdisplay * 1000000,
> (u32)mode->clock);
> line_time = (u32) div_u64((u64) mode->crtc_htotal * 1000000, (u32)mode->clock);
> line_time = min(line_time, (u32) 65535);
>
> ...instead.
>
> Ok?
I think that would work.
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 031/103] drm/nouveau/therm: remove ineffective workarounds for alarm bugs
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 030/103] drm/amdgpu: Make display watermark calculations more accurate Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 032/103] drm/nouveau/tmr: ack interrupt before processing alarms Greg Kroah-Hartman
` (69 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <bskeggs@redhat.com>
commit e4311ee51d1e2676001b2d8fcefd92bdd79aad85 upstream.
These were ineffective due to touching the list without the alarm lock,
but should no longer be required.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
@@ -130,7 +130,7 @@ nvkm_therm_update(struct nvkm_therm *the
poll = false;
}
- if (list_empty(&therm->alarm.head) && poll)
+ if (poll)
nvkm_timer_alarm(tmr, 1000000000ULL, &therm->alarm);
spin_unlock_irqrestore(&therm->lock, flags);
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c
@@ -83,7 +83,7 @@ nvkm_fan_update(struct nvkm_fan *fan, bo
spin_unlock_irqrestore(&fan->lock, flags);
/* schedule next fan update, if not at target speed already */
- if (list_empty(&fan->alarm.head) && target != duty) {
+ if (target != duty) {
u16 bump_period = fan->bios.bump_period;
u16 slow_down_period = fan->bios.slow_down_period;
u64 delay;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c
@@ -53,7 +53,7 @@ nvkm_fantog_update(struct nvkm_fantog *f
duty = !nvkm_gpio_get(gpio, 0, DCB_GPIO_FAN, 0xff);
nvkm_gpio_set(gpio, 0, DCB_GPIO_FAN, 0xff, duty);
- if (list_empty(&fan->alarm.head) && percent != (duty * 100)) {
+ if (percent != (duty * 100)) {
u64 next_change = (percent * fan->period_us) / 100;
if (!duty)
next_change = fan->period_us - next_change;
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c
@@ -185,7 +185,7 @@ alarm_timer_callback(struct nvkm_alarm *
spin_unlock_irqrestore(&therm->sensor.alarm_program_lock, flags);
/* schedule the next poll in one second */
- if (therm->func->temp_get(therm) >= 0 && list_empty(&alarm->head))
+ if (therm->func->temp_get(therm) >= 0)
nvkm_timer_alarm(tmr, 1000000000ULL, alarm);
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 032/103] drm/nouveau/tmr: ack interrupt before processing alarms
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 031/103] drm/nouveau/therm: remove ineffective workarounds for alarm bugs Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 033/103] drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm Greg Kroah-Hartman
` (68 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <bskeggs@redhat.com>
commit 3733bd8b407211739e72d051e5f30ad82a52c4bc upstream.
Fixes a race where we can miss an alarm that triggers while we're already
processing previous alarms.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv04.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv04.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv04.c
@@ -76,8 +76,8 @@ nv04_timer_intr(struct nvkm_timer *tmr)
u32 stat = nvkm_rd32(device, NV04_PTIMER_INTR_0);
if (stat & 0x00000001) {
- nvkm_timer_alarm_trigger(tmr);
nvkm_wr32(device, NV04_PTIMER_INTR_0, 0x00000001);
+ nvkm_timer_alarm_trigger(tmr);
stat &= ~0x00000001;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 033/103] drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 032/103] drm/nouveau/tmr: ack interrupt before processing alarms Greg Kroah-Hartman
@ 2017-05-23 20:08 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 034/103] drm/nouveau/tmr: avoid processing completed alarms when adding a new one Greg Kroah-Hartman
` (67 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:08 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <bskeggs@redhat.com>
commit 9fc64667ee48c9a25e7dca1a6bcb6906fec5bcc5 upstream.
At least therm/fantog "attempts" to work around this issue, which could
lead to corruption of the pending alarm list.
Fix it properly by not updating the timestamp without the lock held, or
trying to add an already pending alarm to the pending alarm list....
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
@@ -65,14 +65,17 @@ nvkm_timer_alarm(struct nvkm_timer *tmr,
struct nvkm_alarm *list;
unsigned long flags;
- alarm->timestamp = nvkm_timer_read(tmr) + nsec;
-
- /* append new alarm to list, in soonest-alarm-first order */
+ /* Remove alarm from pending list.
+ *
+ * This both protects against the corruption of the list,
+ * and implements alarm rescheduling/cancellation.
+ */
spin_lock_irqsave(&tmr->lock, flags);
- if (!nsec) {
- if (!list_empty(&alarm->head))
- list_del(&alarm->head);
- } else {
+ list_del_init(&alarm->head);
+
+ if (nsec) {
+ /* Insert into pending list, ordered earliest to latest. */
+ alarm->timestamp = nvkm_timer_read(tmr) + nsec;
list_for_each_entry(list, &tmr->alarms, head) {
if (list->timestamp > alarm->timestamp)
break;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 034/103] drm/nouveau/tmr: avoid processing completed alarms when adding a new one
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2017-05-23 20:08 ` [PATCH 4.4 033/103] drm/nouveau/tmr: fix corruption of the pending list when rescheduling an alarm Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 035/103] drm/nouveau/tmr: handle races with hw when updating the next alarm time Greg Kroah-Hartman
` (66 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <bskeggs@redhat.com>
commit 330bdf62fe6a6c5b99a647f7bf7157107c9348b3 upstream.
The idea here was to avoid having to "manually" program the HW if there's
a new earliest alarm. This was lazy and bad, as it leads to loads of fun
races between inter-related callers (ie. therm).
Turns out, it's not so difficult after all. Go figure ;)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
@@ -80,12 +80,22 @@ nvkm_timer_alarm(struct nvkm_timer *tmr,
if (list->timestamp > alarm->timestamp)
break;
}
+
list_add_tail(&alarm->head, &list->head);
+
+ /* Update HW if this is now the earliest alarm. */
+ list = list_first_entry(&tmr->alarms, typeof(*list), head);
+ if (list == alarm) {
+ tmr->func->alarm_init(tmr, alarm->timestamp);
+ /* This shouldn't happen if callers aren't stupid.
+ *
+ * Worst case scenario is that it'll take roughly
+ * 4 seconds for the next alarm to trigger.
+ */
+ WARN_ON(alarm->timestamp <= nvkm_timer_read(tmr));
+ }
}
spin_unlock_irqrestore(&tmr->lock, flags);
-
- /* process pending alarms */
- nvkm_timer_alarm_trigger(tmr);
}
void
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 035/103] drm/nouveau/tmr: handle races with hw when updating the next alarm time
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 034/103] drm/nouveau/tmr: avoid processing completed alarms when adding a new one Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 036/103] cdc-acm: fix possible invalid access when processing notification Greg Kroah-Hartman
` (65 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Skeggs
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Skeggs <bskeggs@redhat.com>
commit 1b0f84380b10ee97f7d2dd191294de9017e94d1d upstream.
If the time to the next alarm is short enough, we could race with HW and
end up with an ~4 second delay until it triggers.
Fix this by checking again after we update HW.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c | 26 ++++++++++++++---------
1 file changed, 16 insertions(+), 10 deletions(-)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c
@@ -36,23 +36,29 @@ nvkm_timer_alarm_trigger(struct nvkm_tim
unsigned long flags;
LIST_HEAD(exec);
- /* move any due alarms off the pending list */
+ /* Process pending alarms. */
spin_lock_irqsave(&tmr->lock, flags);
list_for_each_entry_safe(alarm, atemp, &tmr->alarms, head) {
- if (alarm->timestamp <= nvkm_timer_read(tmr))
- list_move_tail(&alarm->head, &exec);
+ /* Have we hit the earliest alarm that hasn't gone off? */
+ if (alarm->timestamp > nvkm_timer_read(tmr)) {
+ /* Schedule it. If we didn't race, we're done. */
+ tmr->func->alarm_init(tmr, alarm->timestamp);
+ if (alarm->timestamp > nvkm_timer_read(tmr))
+ break;
+ }
+
+ /* Move to completed list. We'll drop the lock before
+ * executing the callback so it can reschedule itself.
+ */
+ list_move_tail(&alarm->head, &exec);
}
- /* reschedule interrupt for next alarm time */
- if (!list_empty(&tmr->alarms)) {
- alarm = list_first_entry(&tmr->alarms, typeof(*alarm), head);
- tmr->func->alarm_init(tmr, alarm->timestamp);
- } else {
+ /* Shut down interrupt if no more pending alarms. */
+ if (list_empty(&tmr->alarms))
tmr->func->alarm_fini(tmr);
- }
spin_unlock_irqrestore(&tmr->lock, flags);
- /* execute any pending alarm handlers */
+ /* Execute completed callbacks. */
list_for_each_entry_safe(alarm, atemp, &exec, head) {
list_del_init(&alarm->head);
alarm->func(alarm);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 036/103] cdc-acm: fix possible invalid access when processing notification
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 035/103] drm/nouveau/tmr: handle races with hw when updating the next alarm time Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 037/103] proc: Fix unbalanced hard link numbers Greg Kroah-Hartman
` (64 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tobias Herzog, Oliver Neukum
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tobias Herzog <t-herzog@gmx.de>
commit 1bb9914e1730417d530de9ed37e59efdc647146b upstream.
Notifications may only be 8 bytes long. Accessing the 9th and
10th byte of unimplemented/unknown notifications may be insecure.
Also check the length of known notifications before accessing anything
behind the 8th byte.
Signed-off-by: Tobias Herzog <t-herzog@gmx.de>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/class/cdc-acm.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -311,6 +311,12 @@ static void acm_ctrl_irq(struct urb *urb
break;
case USB_CDC_NOTIFY_SERIAL_STATE:
+ if (le16_to_cpu(dr->wLength) != 2) {
+ dev_dbg(&acm->control->dev,
+ "%s - malformed serial state\n", __func__);
+ break;
+ }
+
newctrl = get_unaligned_le16(data);
if (!acm->clocal && (acm->ctrlin & ~newctrl & ACM_CTRL_DCD)) {
@@ -347,11 +353,10 @@ static void acm_ctrl_irq(struct urb *urb
default:
dev_dbg(&acm->control->dev,
- "%s - unknown notification %d received: index %d "
- "len %d data0 %d data1 %d\n",
+ "%s - unknown notification %d received: index %d len %d\n",
__func__,
- dr->bNotificationType, dr->wIndex,
- dr->wLength, data[0], data[1]);
+ dr->bNotificationType, dr->wIndex, dr->wLength);
+
break;
}
exit:
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 037/103] proc: Fix unbalanced hard link numbers
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 036/103] cdc-acm: fix possible invalid access when processing notification Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 038/103] of: fix sparse warning in of_pci_range_parser_one Greg Kroah-Hartman
` (63 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tristan Ye, Takashi Iwai, Eric W. Biederman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit d66bb1607e2d8d384e53f3d93db5c18483c8c4f7 upstream.
proc_create_mount_point() forgot to increase the parent's nlink, and
it resulted in unbalanced hard link numbers, e.g. /proc/fs shows one
less than expected.
Fixes: eb6d38d5427b ("proc: Allow creating permanently empty directories...")
Reported-by: Tristan Ye <tristan.ye@suse.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/proc/generic.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -469,6 +469,7 @@ struct proc_dir_entry *proc_create_mount
ent->data = NULL;
ent->proc_fops = NULL;
ent->proc_iops = NULL;
+ parent->nlink++;
if (proc_register(parent, ent) < 0) {
kfree(ent);
parent->nlink--;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 038/103] of: fix sparse warning in of_pci_range_parser_one
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 037/103] proc: Fix unbalanced hard link numbers Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 039/103] iio: dac: ad7303: fix channel description Greg Kroah-Hartman
` (62 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rob Herring
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <robh@kernel.org>
commit eb3100365791b06242b8bb5c3c2854ba41dabfbc upstream.
sparse gives the following warning for 'pci_space':
../drivers/of/address.c:266:26: warning: incorrect type in assignment (different base types)
../drivers/of/address.c:266:26: expected unsigned int [unsigned] [usertype] pci_space
../drivers/of/address.c:266:26: got restricted __be32 const [usertype] <noident>
It appears that pci_space is only ever accessed on powerpc, so the endian
swap is often not needed.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/of/address.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -260,7 +260,7 @@ struct of_pci_range *of_pci_range_parser
if (!parser->range || parser->range + parser->np > parser->end)
return NULL;
- range->pci_space = parser->range[0];
+ range->pci_space = be32_to_cpup(parser->range);
range->flags = of_bus_pci_get_flags(parser->range);
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 039/103] iio: dac: ad7303: fix channel description
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 038/103] of: fix sparse warning in of_pci_range_parser_one Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 040/103] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes Greg Kroah-Hartman
` (61 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pavel Roskin, Lars-Peter Clausen,
Jonathan Cameron
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Roskin <plroskin@gmail.com>
commit ce420fd4251809b4c3119b3b20c8b13bd8eba150 upstream.
realbits, storagebits and shift should be numbers, not ASCII characters.
Signed-off-by: Pavel Roskin <plroskin@gmail.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/dac/ad7303.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/iio/dac/ad7303.c
+++ b/drivers/iio/dac/ad7303.c
@@ -184,9 +184,9 @@ static const struct iio_chan_spec_ext_in
.address = (chan), \
.scan_type = { \
.sign = 'u', \
- .realbits = '8', \
- .storagebits = '8', \
- .shift = '0', \
+ .realbits = 8, \
+ .storagebits = 8, \
+ .shift = 0, \
}, \
.ext_info = ad7303_ext_info, \
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 040/103] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 039/103] iio: dac: ad7303: fix channel description Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-06-01 11:55 ` Ben Hutchings
2017-05-23 20:09 ` [PATCH 4.4 041/103] pid_ns: Fix race between setnsed fork() and zap_pid_ns_processes() Greg Kroah-Hartman
` (60 subsequent siblings)
97 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vovo Yang, Guenter Roeck, Eric W. Biederman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman <ebiederm@xmission.com>
commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
The code can potentially sleep for an indefinite amount of time in
zap_pid_ns_processes triggering the hung task timeout, and increasing
the system average. This is undesirable. Sleep with a task state of
TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
undesirable side effects.
Apparently under heavy load this has been allowing Chrome to trigger
the hung time task timeout error and cause ChromeOS to reboot.
Reported-by: Vovo Yang <vovoy@google.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 6347e9009104 ("pidns: guarantee that the pidns init will be the last pidns process reaped")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/pid_namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/pid_namespace.c
+++ b/kernel/pid_namespace.c
@@ -255,7 +255,7 @@ void zap_pid_ns_processes(struct pid_nam
* if reparented.
*/
for (;;) {
- set_current_state(TASK_UNINTERRUPTIBLE);
+ set_current_state(TASK_INTERRUPTIBLE);
if (pid_ns->nr_hashed == init_pids)
break;
schedule();
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 040/103] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
2017-05-23 20:09 ` [PATCH 4.4 040/103] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes Greg Kroah-Hartman
@ 2017-06-01 11:55 ` Ben Hutchings
2017-06-01 13:44 ` Eric W. Biederman
0 siblings, 1 reply; 121+ messages in thread
From: Ben Hutchings @ 2017-06-01 11:55 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, stable, Vovo Yang, Guenter Roeck, Greg Kroah-Hartman
On Tue, 2017-05-23 at 22:09 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Eric W. Biederman <ebiederm@xmission.com>
>
> commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
>
> The code can potentially sleep for an indefinite amount of time in
> zap_pid_ns_processes triggering the hung task timeout, and increasing
> the system average. This is undesirable. Sleep with a task state of
> TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
> undesirable side effects.
[...]
This seems to rely on the task not actually being signallable due to the
PF_EXITING flag. Using TASK_IDLE would be clearer (though less
backport-able).
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 040/103] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes
2017-06-01 11:55 ` Ben Hutchings
@ 2017-06-01 13:44 ` Eric W. Biederman
0 siblings, 0 replies; 121+ messages in thread
From: Eric W. Biederman @ 2017-06-01 13:44 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, Vovo Yang, Guenter Roeck, Greg Kroah-Hartman
Ben Hutchings <ben.hutchings@codethink.co.uk> writes:
> On Tue, 2017-05-23 at 22:09 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Eric W. Biederman <ebiederm@xmission.com>
>>
>> commit b9a985db98961ae1ba0be169f19df1c567e4ffe0 upstream.
>>
>> The code can potentially sleep for an indefinite amount of time in
>> zap_pid_ns_processes triggering the hung task timeout, and increasing
>> the system average. This is undesirable. Sleep with a task state of
>> TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE to remove these
>> undesirable side effects.
> [...]
>
> This seems to rely on the task not actually being signallable due to the
> PF_EXITING flag. Using TASK_IDLE would be clearer (though less
> backport-able).
Point taken. And imporatantly TASK_IDLE also avoids the hung_task
check.
Right now backporting and well understood simplicity is the primary
goal.
I have a patch in the queue for 4.13 that will remove this wait all
together, and just not allow reaping the zombie until the appropriate
conditions are met. That seems to be the better long term approach, as
it avoids blocking in such a weird way in a weird location all together.
Eric
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 041/103] pid_ns: Fix race between setnsed fork() and zap_pid_ns_processes()
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 040/103] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 042/103] USB: serial: ftdi_sio: fix setting latency for unprivileged users Greg Kroah-Hartman
` (59 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kirill Tkhai, Andrew Morton,
Ingo Molnar, Peter Zijlstra, Oleg Nesterov, Mike Rapoport,
Michal Hocko, Andy Lutomirski, Eric W. Biederman, Andrei Vagin,
Cyrill Gorcunov, Serge Hallyn
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill Tkhai <ktkhai@virtuozzo.com>
commit 3fd37226216620c1a468afa999739d5016fbc349 upstream.
Imagine we have a pid namespace and a task from its parent's pid_ns,
which made setns() to the pid namespace. The task is doing fork(),
while the pid namespace's child reaper is dying. We have the race
between them:
Task from parent pid_ns Child reaper
copy_process() ..
alloc_pid() ..
.. zap_pid_ns_processes()
.. disable_pid_allocation()
.. read_lock(&tasklist_lock)
.. iterate over pids in pid_ns
.. kill tasks linked to pids
.. read_unlock(&tasklist_lock)
write_lock_irq(&tasklist_lock); ..
attach_pid(p, PIDTYPE_PID); ..
.. ..
So, just created task p won't receive SIGKILL signal,
and the pid namespace will be in contradictory state.
Only manual kill will help there, but does the userspace
care about this? I suppose, the most users just inject
a task into a pid namespace and wait a SIGCHLD from it.
The patch fixes the problem. It simply checks for
(pid_ns->nr_hashed & PIDNS_HASH_ADDING) in copy_process().
We do it under the tasklist_lock, and can't skip
PIDNS_HASH_ADDING as noted by Oleg:
"zap_pid_ns_processes() does disable_pid_allocation()
and then takes tasklist_lock to kill the whole namespace.
Given that copy_process() checks PIDNS_HASH_ADDING
under write_lock(tasklist) they can't race;
if copy_process() takes this lock first, the new child will
be killed, otherwise copy_process() can't miss
the change in ->nr_hashed."
If allocation is disabled, we just return -ENOMEM
like it's made for such cases in alloc_pid().
v2: Do not move disable_pid_allocation(), do not
introduce a new variable in copy_process() and simplify
the patch as suggested by Oleg Nesterov.
Account the problem with double irq enabling
found by Eric W. Biederman.
Fixes: c876ad768215 ("pidns: Stop pid allocation when init dies")
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Ingo Molnar <mingo@kernel.org>
CC: Peter Zijlstra <peterz@infradead.org>
CC: Oleg Nesterov <oleg@redhat.com>
CC: Mike Rapoport <rppt@linux.vnet.ibm.com>
CC: Michal Hocko <mhocko@suse.com>
CC: Andy Lutomirski <luto@kernel.org>
CC: "Eric W. Biederman" <ebiederm@xmission.com>
CC: Andrei Vagin <avagin@openvz.org>
CC: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Serge Hallyn <serge@hallyn.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1590,11 +1590,13 @@ static struct task_struct *copy_process(
*/
recalc_sigpending();
if (signal_pending(current)) {
- spin_unlock(¤t->sighand->siglock);
- write_unlock_irq(&tasklist_lock);
retval = -ERESTARTNOINTR;
goto bad_fork_cancel_cgroup;
}
+ if (unlikely(!(ns_of_pid(pid)->nr_hashed & PIDNS_HASH_ADDING))) {
+ retval = -ENOMEM;
+ goto bad_fork_cancel_cgroup;
+ }
if (likely(p->pid)) {
ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
@@ -1645,6 +1647,8 @@ static struct task_struct *copy_process(
return p;
bad_fork_cancel_cgroup:
+ spin_unlock(¤t->sighand->siglock);
+ write_unlock_irq(&tasklist_lock);
cgroup_cancel_fork(p, cgrp_ss_priv);
bad_fork_free_pid:
threadgroup_change_end(current);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 042/103] USB: serial: ftdi_sio: fix setting latency for unprivileged users
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 041/103] pid_ns: Fix race between setnsed fork() and zap_pid_ns_processes() Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 043/103] USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs Greg Kroah-Hartman
` (58 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Anthony Mallet, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anthony Mallet <anthony.mallet@laas.fr>
commit bb246681b3ed0967489a7401ad528c1aaa1a4c2e upstream.
Commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") enables unprivileged users to set the FTDI latency timer,
but there was a logic flaw that skipped sending the corresponding
USB control message to the device.
Specifically, the device latency timer would not be updated until next
open, something which was later also inadvertently broken by commit
c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port
probe").
A recent commit c6dce2626606 ("USB: serial: ftdi_sio: fix extreme
low-latency setting") disabled the low-latency mode by default so we now
need this fix to allow unprivileged users to again enable it.
Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
[johan: amend commit message]
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Fixes: c19db4c9e49a ("USB: ftdi_sio: set device latency timeout at port probe").
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1508,9 +1508,9 @@ static int set_serial_info(struct tty_st
(new_serial.flags & ASYNC_FLAGS));
priv->custom_divisor = new_serial.custom_divisor;
+check_and_exit:
write_latency_timer(port);
-check_and_exit:
if ((old_priv.flags & ASYNC_SPD_MASK) !=
(priv->flags & ASYNC_SPD_MASK)) {
if ((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 043/103] USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 042/103] USB: serial: ftdi_sio: fix setting latency for unprivileged users Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 044/103] ext4 crypto: dont let data integrity writebacks fail with ENOMEM Greg Kroah-Hartman
` (57 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrey Korolyov, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Korolyov <andrey@xdel.ru>
commit 5f63424ab7daac840df2b12dd5bcc5b38d50f779 upstream.
This patch adds support for recognition of ARM-USB-TINY(H) devices which
are almost identical to ARM-USB-OCD(H) but lacking separate barrel jack
and serial console.
By suggestion from Johan Hovold it is possible to replace
ftdi_jtag_quirk with a bit more generic construction. Since all
Olimex-ARM debuggers has exactly two ports, we could safely always use
only second port within the debugger family.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/ftdi_sio.c | 8 ++++----
drivers/usb/serial/ftdi_sio_ids.h | 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -809,10 +809,10 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
{ USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
- { USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
- .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_PID, 1) },
+ { USB_DEVICE_INTERFACE_NUMBER(OLIMEX_VID, OLIMEX_ARM_USB_TINY_H_PID, 1) },
{ USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -882,6 +882,8 @@
/* Olimex */
#define OLIMEX_VID 0x15BA
#define OLIMEX_ARM_USB_OCD_PID 0x0003
+#define OLIMEX_ARM_USB_TINY_PID 0x0004
+#define OLIMEX_ARM_USB_TINY_H_PID 0x002a
#define OLIMEX_ARM_USB_OCD_H_PID 0x002b
/*
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 044/103] ext4 crypto: dont let data integrity writebacks fail with ENOMEM
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 043/103] USB: serial: ftdi_sio: add Olimex ARM-USB-TINY(H) PIDs Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 045/103] ext4 crypto: fix some error handling Greg Kroah-Hartman
` (56 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Theodore Tso, Eric Biggers
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit c9af28fdd44922a6c10c9f8315718408af98e315 upstream.
We don't want the writeback triggered from the journal commit (in
data=writeback mode) to cause the journal to abort due to
generic_writepages() returning an ENOMEM error. In addition, if
fsync() fails with ENOMEM, most applications will probably not do the
right thing.
So if we are doing a data integrity sync, and ext4_encrypt() returns
ENOMEM, we will submit any queued I/O to date, and then retry the
allocation using GFP_NOFAIL.
Google-Bug-Id: 27641567
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/crypto.c | 37 +++++++++++++++++++++----------------
fs/ext4/ext4.h | 6 ++++--
fs/ext4/page-io.c | 14 +++++++++++++-
fs/ext4/readpage.c | 2 +-
4 files changed, 39 insertions(+), 20 deletions(-)
--- a/fs/ext4/crypto.c
+++ b/fs/ext4/crypto.c
@@ -94,7 +94,8 @@ void ext4_release_crypto_ctx(struct ext4
* Return: An allocated and initialized encryption context on success; error
* value or NULL otherwise.
*/
-struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode)
+struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode,
+ gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx = NULL;
int res = 0;
@@ -121,7 +122,7 @@ struct ext4_crypto_ctx *ext4_get_crypto_
list_del(&ctx->free_list);
spin_unlock_irqrestore(&ext4_crypto_ctx_lock, flags);
if (!ctx) {
- ctx = kmem_cache_zalloc(ext4_crypto_ctx_cachep, GFP_NOFS);
+ ctx = kmem_cache_zalloc(ext4_crypto_ctx_cachep, gfp_flags);
if (!ctx) {
res = -ENOMEM;
goto out;
@@ -258,7 +259,8 @@ static int ext4_page_crypto(struct inode
ext4_direction_t rw,
pgoff_t index,
struct page *src_page,
- struct page *dest_page)
+ struct page *dest_page,
+ gfp_t gfp_flags)
{
u8 xts_tweak[EXT4_XTS_TWEAK_SIZE];
@@ -269,7 +271,7 @@ static int ext4_page_crypto(struct inode
struct crypto_ablkcipher *tfm = ci->ci_ctfm;
int res = 0;
- req = ablkcipher_request_alloc(tfm, GFP_NOFS);
+ req = ablkcipher_request_alloc(tfm, gfp_flags);
if (!req) {
printk_ratelimited(KERN_ERR
"%s: crypto_request_alloc() failed\n",
@@ -310,9 +312,10 @@ static int ext4_page_crypto(struct inode
return 0;
}
-static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx)
+static struct page *alloc_bounce_page(struct ext4_crypto_ctx *ctx,
+ gfp_t gfp_flags)
{
- ctx->w.bounce_page = mempool_alloc(ext4_bounce_page_pool, GFP_NOWAIT);
+ ctx->w.bounce_page = mempool_alloc(ext4_bounce_page_pool, gfp_flags);
if (ctx->w.bounce_page == NULL)
return ERR_PTR(-ENOMEM);
ctx->flags |= EXT4_WRITE_PATH_FL;
@@ -335,7 +338,8 @@ static struct page *alloc_bounce_page(st
* error value or NULL.
*/
struct page *ext4_encrypt(struct inode *inode,
- struct page *plaintext_page)
+ struct page *plaintext_page,
+ gfp_t gfp_flags)
{
struct ext4_crypto_ctx *ctx;
struct page *ciphertext_page = NULL;
@@ -343,17 +347,17 @@ struct page *ext4_encrypt(struct inode *
BUG_ON(!PageLocked(plaintext_page));
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, gfp_flags);
if (IS_ERR(ctx))
return (struct page *) ctx;
/* The encryption operation will require a bounce page. */
- ciphertext_page = alloc_bounce_page(ctx);
+ ciphertext_page = alloc_bounce_page(ctx, gfp_flags);
if (IS_ERR(ciphertext_page))
goto errout;
ctx->w.control_page = plaintext_page;
err = ext4_page_crypto(inode, EXT4_ENCRYPT, plaintext_page->index,
- plaintext_page, ciphertext_page);
+ plaintext_page, ciphertext_page, gfp_flags);
if (err) {
ciphertext_page = ERR_PTR(err);
errout:
@@ -381,8 +385,8 @@ int ext4_decrypt(struct page *page)
{
BUG_ON(!PageLocked(page));
- return ext4_page_crypto(page->mapping->host,
- EXT4_DECRYPT, page->index, page, page);
+ return ext4_page_crypto(page->mapping->host, EXT4_DECRYPT,
+ page->index, page, page, GFP_NOFS);
}
int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex)
@@ -403,11 +407,11 @@ int ext4_encrypted_zeroout(struct inode
BUG_ON(inode->i_sb->s_blocksize != PAGE_CACHE_SIZE);
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, GFP_NOFS);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
- ciphertext_page = alloc_bounce_page(ctx);
+ ciphertext_page = alloc_bounce_page(ctx, GFP_NOWAIT);
if (IS_ERR(ciphertext_page)) {
err = PTR_ERR(ciphertext_page);
goto errout;
@@ -415,11 +419,12 @@ int ext4_encrypted_zeroout(struct inode
while (len--) {
err = ext4_page_crypto(inode, EXT4_ENCRYPT, lblk,
- ZERO_PAGE(0), ciphertext_page);
+ ZERO_PAGE(0), ciphertext_page,
+ GFP_NOFS);
if (err)
goto errout;
- bio = bio_alloc(GFP_KERNEL, 1);
+ bio = bio_alloc(GFP_NOWAIT, 1);
if (!bio) {
err = -ENOMEM;
goto errout;
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2261,11 +2261,13 @@ extern struct kmem_cache *ext4_crypt_inf
bool ext4_valid_contents_enc_mode(uint32_t mode);
uint32_t ext4_validate_encryption_key_size(uint32_t mode, uint32_t size);
extern struct workqueue_struct *ext4_read_workqueue;
-struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode);
+struct ext4_crypto_ctx *ext4_get_crypto_ctx(struct inode *inode,
+ gfp_t gfp_flags);
void ext4_release_crypto_ctx(struct ext4_crypto_ctx *ctx);
void ext4_restore_control_page(struct page *data_page);
struct page *ext4_encrypt(struct inode *inode,
- struct page *plaintext_page);
+ struct page *plaintext_page,
+ gfp_t gfp_flags);
int ext4_decrypt(struct page *page);
int ext4_encrypted_zeroout(struct inode *inode, struct ext4_extent *ex);
extern const struct dentry_operations ext4_encrypted_d_ops;
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/mm.h>
+#include <linux/backing-dev.h>
#include "ext4_jbd2.h"
#include "xattr.h"
@@ -485,9 +486,20 @@ int ext4_bio_write_page(struct ext4_io_s
if (ext4_encrypted_inode(inode) && S_ISREG(inode->i_mode) &&
nr_to_submit) {
- data_page = ext4_encrypt(inode, page);
+ gfp_t gfp_flags = GFP_NOFS;
+
+ retry_encrypt:
+ data_page = ext4_encrypt(inode, page, gfp_flags);
if (IS_ERR(data_page)) {
ret = PTR_ERR(data_page);
+ if (ret == ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
+ if (io->io_bio) {
+ ext4_io_submit(io);
+ congestion_wait(BLK_RW_ASYNC, HZ/50);
+ }
+ gfp_flags |= __GFP_NOFAIL;
+ goto retry_encrypt;
+ }
data_page = NULL;
goto out;
}
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -279,7 +279,7 @@ int ext4_mpage_readpages(struct address_
if (ext4_encrypted_inode(inode) &&
S_ISREG(inode->i_mode)) {
- ctx = ext4_get_crypto_ctx(inode);
+ ctx = ext4_get_crypto_ctx(inode, GFP_NOFS);
if (IS_ERR(ctx))
goto set_error_page;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 045/103] ext4 crypto: fix some error handling
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 044/103] ext4 crypto: dont let data integrity writebacks fail with ENOMEM Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 047/103] fscrypt: fix context consistency check when key(s) unavailable Greg Kroah-Hartman
` (55 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Theodore Tso, Eric Biggers
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 4762cc3fbbd89e5fd316d6e4d3244a8984444f8d upstream.
We should be testing for -ENOMEM but the minus sign is missing.
Fixes: c9af28fdd449 ('ext4 crypto: don't let data integrity writebacks fail with ENOMEM')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/page-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -492,7 +492,7 @@ int ext4_bio_write_page(struct ext4_io_s
data_page = ext4_encrypt(inode, page, gfp_flags);
if (IS_ERR(data_page)) {
ret = PTR_ERR(data_page);
- if (ret == ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
+ if (ret == -ENOMEM && wbc->sync_mode == WB_SYNC_ALL) {
if (io->io_bio) {
ext4_io_submit(io);
congestion_wait(BLK_RW_ASYNC, HZ/50);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 047/103] fscrypt: fix context consistency check when key(s) unavailable
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 045/103] ext4 crypto: fix some error handling Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 048/103] f2fs: check entire encrypted bigname when finding a dentry Greg Kroah-Hartman
` (54 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Eric Biggers, Theodore Tso
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 272f98f6846277378e1758a49a49d7bf39343c02 upstream.
To mitigate some types of offline attacks, filesystem encryption is
designed to enforce that all files in an encrypted directory tree use
the same encryption policy (i.e. the same encryption context excluding
the nonce). However, the fscrypt_has_permitted_context() function which
enforces this relies on comparing struct fscrypt_info's, which are only
available when we have the encryption keys. This can cause two
incorrect behaviors:
1. If we have the parent directory's key but not the child's key, or
vice versa, then fscrypt_has_permitted_context() returned false,
causing applications to see EPERM or ENOKEY. This is incorrect if
the encryption contexts are in fact consistent. Although we'd
normally have either both keys or neither key in that case since the
master_key_descriptors would be the same, this is not guaranteed
because keys can be added or removed from keyrings at any time.
2. If we have neither the parent's key nor the child's key, then
fscrypt_has_permitted_context() returned true, causing applications
to see no error (or else an error for some other reason). This is
incorrect if the encryption contexts are in fact inconsistent, since
in that case we should deny access.
To fix this, retrieve and compare the fscrypt_contexts if we are unable
to set up both fscrypt_infos.
While this slightly hurts performance when accessing an encrypted
directory tree without the key, this isn't a case we really need to be
optimizing for; access *with* the key is much more important.
Furthermore, the performance hit is barely noticeable given that we are
already retrieving the fscrypt_context and doing two keyring searches in
fscrypt_get_encryption_info(). If we ever actually wanted to optimize
this case we might start by caching the fscrypt_contexts.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/crypto_policy.c | 66 ++++++++++++++++++++++++++++++++++--------------
fs/f2fs/crypto_policy.c | 65 ++++++++++++++++++++++++++++++++++-------------
2 files changed, 96 insertions(+), 35 deletions(-)
--- a/fs/ext4/crypto_policy.c
+++ b/fs/ext4/crypto_policy.c
@@ -148,26 +148,38 @@ int ext4_get_policy(struct inode *inode,
int ext4_is_child_context_consistent_with_parent(struct inode *parent,
struct inode *child)
{
- struct ext4_crypt_info *parent_ci, *child_ci;
+ const struct ext4_crypt_info *parent_ci, *child_ci;
+ struct ext4_encryption_context parent_ctx, child_ctx;
int res;
- if ((parent == NULL) || (child == NULL)) {
- pr_err("parent %p child %p\n", parent, child);
- WARN_ON(1); /* Should never happen */
- return 0;
- }
-
/* No restrictions on file types which are never encrypted */
if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
!S_ISLNK(child->i_mode))
return 1;
- /* no restrictions if the parent directory is not encrypted */
+ /* No restrictions if the parent directory is unencrypted */
if (!ext4_encrypted_inode(parent))
return 1;
- /* if the child directory is not encrypted, this is always a problem */
+
+ /* Encrypted directories must not contain unencrypted files */
if (!ext4_encrypted_inode(child))
return 0;
+
+ /*
+ * Both parent and child are encrypted, so verify they use the same
+ * encryption policy. Compare the fscrypt_info structs if the keys are
+ * available, otherwise retrieve and compare the fscrypt_contexts.
+ *
+ * Note that the fscrypt_context retrieval will be required frequently
+ * when accessing an encrypted directory tree without the key.
+ * Performance-wise this is not a big deal because we already don't
+ * really optimize for file access without the key (to the extent that
+ * such access is even possible), given that any attempted access
+ * already causes a fscrypt_context retrieval and keyring search.
+ *
+ * In any case, if an unexpected error occurs, fall back to "forbidden".
+ */
+
res = ext4_get_encryption_info(parent);
if (res)
return 0;
@@ -176,17 +188,35 @@ int ext4_is_child_context_consistent_wit
return 0;
parent_ci = EXT4_I(parent)->i_crypt_info;
child_ci = EXT4_I(child)->i_crypt_info;
- if (!parent_ci && !child_ci)
- return 1;
- if (!parent_ci || !child_ci)
+ if (parent_ci && child_ci) {
+ return memcmp(parent_ci->ci_master_key, child_ci->ci_master_key,
+ EXT4_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
+ (parent_ci->ci_filename_mode ==
+ child_ci->ci_filename_mode) &&
+ (parent_ci->ci_flags == child_ci->ci_flags);
+ }
+
+ res = ext4_xattr_get(parent, EXT4_XATTR_INDEX_ENCRYPTION,
+ EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &parent_ctx, sizeof(parent_ctx));
+ if (res != sizeof(parent_ctx))
+ return 0;
+
+ res = ext4_xattr_get(child, EXT4_XATTR_INDEX_ENCRYPTION,
+ EXT4_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &child_ctx, sizeof(child_ctx));
+ if (res != sizeof(child_ctx))
return 0;
- return (memcmp(parent_ci->ci_master_key,
- child_ci->ci_master_key,
- EXT4_KEY_DESCRIPTOR_SIZE) == 0 &&
- (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
- (parent_ci->ci_filename_mode == child_ci->ci_filename_mode) &&
- (parent_ci->ci_flags == child_ci->ci_flags));
+ return memcmp(parent_ctx.master_key_descriptor,
+ child_ctx.master_key_descriptor,
+ EXT4_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ctx.contents_encryption_mode ==
+ child_ctx.contents_encryption_mode) &&
+ (parent_ctx.filenames_encryption_mode ==
+ child_ctx.filenames_encryption_mode) &&
+ (parent_ctx.flags == child_ctx.flags);
}
/**
--- a/fs/f2fs/crypto_policy.c
+++ b/fs/f2fs/crypto_policy.c
@@ -141,25 +141,38 @@ int f2fs_get_policy(struct inode *inode,
int f2fs_is_child_context_consistent_with_parent(struct inode *parent,
struct inode *child)
{
- struct f2fs_crypt_info *parent_ci, *child_ci;
+ const struct f2fs_crypt_info *parent_ci, *child_ci;
+ struct f2fs_encryption_context parent_ctx, child_ctx;
int res;
- if ((parent == NULL) || (child == NULL)) {
- pr_err("parent %p child %p\n", parent, child);
- BUG_ON(1);
- }
-
/* No restrictions on file types which are never encrypted */
if (!S_ISREG(child->i_mode) && !S_ISDIR(child->i_mode) &&
!S_ISLNK(child->i_mode))
return 1;
- /* no restrictions if the parent directory is not encrypted */
+ /* No restrictions if the parent directory is unencrypted */
if (!f2fs_encrypted_inode(parent))
return 1;
- /* if the child directory is not encrypted, this is always a problem */
+
+ /* Encrypted directories must not contain unencrypted files */
if (!f2fs_encrypted_inode(child))
return 0;
+
+ /*
+ * Both parent and child are encrypted, so verify they use the same
+ * encryption policy. Compare the fscrypt_info structs if the keys are
+ * available, otherwise retrieve and compare the fscrypt_contexts.
+ *
+ * Note that the fscrypt_context retrieval will be required frequently
+ * when accessing an encrypted directory tree without the key.
+ * Performance-wise this is not a big deal because we already don't
+ * really optimize for file access without the key (to the extent that
+ * such access is even possible), given that any attempted access
+ * already causes a fscrypt_context retrieval and keyring search.
+ *
+ * In any case, if an unexpected error occurs, fall back to "forbidden".
+ */
+
res = f2fs_get_encryption_info(parent);
if (res)
return 0;
@@ -168,17 +181,35 @@ int f2fs_is_child_context_consistent_wit
return 0;
parent_ci = F2FS_I(parent)->i_crypt_info;
child_ci = F2FS_I(child)->i_crypt_info;
- if (!parent_ci && !child_ci)
- return 1;
- if (!parent_ci || !child_ci)
+ if (parent_ci && child_ci) {
+ return memcmp(parent_ci->ci_master_key, child_ci->ci_master_key,
+ F2FS_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
+ (parent_ci->ci_filename_mode ==
+ child_ci->ci_filename_mode) &&
+ (parent_ci->ci_flags == child_ci->ci_flags);
+ }
+
+ res = f2fs_getxattr(parent, F2FS_XATTR_INDEX_ENCRYPTION,
+ F2FS_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &parent_ctx, sizeof(parent_ctx), NULL);
+ if (res != sizeof(parent_ctx))
+ return 0;
+
+ res = f2fs_getxattr(child, F2FS_XATTR_INDEX_ENCRYPTION,
+ F2FS_XATTR_NAME_ENCRYPTION_CONTEXT,
+ &child_ctx, sizeof(child_ctx), NULL);
+ if (res != sizeof(child_ctx))
return 0;
- return (memcmp(parent_ci->ci_master_key,
- child_ci->ci_master_key,
- F2FS_KEY_DESCRIPTOR_SIZE) == 0 &&
- (parent_ci->ci_data_mode == child_ci->ci_data_mode) &&
- (parent_ci->ci_filename_mode == child_ci->ci_filename_mode) &&
- (parent_ci->ci_flags == child_ci->ci_flags));
+ return memcmp(parent_ctx.master_key_descriptor,
+ child_ctx.master_key_descriptor,
+ F2FS_KEY_DESCRIPTOR_SIZE) == 0 &&
+ (parent_ctx.contents_encryption_mode ==
+ child_ctx.contents_encryption_mode) &&
+ (parent_ctx.filenames_encryption_mode ==
+ child_ctx.filenames_encryption_mode) &&
+ (parent_ctx.flags == child_ctx.flags);
}
/**
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 048/103] f2fs: check entire encrypted bigname when finding a dentry
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 047/103] fscrypt: fix context consistency check when key(s) unavailable Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 049/103] fscrypt: avoid collisions when presenting long encrypted filenames Greg Kroah-Hartman
` (53 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, Jaegeuk Kim, Theodore Tso
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jaegeuk Kim <jaegeuk@kernel.org>
commit 6332cd32c8290a80e929fc044dc5bdba77396e33 upstream.
If user has no key under an encrypted dir, fscrypt gives digested dentries.
Previously, when looking up a dentry, f2fs only checks its hash value with
first 4 bytes of the digested dentry, which didn't handle hash collisions fully.
This patch enhances to check entire dentry bytes likewise ext4.
Eric reported how to reproduce this issue by:
# seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
# find edir -type f | xargs stat -c %i | sort | uniq | wc -l
100000
# sync
# echo 3 > /proc/sys/vm/drop_caches
# keyctl new_session
# find edir -type f | xargs stat -c %i | sort | uniq | wc -l
99999
Cc: <stable@vger.kernel.org>
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(fixed f2fs_dentry_hash() to work even when the hash is 0)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/f2fs/dir.c | 32 +++++++++++++++++++++-----------
fs/f2fs/f2fs.h | 3 ++-
fs/f2fs/hash.c | 7 ++++++-
fs/f2fs/inline.c | 4 ++--
4 files changed, 31 insertions(+), 15 deletions(-)
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -124,19 +124,29 @@ struct f2fs_dir_entry *find_target_dentr
de = &d->dentry[bit_pos];
- /* encrypted case */
+ if (de->hash_code != namehash)
+ goto not_match;
+
de_name.name = d->filename[bit_pos];
de_name.len = le16_to_cpu(de->name_len);
- /* show encrypted name */
- if (fname->hash) {
- if (de->hash_code == fname->hash)
- goto found;
- } else if (de_name.len == name->len &&
- de->hash_code == namehash &&
- !memcmp(de_name.name, name->name, name->len))
+#ifdef CONFIG_F2FS_FS_ENCRYPTION
+ if (unlikely(!name->name)) {
+ if (fname->usr_fname->name[0] == '_') {
+ if (de_name.len >= 16 &&
+ !memcmp(de_name.name + de_name.len - 16,
+ fname->crypto_buf.name + 8, 16))
+ goto found;
+ goto not_match;
+ }
+ name->name = fname->crypto_buf.name;
+ name->len = fname->crypto_buf.len;
+ }
+#endif
+ if (de_name.len == name->len &&
+ !memcmp(de_name.name, name->name, name->len))
goto found;
-
+not_match:
if (max_slots && max_len > *max_slots)
*max_slots = max_len;
max_len = 0;
@@ -170,7 +180,7 @@ static struct f2fs_dir_entry *find_in_le
int max_slots;
f2fs_hash_t namehash;
- namehash = f2fs_dentry_hash(&name);
+ namehash = f2fs_dentry_hash(&name, fname);
f2fs_bug_on(F2FS_I_SB(dir), level > MAX_DIR_HASH_DEPTH);
@@ -547,7 +557,7 @@ int __f2fs_add_link(struct inode *dir, c
level = 0;
slots = GET_DENTRY_SLOTS(new_name.len);
- dentry_hash = f2fs_dentry_hash(&new_name);
+ dentry_hash = f2fs_dentry_hash(&new_name, NULL);
current_depth = F2FS_I(dir)->i_current_depth;
if (F2FS_I(dir)->chash == dentry_hash) {
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1722,7 +1722,8 @@ void f2fs_msg(struct super_block *, cons
/*
* hash.c
*/
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *);
+f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+ struct f2fs_filename *fname);
/*
* node.c
--- a/fs/f2fs/hash.c
+++ b/fs/f2fs/hash.c
@@ -70,7 +70,8 @@ static void str2hashbuf(const unsigned c
*buf++ = pad;
}
-f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info)
+f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
+ struct f2fs_filename *fname)
{
__u32 hash;
f2fs_hash_t f2fs_hash;
@@ -79,6 +80,10 @@ f2fs_hash_t f2fs_dentry_hash(const struc
const unsigned char *name = name_info->name;
size_t len = name_info->len;
+ /* encrypted bigname case */
+ if (fname && !fname->disk_name.name)
+ return cpu_to_le32(fname->hash);
+
if (is_dot_dotdot(name_info))
return 0;
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -303,7 +303,7 @@ struct f2fs_dir_entry *find_in_inline_di
if (IS_ERR(ipage))
return NULL;
- namehash = f2fs_dentry_hash(&name);
+ namehash = f2fs_dentry_hash(&name, fname);
inline_dentry = inline_data_addr(ipage);
@@ -468,7 +468,7 @@ int f2fs_add_inline_entry(struct inode *
f2fs_wait_on_page_writeback(ipage, NODE);
- name_hash = f2fs_dentry_hash(name);
+ name_hash = f2fs_dentry_hash(name, NULL);
make_dentry_ptr(NULL, &d, (void *)dentry_blk, 2);
f2fs_update_dentry(ino, mode, &d, name, name_hash, bit_pos);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 049/103] fscrypt: avoid collisions when presenting long encrypted filenames
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 048/103] f2fs: check entire encrypted bigname when finding a dentry Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 050/103] sched/fair: Do not announce throttled next buddy in dequeue_task_fair() Greg Kroah-Hartman
` (52 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gwendal Grignou, Eric Biggers, Theodore Tso
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 6b06cdee81d68a8a829ad8e8d0f31d6836744af9 upstream.
When accessing an encrypted directory without the key, userspace must
operate on filenames derived from the ciphertext names, which contain
arbitrary bytes. Since we must support filenames as long as NAME_MAX,
we can't always just base64-encode the ciphertext, since that may make
it too long. Currently, this is solved by presenting long names in an
abbreviated form containing any needed filesystem-specific hashes (e.g.
to identify a directory block), then the last 16 bytes of ciphertext.
This needs to be sufficient to identify the actual name on lookup.
However, there is a bug. It seems to have been assumed that due to the
use of a CBC (ciphertext block chaining)-based encryption mode, the last
16 bytes (i.e. the AES block size) of ciphertext would depend on the
full plaintext, preventing collisions. However, we actually use CBC
with ciphertext stealing (CTS), which handles the last two blocks
specially, causing them to appear "flipped". Thus, it's actually the
second-to-last block which depends on the full plaintext.
This caused long filenames that differ only near the end of their
plaintexts to, when observed without the key, point to the wrong inode
and be undeletable. For example, with ext4:
# echo pass | e4crypt add_key -p 16 edir/
# seq -f "edir/abcdefghijklmnopqrstuvwxyz012345%.0f" 100000 | xargs touch
# find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
100000
# sync
# echo 3 > /proc/sys/vm/drop_caches
# keyctl new_session
# find edir/ -type f | xargs stat -c %i | sort | uniq | wc -l
2004
# rm -rf edir/
rm: cannot remove 'edir/_A7nNFi3rhkEQlJ6P,hdzluhODKOeWx5V': Structure needs cleaning
...
To fix this, when presenting long encrypted filenames, encode the
second-to-last block of ciphertext rather than the last 16 bytes.
Although it would be nice to solve this without depending on a specific
encryption mode, that would mean doing a cryptographic hash like SHA-256
which would be much less efficient. This way is sufficient for now, and
it's still compatible with encryption modes like HEH which are strong
pseudorandom permutations. Also, changing the presented names is still
allowed at any time because they are only provided to allow applications
to do things like delete encrypted directories. They're not designed to
be used to persistently identify files --- which would be hard to do
anyway, given that they're encrypted after all.
For ease of backports, this patch only makes the minimal fix to both
ext4 and f2fs. It leaves ubifs as-is, since ubifs doesn't compare the
ciphertext block yet. Follow-on patches will clean things up properly
and make the filesystems use a shared helper function.
Fixes: 5de0b4d0cd15 ("ext4 crypto: simplify and speed up filename encryption")
Reported-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/crypto_fname.c | 2 +-
fs/ext4/namei.c | 4 ++--
fs/f2fs/crypto_fname.c | 2 +-
fs/f2fs/dir.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
--- a/fs/ext4/crypto_fname.c
+++ b/fs/ext4/crypto_fname.c
@@ -343,7 +343,7 @@ int _ext4_fname_disk_to_usr(struct inode
memcpy(buf+4, &hinfo->minor_hash, 4);
} else
memset(buf, 0, 8);
- memcpy(buf + 8, iname->name + iname->len - 16, 16);
+ memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
oname->name[0] = '_';
ret = digest_encode(buf, 24, oname->name+1);
oname->len = ret + 1;
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1243,9 +1243,9 @@ static inline int ext4_match(struct ext4
if (unlikely(!name)) {
if (fname->usr_fname->name[0] == '_') {
int ret;
- if (de->name_len < 16)
+ if (de->name_len <= 32)
return 0;
- ret = memcmp(de->name + de->name_len - 16,
+ ret = memcmp(de->name + ((de->name_len - 17) & ~15),
fname->crypto_buf.name + 8, 16);
return (ret == 0) ? 1 : 0;
}
--- a/fs/f2fs/crypto_fname.c
+++ b/fs/f2fs/crypto_fname.c
@@ -333,7 +333,7 @@ int f2fs_fname_disk_to_usr(struct inode
memset(buf + 4, 0, 4);
} else
memset(buf, 0, 8);
- memcpy(buf + 8, iname->name + iname->len - 16, 16);
+ memcpy(buf + 8, iname->name + ((iname->len - 17) & ~15), 16);
oname->name[0] = '_';
ret = digest_encode(buf, 24, oname->name + 1);
oname->len = ret + 1;
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -133,8 +133,8 @@ struct f2fs_dir_entry *find_target_dentr
#ifdef CONFIG_F2FS_FS_ENCRYPTION
if (unlikely(!name->name)) {
if (fname->usr_fname->name[0] == '_') {
- if (de_name.len >= 16 &&
- !memcmp(de_name.name + de_name.len - 16,
+ if (de_name.len > 32 &&
+ !memcmp(de_name.name + ((de_name.len - 17) & ~15),
fname->crypto_buf.name + 8, 16))
goto found;
goto not_match;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 050/103] sched/fair: Do not announce throttled next buddy in dequeue_task_fair()
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 049/103] fscrypt: avoid collisions when presenting long encrypted filenames Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 051/103] sched/fair: Initialize throttle_count for new task-groups lazily Greg Kroah-Hartman
` (51 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khlebnikov,
Peter Zijlstra (Intel),
Ben Segall, Linus Torvalds, Thomas Gleixner, Ingo Molnar,
Ben Pineau
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
commit 754bd598be9bbc953bc709a9e8ed7f3188bfb9d7 upstream.
Hierarchy could be already throttled at this point. Throttled next
buddy could trigger a NULL pointer dereference in pick_next_task_fair().
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/146608183552.21905.15924473394414832071.stgit@buzz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ben Pineau <benjamin.pineau@mirakl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/fair.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4233,15 +4233,14 @@ static void dequeue_task_fair(struct rq
/* Don't dequeue parent if it has other entities besides us */
if (cfs_rq->load.weight) {
+ /* Avoid re-evaluating load for this entity: */
+ se = parent_entity(se);
/*
* Bias pick_next to pick a task from this cfs_rq, as
* p is sleeping when it is within its sched_slice.
*/
- if (task_sleep && parent_entity(se))
- set_next_buddy(parent_entity(se));
-
- /* avoid re-evaluating load for this entity */
- se = parent_entity(se);
+ if (task_sleep && se && !throttled_hierarchy(cfs_rq))
+ set_next_buddy(se);
break;
}
flags |= DEQUEUE_SLEEP;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 051/103] sched/fair: Initialize throttle_count for new task-groups lazily
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 050/103] sched/fair: Do not announce throttled next buddy in dequeue_task_fair() Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 052/103] usb: host: xhci-plat: propagate return value of platform_get_irq() Greg Kroah-Hartman
` (50 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khlebnikov,
Peter Zijlstra (Intel),
Linus Torvalds, Thomas Gleixner, bsegall, Ingo Molnar,
Ben Pineau
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
commit 094f469172e00d6ab0a3130b0e01c83b3cf3a98d upstream.
Cgroup created inside throttled group must inherit current throttle_count.
Broken throttle_count allows to nominate throttled entries as a next buddy,
later this leads to null pointer dereference in pick_next_task_fair().
This patch initialize cfs_rq->throttle_count at first enqueue: laziness
allows to skip locking all rq at group creation. Lazy approach also allows
to skip full sub-tree scan at throttling hierarchy (not in this patch).
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Link: http://lkml.kernel.org/r/146608182119.21870.8439834428248129633.stgit@buzz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ben Pineau <benjamin.pineau@mirakl.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/fair.c | 20 ++++++++++++++++++++
kernel/sched/sched.h | 2 +-
2 files changed, 21 insertions(+), 1 deletion(-)
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3918,6 +3918,26 @@ static void check_enqueue_throttle(struc
if (!cfs_bandwidth_used())
return;
+ /* Synchronize hierarchical throttle counter: */
+ if (unlikely(!cfs_rq->throttle_uptodate)) {
+ struct rq *rq = rq_of(cfs_rq);
+ struct cfs_rq *pcfs_rq;
+ struct task_group *tg;
+
+ cfs_rq->throttle_uptodate = 1;
+
+ /* Get closest up-to-date node, because leaves go first: */
+ for (tg = cfs_rq->tg->parent; tg; tg = tg->parent) {
+ pcfs_rq = tg->cfs_rq[cpu_of(rq)];
+ if (pcfs_rq->throttle_uptodate)
+ break;
+ }
+ if (tg) {
+ cfs_rq->throttle_count = pcfs_rq->throttle_count;
+ cfs_rq->throttled_clock_task = rq_clock_task(rq);
+ }
+ }
+
/* an active group must be handled by the update_curr()->put() path */
if (!cfs_rq->runtime_enabled || cfs_rq->curr)
return;
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -417,7 +417,7 @@ struct cfs_rq {
u64 throttled_clock, throttled_clock_task;
u64 throttled_clock_task_time;
- int throttled, throttle_count;
+ int throttled, throttle_count, throttle_uptodate;
struct list_head throttled_list;
#endif /* CONFIG_CFS_BANDWIDTH */
#endif /* CONFIG_FAIR_GROUP_SCHED */
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 052/103] usb: host: xhci-plat: propagate return value of platform_get_irq()
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 051/103] sched/fair: Initialize throttle_count for new task-groups lazily Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 053/103] xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton Greg Kroah-Hartman
` (49 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Thomas Petazzoni, Mathias Nyman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
commit 4b148d5144d64ee135b8924350cb0b3a7fd21150 upstream.
platform_get_irq() returns an error code, but the xhci-plat driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -92,7 +92,7 @@ static int xhci_plat_probe(struct platfo
irq = platform_get_irq(pdev, 0);
if (irq < 0)
- return -ENODEV;
+ return irq;
/* Try to set 64-bit DMA first */
if (WARN_ON(!pdev->dev.dma_mask))
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 053/103] xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 052/103] usb: host: xhci-plat: propagate return value of platform_get_irq() Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 054/103] usb: host: xhci-mem: allocate zeroed Scratchpad Buffer Greg Kroah-Hartman
` (48 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mathias Nyman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit a0c16630d35a874e82bdf2088f58ecaca1024315 upstream.
Intel Denverton microserver is Atom based and need the PME and CAS quirks
as well.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-pci.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -52,6 +52,7 @@
#define PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI 0x0aa8
#define PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI 0x1aa8
#define PCI_DEVICE_ID_INTEL_APL_XHCI 0x5aa8
+#define PCI_DEVICE_ID_INTEL_DNV_XHCI 0x19d0
static const char hcd_name[] = "xhci_hcd";
@@ -167,12 +168,14 @@ static void xhci_pci_quirks(struct devic
pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_M_XHCI ||
pdev->device == PCI_DEVICE_ID_INTEL_BROXTON_B_XHCI ||
- pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI)) {
+ pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI)) {
xhci->quirks |= XHCI_PME_STUCK_QUIRK;
}
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
(pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
- pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI))
+ pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI ||
+ pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI))
xhci->quirks |= XHCI_MISSING_CAS;
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 054/103] usb: host: xhci-mem: allocate zeroed Scratchpad Buffer
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 053/103] xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 055/103] net: irda: irda-usb: fix firmware name on big-endian hosts Greg Kroah-Hartman
` (47 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Peter Chen, Mathias Nyman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Chen <peter.chen@nxp.com>
commit 7480d912d549f414e0ce39331870899e89a5598c upstream.
According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.
...
The following operations take place to allocate
Scratchpad Buffers to the xHC:
...
b. Software clears the Scratchpad Buffer to '0'
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1709,7 +1709,7 @@ static int scratchpad_alloc(struct xhci_
xhci->dcbaa->dev_context_ptrs[0] = cpu_to_le64(xhci->scratchpad->sp_dma);
for (i = 0; i < num_sp; i++) {
dma_addr_t dma;
- void *buf = dma_alloc_coherent(dev, xhci->page_size, &dma,
+ void *buf = dma_zalloc_coherent(dev, xhci->page_size, &dma,
flags);
if (!buf)
goto fail_sp5;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 055/103] net: irda: irda-usb: fix firmware name on big-endian hosts
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 054/103] usb: host: xhci-mem: allocate zeroed Scratchpad Buffer Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 056/103] [media] usbvision: fix NULL-deref at probe Greg Kroah-Hartman
` (46 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nick Fedchik, Johan Hovold, David S. Miller
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 75cf067953d5ee543b3bda90bbfcbee5e1f94ae8 upstream.
Add missing endianness conversion when using the USB device-descriptor
bcdDevice field to construct a firmware file name.
Fixes: 8ef80aef118e ("[IRDA]: irda-usb.c: STIR421x cleanups")
Cc: Nick Fedchik <nfedchik@atlantic-link.com.ua>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/irda/irda-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/irda/irda-usb.c
+++ b/drivers/net/irda/irda-usb.c
@@ -1077,7 +1077,7 @@ static int stir421x_patch_device(struct
* are "42101001.sb" or "42101002.sb"
*/
sprintf(stir421x_fw_name, "4210%4X.sb",
- self->usbdev->descriptor.bcdDevice);
+ le16_to_cpu(self->usbdev->descriptor.bcdDevice));
ret = request_firmware(&fw, stir421x_fw_name, &self->usbdev->dev);
if (ret < 0)
return ret;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 056/103] [media] usbvision: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 055/103] net: irda: irda-usb: fix firmware name on big-endian hosts Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 057/103] [media] mceusb: " Greg Kroah-Hartman
` (45 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thierry MERLE, Johan Hovold,
Hans Verkuil, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit eacb975b48272f54532b62f515a3cf7eefa35123 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: 2a9f8b5d25be ("V4L/DVB (5206): Usbvision: set alternate interface
modification")
Cc: Thierry MERLE <thierry.merle@free.fr>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/usbvision/usbvision-video.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -1523,7 +1523,14 @@ static int usbvision_probe(struct usb_in
}
for (i = 0; i < usbvision->num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].endpoint[1].desc.
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < 2) {
+ ret = -ENODEV;
+ goto err_pkt;
+ }
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[1].desc.
wMaxPacketSize);
usbvision->alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 057/103] [media] mceusb: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 056/103] [media] usbvision: fix NULL-deref at probe Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 058/103] [media] ttusb2: limit messages to buffer size Greg Kroah-Hartman
` (44 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johan Hovold, Sean Young,
Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 03eb2a557ed552e920a0942b774aaf931596eec1 upstream.
Make sure to check for the required out endpoint to avoid dereferencing
a NULL-pointer in mce_request_packet should a malicious device lack such
an endpoint. Note that this path is hit during probe.
Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/rc/mceusb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1321,8 +1321,8 @@ static int mceusb_dev_probe(struct usb_i
}
}
}
- if (ep_in == NULL) {
- dev_dbg(&intf->dev, "inbound and/or endpoint not found");
+ if (!ep_in || !ep_out) {
+ dev_dbg(&intf->dev, "required endpoints not found\n");
return -ENODEV;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 058/103] [media] ttusb2: limit messages to buffer size
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 057/103] [media] mceusb: " Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-06-02 10:28 ` Ben Hutchings
2017-05-23 20:09 ` [PATCH 4.4 059/103] usb: musb: tusb6010_omap: Do not reset the other directions packet size Greg Kroah-Hartman
` (43 subsequent siblings)
97 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alyssa Milburn, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alyssa Milburn <amilburn@zall.org>
commit a12b8ab8c5ff7ccd7b107a564743507c850a441d upstream.
Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and
heap buffers.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/ttusb2.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/drivers/media/usb/dvb-usb/ttusb2.c
+++ b/drivers/media/usb/dvb-usb/ttusb2.c
@@ -78,6 +78,9 @@ static int ttusb2_msg(struct dvb_usb_dev
u8 *s, *r = NULL;
int ret = 0;
+ if (4 + rlen > 64)
+ return -EIO;
+
s = kzalloc(wlen+4, GFP_KERNEL);
if (!s)
return -ENOMEM;
@@ -381,6 +384,22 @@ static int ttusb2_i2c_xfer(struct i2c_ad
write_read = i+1 < num && (msg[i+1].flags & I2C_M_RD);
read = msg[i].flags & I2C_M_RD;
+ if (3 + msg[i].len > sizeof(obuf)) {
+ err("i2c wr len=%d too high", msg[i].len);
+ break;
+ }
+ if (write_read) {
+ if (3 + msg[i+1].len > sizeof(ibuf)) {
+ err("i2c rd len=%d too high", msg[i+1].len);
+ break;
+ }
+ } else if (read) {
+ if (3 + msg[i].len > sizeof(ibuf)) {
+ err("i2c rd len=%d too high", msg[i].len);
+ break;
+ }
+ }
+
obuf[0] = (msg[i].addr << 1) | (write_read | read);
if (read)
obuf[1] = 0;
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 058/103] [media] ttusb2: limit messages to buffer size
2017-05-23 20:09 ` [PATCH 4.4 058/103] [media] ttusb2: limit messages to buffer size Greg Kroah-Hartman
@ 2017-06-02 10:28 ` Ben Hutchings
0 siblings, 0 replies; 121+ messages in thread
From: Ben Hutchings @ 2017-06-02 10:28 UTC (permalink / raw)
To: Alyssa Milburn, Mauro Carvalho Chehab; +Cc: linux-media
[Dropped cc to stable and LKML.]
On Tue, 2017-05-23 at 22:09 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Alyssa Milburn <amilburn@zall.org>
>
> commit a12b8ab8c5ff7ccd7b107a564743507c850a441d upstream.
>
> Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and
> heap buffers.
This function has another problem: it uses per-device mutexes to guard
access to static buffers. This only works as long as there's a single
device. It should be using per-device buffers (or a static mutex, but
that's less good).
Ben.
> Signed-off-by: Alyssa Milburn <amilburn@zall.org>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/media/usb/dvb-usb/ttusb2.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> --- a/drivers/media/usb/dvb-usb/ttusb2.c
> +++ b/drivers/media/usb/dvb-usb/ttusb2.c
> @@ -78,6 +78,9 @@ static int ttusb2_msg(struct dvb_usb_dev
> u8 *s, *r = NULL;
> int ret = 0;
>
> + if (4 + rlen > 64)
> + return -EIO;
> +
> s = kzalloc(wlen+4, GFP_KERNEL);
> if (!s)
> return -ENOMEM;
> @@ -381,6 +384,22 @@ static int ttusb2_i2c_xfer(struct i2c_ad
> write_read = i+1 < num && (msg[i+1].flags & I2C_M_RD);
> read = msg[i].flags & I2C_M_RD;
>
> + if (3 + msg[i].len > sizeof(obuf)) {
> + err("i2c wr len=%d too high", msg[i].len);
> + break;
> + }
> + if (write_read) {
> + if (3 + msg[i+1].len > sizeof(ibuf)) {
> + err("i2c rd len=%d too high", msg[i+1].len);
> + break;
> + }
> + } else if (read) {
> + if (3 + msg[i].len > sizeof(ibuf)) {
> + err("i2c rd len=%d too high", msg[i].len);
> + break;
> + }
> + }
> +
> obuf[0] = (msg[i].addr << 1) | (write_read | read);
> if (read)
> obuf[1] = 0;
>
>
>
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 059/103] usb: musb: tusb6010_omap: Do not reset the other directions packet size
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 058/103] [media] ttusb2: limit messages to buffer size Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 060/103] USB: iowarrior: fix info ioctl on big-endian hosts Greg Kroah-Hartman
` (42 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Ujfalusi, Tony Lindgren, Bin Liu
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
commit 6df2b42f7c040d57d9ecb67244e04e905ab87ac6 upstream.
We have one register for each EP to set the maximum packet size for both
TX and RX.
If for example an RX programming would happen before the previous TX
transfer finishes we would reset the TX packet side.
To fix this issue, only modify the TX or RX part of the register.
Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/musb/tusb6010_omap.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -220,6 +220,7 @@ static int tusb_omap_dma_program(struct
u32 dma_remaining;
int src_burst, dst_burst;
u16 csr;
+ u32 psize;
int ch;
s8 dmareq;
s8 sync_dev;
@@ -391,15 +392,19 @@ static int tusb_omap_dma_program(struct
if (chdat->tx) {
/* Send transfer_packet_sz packets at a time */
- musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET,
- chdat->transfer_packet_sz);
+ psize = musb_readl(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET);
+ psize &= ~0x7ff;
+ psize |= chdat->transfer_packet_sz;
+ musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET, psize);
musb_writel(ep_conf, TUSB_EP_TX_OFFSET,
TUSB_EP_CONFIG_XFR_SIZE(chdat->transfer_len));
} else {
/* Receive transfer_packet_sz packets at a time */
- musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET,
- chdat->transfer_packet_sz << 16);
+ psize = musb_readl(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET);
+ psize &= ~(0x7ff << 16);
+ psize |= (chdat->transfer_packet_sz << 16);
+ musb_writel(ep_conf, TUSB_EP_MAX_PACKET_SIZE_OFFSET, psize);
musb_writel(ep_conf, TUSB_EP_RX_OFFSET,
TUSB_EP_CONFIG_XFR_SIZE(chdat->transfer_len));
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 060/103] USB: iowarrior: fix info ioctl on big-endian hosts
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 059/103] usb: musb: tusb6010_omap: Do not reset the other directions packet size Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 061/103] usb: serial: option: add Telit ME910 support Greg Kroah-Hartman
` (41 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit dd5ca753fa92fb736b1395db892bd29f78e6d408 upstream.
Drop erroneous le16_to_cpu when returning the USB device speed which is
already in host byte order.
Found using sparse:
warning: cast to restricted __le16
Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/misc/iowarrior.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -557,7 +557,7 @@ static long iowarrior_ioctl(struct file
info.revision = le16_to_cpu(dev->udev->descriptor.bcdDevice);
/* 0==UNKNOWN, 1==LOW(usb1.1) ,2=FULL(usb1.1), 3=HIGH(usb2.0) */
- info.speed = le16_to_cpu(dev->udev->speed);
+ info.speed = dev->udev->speed;
info.if_num = dev->interface->cur_altsetting->desc.bInterfaceNumber;
info.report_size = dev->report_size;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 061/103] usb: serial: option: add Telit ME910 support
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 060/103] USB: iowarrior: fix info ioctl on big-endian hosts Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 063/103] USB: serial: mct_u232: fix big-endian baud-rate handling Greg Kroah-Hartman
` (40 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Daniele Palmas, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniele Palmas <dnlplm@gmail.com>
commit 40dd46048c155b8f0683f468c950a1c107f77a7c upstream.
This patch adds support for Telit ME910 PID 0x1100.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -281,6 +281,7 @@ static void option_instat_callback(struc
#define TELIT_PRODUCT_LE922_USBCFG0 0x1042
#define TELIT_PRODUCT_LE922_USBCFG3 0x1043
#define TELIT_PRODUCT_LE922_USBCFG5 0x1045
+#define TELIT_PRODUCT_ME910 0x1100
#define TELIT_PRODUCT_LE920 0x1200
#define TELIT_PRODUCT_LE910 0x1201
#define TELIT_PRODUCT_LE910_USBCFG4 0x1206
@@ -640,6 +641,11 @@ static const struct option_blacklist_inf
.reserved = BIT(5) | BIT(6),
};
+static const struct option_blacklist_info telit_me910_blacklist = {
+ .sendsetup = BIT(0),
+ .reserved = BIT(1) | BIT(3),
+};
+
static const struct option_blacklist_info telit_le910_blacklist = {
.sendsetup = BIT(0),
.reserved = BIT(1) | BIT(2),
@@ -1235,6 +1241,8 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg3 },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, TELIT_PRODUCT_LE922_USBCFG5, 0xff),
.driver_info = (kernel_ulong_t)&telit_le922_blacklist_usbcfg0 },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910),
+ .driver_info = (kernel_ulong_t)&telit_me910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910),
.driver_info = (kernel_ulong_t)&telit_le910_blacklist },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910_USBCFG4),
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 063/103] USB: serial: mct_u232: fix big-endian baud-rate handling
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 061/103] usb: serial: option: add Telit ME910 support Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 064/103] USB: serial: io_ti: fix div-by-zero in set_termios Greg Kroah-Hartman
` (39 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pete Zaitcev, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 26cede343656c0bc2c33cdc783771282405c7fb2 upstream.
Drop erroneous cpu_to_le32 when setting the baud rate, something which
corrupted the divisor on big-endian hosts.
Found using sparse:
warning: incorrect type in argument 1 (different base types)
expected unsigned int [unsigned] [usertype] val
got restricted __le32 [usertype] <noident>
Fixes: af2ac1a091bc ("USB: serial mct_usb232: move DMA buffers to heap")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-By: Pete Zaitcev <zaitcev@yahoo.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/mct_u232.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -189,7 +189,7 @@ static int mct_u232_set_baud_rate(struct
return -ENOMEM;
divisor = mct_u232_calculate_baud_rate(serial, value, &speed);
- put_unaligned_le32(cpu_to_le32(divisor), buf);
+ put_unaligned_le32(divisor, buf);
rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
MCT_U232_SET_BAUD_RATE_REQUEST,
MCT_U232_SET_REQUEST_TYPE,
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 064/103] USB: serial: io_ti: fix div-by-zero in set_termios
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 063/103] USB: serial: mct_u232: fix big-endian baud-rate handling Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 065/103] USB: hub: fix SS hub-descriptor handling Greg Kroah-Hartman
` (38 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 6aeb75e6adfaed16e58780309613a578fe1ee90b upstream.
Fix a division-by-zero in set_termios when debugging is enabled and a
high-enough speed has been requested so that the divisor value becomes
zero.
Instead of just fixing the offending debug statement, cap the baud rate
at the base as a zero divisor value also appears to crash the firmware.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/io_ti.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2349,8 +2349,11 @@ static void change_port_settings(struct
if (!baud) {
/* pick a default, any default... */
baud = 9600;
- } else
+ } else {
+ /* Avoid a zero divisor. */
+ baud = min(baud, 461550);
tty_encode_baud_rate(tty, baud, baud);
+ }
edge_port->baud_rate = baud;
config->wBaudRate = (__u16)((461550L + baud/2) / baud);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 065/103] USB: hub: fix SS hub-descriptor handling
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 064/103] USB: serial: io_ti: fix div-by-zero in set_termios Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 066/103] USB: hub: fix non-SS " Greg Kroah-Hartman
` (37 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, John Youn, Alan Stern, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 2c25a2c818023df64463aac3288a9f969491e507 upstream.
A SuperSpeed hub descriptor does not have any variable-length fields so
bail out when reading a short descriptor.
This avoids parsing and leaking two bytes of uninitialised slab data
through sysfs removable-attributes.
Fixes: dbe79bbe9dcb ("USB 3.0 Hub Changes")
Cc: John Youn <John.Youn@synopsys.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/hub.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -376,8 +376,12 @@ static int get_hub_descriptor(struct usb
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN | USB_RT_HUB,
dtype << 8, 0, data, size,
USB_CTRL_GET_TIMEOUT);
- if (ret >= (USB_DT_HUB_NONVAR_SIZE + 2))
+ if (hub_is_superspeed(hdev)) {
+ if (ret == size)
+ return ret;
+ } else if (ret >= (USB_DT_HUB_NONVAR_SIZE + 2)) {
return ret;
+ }
}
return -EINVAL;
}
@@ -1303,7 +1307,7 @@ static int hub_configure(struct usb_hub
/* Request the entire hub descriptor.
* hub->descriptor can handle USB_MAXCHILDREN ports,
- * but the hub can/will return fewer bytes here.
+ * but a (non-SS) hub can/will return fewer bytes here.
*/
ret = get_hub_descriptor(hdev, hub->descriptor);
if (ret < 0) {
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 066/103] USB: hub: fix non-SS hub-descriptor handling
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 065/103] USB: hub: fix SS hub-descriptor handling Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 067/103] tty: Prevent ldisc drivers from re-using stale tty fields Greg Kroah-Hartman
` (36 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold, Alan Stern
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit bec444cd1c94c48df409a35ad4e5b143c245c3f7 upstream.
Add missing sanity check on the non-SuperSpeed hub-descriptor length in
order to avoid parsing and leaking two bytes of uninitialised slab data
through sysfs removable-attributes (or a compound-device debug
statement).
Note that we only make sure that the DeviceRemovable field is always
present (and specifically ignore the unused PortPwrCtrlMask field) in
order to continue support any hubs with non-compliant descriptors. As a
further safeguard, the descriptor buffer is also cleared.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/hub.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -358,7 +358,8 @@ static void usb_set_lpm_parameters(struc
}
/* USB 2.0 spec Section 11.24.4.5 */
-static int get_hub_descriptor(struct usb_device *hdev, void *data)
+static int get_hub_descriptor(struct usb_device *hdev,
+ struct usb_hub_descriptor *desc)
{
int i, ret, size;
unsigned dtype;
@@ -374,12 +375,16 @@ static int get_hub_descriptor(struct usb
for (i = 0; i < 3; i++) {
ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN | USB_RT_HUB,
- dtype << 8, 0, data, size,
+ dtype << 8, 0, desc, size,
USB_CTRL_GET_TIMEOUT);
if (hub_is_superspeed(hdev)) {
if (ret == size)
return ret;
- } else if (ret >= (USB_DT_HUB_NONVAR_SIZE + 2)) {
+ } else if (ret >= USB_DT_HUB_NONVAR_SIZE + 2) {
+ /* Make sure we have the DeviceRemovable field. */
+ size = USB_DT_HUB_NONVAR_SIZE + desc->bNbrPorts / 8 + 1;
+ if (ret < size)
+ return -EMSGSIZE;
return ret;
}
}
@@ -1299,7 +1304,7 @@ static int hub_configure(struct usb_hub
}
mutex_init(&hub->status_mutex);
- hub->descriptor = kmalloc(sizeof(*hub->descriptor), GFP_KERNEL);
+ hub->descriptor = kzalloc(sizeof(*hub->descriptor), GFP_KERNEL);
if (!hub->descriptor) {
ret = -ENOMEM;
goto fail;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 067/103] tty: Prevent ldisc drivers from re-using stale tty fields
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 066/103] USB: hub: fix non-SS " Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 069/103] iio: proximity: as3935: fix as3935_write Greg Kroah-Hartman
` (35 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tilman Schmidt, Sasha Levin,
Peter Hurley, Amit Pundir
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Hurley <peter@hurleysoftware.com>
commit dd42bf1197144ede075a9d4793123f7689e164bc upstream.
Line discipline drivers may mistakenly misuse ldisc-related fields
when initializing. For example, a failure to initialize tty->receive_room
in the N_GIGASET_M101 line discipline was recently found and fixed [1].
Now, the N_X25 line discipline has been discovered accessing the previous
line discipline's already-freed private data [2].
Harden the ldisc interface against misuse by initializing revelant
tty fields before instancing the new line discipline.
[1]
commit fd98e9419d8d622a4de91f76b306af6aa627aa9c
Author: Tilman Schmidt <tilman@imap.cc>
Date: Tue Jul 14 00:37:13 2015 +0200
isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
[2] Report from Sasha Levin <sasha.levin@oracle.com>
[ 634.336761] ==================================================================
[ 634.338226] BUG: KASAN: use-after-free in x25_asy_open_tty+0x13d/0x490 at addr ffff8800a743efd0
[ 634.339558] Read of size 4 by task syzkaller_execu/8981
[ 634.340359] =============================================================================
[ 634.341598] BUG kmalloc-512 (Not tainted): kasan: bad access detected
...
[ 634.405018] Call Trace:
[ 634.405277] dump_stack (lib/dump_stack.c:52)
[ 634.405775] print_trailer (mm/slub.c:655)
[ 634.406361] object_err (mm/slub.c:662)
[ 634.406824] kasan_report_error (mm/kasan/report.c:138 mm/kasan/report.c:236)
[ 634.409581] __asan_report_load4_noabort (mm/kasan/report.c:279)
[ 634.411355] x25_asy_open_tty (drivers/net/wan/x25_asy.c:559 (discriminator 1))
[ 634.413997] tty_ldisc_open.isra.2 (drivers/tty/tty_ldisc.c:447)
[ 634.414549] tty_set_ldisc (drivers/tty/tty_ldisc.c:567)
[ 634.415057] tty_ioctl (drivers/tty/tty_io.c:2646 drivers/tty/tty_io.c:2879)
[ 634.423524] do_vfs_ioctl (fs/ioctl.c:43 fs/ioctl.c:607)
[ 634.427491] SyS_ioctl (fs/ioctl.c:622 fs/ioctl.c:613)
[ 634.427945] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:188)
Cc: Tilman Schmidt <tilman@imap.cc>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/tty_ldisc.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -421,6 +421,10 @@ EXPORT_SYMBOL_GPL(tty_ldisc_flush);
* prevent the ldisc driver from re-using stale information for
* the new ldisc instance.
*
+ * The line discipline-related tty_struct fields are reset to
+ * prevent the ldisc driver from re-using stale information for
+ * the new ldisc instance.
+ *
* Locking: takes termios_rwsem
*/
@@ -619,6 +623,9 @@ static void tty_reset_termios(struct tty
tty->termios.c_ispeed = tty_termios_input_baud_rate(&tty->termios);
tty->termios.c_ospeed = tty_termios_baud_rate(&tty->termios);
up_write(&tty->termios_rwsem);
+
+ tty->disc_data = NULL;
+ tty->receive_room = 0;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 069/103] iio: proximity: as3935: fix as3935_write
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 067/103] tty: Prevent ldisc drivers from re-using stale tty fields Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 071/103] [media] gspca: konica: add missing endpoint sanity check Greg Kroah-Hartman
` (34 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, George McCollister, Matt Ranostay,
Jonathan Cameron
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Ranostay <matt.ranostay@konsulko.com>
commit 84ca8e364acb26aba3292bc113ca8ed4335380fd upstream.
AS3935_WRITE_DATA macro bit is incorrect and the actual write
sequence is two leading zeros.
Cc: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/proximity/as3935.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/iio/proximity/as3935.c
+++ b/drivers/iio/proximity/as3935.c
@@ -50,7 +50,6 @@
#define AS3935_TUNE_CAP 0x08
#define AS3935_CALIBRATE 0x3D
-#define AS3935_WRITE_DATA BIT(15)
#define AS3935_READ_DATA BIT(14)
#define AS3935_ADDRESS(x) ((x) << 8)
@@ -105,7 +104,7 @@ static int as3935_write(struct as3935_st
{
u8 *buf = st->buf;
- buf[0] = (AS3935_WRITE_DATA | AS3935_ADDRESS(reg)) >> 8;
+ buf[0] = AS3935_ADDRESS(reg) >> 8;
buf[1] = val;
return spi_write(st->spi, buf, 2);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 071/103] [media] gspca: konica: add missing endpoint sanity check
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 069/103] iio: proximity: as3935: fix as3935_write Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 072/103] [media] s5p-mfc: Fix unbalanced call to clock management Greg Kroah-Hartman
` (33 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Johan Hovold,
Hans Verkuil, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit aa58fedb8c7b6cf2f05941d238495f9e2f29655c upstream.
Make sure to check the number of endpoints to avoid accessing memory
beyond the endpoint array should a device lack the expected endpoints.
Note that, as far as I can tell, the gspca framework has already made
sure there is at least one endpoint in the current alternate setting so
there should be no risk for a NULL-pointer dereference here.
Fixes: b517af722860 ("V4L/DVB: gspca_konica: New gspca subdriver for
konica chipset using cams")
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/gspca/konica.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/usb/gspca/konica.c
+++ b/drivers/media/usb/gspca/konica.c
@@ -188,6 +188,9 @@ static int sd_start(struct gspca_dev *gs
return -EIO;
}
+ if (alt->desc.bNumEndpoints < 2)
+ return -ENODEV;
+
packet_size = le16_to_cpu(alt->endpoint[0].desc.wMaxPacketSize);
n = gspca_dev->cam.cam_mode[gspca_dev->curr_mode].priv;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 072/103] [media] s5p-mfc: Fix unbalanced call to clock management
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 071/103] [media] gspca: konica: add missing endpoint sanity check Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 073/103] [media] dib0700: fix NULL-deref at probe Greg Kroah-Hartman
` (32 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marek Szyprowski, Sylwester Nawrocki,
Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <m.szyprowski@samsung.com>
commit a5cb00eb4223458250b55daf03ac7ea5f424d601 upstream.
Clock should be turned off after calling s5p_mfc_init_hw() from the
watchdog worker, like it is already done in the s5p_mfc_open() which also
calls this function.
Fixes: af93574678108 ("[media] MFC: Add MFC 5.1 V4L2 driver")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -173,6 +173,7 @@ static void s5p_mfc_watchdog_worker(stru
}
s5p_mfc_clock_on();
ret = s5p_mfc_init_hw(dev);
+ s5p_mfc_clock_off();
if (ret)
mfc_err("Failed to reinit FW\n");
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 073/103] [media] dib0700: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 072/103] [media] s5p-mfc: Fix unbalanced call to clock management Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 074/103] [media] zr364xx: enforce minimum size when reading header Greg Kroah-Hartman
` (31 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mauro Carvalho Chehab, Johan Hovold,
Hans Verkuil, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit d5823511c0f8719a39e72ede1bce65411ac653b7 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: c4018fa2e4c0 ("[media] dib0700: fix RC support on Hauppauge
Nova-TD")
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/dvb-usb/dib0700_core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -783,6 +783,9 @@ int dib0700_rc_setup(struct dvb_usb_devi
/* Starting in firmware 1.20, the RC info is provided on a bulk pipe */
+ if (intf->altsetting[0].desc.bNumEndpoints < rc_ep + 1)
+ return -ENODEV;
+
purb = usb_alloc_urb(0, GFP_KERNEL);
if (purb == NULL) {
err("rc usb alloc urb failed");
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 074/103] [media] zr364xx: enforce minimum size when reading header
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 073/103] [media] dib0700: fix NULL-deref at probe Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 075/103] [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops Greg Kroah-Hartman
` (30 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alyssa Milburn, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alyssa Milburn <amilburn@zall.org>
commit ee0fe833d96793853335844b6d99fb76bd12cbeb upstream.
This code copies actual_length-128 bytes from the header, which will
underflow if the received buffer is too small.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/zr364xx/zr364xx.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -604,6 +604,14 @@ static int zr364xx_read_video_callback(s
ptr = pdest = frm->lpvbits;
if (frm->ulState == ZR364XX_READ_IDLE) {
+ if (purb->actual_length < 128) {
+ /* header incomplete */
+ dev_info(&cam->udev->dev,
+ "%s: buffer (%d bytes) too small to hold jpeg header. Discarding.\n",
+ __func__, purb->actual_length);
+ return -EINVAL;
+ }
+
frm->ulState = ZR364XX_READ_FRAME;
frm->cur_size = 0;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 075/103] [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 074/103] [media] zr364xx: enforce minimum size when reading header Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-06-02 11:34 ` Ben Hutchings
2017-05-23 20:09 ` [PATCH 4.4 076/103] [media] cx231xx-audio: fix init error path Greg Kroah-Hartman
` (29 subsequent siblings)
97 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Scheller, Abylay Ospan,
Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Scheller <d.scheller@gmx.net>
commit 158f0328af86a99d64073851967a02694bff987d upstream.
Fixes "w_scan -f c" complaining with
This dvb driver is *buggy*: the symbol rate limits are undefined - please
report to linuxtv.org)
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Acked-by: Abylay Ospan <aospan@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/dvb-frontends/cxd2841er.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -2678,7 +2678,9 @@ static struct dvb_frontend_ops cxd2841e
FE_CAN_MUTE_TS |
FE_CAN_2G_MODULATION,
.frequency_min = 42000000,
- .frequency_max = 1002000000
+ .frequency_max = 1002000000,
+ .symbol_rate_min = 870000,
+ .symbol_rate_max = 11700000
},
.init = cxd2841er_init_tc,
.sleep = cxd2841er_sleep_tc,
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 075/103] [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops
2017-05-23 20:09 ` [PATCH 4.4 075/103] [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops Greg Kroah-Hartman
@ 2017-06-02 11:34 ` Ben Hutchings
0 siblings, 0 replies; 121+ messages in thread
From: Ben Hutchings @ 2017-06-02 11:34 UTC (permalink / raw)
To: Daniel Scheller, Abylay Ospan, Mauro Carvalho Chehab
Cc: linux-kernel, stable, Greg Kroah-Hartman
On Tue, 2017-05-23 at 22:09 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Daniel Scheller <d.scheller@gmx.net>
>
> commit 158f0328af86a99d64073851967a02694bff987d upstream.
>
> Fixes "w_scan -f c" complaining with
>
> This dvb driver is *buggy*: the symbol rate limits are undefined - please
> report to linuxtv.org)
>
> Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
> Acked-by: Abylay Ospan <aospan@netup.ru>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In 4.4 this driver had two separate ops structures for DVB-T and DVB-C,
and this is only updating the DVB-C ops. I think this needs a second
patch to cover DVB-T.
Ben.
> ---
> drivers/media/dvb-frontends/cxd2841er.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -2678,7 +2678,9 @@ static struct dvb_frontend_ops cxd2841e
> FE_CAN_MUTE_TS |
> FE_CAN_2G_MODULATION,
> .frequency_min = 42000000,
> - .frequency_max = 1002000000
> + .frequency_max = 1002000000,
> + .symbol_rate_min = 870000,
> + .symbol_rate_max = 11700000
> },
> .init = cxd2841er_init_tc,
> .sleep = cxd2841er_sleep_tc,
>
>
>
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 076/103] [media] cx231xx-audio: fix init error path
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 075/103] [media] dvb-frontends/cxd2841er: define symbol_rate_min/max in T/C fe-ops Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 077/103] [media] cx231xx-audio: fix NULL-deref at probe Greg Kroah-Hartman
` (28 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sri Deevi, Johan Hovold,
Hans Verkuil, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit fff1abc4d54e469140a699612b4db8d6397bfcba upstream.
Make sure to release the snd_card also on a late allocation error.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-audio.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-audio.c
+++ b/drivers/media/usb/cx231xx/cx231xx-audio.c
@@ -671,10 +671,8 @@ static int cx231xx_audio_init(struct cx2
spin_lock_init(&adev->slock);
err = snd_pcm_new(card, "Cx231xx Audio", 0, 0, 1, &pcm);
- if (err < 0) {
- snd_card_free(card);
- return err;
- }
+ if (err < 0)
+ goto err_free_card;
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE,
&snd_cx231xx_pcm_capture);
@@ -688,10 +686,9 @@ static int cx231xx_audio_init(struct cx2
INIT_WORK(&dev->wq_trigger, audio_trigger);
err = snd_card_register(card);
- if (err < 0) {
- snd_card_free(card);
- return err;
- }
+ if (err < 0)
+ goto err_free_card;
+
adev->sndcard = card;
adev->udev = dev->udev;
@@ -710,9 +707,10 @@ static int cx231xx_audio_init(struct cx2
"audio EndPoint Addr 0x%x, Alternate settings: %i\n",
adev->end_point_addr, adev->num_alt);
adev->alt_max_pkt_size = kmalloc(32 * adev->num_alt, GFP_KERNEL);
-
- if (adev->alt_max_pkt_size == NULL)
- return -ENOMEM;
+ if (!adev->alt_max_pkt_size) {
+ err = -ENOMEM;
+ goto err_free_card;
+ }
for (i = 0; i < adev->num_alt; i++) {
u16 tmp =
@@ -726,6 +724,11 @@ static int cx231xx_audio_init(struct cx2
}
return 0;
+
+err_free_card:
+ snd_card_free(card);
+
+ return err;
}
static int cx231xx_audio_fini(struct cx231xx *dev)
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 077/103] [media] cx231xx-audio: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 076/103] [media] cx231xx-audio: fix init error path Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 078/103] [media] cx231xx-cards: " Greg Kroah-Hartman
` (27 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sri Deevi, Johan Hovold,
Hans Verkuil, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 65f921647f4c89a2068478c89691f39b309b58f7 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-audio.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-audio.c
+++ b/drivers/media/usb/cx231xx/cx231xx-audio.c
@@ -698,6 +698,11 @@ static int cx231xx_audio_init(struct cx2
hs_config_info[0].interface_info.
audio_index + 1];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1) {
+ err = -ENODEV;
+ goto err_free_card;
+ }
+
adev->end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].desc.
bEndpointAddress;
@@ -713,8 +718,14 @@ static int cx231xx_audio_init(struct cx2
}
for (i = 0; i < adev->num_alt; i++) {
- u16 tmp =
- le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1) {
+ err = -ENODEV;
+ goto err_free_pkt_size;
+ }
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.
wMaxPacketSize);
adev->alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
@@ -725,6 +736,8 @@ static int cx231xx_audio_init(struct cx2
return 0;
+err_free_pkt_size:
+ kfree(adev->alt_max_pkt_size);
err_free_card:
snd_card_free(card);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 078/103] [media] cx231xx-cards: fix NULL-deref at probe
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 077/103] [media] cx231xx-audio: fix NULL-deref at probe Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 079/103] powerpc/book3s/mce: Move add_taint() later in virtual mode Greg Kroah-Hartman
` (26 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sri Deevi, Johan Hovold,
Hans Verkuil, Mauro Carvalho Chehab
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 0cd273bb5e4d1828efaaa8dfd11b7928131ed149 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 45 ++++++++++++++++++++++++++----
1 file changed, 40 insertions(+), 5 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -1447,6 +1447,9 @@ static int cx231xx_init_v4l2(struct cx23
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
dev->video_mode.end_point_addr = uif->altsetting[0].endpoint[isoc_pipe].desc.bEndpointAddress;
dev->video_mode.num_alt = uif->num_altsetting;
@@ -1460,7 +1463,12 @@ static int cx231xx_init_v4l2(struct cx23
return -ENOMEM;
for (i = 0; i < dev->video_mode.num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.wMaxPacketSize);
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].desc.wMaxPacketSize);
dev->video_mode.alt_max_pkt_size[i] = (tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
dev_dbg(dev->dev,
"Alternate setting %i, max size= %i\n", i,
@@ -1477,6 +1485,9 @@ static int cx231xx_init_v4l2(struct cx23
}
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
dev->vbi_mode.end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].desc.
bEndpointAddress;
@@ -1493,8 +1504,12 @@ static int cx231xx_init_v4l2(struct cx23
return -ENOMEM;
for (i = 0; i < dev->vbi_mode.num_alt; i++) {
- u16 tmp =
- le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
desc.wMaxPacketSize);
dev->vbi_mode.alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
@@ -1514,6 +1529,9 @@ static int cx231xx_init_v4l2(struct cx23
}
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
dev->sliced_cc_mode.end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].desc.
bEndpointAddress;
@@ -1528,7 +1546,12 @@ static int cx231xx_init_v4l2(struct cx23
return -ENOMEM;
for (i = 0; i < dev->sliced_cc_mode.num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1)
+ return -ENODEV;
+
+ tmp = le16_to_cpu(uif->altsetting[i].endpoint[isoc_pipe].
desc.wMaxPacketSize);
dev->sliced_cc_mode.alt_max_pkt_size[i] =
(tmp & 0x07ff) * (((tmp & 0x1800) >> 11) + 1);
@@ -1693,6 +1716,11 @@ static int cx231xx_usb_probe(struct usb_
}
uif = udev->actconfig->interface[idx];
+ if (uif->altsetting[0].desc.bNumEndpoints < isoc_pipe + 1) {
+ retval = -ENODEV;
+ goto err_video_alt;
+ }
+
dev->ts1_mode.end_point_addr =
uif->altsetting[0].endpoint[isoc_pipe].
desc.bEndpointAddress;
@@ -1710,7 +1738,14 @@ static int cx231xx_usb_probe(struct usb_
}
for (i = 0; i < dev->ts1_mode.num_alt; i++) {
- u16 tmp = le16_to_cpu(uif->altsetting[i].
+ u16 tmp;
+
+ if (uif->altsetting[i].desc.bNumEndpoints < isoc_pipe + 1) {
+ retval = -ENODEV;
+ goto err_video_alt;
+ }
+
+ tmp = le16_to_cpu(uif->altsetting[i].
endpoint[isoc_pipe].desc.
wMaxPacketSize);
dev->ts1_mode.alt_max_pkt_size[i] =
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 079/103] powerpc/book3s/mce: Move add_taint() later in virtual mode
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 078/103] [media] cx231xx-cards: " Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 080/103] powerpc/pseries: Fix of_node_put() underflow during DLPAR remove Greg Kroah-Hartman
` (25 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mahesh Salgaonkar, Michael Ellerman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
commit d93b0ac01a9ce276ec39644be47001873d3d183c upstream.
machine_check_early() gets called in real mode. The very first time when
add_taint() is called, it prints a warning which ends up calling opal
call (that uses OPAL_CALL wrapper) for writing it to console. If we get a
very first machine check while we are in opal we are doomed. OPAL_CALL
overwrites the PACASAVEDMSR in r13 and in this case when we are done with
MCE handling the original opal call will use this new MSR on it's way
back to opal_return. This usually leads to unexpected behaviour or the
kernel to panic. Instead move the add_taint() call later in the virtual
mode where it is safe to call.
This is broken with current FW level. We got lucky so far for not getting
very first MCE hit while in OPAL. But easily reproducible on Mambo.
Fixes: 27ea2c420cad ("powerpc: Set the correct kernel taint on machine check errors.")
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/mce.c | 2 ++
arch/powerpc/kernel/traps.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -204,6 +204,8 @@ static void machine_check_process_queued
{
int index;
+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
+
/*
* For now just print it to console.
* TODO: log this error event to FSP or nvram.
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -297,8 +297,6 @@ long machine_check_early(struct pt_regs
__this_cpu_inc(irq_stat.mce_exceptions);
- add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
-
if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
handled = cur_cpu_spec->machine_check_early(regs);
return handled;
@@ -704,6 +702,8 @@ void machine_check_exception(struct pt_r
__this_cpu_inc(irq_stat.mce_exceptions);
+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
+
/* See if any machine dependent calls. In theory, we would want
* to call the CPU first, and call the ppc_md. one if the CPU
* one returns a positive number. However there is existing code
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 080/103] powerpc/pseries: Fix of_node_put() underflow during DLPAR remove
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 079/103] powerpc/book3s/mce: Move add_taint() later in virtual mode Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 081/103] powerpc/64e: Fix hang when debugging programs with relocated kernel Greg Kroah-Hartman
` (24 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tyrel Datwyler, Michael Ellerman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
commit 68baf692c435339e6295cb470ea5545cbc28160e upstream.
Historically struct device_node references were tracked using a kref embedded as
a struct field. Commit 75b57ecf9d1d ("of: Make device nodes kobjects so they
show up in sysfs") (Mar 2014) refactored device_nodes to be kobjects such that
the device tree could by more simply exposed to userspace using sysfs.
Commit 0829f6d1f69e ("of: device_node kobject lifecycle fixes") (Mar 2014)
followed up these changes to better control the kobject lifecycle and in
particular the referecne counting via of_node_get(), of_node_put(), and
of_node_init().
A result of this second commit was that it introduced an of_node_put() call when
a dynamic node is detached, in of_node_remove(), that removes the initial kobj
reference created by of_node_init().
Traditionally as the original dynamic device node user the pseries code had
assumed responsibilty for releasing this final reference in its platform
specific DLPAR detach code.
This patch fixes a refcount underflow introduced by commit 0829f6d1f6, and
recently exposed by the upstreaming of the recount API.
Messages like the following are no longer seen in the kernel log with this
patch following DLPAR remove operations of cpus and pci devices.
rpadlpar_io: slot PHB 72 removed
refcount_t: underflow; use-after-free.
------------[ cut here ]------------
WARNING: CPU: 5 PID: 3335 at lib/refcount.c:128 refcount_sub_and_test+0xf4/0x110
Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
[mpe: Make change log commit references more verbose]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/pseries/dlpar.c | 1 -
1 file changed, 1 deletion(-)
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -280,7 +280,6 @@ int dlpar_detach_node(struct device_node
if (rc)
return rc;
- of_node_put(dn); /* Must decrement the refcount */
return 0;
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 081/103] powerpc/64e: Fix hang when debugging programs with relocated kernel
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 080/103] powerpc/pseries: Fix of_node_put() underflow during DLPAR remove Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 082/103] ARM: dts: at91: sama5d3_xplained: fix ADC vref Greg Kroah-Hartman
` (23 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liu Hailong, Jiang Xuexin,
Jiang Biao, Liu Song, Huang Jian, Scott Wood
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: LiuHailong <liu.hailong6@zte.com.cn>
commit fd615f69a18a9d4aa5ef02a1dc83f319f75da8e7 upstream.
Debug interrupts can be taken during interrupt entry, since interrupt
entry does not automatically turn them off. The kernel will check
whether the faulting instruction is between [interrupt_base_book3e,
__end_interrupts], and if so clear MSR[DE] and return.
However, when the kernel is built with CONFIG_RELOCATABLE, it can't use
LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) and
LOAD_REG_IMMEDIATE(r15,__end_interrupts), as they ignore relocation.
Thus, if the kernel is actually running at a different address than it
was built at, the address comparison will fail, and the exception entry
code will hang at kernel_dbg_exc.
r2(toc) is also not usable here, as r2 still holds data from the
interrupted context, so LOAD_REG_ADDR() doesn't work either. So we use
the *name@got* to get the EV of two labels directly.
Test programs test.c shows as follows:
int main(int argc, char *argv[])
{
if (access("/proc/sys/kernel/perf_event_paranoid", F_OK) == -1)
printf("Kernel doesn't have perf_event support\n");
}
Steps to reproduce the bug, for example:
1) ./gdb ./test
2) (gdb) b access
3) (gdb) r
4) (gdb) s
Signed-off-by: Liu Hailong <liu.hailong6@zte.com.cn>
Signed-off-by: Jiang Xuexin <jiang.xuexin@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Reviewed-by: Liu Song <liu.song11@zte.com.cn>
Reviewed-by: Huang Jian <huang.jian@zte.com.cn>
[scottwood: cleaned up commit message, and specified bad behavior
as a hang rather than an oops to correspond to mainline kernel behavior]
Fixes: 1cb6e0649248 ("powerpc/book3e: support CONFIG_RELOCATABLE")
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64e.S | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -735,8 +735,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
andis. r15,r14,(DBSR_IC|DBSR_BT)@h
beq+ 1f
+#ifdef CONFIG_RELOCATABLE
+ ld r15,PACATOC(r13)
+ ld r14,interrupt_base_book3e@got(r15)
+ ld r15,__end_interrupts@got(r15)
+#else
LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
LOAD_REG_IMMEDIATE(r15,__end_interrupts)
+#endif
cmpld cr0,r10,r14
cmpld cr1,r10,r15
blt+ cr0,1f
@@ -799,8 +805,14 @@ kernel_dbg_exc:
andis. r15,r14,(DBSR_IC|DBSR_BT)@h
beq+ 1f
+#ifdef CONFIG_RELOCATABLE
+ ld r15,PACATOC(r13)
+ ld r14,interrupt_base_book3e@got(r15)
+ ld r15,__end_interrupts@got(r15)
+#else
LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
LOAD_REG_IMMEDIATE(r15,__end_interrupts)
+#endif
cmpld cr0,r10,r14
cmpld cr1,r10,r15
blt+ cr0,1f
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 082/103] ARM: dts: at91: sama5d3_xplained: fix ADC vref
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (73 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 081/103] powerpc/64e: Fix hang when debugging programs with relocated kernel Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 083/103] ARM: dts: at91: sama5d3_xplained: not all ADC channels are available Greg Kroah-Hartman
` (22 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ludovic Desroches, Nicolas Ferre,
Alexandre Belloni
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <ludovic.desroches@microchip.com>
commit 9cdd31e5913c1f86dce7e201b086155b3f24896b upstream.
The voltage reference for the ADC is not 3V but 3.3V since it is connected to
VDDANA.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -162,6 +162,7 @@
};
adc0: adc@f8018000 {
+ atmel,adc-vref = <3300>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
&pinctrl_adc0_ad0
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 083/103] ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 082/103] ARM: dts: at91: sama5d3_xplained: fix ADC vref Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 084/103] arm64: xchg: hazard against entire exchange variable Greg Kroah-Hartman
` (21 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ludovic Desroches, Nicolas Ferre,
Alexandre Belloni
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ludovic Desroches <ludovic.desroches@microchip.com>
commit d3df1ec06353e51fc44563d2e7e18d42811af290 upstream.
Remove ADC channels that are not available by default on the sama5d3_xplained
board (resistor not populated) in order to not create confusion.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -163,9 +163,9 @@
adc0: adc@f8018000 {
atmel,adc-vref = <3300>;
+ atmel,adc-channels-used = <0xfe>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
- &pinctrl_adc0_ad0
&pinctrl_adc0_ad1
&pinctrl_adc0_ad2
&pinctrl_adc0_ad3
@@ -173,8 +173,6 @@
&pinctrl_adc0_ad5
&pinctrl_adc0_ad6
&pinctrl_adc0_ad7
- &pinctrl_adc0_ad8
- &pinctrl_adc0_ad9
>;
status = "okay";
};
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 084/103] arm64: xchg: hazard against entire exchange variable
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 083/103] ARM: dts: at91: sama5d3_xplained: not all ADC channels are available Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 085/103] arm64: uaccess: ensure extension of access_ok() addr Greg Kroah-Hartman
` (20 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Mark Rutland, Catalin Marinas
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <mark.rutland@arm.com>
commit fee960bed5e857eb126c4e56dd9ff85938356579 upstream.
The inline assembly in __XCHG_CASE() uses a +Q constraint to hazard
against other accesses to the memory location being exchanged. However,
the pointer passed to the constraint is a u8 pointer, and thus the
hazard only applies to the first byte of the location.
GCC can take advantage of this, assuming that other portions of the
location are unchanged, as demonstrated with the following test case:
union u {
unsigned long l;
unsigned int i[2];
};
unsigned long update_char_hazard(union u *u)
{
unsigned int a, b;
a = u->i[1];
asm ("str %1, %0" : "+Q" (*(char *)&u->l) : "r" (0UL));
b = u->i[1];
return a ^ b;
}
unsigned long update_long_hazard(union u *u)
{
unsigned int a, b;
a = u->i[1];
asm ("str %1, %0" : "+Q" (*(long *)&u->l) : "r" (0UL));
b = u->i[1];
return a ^ b;
}
The linaro 15.08 GCC 5.1.1 toolchain compiles the above as follows when
using -O2 or above:
0000000000000000 <update_char_hazard>:
0: d2800001 mov x1, #0x0 // #0
4: f9000001 str x1, [x0]
8: d2800000 mov x0, #0x0 // #0
c: d65f03c0 ret
0000000000000010 <update_long_hazard>:
10: b9400401 ldr w1, [x0,#4]
14: d2800002 mov x2, #0x0 // #0
18: f9000002 str x2, [x0]
1c: b9400400 ldr w0, [x0,#4]
20: 4a000020 eor w0, w1, w0
24: d65f03c0 ret
This patch fixes the issue by passing an unsigned long pointer into the
+Q constraint, as we do for our cmpxchg code. This may hazard against
more than is necessary, but this is better than missing a necessary
hazard.
Fixes: 305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release} atomics")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/cmpxchg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/include/asm/cmpxchg.h
+++ b/arch/arm64/include/asm/cmpxchg.h
@@ -49,7 +49,7 @@ static inline unsigned long __xchg_case_
" swp" #acq_lse #rel #sz "\t%" #w "3, %" #w "0, %2\n" \
" nop\n" \
" " #nop_lse) \
- : "=&r" (ret), "=&r" (tmp), "+Q" (*(u8 *)ptr) \
+ : "=&r" (ret), "=&r" (tmp), "+Q" (*(unsigned long *)ptr) \
: "r" (x) \
: cl); \
\
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 085/103] arm64: uaccess: ensure extension of access_ok() addr
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (76 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 084/103] arm64: xchg: hazard against entire exchange variable Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 086/103] arm64: documentation: document tagged pointer stack constraints Greg Kroah-Hartman
` (19 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Mark Rutland, Catalin Marinas
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <mark.rutland@arm.com>
commit a06040d7a791a9177581dcf7293941bd92400856 upstream.
Our access_ok() simply hands its arguments over to __range_ok(), which
implicitly assummes that the addr parameter is 64 bits wide. This isn't
necessarily true for compat code, which might pass down a 32-bit address
parameter.
In these cases, we don't have a guarantee that the address has been zero
extended to 64 bits, and the upper bits of the register may contain
unknown values, potentially resulting in a suprious failure.
Avoid this by explicitly casting the addr parameter to an unsigned long
(as is done on other architectures), ensuring that the parameter is
widened appropriately.
Fixes: 0aea86a2176c ("arm64: User access library functions")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -92,11 +92,12 @@ static inline void set_fs(mm_segment_t f
*/
#define __range_ok(addr, size) \
({ \
+ unsigned long __addr = (unsigned long __force)(addr); \
unsigned long flag, roksum; \
__chk_user_ptr(addr); \
asm("adds %1, %1, %3; ccmp %1, %4, #2, cc; cset %0, ls" \
: "=&r" (flag), "=&r" (roksum) \
- : "1" (addr), "Ir" (size), \
+ : "1" (__addr), "Ir" (size), \
"r" (current_thread_info()->addr_limit) \
: "cc"); \
flag; \
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 086/103] arm64: documentation: document tagged pointer stack constraints
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (77 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 085/103] arm64: uaccess: ensure extension of access_ok() addr Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 087/103] xc2028: Fix use-after-free bug properly Greg Kroah-Hartman
` (18 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Martin, Will Deacon,
Kristina Martsenko, Catalin Marinas
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit f0e421b1bf7af97f026e1bb8bfe4c5a7a8c08f42 upstream.
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/arm64/tagged-pointers.txt | 66 +++++++++++++++++++++++---------
1 file changed, 49 insertions(+), 17 deletions(-)
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -11,24 +11,56 @@ in AArch64 Linux.
The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
-this byte for application use, with the following caveats:
+this byte for application use.
- (1) The kernel requires that all user addresses passed to EL1
- are tagged with tag 0x00. This means that any syscall
- parameters containing user virtual addresses *must* have
- their top byte cleared before trapping to the kernel.
-
- (2) Non-zero tags are not preserved when delivering signals.
- This means that signal handlers in applications making use
- of tags cannot rely on the tag information for user virtual
- addresses being maintained for fields inside siginfo_t.
- One exception to this rule is for signals raised in response
- to watchpoint debug exceptions, where the tag information
- will be preserved.
-
- (3) Special care should be taken when using tagged pointers,
- since it is likely that C compilers will not hazard two
- virtual addresses differing only in the upper byte.
+
+Passing tagged addresses to the kernel
+--------------------------------------
+
+All interpretation of userspace memory addresses by the kernel assumes
+an address tag of 0x00.
+
+This includes, but is not limited to, addresses found in:
+
+ - pointer arguments to system calls, including pointers in structures
+ passed to system calls,
+
+ - the stack pointer (sp), e.g. when interpreting it to deliver a
+ signal,
+
+ - the frame pointer (x29) and frame records, e.g. when interpreting
+ them to generate a backtrace or call graph.
+
+Using non-zero address tags in any of these locations may result in an
+error code being returned, a (fatal) signal being raised, or other modes
+of failure.
+
+For these reasons, passing non-zero address tags to the kernel via
+system calls is forbidden, and using a non-zero address tag for sp is
+strongly discouraged.
+
+Programs maintaining a frame pointer and frame records that use non-zero
+address tags may suffer impaired or inaccurate debug and profiling
+visibility.
+
+
+Preserving tags
+---------------
+
+Non-zero tags are not preserved when delivering signals. This means that
+signal handlers in applications making use of tags cannot rely on the
+tag information for user virtual addresses being maintained for fields
+inside siginfo_t. One exception to this rule is for signals raised in
+response to watchpoint debug exceptions, where the tag information will
+be preserved.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
+
+
+Other considerations
+--------------------
+
+Special care should be taken when using tagged pointers, since it is
+likely that C compilers will not hazard two virtual addresses differing
+only in the upper byte.
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 087/103] xc2028: Fix use-after-free bug properly
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (78 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 086/103] arm64: documentation: document tagged pointer stack constraints Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 088/103] mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp Greg Kroah-Hartman
` (17 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Takashi Iwai, Mauro Carvalho Chehab,
Amit Pundir
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 22a1e7783e173ab3d86018eb590107d68df46c11 upstream.
The commit 8dfbcc4351a0 ("[media] xc2028: avoid use after free") tried
to address the reported use-after-free by clearing the reference.
However, it's clearing the wrong pointer; it sets NULL to
priv->ctrl.fname, but it's anyway overwritten by the next line
memcpy(&priv->ctrl, p, sizeof(priv->ctrl)).
OTOH, the actual code accessing the freed string is the strcmp() call
with priv->fname:
if (!firmware_name[0] && p->fname &&
priv->fname && strcmp(p->fname, priv->fname))
free_firmware(priv);
where priv->fname points to the previous file name, and this was
already freed by kfree().
For fixing the bug properly, this patch does the following:
- Keep the copy of firmware file name in only priv->fname,
priv->ctrl.fname isn't changed;
- The allocation is done only when the firmware gets loaded;
- The kfree() is called in free_firmware() commonly
Fixes: commit 8dfbcc4351a0 ('[media] xc2028: avoid use after free')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/tuners/tuner-xc2028.c | 37 +++++++++++++++---------------------
1 file changed, 16 insertions(+), 21 deletions(-)
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -281,6 +281,14 @@ static void free_firmware(struct xc2028_
int i;
tuner_dbg("%s called\n", __func__);
+ /* free allocated f/w string */
+ if (priv->fname != firmware_name)
+ kfree(priv->fname);
+ priv->fname = NULL;
+
+ priv->state = XC2028_NO_FIRMWARE;
+ memset(&priv->cur_fw, 0, sizeof(priv->cur_fw));
+
if (!priv->firm)
return;
@@ -291,9 +299,6 @@ static void free_firmware(struct xc2028_
priv->firm = NULL;
priv->firm_size = 0;
- priv->state = XC2028_NO_FIRMWARE;
-
- memset(&priv->cur_fw, 0, sizeof(priv->cur_fw));
}
static int load_all_firmwares(struct dvb_frontend *fe,
@@ -884,9 +889,8 @@ read_not_reliable:
return 0;
fail:
- priv->state = XC2028_NO_FIRMWARE;
+ free_firmware(priv);
- memset(&priv->cur_fw, 0, sizeof(priv->cur_fw));
if (retry_count < 8) {
msleep(50);
retry_count++;
@@ -1332,11 +1336,8 @@ static int xc2028_dvb_release(struct dvb
mutex_lock(&xc2028_list_mutex);
/* only perform final cleanup if this is the last instance */
- if (hybrid_tuner_report_instance_count(priv) == 1) {
+ if (hybrid_tuner_report_instance_count(priv) == 1)
free_firmware(priv);
- kfree(priv->ctrl.fname);
- priv->ctrl.fname = NULL;
- }
if (priv)
hybrid_tuner_release_state(priv);
@@ -1399,19 +1400,8 @@ static int xc2028_set_config(struct dvb_
/*
* Copy the config data.
- * For the firmware name, keep a local copy of the string,
- * in order to avoid troubles during device release.
*/
- kfree(priv->ctrl.fname);
- priv->ctrl.fname = NULL;
memcpy(&priv->ctrl, p, sizeof(priv->ctrl));
- if (p->fname) {
- priv->ctrl.fname = kstrdup(p->fname, GFP_KERNEL);
- if (priv->ctrl.fname == NULL) {
- rc = -ENOMEM;
- goto unlock;
- }
- }
/*
* If firmware name changed, frees firmware. As free_firmware will
@@ -1426,10 +1416,15 @@ static int xc2028_set_config(struct dvb_
if (priv->state == XC2028_NO_FIRMWARE) {
if (!firmware_name[0])
- priv->fname = priv->ctrl.fname;
+ priv->fname = kstrdup(p->fname, GFP_KERNEL);
else
priv->fname = firmware_name;
+ if (!priv->fname) {
+ rc = -ENOMEM;
+ goto unlock;
+ }
+
rc = request_firmware_nowait(THIS_MODULE, 1,
priv->fname,
priv->i2c_props.adap->dev.parent,
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 088/103] mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (79 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 087/103] xc2028: Fix use-after-free bug properly Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 089/103] staging: rtl8192e: fix 2 byte alignment of register BSSIDR Greg Kroah-Hartman
` (16 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Keno Fischer, Kirill A. Shutemov,
Greg Thelen, Nicholas Piggin, Willy Tarreau, Oleg Nesterov,
Kees Cook, Andy Lutomirski, Michal Hocko, Hugh Dickins,
Andrew Morton, Linus Torvalds, Amit Pundir
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Keno Fischer <keno@juliacomputing.com>
commit 8310d48b125d19fcd9521d83b8293e63eb1646aa upstream.
In commit 19be0eaffa3a ("mm: remove gup_flags FOLL_WRITE games from
__get_user_pages()"), the mm code was changed from unsetting FOLL_WRITE
after a COW was resolved to setting the (newly introduced) FOLL_COW
instead. Simultaneously, the check in gup.c was updated to still allow
writes with FOLL_FORCE set if FOLL_COW had also been set.
However, a similar check in huge_memory.c was forgotten. As a result,
remote memory writes to ro regions of memory backed by transparent huge
pages cause an infinite loop in the kernel (handle_mm_fault sets
FOLL_COW and returns 0 causing a retry, but follow_trans_huge_pmd bails
out immidiately because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is
true.
While in this state the process is stil SIGKILLable, but little else
works (e.g. no ptrace attach, no other signals). This is easily
reproduced with the following code (assuming thp are set to always):
#include <assert.h>
#include <fcntl.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#define TEST_SIZE 5 * 1024 * 1024
int main(void) {
int status;
pid_t child;
int fd = open("/proc/self/mem", O_RDWR);
void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
assert(addr != MAP_FAILED);
pid_t parent_pid = getpid();
if ((child = fork()) == 0) {
void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
assert(addr2 != MAP_FAILED);
memset(addr2, 'a', TEST_SIZE);
pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
return 0;
}
assert(child == waitpid(child, &status, 0));
assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
return 0;
}
Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously
to the update in gup.c in the original commit. The same pattern exists
in follow_devmap_pmd. However, we should not be able to reach that
check with FOLL_COW set, so add WARN_ONCE to make sure we notice if we
ever do.
[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20170106015025.GA38411@juliacomputing.com
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[AmitP: Minor refactoring of upstream changes for linux-3.18.y,
where follow_devmap_pmd() doesn't exist.]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/huge_memory.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1269,6 +1269,16 @@ out_unlock:
return ret;
}
+/*
+ * FOLL_FORCE can write to even unwritable pmd's, but only
+ * after we've gone through a COW cycle and they are dirty.
+ */
+static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags)
+{
+ return pmd_write(pmd) ||
+ ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+}
+
struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
unsigned long addr,
pmd_t *pmd,
@@ -1279,7 +1289,7 @@ struct page *follow_trans_huge_pmd(struc
assert_spin_locked(pmd_lockptr(mm, pmd));
- if (flags & FOLL_WRITE && !pmd_write(*pmd))
+ if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
goto out;
/* Avoid dumping huge zero page */
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 089/103] staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (80 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 088/103] mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 090/103] staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD Greg Kroah-Hartman
` (15 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Malcolm Priestley
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Malcolm Priestley <tvboxspy@gmail.com>
commit 867510bde14e7b7fc6dd0f50b48f6753cfbd227a upstream.
BSSIDR has two byte alignment on PCI ioremap correct the write
by swapping to 16 bits first.
This fixes a problem that the device associates fail because
the filter is not set correctly.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -97,8 +97,9 @@ void rtl92e_set_reg(struct net_device *d
switch (variable) {
case HW_VAR_BSSID:
- rtl92e_writel(dev, BSSIDR, ((u32 *)(val))[0]);
- rtl92e_writew(dev, BSSIDR+2, ((u16 *)(val+2))[0]);
+ /* BSSIDR 2 byte alignment */
+ rtl92e_writew(dev, BSSIDR, *(u16 *)val);
+ rtl92e_writel(dev, BSSIDR + 2, *(u32 *)(val + 2));
break;
case HW_VAR_MEDIA_STATUS:
@@ -963,8 +964,8 @@ static void _rtl92e_net_update(struct ne
rtl92e_config_rate(dev, &rate_config);
priv->dot11CurrentPreambleMode = PREAMBLE_AUTO;
priv->basic_rate = rate_config &= 0x15f;
- rtl92e_writel(dev, BSSIDR, ((u32 *)net->bssid)[0]);
- rtl92e_writew(dev, BSSIDR+4, ((u16 *)net->bssid)[2]);
+ rtl92e_writew(dev, BSSIDR, *(u16 *)net->bssid);
+ rtl92e_writel(dev, BSSIDR + 2, *(u32 *)(net->bssid + 2));
if (priv->rtllib->iw_mode == IW_MODE_ADHOC) {
rtl92e_writew(dev, ATIMWND, 2);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 090/103] staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (81 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 089/103] staging: rtl8192e: fix 2 byte alignment of register BSSIDR Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` [PATCH 4.4 091/103] iommu/vt-d: Flush the IOTLB to get rid of the initial kdump mappings Greg Kroah-Hartman
` (14 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Malcolm Priestley
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Malcolm Priestley <tvboxspy@gmail.com>
commit 90be652c9f157d44b9c2803f902a8839796c090d upstream.
EPROM_CMD is 2 byte aligned on PCI map so calling with rtl92e_readl
will return invalid data so use rtl92e_readw.
The device is unable to select the right eeprom type.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -627,7 +627,7 @@ void rtl92e_get_eeprom_size(struct net_d
struct r8192_priv *priv = rtllib_priv(dev);
RT_TRACE(COMP_INIT, "===========>%s()\n", __func__);
- curCR = rtl92e_readl(dev, EPROM_CMD);
+ curCR = rtl92e_readw(dev, EPROM_CMD);
RT_TRACE(COMP_INIT, "read from Reg Cmd9346CR(%x):%x\n", EPROM_CMD,
curCR);
priv->epromtype = (curCR & EPROM_CMD_9356SEL) ? EEPROM_93C56 :
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 091/103] iommu/vt-d: Flush the IOTLB to get rid of the initial kdump mappings
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (82 preceding siblings ...)
2017-05-23 20:09 ` [PATCH 4.4 090/103] staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:09 ` Greg Kroah-Hartman
` (13 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Joerg Roedel, David Woodhouse,
David Woodhouse, Anthony Liguori, KarimAllah Ahmed, Joerg Roedel
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: KarimAllah Ahmed <karahmed@amazon.de>
commit f73a7eee900e95404b61408a23a1df5c5811704c upstream.
Ever since commit 091d42e43d ("iommu/vt-d: Copy translation tables from
old kernel") the kdump kernel copies the IOMMU context tables from the
previous kernel. Each device mappings will be destroyed once the driver
for the respective device takes over.
This unfortunately breaks the workflow of mapping and unmapping a new
context to the IOMMU. The mapping function assumes that either:
1) Unmapping did the proper IOMMU flushing and it only ever flush if the
IOMMU unit supports caching invalid entries.
2) The system just booted and the initialization code took care of
flushing all IOMMU caches.
This assumption is not true for the kdump kernel since the context
tables have been copied from the previous kernel and translations could
have been cached ever since. So make sure to flush the IOTLB as well
when we destroy these old copied mappings.
Cc: Joerg Roedel <joro@8bytes.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Anthony Liguori <aliguori@amazon.com>
Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Fixes: 091d42e43d ("iommu/vt-d: Copy translation tables from old kernel")
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/intel-iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2005,11 +2005,14 @@ static int domain_context_mapping_one(st
if (context_copied(context)) {
u16 did_old = context_domain_id(context);
- if (did_old >= 0 && did_old < cap_ndoms(iommu->cap))
+ if (did_old >= 0 && did_old < cap_ndoms(iommu->cap)) {
iommu->flush.flush_context(iommu, did_old,
(((u16)bus) << 8) | devfn,
DMA_CCMD_MASK_NOBIT,
DMA_CCMD_DEVICE_INVL);
+ iommu->flush.flush_iotlb(iommu, did_old, 0, 0,
+ DMA_TLB_DSI_FLUSH);
+ }
}
pgd = domain->pgd;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 092/103] metag/uaccess: Fix access_ok()
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
0 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Al Viro, James Hogan, linux-metag
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <james.hogan@imgtec.com>
commit 8a8b56638bcac4e64cccc88bf95a0f9f4b19a2fb upstream.
The __user_bad() macro used by access_ok() has a few corner cases
noticed by Al Viro where it doesn't behave correctly:
- The kernel range check has off by 1 errors which permit access to the
first and last byte of the kernel mapped range.
- The kernel range check ends at LINCORE_BASE rather than
META_MEMORY_LIMIT, which is ineffective when the kernel is in global
space (an extremely uncommon configuration).
There are a couple of other shortcomings here too:
- Access to the whole of the other address space is permitted (i.e. the
global half of the address space when the kernel is in local space).
This isn't ideal as it could theoretically still contain privileged
mappings set up by the bootloader.
- The size argument is unused, permitting user copies which start on
valid pages at the end of the user address range and cross the
boundary into the kernel address space (e.g. addr = 0x3ffffff0, size
> 0x10).
It isn't very convenient to add size checks when disallowing certain
regions, and it seems far safer to be sure and explicit about what
userland is able to access, so invert the logic to allow certain regions
instead, and fix the off by 1 errors and missing size checks. This also
allows the get_fs() == KERNEL_DS check to be more easily optimised into
the user address range case.
We now have 3 such allowed regions:
- The user address range (incorporating the get_fs() == KERNEL_DS
check).
- NULL (some kernel code expects this to work, and we'll always catch
the fault anyway).
- The core code memory region.
Fixes: 373cd784d0fc ("metag: Memory handling")
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/metag/include/asm/uaccess.h | 40 +++++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 16 deletions(-)
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -28,24 +28,32 @@
#define segment_eq(a, b) ((a).seg == (b).seg)
-#define __kernel_ok (segment_eq(get_fs(), KERNEL_DS))
-/*
- * Explicitly allow NULL pointers here. Parts of the kernel such
- * as readv/writev use access_ok to validate pointers, but want
- * to allow NULL pointers for various reasons. NULL pointers are
- * safe to allow through because the first page is not mappable on
- * Meta.
- *
- * We also wish to avoid letting user code access the system area
- * and the kernel half of the address space.
- */
-#define __user_bad(addr, size) (((addr) > 0 && (addr) < META_MEMORY_BASE) || \
- ((addr) > PAGE_OFFSET && \
- (addr) < LINCORE_BASE))
-
static inline int __access_ok(unsigned long addr, unsigned long size)
{
- return __kernel_ok || !__user_bad(addr, size);
+ /*
+ * Allow access to the user mapped memory area, but not the system area
+ * before it. The check extends to the top of the address space when
+ * kernel access is allowed (there's no real reason to user copy to the
+ * system area in any case).
+ */
+ if (likely(addr >= META_MEMORY_BASE && addr < get_fs().seg &&
+ size <= get_fs().seg - addr))
+ return true;
+ /*
+ * Explicitly allow NULL pointers here. Parts of the kernel such
+ * as readv/writev use access_ok to validate pointers, but want
+ * to allow NULL pointers for various reasons. NULL pointers are
+ * safe to allow through because the first page is not mappable on
+ * Meta.
+ */
+ if (!addr)
+ return true;
+ /* Allow access to core code memory area... */
+ if (addr >= LINCORE_CODE_BASE && addr <= LINCORE_CODE_LIMIT &&
+ size <= LINCORE_CODE_LIMIT + 1 - addr)
+ return true;
+ /* ... but no other areas. */
+ return false;
}
#define access_ok(type, addr, size) __access_ok((unsigned long)(addr), \
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 092/103] metag/uaccess: Fix access_ok()
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
0 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Greg Kroah-Hartman, stable-u79uwXL29TY76Z2rM5mHXA, Al Viro,
James Hogan, linux-metag-u79uwXL29TY76Z2rM5mHXA
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
commit 8a8b56638bcac4e64cccc88bf95a0f9f4b19a2fb upstream.
The __user_bad() macro used by access_ok() has a few corner cases
noticed by Al Viro where it doesn't behave correctly:
- The kernel range check has off by 1 errors which permit access to the
first and last byte of the kernel mapped range.
- The kernel range check ends at LINCORE_BASE rather than
META_MEMORY_LIMIT, which is ineffective when the kernel is in global
space (an extremely uncommon configuration).
There are a couple of other shortcomings here too:
- Access to the whole of the other address space is permitted (i.e. the
global half of the address space when the kernel is in local space).
This isn't ideal as it could theoretically still contain privileged
mappings set up by the bootloader.
- The size argument is unused, permitting user copies which start on
valid pages at the end of the user address range and cross the
boundary into the kernel address space (e.g. addr = 0x3ffffff0, size
> 0x10).
It isn't very convenient to add size checks when disallowing certain
regions, and it seems far safer to be sure and explicit about what
userland is able to access, so invert the logic to allow certain regions
instead, and fix the off by 1 errors and missing size checks. This also
allows the get_fs() == KERNEL_DS check to be more easily optimised into
the user address range case.
We now have 3 such allowed regions:
- The user address range (incorporating the get_fs() == KERNEL_DS
check).
- NULL (some kernel code expects this to work, and we'll always catch
the fault anyway).
- The core code memory region.
Fixes: 373cd784d0fc ("metag: Memory handling")
Reported-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Signed-off-by: James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Cc: linux-metag-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
---
arch/metag/include/asm/uaccess.h | 40 +++++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 16 deletions(-)
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -28,24 +28,32 @@
#define segment_eq(a, b) ((a).seg == (b).seg)
-#define __kernel_ok (segment_eq(get_fs(), KERNEL_DS))
-/*
- * Explicitly allow NULL pointers here. Parts of the kernel such
- * as readv/writev use access_ok to validate pointers, but want
- * to allow NULL pointers for various reasons. NULL pointers are
- * safe to allow through because the first page is not mappable on
- * Meta.
- *
- * We also wish to avoid letting user code access the system area
- * and the kernel half of the address space.
- */
-#define __user_bad(addr, size) (((addr) > 0 && (addr) < META_MEMORY_BASE) || \
- ((addr) > PAGE_OFFSET && \
- (addr) < LINCORE_BASE))
-
static inline int __access_ok(unsigned long addr, unsigned long size)
{
- return __kernel_ok || !__user_bad(addr, size);
+ /*
+ * Allow access to the user mapped memory area, but not the system area
+ * before it. The check extends to the top of the address space when
+ * kernel access is allowed (there's no real reason to user copy to the
+ * system area in any case).
+ */
+ if (likely(addr >= META_MEMORY_BASE && addr < get_fs().seg &&
+ size <= get_fs().seg - addr))
+ return true;
+ /*
+ * Explicitly allow NULL pointers here. Parts of the kernel such
+ * as readv/writev use access_ok to validate pointers, but want
+ * to allow NULL pointers for various reasons. NULL pointers are
+ * safe to allow through because the first page is not mappable on
+ * Meta.
+ */
+ if (!addr)
+ return true;
+ /* Allow access to core code memory area... */
+ if (addr >= LINCORE_CODE_BASE && addr <= LINCORE_CODE_LIMIT &&
+ size <= LINCORE_CODE_LIMIT + 1 - addr)
+ return true;
+ /* ... but no other areas. */
+ return false;
}
#define access_ok(type, addr, size) __access_ok((unsigned long)(addr), \
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 093/103] metag/uaccess: Check access_ok in strncpy_from_user
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (84 preceding siblings ...)
2017-05-23 20:09 ` Greg Kroah-Hartman
@ 2017-05-23 20:09 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [kernel-hardening] " Greg Kroah-Hartman
` (11 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:09 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Al Viro, James Hogan, linux-metag
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <james.hogan@imgtec.com>
commit 3a158a62da0673db918b53ac1440845a5b64fd90 upstream.
The metag implementation of strncpy_from_user() doesn't validate the src
pointer, which could allow reading of arbitrary kernel memory. Add a
short access_ok() check to prevent that.
Its still possible for it to read across the user/kernel boundary, but
it will invariably reach a NUL character after only 9 bytes, leaking
only a static kernel address being loaded into D0Re0 at the beginning of
__start, which is acceptable for the immediate fix.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/metag/include/asm/uaccess.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -194,8 +194,13 @@ do {
extern long __must_check __strncpy_from_user(char *dst, const char __user *src,
long count);
-#define strncpy_from_user(dst, src, count) __strncpy_from_user(dst, src, count)
-
+static inline long
+strncpy_from_user(char *dst, const char __user *src, long count)
+{
+ if (!access_ok(VERIFY_READ, src, 1))
+ return -EFAULT;
+ return __strncpy_from_user(dst, src, count);
+}
/*
* Return the size of a string (including the ending 0)
*
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 094/103] stackprotector: Increase the per-task stack canarys random range from 32 bits to 64 bits on 64-bit platforms
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:08 ` [PATCH 4.4 002/103] usb: misc: legousbtower: Fix memory leak Greg Kroah-Hartman
` (96 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Micay, Arjan van de Ven,
Rik van Riel, Kees Cook, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner, kernel-hardening, Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Micay <danielmicay@gmail.com>
commit 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 upstream.
The stack canary is an 'unsigned long' and should be fully initialized to
random data rather than only 32 bits of random data.
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Arjan van Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-hardening@lists.openwall.com
Link: http://lkml.kernel.org/r/20170504133209.3053-1-danielmicay@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -368,7 +368,7 @@ static struct task_struct *dup_task_stru
set_task_stack_end_magic(tsk);
#ifdef CONFIG_CC_STACKPROTECTOR
- tsk->stack_canary = get_random_int();
+ tsk->stack_canary = get_random_long();
#endif
/*
^ permalink raw reply [flat|nested] 121+ messages in thread* [kernel-hardening] [PATCH 4.4 094/103] stackprotector: Increase the per-task stack canarys random range from 32 bits to 64 bits on 64-bit platforms
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
0 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Micay, Arjan van de Ven,
Rik van Riel, Kees Cook, Linus Torvalds, Peter Zijlstra,
Thomas Gleixner, kernel-hardening, Ingo Molnar
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Micay <danielmicay@gmail.com>
commit 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 upstream.
The stack canary is an 'unsigned long' and should be fully initialized to
random data rather than only 32 bits of random data.
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Arjan van Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-hardening@lists.openwall.com
Link: http://lkml.kernel.org/r/20170504133209.3053-1-danielmicay@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -368,7 +368,7 @@ static struct task_struct *dup_task_stru
set_task_stack_end_magic(tsk);
#ifdef CONFIG_CC_STACKPROTECTOR
- tsk->stack_canary = get_random_int();
+ tsk->stack_canary = get_random_long();
#endif
/*
^ permalink raw reply [flat|nested] 121+ messages in thread
* [PATCH 4.4 095/103] uwb: fix device quirk on big-endian hosts
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (86 preceding siblings ...)
2017-05-23 20:10 ` [kernel-hardening] " Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 096/103] genirq: Fix chained interrupt data ordering Greg Kroah-Hartman
` (9 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Johan Hovold
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 41318a2b82f5d5fe1fb408f6d6e0b22aa557111d upstream.
Add missing endianness conversion when using the USB device-descriptor
idProduct field to apply a hardware quirk.
Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/uwb/i1480/dfu/usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/uwb/i1480/dfu/usb.c
+++ b/drivers/uwb/i1480/dfu/usb.c
@@ -341,6 +341,7 @@ error_submit_ep1:
static
int i1480_usb_probe(struct usb_interface *iface, const struct usb_device_id *id)
{
+ struct usb_device *udev = interface_to_usbdev(iface);
struct i1480_usb *i1480_usb;
struct i1480 *i1480;
struct device *dev = &iface->dev;
@@ -352,8 +353,8 @@ int i1480_usb_probe(struct usb_interface
iface->cur_altsetting->desc.bInterfaceNumber);
goto error;
}
- if (iface->num_altsetting > 1
- && interface_to_usbdev(iface)->descriptor.idProduct == 0xbabe) {
+ if (iface->num_altsetting > 1 &&
+ le16_to_cpu(udev->descriptor.idProduct) == 0xbabe) {
/* Need altsetting #1 [HW QUIRK] or EP1 won't work */
result = usb_set_interface(interface_to_usbdev(iface), 0, 1);
if (result < 0)
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 096/103] genirq: Fix chained interrupt data ordering
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (87 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 095/103] uwb: fix device quirk on big-endian hosts Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 097/103] osf_wait4(): fix infoleak Greg Kroah-Hartman
` (8 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Borislav Petkov, Thomas Gleixner
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 2c4569ca26986d18243f282dd727da27e9adae4c upstream.
irq_set_chained_handler_and_data() sets up the chained interrupt and then
stores the handler data.
That's racy against an immediate interrupt which gets handled before the
store of the handler data happened. The handler will dereference a NULL
pointer and crash.
Cure it by storing handler data before installing the chained handler.
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/irq/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -810,8 +810,8 @@ irq_set_chained_handler_and_data(unsigne
if (!desc)
return;
- __irq_do_set_handler(desc, handle, 1, NULL);
desc->irq_common_data.handler_data = data;
+ __irq_do_set_handler(desc, handle, 1, NULL);
irq_put_desc_busunlock(desc, flags);
}
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 097/103] osf_wait4(): fix infoleak
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (88 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 096/103] genirq: Fix chained interrupt data ordering Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 098/103] tracing/kprobes: Enforce kprobes teardown after testing Greg Kroah-Hartman
` (7 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <viro@zeniv.linux.org.uk>
commit a8c39544a6eb2093c04afd5005b6192bd0e880c6 upstream.
failing sys_wait4() won't fill struct rusage...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/alpha/kernel/osf_sys.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1188,8 +1188,10 @@ SYSCALL_DEFINE4(osf_wait4, pid_t, pid, i
if (!access_ok(VERIFY_WRITE, ur, sizeof(*ur)))
return -EFAULT;
- err = 0;
- err |= put_user(status, ustatus);
+ err = put_user(status, ustatus);
+ if (ret < 0)
+ return err ? err : ret;
+
err |= __put_user(r.ru_utime.tv_sec, &ur->ru_utime.tv_sec);
err |= __put_user(r.ru_utime.tv_usec, &ur->ru_utime.tv_usec);
err |= __put_user(r.ru_stime.tv_sec, &ur->ru_stime.tv_sec);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 098/103] tracing/kprobes: Enforce kprobes teardown after testing
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (89 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 097/103] osf_wait4(): fix infoleak Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 099/103] PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms Greg Kroah-Hartman
` (6 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Gleixner, Masami Hiramatsu,
Steven Rostedt (VMware)
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 30e7d894c1478c88d50ce94ddcdbd7f9763d9cdd upstream.
Enabling the tracer selftest triggers occasionally the warning in
text_poke(), which warns when the to be modified page is not marked
reserved.
The reason is that the tracer selftest installs kprobes on functions marked
__init for testing. These probes are removed after the tests, but that
removal schedules the delayed kprobes_optimizer work, which will do the
actual text poke. If the work is executed after the init text is freed,
then the warning triggers. The bug can be reproduced reliably when the work
delay is increased.
Flush the optimizer work and wait for the optimizing/unoptimizing lists to
become empty before returning from the kprobes tracer selftest. That
ensures that all operations which were queued due to the probes removal
have completed.
Link: http://lkml.kernel.org/r/20170516094802.76a468bb@gandalf.local.home
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Fixes: 6274de498 ("kprobes: Support delayed unoptimizing")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/kprobes.h | 4 +++-
kernel/kprobes.c | 2 +-
kernel/trace/trace_kprobe.c | 5 +++++
3 files changed, 9 insertions(+), 2 deletions(-)
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -330,7 +330,9 @@ extern int proc_kprobes_optimization_han
int write, void __user *buffer,
size_t *length, loff_t *ppos);
#endif
-
+extern void wait_for_kprobe_optimizer(void);
+#else
+static inline void wait_for_kprobe_optimizer(void) { }
#endif /* CONFIG_OPTPROBES */
#ifdef CONFIG_KPROBES_ON_FTRACE
extern void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -563,7 +563,7 @@ static void kprobe_optimizer(struct work
}
/* Wait for completing optimization and unoptimization */
-static void wait_for_kprobe_optimizer(void)
+void wait_for_kprobe_optimizer(void)
{
mutex_lock(&kprobe_mutex);
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1471,6 +1471,11 @@ static __init int kprobe_trace_self_test
end:
release_all_trace_kprobes();
+ /*
+ * Wait for the optimizer work to finish. Otherwise it might fiddle
+ * with probes in already freed __init text.
+ */
+ wait_for_kprobe_optimizer();
if (warn)
pr_cont("NG: Some tests are failed. Please check them.\n");
else
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 099/103] PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (90 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 098/103] tracing/kprobes: Enforce kprobes teardown after testing Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 101/103] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2 Greg Kroah-Hartman
` (5 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, David Woodhouse, Bjorn Helgaas
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <dwmw@amazon.co.uk>
commit 6bccc7f426abd640f08d8c75fb22f99483f201b4 upstream.
In the PCI_MMAP_PROCFS case when the address being passed by the user is a
'user visible' resource address based on the bus window, and not the actual
contents of the resource, that's what we need to be checking it against.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pci-sysfs.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -973,15 +973,19 @@ void pci_remove_legacy_files(struct pci_
int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma,
enum pci_mmap_api mmap_api)
{
- unsigned long nr, start, size, pci_start;
+ unsigned long nr, start, size;
+ resource_size_t pci_start = 0, pci_end;
if (pci_resource_len(pdev, resno) == 0)
return 0;
nr = vma_pages(vma);
start = vma->vm_pgoff;
size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
- pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
- pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
+ if (mmap_api == PCI_MMAP_PROCFS) {
+ pci_resource_to_user(pdev, resno, &pdev->resource[resno],
+ &pci_start, &pci_end);
+ pci_start >>= PAGE_SHIFT;
+ }
if (start >= pci_start && start < pci_start + size &&
start + nr <= pci_start + size)
return 1;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 101/103] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (91 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 099/103] PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 102/103] nfsd: encoders mustnt use unitialized values in error cases Greg Kroah-Hartman
` (4 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mario Kleiner, Harry Wentland, Daniel Vetter
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Kleiner <mario.kleiner.de@gmail.com>
commit e345da82bd6bdfa8492f80b3ce4370acfd868d95 upstream.
The builtin eDP panel in the HP zBook 17 G2 supports 10 bpc,
as advertised by the Laptops product specs and verified via
injecting a fixed edid + photometer measurements, but edid
reports unknown depth, so drivers fall back to 6 bpc.
Add a quirk to get the full 10 bpc.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1492787108-23959-1-git-send-email-mario.kleiner.de@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_edid.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -75,6 +75,8 @@
#define EDID_QUIRK_FORCE_12BPC (1 << 9)
/* Force 6bpc */
#define EDID_QUIRK_FORCE_6BPC (1 << 10)
+/* Force 10bpc */
+#define EDID_QUIRK_FORCE_10BPC (1 << 11)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -117,6 +119,9 @@ static struct edid_quirk {
{ "FCM", 13600, EDID_QUIRK_PREFER_LARGE_75 |
EDID_QUIRK_DETAILED_IN_CM },
+ /* LGD panel of HP zBook 17 G2, eDP 10 bpc, but reports unknown bpc */
+ { "LGD", 764, EDID_QUIRK_FORCE_10BPC },
+
/* LG Philips LCD LP154W01-A5 */
{ "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
{ "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
@@ -3834,6 +3839,9 @@ int drm_add_edid_modes(struct drm_connec
if (quirks & EDID_QUIRK_FORCE_8BPC)
connector->display_info.bpc = 8;
+ if (quirks & EDID_QUIRK_FORCE_10BPC)
+ connector->display_info.bpc = 10;
+
if (quirks & EDID_QUIRK_FORCE_12BPC)
connector->display_info.bpc = 12;
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 102/103] nfsd: encoders mustnt use unitialized values in error cases
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (92 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 101/103] drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2 Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-23 20:10 ` [PATCH 4.4 103/103] drivers: char: mem: Check for address space wraparound with mmap() Greg Kroah-Hartman
` (3 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ari Kauppi, Christoph Hellwig,
J. Bruce Fields
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: J. Bruce Fields <bfields@redhat.com>
commit f961e3f2acae94b727380c0b74e2d3954d0edf79 upstream.
In error cases, lgp->lg_layout_type may be out of bounds; so we
shouldn't be using it until after the check of nfserr.
This was seen to crash nfsd threads when the server receives a LAYOUTGET
request with a large layout type.
GETDEVICEINFO has the same problem.
Reported-by: Ari Kauppi <Ari.Kauppi@synopsys.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/nfsd/nfs4xdr.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -4041,8 +4041,7 @@ nfsd4_encode_getdeviceinfo(struct nfsd4_
struct nfsd4_getdeviceinfo *gdev)
{
struct xdr_stream *xdr = &resp->xdr;
- const struct nfsd4_layout_ops *ops =
- nfsd4_layout_ops[gdev->gd_layout_type];
+ const struct nfsd4_layout_ops *ops;
u32 starting_len = xdr->buf->len, needed_len;
__be32 *p;
@@ -4059,6 +4058,7 @@ nfsd4_encode_getdeviceinfo(struct nfsd4_
/* If maxcount is 0 then just update notifications */
if (gdev->gd_maxcount != 0) {
+ ops = nfsd4_layout_ops[gdev->gd_layout_type];
nfserr = ops->encode_getdeviceinfo(xdr, gdev);
if (nfserr) {
/*
@@ -4111,8 +4111,7 @@ nfsd4_encode_layoutget(struct nfsd4_comp
struct nfsd4_layoutget *lgp)
{
struct xdr_stream *xdr = &resp->xdr;
- const struct nfsd4_layout_ops *ops =
- nfsd4_layout_ops[lgp->lg_layout_type];
+ const struct nfsd4_layout_ops *ops;
__be32 *p;
dprintk("%s: err %d\n", __func__, nfserr);
@@ -4135,6 +4134,7 @@ nfsd4_encode_layoutget(struct nfsd4_comp
*p++ = cpu_to_be32(lgp->lg_seg.iomode);
*p++ = cpu_to_be32(lgp->lg_layout_type);
+ ops = nfsd4_layout_ops[lgp->lg_layout_type];
nfserr = ops->encode_layoutget(xdr, lgp);
out:
kfree(lgp->lg_content);
^ permalink raw reply [flat|nested] 121+ messages in thread* [PATCH 4.4 103/103] drivers: char: mem: Check for address space wraparound with mmap()
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (93 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 102/103] nfsd: encoders mustnt use unitialized values in error cases Greg Kroah-Hartman
@ 2017-05-23 20:10 ` Greg Kroah-Hartman
2017-05-24 4:01 ` [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck
` (2 subsequent siblings)
97 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-23 20:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Julius Werner
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julius Werner <jwerner@chromium.org>
commit b299cde245b0b76c977f4291162cf668e087b408 upstream.
/dev/mem currently allows mmap() mappings that wrap around the end of
the physical address space, which should probably be illegal. It
circumvents the existing STRICT_DEVMEM permission check because the loop
immediately terminates (as the start address is already higher than the
end address). On the x86_64 architecture it will then cause a panic
(from the BUG(start >= end) in arch/x86/mm/pat.c:reserve_memtype()).
This patch adds an explicit check to make sure offset + size will not
wrap around in the physical address type.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/mem.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -343,6 +343,11 @@ static const struct vm_operations_struct
static int mmap_mem(struct file *file, struct vm_area_struct *vma)
{
size_t size = vma->vm_end - vma->vm_start;
+ phys_addr_t offset = (phys_addr_t)vma->vm_pgoff << PAGE_SHIFT;
+
+ /* It's illegal to wrap around the end of the physical address space. */
+ if (offset + (phys_addr_t)size < offset)
+ return -EINVAL;
if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size))
return -EINVAL;
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (94 preceding siblings ...)
2017-05-23 20:10 ` [PATCH 4.4 103/103] drivers: char: mem: Check for address space wraparound with mmap() Greg Kroah-Hartman
@ 2017-05-24 4:01 ` Guenter Roeck
2017-05-24 6:50 ` Greg Kroah-Hartman
[not found] ` <59252147.91471c0a.7a474.26e6@mx.google.com>
2017-05-24 20:22 ` Guenter Roeck
97 siblings, 1 reply; 121+ messages in thread
From: Guenter Roeck @ 2017-05-24 4:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.70 release.
> There are 103 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:08:25 UTC 2017.
> Anything received after that time might be too late.
>
Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
Guenter
---
...
EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
BUG: unable to handle kernel paging request at 0000000000002280
IP: [<ffffffff81451115>] process_echoes+0x15/0x70
PGD da68067 PUD d991067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
RIP: 0010:[<ffffffff81451115>] [<ffffffff81451115>] process_echoes+0x15/0x70
RSP: 0018:ffff88000d233d50 EFLAGS: 00000202
RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
FS: 00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
Stack:
ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
Call Trace:
[<ffffffff814515b7>] n_tty_write+0x97/0x4e0
[<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
[<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
[<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
[<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
[<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
[<ffffffff81199abe>] ? __fd_install+0x5e/0x110
[<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
[<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
[<ffffffff8117df3a>] vfs_write+0x9a/0x170
[<ffffffff8117ea96>] SyS_write+0x46/0xb0
[<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
RIP [<ffffffff81451115>] process_echoes+0x15/0x70
RSP <ffff88000d233d50>
CR2: 0000000000002280
---[ end trace cec672c0d4b54e81 ]---
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 4:01 ` [PATCH 4.4 000/103] 4.4.70-stable review Guenter Roeck
@ 2017-05-24 6:50 ` Greg Kroah-Hartman
2017-05-24 6:55 ` Greg Kroah-Hartman
0 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-24 6:50 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote:
> On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.70 release.
> > There are 103 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu May 25 20:08:25 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
>
> Guenter
>
> ---
>
> ...
> EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
> BUG: unable to handle kernel paging request at 0000000000002280
> IP: [<ffffffff81451115>] process_echoes+0x15/0x70
> PGD da68067 PUD d991067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
> RIP: 0010:[<ffffffff81451115>] [<ffffffff81451115>] process_echoes+0x15/0x70
> RSP: 0018:ffff88000d233d50 EFLAGS: 00000202
> RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
> RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
> RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
> R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
> R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
> FS: 00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
> Stack:
> ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
> ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
> ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
> Call Trace:
> [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
> [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
> [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
> [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
> [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
> [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
> [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
> [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
> [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
> [<ffffffff8117df3a>] vfs_write+0x9a/0x170
> [<ffffffff8117ea96>] SyS_write+0x46/0xb0
> [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
> Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
> RIP [<ffffffff81451115>] process_echoes+0x15/0x70
> RSP <ffff88000d233d50>
> CR2: 0000000000002280
> ---[ end trace cec672c0d4b54e81 ]---
> Kernel panic - not syncing: Fatal exception
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Fatal exception
Yes, bisection would be great, if you can do it. I would blame the only
tty patch in the release,
tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that
would be odd.
Oops, nope, that would be it, the merge happened badly, I applied a
chunk in the wrong place, ugh. Let me go fix that patch up now...
greg k-h
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 6:50 ` Greg Kroah-Hartman
@ 2017-05-24 6:55 ` Greg Kroah-Hartman
0 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-24 6:55 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Wed, May 24, 2017 at 08:50:39AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote:
> > On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.70 release.
> > > There are 103 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Thu May 25 20:08:25 UTC 2017.
> > > Anything received after that time might be too late.
> > >
> >
> > Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
> >
> > Guenter
> >
> > ---
> >
> > ...
> > EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
> > BUG: unable to handle kernel paging request at 0000000000002280
> > IP: [<ffffffff81451115>] process_echoes+0x15/0x70
> > PGD da68067 PUD d991067 PMD 0
> > Oops: 0000 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> > task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
> > RIP: 0010:[<ffffffff81451115>] [<ffffffff81451115>] process_echoes+0x15/0x70
> > RSP: 0018:ffff88000d233d50 EFLAGS: 00000202
> > RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
> > RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
> > RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
> > R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
> > R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
> > FS: 00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
> > Stack:
> > ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
> > ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
> > ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
> > Call Trace:
> > [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
> > [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
> > [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
> > [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
> > [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
> > [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
> > [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
> > [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
> > [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
> > [<ffffffff8117df3a>] vfs_write+0x9a/0x170
> > [<ffffffff8117ea96>] SyS_write+0x46/0xb0
> > [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
> > Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
> > RIP [<ffffffff81451115>] process_echoes+0x15/0x70
> > RSP <ffff88000d233d50>
> > CR2: 0000000000002280
> > ---[ end trace cec672c0d4b54e81 ]---
> > Kernel panic - not syncing: Fatal exception
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Fatal exception
>
> Yes, bisection would be great, if you can do it. I would blame the only
> tty patch in the release,
> tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that
> would be odd.
>
> Oops, nope, that would be it, the merge happened badly, I applied a
> chunk in the wrong place, ugh. Let me go fix that patch up now...
And that was because this patch was already merged in an older release,
my fault. I've dropped it now, and pushed out an update, this should
fix the problem.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 121+ messages in thread
[parent not found: <59252147.91471c0a.7a474.26e6@mx.google.com>]
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
[not found] ` <59252147.91471c0a.7a474.26e6@mx.google.com>
@ 2017-05-24 7:03 ` Greg Kroah-Hartman
2017-05-24 9:26 ` Thomas Voegtle
2017-05-24 12:47 ` Guenter Roeck
0 siblings, 2 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-24 7:03 UTC (permalink / raw)
To: kernelci.org bot
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, stable
On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>
> Tree: stable-rc
> Branch: linux-4.4.y
> Git Describe: v4.4.69-104-g2ebff3b7590b
> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
54 passed? I had a bug here such that all x86 builds were crashing, in
the core tty layer, which seems odd that anything would be able to boot
with this tree...
I've pushed out an update, can you all verify that it also works?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 7:03 ` Greg Kroah-Hartman
@ 2017-05-24 9:26 ` Thomas Voegtle
2017-05-24 11:35 ` Greg Kroah-Hartman
2017-05-24 12:47 ` Guenter Roeck
1 sibling, 1 reply; 121+ messages in thread
From: Thomas Voegtle @ 2017-05-24 9:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.69-104-g2ebff3b7590b
>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>
> 54 passed? I had a bug here such that all x86 builds were crashing, in
> the core tty layer, which seems odd that anything would be able to boot
> with this tree...
>
> I've pushed out an update, can you all verify that it also works?
I got this:
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC kernel/fork.o
kernel/fork.c: In function 'dup_task_struct':
kernel/fork.c:371:2: error: implicit declaration of function
'get_random_long' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2
This is
stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 9:26 ` Thomas Voegtle
@ 2017-05-24 11:35 ` Greg Kroah-Hartman
2017-05-24 12:04 ` Thomas Voegtle
0 siblings, 1 reply; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-24 11:35 UTC (permalink / raw)
To: Thomas Voegtle
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>
> > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > >
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > >
> > > Tree: stable-rc
> > > Branch: linux-4.4.y
> > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> >
> > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...
> >
> > I've pushed out an update, can you all verify that it also works?
>
>
> I got this:
>
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC kernel/fork.o
> kernel/fork.c: In function 'dup_task_struct':
> kernel/fork.c:371:2: error: implicit declaration of function
> 'get_random_long' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [kernel/fork.o] Error 1
> make: *** [kernel] Error 2
>
>
> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
What arch/.config are you building for that causes this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 11:35 ` Greg Kroah-Hartman
@ 2017-05-24 12:04 ` Thomas Voegtle
2017-05-24 12:53 ` Greg Kroah-Hartman
0 siblings, 1 reply; 121+ messages in thread
From: Thomas Voegtle @ 2017-05-24 12:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Thomas Voegtle, kernelci.org bot, linux-kernel, torvalds, akpm,
linux, shuahkh, patches, ben.hutchings, stable
On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
>> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>>
>>> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>>>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>>>
>>>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>>>
>>>> Tree: stable-rc
>>>> Branch: linux-4.4.y
>>>> Git Describe: v4.4.69-104-g2ebff3b7590b
>>>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>>>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>>>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>>>
>>> 54 passed? I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>>>
>>> I've pushed out an update, can you all verify that it also works?
>>
>>
>> I got this:
>>
>> CALL scripts/checksyscalls.sh
>> CHK include/generated/compile.h
>> CC kernel/fork.o
>> kernel/fork.c: In function 'dup_task_struct':
>> kernel/fork.c:371:2: error: implicit declaration of function
>> 'get_random_long' [-Werror=implicit-function-declaration]
>> cc1: some warnings being treated as errors
>> make[1]: *** [kernel/fork.o] Error 1
>> make: *** [kernel] Error 2
>>
>>
>> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
>
> What arch/.config are you building for that causes this?
x86_64 and CONFIG_CC_STACKPROTECTOR=y
The rest of my kernel config is SuSE's kernel-default config.
get_random_long came with v4.5 as far as I know
I have a running 4.4.70-rc1, Without that mentioned patch and using the
latest rc patch.
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 12:04 ` Thomas Voegtle
@ 2017-05-24 12:53 ` Greg Kroah-Hartman
0 siblings, 0 replies; 121+ messages in thread
From: Greg Kroah-Hartman @ 2017-05-24 12:53 UTC (permalink / raw)
To: Thomas Voegtle
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
On Wed, May 24, 2017 at 02:04:32PM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>
> > On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> > > On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> > >
> > > > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > > > >
> > > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > > >
> > > > > Tree: stable-rc
> > > > > Branch: linux-4.4.y
> > > > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> > > >
> > > > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > > > the core tty layer, which seems odd that anything would be able to boot
> > > > with this tree...
> > > >
> > > > I've pushed out an update, can you all verify that it also works?
> > >
> > >
> > > I got this:
> > >
> > > CALL scripts/checksyscalls.sh
> > > CHK include/generated/compile.h
> > > CC kernel/fork.o
> > > kernel/fork.c: In function 'dup_task_struct':
> > > kernel/fork.c:371:2: error: implicit declaration of function
> > > 'get_random_long' [-Werror=implicit-function-declaration]
> > > cc1: some warnings being treated as errors
> > > make[1]: *** [kernel/fork.o] Error 1
> > > make: *** [kernel] Error 2
> > >
> > >
> > > This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
> >
> > What arch/.config are you building for that causes this?
>
>
> x86_64 and CONFIG_CC_STACKPROTECTOR=y
>
> The rest of my kernel config is SuSE's kernel-default config.
>
> get_random_long came with v4.5 as far as I know
>
> I have a running 4.4.70-rc1, Without that mentioned patch and using the
> latest rc patch.
You are right, this shouldn't have gone to the 4.4-stable tree, thanks
for catching it. I've now dropped it.
thanks again,
greg k-h
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 7:03 ` Greg Kroah-Hartman
2017-05-24 9:26 ` Thomas Voegtle
@ 2017-05-24 12:47 ` Guenter Roeck
2017-05-24 12:58 ` Mark Brown
1 sibling, 1 reply; 121+ messages in thread
From: Guenter Roeck @ 2017-05-24 12:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, kernelci.org bot
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.69-104-g2ebff3b7590b
>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>
> 54 passed? I had a bug here such that all x86 builds were crashing, in
> the core tty layer, which seems odd that anything would be able to boot
> with this tree...
>
Final qemu test result was
total: 115 pass: 89 fail: 26
with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
Guenter
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 12:47 ` Guenter Roeck
@ 2017-05-24 12:58 ` Mark Brown
2017-05-24 13:18 ` Guenter Roeck
2017-05-24 13:33 ` Guenter Roeck
0 siblings, 2 replies; 121+ messages in thread
From: Mark Brown @ 2017-05-24 12:58 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
> > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...
> Final qemu test result was
> total: 115 pass: 89 fail: 26
> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
Not qemu but it has some physical x86 tests like:
https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
which seem to have managed to boot somehow. It's a minnowboard with no
video and it's booting to a ramdisk, I don't know if either of those
helped avoid the issue.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 121+ messages in thread* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 12:58 ` Mark Brown
@ 2017-05-24 13:18 ` Guenter Roeck
2017-05-24 15:08 ` Mark Brown
2017-05-24 13:33 ` Guenter Roeck
1 sibling, 1 reply; 121+ messages in thread
From: Guenter Roeck @ 2017-05-24 13:18 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
On 05/24/2017 05:58 AM, Mark Brown wrote:
> On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
>> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
>
>>> 54 passed? I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>
>> Final qemu test result was
>> total: 115 pass: 89 fail: 26
>> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
>> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
>
> Not qemu but it has some physical x86 tests like:
>
> https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
>
> which seem to have managed to boot somehow. It's a minnowboard with no
> video and it's booting to a ramdisk, I don't know if either of those
> helped avoid the issue.
>
Either that or it is related to the kernel configuration (which, in my case,
was picked from an old yocto version).
Guenter
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 13:18 ` Guenter Roeck
@ 2017-05-24 15:08 ` Mark Brown
0 siblings, 0 replies; 121+ messages in thread
From: Mark Brown @ 2017-05-24 15:08 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On Wed, May 24, 2017 at 06:18:00AM -0700, Guenter Roeck wrote:
> On 05/24/2017 05:58 AM, Mark Brown wrote:
> > which seem to have managed to boot somehow. It's a minnowboard with no
> > video and it's booting to a ramdisk, I don't know if either of those
> > helped avoid the issue.
> Either that or it is related to the kernel configuration (which, in my case,
> was picked from an old yocto version).
Yeah, kernelci is using upstream defconfigs plus a couple of defconfig+X
things. What's the config you're using, perhaps there's some options
that we ought to be adding somewhere for coverage?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-24 12:58 ` Mark Brown
2017-05-24 13:18 ` Guenter Roeck
@ 2017-05-24 13:33 ` Guenter Roeck
1 sibling, 0 replies; 121+ messages in thread
From: Guenter Roeck @ 2017-05-24 13:33 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, kernelci.org bot, linux-kernel, torvalds,
akpm, shuahkh, patches, ben.hutchings, stable
On 05/24/2017 05:58 AM, Mark Brown wrote:
> On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
>> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:
>
>>> 54 passed? I had a bug here such that all x86 builds were crashing, in
>>> the core tty layer, which seems odd that anything would be able to boot
>>> with this tree...
>
>> Final qemu test result was
>> total: 115 pass: 89 fail: 26
>> with only the x86 and x86_64 images crashing, so this isn't entirely surprising,
>> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.
>
> Not qemu but it has some physical x86 tests like:
>
> https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html
>
> which seem to have managed to boot somehow. It's a minnowboard with no
> video and it's booting to a ramdisk, I don't know if either of those
> helped avoid the issue.
>
I had another look; it may be related to the configuration. Turns out
I also had crashes in some mips64 and ppc/ppc64 tests, but not all of
them. For example, mips64 big endian crashed, but the same configuration
little endian passed.
I think I'll add some config file variations to my x86 tests.
Guenter
^ permalink raw reply [flat|nested] 121+ messages in thread
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
2017-05-23 20:08 [PATCH 4.4 000/103] 4.4.70-stable review Greg Kroah-Hartman
` (96 preceding siblings ...)
[not found] ` <59252147.91471c0a.7a474.26e6@mx.google.com>
@ 2017-05-24 20:22 ` Guenter Roeck
97 siblings, 0 replies; 121+ messages in thread
From: Guenter Roeck @ 2017-05-24 20:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Tue, May 23, 2017 at 10:08:26PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.70 release.
> There are 103 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:08:25 UTC 2017.
> Anything received after that time might be too late.
>
Note: This set of results is for v4.4.69-102-g3a21698.
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 121+ messages in thread