- Kernel - mailweb.openeuler.org

[PATCH] Revert "scsi: fix failing unload of a LLDD module"
by Yang Yingliang 09 May '20

09 May '20

From: Ye Bin <yebin10(a)huawei.com> hulk inclusion category: bugfix bugzilla: 34271 CVE: NA -------------------------------- This reverts commit fd72360bc94ad304136beb56e8ff2ec089113bb8. test setp: ... rmmod hisi_sas_v3_hw lsmod fdisk -l insomd hisi_sas_v3_hw.ko lsmod fdisk -l .... We get follow error when we test by above test steps. [ 3660.259153] [ffff00000116f000] pgd=00002027ffffe003, pud=00002027ffffd003, pmd=00002027cdf28003, pte=0000000000000000 [ 3660.269719] Internal error: Oops: 96000007 [#1] PREEMPT SMP [ 3660.275266] Modules linked in: hisi_sas_v3_hw(+) hisi_sas_main hns_roce_hw_v2(O) hns_roce(O) rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_ipoib ib_umad realtek hns3(O) hclge(O) hnae3(O) crc32_ce crct10dif_ce hisi_hpre hisi_zip hisi_qm uacce hisi_trng_v2 rng_core sfc lbc ip_tables x_tables libsas scsi_transport_sas [last unloaded: hisi_sas_main] [ 3660.308227] Process smartd (pid: 19570, stack limit = 0x000000001103634d) [ 3660.314985] CPU: 31 PID: 19570 Comm: smartd Kdump: loaded Tainted: G O 4.19.36-g32894fc #1 [ 3660.324504] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B220.02 03/27/2020 [ 3660.334110] pstate: 60400009 (nZCv daif +PAN -UAO) [ 3660.338882] pc : scsi_device_put+0x18/0x38 [ 3660.342961] lr : scsi_disk_put+0x3c/0x58 [ 3660.346865] sp : ffff0000158a3cb0 [ 3660.350164] x29: ffff0000158a3cb0 x28: ffff8027b8111000 [ 3660.355451] x27: 00000000080a005d x26: 0000000000000000 [ 3660.360738] x25: ffff8027c6310398 x24: ffff8027cd2ec410 [ 3660.366025] x23: ffff000009811000 x22: ffff80276d274750 [ 3660.371312] x21: ffff8027abdd5000 x20: ffff8027b8110800 [ 3660.376599] x19: ffff8027abdd5000 x18: 0000000000000000 [ 3660.381886] x17: 0000000000000000 x16: 0000000000000000 [ 3660.387172] x15: 0000000000000000 x14: 0000000000000000 [ 3660.392459] x13: ffff000009996cd0 x12: ffffffffffffffff [ 3660.397746] x11: ffff000009996cc8 x10: 0000000000000000 [ 3660.403033] x9 : 0000000000000000 x8 : 0000000040000000 [ 3660.408320] x7 : ffff0000098116c8 x6 : 0000000000000000 [ 3660.413607] x5 : ffff00000820ebbc x4 : ffff7e009eb8fb20 [ 3660.418894] x3 : 0000000080400009 x2 : ffff8027ae3ec600 [ 3660.424180] x1 : 71b6030ca20bb300 x0 : ffff00000116f000 [ 3660.429467] Call trace: [ 3660.431904] scsi_device_put+0x18/0x38 [ 3660.435636] scsi_disk_put+0x3c/0x58 [ 3660.439195] sd_release+0x50/0xc0 [ 3660.442496] __blkdev_put+0x20c/0x220 [ 3660.446141] blkdev_put+0x4c/0x110 [ 3660.449527] blkdev_close+0x1c/0x28 [ 3660.453000] __fput+0x88/0x1b8 [ 3660.456042] ____fput+0xc/0x18 [ 3660.459085] task_work_run+0x94/0xb0 [ 3660.462646] do_notify_resume+0x17c/0x180 [ 3660.466637] work_pending+0x8/0x10 [ 3660.470022] Code: f9000bf3 aa0003f3 f9400000 f9404c00 (f9400000) [ 3660.476089] ---[ end trace ca1d0144f9241f71 ]--- void scsi_device_put(struct scsi_device *sdev) { module_put(sdev->host->hostt->module); ---> error code put_device(&sdev->sdev_gendev); } When access "sdev->host->hostt" occurs exception, as "sdev->host->hostt" is point to the module address space which is already removed. module_delete first check module reference count, then call module exit function. So after pass module reference count check and before call module exit, we can call scsi_device_get function successfully. As "scsi: fix failing unload of a LLDD module" lead to call scsi_device_get success during remove module. We revert this patch, "scsi: fixup kernel warning during rmmod()" already fixed previous error. Signed-off-by: Ye Bin <yebin10(a)huawei.com> Reviewed-by: Hou Tao <houtao1(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/scsi/scsi.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index 7d472c2..fc1356d 100644 --- a/drivers/scsi/scsi.c +++ b/drivers/scsi/scsi.c @@ -544,6 +544,9 @@ int scsi_report_opcode(struct scsi_device *sdev, unsigned char *buffer, * Description: Gets a reference to the scsi_device and increments the use count * of the underlying LLDD module. You must hold host_lock of the * parent Scsi_Host or already have a reference when calling this. + * + * This will fail if a device is deleted or cancelled, or when the LLD module + * is in the process of being unloaded. */ int scsi_device_get(struct scsi_device *sdev) { @@ -551,12 +554,12 @@ int scsi_device_get(struct scsi_device *sdev) goto fail; if (!get_device(&sdev->sdev_gendev)) goto fail; - /* We can fail try_module_get if we're doing SCSI operations - * from module exit (like cache flush) - */ - __module_get(sdev->host->hostt->module); + if (!try_module_get(sdev->host->hostt->module)) + goto fail_put_device; return 0; +fail_put_device: + put_device(&sdev->sdev_gendev); fail: return -ENXIO; } -- 1.8.3

1 0

[PATCH] s390/mm: fix page table upgrade vs 2ndary address mode accesses
by Yang Yingliang 09 May '20

09 May '20

From: Christian Borntraeger <borntraeger(a)de.ibm.com> mainline inclusion from mainline-v5.7-rc4 commit 316ec154810960052d4586b634156c54d0778f74 category: bugfix bugzilla: 13690 CVE: CVE-2020-11884 ------------------------------------------------- A page table upgrade in a kernel section that uses secondary address mode will mess up the kernel instructions as follows: Consider the following scenario: two threads are sharing memory. On CPU1 thread 1 does e.g. strnlen_user(). That gets to old_fs = enable_sacf_uaccess(); len = strnlen_user_srst(src, size); and " la %2,0(%1)\n" " la %3,0(%0,%1)\n" " slgr %0,%0\n" " sacf 256\n" "0: srst %3,%2\n" in strnlen_user_srst(). At that point we are in secondary space mode, control register 1 points to kernel page table and instruction fetching happens via c1, rather than usual c13. Interrupts are not disabled, for obvious reasons. On CPU2 thread 2 does MAP_FIXED mmap(), forcing the upgrade of page table from 3-level to e.g. 4-level one. We'd allocated new top-level table, set it up and now we hit this: notify = 1; spin_unlock_bh(&mm->page_table_lock); } if (notify) on_each_cpu(__crst_table_upgrade, mm, 0); OK, we need to actually change over to use of new page table and we need that to happen in all threads that are currently running. Which happens to include the thread 1. IPI is delivered and we have static void __crst_table_upgrade(void *arg) { struct mm_struct *mm = arg; if (current->active_mm == mm) set_user_asce(mm); __tlb_flush_local(); } run on CPU1. That does static inline void set_user_asce(struct mm_struct *mm) { S390_lowcore.user_asce = mm->context.asce; OK, user page table address updated... __ctl_load(S390_lowcore.user_asce, 1, 1); ... and control register 1 set to it. clear_cpu_flag(CIF_ASCE_PRIMARY); } IPI is run in home space mode, so it's fine - insns are fetched using c13, which always points to kernel page table. But as soon as we return from the interrupt, previous PSW is restored, putting CPU1 back into secondary space mode, at which point we no longer get the kernel instructions from the kernel mapping. The fix is to only fixup the control registers that are currently in use for user processes during the page table update. We must also disable interrupts in enable_sacf_uaccess to synchronize the cr and thread.mm_segment updates against the on_each-cpu. Fixes: 0aaba41b58bc ("s390: remove all code using the access register mode") Cc: stable(a)vger.kernel.org # 4.15+ Reported-by: Al Viro <viro(a)zeniv.linux.org.uk> Reviewed-by: Gerald Schaefer <gerald.schaefer(a)de.ibm.com> References: CVE-2020-11884 Signed-off-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: Hanjun Guo <guohanjun(a)huawei.com> Reviewed-by: Jason Yan <yanaijie(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/s390/lib/uaccess.c | 4 ++++ arch/s390/mm/pgalloc.c | 16 ++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/s390/lib/uaccess.c b/arch/s390/lib/uaccess.c index c4f8039..0267405 100644 --- a/arch/s390/lib/uaccess.c +++ b/arch/s390/lib/uaccess.c @@ -64,10 +64,13 @@ mm_segment_t enable_sacf_uaccess(void) { mm_segment_t old_fs; unsigned long asce, cr; + unsigned long flags; old_fs = current->thread.mm_segment; if (old_fs & 1) return old_fs; + /* protect against a concurrent page table upgrade */ + local_irq_save(flags); current->thread.mm_segment |= 1; asce = S390_lowcore.kernel_asce; if (likely(old_fs == USER_DS)) { @@ -83,6 +86,7 @@ mm_segment_t enable_sacf_uaccess(void) __ctl_load(asce, 7, 7); set_cpu_flag(CIF_ASCE_SECONDARY); } + local_irq_restore(flags); return old_fs; } EXPORT_SYMBOL(enable_sacf_uaccess); diff --git a/arch/s390/mm/pgalloc.c b/arch/s390/mm/pgalloc.c index 814f265..f3bc9c9 100644 --- a/arch/s390/mm/pgalloc.c +++ b/arch/s390/mm/pgalloc.c @@ -72,8 +72,20 @@ static void __crst_table_upgrade(void *arg) { struct mm_struct *mm = arg; - if (current->active_mm == mm) - set_user_asce(mm); + /* we must change all active ASCEs to avoid the creation of new TLBs */ + if (current->active_mm == mm) { + S390_lowcore.user_asce = mm->context.asce; + if (current->thread.mm_segment == USER_DS) { + __ctl_load(S390_lowcore.user_asce, 1, 1); + /* Mark user-ASCE present in CR1 */ + clear_cpu_flag(CIF_ASCE_PRIMARY); + } + if (current->thread.mm_segment == USER_DS_SACF) { + __ctl_load(S390_lowcore.user_asce, 7, 7); + /* enable_sacf_uaccess does all or nothing */ + WARN_ON(!test_cpu_flag(CIF_ASCE_SECONDARY)); + } + } __tlb_flush_local(); } -- 1.8.3

1 0

[PATCH kernel-4.19] kernel: just for testing
by Xie XiuQi 07 May '20

07 May '20

just for testing openeuler kernel ci. Signed-off-by: Xie XiuQi <xiexiuqi(a)huawei.com> --- init/version.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/version.c b/init/version.c index ef4012ec4375..b8871517a6b2 100644 --- a/init/version.c +++ b/init/version.c @@ -43,7 +43,7 @@ EXPORT_SYMBOL_GPL(init_uts_ns); /* FIXED STRINGS! Don't touch! */ const char linux_banner[] = - "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@" + "Linux Version " UTS_RELEASE " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n"; const char linux_proc_banner[] = -- 2.20.1

1 0

[PATCH kernel-4.19] kernel: just for testing
by Xie XiuQi 07 May '20

07 May '20

just for testing openeuler kernel ci. Signed-off-by: Xie XiuQi <xiexiuqi(a)huawei.com> --- init/version.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/version.c b/init/version.c index ef4012ec4375..b8871517a6b2 100644 --- a/init/version.c +++ b/init/version.c @@ -43,7 +43,7 @@ EXPORT_SYMBOL_GPL(init_uts_ns); /* FIXED STRINGS! Don't touch! */ const char linux_banner[] = - "Linux version " UTS_RELEASE " (" LINUX_COMPILE_BY "@" + "Linux Version " UTS_RELEASE " (" LINUX_COMPILE_BY "@" LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION "\n"; const char linux_proc_banner[] = -- 2.20.1

1 0

[PATCH 1/3] blk-mq: use static_rqs instead of rqs to iterate tags
by Yang Yingliang 06 May '20

06 May '20

From: yu kuai <yukuai3(a)huawei.com> hulk inclusion category: bugfix bugzilla: 34280 CVE: NA --------------------------- tags->rqs[] will not been cleaned when free driver tag to avoid an extra store on a shared area in the per io path. But there is a window between get driver tag and write tags->rqs[], so we may see stale rq in tags->rqs[] which may have been freed, as the following case: blk_mq_get_request blk_mq_queue_tag_busy_iter -> blk_mq_get_tag -> bt_for_each -> bt_iter -> rq = tags->rqs[] -> rq->q -> blk_mq_rq_ctx_init -> data->hctx->tags->rqs[rq->tag] = rq; In additiion, tags->rqs[] only contains the requests that get driver tag. It is not accurate for io-scheduler case when account busy tags in part_in_flight. To fix both of them, the blk_mq_queue_tag_busy_iter is changed in this patch to use tags->static_rqs[] instead of tags->rqs[]. We have to identify whether there is a io scheduler attached to decide to use hctx->tags or hctx->sched_tags. And we will try to get a non-zero q_usage_counter before that, then could avoid race with update nr_hw_queues, switch io-scheduler and even queue cleanup. Add 'inflight' parameter to determine to iterate in-flight requests or just busy tags and add a new helper interface blk_mq_queue_tag_inflight_iter to iterate all of the in-flight tags and export this interface for drivers. Signed-off-by: yu kuai <yukuai3(a)huawei.com> Reviewed-by: Hou Tao <houtao1(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- block/blk-mq-tag.c | 77 ++++++++++++++++++++++++++++++++++++++++---------- block/blk-mq.c | 6 ++-- include/linux/blk-mq.h | 3 +- 3 files changed, 67 insertions(+), 19 deletions(-) diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c index 41317c5..323bbca 100644 --- a/block/blk-mq-tag.c +++ b/block/blk-mq-tag.c @@ -216,37 +216,51 @@ struct bt_iter_data { busy_iter_fn *fn; void *data; bool reserved; + bool inflight; }; static bool bt_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data) { struct bt_iter_data *iter_data = data; struct blk_mq_hw_ctx *hctx = iter_data->hctx; - struct blk_mq_tags *tags = hctx->tags; bool reserved = iter_data->reserved; + struct blk_mq_tags *tags; struct request *rq; + tags = hctx->sched_tags ? hctx->sched_tags : hctx->tags; + if (!reserved) bitnr += tags->nr_reserved_tags; - rq = tags->rqs[bitnr]; /* - * We can hit rq == NULL here, because the tagging functions - * test and set the bit before assining ->rqs[]. + * Because tags->rqs[] will not been cleaned when free driver tag + * and there is a window between get driver tag and write tags->rqs[], + * so we may see stale rq in tags->rqs[] which may have been freed. + * Using static_rqs[] is safer. */ - if (rq && rq->q == hctx->queue) + rq = tags->static_rqs[bitnr]; + + /* + * There is a small window between get tag and blk_mq_rq_ctx_init, + * so rq->q and rq->mq_hctx maybe different. + */ + if (rq && rq->q == hctx->queue && + (!iter_data->inflight || + blk_mq_rq_state(rq) == MQ_RQ_IN_FLIGHT)) iter_data->fn(hctx, rq, iter_data->data, reserved); return true; } -static void bt_for_each(struct blk_mq_hw_ctx *hctx, struct sbitmap_queue *bt, - busy_iter_fn *fn, void *data, bool reserved) +static void bt_for_each(struct blk_mq_hw_ctx *hctx, + struct sbitmap_queue *bt, busy_iter_fn *fn, + void *data, bool reserved, bool inflight) { struct bt_iter_data iter_data = { .hctx = hctx, .fn = fn, .data = data, .reserved = reserved, + .inflight = inflight, }; sbitmap_for_each_set(&bt->sb, bt_iter, &iter_data); @@ -314,22 +328,23 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set *tagset, } EXPORT_SYMBOL(blk_mq_tagset_busy_iter); -void blk_mq_queue_tag_busy_iter(struct request_queue *q, busy_iter_fn *fn, - void *priv) +static void __blk_mq_queue_tag_busy_iter(struct request_queue *q, + busy_iter_fn *fn, void *priv, bool inflight) { struct blk_mq_hw_ctx *hctx; int i; /* - * __blk_mq_update_nr_hw_queues will update the nr_hw_queues and - * queue_hw_ctx after freeze the queue, so we use q_usage_counter - * to avoid race with it. + * Get a reference of the queue unless it has been zero. We use this + * to avoid the race with the code that would modify the hctxs after + * freeze and drain the queue, including updating nr_hw_queues, io + * scheduler switching and queue clean up. */ if (!percpu_ref_tryget(&q->q_usage_counter)) return; queue_for_each_hw_ctx(q, hctx, i) { - struct blk_mq_tags *tags = hctx->tags; + struct blk_mq_tags *tags; /* * If not software queues are currently mapped to this @@ -338,13 +353,45 @@ void blk_mq_queue_tag_busy_iter(struct request_queue *q, busy_iter_fn *fn, if (!blk_mq_hw_queue_mapped(hctx)) continue; + tags = hctx->sched_tags ? hctx->sched_tags : hctx->tags; + if (tags->nr_reserved_tags) - bt_for_each(hctx, &tags->breserved_tags, fn, priv, true); - bt_for_each(hctx, &tags->bitmap_tags, fn, priv, false); + bt_for_each(hctx, &tags->breserved_tags, + fn, priv, true, inflight); + bt_for_each(hctx, &tags->bitmap_tags, + fn, priv, false, inflight); + /* + * flush_rq represents the rq with REQ_PREFLUSH and REQ_FUA + * (if FUA is not supported by device) to be issued to + * device. So we need to consider it when iterate inflight + * rqs, but needn't to count it when iterate busy tags. + */ + if (inflight && + blk_mq_rq_state(hctx->fq->flush_rq) == MQ_RQ_IN_FLIGHT) + fn(hctx, hctx->fq->flush_rq, priv, false); } blk_queue_exit(q); } +/* + * Iterate all the busy tags including pending and in-flight ones. + */ +void blk_mq_queue_tag_busy_iter(struct request_queue *q, busy_iter_fn *fn, + void *priv) +{ + __blk_mq_queue_tag_busy_iter(q, fn, priv, false); +} + +/* + * Iterate all the inflight tags. + */ +void blk_mq_queue_tag_inflight_iter(struct request_queue *q, + busy_iter_fn *fn, void *priv) +{ + __blk_mq_queue_tag_busy_iter(q, fn, priv, true); +} +EXPORT_SYMBOL(blk_mq_queue_tag_inflight_iter); + static int bt_alloc(struct sbitmap_queue *bt, unsigned int depth, bool round_robin, int node) { diff --git a/block/blk-mq.c b/block/blk-mq.c index 8a7c3d8..ee07575 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -112,7 +112,7 @@ void blk_mq_in_flight(struct request_queue *q, struct hd_struct *part, struct mq_inflight mi = { .part = part, .inflight = inflight, }; inflight[0] = inflight[1] = 0; - blk_mq_queue_tag_busy_iter(q, blk_mq_check_inflight, &mi); + blk_mq_queue_tag_inflight_iter(q, blk_mq_check_inflight, &mi); } static void blk_mq_check_inflight_rw(struct blk_mq_hw_ctx *hctx, @@ -131,7 +131,7 @@ void blk_mq_in_flight_rw(struct request_queue *q, struct hd_struct *part, struct mq_inflight mi = { .part = part, .inflight = inflight, }; inflight[0] = inflight[1] = 0; - blk_mq_queue_tag_busy_iter(q, blk_mq_check_inflight_rw, &mi); + blk_mq_queue_tag_inflight_iter(q, blk_mq_check_inflight_rw, &mi); } void blk_freeze_queue_start(struct request_queue *q) @@ -875,7 +875,7 @@ static void blk_mq_timeout_work(struct work_struct *work) if (!percpu_ref_tryget(&q->q_usage_counter)) return; - blk_mq_queue_tag_busy_iter(q, blk_mq_check_expired, &next); + blk_mq_queue_tag_inflight_iter(q, blk_mq_check_expired, &next); if (next != 0) { mod_timer(&q->timeout, next); diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h index 6578070..149d411 100644 --- a/include/linux/blk-mq.h +++ b/include/linux/blk-mq.h @@ -320,7 +320,8 @@ void blk_mq_tagset_busy_iter(struct blk_mq_tag_set *tagset, void blk_mq_freeze_queue_wait(struct request_queue *q); int blk_mq_freeze_queue_wait_timeout(struct request_queue *q, unsigned long timeout); - +void blk_mq_queue_tag_inflight_iter(struct request_queue *q, busy_iter_fn *fn, + void *priv); int blk_mq_map_queues(struct blk_mq_tag_set *set); void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues); -- 1.8.3

1 2

[PATCH] perf: Make perf able to build with latest libbfd
by Yang Yingliang 06 May '20

06 May '20

From: Changbin Du <changbin.du(a)gmail.com> mainline inclusion from mainline-5.6 commit 0ada120c883d4f1f6aafd01cf0fbb10d8bbba015 category: bugfix bugzilla: 34555 CVE: NA ------------------------------------------------- libbfd has changed the bfd_section_* macros to inline functions bfd_section_<field> since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: Changbin Du <changbin.du(a)gmail.com> Acked-by: Jiri Olsa <jolsa(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> Signed-off-by: Xie XiuQi <xiexiuqi(a)huawei.com> Reviewed-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- tools/perf/util/srcline.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c index af3f9b9..b8e7761 100644 --- a/tools/perf/util/srcline.c +++ b/tools/perf/util/srcline.c @@ -191,16 +191,30 @@ static void find_address_in_section(bfd *abfd, asection *section, void *data) bfd_vma pc, vma; bfd_size_type size; struct a2l_data *a2l = data; + flagword flags; if (a2l->found) return; - if ((bfd_get_section_flags(abfd, section) & SEC_ALLOC) == 0) +#ifdef bfd_get_section_flags + flags = bfd_get_section_flags(abfd, section); +#else + flags = bfd_section_flags(section); +#endif + if ((flags & SEC_ALLOC) == 0) return; pc = a2l->addr; +#ifdef bfd_get_section_vma vma = bfd_get_section_vma(abfd, section); +#else + vma = bfd_section_vma(section); +#endif +#ifdef bfd_get_section_size size = bfd_get_section_size(section); +#else + size = bfd_section_size(section); +#endif if (pc < vma || pc >= vma + size) return; -- 1.8.3

1 0

hello
by chenzy 30 Apr '20

30 Apr '20

subscribe linux-kernel

3 2

[PATCH] pcie_cae support getting chipnums of this system
by Yang Yingliang 28 Apr '20

28 Apr '20

From: Liu Yanshi <liuyanshi(a)huawei.com> driver inclusion category: feature bugzilla: NA CVE: NA pcie_cae add interface to get the chipnums of the current system. Signed-off-by: Liu Yanshi <liuyanshi(a)huawei.com> Reviewed-by: Zhu Xiongxiong <zhuxiongxiong(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- .../controller/hisi-pcie-customer/hisi_pcie_cae.c | 37 ++++++++++++++++++++-- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/drivers/pci/controller/hisi-pcie-customer/hisi_pcie_cae.c b/drivers/pci/controller/hisi-pcie-customer/hisi_pcie_cae.c index 8d0c801..6229a54 100644 --- a/drivers/pci/controller/hisi-pcie-customer/hisi_pcie_cae.c +++ b/drivers/pci/controller/hisi-pcie-customer/hisi_pcie_cae.c @@ -3,6 +3,7 @@ #include <linux/mm.h> #include <linux/miscdevice.h> +#include <linux/uaccess.h> #include <linux/device.h> #include <linux/module.h> #include <linux/io.h> @@ -21,6 +22,7 @@ #define CHIP_INFO_REG_SIZE 4 #define TYPE_SHIFT 4 #define BIT_SHIFT_8 8 +#define PCIE_CMD_GET_CHIPNUMS 0x01 #define DEVICE_NAME "pcie_reg_dev" @@ -37,7 +39,7 @@ enum { MMAP_TYPE_VIRTIO }; -static int current_chip_nums; +static u32 current_chip_nums; static const struct vm_operations_struct mmap_pcie_mem_ops = { #ifdef CONFIG_HAVE_IOREMAP_PROT @@ -100,10 +102,10 @@ static int pcie_reg_mmap(struct file *filep, struct vm_area_struct *vma) return 0; } -int pcie_get_chipnums(u32 cpu_info) +u32 pcie_get_chipnums(u32 cpu_info) { int i; - int chip_count = 0; + u32 chip_count = 0; u32 chip_i_info; for (i = 0; i < MAX_CHIP_NUM; i++) { @@ -144,12 +146,41 @@ static int pcie_release(struct inode *inode, struct file *f) return 0; } +static long pcie_reg_ioctl(struct file *pfile, unsigned int cmd, + unsigned long arg) +{ + int ret = 0; + + switch (cmd) { + case PCIE_CMD_GET_CHIPNUMS: + if ((void *)arg == NULL) { + pr_info("[PCIe Base] invalid arg address\n"); + ret = -EINVAL; + break; + } + + if (copy_to_user((void *)arg, (void *)&current_chip_nums, + sizeof(int))) { + pr_info("[PCIe Base] copy chip_nums to usr failed\n"); + ret = -EINVAL; + } + break; + + default: + pr_info("[PCIe Base] invalid pcie ioctl cmd:%u\n", cmd); + break; + } + + return ret; +} + static const struct file_operations pcie_dfx_fops = { .owner = THIS_MODULE, .open = pcie_open, .release = pcie_release, .llseek = noop_llseek, .mmap = pcie_reg_mmap, + .unlocked_ioctl = pcie_reg_ioctl, }; static struct miscdevice pcie_dfx_misc = { -- 1.8.3

1 0

[PATCH v2] net: hns3: remove the unnecessary ccflags
by Zhengyuan Liu 28 Apr '20

28 Apr '20

category: other bugzilla: NA CVE: NA ---------------------------------- The ccflags removed in this patch shouldn't be in open kernel tree. Especially for -fstack-protector-strong, there will be a compile error when CONFIG_STACKPROTECTOR_STRONG isn't enabled. Signed-off-by: Zhengyuan Liu <liuzhengyuan(a)tj.kylinos.cn> --- drivers/net/ethernet/hisilicon/hns3/Makefile | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile b/drivers/net/ethernet/hisilicon/hns3/Makefile index 6653e81..0365f1c 100644 --- a/drivers/net/ethernet/hisilicon/hns3/Makefile +++ b/drivers/net/ethernet/hisilicon/hns3/Makefile @@ -3,15 +3,6 @@ # Makefile for the HISILICON network device drivers. # -# Add security options -ccflags-y += -fstack-protector-strong -ccflags-y += -Wl,-z,relro,-z,now -ccflags-y += -Wl,-z,noexecstack -ccflags-y += -D_FORTIFY_SOURCE=2 -O2 -ccflags-y += -fvisibility=hidden -ccflags-y += -Wformat=2 -Wfloat-equal -ccflags-y += -fsigned-char - ccflags-y += -DCONFIG_IT_VALIDATION ccflags-y += -DCONFIG_HNS3_TEST -- 2.7.4

3 2

Re: [Infra] Re: [Community] 转发：gitee上已更新issue，请及时查收
by Fred Li 27 Apr '20

27 Apr '20

cc kernel(a)openeuler.org. Just for members who may not know, dwadm(a)pcl.ac.cn is from 鹏程实验室 and will help on issues related with VMs in 鹏程实验室。 On Sun, Apr 26, 2020 at 10:08 AM Xie XiuQi via Infra <infra(a)openeuler.org> wrote: > 感谢你的热心参与，我们正在和鹏程实验室的兄弟联合定位 > On 2020/4/25 13:30, Qichen Zhang wrote: > > > Qichen Zhang > 邮箱：17852657226(a)163.com > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&n…> > > 签名由网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail88> 定制 > > --------- 转发的邮件 --------- > 发件人： Qichen Zhang <17852657226(a)163.com> > 发送日期： 2020年04月25日 13:26 > 收件人： Xiehong (Cynthia) <xiehong(a)huawei.com> > 抄送人： > 主题：回复：gitee上已更新issue，请及时查收 > 各位工程师 > 你们好! > > bug依然存在，还是报Message > kernel watchdog Bug soft lockup > 在issue上已发布，昨晚上七点多一直等到今天凌晨一点，依然存在bug。 > > 请各位工程师看看如何解决? > 上周五发现的这个bug，不能这么愣着啊 > 你们需要我做什么，阔以直接给我说哈， > 我叫张琦琛，手机号同微信号17852657226 > 希望大家一起努力尽快解决这个bug > > 盼回复 > > > Qichen Zhang > 邮箱：17852657226(a)163.com > > <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&n…> > > 签名由网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail88> 定制 > > 在2020年04月21日 14:17，Xiehong (Cynthia) <xiehong(a)huawei.com> 写道： > > HI > > > > 多谢！ > > > > 我们会在社区上的ISSUE系统上继续跟踪。 > > > > > > *发件人:* Qichen Zhang [mailto:17852657226@163.com] > *发送时间:* 2020年4月21日 13:27 > *收件人:* Xiehong (Cynthia) <xiehong(a)huawei.com> > *主题:* gitee上已更新issue，请及时查收 > > > > 尊敬的工程师 > > 您好！ > > > > 我已在 gitee 上已更新issue，请及时查收 > > https://gitee.com/openeuler/community/issues/I1F13I?from=project-issue > > 很乐意和大家一块解决这个bug。 > > — — > > Qichen Zhang > > > _______________________________________________ > Community mailing list -- community(a)openeuler.org > To unsubscribe send an email to community-leave(a)openeuler.org > > _______________________________________________ > Infra mailing list -- infra(a)openeuler.org > To unsubscribe send an email to infra-leave(a)openeuler.org > -- Regards Fred Li (李永乐)

1 0

2024

2023

2022

2021

2020

2019

Kernel