4.16.12-stable review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 155/161 rtc: snvs: Fix usage of snvs_rtc_enable
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryan O'Donoghue <[email protected]>
[ Upstream commit 1485991c024603b2fb4ae77beb7a0d741128a48e ]
commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces the SNVS RTC driver with a function snvs_rtc_enable().
snvs_rtc_enable() can return an error on the enable path however this driver does not currently trap that failure on the probe() path and consequently if enabling the RTC fails we encounter a later error spinning forever in rtc_write_sync_lp().
[ 36.093481] [<c010d630>] (__irq_svc) from [<c0c2e9ec>] (_raw_spin_unlock_irqrestore+0x34/0x44) [ 36.102122] [<c0c2e9ec>] (_raw_spin_unlock_irqrestore) from [<c072e32c>] (regmap_read+0x4c/0x5c) [ 36.110938] [<c072e32c>] (regmap_read) from [<c085d0f4>] (rtc_write_sync_lp+0x6c/0x98) [ 36.118881] [<c085d0f4>] (rtc_write_sync_lp) from [<c085d160>] (snvs_rtc_alarm_irq_enable+0x40/0x4c) [ 36.128041] [<c085d160>] (snvs_rtc_alarm_irq_enable) from [<c08567b4>] (rtc_timer_do_work+0xd8/0x1a8) [ 36.137291] [<c08567b4>] (rtc_timer_do_work) from [<c01441b8>] (process_one_work+0x28c/0x76c) [ 36.145840] [<c01441b8>] (process_one_work) from [<c01446cc>] (worker_thread+0x34/0x58c) [ 36.153961] [<c01446cc>] (worker_thread) from [<c014aee4>] (kthread+0x138/0x150) [ 36.161388] [<c014aee4>] (kthread) from [<c0107e14>] (ret_from_fork+0x14/0x20) [ 36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0 [ 36.178564] rcu_sched R running task 0 8 2 0x00000000 [ 36.185664] [<c0c288b0>] (__schedule) from [<c0c29134>] (schedule+0x3c/0xa0) [ 36.192739] [<c0c29134>] (schedule) from [<c0c2db80>] (schedule_timeout+0x78/0x4e0) [ 36.200422] [<c0c2db80>] (schedule_timeout) from [<c01a7ab0>] (rcu_gp_kthread+0x648/0x1864) [ 36.208800] [<c01a7ab0>] (rcu_gp_kthread) from [<c014aee4>] (kthread+0x138/0x150) [ 36.216309] [<c014aee4>] (kthread) from [<c0107e14>] (ret_from_fork+0x14/0x20)
This patch fixes by parsing the result of rtc_write_sync_lp() and propagating both in the probe and elsewhere. If the RTC doesn't start we don't proceed loading the driver and don't get into this loop mess later on.
--- drivers/rtc/rtc-snvs.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/rtc/rtc-snvs.c +11 -4
@@ -132,20 +132,23 @@ static int snvs_rtc_set_time(struct devi {struct snvs_rtc_data *data =dev_get_drvdata (dev);unsigned long time; +int ret;rtc_tm_to_time (tm, &time);/* Disable RTC first */ -snvs_rtc_enable (data, false); + ret =snvs_rtc_enable (data, false); +if (ret) +return ret;/* Write 32-bit time to 47-bit timer, leaving 15 LSBs blank */ regmap_write (data->regmap, data->offset +SNVS_LPSRTCLR , time <<CNTR_TO_SECS_SH );regmap_write (data->regmap, data->offset +SNVS_LPSRTCMR , time >> (32 -CNTR_TO_SECS_SH ));/* Enable RTC again */ -snvs_rtc_enable (data, true); + ret =snvs_rtc_enable (data, true); -return 0 ; +return ret; }static int snvs_rtc_read_alarm (struct device *dev,struct rtc_wkalrm *alrm)
@@ -288,7 +291,11 @@ static int snvs_rtc_probe(struct platforregmap_write (data->regmap, data->offset +SNVS_LPSR ,0xffffffff );/* Enable RTC */ -snvs_rtc_enable (data, true); + ret =snvs_rtc_enable (data, true); +if (ret) { +dev_err (&pdev->dev,"failed to enable rtc %d\n" , ret); + goto error_rtc_device_register; + }device_init_wakeup (&pdev->dev, true);
Greg Kroah-Hartman
maintainerPATCH 156/161 rtc: hctosys: Ensure system time doesnt overflow time_t
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]
On 32bit platforms, time_t is still a signed 32bit long. If it is overflowed, userspace and the kernel cant agree on the current system time. This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143
A good workaround is to simply avoid using hctosys which is something I greatly encourage as the time is better set by userspace.
However, many distribution enable it and use systemd which is rendering the system unusable in case the RTC holds a date after 2038 (and more so after 2106). Many drivers have workaround for this case and they should be eliminated so there is only one place left to fix when userspace is able to cope with dates after the 31bit overflow.
--- drivers/rtc/hctosys.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/rtc/hctosys.c +5 -0
@@ -49,6 +49,11 @@ static int __init rtc_hctosys(void) tv64.tv_sec =rtc_tm_to_time64 (&tm); +#if BITS_PER_LONG ==32 +if (tv64.tv_sec >INT_MAX ) + goto err_read; +#endif + err =do_settimeofday64 (&tv64); dev_info(rtc->dev.parent,
Greg Kroah-Hartman
maintainerPATCH 157/161 rtc: rk808: fix possible race condition
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit 201fac95e799c3d0304ec724d555e1251b9f6e84 ]
The probe function is not allowed to fail after registering the RTC because the following may happen:
CPU0: CPU1:sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc as late as possible.
--- drivers/rtc/rtc-rk808.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/rtc/rtc-rk808.c +7 -7
@@ -416,12 +416,11 @@ static int rk808_rtc_probe(struct platfodevice_init_wakeup (&pdev->dev,1 ); - rk808_rtc->rtc =devm_rtc_device_register (&pdev->dev,"rk808-rtc" , - &rk808_rtc_ops,THIS_MODULE ); -if (IS_ERR (rk808_rtc->rtc)) { - ret =PTR_ERR (rk808_rtc->rtc); -return ret; - } + rk808_rtc->rtc =devm_rtc_allocate_device (&pdev->dev); +if (IS_ERR (rk808_rtc->rtc)) +return PTR_ERR (rk808_rtc->rtc); + + rk808_rtc->rtc->ops = &rk808_rtc_ops; rk808_rtc->irq =platform_get_irq (pdev,0 );if (rk808_rtc->irq <0 ) {
@@ -438,9 +437,10 @@ static int rk808_rtc_probe(struct platfoif (ret) {dev_err (&pdev->dev,"Failed to request alarm IRQ %d: %d\n" , rk808_rtc->irq, ret); +return ret; } -return ret; +return rtc_register_device (rk808_rtc->rtc); }static struct platform_driver rk808_rtc_driver = {
Greg Kroah-Hartman
maintainerPATCH 158/161 rtc: m41t80: fix race conditions
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit 10d0c768cc6d581523d673b9d1b54213f8a5eb24 ]
The IRQ is requested before the struct rtc is allocated and registered, but this struct is used in the IRQ handler, leading to:
Unable to handle kernel NULL pointer dereference at virtual address 0000017c pgd = a38a2f9b [0000017c] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 613 Comm: irq/48-m41t80 Not tainted 4.16.0-rc1+ #42 Hardware name: Atmel SAMA5 PC is at mutex_lock+0x14/0x38 LR is at m41t80_handle_irq+0x1c/0x9c pc : [<c06e864c>] lr : [<c04b70f0>] psr: 20000013
sp : dec73f30 ip : 00000000 fp : dec56d98
r10: df437cf0 r9 : c0a03008 r8 : c0145ffc
r7 : df5c4300 r6 : dec568d0 r5 : df593000 r4 : 0000017c r3 : df592800 r2 : 60000013 r1 : df593000 r0 : 0000017c
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c53c7d Table: 20004059 DAC: 00000051 Process irq/48-m41t80 (pid: 613, stack limit = 0xb52d091e)
Stack: (0xdec73f30 to 0xdec74000)
3f20: dec56840 df5c4300 00000001 df5c4300
3f40: c0145ffc c0146018 dec56840 ffffe000 00000001 c0146290 dec567c0 00000000 3f60: c0146084 ed7c9a62 c014615c dec56d80 dec567c0 00000000 dec72000 dec56840 3f80: c014615c c012ffc0 dec72000 dec567c0 c012fe80 00000000 00000000 00000000 3fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 29282726 2d2c2b2a [<c06e864c>] (mutex_lock) from [<c04b70f0>] (m41t80_handle_irq+0x1c/0x9c) [<c04b70f0>] (m41t80_handle_irq) from [<c0146018>] (irq_thread_fn+0x1c/0x54) [<c0146018>] (irq_thread_fn) from [<c0146290>] (irq_thread+0x134/0x1c0) [<c0146290>] (irq_thread) from [<c012ffc0>] (kthread+0x140/0x148) [<c012ffc0>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xdec73fb0 to 0xdec73ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e3c33d7f e3c3303f f5d0f000 e593300c (e1901f9f) ---[ end trace 22b027302eb7c604 ]---
genirq: exiting task "irq/48-m41t80" (613) is an active IRQ thread (irq 48)
Also, there is another possible race condition. The probe function is not allowed to fail after the RTC is registered because the following may happen:
CPU0: CPU1:sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc before requesting the IRQ and register it as late as possible.
--- drivers/rtc/rtc-m41t80.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
drivers/rtc/rtc-m41t80.c +11 -7
@@ -885,7 +885,6 @@ static int m41t80_probe(struct i2c_clien {struct i2c_adapter *adapter =to_i2c_adapter (client->dev.parent);int rc =0 ; -struct rtc_device *rtc =NULL ;struct rtc_time tm;struct m41t80_data *m41t80_data =NULL ;bool wakeup_source = false;
@@ -909,6 +908,10 @@ static int m41t80_probe(struct i2c_clien m41t80_data->features = id->driver_data;i2c_set_clientdata (client, m41t80_data); + m41t80_data->rtc =devm_rtc_allocate_device (&client->dev); +if (IS_ERR (m41t80_data->rtc)) +return PTR_ERR (m41t80_data->rtc); +#ifdef CONFIG_OF wakeup_source =of_property_read_bool (client->dev.of_node,"wakeup-source" );
@@ -932,15 +935,11 @@ static int m41t80_probe(struct i2c_cliendevice_init_wakeup (&client->dev, true); } - rtc =devm_rtc_device_register (&client->dev, client->name, - &m41t80_rtc_ops,THIS_MODULE ); -if (IS_ERR (rtc)) -return PTR_ERR (rtc); + m41t80_data->rtc->ops = &m41t80_rtc_ops; - m41t80_data->rtc = rtc;if (client->irq <=0 ) {/* We cannot support UIE mode if we do not have an IRQ line */ - rtc->uie_unsupported =1 ; + m41t80_data->rtc->uie_unsupported =1 ; }/* Make sure HT (Halt Update) bit is cleared */
@@ -993,6 +992,11 @@ static int m41t80_probe(struct i2c_clienif (m41t80_data->features &M41T80_FEATURE_SQ )m41t80_sqw_register_clk (m41t80_data);#endif + + rc =rtc_register_device (m41t80_data->rtc); +if (rc) +return rc; +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 159/161 rtc: tx4939: avoid unintended sign extension on a 24 bit shift
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
[ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ]
The shifting of buf[5] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an unsigned long. If the top bit of buf[5] is set then all then all the upper bits sec end up as also being set because of the sign-extension. Fix this by casting buf[5] to an unsigned long before the shift.
Detected by CoverityScan, CID#1465292 ("Unintended sign extension")
--- drivers/rtc/rtc-tx4939.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/rtc/rtc-tx4939.c +4 -2
@@ -86,7 +86,8 @@ static int tx4939_rtc_read_time(struct dfor (i =2 ; i <6 ; i++) buf[i] =__raw_readl (&rtcreg->dat);spin_unlock_irq (&pdata->lock); - sec = (buf[5 ] <<24 ) | (buf[4 ] <<16 ) | (buf[3 ] <<8 ) | buf[2 ]; + sec = ((unsigned long )buf[5 ] <<24 ) | (buf[4 ] <<16 ) | + (buf[3 ] <<8 ) | buf[2 ];rtc_time_to_tm (sec, tm);return rtc_valid_tm (tm); }
@@ -147,7 +148,8 @@ static int tx4939_rtc_read_alarm(struct alrm->enabled = (ctl &TX4939_RTCCTL_ALME ) ?1 :0 ; alrm->pending = (ctl &TX4939_RTCCTL_ALMD ) ?1 :0 ;spin_unlock_irq (&pdata->lock); - sec = (buf[5 ] <<24 ) | (buf[4 ] <<16 ) | (buf[3 ] <<8 ) | buf[2 ]; + sec = ((unsigned long )buf[5 ] <<24 ) | (buf[4 ] <<16 ) | + (buf[3 ] <<8 ) | buf[2 ];rtc_time_to_tm (sec, &alrm->time);return rtc_valid_tm (&alrm->time); }
Greg Kroah-Hartman
maintainerPATCH 160/161 rtc: rp5c01: fix possible race condition
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Belloni <[email protected]>
[ Upstream commit bcdd559268039d8340d38fa58668393596e29fdc ]
The probe function is not allowed to fail after registering the RTC because the following may happen:
CPU0: CPU1:sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc as late as possible.
--- drivers/rtc/rtc-rp5c01.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/rtc/rtc-rp5c01.c +10 -2
@@ -249,16 +249,24 @@ static int __init rp5c01_rtc_probe(strucplatform_set_drvdata (dev, priv); - rtc =devm_rtc_device_register (&dev->dev,"rtc-rp5c01" , &rp5c01_rtc_ops, -THIS_MODULE ); + rtc =devm_rtc_allocate_device (&dev->dev);if (IS_ERR (rtc))return PTR_ERR (rtc); + + rtc->ops = &rp5c01_rtc_ops; + priv->rtc = rtc; error =sysfs_create_bin_file (&dev->dev.kobj, &priv->nvram_attr);if (error)return error; + error =rtc_register_device (rtc); +if (error) { +sysfs_remove_bin_file (&dev->dev.kobj, &priv->nvram_attr); +return error; + } +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 161/161 rtc: goldfish: Add missing MODULE_LICENSE
In reply to Greg Kroah-Hartman4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <[email protected]>
[ Upstream commit 82d632b85eb89f97051530f556cb49ee1c04bde7 ]
Fix the following warning in MIPS allmodconfig by adding a MODULE_LICENSE() at the end of rtc-goldfish.c, based on the file header comment which says GNU General Public License version 2:
WARNING: modpost: missing MODULE_LICENSE() in drivers/rtc/rtc-goldfish.o
--- drivers/rtc/rtc-goldfish.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/rtc/rtc-goldfish.c +2 -0
@@ -235,3 +235,5 @@ static struct platform_driver goldfish_r };module_platform_driver (goldfish_rtc); + +MODULE_LICENSE ("GPL v2" );
stable-rc/linux-4.16.y boot: 116 boots: 0 failed, 111 passed with 5 offline (v4.16.11-162-gec693ff0154a)
stable-rc/linux-4.16.y boot: 116 boots: 0 failed, 111 passed with 5 offline (v4.16.11-162-gec693ff0154a)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.16.y/kernel/v4.16.11-162-gec693ff0154a/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.16.y/kernel/v4.16.11-162-gec693ff0154a/
Tree: stable-rc
Branch: linux-4.16.y
Git Describe: v4.16.11-162-gec693ff0154a
Git Commit: ec693ff0154a1ad11520223f3c1d2eb5b13cabf1
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 62 unique boards, 24 SoC families, 14 builds out of 186
Offline Platforms:
arm:
imx_v6_v7_defconfig:
imx7s-warp: 1 offline lab
multi_v7_defconfig:
imx7s-warp: 1 offline lab
arm64:
defconfig:
meson-gxbb-p200: 1 offline lab
meson-gxl-s905x-khadas-vim: 1 offline lab
sun50i-a64-pine64-plus: 1 offline lab
---
For more info write to <[email protected]>
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.12 release. There are 161 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 Sat May 26 09:29:22 UTC 2018. Anything received after that time might be too late.
Build results:
total: 143 pass: 143 fail: 0 Qemu test results: total: 139 pass: 139 fail: 0
Details are available at http://kerneltests.org/builders/.
Guenter
Greg Kroah-Hartman
maintainerQuoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.12 release. There are 161 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 Sat May 26 09:29:22 UTC 2018. Anything received after that time might be too late.
Quoted 6 lines
Build results:
total: 143 pass: 143 fail: 0 Qemu test results: total: 139 pass: 139 fail: 0Details are available at http://kerneltests.org/builders/.
Thanks for testing all of these and letting me know.
greg k-h
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.12 release. There are 161 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 Sat May 26 09:29:22 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm.
No regressions detected.
The times03 regression noted below failed while running on a shared host under emulation (QEMU). This is a false failure, which has been fixed in the most recent version of LTP already (see
https://github.com/linux-test-project/ltp/commit/ed01f6a05c77f65cb5d1089474c9a0e2129c581a).
Summary
------------------------------------------------------------------------
kernel: 4.16.12-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: ec693ff0154a1ad11520223f3c1d2eb5b13cabf1
git describe: v4.16.11-162-gec693ff0154a
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.11-162-gec693ff0154a
Regressions (compared to build v4.16.11)
------------------------------------------------------------------------
qemu_arm:
ltp-syscalls-tests:
* times03
* test src: git://github.com/linux-test-project/ltp.git
Ran 11196 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-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
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 11 lines · Dan Rue
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.12 release. There are 161 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 Sat May 26 09:29:22 UTC 2018. Anything received after that time might be too late.
Results from Linaro’s test farm.
No regressions detected.
Thanks for testing.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.12 release. There are 161 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 Sat May 26 09:29: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.16.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · Shuah Khan
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.16.12 release. There are 161 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 Sat May 26 09:29: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.16.12-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.16.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 all of these and letting me know.
greg k-h