Skip to contentSkip to conversation

4.19.7-stable review

PATCH In review Greg Kroah-Hartman 10 participants 156 messages Dec 4, 2018 – Dec 13, 2018 Page 2 of 2

Subsystems (4)
lore
Share & tools
lore
author maintainer
#136 lore raw

PATCH 133/139 iio/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbers

In reply to Greg Kroah-Hartman

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

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

From: Hans de Goede <[email protected]>

commit 0145b50566e7de5637e80ecba96c7f0e6fff1aad upstream.

Before this commit sensor_hub_input_attr_get_raw_value() failed to take the signedness of 16 and 8 bit values into account, returning e.g. 65436 instead of -100 for the z-axis reading of an accelerometer.

This commit adds a new is_signed parameter to the function and makes all callers pass the appropriate value for this.

While at it, this commit also fixes up some neighboring lines where statements were needlessly split over 2 lines to improve readability.

---
 drivers/hid/hid-sensor-custom.c                  |    2 +-
 drivers/hid/hid-sensor-hub.c                     |   13 ++++++++++---
 drivers/iio/accel/hid-sensor-accel-3d.c          |    5 ++++-
 drivers/iio/gyro/hid-sensor-gyro-3d.c            |    5 ++++-
 drivers/iio/humidity/hid-sensor-humidity.c       |    3 ++-
 drivers/iio/light/hid-sensor-als.c               |    8 +++++---
 drivers/iio/light/hid-sensor-prox.c              |    8 +++++---
 drivers/iio/magnetometer/hid-sensor-magn-3d.c    |    8 +++++---
 drivers/iio/orientation/hid-sensor-incl-3d.c     |    8 +++++---
 drivers/iio/pressure/hid-sensor-press.c          |    8 +++++---
 drivers/iio/temperature/hid-sensor-temperature.c |    3 ++-
 drivers/rtc/rtc-hid-sensor-time.c                |    2 +-
 include/linux/hid-sensor-hub.h                   |    4 +++-
 13 files changed, 52 insertions(+), 25 deletions(-)
drivers/hid/hid-sensor-custom.c +1 -1
@@ -358,7 +358,7 @@ static ssize_t show_value(struct device
 						sensor_inst->hsdev,
 						sensor_inst->hsdev->usage,
 						usage, report_id,
-						SENSOR_HUB_SYNC);
+						SENSOR_HUB_SYNC, false);
 	} else if (!strncmp(name, "units", strlen("units")))
 		value = sensor_inst->fields[field_index].attribute.units;
 	else if (!strncmp(name, "unit-expo", strlen("unit-expo")))
drivers/hid/hid-sensor-hub.c +10 -3
@@ -299,7 +299,8 @@ EXPORT_SYMBOL_GPL(sensor_hub_get_feature
 int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
 					u32 usage_id,
 					u32 attr_usage_id, u32 report_id,
-					enum sensor_hub_read_flags flag)
+					enum sensor_hub_read_flags flag,
+					bool is_signed)
 {
 	struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
 	unsigned long flags;
@@ -331,10 +332,16 @@ int sensor_hub_input_attr_get_raw_value(
 						&hsdev->pending.ready, HZ*5);
 		switch (hsdev->pending.raw_size) {
 		case 1:
-			ret_val = *(u8 *)hsdev->pending.raw_data;
+			if (is_signed)
+				ret_val = *(s8 *)hsdev->pending.raw_data;
+			else
+				ret_val = *(u8 *)hsdev->pending.raw_data;
 			break;
 		case 2:
-			ret_val = *(u16 *)hsdev->pending.raw_data;
+			if (is_signed)
+				ret_val = *(s16 *)hsdev->pending.raw_data;
+			else
+				ret_val = *(u16 *)hsdev->pending.raw_data;
 			break;
 		case 4:
 			ret_val = *(u32 *)hsdev->pending.raw_data;
drivers/iio/accel/hid-sensor-accel-3d.c +4 -1
@@ -149,6 +149,7 @@ static int accel_3d_read_raw(struct iio_
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 	struct hid_sensor_hub_device *hsdev =
 					accel_state->common_attributes.hsdev;
 
@@ -158,12 +159,14 @@ static int accel_3d_read_raw(struct iio_
 	case IIO_CHAN_INFO_RAW:
 		hid_sensor_power_state(&accel_state->common_attributes, true);
 		report_id = accel_state->accel[chan->scan_index].report_id;
+		min = accel_state->accel[chan->scan_index].logical_minimum;
 		address = accel_3d_addresses[chan->scan_index];
 		if (report_id >= 0)
 			*val = sensor_hub_input_attr_get_raw_value(
 					accel_state->common_attributes.hsdev,
 					hsdev->usage, address, report_id,
-					SENSOR_HUB_SYNC);
+					SENSOR_HUB_SYNC,
+					min < 0);
 		else {
 			*val = 0;
 			hid_sensor_power_state(&accel_state->common_attributes,
drivers/iio/gyro/hid-sensor-gyro-3d.c +4 -1
@@ -111,6 +111,7 @@ static int gyro_3d_read_raw(struct iio_d
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 
 	*val = 0;
 	*val2 = 0;
@@ -118,13 +119,15 @@ static int gyro_3d_read_raw(struct iio_d
 	case IIO_CHAN_INFO_RAW:
 		hid_sensor_power_state(&gyro_state->common_attributes, true);
 		report_id = gyro_state->gyro[chan->scan_index].report_id;
+		min = gyro_state->gyro[chan->scan_index].logical_minimum;
 		address = gyro_3d_addresses[chan->scan_index];
 		if (report_id >= 0)
 			*val = sensor_hub_input_attr_get_raw_value(
 					gyro_state->common_attributes.hsdev,
 					HID_USAGE_SENSOR_GYRO_3D, address,
 					report_id,
-					SENSOR_HUB_SYNC);
+					SENSOR_HUB_SYNC,
+					min < 0);
 		else {
 			*val = 0;
 			hid_sensor_power_state(&gyro_state->common_attributes,
drivers/iio/humidity/hid-sensor-humidity.c +2 -1
@@ -75,7 +75,8 @@ static int humidity_read_raw(struct iio_
 				HID_USAGE_SENSOR_HUMIDITY,
 				HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY,
 				humid_st->humidity_attr.report_id,
-				SENSOR_HUB_SYNC);
+				SENSOR_HUB_SYNC,
+				humid_st->humidity_attr.logical_minimum < 0);
 		hid_sensor_power_state(&humid_st->common_attributes, false);
 
 		return IIO_VAL_INT;
drivers/iio/light/hid-sensor-als.c +5 -3
@@ -93,6 +93,7 @@ static int als_read_raw(struct iio_dev *
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 
 	*val = 0;
 	*val2 = 0;
@@ -102,8 +103,8 @@ static int als_read_raw(struct iio_dev *
 		case  CHANNEL_SCAN_INDEX_INTENSITY:
 		case  CHANNEL_SCAN_INDEX_ILLUM:
 			report_id = als_state->als_illum.report_id;
-			address =
-			HID_USAGE_SENSOR_LIGHT_ILLUM;
+			min = als_state->als_illum.logical_minimum;
+			address = HID_USAGE_SENSOR_LIGHT_ILLUM;
 			break;
 		default:
 			report_id = -1;
@@ -116,7 +117,8 @@ static int als_read_raw(struct iio_dev *
 					als_state->common_attributes.hsdev,
 					HID_USAGE_SENSOR_ALS, address,
 					report_id,
-					SENSOR_HUB_SYNC);
+					SENSOR_HUB_SYNC,
+					min < 0);
 			hid_sensor_power_state(&als_state->common_attributes,
 						false);
 		} else {
drivers/iio/light/hid-sensor-prox.c +5 -3
@@ -73,6 +73,7 @@ static int prox_read_raw(struct iio_dev
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 
 	*val = 0;
 	*val2 = 0;
@@ -81,8 +82,8 @@ static int prox_read_raw(struct iio_dev
 		switch (chan->scan_index) {
 		case  CHANNEL_SCAN_INDEX_PRESENCE:
 			report_id = prox_state->prox_attr.report_id;
-			address =
-			HID_USAGE_SENSOR_HUMAN_PRESENCE;
+			min = prox_state->prox_attr.logical_minimum;
+			address = HID_USAGE_SENSOR_HUMAN_PRESENCE;
 			break;
 		default:
 			report_id = -1;
@@ -95,7 +96,8 @@ static int prox_read_raw(struct iio_dev
 				prox_state->common_attributes.hsdev,
 				HID_USAGE_SENSOR_PROX, address,
 				report_id,
-				SENSOR_HUB_SYNC);
+				SENSOR_HUB_SYNC,
+				min < 0);
 			hid_sensor_power_state(&prox_state->common_attributes,
 						false);
 		} else {
drivers/iio/magnetometer/hid-sensor-magn-3d.c +5 -3
@@ -163,21 +163,23 @@ static int magn_3d_read_raw(struct iio_d
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 
 	*val = 0;
 	*val2 = 0;
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
 		hid_sensor_power_state(&magn_state->magn_flux_attributes, true);
-		report_id =
-			magn_state->magn[chan->address].report_id;
+		report_id = magn_state->magn[chan->address].report_id;
+		min = magn_state->magn[chan->address].logical_minimum;
 		address = magn_3d_addresses[chan->address];
 		if (report_id >= 0)
 			*val = sensor_hub_input_attr_get_raw_value(
 				magn_state->magn_flux_attributes.hsdev,
 				HID_USAGE_SENSOR_COMPASS_3D, address,
 				report_id,
-				SENSOR_HUB_SYNC);
+				SENSOR_HUB_SYNC,
+				min < 0);
 		else {
 			*val = 0;
 			hid_sensor_power_state(
drivers/iio/orientation/hid-sensor-incl-3d.c +5 -3
@@ -111,21 +111,23 @@ static int incl_3d_read_raw(struct iio_d
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 
 	*val = 0;
 	*val2 = 0;
 	switch (mask) {
 	case IIO_CHAN_INFO_RAW:
 		hid_sensor_power_state(&incl_state->common_attributes, true);
-		report_id =
-			incl_state->incl[chan->scan_index].report_id;
+		report_id = incl_state->incl[chan->scan_index].report_id;
+		min = incl_state->incl[chan->scan_index].logical_minimum;
 		address = incl_3d_addresses[chan->scan_index];
 		if (report_id >= 0)
 			*val = sensor_hub_input_attr_get_raw_value(
 				incl_state->common_attributes.hsdev,
 				HID_USAGE_SENSOR_INCLINOMETER_3D, address,
 				report_id,
-				SENSOR_HUB_SYNC);
+				SENSOR_HUB_SYNC,
+				min < 0);
 		else {
 			hid_sensor_power_state(&incl_state->common_attributes,
 						false);
drivers/iio/pressure/hid-sensor-press.c +5 -3
@@ -77,6 +77,7 @@ static int press_read_raw(struct iio_dev
 	int report_id = -1;
 	u32 address;
 	int ret_type;
+	s32 min;
 
 	*val = 0;
 	*val2 = 0;
@@ -85,8 +86,8 @@ static int press_read_raw(struct iio_dev
 		switch (chan->scan_index) {
 		case  CHANNEL_SCAN_INDEX_PRESSURE:
 			report_id = press_state->press_attr.report_id;
-			address =
-			HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE;
+			min = press_state->press_attr.logical_minimum;
+			address = HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE;
 			break;
 		default:
 			report_id = -1;
@@ -99,7 +100,8 @@ static int press_read_raw(struct iio_dev
 				press_state->common_attributes.hsdev,
 				HID_USAGE_SENSOR_PRESSURE, address,
 				report_id,
-				SENSOR_HUB_SYNC);
+				SENSOR_HUB_SYNC,
+				min < 0);
 			hid_sensor_power_state(&press_state->common_attributes,
 						false);
 		} else {
drivers/iio/temperature/hid-sensor-temperature.c +2 -1
@@ -76,7 +76,8 @@ static int temperature_read_raw(struct i
 			HID_USAGE_SENSOR_TEMPERATURE,
 			HID_USAGE_SENSOR_DATA_ENVIRONMENTAL_TEMPERATURE,
 			temp_st->temperature_attr.report_id,
-			SENSOR_HUB_SYNC);
+			SENSOR_HUB_SYNC,
+			temp_st->temperature_attr.logical_minimum < 0);
 		hid_sensor_power_state(
 				&temp_st->common_attributes,
 				false);
drivers/rtc/rtc-hid-sensor-time.c +1 -1
@@ -213,7 +213,7 @@ static int hid_rtc_read_time(struct devi
 	/* get a report with all values through requesting one value */
 	sensor_hub_input_attr_get_raw_value(time_state->common_attributes.hsdev,
 			HID_USAGE_SENSOR_TIME, hid_time_addresses[0],
-			time_state->info[0].report_id, SENSOR_HUB_SYNC);
+			time_state->info[0].report_id, SENSOR_HUB_SYNC, false);
 	/* wait for all values (event) */
 	ret = wait_for_completion_killable_timeout(
 			&time_state->comp_last_time, HZ*6);
include/linux/hid-sensor-hub.h +3 -1
@@ -177,6 +177,7 @@ int sensor_hub_input_get_attribute_info(
 * @attr_usage_id:	Attribute usage id as per spec
 * @report_id:	Report id to look for
 * @flag:      Synchronous or asynchronous read
+* @is_signed:   If true then fields < 32 bits will be sign-extended
 *
 * Issues a synchronous or asynchronous read request for an input attribute.
 * Returns data upto 32 bits.
@@ -190,7 +191,8 @@ enum sensor_hub_read_flags {
 int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
  					u32 usage_id,
  					u32 attr_usage_id, u32 report_id,
- 					enum sensor_hub_read_flags flag
+					enum sensor_hub_read_flags flag,
+					bool is_signed
 );
 
 /**
author maintainer
#137 lore raw

PATCH 134/139 iio:st_magn: Fix enable device after trigger

In reply to Greg Kroah-Hartman

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

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

From: Martin Kelly <[email protected]>

commit fe5192ac81ad0d4dfe1395d11f393f0513c15f7f upstream.

Currently, we enable the device before we enable the device trigger. At high frequencies, this can cause interrupts that don't yet have a poll function associated with them and are thus treated as spurious. At high frequencies with level interrupts, this can even cause an interrupt storm of repeated spurious interrupts (~100,000 on my Beagleboard with the LSM9DS1 magnetometer). If these repeat too much, the interrupt will get disabled and the device will stop functioning.

To prevent these problems, enable the device prior to enabling the device trigger, and disable the divec prior to disabling the trigger. This means there's no window of time during which the device creates interrupts but we have no trigger to answer them.

Fixes 90efe055629 ("iio: st_sensors: harden interrupt handling")
---
 drivers/iio/magnetometer/st_magn_buffer.c |   12 +++---------
 1 file changed, 3 insertions(+), 9 deletions(-)
drivers/iio/magnetometer/st_magn_buffer.c +3 -9
@@ -30,11 +30,6 @@ int st_magn_trig_set_state(struct iio_tr
 	return st_sensors_set_dataready_irq(indio_dev, state);
 }
 
-static int st_magn_buffer_preenable(struct iio_dev *indio_dev)
-{
-	return st_sensors_set_enable(indio_dev, true);
-}
-
 static int st_magn_buffer_postenable(struct iio_dev *indio_dev)
 {
 	int err;
@@ -50,7 +45,7 @@ static int st_magn_buffer_postenable(str
 	if (err < 0)
 		goto st_magn_buffer_postenable_error;
 
-	return err;
+	return st_sensors_set_enable(indio_dev, true);
 
 st_magn_buffer_postenable_error:
 	kfree(mdata->buffer_data);
@@ -63,11 +58,11 @@ static int st_magn_buffer_predisable(str
 	int err;
 	struct st_sensor_data *mdata = iio_priv(indio_dev);
 
-	err = iio_triggered_buffer_predisable(indio_dev);
+	err = st_sensors_set_enable(indio_dev, false);
 	if (err < 0)
 		goto st_magn_buffer_predisable_error;
 
-	err = st_sensors_set_enable(indio_dev, false);
+	err = iio_triggered_buffer_predisable(indio_dev);
 
 st_magn_buffer_predisable_error:
 	kfree(mdata->buffer_data);
@@ -75,7 +70,6 @@ st_magn_buffer_predisable_error:
 }
 
 static const struct iio_buffer_setup_ops st_magn_buffer_setup_ops = {
-	.preenable = &st_magn_buffer_preenable,
 	.postenable = &st_magn_buffer_postenable,
 	.predisable = &st_magn_buffer_predisable,
 };
author maintainer
#138 lore raw

PATCH 135/139 lib/test_kmod.c: fix rmmod double free

In reply to Greg Kroah-Hartman

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

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

From: Luis Chamberlain <[email protected]>

commit 5618cf031fecda63847cafd1091e7b8bd626cdb1 upstream.

We free the misc device string twice on rmmod; fix this. Without this we cannot remove the module without crashing.

---
 lib/test_kmod.c |    1 -
 1 file changed, 1 deletion(-)
lib/test_kmod.c +0 -1
@@ -1214,7 +1214,6 @@ void unregister_test_dev_kmod(struct kmo
 
 	dev_info(test_dev->dev, "removing interface\n");
 	misc_deregister(&test_dev->misc_dev);
-	kfree(&test_dev->misc_dev.name);
 
 	mutex_unlock(&test_dev->config_mutex);
 	mutex_unlock(&test_dev->trigger_mutex);
author maintainer
#139 lore raw

PATCH 136/139 mm: cleancache: fix corruption on missed inode invalidation

In reply to Greg Kroah-Hartman

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

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

From: Pavel Tikhomirov <[email protected]>

commit 6ff38bd40230af35e446239396e5fc8ebd6a5248 upstream.

If all pages are deleted from the mapping by memory reclaim and also moved to the cleancache:

__delete_from_page_cache
(no shadow case)
unaccount_page_cache_page
cleancache_put_page
page_cache_delete
mapping->nrpages -= nr
(nrpages becomes 0)

We don't clean the cleancache for an inode after final file truncation (removal).

truncate_inode_pages_final
check (nrpages || nrexceptional) is false
no truncate_inode_pages
no cleancache_invalidate_inode(mapping)

These way when reading the new file created with same inode we may get these trash leftover pages from cleancache and see wrong data instead of the contents of the new file.

Fix it by always doing truncate_inode_pages which is already ready for nrpages == 0 && nrexceptional == 0 case and just invalidates inode.

[[email protected]: add comment, per Jan]
Fixes commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")
Cc Johannes Weiner <[email protected]>
Cc Mel Gorman <[email protected]>
Cc Matthew Wilcox <[email protected]>
Cc Andi Kleen <[email protected]>
---
 mm/truncate.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
mm/truncate.c +6 -2
@@ -520,9 +520,13 @@ void truncate_inode_pages_final(struct a
 		 */
 		xa_lock_irq(&mapping->i_pages);
 		xa_unlock_irq(&mapping->i_pages);
-
-		truncate_inode_pages(mapping, 0);
 	}
+
+	/*
+	 * Cleancache needs notification even if there are no pages or shadow
+	 * entries.
+	 */
+	truncate_inode_pages(mapping, 0);
 }
 EXPORT_SYMBOL(truncate_inode_pages_final);
 
author maintainer
#140 lore raw

PATCH 137/139 mm: use swp_offset as key in shmem_replace_page()

In reply to Greg Kroah-Hartman

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

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

From: Yu Zhao <[email protected]>

commit c1cb20d43728aa9b5393bd8d489bc85c142949b2 upstream.

We changed the key of swap cache tree from swp_entry_t.val to swp_offset. We need to do so in shmem_replace_page() as well.

Hugh said:
"shmem_replace_page() has been wrong since the day I wrote it: good
enough to work on swap "type" 0, which is all most people ever use (especially those few who need shmem_replace_page() at all), but broken once there are any non-0 swp_type bits set in the higher order bits"

---
 mm/shmem.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
mm/shmem.c +4 -2
@@ -1551,11 +1551,13 @@ static int shmem_replace_page(struct pag
 {
 	struct page *oldpage, *newpage;
 	struct address_space *swap_mapping;
+	swp_entry_t entry;
 	pgoff_t swap_index;
 	int error;
 
 	oldpage = *pagep;
-	swap_index = page_private(oldpage);
+	entry.val = page_private(oldpage);
+	swap_index = swp_offset(entry);
 	swap_mapping = page_mapping(oldpage);
 
 	/*
@@ -1574,7 +1576,7 @@ static int shmem_replace_page(struct pag
 	__SetPageLocked(newpage);
 	__SetPageSwapBacked(newpage);
 	SetPageUptodate(newpage);
-	set_page_private(newpage, swap_index);
+	set_page_private(newpage, entry.val);
 	SetPageSwapCache(newpage);
 
 	/*
author maintainer
#141 lore raw

PATCH 138/139 Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()

In reply to Greg Kroah-Hartman

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

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

From: Dexuan Cui <[email protected]>

commit eceb05965489784f24bbf4d61ba60e475a983016 upstream.

This is a longstanding issue: if the vmbus upper-layer drivers try to consume too many GPADLs, the host may return with an error 0xC0000044 (STATUS_QUOTA_EXCEEDED), but currently we forget to check the creation_status, and hence we can pass an invalid GPADL handle into the OPEN_CHANNEL message, and get an error code 0xc0000225 in open_info->response.open_result.status, and finally we hang in vmbus_open() -> "goto error_free_info" -> vmbus_teardown_gpadl().

With this patch, we can exit gracefully on STATUS_QUOTA_EXCEEDED.

---
 drivers/hv/channel.c |    8 ++++++++
 1 file changed, 8 insertions(+)
drivers/hv/channel.c +8 -0
@@ -482,6 +482,14 @@ int vmbus_establish_gpadl(struct vmbus_c
 	}
 	wait_for_completion(&msginfo->waitevent);
 
+	if (msginfo->response.gpadl_created.creation_status != 0) {
+		pr_err("Failed to establish GPADL: err = 0x%x\n",
+		       msginfo->response.gpadl_created.creation_status);
+
+		ret = -EDQUOT;
+		goto cleanup;
+	}
+
 	if (channel->rescind) {
 		ret = -ENODEV;
 		goto cleanup;
author maintainer
#142 lore raw

PATCH 139/139 misc: mic/scif: fix copy-paste error in scif_create_remote_lookup

In reply to Greg Kroah-Hartman

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

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

From: YueHaibing <[email protected]>

commit 6484a677294aa5d08c0210f2f387ebb9be646115 upstream.

gcc '-Wunused-but-set-variable' warning:

drivers/misc/mic/scif/scif_rma.c: In function 'scif_create_remote_lookup':
drivers/misc/mic/scif/scif_rma.c:373:25: warning:
variable 'vmalloc_num_pages' set but not used [-Wunused-but-set-variable]

'vmalloc_num_pages' should be used to determine if the address is within the vmalloc range.

Fixes ba612aa8b487 ("misc: mic: SCIF memory registration and unregistration")
Cc stable <[email protected]>
---
 drivers/misc/mic/scif/scif_rma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/misc/mic/scif/scif_rma.c +1 -1
@@ -416,7 +416,7 @@ static int scif_create_remote_lookup(str
 		if (err)
 			goto error_window;
 		err = scif_map_page(&window->num_pages_lookup.lookup[j],
-				    vmalloc_dma_phys ?
+				    vmalloc_num_pages ?
 				    vmalloc_to_page(&window->num_pages[i]) :
 				    virt_to_page(&window->num_pages[i]),
 				    remote_dev);
#143 lore raw
In reply to Greg Kroah-Hartman
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 117 passed with 2 offline, 1 untried/unknown (v4.19.6-140-g987a6da5152c)

stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 117 passed with 2 offline, 1 untried/unknown (v4.19.6-140-g987a6da5152c)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.6-140-g987a6da5152c/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.6-140-g987a6da5152c/

Tree: stable-rc
Branch: linux-4.19.y
Git Describe: v4.19.6-140-g987a6da5152c
Git Commit: 987a6da5152c29e37cc11de9a2d10a23a48015c9
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 62 unique boards, 23 SoC families, 15 builds out of 202

Offline Platforms:

arm:

    multi_v7_defconfig:
        stih410-b2120: 1 offline lab

arm64:

    defconfig:
        meson-gxl-s905x-p212: 1 offline lab

---
For more info write to <[email protected]>

#144 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

During functional tests for this v4.19 release, we faced a PANIC, described bellow, but unlikely related to this specific v4.19 version.

First a WARN() at tcp_output.c:

tcp_send_loss_probe():
...

	/* Retransmit last segment. */
	if (WARN_ON(!skb))
		goto rearm_timer;

...

[  173.557528] WARNING: CPU: 1 PID: 0 at
/srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485
tcp_send_loss_probe+0x164/0x1e8
[  173.571425] Modules linked in: crc32_ce crct10dif_ce fuse
[  173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1
[  173.583014] Hardware name: ARM Juno development board (r2) (DT)
[  173.588879] pstate: 60000005 (nZCv daif -PAN -UAO)
[  173.593629] pc : tcp_send_loss_probe+0x164/0x1e8
[  173.598205] lr : tcp_send_loss_probe+0x70/0x1e8
[  173.602692] sp : ffff00000800bcc0
[  173.605976] x29: ffff00000800bcc0 x28: 0000000000000002
[  173.611251] x27: 0000000000000001 x26: ffff00000961fac0
[  173.616525] x25: ffff000008ce8d88 x24: ffff00000961f000
[  173.621799] x23: ffff800974fb2000 x22: ffff800974fb2008
[  173.627073] x21: 00000000000005a8 x20: 0000000000000000
[  173.632346] x19: ffff800974fb1f80 x18: 0000000000000000
[  173.637620] x17: 0000000000000000 x16: 0000000000000000
[  173.642893] x15: 0000000000000000 x14: 0000000000000000
[  173.648167] x13: 000000009100ad59 x12: ffff800976a14b68
[  173.653440] x11: 0000000000000001 x10: ffff00000961f848
[  173.658713] x9 : ffff0000096a8000 x8 : ffff00000961f848
[  173.663987] x7 : ffff000008ce8dcc x6 : 000000015808f2bf
[  173.669260] x5 : 00ffffffffffffff x4 : 0000000000000015
[  173.674534] x3 : 0000000000000002 x2 : 0000000000000020
[  173.679808] x1 : ffff800974fb21d0 x0 : 0000000000000000
[  173.685081] Call trace:
[  173.687507]  tcp_send_loss_probe+0x164/0x1e8
[  173.691738]  tcp_write_timer_handler+0xf8/0x250
[  173.696226]  tcp_write_timer+0xe0/0x110
[  173.700030]  call_timer_fn+0xbc/0x3f0
[  173.703660]  expire_timers+0x104/0x220
[  173.707376]  run_timer_softirq+0xec/0x1a8
[  173.711349]  __do_softirq+0x114/0x554
[  173.714978]  irq_exit+0x144/0x150
[  173.718263]  __handle_domain_irq+0x6c/0xc0
[  173.722321]  gic_handle_irq+0x60/0xb0
[  173.725949]  el1_irq+0xb4/0x130
[  173.729065]  cpuidle_enter_state+0xbc/0x3f0
[  173.733210]  cpuidle_enter+0x34/0x48
[  173.736753]  call_cpuidle+0x44/0x78
[  173.740209]  do_idle+0x238/0x2b8
[  173.743407]  cpu_startup_entry+0x2c/0x30
[  173.747295]  secondary_start_kernel+0x190/0x1d8
[  173.751782] irq event stamp: 1502997
[  173.755330] hardirqs last  enabled at (1502996): [<ffff000008e53c98>]
_raw_spin_unlock_irq+0x38/0x80
[  173.764377] hardirqs last disabled at (1502997): [<ffff0000080814fc>]
do_debug_exception+0x164/0x1a8
[  173.773424] softirqs last  enabled at (1502992): [<ffff0000080f6df0>]
_local_bh_enable+0x28/0x48
[  173.782128] softirqs last disabled at (1502993): [<ffff0000080f74fc>]

irq_exit+0x144/0x150

right after, a NULL dereference at tcp_rearm_rto():

[  173.794928] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000020
[  173.803649] Mem abort info:
[  173.806437]   ESR = 0x96000004
[  173.809484]   Exception class = DABT (current EL), IL = 32 bits
[  173.815368]   SET = 0, FnV = 0
[  173.818412]   EA = 0, S1PTW = 0
[  173.821543] Data abort info:
[  173.824399]   ISV = 0, ISS = 0x00000004
[  173.828217]   CM = 0, WnR = 0
[  173.831178] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000003f5193ed
[  173.837749] [0000000000000020] pgd=0000000000000000
[  173.842732] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[  173.848251] Modules linked in: crc32_ce crct10dif_ce fuse
[  173.853618] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W
4.19.7-rc1 #1
[  173.861198] Hardware name: ARM Juno development board (r2) (DT)
[  173.867060] pstate: 80000005 (Nzcv daif -PAN -UAO)
[  173.871805] pc : tcp_rearm_rto.part.38+0x7c/0xa8
[  173.876378] lr : tcp_rearm_rto.part.38+0x7c/0xa8
[  173.880948] sp : ffff00000800bc80
[  173.884228] x29: ffff00000800bc80 x28: 0000000000000002
[  173.889497] x27: 0000000000000001 x26: ffff00000961fac0
[  173.894765] x25: ffff000008ce8d88 x24: ffff00000961f000
[  173.900034] x23: ffff800974fb2000 x22: ffff800974fb2008
[  173.905302] x21: 00000000000005a8 x20: 0000000000000000
[  173.910570] x19: ffff800974fb1f80 x18: 0000000000000000
[  173.915838] x17: 0000000000000000 x16: 0000000000000000
[  173.921106] x15: 0000000000000000 x14: 0000000000000000
[  173.926374] x13: 000000009100ad59 x12: ffff800976a14b68
[  173.931642] x11: 0000000000000001 x10: ffff00000961f848
[  173.936910] x9 : ffff0000096a8000 x8 : ffff00000961f848
[  173.942178] x7 : ffff000008ce8dcc x6 : 000000015808f2bf
[  173.947446] x5 : 00ffffffffffffff x4 : 0000000000000015
[  173.952714] x3 : 0000000000000002 x2 : 0000000000000020
[  173.957982] x1 : ffff800974fb21d0 x0 : 0000000000000000
[  173.963252] Process swapper/1 (pid: 0, stack limit = 0x000000000f373131)
[  173.969886] Call trace:
[  173.972308]  tcp_rearm_rto.part.38+0x7c/0xa8
[  173.976536]  tcp_rearm_rto+0x40/0x60
[  173.980077]  tcp_send_loss_probe+0xc8/0x1e8
[  173.984218]  tcp_write_timer_handler+0xf8/0x250
[  173.988703]  tcp_write_timer+0xe0/0x110
[  173.992502]  call_timer_fn+0xbc/0x3f0
[  173.996129]  expire_timers+0x104/0x220
[  173.999841]  run_timer_softirq+0xec/0x1a8
[  174.003810]  __do_softirq+0x114/0x554
[  174.007436]  irq_exit+0x144/0x150
[  174.010717]  __handle_domain_irq+0x6c/0xc0
[  174.014773]  gic_handle_irq+0x60/0xb0
[  174.018398]  el1_irq+0xb4/0x130
[  174.021509]  cpuidle_enter_state+0xbc/0x3f0
[  174.025651]  cpuidle_enter+0x34/0x48
[  174.029190]  call_cpuidle+0x44/0x78
[  174.032643]  do_idle+0x238/0x2b8
[  174.035838]  cpu_startup_entry+0x2c/0x30
[  174.039722]  secondary_start_kernel+0x190/0x1d8
[  174.044209] Code: d65f03c0 f9000fb4 91092260 94059dd4 (f9401014)

Since this was a 1 time failure, and we couldn't reproduce it again, we couldn't KASAN the dereference, unfortunately.

Thanks,

Signature · 2 lines
Rafael D. Tinoco
Linaro - Kernel Validation
author maintainer
#145 lore raw
Quoted 29 lines · Rafael David Tinoco
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

During functional tests for this v4.19 release, we faced a PANIC, described bellow, but unlikely related to this specific v4.19 version.

First a WARN() at tcp_output.c:

tcp_send_loss_probe():
...

	/* Retransmit last segment. */
	if (WARN_ON(!skb))
		goto rearm_timer;
Quoted 8 lines

...

[  173.557528] WARNING: CPU: 1 PID: 0 at
/srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485
tcp_send_loss_probe+0x164/0x1e8
[  173.571425] Modules linked in: crc32_ce crct10dif_ce fuse
[  173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1
[  173.583014] Hardware name: ARM Juno development board (r2) (DT)

So only this one machine saw this failure?

If you can reproduce it again, bisection would be great to do if possible.

thanks,

greg k-h

#146 lore raw
Quoted 39 lines · Greg Kroah-Hartman
Quoted 29 lines · Rafael David Tinoco
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

During functional tests for this v4.19 release, we faced a PANIC, described bellow, but unlikely related to this specific v4.19 version.

First a WARN() at tcp_output.c:

tcp_send_loss_probe():
...

	/* Retransmit last segment. */
	if (WARN_ON(!skb))
		goto rearm_timer;
Quoted 8 lines

...

[  173.557528] WARNING: CPU: 1 PID: 0 at
/srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485
tcp_send_loss_probe+0x164/0x1e8
[  173.571425] Modules linked in: crc32_ce crct10dif_ce fuse
[  173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1
[  173.583014] Hardware name: ARM Juno development board (r2) (DT)
Quoted 4 lines

So only this one machine saw this failure?

If you can reproduce it again, bisection would be great to do if possible.

Yes, the only machine... I'm afraid this issue is intermittent and depends on TCP Tail Loss and a specific race causing the NULL dereference, so bisection would be tricky since it has happened independently of the functional test that was running. I have also copied authors for the Tail Loss code to check if they got any clues even without KASAN data.

Thank you,
-
Rafael D. Tinoco

#147 lore raw
Quoted 46 lines · Rafael David Tinoco
Quoted 39 lines · Greg Kroah-Hartman
Quoted 29 lines · Rafael David Tinoco
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
    https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

During functional tests for this v4.19 release, we faced a PANIC, described bellow, but unlikely related to this specific v4.19 version.

First a WARN() at tcp_output.c:

tcp_send_loss_probe():
...

     /* Retransmit last segment. */
     if (WARN_ON(!skb))
             goto rearm_timer;
Quoted 8 lines

...

[  173.557528] WARNING: CPU: 1 PID: 0 at
/srv/oe/build/tmp-rpb-glibc/work-shared/juno/kernel-source/net/ipv4/tcp_output.c:2485
tcp_send_loss_probe+0x164/0x1e8
[  173.571425] Modules linked in: crc32_ce crct10dif_ce fuse
[  173.576804] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.7-rc1 #1
[  173.583014] Hardware name: ARM Juno development board (r2) (DT)
Quoted 4 lines

So only this one machine saw this failure?

If you can reproduce it again, bisection would be great to do if possible.

Quoted 6 lines

Yes, the only machine... I'm afraid this issue is intermittent and depends on TCP Tail Loss and a specific race causing the NULL dereference, so bisection would be tricky since it has happened independently of the functional test that was running. I have also copied authors for the Tail Loss code to check if they got any clues even without KASAN data.

There cause is an inconsistency of packet accounting: TCP retransmission queue is empty but tp->packets_out is not zero. We will send a fix soon. Thanks.

Quoted 5 lines

Thank you,
-
Rafael D. Tinoco

#148 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 159 pass: 159 fail: 0
Qemu test results:
	total: 337 pass: 337 fail: 0

Details are available at https://kerneltests.org/builders/.

Guenter

author maintainer
#149 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

Quoted 6 lines

Build results:

	total: 159 pass: 159 fail: 0
Qemu test results:
	total: 337 pass: 337 fail: 0

Details are available at https://kerneltests.org/builders/.

Thanks for testing all 3 of these and letting me know.

greg k-h

#150 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz
Quoted 8 lines

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

Peachy as usual on the Lenovo IdeaPad 330-15ARR, no dmesg regressions.

Signature · 2 lines
Harsh Shandilya
PRJKT Development LLC
author maintainer
#151 lore raw
Quoted 16 lines · Harsh Shandilya
Quoted 15 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-4.19.y
and the diffstat can be found below.

Quoted 4 lines
Quoted 3 lines

thanks,

greg k-h

Peachy as usual on the Lenovo IdeaPad 330-15ARR, no dmesg regressions.

Great, thanks for testing and letting me know.

greg k-h

#152 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

Note: As a consequence of the retpoline backport, we upgraded our toolchain that is used to build the kernel and userspace from 7.0 to 7.3 (containing retpoline support).

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.19.7-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 987a6da5152c29e37cc11de9a2d10a23a48015c9 git describe: v4.19.6-140-g987a6da5152c
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.6-140-g987a6da5152c

No Regressions (compared to build v4.19.6)

No Fixes (compared to build v4.19.6)

Ran 20285 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

#153 lore raw
Quoted 15 lines · Rafael David Tinoco
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

Quoted 8 lines
Quoted 3 lines

thanks,

greg k-h

Note: As a consequence of the retpoline backport, we upgraded our toolchain that is used to build the kernel and userspace from 7.0 to 7.3 (containing retpoline support).

Specifically, we went from Linaro's gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08) to upstream's gcc version 7.3.0 (GCC).

Quoted 70 lines

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary
------------------------------------------------------------------------

kernel: 4.19.7-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 987a6da5152c29e37cc11de9a2d10a23a48015c9 git describe: v4.19.6-140-g987a6da5152c
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.6-140-g987a6da5152c

No Regressions (compared to build v4.19.6)

No Fixes (compared to build v4.19.6)

Ran 20285 total tests in the following environments and test suites.

Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
-----------
* boot
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

--
Linaro LKFT
https://lkft.linaro.org

#154 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah

author maintainer
#155 lore raw
Quoted 15 lines · shuah
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.7 release. There are 139 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 Dec 6 10:36:22 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.7-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 4 lines

thanks,

greg k-h

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

Thanks for testing these and letting me know.

greg k-h