4.9.89-stable review
Subsystems (18)
Greg Kroah-Hartman
maintainerPATCH 165/241 video/hdmi: Allow "empty" HDMI infoframes
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Ville Syrj�l�" <[email protected]>
[ Upstream commit 593f4b19a094c4426bd1e1e3cbab87a48bd13c71 ]
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information). This is a workaround against some sinks that fail to realize that they should switch from 3D to 2D mode when the source stop transmitting the infoframe.
v2: Handle unpack() as well
Pull the length calculation into a helper
--- drivers/video/hdmi.c | 51 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 20 deletions(-)
drivers/video/hdmi.c +31 -20
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hd }EXPORT_SYMBOL (hdmi_vendor_infoframe_init); +static int hdmi_vendor_infoframe_length (const struct hdmi_vendor_infoframe *frame) +{ +/* for side by side (half) we also need to provide 3D_Ext_Data */ +if (frame->s3d_struct >=HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF ) +return 6 ; +else if (frame->vic !=0 || frame->s3d_struct !=HDMI_3D_STRUCTURE_INVALID ) +return 5 ; +else +return 4 ; +} +/** * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer * @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(strucu8 *ptr = buffer;size_t length; -/* empty info frame */ -if (frame->vic ==0 && frame->s3d_struct ==HDMI_3D_STRUCTURE_INVALID ) -return -EINVAL ; -/* only one of those can be supplied */ if (frame->vic !=0 && frame->s3d_struct !=HDMI_3D_STRUCTURE_INVALID )return -EINVAL ; -/* for side by side (half) we also need to provide 3D_Ext_Data */ -if (frame->s3d_struct >=HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF ) - frame->length =6 ; -else - frame->length =5 ; + frame->length =hdmi_vendor_infoframe_length (frame); length =HDMI_INFOFRAME_HEADER_SIZE + frame->length;
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struc ptr[5 ] =0x0c ; ptr[6 ] =0x00 ; -if (frame->vic) { - ptr[7 ] =0x1 <<5 ;/* video format */ - ptr[8 ] = frame->vic; - }else { +if (frame->s3d_struct !=HDMI_3D_STRUCTURE_INVALID ) { ptr[7 ] =0x2 <<5 ;/* video format */ ptr[8 ] = (frame->s3d_struct &0xf ) <<4 ;if (frame->s3d_struct >=HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF ) ptr[9 ] = (frame->s3d_ext_data &0xf ) <<4 ; + }else if (frame->vic) { + ptr[7 ] =0x1 <<5 ;/* video format */ + ptr[8 ] = frame->vic; + }else { + ptr[7 ] =0x0 <<5 ;/* video format */ }hdmi_infoframe_set_checksum (buffer, length);
@@ -1161,7 +1166,7 @@ hdmi_vendor_any_infoframe_unpack(union hif (ptr[0 ] !=HDMI_INFOFRAME_TYPE_VENDOR || ptr[1 ] !=1 || - (ptr[2 ] !=5 && ptr[2 ] !=6 )) + (ptr[2 ] !=4 && ptr[2 ] !=5 && ptr[2 ] !=6 ))return -EINVAL ; length = ptr[2 ];
@@ -1189,16 +1194,22 @@ hdmi_vendor_any_infoframe_unpack(union h hvf->length = length; -if (hdmi_video_format ==0x1 ) { - hvf->vic = ptr[4 ]; - }else if (hdmi_video_format ==0x2 ) { +if (hdmi_video_format ==0x2 ) { +if (length !=5 && length !=6 ) +return -EINVAL ; hvf->s3d_struct = ptr[4 ] >>4 ;if (hvf->s3d_struct >=HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF ) { -if (length ==6 ) - hvf->s3d_ext_data = ptr[5 ] >>4 ; -else +if (length !=6 )return -EINVAL ; + hvf->s3d_ext_data = ptr[5 ] >>4 ; } + }else if (hdmi_video_format ==0x1 ) { +if (length !=5 ) +return -EINVAL ; + hvf->vic = ptr[4 ]; + }else { +if (length !=4 ) +return -EINVAL ; }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 166/241 HID: elo: clear BTN_LEFT mapping
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Kosina <[email protected]>
[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]
ELO devices have one Button usage in GenDesk field, which makes hid-input map it to BTN_LEFT; that confuses userspace, which then considers the device to be a mouse/touchpad instead of touchscreen.
Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.
--- drivers/hid/hid-elo.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/hid/hid-elo.c +6 -0
@@ -42,6 +42,12 @@ static int elo_input_configured(struct h {struct input_dev *input = hidinput->input; +/* +* ELO devices have one Button usage in GenDesk field, which makes +* hid-input map it to BTN_LEFT; that confuses userspace, which then +* considers the device to be a mouse/touchpad instead of touchscreen. +*/ +clear_bit (BTN_LEFT , input->keybit);set_bit (BTN_TOUCH , input->keybit);set_bit (ABS_PRESSURE , input->absbit);input_set_abs_params (input,ABS_PRESSURE ,0 ,256 ,0 ,0 );
Greg Kroah-Hartman
maintainerPATCH 167/241 iwlwifi: mvm: rs: dont override the rate history in the search cycle
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <[email protected]>
[ Upstream commit 992172e3aec19e5b0ea5b757ba40a146b9282d1e ]
When we are in a search cycle, we try different combinations of parameters. Those combinations are called 'columns'. When we switch to a new column, we first need to check if this column has a suitable rate, if not, we can't try it. This means we must not erase the statistics we gathered for the previous column until we are sure that we are indeed switching column.
The code that tries to switch to a new column first sets a whole bunch of things for the new column, and only then checks that we can find suitable rates in that column. While doing that, the code mistakenly erased the rate statistics. This code was right until
struct iwl_scale_tbl_info grew up for TPC.
Fix this to make sure we don't erase the rate statistics until we are sure that we can indeed switch to the new column.
Note that this bug is really harmless since it causes a change in the behavior only when we can't find any rate in the new column which should really not happen. In the case we do find a suitable we reset the rate statistics a few lines later anyway.
--- drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/net/wireless/intel/iwlwifi/mvm/rs.c +1 -3
@@ -1867,12 +1867,10 @@ static int rs_switch_to_column(struct iwstruct rs_rate *rate = &search_tbl->rate;const struct rs_tx_column *column = &rs_tx_columns[col_id];const struct rs_tx_column *curr_column = &rs_tx_columns[tbl->column]; -u32 sz = (sizeof (struct iwl_scale_tbl_info ) - - (sizeof (struct iwl_rate_scale_data ) *IWL_RATE_COUNT ));unsigned long rate_mask =0 ;u32 rate_idx =0 ; -memcpy (search_tbl, tbl, sz); +memcpy (search_tbl, tbl, offsetof(struct iwl_scale_tbl_info , win)); rate->sgi = column->sgi; rate->ant = column->ant;
Greg Kroah-Hartman
maintainerPATCH 168/241 clk: meson: gxbb: fix wrong clock for SARADC/SANA
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yixun Lan <[email protected]>
[ Upstream commit 75eccf5ed83250c0aeaeeb76f7288254ac0a87b4 ]
According to the datasheet, in Meson-GXBB/GXL series, The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22], while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].
Test passed at gxl-s905x-p212 board.
The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4
[2] GXL v0.3_20170314
--- drivers/clk/meson/gxbb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/clk/meson/gxbb.c +2 -2
@@ -572,7 +572,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_M static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7); static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8); static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9); -static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10); +static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10); static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11); static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12); static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -623,7 +623,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11); static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12); static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15); -static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22); +static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22); static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25); static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26); static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
Greg Kroah-Hartman
maintainerPATCH 169/241 ARM: dts: exynos: Correct Trats2 panel reset line
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Simon Shields <[email protected]>
[ Upstream commit 1b377924841df1e13ab5b225be3a83f807a92b52 ]
Trats2 uses gpf2-1 as the panel reset GPIO. gpy4-5 was only used on early revisions of the board.
--- arch/arm/boot/dts/exynos4412-trats2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/exynos4412-trats2.dts +1 -1
@@ -408,7 +408,7 @@ reg = <0>; vdd3-supply = <&lcd_vdd3_reg>; vci-supply = <&ldo25_reg>; - reset-gpios = <&gpy4 5 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpf2 1 GPIO_ACTIVE_HIGH>; power-on-delay= <50>; reset-delay = <100>; init-delay = <100>;
Greg Kroah-Hartman
maintainerPATCH 170/241 sched: Stop switched_to_rt() from sending IPIs to offline CPUs
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Paul E. McKenney" <[email protected]>
[ Upstream commit 2fe2582649aa2355f79acddb86bd4d6c5363eb63 ]
The rcutorture test suite occasionally provokes a splat due to invoking rt_mutex_lock() which needs to boost the priority of a task currently sitting on a runqueue that belongs to an offline CPU:
WARNING: CPU: 0 PID: 12 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40 Modules linked in: CPU: 0 PID: 12 Comm: rcub/7 Not tainted 4.14.0-rc4+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 task: ffff9ed3de5f8cc0 task.stack: ffffbbf80012c000 RIP: 0010:native_smp_send_reschedule+0x37/0x40 RSP: 0018:ffffbbf80012fd10 EFLAGS: 00010082 RAX: 000000000000002f RBX: ffff9ed3dd9cb300 RCX: 0000000000000004 RDX: 0000000080000004 RSI: 0000000000000086 RDI: 00000000ffffffff RBP: ffffbbf80012fd10 R08: 000000000009da7a R09: 0000000000007b9d R10: 0000000000000001 R11: ffffffffbb57c2cd R12: 000000000000000d R13: ffff9ed3de5f8cc0 R14: 0000000000000061 R15: ffff9ed3ded59200 FS: 0000000000000000(0000) GS:ffff9ed3dea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000080686f0 CR3: 000000001b9e0000 CR4: 00000000000006f0 Call Trace: resched_curr+0x61/0xd0 switched_to_rt+0x8f/0xa0 rt_mutex_setprio+0x25c/0x410 task_blocks_on_rt_mutex+0x1b3/0x1f0 rt_mutex_slowlock+0xa9/0x1e0 rt_mutex_lock+0x29/0x30 rcu_boost_kthread+0x127/0x3c0 kthread+0x104/0x140 ? rcu_report_unblock_qs_rnp+0x90/0x90 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x22/0x30 Code: f0 00 0f 92 c0 84 c0 74 14 48 8b 05 34 74 c5 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 a0 c6 fc b9 e8 d5 b5 06 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 a2 d1 13 02 85 c0 75 38 55 48
But the target task's priority has already been adjusted, so the only purpose of switched_to_rt() invoking resched_curr() is to wake up the CPU running some task that needs to be preempted by the boosted task. But the CPU is offline, which presumably means that the task must be migrated to some other CPU, and that this other CPU will undertake any needed preemption at the time of migration. Because the runqueue lock is held when resched_curr() is invoked, we know that the boosted task cannot go anywhere, so it is not necessary to invoke resched_curr() in this particular case.
This commit therefore makes switched_to_rt() refrain from invoking resched_curr() when the target CPU is offline.
--- kernel/sched/rt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sched/rt.c +1 -1
@@ -2206,7 +2206,7 @@ static void switched_to_rt(struct rq *rqif (tsk_nr_cpus_allowed (p) >1 && rq->rt.overloaded)queue_push_tasks (rq);#endif /* CONFIG_SMP */ -if (p->prio < rq->curr->prio) +if (p->prio < rq->curr->prio &&cpu_online (cpu_of (rq)))resched_curr (rq); } }
Greg Kroah-Hartman
maintainerPATCH 171/241 sched: Stop resched_cpu() from sending IPIs to offline CPUs
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Paul E. McKenney" <[email protected]>
[ Upstream commit a0982dfa03efca6c239c52cabebcea4afb93ea6b ]
The rcutorture test suite occasionally provokes a splat due to invoking resched_cpu() on an offline CPU:
WARNING: CPU: 2 PID: 8 at /home/paulmck/public_git/linux-rcu/arch/x86/kernel/smp.c:128 native_smp_send_reschedule+0x37/0x40 Modules linked in: CPU: 2 PID: 8 Comm: rcu_preempt Not tainted 4.14.0-rc4+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 task: ffff902ede9daf00 task.stack: ffff96c50010c000 RIP: 0010:native_smp_send_reschedule+0x37/0x40 RSP: 0018:ffff96c50010fdb8 EFLAGS: 00010096 RAX: 000000000000002e RBX: ffff902edaab4680 RCX: 0000000000000003 RDX: 0000000080000003 RSI: 0000000000000000 RDI: 00000000ffffffff RBP: ffff96c50010fdb8 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000000 R11: 00000000299f36ae R12: 0000000000000001 R13: ffffffff9de64240 R14: 0000000000000001 R15: ffffffff9de64240 FS: 0000000000000000(0000) GS:ffff902edfc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f7d4c642 CR3: 000000001e0e2000 CR4: 00000000000006e0 Call Trace: resched_curr+0x8f/0x1c0 resched_cpu+0x2c/0x40 rcu_implicit_dynticks_qs+0x152/0x220 force_qs_rnp+0x147/0x1d0 ? sync_rcu_exp_select_cpus+0x450/0x450 rcu_gp_kthread+0x5a9/0x950 kthread+0x142/0x180 ? force_qs_rnp+0x1d0/0x1d0 ? kthread_create_on_node+0x40/0x40 ret_from_fork+0x27/0x40 Code: 14 01 0f 92 c0 84 c0 74 14 48 8b 05 14 4f f4 00 be fd 00 00 00 ff 90 a0 00 00 00 5d c3 89 fe 48 c7 c7 38 89 ca 9d e8 e5 56 08 00 <0f> ff 5d c3 0f 1f 44 00 00 8b 05 52 9e 37 02 85 c0 75 38 55 48 ---[ end trace 26df9e5df4bba4ac ]---
This splat cannot be generated by expedited grace periods because they always invoke resched_cpu() on the current CPU, which is good because expedited grace periods require that resched_cpu() unconditionally succeed. However, other parts of RCU can tolerate resched_cpu() acting as a no-op, at least as long as it doesn't happen too often.
This commit therefore makes resched_cpu() invoke resched_curr() only if the CPU is either online or is the current CPU.
--- kernel/sched/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
kernel/sched/core.c +2 -1
@@ -508,7 +508,8 @@ void resched_cpu(int cpu)unsigned long flags;raw_spin_lock_irqsave (&rq->lock, flags); -resched_curr (rq); +if (cpu_online (cpu) || cpu ==smp_processor_id ()) +resched_curr (rq);raw_spin_unlock_irqrestore (&rq->lock, flags); }
Greg Kroah-Hartman
maintainerPATCH 172/241 test_firmware: fix setting old custom fw path back on exit
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Luis R. Rodriguez" <[email protected]>
[ Upstream commit 65c79230576873b312c3599479c1e42355c9f349 ]
The file /sys/module/firmware_class/parameters/path can be used to set a custom firmware path. The fw_filesystem.sh script creates a temporary directory to add a test firmware file to be used during testing, in order for this to work it uses the custom path syfs file and it was supposed to reset back the file on execution exit. The script failed to do this due to a typo, it was using OLD_PATH instead of OLD_FWPATH, since its inception since v3.17.
Its not as easy to just keep the old setting, it turns out that resetting an empty setting won't actually do what we want, we need to check if it was empty and set an empty space.
Without this we end up having the temporary path always set after we run these tests.
--- tools/testing/selftests/firmware/fw_filesystem.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
tools/testing/selftests/firmware/fw_filesystem.sh +4 -1
@@ -28,7 +28,10 @@ test_finish() if [ "$HAS_FW_LOADER_USER_HELPER" = "yes" ]; then echo "$OLD_TIMEOUT" >/sys/class/firmware/timeout fi - echo -n "$OLD_PATH" >/sys/module/firmware_class/parameters/path + if [ "$OLD_FWPATH" = "" ]; then + OLD_FWPATH=" " + fi + echo -n "$OLD_FWPATH" >/sys/module/firmware_class/parameters/path rm -f "$FW" rmdir "$FWPATH" }
Greg Kroah-Hartman
maintainerPATCH 173/241 net: ieee802154: adf7242: Fix bug if defined DEBUG
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Hennerich <[email protected]>
[ Upstream commit 388b3b2b03701f3b3c10975c272892d7f78080df ]
This fixes undefined reference to struct adf7242_local *lp in case DEBUG is defined.
--- drivers/net/ieee802154/adf7242.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ieee802154/adf7242.c +2 -2
@@ -888,7 +888,7 @@ static struct ieee802154_ops adf7242_ops .set_cca_ed_level = adf7242_set_cca_ed_level, }; -static void adf7242_debug (u8 irq1) +static void adf7242_debug (struct adf7242_local *lp,u8 irq1) {#ifdef DEBUG u8 stat;
@@ -932,7 +932,7 @@ static irqreturn_t adf7242_isr(int irq,dev_err (&lp->spi->dev,"%s :ERROR IRQ1 = 0x%X\n" , __func__, irq1); -adf7242_debug (irq1); +adf7242_debug (lp, irq1); xmit =test_bit (FLAG_XMIT , &lp->flags);
Greg Kroah-Hartman
maintainerPATCH 174/241 net: xfrm: allow clearing socket xfrm policies.
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Colitti <[email protected]>
[ Upstream commit be8f8284cd897af2482d4e54fbc2bdfc15557259 ]
Currently it is possible to add or update socket policies, but not clear them. Therefore, once a socket policy has been applied, the socket cannot be used for unencrypted traffic.
This patch allows (privileged) users to clear socket policies by passing in a NULL pointer and zero length argument to the {IP,IPV6}_{IPSEC,XFRM}_POLICY setsockopts. This results in both the incoming and outgoing policies being cleared.
The simple approach taken in this patch cannot clear socket policies in only one direction. If desired this could be added in the future, for example by continuing to pass in a length of zero (which currently is guaranteed to return EMSGSIZE) and making the policy be a pointer to an integer that contains one of the XFRM_POLICY_{IN,OUT} enum values.
An alternative would have been to interpret the length as a signed integer and use XFRM_POLICY_IN (i.e., 0) to clear the input policy and -XFRM_POLICY_OUT (i.e., -1) to clear the output policy.
Tested: https://android-review.googlesource.com/539816
--- net/xfrm/xfrm_policy.c | 2 +- net/xfrm/xfrm_state.c | 7 +++++++ 2 files changed, 8 insertions(+), 1 deletion(-)
net/xfrm/xfrm_policy.c +1 -1
@@ -1346,7 +1346,7 @@ EXPORT_SYMBOL(xfrm_policy_delete);int xfrm_sk_policy_insert (struct sock *sk,int dir,struct xfrm_policy *pol) { -struct net *net =xp_net (pol); +struct net *net =sock_net (sk);struct xfrm_policy *old_pol;#ifdef CONFIG_XFRM_SUB_POLICY
net/xfrm/xfrm_state.c +7 -0
@@ -1883,6 +1883,13 @@ int xfrm_user_policy(struct sock *sk, instruct xfrm_mgr *km;struct xfrm_policy *pol =NULL ; +if (!optval && !optlen) { +xfrm_sk_policy_insert (sk,XFRM_POLICY_IN ,NULL ); +xfrm_sk_policy_insert (sk,XFRM_POLICY_OUT ,NULL ); +__sk_dst_reset (sk); +return 0 ; + } +if (optlen <=0 || optlen >PAGE_SIZE )return -EMSGSIZE ;
Greg Kroah-Hartman
maintainerPATCH 175/241 mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miquel Raynal <[email protected]>
[ Upstream commit df467899da0b71465760b4e35127bce837244eee ]
Some drivers (like nand_hynix.c) call ->cmdfunc() with NAND_CMD_NONE and a column address and expect the controller to only send address cycles. Right now, the default ->cmdfunc() implementations provided by the core do not filter out the command cycle in this case and forwards the request to the controller driver through the ->cmd_ctrl() method. The thing is, NAND controller drivers can get this wrong and send a command cycle with a NAND_CMD_NONE opcode and since NAND_CMD_NONE is -1, and the command field is usually casted to an u8, we end up sending the 0xFF command which is actually a RESET operation.
Add conditions in nand_command[_lp]() functions to sending the initial command cycle when command == NAND_CMD_NONE.
--- drivers/mtd/nand/nand_base.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/mtd/nand/nand_base.c +7 -2
@@ -715,7 +715,8 @@ static void nand_command(struct mtd_info chip->cmd_ctrl (mtd, readcmd, ctrl); ctrl &= ~NAND_CTRL_CHANGE ; } - chip->cmd_ctrl (mtd, command, ctrl); +if (command !=NAND_CMD_NONE ) + chip->cmd_ctrl (mtd, command, ctrl);/* Address cycle, when necessary */ ctrl =NAND_CTRL_ALE |NAND_CTRL_CHANGE ;
@@ -744,6 +745,7 @@ static void nand_command(struct mtd_info*/ switch (command) { +case NAND_CMD_NONE :case NAND_CMD_PAGEPROG :case NAND_CMD_ERASE1 :case NAND_CMD_ERASE2 :
@@ -806,7 +808,9 @@ static void nand_command_lp(struct mtd_i }/* Command latch cycle */ - chip->cmd_ctrl (mtd, command,NAND_NCE |NAND_CLE |NAND_CTRL_CHANGE ); +if (command !=NAND_CMD_NONE ) + chip->cmd_ctrl (mtd, command, +NAND_NCE |NAND_CLE |NAND_CTRL_CHANGE );if (column !=-1 || page_addr !=-1 ) {int ctrl =NAND_CTRL_CHANGE |NAND_NCE |NAND_ALE ;
@@ -842,6 +846,7 @@ static void nand_command_lp(struct mtd_i*/ switch (command) { +case NAND_CMD_NONE :case NAND_CMD_CACHEDPROG :case NAND_CMD_PAGEPROG :case NAND_CMD_ERASE1 :
Greg Kroah-Hartman
maintainerPATCH 176/241 net: thunderx: Set max queue count taking XDP_TX into account
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sunil Goutham <[email protected]>
[ Upstream commit 87de083857aa269fb171ef0b39696b2888361c58 ]
on T81 there are only 4 cores, hence setting max queue count to 4 would leave nothing for XDP_TX. This patch fixes this by doubling max queue count in above scenarios.
--- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/ethernet/cavium/thunder/nicvf_main.c +5 -0
@@ -1576,6 +1576,11 @@ static int nicvf_probe(struct pci_dev *p nic->pdev = pdev; nic->pnicvf = nic; nic->max_queues = qcount; +/* If no of CPUs are too low, there won't be any queues left +* for XDP_TX, hence double it. +*/ +if (!nic->t88) + nic->max_queues *=2 ;/* MAP VF's configuration registers */ nic->reg_base =pcim_iomap (pdev,PCI_CFG_REG_BAR_NUM ,0 );
Greg Kroah-Hartman
maintainerPATCH 177/241 ARM: dts: am335x-pepper: Fix the audio CODECs reset pin
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Andrew F. Davis" <[email protected]>
[ Upstream commit e153db03c6b7a035c797bcdf35262586f003ee93 ]
The correct DT property for specifying a GPIO used for reset is "reset-gpios", fix this here.
--- arch/arm/boot/dts/am335x-pepper.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/am335x-pepper.dts +1 -1
@@ -139,7 +139,7 @@ &audio_codec { status = "okay"; - gpio-reset = <&gpio1 16 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>; AVDD-supply = <&ldo3_reg>; IOVDD-supply = <&ldo3_reg>; DRVDD-supply = <&ldo3_reg>;
Greg Kroah-Hartman
maintainerPATCH 178/241 ARM: dts: omap3-n900: Fix the audio CODECs reset pin
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Andrew F. Davis" <[email protected]>
[ Upstream commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 ]
The correct DT property for specifying a GPIO used for reset is "reset-gpios", fix this here.
--- arch/arm/boot/dts/omap3-n900.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/omap3-n900.dts +2 -2
@@ -510,7 +510,7 @@ tlv320aic3x: tlv320aic3x@18 { compatible = "ti,tlv320aic3x"; reg = <0x18>; - gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */ + reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */ ai3x-gpio-func = < 0 /* AIC3X_GPIO1_FUNC_DISABLED */ 5 /* AIC3X_GPIO2_FUNC_DIGITAL_MIC_INPUT */
@@ -527,7 +527,7 @@ tlv320aic3x_aux: tlv320aic3x@19 { compatible = "ti,tlv320aic3x"; reg = <0x19>; - gpio-reset = <&gpio2 28 GPIO_ACTIVE_HIGH>; /* 60 */ + reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>; /* 60 */ AVDD-supply = <&vmmc2>; DRVDD-supply = <&vmmc2>;
Greg Kroah-Hartman
maintainerPATCH 179/241 mtd: nand: ifc: update bufnum mask for ver >= 2.0.0
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jagdish Gediya <[email protected]>
[ Upstream commit bccb06c353af3764ca86d9da47652458e6c2eb41 ]
Bufnum mask is used to calculate page position in the internal SRAM.
As IFC version 2.0.0 has 16KB of internal SRAM as compared to older versions which had 8KB. Hence bufnum mask needs to be updated.
--- drivers/mtd/nand/fsl_ifc_nand.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/mtd/nand/fsl_ifc_nand.c +7 -0
@@ -907,6 +907,13 @@ static int fsl_ifc_chip_init(struct fsl_if (ctrl->version ==FSL_IFC_VERSION_1_1_0 )fsl_ifc_sram_init (priv); +/* +* As IFC version 2.0.0 has 16KB of internal SRAM as compared to older +* versions which had 8KB. Hence bufnum mask needs to be updated. +*/ +if (ctrl->version >=FSL_IFC_VERSION_2_0_0 ) + priv->bufnum_mask = (priv->bufnum_mask *2 ) +1 ; +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 180/241 userns: Dont fail follow_automount based on s_user_ns
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Eric W. Biederman" <[email protected]>
[ Upstream commit bbc3e471011417598e598707486f5d8814ec9c01 ]
When vfs_submount was added the test to limit automounts from filesystems that with s_user_ns != &init_user_ns accidentially left in follow_automount. The test was never about any security concerns and was always about how do we implement this for filesystems whose s_user_ns != &init_user_ns.
At the moment this check makes no difference as there are no filesystems that both set FS_USERNS_MOUNT and implement d_automount.
Remove this check now while I am thinking about it so there will not be odd booby traps for someone who does want to make this combination work.
vfs_submount still needs improvements to allow this combination to work, and vfs_submount contains a check that presents a warning.
The autofs4 filesystem could be modified to set FS_USERNS_MOUNT and it would need not work on this code path, as userspace performs the mounts.
--- fs/namei.c | 3 --- 1 file changed, 3 deletions(-)
fs/namei.c +0 -3
@@ -1121,9 +1121,6 @@ static int follow_automount(struct path path->dentry->d_inode)return -EISDIR ; -if (path->dentry->d_sb->s_user_ns != &init_user_ns) -return -EACCES ; - nd->total_link_count++;if (nd->total_link_count >=40 )return -ELOOP ;
Greg Kroah-Hartman
maintainerPATCH 181/241 leds: pm8058: Silence pointer to integer size warning
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Andersson <[email protected]>
[ Upstream commit 8f52df50d9366f770a894d14ef724e5e04574e98 ]
The pointer returned by of_device_get_match_data() doesn't have the same size as u32 on 64-bit architectures, causing a compile warning when compile-testing the driver on such platform.
Cast the return value of of_device_get_match_data() to unsigned long and then to u32 to silence this warning.
--- drivers/leds/leds-pm8058.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/leds/leds-pm8058.c +1 -1
@@ -106,7 +106,7 @@ static int pm8058_led_probe(struct platfif (!led)return -ENOMEM ; - led->ledtype = (u32 )of_device_get_match_data (&pdev->dev); + led->ledtype = (u32 )(unsigned long )of_device_get_match_data (&pdev->dev); map =dev_get_regmap (pdev->dev.parent,NULL );if (!map) {
Greg Kroah-Hartman
maintainerPATCH 182/241 power: supply: ab8500_charger: Fix an error handling path
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit bf59fddde1c3eab89eb8dca8f3d3dc097887d2bb ]
'ret' is know to be 0 at this point, because it has not been updated by the the previous call to 'abx500_mask_and_set_register_interruptible()'.
Fix it by updating 'ret' before checking if an error occurred.
--- drivers/power/supply/ab8500_charger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/power/supply/ab8500_charger.c +1 -1
@@ -3218,7 +3218,7 @@ static int ab8500_charger_init_hw_regist }/* Enable backup battery charging */ -abx500_mask_and_set_register_interruptible (di->dev, + ret =abx500_mask_and_set_register_interruptible (di->dev,AB8500_RTC ,AB8500_RTC_CTRL_REG ,RTC_BUP_CH_ENA ,RTC_BUP_CH_ENA );if (ret <0 )
Greg Kroah-Hartman
maintainerPATCH 183/241 power: supply: ab8500_charger: Bail out in case of error in ab8500_charger_init_hw_registers()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 09edcb647542487864e23aa8d2ef26be3e08978a ]
If an error occurs when we enable the backup battery charging, we should go through the error handling path directly.
Before commit db43e6c473b5 ("ab8500-bm: Add usb power path support") this was the case, but this commit has added some code between the last test and the 'out' label.
So, in case of error, this added code is executed and the error may be silently ignored.
Fix it by adding the missing 'goto out', as done in all other error handling paths.
--- drivers/power/supply/ab8500_charger.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/power/supply/ab8500_charger.c +3 -1
@@ -3221,8 +3221,10 @@ static int ab8500_charger_init_hw_regist ret =abx500_mask_and_set_register_interruptible (di->dev,AB8500_RTC ,AB8500_RTC_CTRL_REG ,RTC_BUP_CH_ENA ,RTC_BUP_CH_ENA ); -if (ret <0 ) +if (ret <0 ) {dev_err (di->dev,"%s mask and set failed\n" , __func__); + goto out; + }if (is_ab8540 (di->parent)) { ret = abx500_mask_and_set_register_interruptible(di->dev,
Greg Kroah-Hartman
maintainerPATCH 184/241 ath10k: update tdls teardown state to target
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manikanta Pubbisetty <[email protected]>
[ Upstream commit 424ea0d174e82365f85c6770225dba098b8f1d5f ]
It is required to update the teardown state of the peer when a tdls link with that peer is terminated. This information is useful for the target to perform some cleanups wrt the tdls peer.
Without proper cleanup, target assumes that the peer is connected and blocks future connection requests, updating the teardown state of the peer addresses the problem.
Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.
--- drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/net/wireless/ath/ath10k/mac.c +10 -0
@@ -6054,6 +6054,16 @@ static int ath10k_sta_state(struct ieee8"mac vdev %d peer delete %pM sta %pK (sta gone)\n" , arvif->vdev_id, sta->addr, sta); +if (sta->tdls) { + ret =ath10k_mac_tdls_peer_update (ar, arvif->vdev_id, + sta, +WMI_TDLS_PEER_STATE_TEARDOWN ); +if (ret) +ath10k_warn (ar,"failed to update tdls peer state for %pM state %d: %i\n" , + sta->addr, +WMI_TDLS_PEER_STATE_TEARDOWN , ret); + } + ret =ath10k_peer_delete (ar, arvif->vdev_id, sta->addr);if (ret) ath10k_warn(ar, "failed to delete peer %pM for vdev %d: %i\n",
Greg Kroah-Hartman
maintainerPATCH 185/241 dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Ujfalusi <[email protected]>
[ Upstream commit de92436ac40ffe9933230aa503e24dbb5ede9201 ]
To avoid race with vchan_complete, use the race free way to terminate running transfer.
Implement the device_synchronize callback to make sure that the terminated descriptor is freed.
--- drivers/dma/bcm2835-dma.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/dma/bcm2835-dma.c +9 -1
@@ -812,7 +812,7 @@ static int bcm2835_dma_terminate_all(str* c->desc is NULL and exit.) */ if (c->desc) { -bcm2835_dma_desc_free (&c->desc->vd); +vchan_terminate_vdesc (&c->desc->vd); c->desc =NULL ;bcm2835_dma_abort (c->chan_base);
@@ -836,6 +836,13 @@ static int bcm2835_dma_terminate_all(strreturn 0 ; } +static void bcm2835_dma_synchronize (struct dma_chan *chan) +{ +struct bcm2835_chan *c =to_bcm2835_dma_chan (chan); + +vchan_synchronize (&c->vc); +} +static int bcm2835_dma_chan_init (struct bcm2835_dmadev *d,int chan_id,int irq,unsigned int irq_flags) {
@@ -942,6 +949,7 @@ static int bcm2835_dma_probe(struct plat od->ddev.device_prep_dma_memcpy = bcm2835_dma_prep_dma_memcpy; od->ddev.device_config = bcm2835_dma_slave_config; od->ddev.device_terminate_all = bcm2835_dma_terminate_all; + od->ddev.device_synchronize = bcm2835_dma_synchronize; od->ddev.src_addr_widths =BIT (DMA_SLAVE_BUSWIDTH_4_BYTES ); od->ddev.dst_addr_widths =BIT (DMA_SLAVE_BUSWIDTH_4_BYTES ); od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV) |
Greg Kroah-Hartman
maintainerPATCH 186/241 scsi: ses: dont ask for diagnostic pages repeatedly during probe
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Li Dongyang <[email protected]>
[ Upstream commit 9c0a50022b8ac7e863e6ec8342fa476fe5d1d75c ]
We are testing if there is a match with the ses device in a loop by calling ses_match_to_enclosure(), which will issue scsi receive diagnostics commands to the ses device for every device on the same host. On one of our boxes with 840 disks, it takes a long time to load the driver:
[root@g1b-oss06 ~]# time modprobe ses
real 40m48.247s
user 0m0.001s
sys 0m0.196s
With the patch:
[root@g1b-oss06 ~]# time modprobe ses
real 0m17.915s
user 0m0.008s
sys 0m0.053s
Note that we still need to refresh page 10 when we see a new disk to create the link.
--- drivers/scsi/ses.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/scsi/ses.c +7 -4
@@ -578,13 +578,16 @@ static void ses_enclosure_data_process(s }static void ses_match_to_enclosure (struct enclosure_device *edev, -struct scsi_device *sdev) +struct scsi_device *sdev, +int refresh) { +struct scsi_device *edev_sdev =to_scsi_device (edev->edev.parent);struct efd efd = { .addr =0 , }; -ses_enclosure_data_process (edev,to_scsi_device (edev->edev.parent),0 ); +if (refresh) +ses_enclosure_data_process (edev, edev_sdev,0 );if (scsi_is_sas_rphy (sdev->sdev_target->dev.parent)) efd.addr =sas_get_address (sdev);
@@ -615,7 +618,7 @@ static int ses_intf_add(struct device *cstruct enclosure_device *prev =NULL ;while ((edev =enclosure_find (&sdev->host->shost_gendev, prev)) !=NULL ) { -ses_match_to_enclosure (edev, sdev); +ses_match_to_enclosure (edev, sdev,1 ); prev = edev; }return -ENODEV ;
@@ -727,7 +730,7 @@ static int ses_intf_add(struct device *cshost_for_each_device (tmp_sdev, sdev->host) {if (tmp_sdev->lun !=0 ||scsi_device_enclosure (tmp_sdev))continue ; -ses_match_to_enclosure (edev, tmp_sdev); +ses_match_to_enclosure (edev, tmp_sdev,0 ); }return 0 ;
Greg Kroah-Hartman
maintainerPATCH 187/241 pwm: stmpe: Fix wrong register offset for hwpwm=2 case
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
[ Upstream commit 8472b529e113e0863ea064fdee51bf73c3f86fd6 ]
Fix trivial copy/paste bug.
--- drivers/pwm/pwm-stmpe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pwm/pwm-stmpe.c +1 -1
@@ -145,7 +145,7 @@ static int stmpe_24xx_pwm_config(structbreak ;case 2 : - offset =STMPE24XX_PWMIC1 ; + offset =STMPE24XX_PWMIC2 ;break ;default :
Greg Kroah-Hartman
maintainerPATCH 188/241 clk: qcom: msm8916: fix mnd_width for codec_digcodec
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Kandagatla <[email protected]>
[ Upstream commit d8e488e8242ecf129eebc440c92d800a99ca109d ]
This patch fixes missing mnd_width for codec_digital clk, this is now set to 8 inline with datasheet.
--- drivers/clk/qcom/gcc-msm8916.c | 1 + 1 file changed, 1 insertion(+)
drivers/clk/qcom/gcc-msm8916.c +1 -0
@@ -1437,6 +1437,7 @@ static const struct freq_tbl ftbl_codec_static struct clk_rcg2 codec_digcodec_clk_src = { .cmd_rcgr =0x1c09c , + .mnd_width =8 , .hid_width =5 , .parent_map = gcc_xo_gpll1_emclk_sleep_map, .freq_tbl = ftbl_codec_clk,
Greg Kroah-Hartman
maintainerPATCH 189/241 mwifiex: cfg80211: do not change virtual interface during scan processing
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Limin Zhu <[email protected]>
[ Upstream commit c61cfe49f0f0f0d1f8b56d0b045838d597e8c3a3 ]
(1) Change virtual interface operation in cfg80211 process reset and reinitilize private data structure.
(2) Scan result event processed in main process will dereference private data structure concurrently, ocassionly crash the kernel.
The cornel case could be trigger by below steps:
(1) wpa_cli mlan0 scan
(2) ./hostapd mlan0.conf
Cfg80211 asynchronous scan procedure is not all the time operated under rtnl lock, here we add the protect to serialize the cfg80211 scan and change_virtual interface operation.
--- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/wireless/marvell/mwifiex/cfg80211.c +6 -0
@@ -1109,6 +1109,12 @@ mwifiex_cfg80211_change_virtual_intf(strstruct mwifiex_private *priv =mwifiex_netdev_get_priv (dev);enum nl80211_iftype curr_iftype = dev->ieee80211_ptr->iftype; +if (priv->scan_request) { +mwifiex_dbg (priv->adapter,ERROR , +"change virtual interface: scan in process\n" ); +return -EBUSY ; + } +switch (curr_iftype) {case NL80211_IFTYPE_ADHOC :switch (type) {
Greg Kroah-Hartman
maintainerPATCH 190/241 ath10k: fix invalid STS_CAP_OFFSET_MASK
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Greear <[email protected]>
[ Upstream commit 8cec57f5277ef0e354e37a0bf909dc71bc1f865b ]
The 10.4 firmware defines this as a 3-bit field, as does the mac80211 stack. The 4th bit is defined as CONF_IMPLICIT_BF at least in the firmware header I have seen. This patch fixes the ath10k wmi header to match the firmware.
--- drivers/net/wireless/ath/ath10k/wmi.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/wmi.h +2 -1
@@ -5017,7 +5017,8 @@ enum wmi_10_4_vdev_param {#define WMI_VDEV_PARAM_TXBF_MU_TX_BFER BIT(3)#define WMI_TXBF_STS_CAP_OFFSET_LSB 4 -#define WMI_TXBF_STS_CAP_OFFSET_MASK 0xf0 +#define WMI_TXBF_STS_CAP_OFFSET_MASK 0x70 +#define WMI_TXBF_CONF_IMPLICIT_BF BIT(7)#define WMI_BF_SOUND_DIM_OFFSET_LSB 8#define WMI_BF_SOUND_DIM_OFFSET_MASK 0xf00
Greg Kroah-Hartman
maintainerPATCH 191/241 tools/usbip: fixes build with musl libc toolchain
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julien BOIBESSOT <[email protected]>
[ Upstream commit 77be4c878c72e411ad22af96b6f81dd45c26450a ]
Indeed musl doesn't define old SIGCLD signal name but only new one SIGCHLD. SIGCHLD is the new POSIX name for that signal so it doesn't change anything on other libcs.
This fixes this kind of build error:
usbipd.c: In function ‘set_signal’:
usbipd.c:459:12: error: 'SIGCLD' undeclared (first use in this function)
sigaction(SIGCLD, &act, NULL);
^~~~~~usbipd.c:459:12: note: each undeclared identifier is reported only once
for each function it appears in
Makefile:407: recipe for target 'usbipd.o' failed
make[3]: *** [usbipd.o] Error 1
--- tools/usb/usbip/src/usbipd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/usb/usbip/src/usbipd.c +1 -1
@@ -463,7 +463,7 @@ static void set_signal(void)sigaction (SIGTERM , &act,NULL );sigaction (SIGINT , &act,NULL ); act.sa_handler =SIG_IGN ; -sigaction (SIGCLD , &act,NULL ); +sigaction (SIGCHLD , &act,NULL ); }static const char *pid_file;
Greg Kroah-Hartman
maintainerPATCH 192/241 spi: sun6i: disable/unprepare clocks on remove
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tobias Jordan <[email protected]>
[ Upstream commit 2d9bbd02c54094ceffa555143b0d68cd06504d63 ]
sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable clocks, so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to disable/unprepare them if we're not suspended.
Replacing pm_runtime_disable() by pm_runtime_force_suspend() will ensure that sun6i_spi_runtime_suspend() is called if needed.
Found by Linux Driver Verification project (linuxtesting.org).
--- drivers/spi/spi-sun6i.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-sun6i.c +1 -1
@@ -464,7 +464,7 @@ err_free_master:static int sun6i_spi_remove (struct platform_device *pdev) { -pm_runtime_disable (&pdev->dev); +pm_runtime_force_suspend (&pdev->dev);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 193/241 bnxt_en: Dont print "Link speed -1 no longer supported" messages.
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Chan <[email protected]>
[ Upstream commit a8168b6cee6e9334dfebb4b9108e8d73794f6088 ]
On some dual port NICs, the 2 ports have to be configured with compatible link speeds. Under some conditions, a port's configured speed may no longer be supported. The firmware will send a message to the driver when this happens.
Improve this logic that prints out the warning by only printing it if we can determine the link speed that is no longer supported. If the speed is unknown or it is in autoneg mode, skip the warning message.
--- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
drivers/net/ethernet/broadcom/bnxt/bnxt.c +7 -3
@@ -1498,12 +1498,16 @@ static int bnxt_async_event_process(struif (BNXT_VF (bp)) goto async_event_process_exit; -if (data1 &0x20000 ) { + +/* print unsupported speed warning in forced speed mode only */ +if (!(link_info->autoneg &BNXT_AUTONEG_SPEED ) && + (data1 &0x20000 )) {u16 fw_speed = link_info->force_link_speed;u32 speed =bnxt_fw_to_ethtool_speed (fw_speed); -netdev_warn (bp->dev,"Link speed %d no longer supported\n" , - speed); +if (speed !=SPEED_UNKNOWN ) +netdev_warn (bp->dev,"Link speed %d no longer supported\n" , + speed); }set_bit (BNXT_LINK_SPEED_CHNG_SP_EVENT , &bp->sp_event);/* fall thru */
Greg Kroah-Hartman
maintainerPATCH 194/241 scsi: core: scsi_get_device_flags_keyed(): Always return device flags
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bart Van Assche <[email protected]>
[ Upstream commit a44c9d36509c83cf64f33b93f6ab2e63822c01eb ]
Since scsi_get_device_flags_keyed() callers do not check whether or not the returned value is an error code, change that function such that it returns a flags value even if the 'key' argument is invalid. Note:
since commit 28a0bc4120d3 ("scsi: sd: Implement blacklist option for WRITE SAME w/ UNMAP") bit 31 is a valid device information flag so checking whether bit 31 is set in the return value is not sufficient to tell the difference between an error code and a flags value.
--- drivers/scsi/scsi_devinfo.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
drivers/scsi/scsi_devinfo.c +1 -6
@@ -596,17 +596,12 @@ int scsi_get_device_flags_keyed(struct s int key) {struct scsi_dev_info_list *devinfo; -int err; devinfo =scsi_dev_info_list_find (vendor, model, key);if (!IS_ERR (devinfo))return devinfo->flags; - err =PTR_ERR (devinfo); -if (err != -ENOENT ) -return err; - -/* nothing found, return nothing */ +/* key or device not found: return nothing */ if (key !=SCSI_DEVINFO_GLOBAL )return 0 ;
Greg Kroah-Hartman
maintainerPATCH 195/241 scsi: devinfo: apply to HP XP the same flags as Hitachi VSP
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xose Vazquez Perez <[email protected]>
[ Upstream commit b369a0471503130cfc74f9f62071db97f48948c3 ]
Commit 56f3d383f37b ("scsi: scsi_devinfo: Add TRY_VPD_PAGES to HITACHI OPEN-V blacklist entry") modified some Hitachi entries:
HITACHI is always supporting VPD pages, even though it's claiming to support SCSI Revision 3 only.
The same should have been done also for HP-rebranded.
[mkp: checkpatch and tweaked commit message]
--- drivers/scsi/scsi_devinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/scsi_devinfo.c +1 -1
@@ -180,7 +180,7 @@ static struct { {"HITACHI", "6586-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HITACHI", "6588-", "*", BLIST_SPARSELUN | BLIST_LARGELUN}, {"HP", "A6189A", NULL, BLIST_SPARSELUN | BLIST_LARGELUN}, /* HP VA7400 */ - {"HP", "OPEN-", "*", BLIST_REPORTLUN2}, /* HP XP Arrays */ + {"HP", "OPEN-", "*", BLIST_REPORTLUN2 | BLIST_TRY_VPD_PAGES}, /* HP XP Arrays */ {"HP", "NetRAID-4M", NULL, BLIST_FORCELUN}, {"HP", "HSV100", NULL, BLIST_REPORTLUN2 | BLIST_NOSTARTONADD}, {"HP", "C1557A", NULL, BLIST_FORCELUN},
Greg Kroah-Hartman
maintainerPATCH 196/241 scsi: dh: add new rdac devices
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xose Vazquez Perez <[email protected]>
[ Upstream commit 4b3aec2bbbce1c35f50e7475a9fd78d24b9ea4ea ]
Add IBM 3542 and 3552, arrays: FAStT200 and FAStT500.
Add full STK OPENstorage family, arrays: 9176, D173, D178, D210, D220, D240 and D280.
Add STK BladeCtlr family, arrays: B210, B220, B240 and B280.
These changes were done in multipath-tools time ago.
--- drivers/scsi/scsi_dh.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/scsi_dh.c +4 -1
@@ -56,10 +56,13 @@ static const struct scsi_dh_blist scsi_d {"IBM", "1815", "rdac", }, {"IBM", "1818", "rdac", }, {"IBM", "3526", "rdac", }, + {"IBM", "3542", "rdac", }, + {"IBM", "3552", "rdac", }, {"SGI", "TP9", "rdac", }, {"SGI", "IS", "rdac", }, - {"STK", "OPENstorage D280", "rdac", }, + {"STK", "OPENstorage", "rdac", }, {"STK", "FLEXLINE 380", "rdac", }, + {"STK", "BladeCtlr", "rdac", }, {"SUN", "CSM", "rdac", }, {"SUN", "LCSM100", "rdac", }, {"SUN", "STK6580_6780", "rdac", },
Greg Kroah-Hartman
maintainerPATCH 197/241 media: vsp1: Prevent suspending and resuming DRM pipelines
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kieran Bingham <[email protected]>
[ Upstream commit a17d2d6cd9985ca09a9e384f1bc71d710f7e5203 ]
When used as part of a display pipeline, the VSP is stopped and restarted explicitly by the DU from its suspend and resume handlers. There is thus no need to stop or restart pipelines in the VSP suspend and resume handlers, and doing so would cause the hardware to be left in a misconfigured state.
Ensure that the VSP suspend and resume handlers do not affect DRM-based pipelines.
--- drivers/media/platform/vsp1/vsp1_drv.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
drivers/media/platform/vsp1/vsp1_drv.c +14 -2
@@ -509,7 +509,13 @@ static int __maybe_unused vsp1_pm_suspen {struct vsp1_device *vsp1 =dev_get_drvdata (dev); -vsp1_pipelines_suspend (vsp1); +/* +* When used as part of a display pipeline, the VSP is stopped and +* restarted explicitly by the DU. +*/ +if (!vsp1->drm) +vsp1_pipelines_suspend (vsp1); +pm_runtime_force_suspend (vsp1->dev);return 0 ;
@@ -520,7 +526,13 @@ static int __maybe_unused vsp1_pm_resumestruct vsp1_device *vsp1 =dev_get_drvdata (dev);pm_runtime_force_resume (vsp1->dev); -vsp1_pipelines_resume (vsp1); + +/* +* When used as part of a display pipeline, the VSP is stopped and +* restarted explicitly by the DU. +*/ +if (!vsp1->drm) +vsp1_pipelines_resume (vsp1);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 198/241 media: cpia2: Fix a couple off by one bugs
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit d5ac225c7d64c9c3ef821239edc035634e594ec9 ]
The cam->buffers[] array has cam->num_frames elements so the > needs to be changed to >= to avoid going beyond the end of the array. The ->buffers[] array is allocated in cpia2_allocate_buffers() if you want to confirm.
--- drivers/media/usb/cpia2/cpia2_v4l.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/media/usb/cpia2/cpia2_v4l.c +2 -2
@@ -812,7 +812,7 @@ static int cpia2_querybuf(struct file *fstruct camera_data *cam =video_drvdata (file);if (buf->type !=V4L2_BUF_TYPE_VIDEO_CAPTURE || - buf->index > cam->num_frames) + buf->index >= cam->num_frames)return -EINVAL ; buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
@@ -863,7 +863,7 @@ static int cpia2_qbuf(struct file *file,if (buf->type !=V4L2_BUF_TYPE_VIDEO_CAPTURE || buf->memory !=V4L2_MEMORY_MMAP || - buf->index > cam->num_frames) + buf->index >= cam->num_frames)return -EINVAL ;DBG ("QBUF #%d\n" , buf->index);
Greg Kroah-Hartman
maintainerPATCH 199/241 veth: set peer GSO values
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephen Hemminger <[email protected]>
[ Upstream commit 72d24955b44a4039db54a1c252b5031969eeaac3 ]
When new veth is created, and GSO values have been configured on one device, clone those values to the peer.
For example:
# ip link add dev vm1 gso_max_size 65530 type veth peer name vm2
This should create vm1 <--> vm2 with both having GSO maximum size set to 65530.
--- drivers/net/veth.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/veth.c +3 -0
@@ -425,6 +425,9 @@ static int veth_newlink(struct net *src_if (ifmp && (dev->ifindex !=0 )) peer->ifindex = ifmp->ifi_index; + peer->gso_max_size = dev->gso_max_size; + peer->gso_max_segs = dev->gso_max_segs; + err =register_netdevice (peer);put_net (net); net =NULL ;
Greg Kroah-Hartman
maintainerPATCH 200/241 drm/amdkfd: Fix memory leaks in kfd topology
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yong Zhao <[email protected]>
[ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ]
Kobject created using kobject_create_and_add() can be freed using kobject_put() when there is no referenece any more. However, kobject memory allocated with kzalloc() has to set up a release callback in order to free it when the counter decreases to 0. Otherwise it causes memory leak.
--- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/gpu/drm/amd/amdkfd/kfd_topology.c +10 -0
@@ -519,11 +519,17 @@ static ssize_t sysprops_show(struct kobjreturn ret; } +static void kfd_topology_kobj_release (struct kobject *kobj) +{ +kfree (kobj); +} +static const struct sysfs_ops sysprops_ops = { .show = sysprops_show, };static struct kobj_type sysprops_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &sysprops_ops, };
@@ -559,6 +565,7 @@ static const struct sysfs_ops iolink_ops };static struct kobj_type iolink_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &iolink_ops, };
@@ -586,6 +593,7 @@ static const struct sysfs_ops mem_ops = };static struct kobj_type mem_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &mem_ops, };
@@ -625,6 +633,7 @@ static const struct sysfs_ops cache_ops };static struct kobj_type cache_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &cache_ops, };
@@ -747,6 +756,7 @@ static const struct sysfs_ops node_ops = };static struct kobj_type node_type = { + .release = kfd_topology_kobj_release, .sysfs_ops = &node_ops, };
Greg Kroah-Hartman
maintainerPATCH 201/241 powerpc/modules: Dont try to restore r2 after a sibling call
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Josh Poimboeuf <[email protected]>
[ Upstream commit b9eab08d012fa093947b230f9a87257c27fb829b ]
When attempting to load a livepatch module, I got the following error:
module_64: patch_module: Expect noop after relocate, got 3c820000
The error was triggered by the following code inunregister_netdevice_queue():
14c: 00 00 00 48 b 14c <unregister_netdevice_queue+0x14c>
14c: R_PPC64_REL24 net_set_todo
150: 00 00 82 3c addis r4,r2,0
GCC didn't insert a nop after the branch to net_set_todo() because it's a sibling call, so it never returns. The nop isn't needed after the branch in that case.
--- arch/powerpc/include/asm/code-patching.h | 1 + arch/powerpc/kernel/module_64.c | 12 +++++++++++- arch/powerpc/lib/code-patching.c | 5 +++++ 3 files changed, 17 insertions(+), 1 deletion(-)
arch/powerpc/include/asm/code-patching.h +1 -0
@@ -30,6 +30,7 @@ int patch_branch(unsigned int *addr, unsint patch_instruction (unsigned int *addr,unsigned int instr);int instr_is_relative_branch (unsigned int instr); +int instr_is_relative_link_branch (unsigned int instr);int instr_is_branch_to_addr (const unsigned int *instr,unsigned long addr);unsigned long branch_target (const unsigned int *instr); unsigned int translate_branch(const unsigned int *dest,
arch/powerpc/kernel/module_64.c +11 -1
@@ -494,7 +494,17 @@ static bool is_early_mcount_callsite(u32restore r2. */ static int restore_r2 (u32 *instruction,struct module *me) { -if (is_early_mcount_callsite (instruction -1 )) +u32 *prev_insn = instruction -1 ; + +if (is_early_mcount_callsite (prev_insn)) +return 1 ; + +/* +* Make sure the branch isn't a sibling call. Sibling calls aren't +* "link" branches and they don't return, so they don't need the r2 +* restore afterwards. +*/ +if (!instr_is_relative_link_branch (*prev_insn))return 1 ;if (*instruction !=PPC_INST_NOP ) {
arch/powerpc/lib/code-patching.c +5 -0
@@ -95,6 +95,11 @@ int instr_is_relative_branch(unsigned inreturn instr_is_branch_iform (instr) ||instr_is_branch_bform (instr); } +int instr_is_relative_link_branch (unsigned int instr) +{ +return instr_is_relative_branch (instr) && (instr &BRANCH_SET_LINK ); +} +static unsigned long branch_iform_target (const unsigned int *instr) {signed long imm;
Greg Kroah-Hartman
maintainerPATCH 202/241 agp/intel: Flush all chipset writes after updating the GGTT
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
[ Upstream commit 8516673a996870ea0ceb337ee4f83c33c5ec3111 ]
Before accessing the GGTT we must flush the PTE writes and make them visible to the chipset, or else the indirect access may end up in the wrong page. In commit 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE"), we noticed corruption of the uploads for pwrite and for capturing GPU error states, but it was presumed that the explicit calls to intel_gtt_chipset_flush() were sufficient for the execbuffer path. However, we have not been flushing the chipset between the PTE writes and access via the GTT itself.
For simplicity, do the flush after any PTE update rather than try and batch the flushes on a just-in-time basis.
References: 3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
--- drivers/char/agp/intel-gtt.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/char/agp/intel-gtt.c +2 -0
@@ -871,6 +871,8 @@ void intel_gtt_insert_sg_entries(struct } }wmb (); +if (intel_private.driver->chipset_flush) + intel_private.driver->chipset_flush (); }EXPORT_SYMBOL (intel_gtt_insert_sg_entries);
Greg Kroah-Hartman
maintainerPATCH 203/241 mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adiel Aloni <[email protected]>
[ Upstream commit e16ea4bb516bc21ea2202f2107718b29218bea59 ]
Enforce using PS_MANUAL_POLL in ps hwsim debugfs to trigger a poll, only if PS_ENABLED was set before.
This is required due to commit c9491367b759 ("mac80211: always update the PM state of a peer on MGMT / DATA frames") that enforces the ap to check only mgmt/data frames ps bit, and then update station's power save accordingly.
When sending only ps-poll (control frame) the ap will not be aware that the station entered power save.
Setting ps enable before triggering ps_poll, will send NDP with PM bit enabled first.
--- drivers/net/wireless/mac80211_hwsim.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/net/wireless/mac80211_hwsim.c +11 -6
@@ -728,16 +728,21 @@ static int hwsim_fops_ps_write(void *dat val != PS_MANUAL_POLL)return -EINVAL ; - old_ps = data->ps; - data->ps = val; - -local_bh_disable ();if (val ==PS_MANUAL_POLL ) { +if (data->ps !=PS_ENABLED ) +return -EINVAL ; +local_bh_disable ();ieee80211_iterate_active_interfaces_atomic ( data->hw,IEEE80211_IFACE_ITER_NORMAL , hwsim_send_ps_poll, data); - data->ps_poll_pending = true; - }else if (old_ps ==PS_DISABLED && val !=PS_DISABLED ) { +local_bh_enable (); +return 0 ; + } + old_ps = data->ps; + data->ps = val; + +local_bh_disable (); +if (old_ps ==PS_DISABLED && val !=PS_DISABLED ) {ieee80211_iterate_active_interfaces_atomic ( data->hw,IEEE80211_IFACE_ITER_NORMAL , hwsim_send_nullfunc_ps, data);
Greg Kroah-Hartman
maintainerPATCH 204/241 mac80211: remove BUG() when interface type is invalid
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luca Coelho <[email protected]>
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid and, if not, call BUG(). This should never happen, but if there is something wrong with the code, it will not be caught until the bug happens when an interface is being set up. Calling BUG() is too extreme for this and a WARN_ON() would be better used instead. Change that.
--- net/mac80211/iface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/mac80211/iface.c +1 -1
@@ -1520,7 +1520,7 @@ static void ieee80211_setup_sdata(structbreak ;case NL80211_IFTYPE_UNSPECIFIED :case NUM_NL80211_IFTYPES : -BUG (); +WARN_ON (1 );break ; }
Greg Kroah-Hartman
maintainerPATCH 205/241 ASoC: nuc900: Fix a loop timeout test
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 65a12b3aafed5fc59f4ce41b22b752b1729e6701 ]
We should be finishing the loop with timeout set to zero but because this is a post-op we finish with timeout == -1.
--- sound/soc/nuc900/nuc900-ac97.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/soc/nuc900/nuc900-ac97.c +2 -2
@@ -67,7 +67,7 @@ static unsigned short nuc900_ac97_read(s/* polling the AC_R_FINISH */ while (!(AUDIO_READ (nuc900_audio->mmio +ACTL_ACCON ) &AC_R_FINISH ) - && timeout--) + && --timeout)mdelay (1 );if (!timeout) {
@@ -121,7 +121,7 @@ static void nuc900_ac97_write(struct snd/* polling the AC_W_FINISH */ while ((AUDIO_READ (nuc900_audio->mmio +ACTL_ACCON ) &AC_W_FINISH ) - && timeout--) + && --timeout)mdelay (1 );if (!timeout)
Greg Kroah-Hartman
maintainerPATCH 206/241 ipvlan: add L2 check for packets arriving via virtual devices
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mahesh Bandewar <[email protected]>
[ Upstream commit 92ff42645028fa6f9b8aa767718457b9264316b4 ]
Packets that don't have dest mac as the mac of the master device should not be entertained by the IPvlan rx-handler. This is mostly true as the packet path mostly takes care of that, except when the master device is a virtual device. As demonstrated in the following case -
ip netns add ns1
ip link add ve1 type veth peer name ve2
ip link add link ve2 name iv1 type ipvlan mode l2 ip link set dev iv1 netns ns1
ip link set ve1 up
ip link set ve2 up
ip -n ns1 link set iv1 up
ip addr add 192.168.10.1/24 dev ve1
ip -n ns1 addr 192.168.10.2/24 dev iv1 ping -c2 192.168.10.2
<Works!>
ip neigh show dev ve1
ip neigh show 192.168.10.2 lladdr <random> dev ve1 ping -c2 192.168.10.2
<Still works! Wrong!!>
This patch adds that missing check in the IPvlan rx-handler.
--- drivers/net/ipvlan/ipvlan_core.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ipvlan/ipvlan_core.c +4 -0
@@ -299,6 +299,10 @@ static int ipvlan_rcv_frame(struct ipvl_if (dev_forward_skb (ipvlan->dev, skb) ==NET_RX_SUCCESS ) success = true; }else { +if (!ether_addr_equal_64bits (eth_hdr (skb)->h_dest, + ipvlan->phy_dev->dev_addr)) + skb->pkt_type =PACKET_OTHERHOST ; + ret =RX_HANDLER_ANOTHER ; success = true; }
Greg Kroah-Hartman
maintainerPATCH 207/241 rcutorture/configinit: Fix build directory error message
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: SeongJae Park <[email protected]>
[ Upstream commit 2adfa4210f8f35cdfb4e08318cc06b99752964c2 ]
The 'configinit.sh' script checks the format of optional argument for the build directory, printing an error message if the format is not valid. However, the error message uses the wrong variable, indicating an empty string even though the user entered a non-empty (but erroneous) string. This commit fixes the script to use the correct variable.
--- tools/testing/selftests/rcutorture/bin/configinit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/rcutorture/bin/configinit.sh +1 -1
@@ -51,7 +51,7 @@ then mkdir $builddir fi else - echo Bad build directory: \"$builddir\" + echo Bad build directory: \"$buildloc\" exit 2 fi fi
Greg Kroah-Hartman
maintainerPATCH 208/241 locking/locktorture: Fix num reader/writer corner cases
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Davidlohr Bueso <[email protected]>
[ Upstream commit 2ce77d16db4240dd2e422fc0a5c26d3e2ec03446 ]
Things can explode for locktorture if the user does combinations of nwriters_stress=0 nreaders_stress=0. Fix this by not assuming we always want to torture writer threads.
--- kernel/locking/locktorture.c | 76 ++++++++++++++++++++++++------------------- 1 file changed, 44 insertions(+), 32 deletions(-)
kernel/locking/locktorture.c +44 -32
@@ -641,8 +641,7 @@ static void __torture_print_stats(char * {bool fail =0 ;int i, n_stress; -long max =0 ; -long min = statp[0 ].n_lock_acquired; +long max =0 , min = statp ? statp[0 ].n_lock_acquired :0 ;long long sum =0 ; n_stress = write ? cxt.nrealwriters_stress : cxt.nrealreaders_stress;
@@ -749,7 +748,7 @@ static void lock_torture_cleanup(void)* such, only perform the underlying torture-specific cleanups, * and avoid anything related to locktorture. */ -if (!cxt.lwsa) +if (!cxt.lwsa && !cxt.lrsa) goto end;if (writer_tasks) {
@@ -823,6 +822,13 @@ static int __init lock_torture_init(void firsterr = -EINVAL ; goto unwind; } + +if (nwriters_stress ==0 && nreaders_stress ==0 ) { +pr_alert ("lock-torture: must run at least one locking thread\n" ); + firsterr = -EINVAL ; + goto unwind; + } +if (cxt.cur_ops->init) cxt.cur_ops->init ();
@@ -846,17 +852,19 @@ static int __init lock_torture_init(void#endif /* Initialize the statistics so that each run gets its own numbers. */ +if (nwriters_stress) { + lock_is_write_held =0 ; + cxt.lwsa =kmalloc (sizeof (*cxt.lwsa) * cxt.nrealwriters_stress,GFP_KERNEL ); +if (cxt.lwsa ==NULL ) { +VERBOSE_TOROUT_STRING ("cxt.lwsa: Out of memory" ); + firsterr = -ENOMEM ; + goto unwind; + } - lock_is_write_held =0 ; - cxt.lwsa =kmalloc (sizeof (*cxt.lwsa) * cxt.nrealwriters_stress,GFP_KERNEL ); -if (cxt.lwsa ==NULL ) { -VERBOSE_TOROUT_STRING ("cxt.lwsa: Out of memory" ); - firsterr = -ENOMEM ; - goto unwind; - } -for (i =0 ; i < cxt.nrealwriters_stress; i++) { - cxt.lwsa[i].n_lock_fail =0 ; - cxt.lwsa[i].n_lock_acquired =0 ; +for (i =0 ; i < cxt.nrealwriters_stress; i++) { + cxt.lwsa[i].n_lock_fail =0 ; + cxt.lwsa[i].n_lock_acquired =0 ; + } }if (cxt.cur_ops->readlock) {
@@ -873,19 +881,21 @@ static int __init lock_torture_init(void cxt.nrealreaders_stress = cxt.nrealwriters_stress; } - lock_is_read_held =0 ; - cxt.lrsa =kmalloc (sizeof (*cxt.lrsa) * cxt.nrealreaders_stress,GFP_KERNEL ); -if (cxt.lrsa ==NULL ) { -VERBOSE_TOROUT_STRING ("cxt.lrsa: Out of memory" ); - firsterr = -ENOMEM ; -kfree (cxt.lwsa); - cxt.lwsa =NULL ; - goto unwind; - } - -for (i =0 ; i < cxt.nrealreaders_stress; i++) { - cxt.lrsa[i].n_lock_fail =0 ; - cxt.lrsa[i].n_lock_acquired =0 ; +if (nreaders_stress) { + lock_is_read_held =0 ; + cxt.lrsa =kmalloc (sizeof (*cxt.lrsa) * cxt.nrealreaders_stress,GFP_KERNEL ); +if (cxt.lrsa ==NULL ) { +VERBOSE_TOROUT_STRING ("cxt.lrsa: Out of memory" ); + firsterr = -ENOMEM ; +kfree (cxt.lwsa); + cxt.lwsa =NULL ; + goto unwind; + } + +for (i =0 ; i < cxt.nrealreaders_stress; i++) { + cxt.lrsa[i].n_lock_fail =0 ; + cxt.lrsa[i].n_lock_acquired =0 ; + } } }
@@ -915,12 +925,14 @@ static int __init lock_torture_init(void goto unwind; } - writer_tasks =kzalloc (cxt.nrealwriters_stress *sizeof (writer_tasks[0 ]), -GFP_KERNEL ); -if (writer_tasks ==NULL ) { -VERBOSE_TOROUT_ERRSTRING ("writer_tasks: Out of memory" ); - firsterr = -ENOMEM ; - goto unwind; +if (nwriters_stress) { + writer_tasks =kzalloc (cxt.nrealwriters_stress *sizeof (writer_tasks[0 ]), +GFP_KERNEL ); +if (writer_tasks ==NULL ) { +VERBOSE_TOROUT_ERRSTRING ("writer_tasks: Out of memory" ); + firsterr = -ENOMEM ; + goto unwind; + } }if (cxt.cur_ops->readlock) {
Greg Kroah-Hartman
maintainerPATCH 209/241 ima: relax requiring a file signature for new files with zero length
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mimi Zohar <[email protected]>
[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]
Custom policies can require file signatures based on LSM labels. These files are normally created and only afterwards labeled, requiring them to be signed.
Instead of requiring file signatures based on LSM labels, entire filesystems could require file signatures. In this case, we need the ability of writing new files without requiring file signatures.
The definition of a "new" file was originally defined as any file with a length of zero. Subsequent patches redefined a "new" file to be based on the FILE_CREATE open flag. By combining the open flag with a file size of zero, this patch relaxes the file signature requirement.
--- security/integrity/ima/ima_appraise.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
security/integrity/ima/ima_appraise.c +2 -1
@@ -207,7 +207,8 @@ int ima_appraise_measurement(enum ima_hoif (opened &FILE_CREATED ) iint->flags |=IMA_NEW_FILE ;if ((iint->flags &IMA_NEW_FILE ) && - !(iint->flags &IMA_DIGSIG_REQUIRED )) + (!(iint->flags &IMA_DIGSIG_REQUIRED ) || + (inode->i_size ==0 ))) status =INTEGRITY_PASS ; goto out; }
Greg Kroah-Hartman
maintainerPATCH 210/241 net: hns: Some checkpatch.pl script & warning fixes
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Salil <[email protected]>
commit b4957ab0826f6f7efdfdc648521e1c4c3fc6ceda upstream.
This patch fixes some checkpatch.pl script caught errors and warnings during the compilation time.
[ backported to 4.9.y to fix build warnings caused by the backporting of
64ec10dc2ab8 ("net: hns: Correct HNS RSS key set function") by Sasha
- gregkh]
--- drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 11 +++++------ drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 2 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 1 - drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +++-- drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 1 - 5 files changed, 9 insertions(+), 11 deletions(-)
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c +5 -6
@@ -86,12 +86,11 @@ static void hns_gmac_disable(void *mac_ddsaf_set_dev_bit (drv,GMAC_PORT_EN_REG ,GMAC_PORT_RX_EN_B ,0 ); } -/** -*hns_gmac_get_en - get port enable -*@mac_drv:mac device -*@rx:rx enable -*@tx:tx enable -*/ +/* hns_gmac_get_en - get port enable +* @mac_drv:mac device +* @rx:rx enable +* @tx:tx enable +*/ static void hns_gmac_get_en (void *mac_drv,u32 *rx,u32 *tx) {struct mac_driver *drv = (struct mac_driver *)mac_drv;
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h +1 -1
@@ -70,7 +70,7 @@ enum dsaf_roce_qos_sl { };#define DSAF_STATS_READ (p, offset) (*((u64 *)((u8 *)(p) + (offset)))) -#define HNS_DSAF_IS_DEBUG (dev) (dev->dsaf_mode == DSAF_MODE_DISABLE_SP) +#define HNS_DSAF_IS_DEBUG (dev) ((dev)->dsaf_mode == DSAF_MODE_DISABLE_SP)enum hal_dsaf_mode {HRD_DSAF_NO_DSAF_MODE =0x0 ,
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c +0 -1
@@ -430,7 +430,6 @@ static void hns_rcb_ring_pair_get_cfg(ststatic int hns_rcb_get_port_in_comm (struct rcb_common_cb *rcb_common,int ring_idx) { -return ring_idx / (rcb_common->max_q_per_vf * rcb_common->max_vfn); }
drivers/net/ethernet/hisilicon/hns/hns_enet.c +3 -2
@@ -511,7 +511,8 @@ static void hns_nic_reuse_page(struct skint last_offset;bool twobufs; - twobufs = ((PAGE_SIZE <8192 ) &&hnae_buf_size (ring) ==HNS_BUFFER_SIZE_2048 ); + twobufs = ((PAGE_SIZE <8192 ) && +hnae_buf_size (ring) ==HNS_BUFFER_SIZE_2048 ); desc = &ring->desc[ring->next_to_clean]; size =le16_to_cpu (desc->rx.size);
@@ -1700,7 +1701,7 @@ static void hns_nic_reset_subtask(structstatic void hns_nic_service_event_complete (struct hns_nic_priv *priv) {WARN_ON (!test_bit (NIC_STATE_SERVICE_SCHED , &priv->state)); - +/* make sure to commit the things */ smp_mb__before_atomic ();clear_bit (NIC_STATE_SERVICE_SCHED , &priv->state); }
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c +0 -1
@@ -1243,7 +1243,6 @@ hns_set_rss(struct net_device *netdev, c {struct hns_nic_priv *priv =netdev_priv (netdev);struct hnae_ae_ops *ops; -int ret;if (AE_IS_VER1 (priv->enet_ver)) { netdev_err(netdev,
Greg Kroah-Hartman
maintainerPATCH 211/241 x86/boot/32: Fix UP boot on Quark and possibly other platforms
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit d2b6dc61a8dd3c429609b993778cb54e75a5c5f0 upstream.
This partially reverts commit:
23b2a4ddebdd17f ("x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up")
That commit had one definite bug and one potential bug. The definite bug is that setup_per_cpu_areas() uses a differnet generic implementation on UP kernels, so initial_page_table never got resynced. This was fine for access to percpu data (it's in the identity map on UP), but it breaks other users of initial_page_table. The potential bug is that helpers like efi_init() would be called before the tables were synced.
Avoid both problems by just syncing the page tables in setup_arch() *and* setup_per_cpu_areas().
--- arch/x86/kernel/setup.c | 15 +++++++++++++++ arch/x86/kernel/setup_percpu.c | 10 +++++----- 2 files changed, 20 insertions(+), 5 deletions(-)
arch/x86/kernel/setup.c +15 -0
@@ -1200,6 +1200,21 @@ void __init setup_arch(char **cmdline_p)kasan_init (); +#ifdef CONFIG_X86_32 +/* sync back kernel address range */ +clone_pgd_range (initial_page_table +KERNEL_PGD_BOUNDARY , + swapper_pg_dir +KERNEL_PGD_BOUNDARY , +KERNEL_PGD_PTRS ); + +/* +* sync back low identity map too. It is used for example +* in the 32-bit EFI stub. +*/ +clone_pgd_range (initial_page_table, + swapper_pg_dir +KERNEL_PGD_BOUNDARY , +min (KERNEL_PGD_PTRS ,KERNEL_PGD_BOUNDARY )); +#endif +tboot_probe ();map_vsyscall ();
arch/x86/kernel/setup_percpu.c +5 -5
@@ -290,11 +290,11 @@ void __init setup_per_cpu_areas(void)#ifdef CONFIG_X86_32 /* -* Sync back kernel address range. We want to make sure that -* all kernel mappings, including percpu mappings, are available -* in the smpboot asm. We can't reliably pick up percpu -* mappings using vmalloc_fault(), because exception dispatch -* needs percpu data. +* Sync back kernel address range again. We already did this in +* setup_arch(), but percpu data also needs to be available in +* the smpboot asm. We can't reliably pick up percpu mappings +* using vmalloc_fault(), because exception dispatch needs +* percpu data. */ clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY, swapper_pg_dir + KERNEL_PGD_BOUNDARY,
Greg Kroah-Hartman
maintainerPATCH 212/241 x86/cpufeatures: Add Intel PCONFIG cpufeature
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill A. Shutemov <[email protected]>
commit 7958b2246fadf54b7ff820a2a5a2c5ca1554716f upstream.
CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction.
--- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -302,6 +302,7 @@/* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */ #define X86_FEATURE_AVX512_4VNNIW (18*32+ 2)/* AVX-512 Neural Network Instructions */ #define X86_FEATURE_AVX512_4FMAPS (18*32+ 3)/* AVX-512 Multiply Accumulation Single precision */ +#define X86_FEATURE_PCONFIG (18*32+18)/* Intel PCONFIG */ #define X86_FEATURE_SPEC_CTRL (18*32+26)/* "" Speculation Control (IBRS + IBPB) */ #define X86_FEATURE_INTEL_STIBP (18*32+27)/* "" Single Thread Indirect Branch Predictors */ #define X86_FEATURE_ARCH_CAPABILITIES (18*32+29)/* IA32_ARCH_CAPABILITIES MSR (Intel) */
Greg Kroah-Hartman
maintainerPATCH 213/241 selftests/x86/entry_from_vm86: Exit with 1 if we fail
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream.
Fix a logic error that caused the test to exit with 0 even if test cases failed.
--- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/testing/selftests/x86/entry_from_vm86.c +1 -1
@@ -231,7 +231,7 @@ int main(void)clearhandler (SIGSEGV );/* Make sure nothing explodes if we fork. */ -if (fork () >0 ) +if (fork () ==0 )return 0 ;return (nerrs ==0 ?0 :1 );
Greg Kroah-Hartman
maintainerPATCH 214/241 selftests/x86: Add tests for User-Mode Instruction Prevention
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Neri <[email protected]>
commit 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e upstream.
Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a fault happens, the kernel traps it and emulates the results of these instructions with dummy values. The purpose of this new test is to verify whether the impacted instructions can be executed without causing such #GP. If no #GP exceptions occur, we expect to exit virtual-8086 mode from INT3.
The instructions protected by UMIP are executed in representative use cases:
a) displacement-only memory addressing
b) register-indirect memory addressing
c) results stored directly in operands
Unfortunately, it is not possible to check the results against a set of expected values because no emulation will occur in systems that do not have the UMIP feature. Instead, results are printed for verification. A simple verification is done to ensure that results of all tests are identical.
--- tools/testing/selftests/x86/entry_from_vm86.c | 73 +++++++++++++++++++++++++- 1 file changed, 72 insertions(+), 1 deletion(-)
tools/testing/selftests/x86/entry_from_vm86.c +72 -1
@@ -95,6 +95,22 @@ asm ("int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" +"vmcode_umip:\n\t" +/* addressing via displacements */ +"smsw (2052)\n\t" +"sidt (2054)\n\t" +"sgdt (2060)\n\t" +/* addressing via registers */ +"mov $2066, %bx\n\t" +"smsw (%bx)\n\t" +"mov $2068, %bx\n\t" +"sidt (%bx)\n\t" +"mov $2074, %bx\n\t" +"sgdt (%bx)\n\t" +/* register operands, only for smsw */ +"smsw %ax\n\t" +"mov %ax, (2080)\n\t" +"int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t"
@@ -103,7 +119,7 @@ asm (extern unsigned char vmcode[], end_vmcode[];extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[];/* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -160,6 +176,58 @@ static bool do_test(struct vm86plus_strureturn true; } +void do_umip_tests (struct vm86plus_struct *vm86,unsigned char *test_mem) +{ +struct table_desc { +unsigned short limit; +unsigned long base; + } __attribute__((packed)); + +/* Initialize variables with arbitrary values */ +struct table_desc gdt1 = { .base =0x3c3c3c3c , .limit =0x9999 }; +struct table_desc gdt2 = { .base =0x1a1a1a1a , .limit =0xaeae }; +struct table_desc idt1 = { .base =0x7b7b7b7b , .limit =0xf1f1 }; +struct table_desc idt2 = { .base =0x89898989 , .limit =0x1313 }; +unsigned short msw1 =0x1414 , msw2 =0x2525 , msw3 =3737 ; + +/* UMIP -- exit with INT3 unless kernel emulation did not trap #GP */ +do_test (vm86, vmcode_umip - vmcode,VM86_TRAP ,3 ,"UMIP tests" ); + +/* Results from displacement-only addressing */ + msw1 = *(unsigned short *)(test_mem +2052 ); +memcpy (&idt1, test_mem +2054 ,sizeof (idt1)); +memcpy (&gdt1, test_mem +2060 ,sizeof (gdt1)); + +/* Results from register-indirect addressing */ + msw2 = *(unsigned short *)(test_mem +2066 ); +memcpy (&idt2, test_mem +2068 ,sizeof (idt2)); +memcpy (&gdt2, test_mem +2074 ,sizeof (gdt2)); + +/* Results when using register operands */ + msw3 = *(unsigned short *)(test_mem +2080 ); + +printf ("[INFO]\tResult from SMSW:[0x%04x]\n" , msw1); +printf ("[INFO]\tResult from SIDT: limit[0x%04x]base[0x%08lx]\n" , + idt1.limit, idt1.base); +printf ("[INFO]\tResult from SGDT: limit[0x%04x]base[0x%08lx]\n" , + gdt1.limit, gdt1.base); + +if (msw1 != msw2 || msw1 != msw3) +printf ("[FAIL]\tAll the results of SMSW should be the same.\n" ); +else +printf ("[PASS]\tAll the results from SMSW are identical.\n" ); + +if (memcmp (&gdt1, &gdt2,sizeof (gdt1))) +printf ("[FAIL]\tAll the results of SGDT should be the same.\n" ); +else +printf ("[PASS]\tAll the results from SGDT are identical.\n" ); + +if (memcmp (&idt1, &idt2,sizeof (idt1))) +printf ("[FAIL]\tAll the results of SIDT should be the same.\n" ); +else +printf ("[PASS]\tAll the results from SIDT are identical.\n" ); +} +int main (void ) {struct vm86plus_struct v86;
@@ -218,6 +286,9 @@ int main(void) v86.regs.eax = (unsigned int )-1 ;do_test (&v86, vmcode_int80 - vmcode, VM86_INTx,0x80 ,"int80" ); +/* UMIP -- should exit with INTx 0x80 unless UMIP was not disabled */ +do_umip_tests (&v86, addr); +/* Execute a null pointer */ v86.regs.cs =0 ; v86.regs.ss =0 ;
Greg Kroah-Hartman
maintainerPATCH 215/241 selftests/x86: Add tests for the STR and SLDT instructions
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricardo Neri <[email protected]>
commit a9e017d5619eb371460c8e516f4684def62bef3a upstream.
The STR and SLDT instructions are not valid when running on virtual-8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions generate a general protection fault if called from CPL > 0. Linux traps the general protection fault and emulates the instructions sgdt, sidt and smsw; but not str and sldt.
These tests are added to verify that the emulation code does not emulate these two instructions but the expected invalid operand exception is seen.
Tests fallback to exit with INT3 in case emulation does happen.
--- tools/testing/selftests/x86/entry_from_vm86.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-)
tools/testing/selftests/x86/entry_from_vm86.c +17 -1
@@ -111,6 +111,11 @@ asm ("smsw %ax\n\t" "mov %ax, (2080)\n\t" "int3\n\t" +"vmcode_umip_str:\n\t" +"str %eax\n\t" +"vmcode_umip_sldt:\n\t" +"sldt %eax\n\t" +"int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t"
@@ -119,7 +124,8 @@ asm (extern unsigned char vmcode[], end_vmcode[];extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], + vmcode_umip_str[], vmcode_umip_sldt[];/* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -226,6 +232,16 @@ void do_umip_tests(struct vm86plus_strucprintf ("[FAIL]\tAll the results of SIDT should be the same.\n" ); else printf("[PASS]\tAll the results from SIDT are identical.\n"); + +sethandler (SIGILL , sighandler,0 ); +do_test (vm86, vmcode_umip_str - vmcode,VM86_SIGNAL ,0 , +"STR instruction" ); +clearhandler (SIGILL ); + +sethandler (SIGILL , sighandler,0 ); +do_test (vm86, vmcode_umip_sldt - vmcode,VM86_SIGNAL ,0 , +"SLDT instruction" ); +clearhandler (SIGILL ); }int main (void )
Greg Kroah-Hartman
maintainerPATCH 216/241 selftests/x86/entry_from_vm86: Add test cases for POPF
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream.
POPF is currently broken -- add tests to catch the error. This results in:
[RUN] POPF with VIP set and IF clear from vm86 mode
[INFO] Exited vm86 mode due to STI
[FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf)
because POPF currently fails to check IF before reporting a pending interrupt.
This patch also makes the FAIL message a bit more informative.
--- tools/testing/selftests/x86/entry_from_vm86.c | 30 +++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-)
tools/testing/selftests/x86/entry_from_vm86.c +27 -3
@@ -95,6 +95,10 @@ asm ("int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" +"vmcode_popf_hlt:\n\t" +"push %ax\n\t" +"popf\n\t" +"hlt\n\t" "vmcode_umip:\n\t" /* addressing via displacements */ "smsw (2052)\n\t"
@@ -124,8 +128,8 @@ asm (extern unsigned char vmcode[], end_vmcode[];extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], - vmcode_umip_str[], vmcode_umip_sldt[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[], + vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[];/* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip,
@@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_stru (VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) { printf("[OK]\tReturned correctly\n"); } else { -printf ("[FAIL]\tIncorrect return reason\n" ); +printf ("[FAIL]\tIncorrect return reason (started at eip = 0x%lx, ended at eip = 0x%lx)\n" , eip, v86->regs.eip); nerrs++; }
@@ -264,6 +268,9 @@ int main(void) v86.regs.ds = load_addr /16 ; v86.regs.es = load_addr /16 ; +/* Use the end of the page as our stack. */ + v86.regs.esp =4096 ; +assert ((v86.regs.cs &3 ) ==0 );/* Looks like RPL = 0 */ /* #BR -- should deliver SIG??? */
@@ -295,6 +302,23 @@ int main(void) v86.regs.eflags &= ~X86_EFLAGS_IF ;do_test (&v86, vmcode_sti - vmcode,VM86_STI ,0 ,"STI with VIP set" ); +/* POPF with VIP set but IF clear: should not trap */ + v86.regs.eflags =X86_EFLAGS_VIP ; + v86.regs.eax =0 ; +do_test (&v86, vmcode_popf_hlt - vmcode,VM86_UNKNOWN ,0 ,"POPF with VIP set and IF clear" ); + +/* POPF with VIP set and IF set: should trap */ + v86.regs.eflags =X86_EFLAGS_VIP ; + v86.regs.eax =X86_EFLAGS_IF ; +do_test (&v86, vmcode_popf_hlt - vmcode,VM86_STI ,0 ,"POPF with VIP and IF set" ); + +/* POPF with VIP clear and IF set: should not trap */ + v86.regs.eflags =0 ; + v86.regs.eax =X86_EFLAGS_IF ; +do_test (&v86, vmcode_popf_hlt - vmcode,VM86_UNKNOWN ,0 ,"POPF with VIP clear and IF set" ); + + v86.regs.eflags =0 ; +/* INT3 -- should cause #BP */ do_test (&v86, vmcode_int3 - vmcode,VM86_TRAP ,3 ,"INT3" );
Greg Kroah-Hartman
maintainerPATCH 217/241 x86/vm86/32: Fix POPF emulation
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream.
POPF would trap if VIP was set regardless of whether IF was set. Fix it.
--- arch/x86/kernel/vm86_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/kernel/vm86_32.c +2 -1
@@ -719,7 +719,8 @@ void handle_vm86_fault(struct kernel_vm8return ; check_vip: -if (VEFLAGS &X86_EFLAGS_VIP ) { +if ((VEFLAGS & (X86_EFLAGS_VIP |X86_EFLAGS_VIF )) == + (X86_EFLAGS_VIP |X86_EFLAGS_VIF )) {save_v86_state (regs,VM86_STI );return ; }
Greg Kroah-Hartman
maintainerPATCH 218/241 x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Whitcroft <[email protected]>
commit a14bff131108faf50cc0cf864589fd71ee216c96 upstream.
In the following commit:
9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool")
... we added annotations for CALL_NOSPEC/JMP_NOSPEC on 64-bit x86 kernels, but we did not annotate the 32-bit path.
Annotate it similarly.
--- arch/x86/include/asm/nospec-branch.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
arch/x86/include/asm/nospec-branch.h +4 -1
@@ -183,7 +183,10 @@* otherwise we'll run out of registers. We don't care about CET * here, anyway. */ -# define CALL_NOSPEC ALTERNATIVE("call *%[thunk_target]\n", \ +# define CALL_NOSPEC \ + ALTERNATIVE( \ + ANNOTATE_RETPOLINE_SAFE \ + "call *%[thunk_target]\n", \ " jmp 904f;\n" \ " .align 16\n" \ "901: call 903f;\n" \
Greg Kroah-Hartman
maintainerPATCH 219/241 x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Sergeyev <[email protected]>
commit e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 upstream.
In accordance with Intel's microcode revision guidance from March 6 MCU rev 0xc2 is cleared on both Skylake H/S and Skylake Xeon E3 processors that share CPUID 506E3.
--- arch/x86/kernel/cpu/intel.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
arch/x86/kernel/cpu/intel.c +1 -2
@@ -64,7 +64,7 @@ void check_mpx_erratum(struct cpuinfo_x8/* * Early microcode releases for the Spectre v2 mitigation were broken. * Information taken from; -* - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf +* - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-update-guidance.pdf * - https://kb.vmware.com/s/article/52345 * - Microcode revisions observed in the wild * - Release note from 20180108 microcode release
@@ -82,7 +82,6 @@ static const struct sku_microcode spectr { INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x80 }, { INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e }, { INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003c }, - { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0xc2 }, { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 }, { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b }, { INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 },
Greg Kroah-Hartman
maintainerPATCH 220/241 x86/mm: Fix vmalloc_fault to use pXd_large
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Toshi Kani <[email protected]>
commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream.
Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS is not set since the function inadvertently uses pXn_huge(), which always return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS.
Fix vmalloc_fault() to call pXd_large() instead.
--- arch/x86/mm/fault.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/x86/mm/fault.c +3 -3
@@ -343,7 +343,7 @@ static noinline int vmalloc_fault(unsignif (!pmd_k)return -1 ; -if (pmd_huge (*pmd_k)) +if (pmd_large (*pmd_k))return 0 ; pte_k =pte_offset_kernel (pmd_k, address);
@@ -463,7 +463,7 @@ static noinline int vmalloc_fault(unsignif (pud_none (*pud) ||pud_pfn (*pud) !=pud_pfn (*pud_ref))BUG (); -if (pud_huge (*pud)) +if (pud_large (*pud))return 0 ; pmd =pmd_offset (pud, address);
@@ -474,7 +474,7 @@ static noinline int vmalloc_fault(unsignif (pmd_none (*pmd) ||pmd_pfn (*pmd) !=pmd_pfn (*pmd_ref))BUG (); -if (pmd_huge (*pmd)) +if (pmd_large (*pmd))return 0 ; pte_ref =pte_offset_kernel (pmd_ref, address);
Greg Kroah-Hartman
maintainerPATCH 221/241 parisc: Handle case where flush_cache_range is called with no context
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: John David Anglin <[email protected]>
commit 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 upstream.
Just when I had decided that flush_cache_range() was always called with a valid context, Helge reported two cases where the "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd:
kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587!
CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1 Workqueue: events free_ioctx IAOQ[0]: flush_cache_range+0x164/0x168 IAOQ[1]: flush_cache_page+0x0/0x1c8 RP(r2): unmap_page_range+0xae8/0xb88 Backtrace: [<00000000404a6980>] unmap_page_range+0xae8/0xb88 [<00000000404a6ae0>] unmap_single_vma+0xc0/0x188 [<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8 [<00000000404a702c>] unmap_mapping_range+0x1cc/0x208 [<0000000040461518>] truncate_pagecache+0x98/0x108 [<0000000040461624>] truncate_setsize+0x9c/0xb8 [<00000000405d7f30>] put_aio_ring_file+0x80/0x100 [<00000000405d803c>] aio_free_ring+0x8c/0x290 [<00000000405d82c0>] free_ioctx+0x80/0x180 [<0000000040284e6c>] process_one_work+0x21c/0x668 [<00000000402854c4>] worker_thread+0x20c/0x778 [<0000000040291d44>] kthread+0x2d4/0x2e0 [<0000000040204020>] end_fault_vector+0x20/0xc0
This indicates that we need to handle the no context case in flush_cache_range() as we do in flush_cache_mm().
In thinking about this, I realized that we don't need to flush the TLB when there is no context. So, I added context checks to the large flush cases in flush_cache_mm() and flush_cache_range(). The large flush case occurs frequently in flush_cache_mm() and the change should improve fork performance.
The v2 version of this change removes the BUG_ON from flush_cache_page() by skipping the TLB flush when there is no context. I also added code to flush the TLB in flush_cache_mm() and flush_cache_range() when we have a context that's not current. Now all three routines handle TLB flushes in a similar manner.
--- arch/parisc/kernel/cache.c | 41 ++++++++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 9 deletions(-)
arch/parisc/kernel/cache.c +32 -9
@@ -542,7 +542,8 @@ void flush_cache_mm(struct mm_struct *mmrp3440, etc. So, avoid it if the mm isn't too big. */ if ((!IS_ENABLED (CONFIG_SMP ) || !arch_irqs_disabled ()) &&mm_total_size (mm) >= parisc_cache_flush_threshold) { -flush_tlb_all (); +if (mm->context) +flush_tlb_all ();flush_cache_all ();return ; }
@@ -570,6 +571,8 @@ void flush_cache_mm(struct mm_struct *mm pfn =pte_pfn (*ptep);if (!pfn_valid (pfn))continue ; +if (unlikely (mm->context)) +flush_tlb_page (vma, addr);__flush_cache_page (vma, addr,PFN_PHYS (pfn)); } }
@@ -596,26 +599,46 @@ flush_user_icache_range(unsigned long stvoid flush_cache_range (struct vm_area_struct *vma,unsigned long start,unsigned long end) { +pgd_t *pgd; +unsigned long addr; +if ((!IS_ENABLED (CONFIG_SMP ) || !arch_irqs_disabled ()) && end - start >= parisc_cache_flush_threshold) { -flush_tlb_range (vma, start, end); +if (vma->vm_mm->context) +flush_tlb_range (vma, start, end);flush_cache_all ();return ; } -flush_user_dcache_range_asm (start, end); -if (vma->vm_flags &VM_EXEC ) -flush_user_icache_range_asm (start, end); -flush_tlb_range (vma, start, end); +if (vma->vm_mm->context ==mfsp (3 )) { +flush_user_dcache_range_asm (start, end); +if (vma->vm_flags &VM_EXEC ) +flush_user_icache_range_asm (start, end); +flush_tlb_range (vma, start, end); +return ; + } + + pgd = vma->vm_mm->pgd; +for (addr = vma->vm_start; addr < vma->vm_end; addr +=PAGE_SIZE ) { +unsigned long pfn; +pte_t *ptep =get_ptep (pgd, addr); +if (!ptep) +continue ; + pfn =pte_pfn (*ptep); +if (pfn_valid (pfn)) { +if (unlikely (vma->vm_mm->context)) +flush_tlb_page (vma, addr); +__flush_cache_page (vma, addr,PFN_PHYS (pfn)); + } + } }void flush_cache_page (struct vm_area_struct *vma,unsigned long vmaddr,unsigned long pfn) { -BUG_ON (!vma->vm_mm->context); -if (pfn_valid (pfn)) { -flush_tlb_page (vma, vmaddr); +if (likely (vma->vm_mm->context)) +flush_tlb_page (vma, vmaddr);__flush_cache_page (vma, vmaddr,PFN_PHYS (pfn)); } }
Greg Kroah-Hartman
maintainerPATCH 222/241 ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 01c0b4265cc16bc1f43f475c5944c55c10d5768f upstream.
snd_pcm_oss_get_formats() has an obvious use-after-free around snd_mask_test() calls, as spotted by syzbot. The passed format_mask argument is a pointer to the hw_params object that is freed before the loop. What a surprise that it has been present since the original code of decades ago...
--- sound/core/oss/pcm_oss.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
sound/core/oss/pcm_oss.c +6 -4
@@ -1814,10 +1814,9 @@ static int snd_pcm_oss_get_formats(strucreturn -ENOMEM ;_snd_pcm_hw_params_any (params); err =snd_pcm_hw_refine (substream, params); - format_mask = *hw_param_mask (params,SNDRV_PCM_HW_PARAM_FORMAT ); -kfree (params);if (err <0 ) -return err; + goto error; + format_mask = *hw_param_mask (params,SNDRV_PCM_HW_PARAM_FORMAT );for (fmt =0 ; fmt <32 ; ++fmt) {if (snd_mask_test (&format_mask, fmt)) {int f =snd_pcm_oss_format_to (fmt);
@@ -1825,7 +1824,10 @@ static int snd_pcm_oss_get_formats(struc formats |= f; } } -return formats; + + error: +kfree (params); +return err <0 ? err : formats; }static int snd_pcm_oss_set_format (struct snd_pcm_oss_file *pcm_oss_file,int format)
Greg Kroah-Hartman
maintainerPATCH 223/241 ALSA: hda - Revert power_save option default value
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 40088dc4e1ead7df31728c73f5b51d71da18831d upstream.
With the commit 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist"), we changed the default value of power_save option to -1 for processing the power-save blacklist.
Unfortunately, this seems breaking user-space applications that actually read the power_save parameter value via sysfs and judge / adjust the power-saving status. They see the value -1 as if the power-save is turned off, although the actual value is taken from CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive.
So, overall, passing -1 there was no good idea. Let's partially revert it -- at least for power_save option default value is restored again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT. Meanwhile, in this patch, we keep the blacklist behavior and make is adjustable via the new option, pm_blacklist.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
--- sound/pci/hda/hda_intel.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
sound/pci/hda/hda_intel.c +6 -3
@@ -180,11 +180,15 @@ static const struct kernel_param_ops par };#define param_check_xint param_check_int -static int power_save =-1 ; +static int power_save =CONFIG_SND_HDA_POWER_SAVE_DEFAULT ;module_param (power_save, xint,0644 );MODULE_PARM_DESC (power_save,"Automatic power-saving timeout " "(in second, 0 = disable)." ); +static bool pm_blacklist = true; +module_param (pm_blacklist, bool,0644 ); +MODULE_PARM_DESC (pm_blacklist,"Enable power-management blacklist" ); +/* reset the HD-audio controller in power save mode. * this may give more power-saving, but will take longer time to * wake up.
@@ -2153,10 +2157,9 @@ static int azx_probe_continue(struct azx val = power_save;#ifdef CONFIG_PM -if (val ==-1 ) { +if (pm_blacklist) {const struct snd_pci_quirk *q; - val =CONFIG_SND_HDA_POWER_SAVE_DEFAULT ; q =snd_pci_quirk_lookup (chip->pci, power_save_blacklist);if (q && val) { dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n",
Greg Kroah-Hartman
maintainerPATCH 224/241 ALSA: seq: Fix possible UAF in snd_seq_check_queue()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit d0f833065221cbfcbadf19fd4102bcfa9330006a upstream.
Although we've covered the races between concurrent write() and ioctl() in the previous patch series, there is still a possible UAF in the following scenario:
A: user client closed B: timer irq
-> snd_seq_release() -> snd_seq_timer_interrupt()
-> snd_seq_free_client() -> snd_seq_check_queue()
-> cell = snd_seq_prioq_cell_peek()
-> snd_seq_prioq_leave()
.... removing all cells
-> snd_seq_pool_done()
.... vfree()
-> snd_seq_compare_tick_time(cell)
... OopsSo the problem is that a cell is peeked and accessed without any protection until it's retrieved from the queue again via snd_seq_prioq_cell_out().
This patch tries to address it, also cleans up the code by a slight refactoring. snd_seq_prioq_cell_out() now receives an extra pointer argument. When it's non-NULL, the function checks the event timestamp with the given pointer. The caller needs to pass the right reference either to snd_seq_tick or snd_seq_realtime depending on the event timestamp type.
A good news is that the above change allows us to remove the snd_seq_prioq_cell_peek(), too, thus the patch actually reduces the code size.
--- sound/core/seq/seq_prioq.c | 28 ++++++++++++++-------------- sound/core/seq/seq_prioq.h | 6 ++---- sound/core/seq/seq_queue.c | 28 +++++++++------------------- 3 files changed, 25 insertions(+), 37 deletions(-)
sound/core/seq/seq_prioq.c +14 -14
@@ -87,7 +87,7 @@ void snd_seq_prioq_delete(struct snd_seqif (f->cells >0 ) {/* drain prioQ */ while (f->cells >0 ) -snd_seq_cell_free (snd_seq_prioq_cell_out (f)); +snd_seq_cell_free (snd_seq_prioq_cell_out (f,NULL )); }kfree (f);
@@ -214,8 +214,18 @@ int snd_seq_prioq_cell_in(struct snd_seqreturn 0 ; } +/* return 1 if the current time >= event timestamp */ +static int event_is_ready (struct snd_seq_event *ev,void *current_time) +{ +if ((ev->flags &SNDRV_SEQ_TIME_STAMP_MASK ) ==SNDRV_SEQ_TIME_STAMP_TICK ) +return snd_seq_compare_tick_time (current_time, &ev->time.tick); +else +return snd_seq_compare_real_time (current_time, &ev->time.time); +} +/* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out (struct snd_seq_prioq *f) +struct snd_seq_event_cell *snd_seq_prioq_cell_out (struct snd_seq_prioq *f, +void *current_time) {struct snd_seq_event_cell *cell;unsigned long flags;
@@ -227,6 +237,8 @@ struct snd_seq_event_cell *snd_seq_prioqspin_lock_irqsave (&f->lock, flags); cell = f->head; +if (cell && current_time && !event_is_ready (&cell->event, current_time)) + cell =NULL ;if (cell) { f->head = cell->next;
@@ -252,18 +264,6 @@ int snd_seq_prioq_avail(struct snd_seq_preturn f->cells; } - -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek (struct snd_seq_prioq * f) -{ -if (f ==NULL ) { -pr_debug ("ALSA: seq: snd_seq_prioq_cell_in() called with NULL prioq\n" ); -return NULL ; - } -return f->head; -} - -static inline int prioq_match (struct snd_seq_event_cell *cell,int client,int timestamp) {
sound/core/seq/seq_prioq.h +2 -4
@@ -44,14 +44,12 @@ void snd_seq_prioq_delete(struct snd_seqint snd_seq_prioq_cell_in (struct snd_seq_prioq *f,struct snd_seq_event_cell *cell);/* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out (struct snd_seq_prioq *f); +struct snd_seq_event_cell *snd_seq_prioq_cell_out (struct snd_seq_prioq *f, +void *current_time);/* return number of events available in prioq */ int snd_seq_prioq_avail (struct snd_seq_prioq *f); -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek (struct snd_seq_prioq *f); -/* client left queue */ void snd_seq_prioq_leave (struct snd_seq_prioq *f,int client,int timestamp);
sound/core/seq/seq_queue.c +9 -19
@@ -277,30 +277,20 @@ void snd_seq_check_queue(struct snd_seq_ __again:/* Process tick queue... */ -while ((cell =snd_seq_prioq_cell_peek (q->tickq)) !=NULL ) { -if (snd_seq_compare_tick_time (&q->timer->tick.cur_tick, - &cell->event.time.tick)) { - cell =snd_seq_prioq_cell_out (q->tickq); -if (cell) -snd_seq_dispatch_event (cell, atomic, hop); - }else { -/* event remains in the queue */ +for (;;) { + cell =snd_seq_prioq_cell_out (q->tickq, + &q->timer->tick.cur_tick); +if (!cell)break ; - } +snd_seq_dispatch_event (cell, atomic, hop); } -/* Process time queue... */ -while ((cell =snd_seq_prioq_cell_peek (q->timeq)) !=NULL ) { -if (snd_seq_compare_real_time (&q->timer->cur_time, - &cell->event.time.time)) { - cell =snd_seq_prioq_cell_out (q->timeq); -if (cell) -snd_seq_dispatch_event (cell, atomic, hop); - }else { -/* event remains in the queue */ +for (;;) { + cell =snd_seq_prioq_cell_out (q->timeq, &q->timer->cur_time); +if (!cell)break ; - } +snd_seq_dispatch_event (cell, atomic, hop); }/* free lock */
Greg Kroah-Hartman
maintainerPATCH 225/241 ALSA: seq: Clear client entry before deleting else at closing
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit a2ff19f7b70118ced291a28d5313469914de451b upstream.
When releasing a client, we need to clear the clienttab[] entry at first, then call snd_seq_queue_client_leave(). Otherwise, the in-flight cell in the queue might be picked up by the timer interrupt via snd_seq_check_queue() before calling snd_seq_queue_client_leave(), and it's delivered to another queue while the client is clearing queues. This may eventually result in an uncleared cell remaining in a queue, and the later snd_seq_pool_delete() may need to wait for a long time until the event gets really processed.
By moving the clienttab[] clearance at the beginning of release, any event delivery of a cell belonging to this client will fail at a later point, since snd_seq_client_ptr() returns NULL. Thus the cell that was picked up by the timer interrupt will be returned immediately without further delivery, and the long stall of snd_seq_delete_pool() can be avoided, too.
--- sound/core/seq/seq_clientmgr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/core/seq/seq_clientmgr.c +2 -2
@@ -255,12 +255,12 @@ static int seq_free_client1(struct snd_sif (!client)return 0 ; -snd_seq_delete_all_ports (client); -snd_seq_queue_client_leave (client->number);spin_lock_irqsave (&clients_lock, flags); clienttablock[client->number] =1 ; clienttab[client->number] =NULL ;spin_unlock_irqrestore (&clients_lock, flags); +snd_seq_delete_all_ports (client); +snd_seq_queue_client_leave (client->number);snd_use_lock_sync (&client->use_lock);snd_seq_queue_client_termination (client->number);if (client->pool)
Greg Kroah-Hartman
maintainerPATCH 226/241 drm/amdgpu: fix prime teardown order
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian König <[email protected]>
commit 342038d92403b3efa1138a8599666b9f026279d6 upstream.
We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +0 -2
@@ -36,8 +36,6 @@ void amdgpu_gem_object_free(struct drm_gstruct amdgpu_bo *robj =gem_to_amdgpu_bo (gobj);if (robj) { -if (robj->gem_base.import_attach) -drm_prime_gem_destroy (&robj->gem_base, robj->tbo.sg);amdgpu_mn_unregister (robj);amdgpu_bo_unref (&robj); }
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +2 -0
@@ -94,6 +94,8 @@ static void amdgpu_ttm_bo_destroy(structamdgpu_update_memory_usage (bo->adev, &bo->tbo.mem,NULL ); +if (bo->gem_base.import_attach) +drm_prime_gem_destroy (&bo->gem_base, bo->tbo.sg);drm_gem_object_release (&bo->gem_base);amdgpu_bo_unref (&bo->parent);if (!list_empty (&bo->shadow_list)) {
Greg Kroah-Hartman
maintainerPATCH 227/241 drm/amdgpu/dce: Dont turn off DP sink when disconnected
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michel Dänzer <[email protected]>
commit 7d617264eb22b18d979eac6e85877a141253034e upstream.
Turning off the sink in this case causes various issues, because userspace expects it to stay on until it turns it off explicitly.
Instead, turn the sink off and back on when a display is connected again. This dance seems necessary for link training to work correctly.
Bugzilla: https://bugs.freedesktop.org/105308
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 29 +++++++++---------------- 1 file changed, 11 insertions(+), 18 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +11 -18
@@ -69,25 +69,18 @@ void amdgpu_connector_hotplug(struct drm/* don't do anything if sink is not display port, i.e., * passive dp->(dvi|hdmi) adaptor */ -if (dig_connector->dp_sink_type ==CONNECTOR_OBJECT_ID_DISPLAYPORT ) { -int saved_dpms = connector->dpms; -/* Only turn off the display if it's physically disconnected */ -if (!amdgpu_display_hpd_sense (adev, amdgpu_connector->hpd.hpd)) { -drm_helper_connector_dpms (connector,DRM_MODE_DPMS_OFF ); - }else if (amdgpu_atombios_dp_needs_link_train (amdgpu_connector)) { -/* Don't try to start link training before we -* have the dpcd */ -if (amdgpu_atombios_dp_get_dpcd (amdgpu_connector)) -return ; +if (dig_connector->dp_sink_type ==CONNECTOR_OBJECT_ID_DISPLAYPORT && +amdgpu_display_hpd_sense (adev, amdgpu_connector->hpd.hpd) && +amdgpu_atombios_dp_needs_link_train (amdgpu_connector)) { +/* Don't start link training before we have the DPCD */ +if (amdgpu_atombios_dp_get_dpcd (amdgpu_connector)) +return ; -/* set it to OFF so that drm_helper_connector_dpms() -* won't return immediately since the current state -* is ON at this point. -*/ - connector->dpms =DRM_MODE_DPMS_OFF ; -drm_helper_connector_dpms (connector,DRM_MODE_DPMS_ON ); - } - connector->dpms = saved_dpms; +/* Turn the connector off and back on immediately, which +* will trigger link training +*/ +drm_helper_connector_dpms (connector,DRM_MODE_DPMS_OFF ); +drm_helper_connector_dpms (connector,DRM_MODE_DPMS_ON ); } } }
Greg Kroah-Hartman
maintainerPATCH 228/241 fs: Teach path_connected to handle nfs filesystems with multiple roots.
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman <[email protected]>
commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream.
On nfsv2 and nfsv3 the nfs server can export subsets of the same filesystem and report the same filesystem identifier, so that the nfs client can know they are the same filesystem. The subsets can be from disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no way to find the common root of all directory trees exported form the server with the same filesystem identifier.
The practical result is that in struct super s_root for nfs s_root is not necessarily the root of the filesystem. The nfs mount code sets s_root to the root of the first subset of the nfs filesystem that the kernel mounts.
This effects the dcache invalidation code in generic_shutdown_super currently called shrunk_dcache_for_umount and that code for years has gone through an additional list of dentries that might be dentry trees that need to be freed to accomodate nfs.
When I wrote path_connected I did not realize nfs was so special, and it's hueristic for avoiding calling is_subdir can fail.
The practical case where this fails is when there is a move of a directory from the subtree exposed by one nfs mount to the subtree exposed by another nfs mount. This move can happen either locally or remotely. With the remote case requiring that the move directory be cached before the move and that after the move someone walks the path to where the move directory now exists and in so doing causes the already cached directory to be moved in the dcache through the magic of d_splice_alias.
If someone whose working directory is in the move directory or a subdirectory and now starts calling .. from the initial mount of nfs (where s_root == mnt_root), then path_connected as a heuristic will not bother with the is_subdir check. As s_root really is not the root of the nfs filesystem this heuristic is wrong, and the path may actually not be connected and path_connected can fail.
The is_subdir function might be cheap enough that we can call it unconditionally. Verifying that will take some benchmarking and the result may not be the same on all kernels this fix needs to be backported to. So I am avoiding that for now.
Filesystems with snapshots such as nilfs and btrfs do something similar. But as the directory tree of the snapshots are disjoint from one another and from the main directory tree rename won't move things between them and this problem will not occur.
--- fs/namei.c | 5 +++-- fs/nfs/super.c | 2 ++ include/linux/fs.h | 1 + 3 files changed, 6 insertions(+), 2 deletions(-)
fs/namei.c +3 -2
@@ -578,9 +578,10 @@ static int __nd_alloc_stack(struct nameistatic bool path_connected (const struct path *path) {struct vfsmount *mnt = path->mnt; +struct super_block *sb = mnt->mnt_sb; -/* Only bind mounts can have disconnected paths */ -if (mnt->mnt_root == mnt->mnt_sb->s_root) +/* Bind mounts and multi-root filesystems can have disconnected paths */ +if (!(sb->s_iflags &SB_I_MULTIROOT ) && (mnt->mnt_root == sb->s_root))return true;return is_subdir (path->dentry, mnt->mnt_root);
fs/nfs/super.c +2 -0
@@ -2613,6 +2613,8 @@ struct dentry *nfs_fs_mount_common(struc/* initial superblock/root creation */ mount_info->fill_super (s, mount_info);nfs_get_cache_cookie (s, mount_info->parsed, mount_info->cloned); +if (!(server->flags &NFS_MOUNT_UNSHARED )) + s->s_iflags |=SB_I_MULTIROOT ; } mntroot =nfs_get_root (s, mount_info->mntfh, dev_name);
include/linux/fs.h +1 -0
@@ -1319,6 +1319,7 @@ struct mm_struct;#define SB_I_CGROUPWB 0x00000001/* cgroup-aware writeback enabled */ #define SB_I_NOEXEC 0x00000002/* Ignore executables on this fs */ #define SB_I_NODEV 0x00000004/* Ignore devices on this fs */ +#define SB_I_MULTIROOT 0x00000008/* Multiple roots to the dentry tree */ /* sb->s_iflags to limit user namespace mounts */ #define SB_I_USERNS_VISIBLE 0x00000010/* fstype already mounted */
Greg Kroah-Hartman
maintainerPATCH 229/241 lock_parent() needs to recheck if dentry got __dentry_killed under it
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 3b821409632ab778d46e807516b457dfa72736ed upstream.
In case when dentry passed to lock_parent() is protected from freeing only by the fact that it's on a shrink list and trylock of parent fails, we could get hit by __dentry_kill() (and subsequent dentry_kill(parent)) between unlocking dentry and locking presumed parent. We need to recheck that dentry is alive once we lock both it and parent *and* postpone rcu_read_unlock() until after that point. Otherwise we could return a pointer to struct dentry that already is rcu-scheduled for freeing, with ->d_lock held on it; caller's subsequent attempt to unlock it can end up with memory corruption.
--- fs/dcache.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
fs/dcache.c +8 -3
@@ -637,11 +637,16 @@ again:spin_unlock (&parent->d_lock); goto again; } -rcu_read_unlock (); -if (parent != dentry) +if (parent != dentry) {spin_lock_nested (&dentry->d_lock,DENTRY_D_LOCK_NESTED ); -else +if (unlikely (dentry->d_lockref.count <0 )) { +spin_unlock (&parent->d_lock); + parent =NULL ; + } + }else { parent =NULL ; + } +rcu_read_unlock ();return parent; }
Greg Kroah-Hartman
maintainerPATCH 230/241 fs/aio: Add explicit RCU grace period when freeing kioctx
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit a6d7cff472eea87d96899a20fa718d2bab7109f3 upstream.
While fixing refcounting, e34ecee2ae79 ("aio: Fix a trinity splat") incorrectly removed explicit RCU grace period before freeing kioctx. The intention seems to be depending on the internal RCU grace periods of percpu_ref; however, percpu_ref uses a different flavor of RCU, sched-RCU. This can lead to kioctx being freed while RCU read protected dereferences are still in progress.
Fix it by updating free_ioctx() to go through call_rcu() explicitly.
v2: Comment added to explain double bouncing.
--- fs/aio.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
fs/aio.c +19 -4
@@ -115,7 +115,8 @@ struct kioctx {struct page **ring_pages;long nr_pages; -struct work_struct free_work; +struct rcu_head free_rcu; +struct work_struct free_work;/* see free_ioctx() */ /* * signals when all in-flight requests are done
@@ -581,6 +582,12 @@ static int kiocb_cancel(struct aio_kiocbreturn cancel (&kiocb->common); } +/* +* free_ioctx() should be RCU delayed to synchronize against the RCU +* protected lookup_ioctx() and also needs process context to call +* aio_free_ring(), so the double bouncing through kioctx->free_rcu and +* ->free_work. +*/ static void free_ioctx (struct work_struct *work) { struct kioctx *ctx = container_of(work, struct kioctx, free_work);
@@ -594,6 +601,14 @@ static void free_ioctx(struct work_struckmem_cache_free (kioctx_cachep, ctx); } +static void free_ioctx_rcufn (struct rcu_head *head) +{ + struct kioctx *ctx = container_of(head, struct kioctx, free_rcu); + +INIT_WORK (&ctx->free_work, free_ioctx); +schedule_work (&ctx->free_work); +} +static void free_ioctx_reqs (struct percpu_ref *ref) { struct kioctx *ctx = container_of(ref, struct kioctx, reqs);
@@ -602,8 +617,8 @@ static void free_ioctx_reqs(struct percpif (ctx->rq_wait &&atomic_dec_and_test (&ctx->rq_wait->count))complete (&ctx->rq_wait->comp); -INIT_WORK (&ctx->free_work, free_ioctx); -schedule_work (&ctx->free_work); +/* Synchronize against RCU protected table->table[] dereferences */ +call_rcu (&ctx->free_rcu, free_ioctx_rcufn); }/*
@@ -825,7 +840,7 @@ static int kill_ioctx(struct mm_struct * table->table[ctx->id] =NULL ;spin_unlock (&mm->ioctx_lock); -/* percpu_ref_kill() will do the necessary call_rcu() */ +/* free_ioctx_reqs() will do the necessary RCU synchronization */ wake_up_all (&ctx->wait);/*
Greg Kroah-Hartman
maintainerPATCH 231/241 fs/aio: Use RCU accessors for kioctx_table->table[]
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit d0264c01e7587001a8c4608a5d1818dba9a4c11a upstream.
While converting ioctx index from a list to a table, db446a08c23d ("aio: convert the ioctx list to table lookup v3") missed tagging kioctx_table->table[] as an array of RCU pointers and using the appropriate RCU accessors. This introduces a small window in the lookup path where init and access may race.
Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field.
--- fs/aio.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
fs/aio.c +11 -10
@@ -68,9 +68,9 @@ struct aio_ring {#define AIO_RING_PAGES 8struct kioctx_table { -struct rcu_head rcu; -unsigned nr; -struct kioctx *table[]; +struct rcu_head rcu; +unsigned nr; +struct kioctx __rcu *table[]; };struct kioctx_cpu {
@@ -330,7 +330,7 @@ static int aio_ring_mremap(struct vm_arefor (i =0 ; i < table->nr; i++) {struct kioctx *ctx; - ctx = table->table[i]; + ctx =rcu_dereference (table->table[i]);if (ctx && ctx->aio_ring_file == file) {if (!atomic_read (&ctx->dead)) { ctx->user_id = ctx->mmap_base = vma->vm_start;
@@ -659,9 +659,9 @@ static int ioctx_add_table(struct kioctxwhile (1 ) {if (table)for (i =0 ; i < table->nr; i++) -if (!table->table[i]) { +if (!rcu_access_pointer (table->table[i])) { ctx->id = i; - table->table[i] = ctx; +rcu_assign_pointer (table->table[i], ctx);spin_unlock (&mm->ioctx_lock);/* While kioctx setup is in progress,
@@ -836,8 +836,8 @@ static int kill_ioctx(struct mm_struct * } table =rcu_dereference_raw (mm->ioctx_table); -WARN_ON (ctx != table->table[ctx->id]); - table->table[ctx->id] =NULL ; +WARN_ON (ctx !=rcu_access_pointer (table->table[ctx->id])); +RCU_INIT_POINTER (table->table[ctx->id],NULL );spin_unlock (&mm->ioctx_lock);/* free_ioctx_reqs() will do the necessary RCU synchronization */
@@ -882,7 +882,8 @@ void exit_aio(struct mm_struct *mm) skipped =0 ;for (i =0 ; i < table->nr; ++i) { -struct kioctx *ctx = table->table[i]; +struct kioctx *ctx = +rcu_dereference_protected (table->table[i], true);if (!ctx) { skipped++;
@@ -1071,7 +1072,7 @@ static struct kioctx *lookup_ioctx(unsigif (!table || id >= table->nr) goto out; - ctx = table->table[id]; + ctx =rcu_dereference (table->table[id]);if (ctx && ctx->user_id == ctx_id) {percpu_ref_get (&ctx->users); ret = ctx;
Greg Kroah-Hartman
maintainerPATCH 232/241 irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ard Biesheuvel <[email protected]>
commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream.
When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap.
This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional.
For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work.
So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place.
--- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
drivers/irqchip/irq-gic-v3-its.c +4 -5
@@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = {* This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT)static unsigned long *lpi_bitmap;static u32 lpi_chunks;
@@ -1320,11 +1320,10 @@ static struct its_device *its_create_dev dev =kzalloc (sizeof (*dev),GFP_KERNEL );/* -* At least one bit of EventID is being used, hence a minimum -* of two entries. No, the architecture doesn't let you -* express an ITT with a single entry. +* We allocate at least one chunk worth of LPIs bet device, +* and thus that many ITEs. The device may require less though. */ - nr_ites =max (2UL ,roundup_pow_of_two (nvecs)); + nr_ites =max (IRQS_PER_CHUNK ,roundup_pow_of_two (nvecs)); sz = nr_ites * its->ite_size; sz =max (sz,ITS_ITT_ALIGN ) +ITS_ITT_ALIGN -1 ; itt =kzalloc (sz,GFP_KERNEL );
Greg Kroah-Hartman
maintainerPATCH 233/241 scsi: sg: fix SG_DXFER_FROM_DEV transfers
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Thumshirn <[email protected]>
commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream.
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request")
--- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/sg.c +4 -1
@@ -758,8 +758,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_if (hp->dxferp || hp->dxfer_len >0 )return false;return true; -case SG_DXFER_TO_DEV :case SG_DXFER_FROM_DEV : +if (hp->dxfer_len <0 ) +return false; +return true; +case SG_DXFER_TO_DEV :case SG_DXFER_TO_FROM_DEV :if (!hp->dxferp || hp->dxfer_len ==0 )return false;
Greg Kroah-Hartman
maintainerPATCH 234/241 scsi: sg: fix static checker warning in sg_is_valid_dxfer
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Thumshirn <[email protected]>
commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream.
dxfer_len is an unsigned int and we always assign a value > 0 to it, so it doesn't make any sense to check if it is < 0. We can't really check dxferp as well as we have both NULL and not NULL cases in the possible call paths.
So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer().
--- drivers/scsi/sg.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/scsi/sg.c +5 -2
@@ -759,8 +759,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_return false;return true;case SG_DXFER_FROM_DEV : -if (hp->dxfer_len <0 ) -return false; +/* +* for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp +* can either be NULL or != NULL so there's no point in checking +* it either. So just return true. +*/ return true;case SG_DXFER_TO_DEV :case SG_DXFER_TO_FROM_DEV :
Greg Kroah-Hartman
maintainerPATCH 235/241 scsi: sg: only check for dxfer_len greater than 256M
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Thumshirn <[email protected]>
commit f930c7043663188429cd9b254e9d761edfc101ce upstream.
Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M.
--- drivers/scsi/sg.c | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-)
drivers/scsi/sg.c +1 -30
@@ -751,35 +751,6 @@ sg_new_write(Sg_fd *sfp, struct file *fireturn count; } -static bool sg_is_valid_dxfer (sg_io_hdr_t *hp) -{ -switch (hp->dxfer_direction) { -case SG_DXFER_NONE : -if (hp->dxferp || hp->dxfer_len >0 ) -return false; -return true; -case SG_DXFER_FROM_DEV : -/* -* for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp -* can either be NULL or != NULL so there's no point in checking -* it either. So just return true. -*/ -return true; -case SG_DXFER_TO_DEV : -case SG_DXFER_TO_FROM_DEV : -if (!hp->dxferp || hp->dxfer_len ==0 ) -return false; -return true; -case SG_DXFER_UNKNOWN : -if ((!hp->dxferp && hp->dxfer_len) || - (hp->dxferp && hp->dxfer_len ==0 )) -return false; -return true; -default : -return false; - } -} -static int sg_common_write (Sg_fd * sfp,Sg_request * srp,unsigned char *cmnd,int timeout,int blocking)
@@ -800,7 +771,7 @@ sg_common_write(Sg_fd * sfp, Sg_request"sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n" , (int) cmnd[0], (int) hp->cmd_len)); -if (!sg_is_valid_dxfer (hp)) +if (hp->dxfer_len >=SZ_256M )return -EINVAL ; k =sg_start_req (srp, cmnd);
Greg Kroah-Hartman
maintainerPATCH 236/241 btrfs: alloc_chunk: fix DUP stripe size handling
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans van Kranenburg <[email protected]>
commit 92e222df7b8f05c565009c7383321b593eca488b upstream.
In case of using DUP, we search for enough unallocated disk space on a device to hold two stripes.
The devices_info[ndevs-1].max_avail that holds the amount of unallocated space found is directly assigned to stripe_size, while it's actually twice the stripe size.
Later on in the code, an unconditional division of stripe_size by dev_stripes corrects the value, but in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size.
The unconditional division later tries to correct stripe_size, but will actually make sure we can't allocate more than half the max_chunk_size.
Fix this by moving the division by dev_stripes before the max chunk size check, so it always contains the right value, instead of putting a duct tape division in further on to get it fixed again.
Since in all other cases than DUP, dev_stripes is 1, this change only affects DUP.
Other attempts in the past were made to fix this:
* 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried to fix the same problem, but still resulted in part of the code acting on a wrongly doubled stripe_size value.
* 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally broke this fix again.
The real problem was already introduced with the rest of the code in 73c5de0051.
The user visible result however will be that the max chunk size for DUP will suddenly double, while it's actually acting according to the limits in the code again like it was 5 years ago.
--- fs/btrfs/volumes.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
fs/btrfs/volumes.c +6 -5
@@ -4748,10 +4748,13 @@ static int __btrfs_alloc_chunk(struct btif (devs_max && ndevs > devs_max) ndevs = devs_max;/* -* the primary goal is to maximize the number of stripes, so use as many -* devices as possible, even if the stripes are not maximum sized. +* The primary goal is to maximize the number of stripes, so use as +* many devices as possible, even if the stripes are not maximum sized. +* +* The DUP profile stores more than one stripe per device, the +* max_avail is the total size so we have to adjust. */ - stripe_size = devices_info[ndevs-1 ].max_avail; + stripe_size =div_u64 (devices_info[ndevs -1 ].max_avail, dev_stripes); num_stripes = ndevs * dev_stripes;/*
@@ -4791,8 +4794,6 @@ static int __btrfs_alloc_chunk(struct bt stripe_size = devices_info[ndevs-1 ].max_avail; } - stripe_size =div_u64 (stripe_size, dev_stripes); -/* align to BTRFS_STRIPE_LEN */ stripe_size =div_u64 (stripe_size, raid_stripe_len); stripe_size *= raid_stripe_len;
Greg Kroah-Hartman
maintainerPATCH 237/241 btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Borisov <[email protected]>
commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream.
Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then btrfs_free_stale_devices will proceed to also free the btrfs_fs_devices struct itself. Currently this leads to a use after free since list_for_each_entry will try to perform a check on the already freed memory to see if it has to terminate the loop.
The fix is to use 'break' when we know we are freeing the current fs_devs.
--- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+)
fs/btrfs/volumes.c +1 -0
@@ -583,6 +583,7 @@ void btrfs_free_stale_device(struct btrfbtrfs_sysfs_remove_fsid (fs_devs);list_del (&fs_devs->list);free_fs_devices (fs_devs); +break ; }else { fs_devs->num_devices--;list_del (&dev->dev_list);
Greg Kroah-Hartman
maintainerPATCH 238/241 scsi: qla2xxx: Fix extraneous ref on sps after adapter break
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bill Kuzeja <[email protected]>
commit 4cd3b6ebff8510b2139d64024411207090cfe0a9 upstream.
Hung task timeouts can result if a qlogic board breaks unexpectedly while running I/O. These tasks become hung because command srb reference counts are not going to zero, hence the affected srbs and commands do not get freed. This fix accounts for this extra reference in the srbs in the case of a board failure.
--- drivers/scsi/qla2xxx/qla_os.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_os.c +6 -2
@@ -1443,7 +1443,7 @@ qla2x00_loop_reset(scsi_qla_host_t *vha)void qla2x00_abort_all_cmds (scsi_qla_host_t *vha,int res) { -int que, cnt; +int que, cnt, status;unsigned long flags;srb_t *sp;struct qla_hw_data *ha = vha->hw;
@@ -1473,8 +1473,12 @@ qla2x00_abort_all_cmds(scsi_qla_host_t **/ sp_get (sp);spin_unlock_irqrestore (&ha->hardware_lock, flags); -qla2xxx_eh_abort (GET_CMD_SP (sp)); + status =qla2xxx_eh_abort (GET_CMD_SP (sp));spin_lock_irqsave (&ha->hardware_lock, flags); +/* Get rid of extra reference if immediate exit +* from ql2xxx_eh_abort */ +if (status ==FAILED && (qla2x00_isp_reg_stat (ha))) +atomic_dec (&sp->ref_count); } req->outstanding_cmds[cnt] =NULL ; sp->done (vha, sp, res);
Greg Kroah-Hartman
maintainerPATCH 239/241 USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream.
Add the missing platform_device_put() before return from bdc_pci_probe() in the platform_device_add_resources() error handling case.
--- drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/udc/bdc/bdc_pci.c +1 -0
@@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_devif (ret) {dev_err (&pci->dev,"couldn't add resources to bdc device\n" ); +platform_device_put (bdc);return ret; }
Greg Kroah-Hartman
maintainerPATCH 240/241 usb: dwc3: Fix GDBGFIFOSPACE_TYPE values
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thinh Nguyen <[email protected]>
commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream.
The FIFO/Queue type values are incorrect. Correct them according to DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25).
Additionally, this patch includes ProtocolStatusQ and AuxEventQ types.
--- drivers/usb/dwc3/core.h | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
drivers/usb/dwc3/core.h +9 -7
@@ -159,13 +159,15 @@#define DWC3_GDBGFIFOSPACE_TYPE (n) (((n) << 5) & 0x1e0)#define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE (n) (((n) >> 16) & 0xffff) -#define DWC3_TXFIFOQ 1 -#define DWC3_RXFIFOQ 3 -#define DWC3_TXREQQ 5 -#define DWC3_RXREQQ 7 -#define DWC3_RXINFOQ 9 -#define DWC3_DESCFETCHQ 13 -#define DWC3_EVENTQ 15 +#define DWC3_TXFIFOQ 0 +#define DWC3_RXFIFOQ 1 +#define DWC3_TXREQQ 2 +#define DWC3_RXREQQ 3 +#define DWC3_RXINFOQ 4 +#define DWC3_PSTATQ 5 +#define DWC3_DESCFETCHQ 6 +#define DWC3_EVENTQ 7 +#define DWC3_AUXEVENTQ 8/* Global RX Threshold Configuration Register */ #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE (n) (((n) & 0x1f) << 19)
Greg Kroah-Hartman
maintainerPATCH 241/241 usb: gadget: bdc: 64-bit pointer capability check
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinath Mannam <[email protected]>
commit c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 upstream.
Corrected the register to check the 64-bit pointer capability state. 64-bit pointer implementation capability was checking in wrong register, which causes the BDC enumeration failure in 64-bit memory address.
Broadcom USB3.0 device controller IP BDC")
--- drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/bdc/bdc_core.c +1 -1
@@ -475,7 +475,7 @@ static int bdc_probe(struct platform_dev bdc->dev = dev;dev_dbg (bdc->dev,"bdc->regs: %p irq=%d\n" , bdc->regs, bdc->irq); - temp =bdc_readl (bdc->regs,BDC_BDCSC ); + temp =bdc_readl (bdc->regs,BDC_BDCCAP1 );if ((temp &BDC_P64 ) && !dma_set_mask_and_coherent (dev,DMA_BIT_MASK (64 ))) {dev_dbg (bdc->dev,"Using 64-bit address\n" );
stable-rc/linux-4.9.y boot: 35 boots: 0 failed, 30 passed with 4 offline, 1 untried/unknown (v4.9.88-242-g0568177724e0)
stable-rc/linux-4.9.y boot: 35 boots: 0 failed, 30 passed with 4 offline, 1 untried/unknown (v4.9.88-242-g0568177724e0)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.88-242-g0568177724e0/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.88-242-g0568177724e0/
Tree: stable-rc
Branch: linux-4.9.y
Git Describe: v4.9.88-242-g0568177724e0
Git Commit: 0568177724e0610f4592a7e927085b06481e52f4
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 28 unique boards, 8 SoC families, 12 builds out of 183
Offline Platforms:
arm:
davinci_all_defconfig:
dm365evm,legacy: 1 offline lab
exynos_defconfig:
exynos5410-odroidxu: 1 offline lab
exynos5800-peach-pi: 1 offline lab
imx_v6_v7_defconfig:
vf610-colibri-eval-v3: 1 offline lab
---
For more info write to <[email protected]>
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 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.
Quoted 8 lines
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
I needed to revert the following in order to successfully build arm32 and arm64 with default configs:
9b18a27ddaa0 ("ARM: dts: silk: Correct clock of DU1")181e698aaf8c ("ARM: dts: r8a7794: Correct clock of DU1")2bbf316eee1b ("soc/tegra: Fix link errors with PMC disabled")0a576d2dfcc6 ("dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free") 67ee5b1dfe12 ("clk: sunxi-ng: a33: Add offset and minimum value for DDR1 PLL N factor") 9294024e21e3 ("ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss")
I'm not sure the best way to report the specific issues with those, or why there have been so many arm32/64-related build issues lately. Let me know if you want more details.
Dan
Greg Kroah-Hartman
maintainerQuoted 15 lines · Dan Rue
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 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.
Quoted 8 lines
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
Quoted 5 lines
I needed to revert the following in order to successfully build arm32 and arm64 with default configs:
9b18a27ddaa0("ARM: dts: silk: Correct clock of DU1")181e698aaf8c("ARM: dts: r8a7794: Correct clock of DU1")
Should now be fixed.
Quoted 1 line
2bbf316eee1b("soc/tegra: Fix link errors with PMC disabled")
Now dropped, should have not been included, was fixing something from 4.12.
Quoted 1 line
0a576d2dfcc6("dmaengine: bcm2835-dma: Usevchan_terminate_vdesc()instead ofdesc_free")
Dropped, I thought I had deleted it earlier, my fault.
Quoted 1 line
67ee5b1dfe12("clk: sunxi-ng: a33: Add offset and minimum value for DDR1 PLL N factor")
Now dropped.
Quoted 1 line
9294024e21e3("ARM: DRA7:hwmod_data: Preventwait_target_disableerror forusb_otg_ss")
Now dropped.
Quoted 3 lines
I'm not sure the best way to report the specific issues with those, or why there have been so many arm32/64-related build issues lately. Let me know if you want more details.
This way was just fine. I'll go push out a -rc2 for this tree now, many thanks.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 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.
Quoted 8 lines
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
-rc2 is out to fix a bunch of arm32 build errors:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gz
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 UTC 2018. Anything received after that time might be too late.
Quoted 8 lines
Quoted 5 lines
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.-rc2 is out to fix a bunch of arm32 build errors:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gz
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.9.89-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 393003b009f8d3f1254537abee90a28c3e596778
git describe: v4.9.88-239-g393003b009f8
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.88-239-g393003b009f8
No regressions (compared to build v4.9.88-242-g0568177724e0)
Boards, architectures and test suites:
-------------------------------------
dragonboard-410c - arm64
* boot - pass: 20
* kselftest - skip: 27, pass: 36
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 148, pass: 1002
* ltp-timers-tests - skip: 1, pass: 12
hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 24, pass: 39
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 151, pass: 999
* ltp-timers-tests - skip: 1, pass: 12
juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 23, pass: 40
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 149, pass: 1001
* ltp-timers-tests - skip: 1, pass: 12
qemu_x86_64
* boot - pass: 22
* kselftest - skip: 28, pass: 52
* kselftest-vsyscall-mode-native - skip: 28, pass: 52
* kselftest-vsyscall-mode-none - skip: 28, pass: 52
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 148, pass: 1002
* ltp-timers-tests - skip: 1, pass: 12
x15 - arm
* boot - pass: 20
* kselftest - skip: 24, pass: 38
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 97, pass: 1053
* ltp-timers-tests - skip: 1, pass: 12
x86_64
* boot - pass: 22
* kselftest - skip: 25, fail: 1, pass: 54
* kselftest-vsyscall-mode-native - skip: 25, fail: 1, pass: 53
* kselftest-vsyscall-mode-none - skip: 25, fail: 2, pass: 53
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 119, pass: 1030
* ltp-timers-tests - skip: 1, pass: 12
--
Linaro QA (beta)
https://qa-reports.linaro.org
Quoted 5 lines
_______________________________________________
Lkft-triage mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lkft-triage
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
Quoted 5 lines
Quoted 2 lines
-rc2 is out to fix a bunch of arm32 build errors:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gzResults from Linaro’s test farm.
No regressions on arm64, arm andx86_64.
Thanks for testing and letting me know.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 16 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
Review
Quoted 2 lines
(quoted diff) +0
-1-rc2 is out to fix a bunch of arm32 build errors: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gz
And -rc3 is out to fix some more arm32 build errors, as well as an x86 one I noticed showed up in the build tests:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc3.gz
Quoted 16 lines · Greg Kroah-Hartman
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
Quoted 8 lines
Review
Quoted 3 lines
(quoted diff) +0
-1-rc2 is out to fix a bunch of arm32 build errors: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gzAnd -rc3 is out to fix some more arm32 build errors, as well as an x86 one I noticed showed up in the build tests:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc3.gz
For v4.9.88-238-g369cbfd:
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 137 pass: 137 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 26 lines · Guenter Roeck
Quoted 16 lines · Greg Kroah-Hartman
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.Quoted 8 lines
Review
Quoted 3 lines
(quoted diff) +0
-1-rc2 is out to fix a bunch of arm32 build errors: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gzAnd -rc3 is out to fix some more arm32 build errors, as well as an x86 one I noticed showed up in the build tests:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc3.gz
Quoted 6 lines
For v4.9.88-238-g369cbfd:
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 137 pass: 137 fail: 0
Yeah, finally! :)
thanks for the testing, much appreciated.
greg k-h
Quoted 16 lines · Greg Kroah-Hartman
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.
Quoted 7 lines
Quoted 3 lines
-rc2 is out to fix a bunch of arm32 build errors:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gzAnd -rc3 is out to fix some more arm32 build errors, as well as an x86 one I noticed showed up in the build tests:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc3.gz
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.9.89-rc3
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 369cbfd2394b6ea1d767813ffa7fb01f6e5fc68c
git describe: v4.9.88-238-g369cbfd2394b
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.88-238-g369cbfd2394b
No regressions (compared to build v4.9.88-239-g393003b009f8)
Boards, architectures and test suites:
-------------------------------------
dragonboard-410c - arm64
* boot - pass: 20
* kselftest - skip: 27, pass: 36
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 148, pass: 1002
* ltp-timers-tests - skip: 1, pass: 12
hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 24, pass: 39
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 151, pass: 999
* ltp-timers-tests - skip: 1, pass: 12
juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 23, pass: 40
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 4, pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 149, pass: 1001
* ltp-timers-tests - skip: 1, pass: 12
qemu_x86_64
* boot - pass: 22
* kselftest - skip: 28, pass: 52
* kselftest-vsyscall-mode-native - skip: 28, pass: 52
* kselftest-vsyscall-mode-none - skip: 28, pass: 52
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 6, pass: 57
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 149, pass: 1001
* ltp-timers-tests - skip: 1, pass: 12
x15 - arm
* boot - pass: 20
* kselftest - skip: 24, pass: 38
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 2, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 97, pass: 1053
* ltp-timers-tests - skip: 1, pass: 12
x86_64
* boot - pass: 22
* kselftest - skip: 25, fail: 1, pass: 54
* kselftest-vsyscall-mode-native - skip: 25, fail: 1, pass: 54
* kselftest-vsyscall-mode-none - skip: 25, fail: 2, pass: 53
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 17, pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 62
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 5, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 119, pass: 1031
* ltp-timers-tests - skip: 1, pass: 12
--
Linaro QA (beta)
https://qa-reports.linaro.org
Quoted 5 lines
_______________________________________________
Lkft-triage mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lkft-triage
Greg Kroah-Hartman
maintainerQuoted 41 lines · Naresh Kamboju
Quoted 16 lines · Greg Kroah-Hartman
Quoted 15 lines · Greg Kroah-Hartman
Quoted 13 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.Quoted 7 lines
Quoted 3 lines
-rc2 is out to fix a bunch of arm32 build errors:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc2.gzAnd -rc3 is out to fix some more arm32 build errors, as well as an x86 one I noticed showed up in the build tests:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.89-rc3.gzResults from Linaro’s test farm.
No regressions on arm64, arm andx86_64.Summary
------------------------------------------------------------------------kernel: 4.9.89-rc3
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit:369cbfd2394b6ea1d767813ffa7fb01f6e5fc68c
git describe: v4.9.88-238-g369cbfd2394b
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.88-238-g369cbfd2394b
Quoted 1 line
No regressions (compared to build v4.9.88-239-g393003b009f8)
Great, thanks for testing and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 UTC 2018. Anything received after that time might be too late.
For v4.9.88-239-g393003b:
Build results:
total: 145 pass: 143 fail: 2 Failed builds: arm:allmodconfig x86_64:allnoconfig
arm:
sound/soc/sh/rcar/cmd.c: In function 'rsnd_cmd_init':sound/soc/sh/rcar/cmd.c:85:14: warning: array subscript is below array bounds
drivers/net/ethernet/marvell/mvpp2.c: In function 'mvpp2_probe':drivers/net/ethernet/marvell/mvpp2.c:6423:10: error: 'struct mvpp2' has no member named 'hw_version'
drivers/net/ethernet/marvell/mvpp2.c:6423:26: error: 'MVPP22' undeclared
x86_64:
arch/x86/kernel/sys_x86_64.c: In function ‘find_start_end’:arch/x86/kernel/sys_x86_64.c:103:7: error: implicit declaration of function ‘in_compat_syscall’
Guenter
Greg Kroah-Hartman
maintainerQuoted 18 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 UTC 2018. Anything received after that time might be too late.
For v4.9.88-239-g393003b:
Build results:
total: 145 pass: 143 fail: 2 Failed builds: arm:allmodconfig x86_64:allnoconfig
Quoted 4 lines
arm:
sound/soc/sh/rcar/cmd.c: In function 'rsnd_cmd_init':sound/soc/sh/rcar/cmd.c:85:14: warning: array subscript is below array bounds
Oops, missed this one for -rc3, let me go dig...
greg k-h
Greg Kroah-Hartman
maintainerQuoted 19 lines · Greg Kroah-Hartman
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 UTC 2018. Anything received after that time might be too late.
For v4.9.88-239-g393003b:
Build results:
total: 145 pass: 143 fail: 2 Failed builds: arm:allmodconfig x86_64:allnoconfig
Quoted 6 lines
Quoted 4 lines
arm:
sound/soc/sh/rcar/cmd.c: In function 'rsnd_cmd_init':sound/soc/sh/rcar/cmd.c:85:14: warning: array subscript is below array boundsOops, missed this one for -rc3, let me go dig...
I don't see anything in this -rc that looks to be causing this. Has this warning been there before, or is it new now?
thanks,
greg k-h
Quoted 22 lines · Greg Kroah-Hartman
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 UTC 2018. Anything received after that time might be too late.
For v4.9.88-239-g393003b:
Build results:
total: 145 pass: 143 fail: 2 Failed builds: arm:allmodconfig x86_64:allnoconfigarm:
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
sound/soc/sh/rcar/cmd.c: In function 'rsnd_cmd_init':sound/soc/sh/rcar/cmd.c:85:14: warning: array subscript is below array boundsOops, missed this one for -rc3, let me go dig...
I don't see anything in this -rc that looks to be causing this. Has this warning been there before, or is it new now?
Probably old. I only mentioned it because you had asked to be informed about warnings. Does it make sense to bisect ?
Guenter
Greg Kroah-Hartman
maintainerQuoted 26 lines · Guenter Roeck
Quoted 25 lines · Greg Kroah-Hartman
Quoted 24 lines · Greg Kroah-Hartman
Quoted 22 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 UTC 2018. Anything received after that time might be too late.
For v4.9.88-239-g393003b:
Build results:
total: 145 pass: 143 fail: 2 Failed builds: arm:allmodconfig x86_64:allnoconfigarm:
sound/soc/sh/rcar/cmd.c: In function 'rsnd_cmd_init':sound/soc/sh/rcar/cmd.c:85:14: warning: array subscript is below array bounds
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Oops, missed this one for -rc3, let me go dig...
I don't see anything in this -rc that looks to be causing this. Has this warning been there before, or is it new now?
Probably old. I only mentioned it because you had asked to be informed about warnings. Does it make sense to bisect ?
Looks like 374503c6109e ("ASoC: rsnd: check src mod pointer for rsnd_mod_id()") fixes this, so I'll queue that up for the next round of updates after this one.
thanks,
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.89 release. There are 241 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Mar 21 18:07:03 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.9.89-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah