- Linux-stable-mirror - lists.linaro.org

[PATCH AUTOSEL 4.9 01/17] bfs: add sanity check at bfs_fill_super()

by Sasha Levin

From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> [ Upstream commit 9f2df09a33aa2c76ce6385d382693f98d7f2f07e ] syzbot is reporting too large memory allocation at bfs_fill_super() [1]. Since file system image is corrupted such that bfs_sb->s_start == 0, bfs_fill_super() is trying to allocate 8MB of continuous memory. Fix this by adding a sanity check on bfs_sb->s_start, __GFP_NOWARN and printf(). [1] https://syzkaller.appspot.com/bug?id=16a87c236b951351374a84c8a32f40edbc034e… Link: http://lkml.kernel.org/r/1525862104-3407-1-git-send-email-penguin-kernel@I-… Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+71c6b5d68e91149fc8a4(a)syzkaller.appspotmail.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Tigran Aivazian <aivazian.tigran(a)gmail.com> Cc: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/bfs/inode.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c index 1e5c896f6b79..0acb83efedea 100644 --- a/fs/bfs/inode.c +++ b/fs/bfs/inode.c @@ -350,7 +350,8 @@ static int bfs_fill_super(struct super_block *s, void *data, int silent) s->s_magic = BFS_MAGIC; - if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end)) { + if (le32_to_cpu(bfs_sb->s_start) > le32_to_cpu(bfs_sb->s_end) || + le32_to_cpu(bfs_sb->s_start) < BFS_BSIZE) { printf("Superblock is corrupted\n"); goto out1; } @@ -359,9 +360,11 @@ static int bfs_fill_super(struct super_block *s, void *data, int silent) sizeof(struct bfs_inode) + BFS_ROOT_INO - 1; imap_len = (info->si_lasti / 8) + 1; - info->si_imap = kzalloc(imap_len, GFP_KERNEL); - if (!info->si_imap) + info->si_imap = kzalloc(imap_len, GFP_KERNEL | __GFP_NOWARN); + if (!info->si_imap) { + printf("Cannot allocate %u bytes\n", imap_len); goto out1; + } for (i = 0; i < BFS_ROOT_INO; i++) set_bit(i, info->si_imap); -- 2.17.1

7 years, 1 month

3
19
0 0

v4.19.3 build: 0 failures 4 warnings (v4.19.3)

by Build bot for Mark Brown

Tree/Branch: v4.19.3 Git describe: v4.19.3 Commit: 73aa1c86c6 Linux 4.19.3 Build Time: 124 min 23 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 4 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : x86_64-allmodconfig 1 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-multi_v5_defconfig 1 warnings 0 mismatches : x86_64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 4 2 ../drivers/gpu/drm/i915/i915_gem_gtt.c:1771:41: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=] 1 ../drivers/staging/erofs/unzip_vle.c:186:29: warning: array subscript is above array bounds [-Warray-bounds] 1 ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/i2c/busses/i2c-aspeed.c:567:1: warning: label 'out' defined but not used [-Wunused-label] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpu/drm/i915/i915_gem_gtt.c:1771:41: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=] ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/staging/erofs/unzip_vle.c:186:29: warning: array subscript is above array bounds [-Warray-bounds] ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/i2c/busses/i2c-aspeed.c:567:1: warning: label 'out' defined but not used [-Wunused-label] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/gpu/drm/i915/i915_gem_gtt.c:1771:41: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v7_defconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig

7 years, 1 month

1
0
0 0

[PATCH for v4.4] Revert "media: videobuf2-core: don't call memop 'finish' when queueing"

by Hans Verkuil

