5.5.8-stable review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 146/176 RDMA/hns: Bugfix for posting a wqe with sge
In reply to Greg Kroah-HartmanFrom: Lijun Ou <[email protected]>
commit 468d020e2f02867b8ec561461a1689cd4365e493 upstream.
Driver should first check whether the sge is valid, then fill the valid sge and the caculated total into hardware, otherwise invalid sges will cause an error.
--- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 41 +++++++++++++++++------------ 1 file changed, 25 insertions(+), 16 deletions(-)
drivers/infiniband/hw/hns/hns_roce_hw_v2.c +25 -16
@@ -110,7 +110,7 @@ static void set_atomic_seg(struct hns_ro }static void set_extend_sge (struct hns_roce_qp *qp,const struct ib_send_wr *wr, -unsigned int *sge_ind) +unsigned int *sge_ind,int valid_num_sge) {struct hns_roce_v2_wqe_data_seg *dseg;struct ib_sge *sg;
@@ -123,7 +123,7 @@ static void set_extend_sge(struct hns_roif (qp->ibqp.qp_type ==IB_QPT_RC || qp->ibqp.qp_type ==IB_QPT_UC ) num_in_wqe =HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE ; - extend_sge_num = wr->num_sge - num_in_wqe; + extend_sge_num = valid_num_sge - num_in_wqe; sg = wr->sg_list + num_in_wqe; shift = qp->hr_buf.page_shift;
@@ -159,14 +159,16 @@ static void set_extend_sge(struct hns_rostatic int set_rwqe_data_seg (struct ib_qp *ibqp,const struct ib_send_wr *wr,struct hns_roce_v2_rc_send_wqe *rc_sq_wqe,void *wqe,unsigned int *sge_ind, +int valid_num_sge,const struct ib_send_wr **bad_wr) {struct hns_roce_dev *hr_dev =to_hr_dev (ibqp->device);struct hns_roce_v2_wqe_data_seg *dseg = wqe;struct hns_roce_qp *qp =to_hr_qp (ibqp); +int j =0 ;int i; -if (wr->send_flags &IB_SEND_INLINE && wr->num_sge) { +if (wr->send_flags &IB_SEND_INLINE && valid_num_sge) {if (le32_to_cpu (rc_sq_wqe->msg_len) > hr_dev->caps.max_sq_inline) { *bad_wr = wr;
@@ -190,7 +192,7 @@ static int set_rwqe_data_seg(struct ib_qroce_set_bit (rc_sq_wqe->byte_4,V2_RC_SEND_WQE_BYTE_4_INLINE_S ,1 ); }else { -if (wr->num_sge <=HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE ) { +if (valid_num_sge <=HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE ) {for (i =0 ; i < wr->num_sge; i++) {if (likely (wr->sg_list[i].length)) {set_data_seg_v2 (dseg, wr->sg_list + i);
@@ -203,19 +205,21 @@ static int set_rwqe_data_seg(struct ib_qV2_RC_SEND_WQE_BYTE_20_MSG_START_SGE_IDX_S , (*sge_ind) & (qp->sge.sge_cnt - 1)); -for (i =0 ; i <HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE ; i++) { +for (i =0 ; i < wr->num_sge && + j <HNS_ROCE_V2_UC_RC_SGE_NUM_IN_WQE ; i++) {if (likely (wr->sg_list[i].length)) {set_data_seg_v2 (dseg, wr->sg_list + i); dseg++; + j++; } } -set_extend_sge (qp, wr, sge_ind); +set_extend_sge (qp, wr, sge_ind, valid_num_sge); }roce_set_field (rc_sq_wqe->byte_16,V2_RC_SEND_WQE_BYTE_16_SGE_NUM_M , -V2_RC_SEND_WQE_BYTE_16_SGE_NUM_S , wr->num_sge); +V2_RC_SEND_WQE_BYTE_16_SGE_NUM_S , valid_num_sge); }return 0 ;
@@ -243,6 +247,7 @@ static int hns_roce_v2_post_send(structunsigned int sge_idx;unsigned int wqe_idx;unsigned long flags; +int valid_num_sge;void *wqe =NULL ;bool loopback;int attr_mask;
@@ -292,8 +297,16 @@ static int hns_roce_v2_post_send(struct qp->sq.wrid[wqe_idx] = wr->wr_id; owner_bit = ~(((qp->sq.head + nreq) >>ilog2 (qp->sq.wqe_cnt)) &0x1 ); + valid_num_sge =0 ; tmp_len =0 ; +for (i =0 ; i < wr->num_sge; i++) { +if (likely (wr->sg_list[i].length)) { + tmp_len += wr->sg_list[i].length; + valid_num_sge++; + } + } +/* Corresponding to the QP type, wqe process separately */ if (ibqp->qp_type ==IB_QPT_GSI ) { ud_sq_wqe = wqe;
@@ -329,9 +342,6 @@ static int hns_roce_v2_post_send(structV2_UD_SEND_WQE_BYTE_4_OPCODE_S , HNS_ROCE_V2_WQE_OP_SEND); -for (i =0 ; i < wr->num_sge; i++) - tmp_len += wr->sg_list[i].length; - ud_sq_wqe->msg_len =cpu_to_le32 (le32_to_cpu (ud_sq_wqe->msg_len) + tmp_len);
@@ -367,7 +377,7 @@ static int hns_roce_v2_post_send(structroce_set_field (ud_sq_wqe->byte_16,V2_UD_SEND_WQE_BYTE_16_SGE_NUM_M ,V2_UD_SEND_WQE_BYTE_16_SGE_NUM_S , - wr->num_sge); + valid_num_sge); roce_set_field(ud_sq_wqe->byte_20, V2_UD_SEND_WQE_BYTE_20_MSG_START_SGE_IDX_M,
@@ -422,12 +432,10 @@ static int hns_roce_v2_post_send(structmemcpy (&ud_sq_wqe->dgid[0 ], &ah->av.dgid[0 ],GID_LEN_V2 ); -set_extend_sge (qp, wr, &sge_idx); +set_extend_sge (qp, wr, &sge_idx, valid_num_sge); }else if (ibqp->qp_type ==IB_QPT_RC ) { rc_sq_wqe = wqe;memset (rc_sq_wqe,0 ,sizeof (*rc_sq_wqe)); -for (i =0 ; i < wr->num_sge; i++) - tmp_len += wr->sg_list[i].length; rc_sq_wqe->msg_len =cpu_to_le32 (le32_to_cpu (rc_sq_wqe->msg_len) + tmp_len);
@@ -548,10 +556,11 @@ static int hns_roce_v2_post_send(structroce_set_field (rc_sq_wqe->byte_16,V2_RC_SEND_WQE_BYTE_16_SGE_NUM_M ,V2_RC_SEND_WQE_BYTE_16_SGE_NUM_S , - wr->num_sge); + valid_num_sge); }else if (wr->opcode !=IB_WR_REG_MR ) { ret =set_rwqe_data_seg (ibqp, wr, rc_sq_wqe, - wqe, &sge_idx, bad_wr); + wqe, &sge_idx, + valid_num_sge, bad_wr);if (ret) goto out; }
Greg Kroah-Hartman
maintainerPATCH 147/176 drivers: net: xgene: Fix the order of the arguments of alloc_etherdev_mqs()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
commit 5a44c71ccda60a50073c5d7fe3f694cdfa3ab0c2 upstream.
'alloc_etherdev_mqs()' expects first 'tx', then 'rx'. The semantic here looks reversed.
Reorder the arguments passed to 'alloc_etherdev_mqs()' in order to keep the correct semantic.
In fact, this is a no-op because both XGENE_NUM_[RT]X_RING are 8.
--- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/apm/xgene/xgene_enet_main.c +1 -1
@@ -2020,7 +2020,7 @@ static int xgene_enet_probe(struct platfint ret; ndev =alloc_etherdev_mqs (sizeof (struct xgene_enet_pdata ), -XGENE_NUM_RX_RING ,XGENE_NUM_TX_RING ); +XGENE_NUM_TX_RING ,XGENE_NUM_RX_RING );if (!ndev)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 148/176 ima: ima/lsm policy rule loading logic bug fixes
In reply to Greg Kroah-HartmanFrom: Janne Karhunen <[email protected]>
commit 483ec26eed42bf050931d9a5c5f9f0b5f2ad5f3b upstream.
Keep the ima policy rules around from the beginning even if they appear invalid at the time of loading, as they may become active after an lsm policy load. However, loading a custom IMA policy with unknown LSM labels is only safe after we have transitioned from the "built-in" policy rules to a custom IMA policy.
Patch also fixes the rule re-use during the lsm policy reload and makes some prints a bit more human readable.
Changelog:
v4:
- Do not allow the initial policy load refer to non-existing lsm rules. v3:
- Fix too wide policy rule matching for non-initialized LSMs v2:
- Fix log prints
--- security/integrity/ima/ima_policy.c | 44 +++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 18 deletions(-)
security/integrity/ima/ima_policy.c +26 -18
@@ -263,7 +263,7 @@ static void ima_lsm_free_rule(struct imastatic struct ima_rule_entry *ima_lsm_copy_rule (struct ima_rule_entry *entry) {struct ima_rule_entry *nentry; -int i, result; +int i; nentry =kmalloc (sizeof (*nentry),GFP_KERNEL );if (!nentry)
@@ -277,7 +277,7 @@ static struct ima_rule_entry *ima_lsm_co memset(nentry->lsm, 0, sizeof_field(struct ima_rule_entry, lsm));for (i =0 ; i <MAX_LSM_RULES ; i++) { -if (!entry->lsm[i].rule) +if (!entry->lsm[i].args_p)continue ; nentry->lsm[i].type = entry->lsm[i].type;
@@ -286,13 +286,13 @@ static struct ima_rule_entry *ima_lsm_coif (!nentry->lsm[i].args_p) goto out_err; - result =security_filter_rule_init (nentry->lsm[i].type, - Audit_equal, - nentry->lsm[i].args_p, - &nentry->lsm[i].rule); -if (result == -EINVAL ) -pr_warn ("ima: rule for LSM \'%d\' is undefined\n" , - entry->lsm[i].type); +security_filter_rule_init (nentry->lsm[i].type, + Audit_equal, + nentry->lsm[i].args_p, + &nentry->lsm[i].rule); +if (!nentry->lsm[i].rule) +pr_warn ("rule for LSM \'%s\' is undefined\n" , + (char *)entry->lsm[i].args_p); }return nentry;
@@ -329,7 +329,7 @@ static void ima_lsm_update_rules(void)list_for_each_entry_safe (entry, e, &ima_policy_rules, list) { needs_update =0 ;for (i =0 ; i <MAX_LSM_RULES ; i++) { -if (entry->lsm[i].rule) { +if (entry->lsm[i].args_p) { needs_update =1 ;break ; }
@@ -339,8 +339,7 @@ static void ima_lsm_update_rules(void) result =ima_lsm_update_rule (entry);if (result) { -pr_err ("ima: lsm rule update error %d\n" , - result); +pr_err ("lsm rule update error %d\n" , result);return ; } }
@@ -357,7 +356,7 @@ int ima_lsm_policy_change(struct notifie }/** -* ima_match_rules - determine whether an inode matches the measure rule. +* ima_match_rules - determine whether an inode matches the policy rule. * @rule: a pointer to a rule * @inode: a pointer to an inode * @cred: a pointer to a credentials structure for user validation
@@ -415,9 +414,12 @@ static bool ima_match_rules(struct ima_rint rc =0 ;u32 osid; -if (!rule->lsm[i].rule) -continue ; - +if (!rule->lsm[i].rule) { +if (!rule->lsm[i].args_p) +continue ; +else +return false; + }switch (i) {case LSM_OBJ_USER :case LSM_OBJ_ROLE :
@@ -823,8 +825,14 @@ static int ima_lsm_rule_init(struct ima_ entry->lsm[lsm_rule].args_p, &entry->lsm[lsm_rule].rule);if (!entry->lsm[lsm_rule].rule) { -kfree (entry->lsm[lsm_rule].args_p); -return -EINVAL ; +pr_warn ("rule for LSM \'%s\' is undefined\n" , + (char *)entry->lsm[lsm_rule].args_p); + +if (ima_rules == &ima_default_rules) { +kfree (entry->lsm[lsm_rule].args_p); + result = -EINVAL ; + }else + result =0 ; }return result;
Greg Kroah-Hartman
maintainerPATCH 149/176 kprobes: Set unoptimized flag after unoptimizing code
In reply to Greg Kroah-HartmanFrom: Masami Hiramatsu <[email protected]>
commit f66c0447cca1281116224d474cdb37d6a18e4b5b upstream.
Set the unoptimized flag after confirming the code is completely unoptimized. Without this fix, when a kprobe hits the intermediate modified instruction (the first byte is replaced by an INT3, but later bytes can still be a jump address operand) while unoptimizing, it can return to the middle byte of the modified code, which causes an invalid instruction exception in the kernel.
Usually, this is a rare case, but if we put a probe on the function call while text patching, it always causes a kernel panic as below:
# echo p text_poke+5 > kprobe_events # echo 1 > events/kprobes/enable # echo 0 > events/kprobes/enable
invalid opcode: 0000 [#1] PREEMPT SMP PTI
RIP: 0010:text_poke+0x9/0x50 Call Trace: arch_unoptimize_kprobe+0x22/0x28 arch_unoptimize_kprobes+0x39/0x87 kprobe_optimizer+0x6e/0x290 process_one_work+0x2a0/0x610 worker_thread+0x28/0x3d0 ? process_one_work+0x610/0x610 kthread+0x10d/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x3a/0x50
text_poke() is used for patching the code in optprobes.
This can happen even if we blacklist text_poke() and other functions, because there is a small time window during which we show the intermediate code to other CPUs.
[ mingo: Edited the changelog. ]
--- kernel/kprobes.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/kprobes.c +3 -1
@@ -510,6 +510,8 @@ static void do_unoptimize_kprobes(void)arch_unoptimize_kprobes (&unoptimizing_list, &freeing_list);/* Loop free_list for disarming */ list_for_each_entry_safe (op, tmp, &freeing_list, list) { +/* Switching from detour code to origin */ + op->kp.flags &= ~KPROBE_FLAG_OPTIMIZED ;/* Disarm probes if marked disabled */ if (kprobe_disabled (&op->kp))arch_disarm_kprobe (&op->kp);
@@ -665,6 +667,7 @@ static void force_unoptimize_kprobe(stru {lockdep_assert_cpus_held ();arch_unoptimize_kprobe (op); + op->kp.flags &= ~KPROBE_FLAG_OPTIMIZED ;if (kprobe_disabled (&op->kp))arch_disarm_kprobe (&op->kp); }
@@ -681,7 +684,6 @@ static void unoptimize_kprobe(struct kprif (!kprobe_optimized (p))return ; - op->kp.flags &= ~KPROBE_FLAG_OPTIMIZED ;if (!list_empty (&op->list)) {if (optprobe_queued_unopt (op)) {/* Queued in unoptimizing queue */
Greg Kroah-Hartman
maintainerPATCH 150/176 lib/vdso: Make __arch_update_vdso_data() logic understandable
In reply to Greg Kroah-HartmanFrom: Thomas Gleixner <[email protected]>
commit 9a6b55ac4a44060bcb782baf002859b2a2c63267 upstream.
The function name suggests that this is a boolean checking whether the architecture asks for an update of the VDSO data, but it works the other way round. To spare further confusion invert the logic.
--- arch/arm/include/asm/vdso/vsyscall.h | 4 ++-- include/asm-generic/vdso/vsyscall.h | 4 ++-- kernel/time/vsyscall.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
arch/arm/include/asm/vdso/vsyscall.h +2 -2
@@ -34,9 +34,9 @@ struct vdso_data *__arm_get_k_vdso_data(#define __arch_get_k_vdso_data __arm_get_k_vdso_datastatic __always_inline -int __arm_update_vdso_data(void) +bool __arm_update_vdso_data(void) { -return !cntvct_ok; +return cntvct_ok; }#define __arch_update_vdso_data __arm_update_vdso_data
include/asm-generic/vdso/vsyscall.h +2 -2
@@ -12,9 +12,9 @@ static __always_inline struct vdso_data#endif /* __arch_get_k_vdso_data */ #ifndef __arch_update_vdso_data -static __always_inline int __arch_update_vdso_data(void) +static __always_inline bool __arch_update_vdso_data(void) { -return 0 ; +return true; }#endif /* __arch_update_vdso_data */
kernel/time/vsyscall.c +1 -1
@@ -84,7 +84,7 @@ void update_vsyscall(struct timekeeper *struct vdso_timestamp *vdso_ts;u64 nsec; -if (__arch_update_vdso_data ()) { +if (!__arch_update_vdso_data ()) {/* * Some architectures might want to skip the update of the * data page.
Greg Kroah-Hartman
maintainerPATCH 151/176 lib/vdso: Update coarse timekeeper unconditionally
In reply to Greg Kroah-HartmanFrom: Thomas Gleixner <[email protected]>
commit 9f24c540f7f8eb3a981528da9a9a636a5bdf5987 upstream.
The low resolution parts of the VDSO, i.e.:
clock_gettime(CLOCK_*_COARSE), clock_getres(), time()
can be used even if there is no VDSO capable clocksource.
But if an architecture opts out of the VDSO data update then this information becomes stale. This affects ARM when there is no architected timer available. The lack of update causes userspace to use stale data forever.
Make the update of the low resolution parts unconditional and only skip the update of the high resolution parts if the architecture requests it.
--- kernel/time/vsyscall.c | 37 +++++++++++++++++-------------------- 1 file changed, 17 insertions(+), 20 deletions(-)
kernel/time/vsyscall.c +17 -20
@@ -28,11 +28,6 @@ static inline void update_vdso_data(stru vdata[CS_RAW ].mult = tk->tkr_raw.mult; vdata[CS_RAW ].shift = tk->tkr_raw.shift; -/* CLOCK_REALTIME */ - vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_REALTIME ]; - vdso_ts->sec = tk->xtime_sec; - vdso_ts->nsec = tk->tkr_mono.xtime_nsec; -/* CLOCK_MONOTONIC */ vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_MONOTONIC ]; vdso_ts->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec;
@@ -70,12 +65,6 @@ static inline void update_vdso_data(stru vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_TAI ]; vdso_ts->sec = tk->xtime_sec + (s64 )tk->tai_offset; vdso_ts->nsec = tk->tkr_mono.xtime_nsec; - -/* -* Read without the seqlock held by clock_getres(). -* Note: No need to have a second copy. -*/ -WRITE_ONCE (vdata[CS_HRES_COARSE ].hrtimer_res, hrtimer_resolution); }void update_vsyscall (struct timekeeper *tk)
@@ -84,20 +73,17 @@ void update_vsyscall(struct timekeeper *struct vdso_timestamp *vdso_ts;u64 nsec; -if (!__arch_update_vdso_data ()) { -/* -* Some architectures might want to skip the update of the -* data page. -*/ -return ; - } -/* copy vsyscall data */ vdso_write_begin (vdata); vdata[CS_HRES_COARSE ].clock_mode =__arch_get_clock_mode (tk); vdata[CS_RAW ].clock_mode =__arch_get_clock_mode (tk); +/* CLOCK_REALTIME also required for time() */ + vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_REALTIME ]; + vdso_ts->sec = tk->xtime_sec; + vdso_ts->nsec = tk->tkr_mono.xtime_nsec; +/* CLOCK_REALTIME_COARSE */ vdso_ts = &vdata[CS_HRES_COARSE ].basetime[CLOCK_REALTIME_COARSE ]; vdso_ts->sec = tk->xtime_sec;
@@ -110,7 +96,18 @@ void update_vsyscall(struct timekeeper * nsec = nsec + tk->wall_to_monotonic.tv_nsec; vdso_ts->sec +=__iter_div_u64_rem (nsec,NSEC_PER_SEC , &vdso_ts->nsec); -update_vdso_data (vdata, tk); +/* +* Read without the seqlock held by clock_getres(). +* Note: No need to have a second copy. +*/ +WRITE_ONCE (vdata[CS_HRES_COARSE ].hrtimer_res, hrtimer_resolution); + +/* +* Architectures can opt out of updating the high resolution part +* of the VDSO. +*/ +if (__arch_update_vdso_data ()) +update_vdso_data (vdata, tk);__arch_update_vsyscall (vdata, tk);
Greg Kroah-Hartman
maintainerPATCH 152/176 pwm: omap-dmtimer: put_device() after of_find_device_by_node()
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
commit c7cb3a1dd53f63c64fb2b567d0be130b92a44d91 upstream.
This was found by coccicheck:
drivers/pwm/pwm-omap-dmtimer.c:304:2-8: ERROR: missing put_device; call of_find_device_by_node on line 255, but without a corresponding object release within this function.
--- drivers/pwm/pwm-omap-dmtimer.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-)
drivers/pwm/pwm-omap-dmtimer.c +15 -6
@@ -256,7 +256,7 @@ static int pwm_omap_dmtimer_probe(structif (!timer_pdev) {dev_err (&pdev->dev,"Unable to find Timer pdev\n" ); ret = -ENODEV ; - goto put; + goto err_find_timer_pdev; } timer_pdata =dev_get_platdata (&timer_pdev->dev);
@@ -264,7 +264,7 @@ static int pwm_omap_dmtimer_probe(structdev_dbg (&pdev->dev,"dmtimer pdata structure NULL, deferring probe\n" ); ret = -EPROBE_DEFER ; - goto put; + goto err_platdata; } pdata = timer_pdata->timer_ops;
@@ -283,19 +283,19 @@ static int pwm_omap_dmtimer_probe(struct !pdata->write_counter) {dev_err (&pdev->dev,"Incomplete dmtimer pdata structure\n" ); ret = -EINVAL ; - goto put; + goto err_platdata; }if (!of_get_property (timer,"ti,timer-pwm" ,NULL )) {dev_err (&pdev->dev,"Missing ti,timer-pwm capability\n" ); ret = -ENODEV ; - goto put; + goto err_timer_property; } dm_timer = pdata->request_by_node (timer);if (!dm_timer) { ret = -EPROBE_DEFER ; - goto put; + goto err_request_timer; } omap =devm_kzalloc (&pdev->dev,sizeof (*omap),GFP_KERNEL );
@@ -352,7 +352,14 @@ err_pwmchip_add: err_alloc_omap: pdata->free (dm_timer); -put: +err_request_timer: + +err_timer_property: +err_platdata: + +put_device (&timer_pdev->dev); +err_find_timer_pdev: +of_node_put (timer);return ret;
@@ -372,6 +379,8 @@ static int pwm_omap_dmtimer_remove(struc omap->pdata->free (omap->dm_timer); +put_device (&omap->dm_timer_pdev->dev); +mutex_destroy (&omap->mutex);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 153/176 perf hists browser: Restore ESC as "Zoom out" of DSO/thread/etc
In reply to Greg Kroah-HartmanFrom: Arnaldo Carvalho de Melo <[email protected]>
commit 3f7774033e6820d25beee5cf7aefa11d4968b951 upstream.
We need to set actions->ms.map since 599a2f38a989 ("perf hists browser:
Check sort keys before hot key actions"), as in that patch we bail out if map is NULL.
--- tools/perf/ui/browsers/hists.c | 1 + 1 file changed, 1 insertion(+)
tools/perf/ui/browsers/hists.c +1 -0
@@ -3062,6 +3062,7 @@ static int perf_evsel__hists_browse(strucontinue ; } + actions->ms.map = map; top =pstack__peek (browser->pstack);if (top == &browser->hists->dso_filter) {/*
Greg Kroah-Hartman
maintainerPATCH 154/176 perf ui gtk: Add missing zalloc object
In reply to Greg Kroah-HartmanFrom: Jiri Olsa <[email protected]>
commit 604e2139a1026793b8c2172bd92c7e9d039a5cf0 upstream.
When we moved zalloc.o to the library we missed gtk library which needs it compiled in, otherwise the missing __zfree symbol will cause the library to fail to load.
Adding the zalloc object to the gtk library build.
--- tools/perf/ui/gtk/Build | 5 +++++ 1 file changed, 5 insertions(+)
tools/perf/ui/gtk/Build +5 -0
@@ -7,3 +7,8 @@ gtk-y += util.o gtk-y += helpline.o gtk-y += progress.o gtk-y += annotate.o +gtk-y += zalloc.o + +$(OUTPUT)ui/gtk/zalloc.o: ../lib/zalloc.c FORCE + $(call rule_mkdir) + $(call if_changed_dep,cc_o_c)
Greg Kroah-Hartman
maintainerPATCH 155/176 perf maps: Add missing unlock to maps__insert() error case
In reply to Greg Kroah-HartmanFrom: Cengiz Can <[email protected]>
commit 85fc95d75970ee7dd8e01904e7fb1197c275ba6b upstream.
tools/perf/util/map.c has a function named maps__insert that acquires a write lock if its in multithread context.
Even though this lock is released when function successfully completes, there's a branch that is executed when maps_by_name == NULL that returns from this function without releasing the write lock.
Added an up_write to release the lock when this happens.
--- tools/perf/util/map.c | 1 + 1 file changed, 1 insertion(+)
tools/perf/util/map.c +1 -0
@@ -549,6 +549,7 @@ void maps__insert(struct maps *maps, strif (maps_by_name ==NULL ) {__maps__free_maps_by_name (maps); +up_write (&maps->lock);return ; }
Greg Kroah-Hartman
maintainerPATCH 156/176 x86/resctrl: Check monitoring static key in the MBM overflow handler
In reply to Greg Kroah-HartmanFrom: Xiaochen Shen <[email protected]>
commit 536a0d8e79fb928f2735db37dda95682b6754f9a upstream.
Currently, there are three static keys in the resctrl file system:rdt_mon_enable_key and rdt_alloc_enable_key indicate if the monitoring feature and the allocation feature are enabled, respectively. The rdt_enable_key is enabled when either the monitoring feature or the allocation feature is enabled.
If no monitoring feature is present (either hardware doesn't support a monitoring feature or the feature is disabled by the kernel command line option "rdt="), rdt_enable_key is still enabled but rdt_mon_enable_key is disabled.
MBM is a monitoring feature. The MBM overflow handler intends to check if the monitoring feature is not enabled for fast return.
So check the rdt_mon_enable_key in it instead of the rdt_enable_key as former is the more accurate check.
[ bp: Massage commit message. ]
--- arch/x86/kernel/cpu/resctrl/internal.h | 1 + arch/x86/kernel/cpu/resctrl/monitor.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/resctrl/internal.h +1 -0
@@ -57,6 +57,7 @@ static inline struct rdt_fs_context *rdt }DECLARE_STATIC_KEY_FALSE (rdt_enable_key); +DECLARE_STATIC_KEY_FALSE (rdt_mon_enable_key);/** * struct mon_evt - Entry in the event list of a resource
arch/x86/kernel/cpu/resctrl/monitor.c +2 -2
@@ -514,7 +514,7 @@ void mbm_handle_overflow(struct work_strmutex_lock (&rdtgroup_mutex); -if (!static_branch_likely (&rdt_enable_key)) +if (!static_branch_likely (&rdt_mon_enable_key)) goto out_unlock; d =get_domain_from_cpu (cpu, &rdt_resources_all[RDT_RESOURCE_L3 ]);
@@ -543,7 +543,7 @@ void mbm_setup_overflow_handler(struct runsigned long delay =msecs_to_jiffies (delay_ms);int cpu; -if (!static_branch_likely (&rdt_enable_key)) +if (!static_branch_likely (&rdt_mon_enable_key))return ; cpu =cpumask_any (&dom->cpu_mask); dom->mbm_work_cpu = cpu;
Greg Kroah-Hartman
maintainerPATCH 157/176 KVM: X86: Fix kvm_bitmap_or_dest_vcpus() to use irq shorthand
In reply to Greg Kroah-HartmanFrom: Peter Xu <[email protected]>
commit b4b2963616bbd91ebb33148522552e1135de56ae upstream.
The 3rd parameter of kvm_apic_match_dest() is the irq shorthand, rather than the irq delivery mode.
--- arch/x86/kvm/lapic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/lapic.c +1 -1
@@ -1150,7 +1150,7 @@ void kvm_bitmap_or_dest_vcpus(struct kvmif (!kvm_apic_present (vcpu))continue ;if (!kvm_apic_match_dest (vcpu,NULL , - irq->delivery_mode, + irq->shorthand, irq->dest_id, irq->dest_mode))continue ;
Greg Kroah-Hartman
maintainerPATCH 158/176 KVM: x86: Remove spurious kvm_mmu_unload() from vcpu destruction path
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 9d979c7e6ff43ca3200ffcb74f57415fd633a2da upstream.
x86 does not load its MMU until KVM_RUN, which cannot be invoked until after vCPU creation succeeds. Given that kvm_arch_vcpu_destroy() is called if and only if vCPU creation fails, it is impossible for the MMU to be loaded.
Note, the bogus kvm_mmu_unload() call was added during an unrelated refactoring of vCPU allocation, i.e. was presumably added as an opportunstic "fix" for a perceived leak.
--- arch/x86/kvm/x86.c | 4 ---- 1 file changed, 4 deletions(-)
arch/x86/kvm/x86.c +0 -4
@@ -9229,10 +9229,6 @@ void kvm_arch_vcpu_destroy(struct kvm_vc { vcpu->arch.apf.msr_val =0 ; -vcpu_load (vcpu); -kvm_mmu_unload (vcpu); -vcpu_put (vcpu); -kvm_arch_vcpu_free (vcpu); }
Greg Kroah-Hartman
maintainerPATCH 159/176 KVM: x86: Remove spurious clearing of async #PF MSR
In reply to Greg Kroah-HartmanFrom: Sean Christopherson <[email protected]>
commit 208050dac5ef4de5cb83ffcafa78499c94d0b5ad upstream.
Remove a bogus clearing of apf.msr_val from kvm_arch_vcpu_destroy().
apf.msr_val is only set to a non-zero value by kvm_pv_enable_async_pf(), which is only reachable by kvm_set_msr_common(), i.e. by writing MSR_KVM_ASYNC_PF_EN. KVM does not autonomously write said MSR, i.e. can only be written via KVM_SET_MSRS or KVM_RUN. Since KVM_SET_MSRS and KVM_RUN are vcpu ioctls, they require a valid vcpu file descriptor. kvm_arch_vcpu_destroy() is only called if KVM_CREATE_VCPU fails, and KVM declares KVM_CREATE_VCPU successful once the vcpu fd is installed and thus visible to userspace. Ergo, apf.msr_val cannot be non-zero when kvm_arch_vcpu_destroy() is called.
--- arch/x86/kvm/x86.c | 2 -- 1 file changed, 2 deletions(-)
arch/x86/kvm/x86.c +0 -2
@@ -9227,8 +9227,6 @@ void kvm_arch_vcpu_postcreate(struct kvmvoid kvm_arch_vcpu_destroy (struct kvm_vcpu *vcpu) { - vcpu->arch.apf.msr_val =0 ; -kvm_arch_vcpu_free (vcpu); }
Greg Kroah-Hartman
maintainerPATCH 160/176 rcu: Allow only one expedited GP to run concurrently with wakeups
In reply to Greg Kroah-HartmanFrom: Neeraj Upadhyay <[email protected]>
commit 4bc6b745e5cbefed92c48071e28a5f41246d0470 upstream.
The current expedited RCU grace-period code expects that a task requesting an expedited grace period cannot awaken until that grace period has reached the wakeup phase. However, it is possible for a long preemption to result in the waiting task never sleeping. For example, consider the following sequence of events:
1. Task A starts an expedited grace period by invoking
synchronize_rcu_expedited(). It proceeds normally up to the wait_event() near the end of that function, and is then preempted (or interrupted or whatever).
2. The expedited grace period completes, and a kworker task starts
the awaken phase, having incremented the counter and acquired the rcu_state structure's .exp_wake_mutex. This kworker task is then preempted or interrupted or whatever.
3. Task A resumes and enters wait_event(), which notes that the
expedited grace period has completed, and thus doesn't sleep.
4. Task B starts an expedited grace period exactly as did Task A,
complete with the preemption (or whatever delay) just before the call to wait_event().
5. The expedited grace period completes, and another kworker
task starts the awaken phase, having incremented the counter. However, it blocks when attempting to acquire the rcu_state structure's .exp_wake_mutex because step 2's kworker task has not yet released it.
6. Steps 4 and 5 repeat, resulting in overflow of the rcu_node
structure's ->exp_wq[] array.
In theory, this is harmless. Tasks waiting on the various ->exp_wq[] array will just be spuriously awakened, but they will just sleep again on noting that the rcu_state structure's ->expedited_sequence value has not advanced far enough.
In practice, this wastes CPU time and is an accident waiting to happen. This commit therefore moves the rcu_exp_gp_seq_end() call that officially ends the expedited grace period (along with associate tracing) until after the ->exp_wake_mutex has been acquired. This prevents Task A from awakening prematurely, thus preventing more than one expedited grace period from being in flight during a previous expedited grace period's wakeup phase.
--- kernel/rcu/tree_exp.h | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-)
kernel/rcu/tree_exp.h +5 -6
@@ -540,14 +540,13 @@ static void rcu_exp_wait_wake(unsigned lstruct rcu_node *rnp;synchronize_sched_expedited_wait (); -rcu_exp_gp_seq_end (); -trace_rcu_exp_grace_period (rcu_state.name, s,TPS ("end" )); -/* -* Switch over to wakeup mode, allowing the next GP, but -only- the -* next GP, to proceed. -*/ +// Switch over to wakeup mode, allowing the next GP to proceed. +// End the previous grace period only after acquiring the mutex +// to ensure that only one GP runs concurrently with wakeups. mutex_lock (&rcu_state.exp_wake_mutex); +rcu_exp_gp_seq_end (); +trace_rcu_exp_grace_period (rcu_state.name, s,TPS ("end" ));rcu_for_each_node_breadth_first (rnp) {if (ULONG_CMP_LT (READ_ONCE (rnp->exp_seq_rq), s)) {
Greg Kroah-Hartman
maintainerPATCH 161/176 ubifs: Fix ino_t format warnings in orphan_delete()
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
commit 155fc6ba488a8bdfd1d3be3d7ba98c9cec2b2429 upstream.
On alpha and s390x:
fs/ubifs/debug.h:158:11: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘ino_t {aka unsigned int}’ [-Wformat=]
...
fs/ubifs/orphan.c:132:3: note: in expansion of macro ‘dbg_gen’
dbg_gen("deleted twice ino %lu", orph->inum);
...
fs/ubifs/orphan.c:140:3: note: in expansion of macro ‘dbg_gen’
dbg_gen("delete later ino %lu", orph->inum);__kernel_ino_t is "unsigned long" on most architectures, but not on alpha and s390x, where it is "unsigned int". Hence when printing an ino_t, it should always be cast to "unsigned long" first.
Fix this by re-adding the recently removed casts.
--- fs/ubifs/orphan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ubifs/orphan.c +2 -2
@@ -129,7 +129,7 @@ static void __orphan_drop(struct ubifs_istatic void orphan_delete (struct ubifs_info *c,struct ubifs_orphan *orph) {if (orph->del) { -dbg_gen ("deleted twice ino %lu" , orph->inum); +dbg_gen ("deleted twice ino %lu" , (unsigned long )orph->inum);return ; }
@@ -137,7 +137,7 @@ static void orphan_delete(struct ubifs_i orph->del =1 ; orph->dnext = c->orph_dnext; c->orph_dnext = orph; -dbg_gen ("delete later ino %lu" , orph->inum); +dbg_gen ("delete later ino %lu" , (unsigned long )orph->inum);return ; }
Greg Kroah-Hartman
maintainerPATCH 162/176 thermal: db8500: Depromote debug print
In reply to Greg Kroah-HartmanFrom: Linus Walleij <[email protected]>
commit c56dcfa3d4d0f49f0c37cd24886aa86db7aa7f30 upstream.
We are not interested in getting this debug print on our console all the time.
--- drivers/thermal/db8500_thermal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/thermal/db8500_thermal.c +2 -2
@@ -152,8 +152,8 @@ static irqreturn_t prcmu_high_irq_handledb8500_thermal_update_config (th, idx,THERMAL_TREND_RAISING , next_low, next_high); -dev_info (&th->tz->device, -"PRCMU set max %ld, min %ld\n" , next_high, next_low); +dev_dbg (&th->tz->device, +"PRCMU set max %ld, min %ld\n" , next_high, next_low); }else if (idx == num_points -1 )/* So we roof out 1 degree over the max point */ th->interpolated_temp = db8500_thermal_points[idx] +1 ;
Greg Kroah-Hartman
maintainerPATCH 163/176 thermal: brcmstb_thermal: Do not use DT coefficients
In reply to Greg Kroah-HartmanFrom: Florian Fainelli <[email protected]>
commit e1ff6fc22f19e2af8adbad618526b80067911d40 upstream.
At the time the brcmstb_thermal driver and its binding were merged, the DT binding did not make the coefficients properties a mandatory one, therefore all users of the brcmstb_thermal driver out there have a non functional implementation with zero coefficients. Even if these properties were provided, the formula used for computation is incorrect.
The coefficients are entirely process specific (right now, only 28nm is supported) and not board or SoC specific, it is therefore appropriate to hard code them in the driver given the compatibility string we are probed with which has to be updated whenever a new process is introduced.
We remove the existing coefficients definition since subsequent patches are going to add support for a new process and will introduce new coefficients as well.
--- drivers/thermal/broadcom/brcmstb_thermal.c | 31 ++++++++--------------------- 1 file changed, 9 insertions(+), 22 deletions(-)
drivers/thermal/broadcom/brcmstb_thermal.c +9 -22
@@ -49,7 +49,7 @@#define AVS_TMON_TP_TEST_ENABLE 0x20/* Default coefficients */ -#define AVS_TMON_TEMP_SLOPE -487 +#define AVS_TMON_TEMP_SLOPE 487#define AVS_TMON_TEMP_OFFSET 410040/* HW related temperature constants */
@@ -108,23 +108,12 @@ struct brcmstb_thermal_priv {struct thermal_zone_device *thermal; }; -static void avs_tmon_get_coeffs (struct thermal_zone_device *tz,int *slope, -int *offset) -{ - *slope =thermal_zone_get_slope (tz); - *offset =thermal_zone_get_offset (tz); -} -/* Convert a HW code to a temperature reading (millidegree celsius) */ static inline int avs_tmon_code_to_temp (struct thermal_zone_device *tz,u32 code) { -const int val = code &AVS_TMON_TEMP_MASK ; -int slope, offset; - -avs_tmon_get_coeffs (tz, &slope, &offset); - -return slope * val + offset; +return (AVS_TMON_TEMP_OFFSET - + (int )((code &AVS_TMON_TEMP_MAX ) *AVS_TMON_TEMP_SLOPE )); }/*
@@ -136,20 +125,18 @@ static inline int avs_tmon_code_to_temp(static inline u32 avs_tmon_temp_to_code (struct thermal_zone_device *tz,int temp,bool low) { -int slope, offset; -if (temp <AVS_TMON_TEMP_MIN ) -return AVS_TMON_TEMP_MAX ;/* Maximum code value */ - -avs_tmon_get_coeffs (tz, &slope, &offset); +return AVS_TMON_TEMP_MAX ;/* Maximum code value */ -if (temp >= offset) +if (temp >=AVS_TMON_TEMP_OFFSET )return 0 ;/* Minimum code value */ if (low) -return (u32)(DIV_ROUND_UP (offset - temp,abs (slope))); +return (u32)(DIV_ROUND_UP (AVS_TMON_TEMP_OFFSET - temp, +AVS_TMON_TEMP_SLOPE ));else -return (u32)((offset - temp) /abs (slope)); +return (u32)((AVS_TMON_TEMP_OFFSET - temp) / +AVS_TMON_TEMP_SLOPE ); }static int brcmstb_get_temp (void *data,int *temp)
Greg Kroah-Hartman
maintainerPATCH 164/176 netfilter: nft_tunnel: no need to call htons() when dumping ports
In reply to Greg Kroah-HartmanFrom: Xin Long <[email protected]>
commit cf3e204a1ca5442190018a317d9ec181b4639bd6 upstream.
info->key.tp_src and tp_dst are __be16, when using nla_put_be16() to dump them, htons() is not needed, so remove it in this patch.
--- net/netfilter/nft_tunnel.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/netfilter/nft_tunnel.c +2 -2
@@ -505,8 +505,8 @@ static int nft_tunnel_opts_dump(struct sstatic int nft_tunnel_ports_dump (struct sk_buff *skb,struct ip_tunnel_info *info) { -if (nla_put_be16 (skb,NFTA_TUNNEL_KEY_SPORT ,htons (info->key.tp_src)) <0 || -nla_put_be16 (skb,NFTA_TUNNEL_KEY_DPORT ,htons (info->key.tp_dst)) <0 ) +if (nla_put_be16 (skb,NFTA_TUNNEL_KEY_SPORT , info->key.tp_src) <0 || +nla_put_be16 (skb,NFTA_TUNNEL_KEY_DPORT , info->key.tp_dst) <0 )return -1 ;return 0 ;
Greg Kroah-Hartman
maintainerPATCH 165/176 netfilter: nf_flowtable: fix documentation
In reply to Greg Kroah-HartmanFrom: Matteo Croce <[email protected]>
commit 78e06cf430934fc3768c342cbebdd1013dcd6fa7 upstream.
In the flowtable documentation there is a missing semicolon, the command as is would give this error:
nftables.conf:5:27-33: Error: syntax error, unexpected devices, expecting newline or semicolon
hook ingress priority 0 devices = { br0, pppoe-data };
^^^^^^^
nftables.conf:4:12-13: Error: invalid hook (null)
flowtable ft {
^^--- Documentation/networking/nf_flowtable.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/networking/nf_flowtable.txt +1 -1
@@ -76,7 +76,7 @@ flowtable and add one rule to your forwa table inet x { flowtable f { - hook ingress priority 0 devices = { eth0, eth1 }; + hook ingress priority 0; devices = { eth0, eth1 }; } chain y { type filter hook forward priority 0; policy accept;
Greg Kroah-Hartman
maintainerPATCH 166/176 bus: tegra-aconnect: Remove PM_CLK dependency
In reply to Greg Kroah-HartmanFrom: Sameer Pujar <[email protected]>
commit 2f56acf818a08a9187ac8ec6e3d994fc13dc368d upstream.
The ACONNECT bus driver does not use pm-clk interface anymore and hence the dependency can be removed from its Kconfig option.
--- drivers/bus/Kconfig | 1 - 1 file changed, 1 deletion(-)
drivers/bus/Kconfig +0 -1
@@ -139,7 +139,6 @@ config TEGRA_ACONNECT tristate "Tegra ACONNECT Bus Driver" depends on ARCH_TEGRA_210_SOC depends on OF && PM - select PM_CLK help Driver for the Tegra ACONNECT bus which is used to interface with the devices inside the Audio Processing Engine (APE) for Tegra210.
Greg Kroah-Hartman
maintainerPATCH 167/176 clk: qcom: rpmh: Sort OF match table
In reply to Greg Kroah-HartmanFrom: Bjorn Andersson <[email protected]>
commit 9e0cda721d18f44f1cd74d3a426931d71c1f1b30 upstream.
sc7180 was added to the end of the match table, sort the table.
--- drivers/clk/qcom/clk-rpmh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/clk-rpmh.c +1 -1
@@ -481,9 +481,9 @@ static int clk_rpmh_probe(struct platfor }static const struct of_device_id clk_rpmh_match_table[] = { + { .compatible ="qcom,sc7180-rpmh-clk" , .data = &clk_rpmh_sc7180}, { .compatible ="qcom,sdm845-rpmh-clk" , .data = &clk_rpmh_sdm845}, { .compatible ="qcom,sm8150-rpmh-clk" , .data = &clk_rpmh_sm8150}, - { .compatible ="qcom,sc7180-rpmh-clk" , .data = &clk_rpmh_sc7180}, { } };MODULE_DEVICE_TABLE (of, clk_rpmh_match_table);
Greg Kroah-Hartman
maintainerPATCH 168/176 xfs: clear kernel only flags in XFS_IOC_ATTRMULTI_BY_HANDLE
In reply to Greg Kroah-HartmanFrom: Christoph Hellwig <[email protected]>
commit 953aa9d136f53e226448dbd801a905c28f8071bf upstream.
Don't allow passing arbitrary flags as they change behavior including memory allocation that the call stack is not prepared for.
--- fs/xfs/libxfs/xfs_attr.h | 7 +++++-- fs/xfs/xfs_ioctl.c | 2 ++ fs/xfs/xfs_ioctl32.c | 2 ++ 3 files changed, 9 insertions(+), 2 deletions(-)
fs/xfs/libxfs/xfs_attr.h +5 -2
@@ -26,7 +26,7 @@ struct xfs_attr_list_context;*========================================================================*/ -#define ATTR_DONTFOLLOW 0x0001/* -- unused, from IRIX -- */ +#define ATTR_DONTFOLLOW 0x0001/* -- ignored, from IRIX -- */ #define ATTR_ROOT 0x0002/* use attrs in root (trusted) namespace */ #define ATTR_TRUST 0x0004/* -- unused, from IRIX -- */ #define ATTR_SECURE 0x0008/* use attrs in security namespace */
@@ -37,7 +37,10 @@ struct xfs_attr_list_context;#define ATTR_KERNOVAL 0x2000/* [kernel] get attr size only, not value */ #define ATTR_INCOMPLETE 0x4000/* [kernel] return INCOMPLETE attr keys */ -#define ATTR_ALLOC 0x8000/* allocate xattr buffer on demand */ +#define ATTR_ALLOC 0x8000/* [kernel] allocate xattr buffer on demand */ + +#define ATTR_KERNEL_FLAGS \ + (ATTR_KERNOTIME | ATTR_KERNOVAL | ATTR_INCOMPLETE | ATTR_ALLOC)#define XFS_ATTR_FLAGS \ { ATTR_DONTFOLLOW, "DONTFOLLOW" }, \
fs/xfs/xfs_ioctl.c +2 -0
@@ -462,6 +462,8 @@ xfs_attrmulti_by_handle( error =0 ;for (i =0 ; i < am_hreq.opcount; i++) { + ops[i].am_flags &= ~ATTR_KERNEL_FLAGS ; + ops[i].am_error =strncpy_from_user ((char *)attr_name, ops[i].am_attrname,MAXNAMELEN );if (ops[i].am_error ==0 || ops[i].am_error ==MAXNAMELEN )
fs/xfs/xfs_ioctl32.c +2 -0
@@ -450,6 +450,8 @@ xfs_compat_attrmulti_by_handle( error =0 ;for (i =0 ; i < am_hreq.opcount; i++) { + ops[i].am_flags &= ~ATTR_KERNEL_FLAGS ; + ops[i].am_error =strncpy_from_user ((char *)attr_name,compat_ptr (ops[i].am_attrname),MAXNAMELEN );
Greg Kroah-Hartman
maintainerPATCH 169/176 padata: always acquire cpu_hotplug_lock before pinst->lock
In reply to Greg Kroah-HartmanFrom: Daniel Jordan <[email protected]>
commit 38228e8848cd7dd86ccb90406af32de0cad24be3 upstream.
lockdep complains when padata's paths to update cpumasks via CPU hotplug and sysfs are both taken:
# echo 0 > /sys/devices/system/cpu/cpu1/online # echo ff > /sys/kernel/pcrypt/pencrypt/parallel_cpumask
======================================================
WARNING: possible circular locking dependency detected 5.4.0-rc8-padata-cpuhp-v3+ #1 Not tainted
------------------------------------------------------
bash/205 is trying to acquire lock:
ffffffff8286bcd0 (cpu_hotplug_lock.rw_sem){++++}, at: padata_set_cpumask+0x2b/0x120
but task is already holding lock:
ffff8880001abfa0 (&pinst->lock){+.+.}, at: padata_set_cpumask+0x26/0x120
which lock already depends on the new lock.
padata doesn't take cpu_hotplug_lock and pinst->lock in a consistent order. Which should be first? CPU hotplug calls into padata with cpu_hotplug_lock already held, so it should have priority.
--- kernel/padata.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/padata.c +2 -2
@@ -643,8 +643,8 @@ int padata_set_cpumask(struct padata_insstruct cpumask *serial_mask, *parallel_mask;int err = -EINVAL ; -mutex_lock (&pinst->lock);get_online_cpus (); +mutex_lock (&pinst->lock);switch (cpumask_type) {case PADATA_CPU_PARALLEL :
@@ -662,8 +662,8 @@ int padata_set_cpumask(struct padata_ins err =__padata_set_cpumasks (pinst, parallel_mask, serial_mask); out: -put_online_cpus ();mutex_unlock (&pinst->lock); +put_online_cpus ();return err; }
Greg Kroah-Hartman
maintainerPATCH 170/176 locking/lockdep: Fix lockdep_stats indentation problem
In reply to Greg Kroah-HartmanFrom: Waiman Long <[email protected]>
commit a030f9767da1a6bbcec840fc54770eb11c2414b6 upstream.
It was found that two lines in the output of /proc/lockdep_stats have indentation problem:
# cat /proc/lockdep_stats
:
in-process chains: 25057
stack-trace entries: 137827 [max: 524288]
number of stack traces: 7973
number of stack hash chains: 6355
combined max dependencies: 1356414598
hardirq-safe locks: 57
hardirq-unsafe locks: 1286
:All the numbers displayed in /proc/lockdep_stats except the two stack trace numbers are formatted with a field with of 11. To properly align all the numbers, a field width of 11 is now added to the two stack trace numbers.
--- kernel/locking/lockdep_proc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/locking/lockdep_proc.c +2 -2
@@ -286,9 +286,9 @@ static int lockdep_stats_show(struct seqseq_printf (m," stack-trace entries: %11lu [max: %lu]\n" , nr_stack_trace_entries,MAX_STACK_TRACE_ENTRIES );#if defined(CONFIG_TRACE_IRQFLAGS ) && defined(CONFIG_PROVE_LOCKING ) -seq_printf (m," number of stack traces: %llu\n" , +seq_printf (m," number of stack traces: %11llu\n" ,lockdep_stack_trace_count ()); -seq_printf (m," number of stack hash chains: %llu\n" , +seq_printf (m," number of stack hash chains: %11llu\n" ,lockdep_stack_hash_count ());#endif seq_printf(m, " combined max dependencies: %11u\n",
Greg Kroah-Hartman
maintainerPATCH 171/176 mm/debug.c: always print flags in dump_page()
In reply to Greg Kroah-HartmanFrom: Vlastimil Babka <[email protected]>
commit 5b57b8f22709f07c0ab5921c94fd66e8c59c3e11 upstream.
Commit 76a1850e4572 ("mm/debug.c: __dump_page() prints an extra line") inadvertently removed printing of page flags for pages that are neither anon nor ksm nor have a mapping. Fix that.
Using pr_cont() again would be a solution, but the commit explicitly removed its use. Avoiding the danger of mixing up split lines from multiple CPUs might be beneficial for near-panic dumps like this, so fix this without reintroducing pr_cont().
--- mm/debug.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
mm/debug.c +5 -3
@@ -47,6 +47,7 @@ void __dump_page(struct page *page, consstruct address_space *mapping;bool page_poisoned =PagePoisoned (page);int mapcount; +char *type ="" ;/* * If struct page is poisoned don't access Page*() functions as that
@@ -78,9 +79,9 @@ void __dump_page(struct page *page, cons page,page_ref_count (page), mapcount, page->mapping, page_to_pgoff(page));if (PageKsm (page)) -pr_warn ("ksm flags: %#lx(%pGp)\n" , page->flags, &page->flags); + type ="ksm " ;else if (PageAnon (page)) -pr_warn ("anon flags: %#lx(%pGp)\n" , page->flags, &page->flags); + type ="anon " ;else if (mapping) {if (mapping->host && mapping->host->i_dentry.first) {struct dentry *dentry;
@@ -88,10 +89,11 @@ void __dump_page(struct page *page, conspr_warn ("%ps name:\"%pd\"\n" , mapping->a_ops, dentry); }else pr_warn ("%ps\n" , mapping->a_ops); -pr_warn ("flags: %#lx(%pGp)\n" , page->flags, &page->flags); }BUILD_BUG_ON (ARRAY_SIZE (pageflag_names) != __NR_PAGEFLAGS +1 ); +pr_warn ("%sflags: %#lx(%pGp)\n" , type, page->flags, &page->flags); + hex_only: print_hex_dump(KERN_WARNING, "raw: ", DUMP_PREFIX_NONE, 32, sizeof(unsigned long), page,
Greg Kroah-Hartman
maintainerPATCH 172/176 mm/gup: allow FOLL_FORCE for get_user_pages_fast()
In reply to Greg Kroah-HartmanFrom: John Hubbard <[email protected]>
commit f4000fdf435b8301a11cf85237c561047f8c4c72 upstream.
Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast(). This, combined with the fact that get_user_pages_fast() falls back to "slow gup", which *does* accept FOLL_FORCE, leads to an odd situation:
if you need FOLL_FORCE, you cannot call get_user_pages_fast().
There does not appear to be any reason for filtering out FOLL_FORCE. There is nothing in the _fast() implementation that requires that we avoid writing to the pages. So it appears to have been an oversight.
Fix by allowing FOLL_FORCE to be set for get_user_pages_fast().
--- mm/gup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/gup.c +2 -1
@@ -2415,7 +2415,8 @@ int get_user_pages_fast(unsigned long stunsigned long addr, len, end;int nr =0 , ret =0 ; -if (WARN_ON_ONCE (gup_flags & ~(FOLL_WRITE |FOLL_LONGTERM ))) +if (WARN_ON_ONCE (gup_flags & ~(FOLL_WRITE |FOLL_LONGTERM | +FOLL_FORCE )))return -EINVAL ; start =untagged_addr (start) &PAGE_MASK ;
Greg Kroah-Hartman
maintainerPATCH 173/176 mm/huge_memory.c: use head to check huge zero page
In reply to Greg Kroah-HartmanFrom: Wei Yang <[email protected]>
commit cb829624867b5ab10bc6a7036d183b1b82bfe9f8 upstream.
The page could be a tail page, if this is the case, this BUG_ON will never be triggered.
--- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/huge_memory.c +1 -1
@@ -2712,7 +2712,7 @@ int split_huge_page_to_list(struct pageunsigned long flags;pgoff_t end; -VM_BUG_ON_PAGE (is_huge_zero_page (page), page); +VM_BUG_ON_PAGE (is_huge_zero_page (head), head);VM_BUG_ON_PAGE (!PageLocked (page), page);VM_BUG_ON_PAGE (!PageCompound (page), page);
Greg Kroah-Hartman
maintainerPATCH 174/176 mm, thp: fix defrag setting if newline is not used
In reply to Greg Kroah-HartmanFrom: David Rientjes <[email protected]>
commit f42f25526502d851d0e3ca1e46297da8aafce8a7 upstream.
If thp defrag setting "defer" is used and a newline is *not* used when writing to the sysfs file, this is interpreted as the "defer+madvise" option.
This is because we do prefix matching and if five characters are written without a newline, the current code ends up comparing to the first five bytes of the "defer+madvise" option and using that instead.
Use the more appropriate sysfs_streq() that handles the trailing newline for us. Since this doubles as a nice cleanup, do it in enabled_store() as well.
The current implementation relies on prefix matching: the number of bytes compared is either the number of bytes written or the length of the option being compared. With a newline, "defer\n" does not match "defer+"madvise"; without a newline, however, "defer" is considered to match "defer+madvise" (prefix matching is only comparing the first five bytes). End result is that writing "defer" is broken unless it has an additional trailing character.
This means that writing "madv" in the past would match and set "madvise". With strict checking, that no longer is the case but it is unlikely anybody is currently doing this.
--- mm/huge_memory.c | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-)
mm/huge_memory.c +8 -16
@@ -177,16 +177,13 @@ static ssize_t enabled_store(struct kobj {ssize_t ret = count; -if (!memcmp ("always" , buf, -min (sizeof ("always" )-1 , count))) { +if (sysfs_streq (buf,"always" )) {clear_bit (TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG , &transparent_hugepage_flags);set_bit (TRANSPARENT_HUGEPAGE_FLAG , &transparent_hugepage_flags); - }else if (!memcmp ("madvise" , buf, -min (sizeof ("madvise" )-1 , count))) { + }else if (sysfs_streq (buf,"madvise" )) {clear_bit (TRANSPARENT_HUGEPAGE_FLAG , &transparent_hugepage_flags);set_bit (TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG , &transparent_hugepage_flags); - }else if (!memcmp ("never" , buf, -min (sizeof ("never" )-1 , count))) { + }else if (sysfs_streq (buf,"never" )) {clear_bit (TRANSPARENT_HUGEPAGE_FLAG , &transparent_hugepage_flags);clear_bit (TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG , &transparent_hugepage_flags); }else
@@ -250,32 +247,27 @@ static ssize_t defrag_store(struct kobje struct kobj_attribute *attr, const char *buf, size_t count) { - if (!memcmp("always", buf, - min(sizeof("always")-1, count))) { + if (sysfs_streq(buf, "always")) { clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, &transparent_hugepage_flags); set_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags); - } else if (!memcmp("defer+madvise", buf, -min (sizeof ("defer+madvise" )-1 , count))) { + } else if (sysfs_streq(buf, "defer+madvise")) { clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, &transparent_hugepage_flags); set_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, &transparent_hugepage_flags); - }else if (!memcmp ("defer" , buf, -min (sizeof ("defer" )-1 , count))) { + } else if (sysfs_streq(buf, "defer")) { clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, &transparent_hugepage_flags); set_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, &transparent_hugepage_flags); - }else if (!memcmp ("madvise" , buf, -min (sizeof ("madvise" )-1 , count))) { + } else if (sysfs_streq(buf, "madvise")) { clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, &transparent_hugepage_flags); set_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, &transparent_hugepage_flags); - }else if (!memcmp ("never" , buf, -min (sizeof ("never" )-1 , count))) { + } else if (sysfs_streq(buf, "never")) { clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_FLAG, &transparent_hugepage_flags); clear_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, &transparent_hugepage_flags);
Greg Kroah-Hartman
maintainerPATCH 175/176 kvm: nVMX: VMWRITE checks VMCS-link pointer before VMCS field
In reply to Greg Kroah-HartmanFrom: Jim Mattson <[email protected]>
commit dd2d6042b7f4a5440705b4ffc6c4c2dba81a43b7 upstream.
According to the SDM, a VMWRITE in VMX non-root operation with an invalid VMCS-link pointer results in VMfailInvalid before the validity of the VMCS field in the secondary source operand is checked.
For consistency, modify both handle_vmwrite and handle_vmread, even though there was no problem with the latter.
--- arch/x86/kvm/vmx/nested.c | 59 +++++++++++++++++++--------------------------- 1 file changed, 25 insertions(+), 34 deletions(-)
arch/x86/kvm/vmx/nested.c +25 -34
@@ -4808,32 +4808,28 @@ static int handle_vmread(struct kvm_vcpu {unsigned long field;u64 field_value; +struct vcpu_vmx *vmx =to_vmx (vcpu);unsigned long exit_qualification =vmcs_readl (EXIT_QUALIFICATION );u32 vmx_instruction_info =vmcs_read32 (VMX_INSTRUCTION_INFO );int len;gva_t gva =0 ; -struct vmcs12 *vmcs12; +struct vmcs12 *vmcs12 =is_guest_mode (vcpu) ?get_shadow_vmcs12 (vcpu) + :get_vmcs12 (vcpu);struct x86_exception e;short offset;if (!nested_vmx_check_permission (vcpu))return 1 ; -if (to_vmx (vcpu)->nested.current_vmptr ==-1ull ) +/* +* In VMX non-root operation, when the VMCS-link pointer is -1ull, +* any VMREAD sets the ALU flags for VMfailInvalid. +*/ +if (vmx->nested.current_vmptr ==-1ull || + (is_guest_mode (vcpu) && +get_vmcs12 (vcpu)->vmcs_link_pointer ==-1ull ))return nested_vmx_failInvalid (vcpu); -if (!is_guest_mode (vcpu)) - vmcs12 =get_vmcs12 (vcpu); -else { -/* -* When vmcs->vmcs_link_pointer is -1ull, any VMREAD -* to shadowed-field sets the ALU flags for VMfailInvalid. -*/ -if (get_vmcs12 (vcpu)->vmcs_link_pointer ==-1ull ) -return nested_vmx_failInvalid (vcpu); - vmcs12 =get_shadow_vmcs12 (vcpu); - } -/* Decode instruction info and find the field to read */ field =kvm_register_readl (vcpu, (((vmx_instruction_info) >>28 ) &0xf ));
@@ -4912,13 +4908,20 @@ static int handle_vmwrite(struct kvm_vcp*/ u64 field_value =0 ;struct x86_exception e; -struct vmcs12 *vmcs12; +struct vmcs12 *vmcs12 =is_guest_mode (vcpu) ?get_shadow_vmcs12 (vcpu) + :get_vmcs12 (vcpu);short offset;if (!nested_vmx_check_permission (vcpu))return 1 ; -if (vmx->nested.current_vmptr ==-1ull ) +/* +* In VMX non-root operation, when the VMCS-link pointer is -1ull, +* any VMWRITE sets the ALU flags for VMfailInvalid. +*/ +if (vmx->nested.current_vmptr ==-1ull || + (is_guest_mode (vcpu) && +get_vmcs12 (vcpu)->vmcs_link_pointer ==-1ull ))return nested_vmx_failInvalid (vcpu);if (vmx_instruction_info & (1u <<10 ))
@@ -4946,24 +4949,12 @@ static int handle_vmwrite(struct kvm_vcpreturn nested_vmx_failValid (vcpu,VMXERR_VMWRITE_READ_ONLY_VMCS_COMPONENT ); -if (!is_guest_mode (vcpu)) { - vmcs12 =get_vmcs12 (vcpu); - -/* -* Ensure vmcs12 is up-to-date before any VMWRITE that dirties -* vmcs12, else we may crush a field or consume a stale value. -*/ -if (!is_shadow_field_rw (field)) -copy_vmcs02_to_vmcs12_rare (vcpu, vmcs12); - }else { -/* -* When vmcs->vmcs_link_pointer is -1ull, any VMWRITE -* to shadowed-field sets the ALU flags for VMfailInvalid. -*/ -if (get_vmcs12 (vcpu)->vmcs_link_pointer ==-1ull ) -return nested_vmx_failInvalid (vcpu); - vmcs12 =get_shadow_vmcs12 (vcpu); - } +/* +* Ensure vmcs12 is up-to-date before any VMWRITE that dirties +* vmcs12, else we may crush a field or consume a stale value. +*/ +if (!is_guest_mode (vcpu) && !is_shadow_field_rw (field)) +copy_vmcs02_to_vmcs12_rare (vcpu, vmcs12); offset =vmcs_field_to_offset (field);if (offset <0 )
Greg Kroah-Hartman
maintainerPATCH 176/176 kvm: nVMX: VMWRITE checks unsupported field before read-only field
In reply to Greg Kroah-HartmanFrom: Jim Mattson <[email protected]>
commit 693e02cc24090c379217138719d9d84e50036b24 upstream.
According to the SDM, VMWRITE checks to see if the secondary source operand corresponds to an unsupported VMCS field before it checks to see if the secondary source operand corresponds to a VM-exit information field and the processor does not support writing to VM-exit information fields.
--- arch/x86/kvm/vmx/nested.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
arch/x86/kvm/vmx/nested.c +6 -5
@@ -4940,6 +4940,12 @@ static int handle_vmwrite(struct kvm_vcp field =kvm_register_readl (vcpu, (((vmx_instruction_info) >>28 ) &0xf )); + + offset =vmcs_field_to_offset (field); +if (offset <0 ) +return nested_vmx_failValid (vcpu, +VMXERR_UNSUPPORTED_VMCS_COMPONENT ); +/* * If the vCPU supports "VMWRITE to any supported field in the * VMCS," then the "read-only" fields are actually read/write.
@@ -4956,11 +4962,6 @@ static int handle_vmwrite(struct kvm_vcpif (!is_guest_mode (vcpu) && !is_shadow_field_rw (field))copy_vmcs02_to_vmcs12_rare (vcpu, vmcs12); - offset =vmcs_field_to_offset (field); -if (offset <0 ) -return nested_vmx_failValid (vcpu, -VMXERR_UNSUPPORTED_VMCS_COMPONENT ); -/* * Some Intel CPUs intentionally drop the reserved bits of the AR byte * fields on VMWRITE. Emulate this behavior to ensure consistent KVM
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.5:
13 builds: 13 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 failLinux version: 5.5.8-rc1-g3517b32c0774
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 27 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.5:
13 builds: 13 pass, 0 fail 22 boots: 22 pass, 0 fail 40 tests: 40 pass, 0 fail
Quoted 6 lines
Linux version: 5.5.8-rc1-g3517b32c0774
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
thanks for testing all of these and letting me know.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · shuah
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Great, thanks for testing these and letting me know.
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions detected on x86_64 and i386.
Test failure output:
CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description:
CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
ref:
https://github.com/speed47/spectre-meltdown-checker
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.5-oe/tests/spectre-meltdown-checker-test/CVE-2017-5715
https://lkft.validation.linaro.org/scheduler/job/1264643#L21206
Summary
------------------------------------------------------------------------
kernel: 5.5.8-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.5.y
git commit: 3517b32c0774341d492140b2be08c4bf6d1a833e
git describe: v5.5.7-177-g3517b32c0774
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.5-oe/build/v5.5.7-177-g3517b32c0774
Regressions (compared to build v5.5.7)
------------------------------------------------------------------------
i386:
spectre-meltdown-checker-test:
* CVE-2017-5715
x86:
spectre-meltdown-checker-test:
* CVE-2017-5715
No fixes (compared to build v5.5.7)
Ran 25662 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* linux-log-parser
* perf
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-fcntl-locktests-tests
* ltp-fs-tests
* ltp-ipc-tests
* ltp-sched-tests
* network-basic-tests
* kvm-unit-tests
* libhugetlbfs
* ltp-commands-tests
* ltp-containers-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-m[
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-cap_bounds-64k-page_size-tests
* ltp-cap_bounds-kasan-tests
* ltp-commands-64k-page_size-tests
* ltp-commands-kasan-tests
* ltp-containers-64k-page_size-tests
* ltp-containers-kasan-tests
* ltp-cpuhotplug-64k-page_size-tests
* ltp-cpuhotplug-kasan-tests
* ltp-crypto-64k-page_size-tests
* ltp-crypto-kasan-tests
* ltp-cve-64k-page_size-tests
* ltp-cve-kasan-tests
* ltp-dio-64k-page_size-tests
* ltp-dio-kasan-tests
* ltp-fcntl-locktests-64k-page_size-tests
* ltp-fcntl-locktests-kasan-tests
* ltp-filecaps-64k-page_size-tests
* ltp-filecaps-kasan-tests
* ltp-fs-64k-page_size-tests
* ltp-fs-kasan-tests
* ltp-fs_bind-64k-page_size-tests
* ltp-fs_bind-kasan-tests
* ltp-fs_perms_simple-64k-page_size-tests
* ltp-fs_perms_simple-kasan-tests
* ltp-fsx-64k-page_size-tests
* ltp-fsx-kasan-tests
* ltp-hugetlb-64k-page_size-tests
* ltp-hugetlb-kasan-tests
* ltp-io-64k-page_size-tests
* ltp-io-kasan-tests
* ltp-ipc-64k-page_size-tests
* ltp-ipc-kasan-tests
* ltp-math-64k-page_size-tests
* ltp-math-kasan-tests
* ltp-math-tests
* ltp-mm-64k-page_size-tests
* ltp-mm-kasan-tests
* ltp-nptl-64k-page_size-tests
* ltp-nptl-kasan-tests
* ltp-pty-64k-page_size-tests
* ltp-pty-kasan-tests
* ltp-sched-64k-page_size-tests
* ltp-sched-kasan-tests
* ltp-securebits-64k-page_size-tests
* ltp-securebits-kasan-tests
* ltp-syscalls-64k-page_size-tests
* ltp-syscalls-compat-tests
* ltp-syscalls-kasan-tests
* ltp-open-posix-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions detected onx86_64and i386.Test failure output:
CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)Test description:
CVE-2017-5715 branch target injection (Spectre Variant 2)
Quoted 8 lines
Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
thanks,
greg k-h
Greg Kroah-Hartman
maintainerQuoted 42 lines · Greg Kroah-Hartman
Quoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions detected onx86_64and i386.Test failure output:
CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)Test description:
CVE-2017-5715 branch target injection (Spectre Variant 2)Quoted 8 lines
Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
Quoted 6 lines
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
Quoted 1 line
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
So please verify that this really is a real issue, and not just the script doing foolish things.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerQuoted 65 lines · Greg Kroah-Hartman
Quoted 42 lines · Greg Kroah-Hartman
Quoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions detected onx86_64and i386.Test failure output:
CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)Test description:
CVE-2017-5715 branch target injection (Spectre Variant 2)Quoted 8 lines
Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPUQuoted 6 lines
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional,IBRS_FW, STIBP: conditional, RSB filling)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
Quoted 8 lines
Quoted 1 line
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in
/boot/(I don't use netboot)So please verify that this really is a real issue, and not just the script doing foolish things.
And, if I tell the script where my kernel image is, suddenly all is good:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: N/A (not testable in offline mode)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: N/A (not testable in offline mode)
* Mitigation 2
* Kernel has branch predictor hardening (arm): UNKNOWN
* Kernel compiled with retpoline option: UNKNOWN (couldn't read your kernel configuration)
* Kernel supports RSB filling: YES
Quoted 1 line
STATUS: NOT VULNERABLE (offline mode: kernel supports IBRS + IBPB to mitigate the vulnerability)
Quoted 67 lines · Greg Kroah-Hartman
Quoted 65 lines · Greg Kroah-Hartman
Quoted 42 lines · Greg Kroah-Hartman
Quoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions detected onx86_64and i386.Test failure output:
CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)Test description:
CVE-2017-5715 branch target injection (Spectre Variant 2)Quoted 8 lines
Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPUQuoted 6 lines
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional,IBRS_FW, STIBP: conditional, RSB filling)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in
/boot/(I don't use netboot)
Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm, x86_64, and i386 for 4.19, 5.4 and 5.5 branches.
Sorry for the noise.
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 71 lines · Naresh Kamboju
Quoted 69 lines · Greg Kroah-Hartman
Quoted 67 lines · Greg Kroah-Hartman
Quoted 42 lines · Greg Kroah-Hartman
Quoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. 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/v5.x/stable-review/patch-5.5.8-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.5.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
Regressions detected onx86_64and i386.Test failure output:
CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)Test description:
CVE-2017-5715 branch target injection (Spectre Variant 2)Quoted 8 lines
Impact: Kernel
Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPUQuoted 6 lines
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional,IBRS_FW, STIBP: conditional, RSB filling)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))Quoted 1 line
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in
/boot/(I don't use netboot)Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm,
x86_64, and i386 for 4.19, 5.4 and 5.5 branches.
Great, thanks for confirming and for testing all of these.
greg k-h
Quoted 11 lines · Greg Kroah-Hartman
Quoted 8 lines · Naresh Kamboju
Quoted 3 lines
Quoted 3 lines
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in
/boot/(I don't use netboot)Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm,
x86_64, and i386 for 4.19, 5.4 and 5.5 branches.Great, thanks for confirming and for testing all of these.
We originally added spectre-meltdown-checker to lkft for informational purposes, so that we could compare its report to any actual tests that produce spectre/meltdown related failures (and help determine if the problem is hardware/firmware or kernel). In practice, it's never been helpful (because it's not an actual test) and so we'll be removing it from LKFT.
Dan
Quoted 2 lines
greg k-h
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 423 pass: 423 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 6 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.5.8 release. There are 176 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
Quoted 3 lines
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
Build results:
total: 157 pass: 157 fail: 0 Qemu test results: total: 423 pass: 423 fail: 0
Wonderful, thanks for testing these and letting me konw.
greg k-h