This reverts commit 46431d9c28f6859f8e568ac7db92137f1da31100. This commit fixes a bug in upstream commit a136f59c0a1f ("vb2: Move buffer cache synchronisation to prepare from queue") which isn't present in 4.4. So as a result you get an UNBALANCED message in the kernel log if this patch is applied: vb2: counters for queue ffffffc0f3687478, buffer 3: UNBALANCED! vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805 vb2: buf_queue: 806 buf_done: 806 vb2: alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0 vb2: get_userptr: 0 put_userptr: 0 vb2: attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805 vb2: get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805 Reverting this patch solves this regression. Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com> --- Probably two reasons why this slipped through: 1) The patch was missing a Fixes: tag 2) I was probably CC-ed about this when it was about to be added to 4.9 but didn't realize that that was wrong. --- drivers/media/v4l2-core/videobuf2-core.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 1c37d5a..8ce9c63 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -870,12 +870,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state) dprintk(4, "done processing on buffer %d, state: %d\n", vb->index, state); - if (state != VB2_BUF_STATE_QUEUED && - state != VB2_BUF_STATE_REQUEUEING) { - /* sync buffers */ - for (plane = 0; plane < vb->num_planes; ++plane) - call_void_memop(vb, finish, vb->planes[plane].mem_priv); - } + /* sync buffers */ + for (plane = 0; plane < vb->num_planes; ++plane) + call_void_memop(vb, finish, vb->planes[plane].mem_priv); spin_lock_irqsave(&q->done_lock, flags); if (state == VB2_BUF_STATE_QUEUED || -- 2.10.2

7 years, 1 month

1
0
0 0

stable/linux-3.18.y boot: 46 boots: 3 failed, 43 passed (v3.18.126)

by kernelci.org bot

stable/linux-3.18.y boot: 46 boots: 3 failed, 43 passed (v3.18.126) Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-3.18.y/kernel/v3.18.1… Full Build Summary: https://kernelci.org/build/stable/branch/linux-3.18.y/kernel/v3.18.126/ Tree: stable Branch: linux-3.18.y Git Describe: v3.18.126 Git Commit: 1ed089625825edd4e98c3b84d935dfcdcb93c9c9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 22 unique boards, 12 SoC families, 14 builds out of 185 Boot Failures Detected: x86: x86_64_defconfig qemu: 2 failed labs x86-atom330: 1 failed lab --- For more info write to <info(a)kernelci.org>

7 years, 1 month

1
0
0 0

stable-rc/linux-3.18.y boot: 46 boots: 3 failed, 43 passed (v3.18.126)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 46 boots: 3 failed, 43 passed (v3.18.126) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.126/ Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.126 Git Commit: 1ed089625825edd4e98c3b84d935dfcdcb93c9c9 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 22 unique boards, 12 SoC families, 14 builds out of 185 Boot Failures Detected: x86: x86_64_defconfig qemu: 2 failed labs x86-atom330: 1 failed lab --- For more info write to <info(a)kernelci.org>

7 years, 1 month

1
0
0 0

THE RE-BUILD IRAQ PROJECT

by Dr. Rahman Mahmoud

Salaam Aleikum, The economy of Iraq has been devastated by the recent war, now that the war is winding down the emphasis in Iraq has turned to rebuilding a viable, vibrant economy, in this light the Iraq Reconstruction Management Office (IRMO) have been saddled with a renewed mandate from the Iraqi government to solicit, evaluate and recommend companies/individuals to work as partners in "THE RE-BUILD IRAQ PROJECT ". The launch of ongoing sourcing and bulk supply strategies has opened up new streams of public sector supply opportunities, as your company/individual has been shortlisted for this purpose and to participate " This project entails supplying various items for the Humanitarian Aid & Reconstruction Projects scheduled for all Provinces in the whole of Iraq.Please note given the current exigent circumstances in Iraq, the (IRMO) are currently accepting quotes to the port of Aquaba, Jordan from foreign contractors and Adhoc disbursement centers are now been utilized to expedite payments to contractors through our European payment centers.. Please kindly confirm your willingness to partake in this bulk supplies and contracting program under this new initiative "THE RE-BUILD IRAQ PROJECT ". Note confirmation should be strictly by our email as written below, in order to allow us send detailed procedures and the accompanying Iraq Reconstruction Management Office (IRMO) questionnaire will be sent promptly. Thank you for your co-operation. Yours Faithfully, Dr. Rahman Mahmoud Email: drrahmanmahm(a)gmail.com

7 years, 1 month

1
0
0 0

[tip:perf/urgent] perf/x86/intel: Disallow precise_ip on BTS events

by tip-bot for Jiri Olsa

Commit-ID: 472de49fdc53365c880ab81ae2b5cfdd83db0b06 Gitweb: https://git.kernel.org/tip/472de49fdc53365c880ab81ae2b5cfdd83db0b06 Author: Jiri Olsa <jolsa(a)kernel.org> AuthorDate: Wed, 21 Nov 2018 11:16:12 +0100 Committer: Ingo Molnar <mingo(a)kernel.org> CommitDate: Thu, 22 Nov 2018 09:45:10 +0100 perf/x86/intel: Disallow precise_ip on BTS events Vince reported a crash in the BTS flush code when touching the callchain data, which was supposed to be initialized as an 'early' callchain, but intel_pmu_drain_bts_buffer() does not do that: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 ... Call Trace: <IRQ> intel_pmu_drain_bts_buffer+0x151/0x220 ? intel_get_event_constraints+0x219/0x360 ? perf_assign_events+0xe2/0x2a0 ? select_idle_sibling+0x22/0x3a0 ? __update_load_avg_se+0x1ec/0x270 ? enqueue_task_fair+0x377/0xdd0 ? cpumask_next_and+0x19/0x20 ? load_balance+0x134/0x950 ? check_preempt_curr+0x7a/0x90 ? ttwu_do_wakeup+0x19/0x140 x86_pmu_stop+0x3b/0x90 x86_pmu_del+0x57/0x160 event_sched_out.isra.106+0x81/0x170 group_sched_out.part.108+0x51/0xc0 __perf_event_disable+0x7f/0x160 event_function+0x8c/0xd0 remote_function+0x3c/0x50 flush_smp_call_function_queue+0x35/0xe0 smp_call_function_single_interrupt+0x3a/0xd0 call_function_single_interrupt+0xf/0x20 </IRQ> It was triggered by fuzzer but can be easily reproduced by: # perf record -e cpu/branch-instructions/pu -g -c 1 Peter suggested not to allow branch tracing for precise events: > Now arguably, this is really stupid behaviour. Who in his right mind > wants callchain output on BTS entries. And even if they do, BTS + > precise_ip is nonsensical. > > So in my mind disallowing precise_ip on BTS would be the simplest fix. Suggested-by: Peter Zijlstra <peterz(a)infradead.org> Reported-by: Vince Weaver <vincent.weaver(a)maine.edu> Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Cc: <stable(a)vger.kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Fixes: 6cbc304f2f36 ("perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)") Link: http://lkml.kernel.org/r/20181121101612.16272-3-jolsa@kernel.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> --- arch/x86/events/intel/core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index a15a73788693..ecc3e34ca955 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -3106,6 +3106,10 @@ static int intel_pmu_bts_config(struct perf_event *event) if (!attr->exclude_kernel) return -EOPNOTSUPP; + /* BTS is not allowed for precise events. */ + if (attr->precise_ip) + return -EOPNOTSUPP; + /* disallow bts if conflicting events are present */ if (x86_add_exclusive(x86_lbr_exclusive_lbr)) return -EBUSY;

7 years, 1 month

1
0
0 0

[tip:perf/urgent] perf/x86/intel: Add generic branch tracing check to intel_pmu_has_bts()

by tip-bot for Jiri Olsa

Commit-ID: 67266c1080ad56c31af72b9c18355fde8ccc124a Gitweb: https://git.kernel.org/tip/67266c1080ad56c31af72b9c18355fde8ccc124a Author: Jiri Olsa <jolsa(a)kernel.org> AuthorDate: Wed, 21 Nov 2018 11:16:11 +0100 Committer: Ingo Molnar <mingo(a)kernel.org> CommitDate: Thu, 22 Nov 2018 09:45:09 +0100 perf/x86/intel: Add generic branch tracing check to intel_pmu_has_bts() Currently we check the branch tracing only by checking for the PERF_COUNT_HW_BRANCH_INSTRUCTIONS event of PERF_TYPE_HARDWARE type. But we can define the same event with the PERF_TYPE_RAW type. Changing the intel_pmu_has_bts() code to check on event's final hw config value, so both HW types are covered. Adding unlikely to intel_pmu_has_bts() condition calls, because it was used in the original code in intel_bts_constraints. Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Cc: <stable(a)vger.kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Link: http://lkml.kernel.org/r/20181121101612.16272-2-jolsa@kernel.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> --- arch/x86/events/intel/core.c | 17 +++-------------- arch/x86/events/perf_event.h | 13 +++++++++---- 2 files changed, 12 insertions(+), 18 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index a95079abeb03..a15a73788693 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -2474,16 +2474,7 @@ done: static struct event_constraint * intel_bts_constraints(struct perf_event *event) { - struct hw_perf_event *hwc = &event->hw; - unsigned int hw_event, bts_event; - - if (event->attr.freq) - return NULL; - - hw_event = hwc->config & INTEL_ARCH_EVENT_MASK; - bts_event = x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS); - - if (unlikely(hw_event == bts_event && hwc->sample_period == 1)) + if (unlikely(intel_pmu_has_bts(event))) return &bts_constraint; return NULL; @@ -3105,10 +3096,8 @@ static unsigned long intel_pmu_large_pebs_flags(struct perf_event *event) static int intel_pmu_bts_config(struct perf_event *event) { struct perf_event_attr *attr = &event->attr; - struct hw_perf_event *hwc = &event->hw; - if (attr->config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS && - !attr->freq && hwc->sample_period == 1) { + if (unlikely(intel_pmu_has_bts(event))) { /* BTS is not supported by this architecture. */ if (!x86_pmu.bts_active) return -EOPNOTSUPP; @@ -3170,7 +3159,7 @@ static int intel_pmu_hw_config(struct perf_event *event) /* * BTS is set up earlier in this path, so don't account twice */ - if (!intel_pmu_has_bts(event)) { + if (!unlikely(intel_pmu_has_bts(event))) { /* disallow lbr if conflicting events are present */ if (x86_add_exclusive(x86_lbr_exclusive_lbr)) return -EBUSY; diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h index adae087cecdd..78d7b7031bfc 100644 --- a/arch/x86/events/perf_event.h +++ b/arch/x86/events/perf_event.h @@ -859,11 +859,16 @@ static inline int amd_pmu_init(void) static inline bool intel_pmu_has_bts(struct perf_event *event) { - if (event->attr.config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS && - !event->attr.freq && event->hw.sample_period == 1) - return true; + struct hw_perf_event *hwc = &event->hw; + unsigned int hw_event, bts_event; + + if (event->attr.freq) + return false; + + hw_event = hwc->config & INTEL_ARCH_EVENT_MASK; + bts_event = x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS); - return false; + return hw_event == bts_event && hwc->sample_period == 1; } int intel_pmu_save_and_restart(struct perf_event *event);

7 years, 1 month

1
0
0 0

[tip:perf/urgent] perf/x86/intel: Move branch tracing setup to the Intel-specific source file

by tip-bot for Jiri Olsa

Commit-ID: ed6101bbf6266ee83e620b19faa7c6ad56bb41ab Gitweb: https://git.kernel.org/tip/ed6101bbf6266ee83e620b19faa7c6ad56bb41ab Author: Jiri Olsa <jolsa(a)kernel.org> AuthorDate: Wed, 21 Nov 2018 11:16:10 +0100 Committer: Ingo Molnar <mingo(a)kernel.org> CommitDate: Thu, 22 Nov 2018 09:45:09 +0100 perf/x86/intel: Move branch tracing setup to the Intel-specific source file Moving branch tracing setup to Intel core object into separate intel_pmu_bts_config function, because it's Intel specific. Suggested-by: Peter Zijlstra <peterz(a)infradead.org> Signed-off-by: Jiri Olsa <jolsa(a)kernel.org> Acked-by: Peter Zijlstra <a.p.zijlstra(a)chello.nl> Cc: <stable(a)vger.kernel.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Stephane Eranian <eranian(a)google.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Link: http://lkml.kernel.org/r/20181121101612.16272-1-jolsa@kernel.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> --- arch/x86/events/core.c | 20 -------------------- arch/x86/events/intel/core.c | 41 ++++++++++++++++++++++++++++++++++++++++- 2 files changed, 40 insertions(+), 21 deletions(-) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 106911b603bd..374a19712e20 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -438,26 +438,6 @@ int x86_setup_perfctr(struct perf_event *event) if (config == -1LL) return -EINVAL; - /* - * Branch tracing: - */ - if (attr->config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS && - !attr->freq && hwc->sample_period == 1) { - /* BTS is not supported by this architecture. */ - if (!x86_pmu.bts_active) - return -EOPNOTSUPP; - - /* BTS is currently only allowed for user-mode. */ - if (!attr->exclude_kernel) - return -EOPNOTSUPP; - - /* disallow bts if conflicting events are present */ - if (x86_add_exclusive(x86_lbr_exclusive_lbr)) - return -EBUSY; - - event->destroy = hw_perf_lbr_event_destroy; - } - hwc->config |= config; return 0; diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index af8bea9d4006..a95079abeb03 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -3102,10 +3102,49 @@ static unsigned long intel_pmu_large_pebs_flags(struct perf_event *event) return flags; } +static int intel_pmu_bts_config(struct perf_event *event) +{ + struct perf_event_attr *attr = &event->attr; + struct hw_perf_event *hwc = &event->hw; + + if (attr->config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS && + !attr->freq && hwc->sample_period == 1) { + /* BTS is not supported by this architecture. */ + if (!x86_pmu.bts_active) + return -EOPNOTSUPP; + + /* BTS is currently only allowed for user-mode. */ + if (!attr->exclude_kernel) + return -EOPNOTSUPP; + + /* disallow bts if conflicting events are present */ + if (x86_add_exclusive(x86_lbr_exclusive_lbr)) + return -EBUSY; + + event->destroy = hw_perf_lbr_event_destroy; + } + + return 0; +} + +static int core_pmu_hw_config(struct perf_event *event) +{ + int ret = x86_pmu_hw_config(event); + + if (ret) + return ret; + + return intel_pmu_bts_config(event); +} + static int intel_pmu_hw_config(struct perf_event *event) { int ret = x86_pmu_hw_config(event); + if (ret) + return ret; + + ret = intel_pmu_bts_config(event); if (ret) return ret; @@ -3600,7 +3639,7 @@ static __initconst const struct x86_pmu core_pmu = { .enable_all = core_pmu_enable_all, .enable = core_pmu_enable_event, .disable = x86_pmu_disable_event, - .hw_config = x86_pmu_hw_config, + .hw_config = core_pmu_hw_config, .schedule_events = x86_schedule_events, .eventsel = MSR_ARCH_PERFMON_EVENTSEL0, .perfctr = MSR_ARCH_PERFMON_PERFCTR0,

7 years, 1 month

1
0
0 0

Re: [PATCH] kmemleak: Turn kmemleak_lock to raw spinlock on RT

by He Zhe

On 2018/11/15 02:09, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v4.19.1, v4.18.18, v4.14.80, v4.9.136, v4.4.163, v3.18.125. > > v4.19.1: Build OK! > v4.18.18: Build OK! > v4.14.80: Build OK! > v4.9.136: Build OK! > v4.4.163: Build OK! > v3.18.125: Failed to apply! Possible dependencies: > Unable to calculate This is only for RT patchset. Sorry for adding stable tag. I'll send v2. Zhe > > > -- > Thanks, > Sasha >

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror