Re: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
On Fri, 2015-02-27 at 11:53 +, Mel Gorman wrote:
> On Fri, Feb 27, 2015 at 03:21:36PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone fields
> > into read-only, page alloc, statistics and page reclaim lines")
> >
> > The perf cpu-cycles for spinlock (zone->lock) increased a lot. I suspect
> > there are some cache ping-pong or false sharing.
> >
>
> Annoying because this is pretty much the opposite of what I found during
> testing. What is the kernel config? Similar to the kernel config, can you
> post "pahole -C zone vmlinux" for the kernel you built? I should get the same
> result if I use the same kernel config but no harm in being sure. Thanks.
The output of pahole -C zone vmlinux for the kernels are as below.
Best Regards,
Huang, Ying
3484b2de94
---
struct zone {
long unsigned int watermark[3]; /* 024 */
long int lowmem_reserve[4];/*2432 */
intnode; /*56 4 */
unsigned int inactive_ratio; /*60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
struct pglist_data * zone_pgdat; /*64 8 */
struct per_cpu_pageset * pageset; /*72 8 */
long unsigned int dirty_balance_reserve; /*80 8 */
long unsigned int min_unmapped_pages; /*88 8 */
long unsigned int min_slab_pages; /*96 8 */
long unsigned int zone_start_pfn; /* 104 8 */
long unsigned int managed_pages;/* 112 8 */
long unsigned int spanned_pages;/* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
long unsigned int present_pages;/* 128 8 */
const char * name; /* 136 8 */
intnr_migrate_reserve_block; /* 144 4 */
seqlock_t span_seqlock; /* 148 8 */
/* XXX 4 bytes hole, try to pack */
wait_queue_head_t *wait_table; /* 160 8 */
long unsigned int wait_table_hash_nr_entries; /* 168 8 */
long unsigned int wait_table_bits; /* 176 8 */
/* XXX 8 bytes hole, try to pack */
/* --- cacheline 3 boundary (192 bytes) --- */
struct zone_padding_pad1_; /* 192 0 */
spinlock_t lock; /* 192 4 */
/* XXX 4 bytes hole, try to pack */
struct free_area free_area[11];/* 200 968 */
/* --- cacheline 18 boundary (1152 bytes) was 16 bytes ago --- */
long unsigned int flags;/* 1168 8 */
/* XXX 40 bytes hole, try to pack */
/* --- cacheline 19 boundary (1216 bytes) --- */
struct zone_padding_pad2_; /* 1216 0 */
spinlock_t lru_lock; /* 1216 4 */
/* XXX 4 bytes hole, try to pack */
long unsigned int pages_scanned;/* 1224 8 */
struct lruvec lruvec; /* 1232 120 */
/* --- cacheline 21 boundary (1344 bytes) was 8 bytes ago --- */
atomic_long_t inactive_age; /* 1352 8 */
long unsigned int percpu_drift_mark;/* 1360 8 */
long unsigned int compact_cached_free_pfn; /* 1368 8 */
long unsigned int compact_cached_migrate_pfn[2]; /* 1376
16 */
unsigned int compact_considered; /* 1392 4 */
unsigned int compact_defer_shift; /* 1396 4 */
intcompact_order_failed; /* 1400 4 */
bool compact_blockskip_flush; /* 1404 1 */
/* XXX 3 bytes hole, try to pack */
/* --- cacheline 22 boundary (1408 bytes) --- */
struct zone_padding_pad3_; /* 1408 0 */
atomic_long_t vm_stat[38]; /* 1408 304 */
/* --- cacheline 26 boundary (1664 bytes) was 48 bytes ago --- */
/* size: 1728, cachelines: 27, members: 37 */
/* sum members: 1649, holes: 6, sum holes: 63 */
/* padding: 16 */
};
24b7e5819a
---
struct zone {
long unsigned int watermark[3]; /* 024 */
long unsigned int percpu_drift_mark;/*24 8 */
long unsigned
Re: [STLinux Kernel] [PATCH 3/4] clk: Provide always-on clock support
Hi Lee, On 02/27/2015 10:14 PM, Lee Jones wrote: Lots of platforms contain clocks which if turned off would prove fatal. The only way to recover from these catastrophic failures is to restart the board(s). Now, when a clock is registered with the framework it is compared against a list of provided always-on clock names which must be kept ungated. If it matches, we enable the existing CLK_IGNORE_UNUSED flag, which will prevent the common clk framework from attempting to gate it during the clk_disable_unused() procedure. Please correct me if I'm wrong, but your patch does not fix the issue you had initially. Let's take an example: A clock is critical for the system, and should never be gated, so you add the CLK_IGNORE_UNUSED flag so that it is not disabled by clk_disable_unused() procedure. The same clock is also used by other IPs, for example spi 0 instance. When starting a spi transfer, clk_enable() is called on this clock, so its usecount becomes 1. Once transfer done, clk_disable() is called, usecount becomes 0 and the clock gets disabled: system freeze. BR, Maxime -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Fix pthread_attr_setaffinity_np() feature detection on Ubuntu systems
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 0afb1704010f60e7ae85aef0f93fc10f2d99761e: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2015-02-26 12:25:20 +0100) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo > > for you to fetch changes up to fefd2d9619de3bf0bf02a8622e9f445c3d19cc3f: > > perf report: Fix branch stack mode cannot be set (2015-02-27 15:52:42 -0300) > > > perf/core improvements and fixes: > > User visible: > > - Fix SIGBUS failures due to misaligned accesses in Sparc64 (David Ahern) > > - Fix branch stack mode in 'perf report' (He Kuang) > > - Fix a 'perf probe' operator precedence bug (He Kuang) > > - Fix Support for different binaries with same name in 'perf diff' (Kan Liang) > > - Check kprobes blacklist when adding new events via 'perf probe' (Masami > Hiramatsu) > > - Add --purge FILE to remove all caches of FILE in 'perf buildid-cache' > (Masami Hiramatsu) > > - Show usage with some incorrect params (Masami Hiramatsu) > > - Add new buildid cache if update target is not cached in 'buildid-cache' > (Masami Hiramatsu) > > - Allow listing events with 'tracepoint' prefix in 'perf list' (Yunlong Song) > > - Sort the output of 'perf list' (Yunlong Song) > > - Fix bash completion of 'perf --' (Yunlong Song) > > Developer Zone: > > - Handle strdup() failure path in 'perf probe' (Arnaldo Carvalho de Melo) > > - Fix get_real_path to free allocated memory in error path in 'perf probe' > (Masami Hiramatsu) > > - Use pr_debug instead of verbose && pr_info perf buildid-cache (Masami > Hiramatsu) > > - Fix building of 'perf data' with some gcc versions due to incorrect array > struct > entry (Yunlong Song) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (1): > perf probe: Handle strdup() failure > > David Ahern (1): > perf trace: Fix SIGBUS failures due to misaligned accesses > > He Kuang (2): > perf probe: Fix a precedence bug > perf report: Fix branch stack mode cannot be set > > Kan Liang (1): > perf diff: Support for different binaries > > Masami Hiramatsu (6): > perf probe: Check kprobes blacklist when adding new events > perf probe: Fix get_real_path to free allocated memory in error path > perf buildid-cache: Add new buildid cache if update target is not cached > perf buildid-cache: Add --purge FILE to remove all caches of FILE > perf buildid-cache: Use pr_debug instead of verbose && pr_info > perf buildid-cache: Show usage with incorrect params > > Yunlong Song (8): > perf data: Fix sentinel setting for data_cmds array > perf list: Sort the output of 'perf list' to view more clearly > perf list: Allow listing events with 'tracepoint' prefix > perf list: Avoid confusion of perf output and the next command prompt > perf tools: Remove the '--(null)' long_name for --list-opts > perf list: Clean up the printing functions of hardware/software events > perf list: Extend raw-dump to certain kind of events > perf tools: Fix the bash completion problem of 'perf --*' > > tools/perf/Documentation/perf-buildid-cache.txt | 24 ++- > tools/perf/Documentation/perf-diff.txt | 5 + > tools/perf/Documentation/perf-list.txt | 6 + > tools/perf/builtin-buildid-cache.c | 72 ++-- > tools/perf/builtin-data.c | 2 +- > tools/perf/builtin-list.c | 27 ++- > tools/perf/builtin-report.c | 2 +- > tools/perf/builtin-trace.c | 36 +++- > tools/perf/perf-completion.sh | 6 +- > tools/perf/perf.c | 28 > tools/perf/util/build-id.c | 105 ++-- > tools/perf/util/build-id.h | 4 + > tools/perf/util/parse-events.c | 210 > +--- > tools/perf/util/parse-events.h | 11 +- > tools/perf/util/parse-options.c | 5 +- > tools/perf/util/probe-event.c | 117 - > tools/perf/util/sort.c | 9 + > 17 files changed, 542 insertions(+), 127 deletions(-) Pulled, but let me rant a bit: recent changes to perf bench broke the build on an Ubuntu image I have: CC bench/futex-hash.o In file included from bench/futex-hash.c:17:0: bench/futex.h:73:19: error: conflicting types for ‘pthread_attr_setaffinity_np’ static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr, ^ In file
Re: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
On Sat, 2015-02-28 at 01:46 +, Mel Gorman wrote:
> On Fri, Feb 27, 2015 at 03:21:36PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone fields
> > into read-only, page alloc, statistics and page reclaim lines")
> >
> > The perf cpu-cycles for spinlock (zone->lock) increased a lot. I suspect
> > there are some cache ping-pong or false sharing.
> >
>
> Are you sure about this result? I ran similar tests here and found that
> there was a major regression introduced near there but it was commit
> 05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter") that
> cause the problem and it was later reverted. On local tests on a 4-node
> machine, commit 3484b2de9499df23c4604a513b36f96326ae81ad was within 1%
> of the previous commit and well within the noise.
After applying the below debug patch, the performance regression
restored. So I think we can root cause this regression to be cache line
alignment related issue?
If my understanding were correct, after the 3484b2de94, lock and low
address area free_area are in the same cache line, so that the cache
line of the lock and the low address area of free_area will be switched
between MESI "E" and "S" state because it is written in one CPU (page
allocating with free_area) and frequently read (spinning on lock) in
another CPU.
Best Regards,
Huang, Ying
---
include/linux/mmzone.h |2 ++
1 file changed, 2 insertions(+)
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -468,6 +468,8 @@ struct zone {
/* Write-intensive fields used from the page allocator */
spinlock_t lock;
+ ZONE_PADDING(_pad_xx_)
+
/* free areas of different sizes */
struct free_areafree_area[MAX_ORDER];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi: spidev_test: Added functionalities
On Fri, Feb 27, 2015 at 03:11:17PM -0700, Jonathan Corbet wrote: > (Meanwhile, I've applied this one). Sorry, I shoud've been clearer that my previous mail was intended as a nack for the patch as submitted - I'd expected SPI documentation/test code updates to be going via the SPI tree. signature.asc Description: Digital signature
Re: Generic page fault (Was: libsigsegv ....)
On Sat, 2015-02-28 at 18:12 +1100, Benjamin Herrenschmidt wrote: > > Let me know what you think of the approach. It's boot tested on x86_64 > in qemu and ... and powerpc64 LE on qemu as well :-) Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Generic page fault (Was: libsigsegv ....)
On Sun, 2015-02-01 at 17:09 -0800, Linus Torvalds wrote:
>
> Of course, what I *really* want would be to make a new
> "generic_mm_fault()" helper that would do all the normal stuff:
>
> - find_vma()
> - check permissions and ranges
> - call 'handle_mm_fault()'
> - do the proper error, retry and minor/major fault handling
>
> and then most architectures could just call that.
So I spent a bit of time today while the kids were playing quietly (it
does happen !), and came up with this (very) draft pair of patches
for x86 and powerpc. It's by no mean a finished product as you can see,
but it shows how "messy" things get. Basically a bit more messy than I
originally thought but it's not *too* bad either.
Let me know what you think of the approach. It's boot tested on x86_64
in qemu and .
Next I think I'll tackle ARM, test a bit more, clean a few things up and
submit, but by all means, please provide feedback on the approach before
that :)
I'm attaching the patches for now (there are two and I don't feel like
posting two emails on that subject. The final stuff will be broken down
in smaller bits).
Cheers,
Ben.
From 1e3060ecdb479a3dfd587a5870e0351e0b1b5ddc Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt
Date: Sat, 28 Feb 2015 17:38:17 +1100
Subject: [PATCH 1/2] Move bulk of x86 __do_page_fault() to a
generic_page_fault()
(Add add various hooks that other archs will need etc...)
Signed-off-by: Benjamin Herrenschmidt
---
arch/x86/include/asm/fault.h | 99 +
arch/x86/mm/fault.c | 253 +++
include/linux/fault.h| 11 ++
mm/Makefile | 2 +-
mm/fault.c | 171 +
5 files changed, 296 insertions(+), 240 deletions(-)
create mode 100644 arch/x86/include/asm/fault.h
create mode 100644 include/linux/fault.h
create mode 100644 mm/fault.c
diff --git a/arch/x86/include/asm/fault.h b/arch/x86/include/asm/fault.h
new file mode 100644
index 000..7c1712e1
--- /dev/null
+++ b/arch/x86/include/asm/fault.h
@@ -0,0 +1,99 @@
+#ifndef _ASM_X86_FAULT_H
+#define _ASM_X86_FAULT_H
+
+#include
+#include
+
+/*
+ * Page fault error code bits:
+ *
+ * bit 0 == 0: no page found 1: protection fault
+ * bit 1 == 0: read access 1: write access
+ * bit 2 == 0: kernel-mode access 1: user-mode access
+ * bit 3 ==1: use of reserved bit detected
+ * bit 4 ==1: fault was an instruction fetch
+ */
+enum x86_pf_error_code {
+
+ PF_PROT = 1 << 0,
+ PF_WRITE = 1 << 1,
+ PF_USER = 1 << 2,
+ PF_RSVD = 1 << 3,
+ PF_INSTR = 1 << 4,
+};
+
+static inline bool fault_is_user(struct pt_regs *regs, unsigned long err_code)
+{
+ return err_code & PF_USER;
+}
+
+static inline bool fault_is_write(struct pt_regs *regs, unsigned long err_code)
+{
+ return err_code & PF_WRITE;
+}
+
+/* Return type for do_page_fault */
+typedef void gpf_ret_t;
+
+#define FAULT_NO_ERR
+
+/* Check if the stack is allowed to grow during a user page fault */
+static inline bool stack_can_grow(struct pt_regs *regs, unsigned long err_code,
+ unsigned long address,
+ struct vm_area_struct *vma)
+{
+ /*
+ * Accessing the stack below %sp is always a bug.
+ * The large cushion allows instructions like enter
+ * and pusha to work. ("enter $65535, $31" pushes
+ * 32 pointers and then decrements %sp by 65535.)
+ */
+ return address + 65536 + 32 * sizeof(unsigned long) >= regs->sp;
+}
+
+/* Access validity check */
+static inline bool access_error(struct pt_regs *regs, unsigned long err_code,
+struct vm_area_struct *vma)
+{
+ if (err_code & PF_WRITE) {
+ /* write, present and write, not present: */
+ if (unlikely(!(vma->vm_flags & VM_WRITE)))
+ return true;
+ return false;
+ }
+
+ /* read, present: */
+ if (unlikely(err_code & PF_PROT))
+ return true;
+
+ /* read, not present: */
+ if (unlikely(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE
+ return true;
+
+ return false;
+}
+
+/* Error handlers */
+
+gpf_ret_t handle_bad_area(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address, int si_code);
+
+
+void no_context(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address, int signal, int si_code);
+
+static inline gpf_ret_t handle_kernel_fault(struct pt_regs *regs,
+ unsigned long error_code,
+ unsigned long address, int sig,
+ int si_code)
+{
+ no_context(regs, error_code, address, sig, si_code);
+}
+
+gpf_ret_t do_sigbus(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address, unsigned int fault);
+
+static inline void arch_account_major_fault(void) { }
+
+
+#endif /* _ASM_X86_FAULT_H */
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index ede025f..b7ca60a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -13,6 +13,7 @@
#include /* hstate_index_to_shift */
#include /* prefetchw */
#include /* exception_enter(), ... */
+#include
#include /* dotraplinkage,
[tip:x86/urgent] x86: Init per-cpu shadow copy of CR4 on 32-bit CPUs too
Commit-ID: 5b2bdbc84556774afbe11bcfd24c2f6411cfa92b
Gitweb: http://git.kernel.org/tip/5b2bdbc84556774afbe11bcfd24c2f6411cfa92b
Author: Steven Rostedt
AuthorDate: Fri, 27 Feb 2015 14:50:19 -0500
Committer: Ingo Molnar
CommitDate: Sat, 28 Feb 2015 08:04:20 +0100
x86: Init per-cpu shadow copy of CR4 on 32-bit CPUs too
Commit:
1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
added a shadow CR4 such that reads and writes that do not
modify the CR4 execute much faster than always reading the
register itself.
The change modified cpu_init() in common.c, so that the
shadow CR4 gets initialized before anything uses it.
Unfortunately, there's two cpu_init()s in common.c. There's
one for 64-bit and one for 32-bit. The commit only added
the shadow init to the 64-bit path, but the 32-bit path
needs the init too.
Link: http://lkml.kernel.org/r/20150227125208.71c36...@gandalf.local.home
Fixes: 1e02ce4cccdc "x86: Store a per-cpu shadow copy of CR4"
Signed-off-by: Steven Rostedt
Acked-by: Andy Lutomirski
Cc: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Link: http://lkml.kernel.org/r/20150227145019.2bdd4...@gandalf.local.home
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/common.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index b5c8ff5..2346c95 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1396,6 +1396,12 @@ void cpu_init(void)
wait_for_master_cpu(cpu);
+ /*
+* Initialize the CR4 shadow before doing anything that could
+* try to read it.
+*/
+ cr4_init_shadow();
+
show_ucode_info_early();
printk(KERN_INFO "Initializing CPU#%d\n", cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ocfs2: remove unneeded variable 'status'
Am 27.02.2015 um 11:29 schrieb DaeSeok Youn: > Hi, > > 2015-02-27 18:41 GMT+09:00 Richard Weinberger : >> On Fri, Feb 27, 2015 at 10:27 AM, DaeSeok Youn >> wrote: >>> Hi, >>> >>> I think this patch was already queued. Can I send this patch again >>> after update changelog? >> >> One thing that is much more important, how did you test this patch? Did you? > > I couldn't test, actually I don't have the environment for testing > this file system. > just looking this file for cleaning up and found this. *please* setup a test environment and test the code paths you're changing. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem
From: Yanjiang Jin Fix rng_unmap_ctx's DMA_UNMAP size problem for caam_rng, else system would report the below calltrace during kexec boot: caam_jr ffe301000.jr: DMA-API: device driver frees DMA memory with different size [device address=0x7f080010] [map size=16 bytes] [unmap size=40 bytes] [ cut here ] WARNING: at lib/dma-debug.c:887 Modules linked in: CPU: 1 PID: 730 Comm: kexec Not tainted 3.10.62-ltsi-WR6.0.0.0_standard #188 task: c000f7cdaa80 ti: c000e534 task.ti: c000e534 NIP: c04f5bc8 LR: c04f5bc4 CTR: c05f69b0 REGS: c000e53433c0 TRAP: 0700 Not tainted (3.10.62-ltsi-WR6.0.0.0_standard) MSR: 80029000 CR: 24088482 XER: SOFTE: 0 GPR00: c04f5bc4 c000e5343640 c12af360 009f GPR04: 00a0 c0d02070 c00015980660 GPR08: c0cff360 c12da018 GPR12: 01e3 c1fff780 100f 0001 GPR16: 0002 GPR20: 0001 GPR24: 0001 0001 0001 GPR28: c1556b90 c1565b80 c000e5343750 c000f9427480 NIP [c04f5bc8] .check_unmap+0x538/0x9c0 LR [c04f5bc4] .check_unmap+0x534/0x9c0 Call Trace: [c000e5343640] [c04f5bc4] .check_unmap+0x534/0x9c0 (unreliable) [c000e53436e0] [c04f60d4] .debug_dma_unmap_page+0x84/0xb0 [c000e5343810] [c082f9d4] .caam_cleanup+0x1d4/0x240 [c000e53438a0] [c056cc88] .hwrng_unregister+0xd8/0x1c0 [c000e5343930] [c082fa74] .caam_rng_shutdown+0x34/0x60 [c000e53439a0] [c0817354] .caam_remove+0x54/0x420 [c000e5343a70] [c05791ac] .platform_drv_shutdown+0x3c/0x60 [c000e5343af0] [c0573728] .device_shutdown+0x128/0x240 [c000e5343b90] [c00880b4] .kernel_restart_prepare+0x54/0x70 [c000e5343c10] [c00e5cac] .kernel_kexec+0x9c/0xd0 [c000e5343c90] [c0088404] .SyS_reboot+0x244/0x2d0 [c000e5343e30] [c718] syscall_exit+0x0/0x8c Instruction dump: 7c641b78 41de0410 e8a90050 2fa5 419e0484 e8de0028 e8ff0030 3c62ff90 e91e0030 38638388 48546ed9 6000 <0fe0> 3c62ff8f 38637fc8 48546ec5 ---[ end trace e43fd1734d6600df ]--- Signed-off-by: Yanjiang Jin --- drivers/crypto/caam/caamrng.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c index ae31e55..314f73d 100644 --- a/drivers/crypto/caam/caamrng.c +++ b/drivers/crypto/caam/caamrng.c @@ -90,8 +90,8 @@ static inline void rng_unmap_ctx(struct caam_rng_ctx *ctx) struct device *jrdev = ctx->jrdev; if (ctx->sh_desc_dma) - dma_unmap_single(jrdev, ctx->sh_desc_dma, DESC_RNG_LEN, -DMA_TO_DEVICE); + dma_unmap_single(jrdev, ctx->sh_desc_dma, + desc_bytes(ctx->sh_desc), DMA_TO_DEVICE); rng_unmap_buf(jrdev, >bufs[0]); rng_unmap_buf(jrdev, >bufs[1]); } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC V2] mm: change mm_advise_free to clear page dirty
This patch add ClearPageDirty() to clear AnonPage dirty flag,
if not clear page dirty for this anon page, the page will never be
treated as freeable. we also make sure the shared AnonPage is not
freeable, we implement it by dirty all copyed AnonPage pte,
so that make sure the Anonpage will not become freeable, unless
all process which shared this page call madvise_free syscall.
Another change is that we also handle file map page,
we just clear pte young bit for file map, this is useful,
it can make reclaim patch move file pages into inactive
lru list aggressively.
Signed-off-by: Yalin Wang
---
mm/madvise.c | 26 +++---
mm/memory.c | 12 ++--
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8..712756b 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -299,30 +299,38 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
long addr,
page = vm_normal_page(vma, addr, ptent);
if (!page)
continue;
+ if (!PageAnon(page))
+ goto set_pte;
+ if (!trylock_page(page))
+ continue;
if (PageSwapCache(page)) {
- if (!trylock_page(page))
- continue;
-
if (!try_to_free_swap(page)) {
unlock_page(page);
continue;
}
-
- ClearPageDirty(page);
- unlock_page(page);
}
/*
+* we clear page dirty flag for AnonPage, no matter if this
+* page is in swapcahce or not, AnonPage not in swapcache also
set
+* dirty flag sometimes, this happened when an AnonPage is
removed
+* from swapcahce by try_to_free_swap()
+*/
+ ClearPageDirty(page);
+ unlock_page(page);
+ /*
* Some of architecture(ex, PPC) don't update TLB
* with set_pte_at and tlb_remove_tlb_entry so for
* the portability, remap the pte with old|clean
* after pte clearing.
*/
+set_pte:
ptent = ptep_get_and_clear_full(mm, addr, pte,
tlb->fullmm);
ptent = pte_mkold(ptent);
- ptent = pte_mkclean(ptent);
+ if (PageAnon(page))
+ ptent = pte_mkclean(ptent);
set_pte_at(mm, addr, pte, ptent);
tlb_remove_tlb_entry(tlb, pte, addr);
}
@@ -364,10 +372,6 @@ static int madvise_free_single_vma(struct vm_area_struct
*vma,
if (vma->vm_flags & (VM_LOCKED|VM_HUGETLB|VM_PFNMAP))
return -EINVAL;
- /* MADV_FREE works for only anon vma at the moment */
- if (vma->vm_file)
- return -EINVAL;
-
start = max(vma->vm_start, start_addr);
if (start >= vma->vm_end)
return -EINVAL;
diff --git a/mm/memory.c b/mm/memory.c
index 8068893..3d949b3 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -874,10 +874,18 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct
*src_mm,
if (page) {
get_page(page);
page_dup_rmap(page);
- if (PageAnon(page))
+ if (PageAnon(page)) {
+ /*
+* we dirty the copyed pte for anon page,
+* this is useful for madvise_free_pte_range(),
+* this can prevent shared anon page freed by
madvise_free
+* syscall
+*/
+ pte = pte_mkdirty(pte);
rss[MM_ANONPAGES]++;
- else
+ } else {
rss[MM_FILEPAGES]++;
+ }
}
out_set_pte:
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] crypto: caamhash: replace kmalloc with kzalloc
From: Yanjiang Jin
This can make sure we get a clean memory, else system would report
the below warning:
caam_jr ffe301000.jr: DMA-API: device driver tries to free DMA memory it has
not allocated [device address=0xdeadbeefdeadbeef] [size=18446744073150512879
bytes]
[ cut here ]
WARNING: at lib/dma-debug.c:877
Modules linked in:
CPU: 1 PID: 98 Comm: cryptomgr_test Not tainted 3.10.62-ltsi-WR6.0.0.0_standard
#175
task: c000f74bc400 ti: c000fffd task.ti: c000f775c000
NIP: c04f5ed8 LR: c04f5ed4 CTR: c055a160
REGS: c000fffd3650 TRAP: 0700 Not tainted
(3.10.62-ltsi-WR6.0.0.0_standard)
MSR: 80029000 CR: 24a48e84 XER:
SOFTE: 1
004f5ed4 c000fffd38d0 c12af348 00a0
24a48e84 c125f1c8 01eb
0060 0001 10187373 0020
01eb c1fff780 c11ac928 c0007f003028
0097 0098 0098 c000f7758800
f7098c00 0001 0001 003f
f7098c00 0014 c0007f003000 c11b0e98
c1565b80 c000fffd39e0 c000f72f2410
NIP [c04f5ed8] .check_unmap+0x848/0x9c0
LR [c04f5ed4] .check_unmap+0x844/0x9c0
Call Trace:
[c000fffd38d0] [c04f5ed4] .check_unmap+0x844/0x9c0 (unreliable)
[c000fffd3970] [c04f60d4] .debug_dma_unmap_page+0x84/0xb0
[c000fffd3aa0] [c08295cc] .ahash_done+0x1dc/0x360
[c000fffd3ca0] [c081b7ec] .caam_jr_dequeue+0x26c/0x3a0
[c000fffd3da0] [c08be50c] .net_rx_action+0x1cc/0x330
[c000fffd3e80] [c007276c] .__do_softirq+0x19c/0x3d0
[c000fffd3f90] [c0017054] .call_do_softirq+0x14/0x24
[c000f775ef10] [c0005fe8] .do_softirq+0x118/0x150
sda: sda1 sda2 sda3
[c000f775efa0] [c0072c54] .irq_exit+0x124/0x140
[c000f775f020] [c0005ac4] .do_IRQ+0x184/0x370
[c000f775f0d0] [c001b93c] exc_0x500_common+0xfc/0x100
--- Exception: 501 at .rcu_note_context_switch+0x0/0x370
edule+0xbc/0x7f0
[c000f775f3c0] [c0a29944] .__schedule+0xa4/0x7f0 (unreliable)
[c000f775f620] [c0a277f4] .schedule_timeout+0x1b4/0x2e0
[c000f775f700] [c0a29428] .wait_for_common+0xf8/0x1d0
[c000f775f7c0] [c0a295ac]
.wait_for_completion_interruptible+0x2c/0x50
[c000f775f840] [c0494b64]
.do_one_async_hash_op.isra.1.part.2+0x24/0x50
[c000f775f8c0] [c04951a8] .test_hash+0x618/0x7d0
[c000f775fb30] [c0495424] .alg_test_hash+0xc4/0xf0
[c000f775fbc0] [c0494928] .alg_test+0xa8/0x2c0
[c000f775fcb0] [c0491164] .cryptomgr_test+0x64/0x80
[c000f775fd30] [c009a8d0] .kthread+0xf0/0x100
[c000f775fe30] [ca08] .ret_from_kernel_thread+0x5c/0xd4
Instruction dump:
7c641b78 419e0160 e8a90050 2fa5 409e0008 e8a90010 e8de0028 e8fe0030
3c62ff90 38638320 48546b69 6000 <0fe0> 4b34 e87e0010 2fa3
---[ end trace 52825d316d569f00 ]---
Signed-off-by: Yanjiang Jin
---
drivers/crypto/caam/caamhash.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index f6ad322..a6ba9f7 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -451,7 +451,7 @@ static int hash_digest_key(struct caam_hash_ctx *ctx, const
u8 *key_in,
dma_addr_t src_dma, dst_dma;
int ret = 0;
- desc = kmalloc(CAAM_CMD_SZ * 8 + CAAM_PTR_SZ * 2, GFP_KERNEL | GFP_DMA);
+ desc = kzalloc(CAAM_CMD_SZ * 8 + CAAM_PTR_SZ * 2, GFP_KERNEL | GFP_DMA);
if (!desc) {
dev_err(jrdev, "unable to allocate key input memory\n");
return -ENOMEM;
@@ -815,7 +815,7 @@ static int ahash_update_ctx(struct ahash_request *req)
* allocate space for base edesc and hw desc commands,
* link tables
*/
- edesc = kmalloc(sizeof(struct ahash_edesc) + DESC_JOB_IO_LEN +
+ edesc = kzalloc(sizeof(struct ahash_edesc) + DESC_JOB_IO_LEN +
sec4_sg_bytes, GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev,
@@ -926,7 +926,7 @@ static int ahash_final_ctx(struct ahash_request *req)
sec4_sg_bytes = (1 + (buflen ? 1 : 0)) * sizeof(struct sec4_sg_entry);
/* allocate space for base edesc and hw desc commands, link tables */
- edesc = kmalloc(sizeof(struct ahash_edesc) + DESC_JOB_IO_LEN +
+ edesc = kzalloc(sizeof(struct ahash_edesc) + DESC_JOB_IO_LEN +
sec4_sg_bytes, GFP_DMA | flags);
if (!edesc) {
dev_err(jrdev, "could not allocate extended descriptor\n");
@@ -1013,7 +1013,7 @@ static int ahash_finup_ctx(struct ahash_request *req)
sizeof(struct sec4_sg_entry);
[PATCH 3/4] crypto: caamhash: add two missed dma_mapping_error
From: Yanjiang Jin
Add two missed dma_mapping_error() after dma_map_single().
Signed-off-by: Yanjiang Jin
---
drivers/crypto/caam/caamhash.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index f347ab7..f6ad322 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -160,6 +160,10 @@ static inline dma_addr_t map_seq_out_ptr_result(u32 *desc,
struct device *jrdev,
dma_addr_t dst_dma;
dst_dma = dma_map_single(jrdev, result, digestsize, DMA_FROM_DEVICE);
+ if (dma_mapping_error(jrdev, dst_dma)) {
+ dev_err(jrdev, "unable to map dst dma\n");
+ return -ENOMEM;
+ }
append_seq_out_ptr(desc, dst_dma, digestsize, 0);
return dst_dma;
@@ -173,6 +177,10 @@ static inline dma_addr_t buf_map_to_sec4_sg(struct device
*jrdev,
dma_addr_t buf_dma;
buf_dma = dma_map_single(jrdev, buf, buflen, DMA_TO_DEVICE);
+ if (dma_mapping_error(jrdev, buf_dma)) {
+ dev_err(jrdev, "unable to map buf dma\n");
+ return 0;
+ }
dma_to_sec4_sg_one(sec4_sg, buf_dma, buflen, 0);
return buf_dma;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] crypto: caam: fix some compile warnings
From: Yanjiang Jin
This commit is to avoid the below warnings:
drivers/crypto/caam/sg_sw_sec4.h:88:12: warning:
'dma_map_sg_chained' defined but not used [-Wunused-function]
static int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
^
drivers/crypto/caam/sg_sw_sec4.h:104:12: warning:
'dma_unmap_sg_chained' defined but not used [-Wunused-function]
static int dma_unmap_sg_chained(struct device *dev,
^
Signed-off-by: Yanjiang Jin
---
drivers/crypto/caam/sg_sw_sec4.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index 3b91821..a6276eb 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -85,7 +85,7 @@ static inline int sg_count(struct scatterlist *sg_list, int
nbytes,
return sg_nents;
}
-static int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
+static inline int dma_map_sg_chained(struct device *dev, struct scatterlist
*sg,
unsigned int nents, enum dma_data_direction dir,
bool chained)
{
@@ -101,9 +101,9 @@ static int dma_map_sg_chained(struct device *dev, struct
scatterlist *sg,
return nents;
}
-static int dma_unmap_sg_chained(struct device *dev, struct scatterlist *sg,
- unsigned int nents, enum dma_data_direction dir,
- bool chained)
+static inline int dma_unmap_sg_chained(struct device *dev,
+ struct scatterlist *sg, unsigned int nents,
+ enum dma_data_direction dir, bool chained)
{
if (unlikely(chained)) {
int i;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Staging: fbtft: fb_ssd1331: replaced C99 comments with C89
Replaced C99 '//' comments with C89 '/**/' Signed-off-by: Tolga Ceylan --- drivers/staging/fbtft/fb_ssd1331.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/staging/fbtft/fb_ssd1331.c index da7464f..c4e1dd7 100644 --- a/drivers/staging/fbtft/fb_ssd1331.c +++ b/drivers/staging/fbtft/fb_ssd1331.c @@ -29,24 +29,24 @@ static int init_display(struct fbtft_par *par) write_reg(par, 0xae); /* Display Off */ write_reg(par, 0xa0, 0x70 | (par->bgr << 2)); /* Set Colour Depth */ - write_reg(par, 0x72); // RGB colour + write_reg(par, 0x72); /* RGB colour */ write_reg(par, 0xa1, 0x00); /* Set Display Start Line */ write_reg(par, 0xa2, 0x00); /* Set Display Offset */ write_reg(par, 0xa4); /* NORMALDISPLAY */ - write_reg(par, 0xa8, 0x3f); // Set multiplex - write_reg(par, 0xad, 0x8e); // Set master - // write_reg(par, 0xb0, 0x0b); // Set power mode - write_reg(par, 0xb1, 0x31); // Precharge - write_reg(par, 0xb3, 0xf0); // Clock div - write_reg(par, 0x8a, 0x64); // Precharge A - write_reg(par, 0x8b, 0x78); // Precharge B - write_reg(par, 0x8c, 0x64); // Precharge C - write_reg(par, 0xbb, 0x3a); // Precharge level - write_reg(par, 0xbe, 0x3e); // vcomh - write_reg(par, 0x87, 0x06); // Master current - write_reg(par, 0x81, 0x91); // Contrast A - write_reg(par, 0x82, 0x50); // Contrast B - write_reg(par, 0x83, 0x7d); // Contrast C + write_reg(par, 0xa8, 0x3f); /* Set multiplex */ + write_reg(par, 0xad, 0x8e); /* Set master */ + /* write_reg(par, 0xb0, 0x0b); */ /* Set power mode */ + write_reg(par, 0xb1, 0x31); /* Precharge */ + write_reg(par, 0xb3, 0xf0); /* Clock div */ + write_reg(par, 0x8a, 0x64); /* Precharge A */ + write_reg(par, 0x8b, 0x78); /* Precharge B */ + write_reg(par, 0x8c, 0x64); /* Precharge C */ + write_reg(par, 0xbb, 0x3a); /* Precharge level */ + write_reg(par, 0xbe, 0x3e); /* vcomh */ + write_reg(par, 0x87, 0x06); /* Master current */ + write_reg(par, 0x81, 0x91); /* Contrast A */ + write_reg(par, 0x82, 0x50); /* Contrast B */ + write_reg(par, 0x83, 0x7d); /* Contrast C */ write_reg(par, 0xaf); /* Set Sleep Mode Display On */ return 0; -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Staging: fbtft: fb_ssd1331: replaced C99 comments with C89
On Fri, Feb 27, 2015 at 9:37 PM, Tolga Ceylan wrote: > Replaced C99 '//' comments with C89 '/**/' > > Signed-off-by: Tolga Ceylan > --- > drivers/staging/fbtft/fb_ssd1331.c | 30 +++--- > 1 file changed, 15 insertions(+), 15 deletions(-) > > diff --git a/drivers/staging/fbtft/fb_ssd1331.c > b/drivers/staging/fbtft/fb_ssd1331.c > index da7464f..5cbd763 100644 > --- a/drivers/staging/fbtft/fb_ssd1331.c > +++ b/drivers/staging/fbtft/fb_ssd1331.c > @@ -29,24 +29,24 @@ static int init_display(struct fbtft_par *par) > > write_reg(par, 0xae); /* Display Off */ > write_reg(par, 0xa0, 0x70 | (par->bgr << 2)); /* Set Colour Depth */ > - write_reg(par, 0x72); // RGB colour > + write_reg(par, 0x72); /* RGB colour */ > write_reg(par, 0xa1, 0x00); /* Set Display Start Line */ > write_reg(par, 0xa2, 0x00); /* Set Display Offset */ > write_reg(par, 0xa4); /* NORMALDISPLAY */ > - write_reg(par, 0xa8, 0x3f); // Set multiplex > - write_reg(par, 0xad, 0x8e); // Set master > - // write_reg(par, 0xb0, 0x0b); // Set power mode > - write_reg(par, 0xb1, 0x31); // Precharge > - write_reg(par, 0xb3, 0xf0); // Clock div > - write_reg(par, 0x8a, 0x64); // Precharge A > - write_reg(par, 0x8b, 0x78); // Precharge B > - write_reg(par, 0x8c, 0x64); // Precharge C > - write_reg(par, 0xbb, 0x3a); // Precharge level > - write_reg(par, 0xbe, 0x3e); // vcomh > - write_reg(par, 0x87, 0x06); // Master current > - write_reg(par, 0x81, 0x91); // Contrast A > - write_reg(par, 0x82, 0x50); // Contrast B > - write_reg(par, 0x83, 0x7d); // Contrast C > + write_reg(par, 0xa8, 0x3f); /* Set multiplex > + write_reg(par, 0xad, 0x8e); /* Set master > + /* write_reg(par, 0xb0, 0x0b); */ /* Set power mode */ > + write_reg(par, 0xb1, 0x31); /* Precharge */ > + write_reg(par, 0xb3, 0xf0); /* Clock div */ > + write_reg(par, 0x8a, 0x64); /* Precharge A */ > + write_reg(par, 0x8b, 0x78); /* Precharge B */ > + write_reg(par, 0x8c, 0x64); /* Precharge C */ > + write_reg(par, 0xbb, 0x3a); /* Precharge level */ > + write_reg(par, 0xbe, 0x3e); /* vcomh */ > + write_reg(par, 0x87, 0x06); /* Master current */ > + write_reg(par, 0x81, 0x91); /* Contrast A */ > + write_reg(par, 0x82, 0x50); /* Contrast B */ > + write_reg(par, 0x83, 0x7d); /* Contrast C */ > write_reg(par, 0xaf); /* Set Sleep Mode Display On */ > > return 0; > -- > 2.3.0 > Apologies, please ignore this patch. It is faulty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Staging: fbtft: fb_ssd1331: replaced C99 comments with C89
Replaced C99 '//' comments with C89 '/**/' Signed-off-by: Tolga Ceylan --- drivers/staging/fbtft/fb_ssd1331.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/staging/fbtft/fb_ssd1331.c b/drivers/staging/fbtft/fb_ssd1331.c index da7464f..5cbd763 100644 --- a/drivers/staging/fbtft/fb_ssd1331.c +++ b/drivers/staging/fbtft/fb_ssd1331.c @@ -29,24 +29,24 @@ static int init_display(struct fbtft_par *par) write_reg(par, 0xae); /* Display Off */ write_reg(par, 0xa0, 0x70 | (par->bgr << 2)); /* Set Colour Depth */ - write_reg(par, 0x72); // RGB colour + write_reg(par, 0x72); /* RGB colour */ write_reg(par, 0xa1, 0x00); /* Set Display Start Line */ write_reg(par, 0xa2, 0x00); /* Set Display Offset */ write_reg(par, 0xa4); /* NORMALDISPLAY */ - write_reg(par, 0xa8, 0x3f); // Set multiplex - write_reg(par, 0xad, 0x8e); // Set master - // write_reg(par, 0xb0, 0x0b); // Set power mode - write_reg(par, 0xb1, 0x31); // Precharge - write_reg(par, 0xb3, 0xf0); // Clock div - write_reg(par, 0x8a, 0x64); // Precharge A - write_reg(par, 0x8b, 0x78); // Precharge B - write_reg(par, 0x8c, 0x64); // Precharge C - write_reg(par, 0xbb, 0x3a); // Precharge level - write_reg(par, 0xbe, 0x3e); // vcomh - write_reg(par, 0x87, 0x06); // Master current - write_reg(par, 0x81, 0x91); // Contrast A - write_reg(par, 0x82, 0x50); // Contrast B - write_reg(par, 0x83, 0x7d); // Contrast C + write_reg(par, 0xa8, 0x3f); /* Set multiplex + write_reg(par, 0xad, 0x8e); /* Set master + /* write_reg(par, 0xb0, 0x0b); */ /* Set power mode */ + write_reg(par, 0xb1, 0x31); /* Precharge */ + write_reg(par, 0xb3, 0xf0); /* Clock div */ + write_reg(par, 0x8a, 0x64); /* Precharge A */ + write_reg(par, 0x8b, 0x78); /* Precharge B */ + write_reg(par, 0x8c, 0x64); /* Precharge C */ + write_reg(par, 0xbb, 0x3a); /* Precharge level */ + write_reg(par, 0xbe, 0x3e); /* vcomh */ + write_reg(par, 0x87, 0x06); /* Master current */ + write_reg(par, 0x81, 0x91); /* Contrast A */ + write_reg(par, 0x82, 0x50); /* Contrast B */ + write_reg(par, 0x83, 0x7d); /* Contrast C */ write_reg(par, 0xaf); /* Set Sleep Mode Display On */ return 0; -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Staging: fbtft: fbtft-core: removed space before ','
Removed space before ',' Signed-off-by: Tolga Ceylan --- drivers/staging/fbtft/fbtft-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index 37dcf7e..ac4287f 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -49,7 +49,7 @@ extern int fbtft_gamma_parse_str(struct fbtft_par *par, unsigned long *curves, const char *str, int size); static unsigned long debug; -module_param(debug, ulong , 0); +module_param(debug, ulong, 0); MODULE_PARM_DESC(debug, "override device debug level"); static bool dma = true; -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Staging: rtl8192u: r8192U_wx: removed unnecessary comments
1) Removed commented out include header statement 2) Removed unnecessary author/date comment Signed-off-by: Tolga Ceylan --- drivers/staging/rtl8192u/r8192U_wx.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/rtl8192u/r8192U_wx.h b/drivers/staging/rtl8192u/r8192U_wx.h index ae7a617..e926d37 100644 --- a/drivers/staging/rtl8192u/r8192U_wx.h +++ b/drivers/staging/rtl8192u/r8192U_wx.h @@ -14,10 +14,9 @@ #ifndef R8180_WX_H #define R8180_WX_H -//#include extern struct iw_handler_def r8192_wx_handlers_def; -/* Enable the rtl819x_core.c to share this function, david 2008.9.22 */ +/* Enable the rtl819x_core.c to share this function */ extern struct iw_statistics *r8192_get_wireless_stats(struct net_device *dev); #endif -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] introduce dynamic device creation/removal
On Sat, 28 Feb 2015 12:34:15 +0900 Sergey Senozhatsky
wrote:
> On (02/27/15 14:51), Andrew Morton wrote:
> > hoo boy. Creating a /dev node and doing ioctls on it is really old
> > school. So old school that I've forgotten why we don't do it any more.
> >
> > Hopefully Alan can recall the thinking?
> >
>
> perhaps, something like
>
> static struct class_attribute zram_class_attrs[] = {
> __ATTR(zram_control, S_IWUSR | S_IRUGO,
> zram_control_show, zram_control_store),
> __ATTR_NULL,
> };
>
> struct class zram_class = {
> .name = "zram-control",
> .class_attrs= zram_class_attrs,
> };
>
>
> class_register(_class);
>
>
>
> or (even better) separate control files
>
> static struct class_attribute zram_class_attrs[] = {
> __ATTR(zram_add, ),
> __ATTR(zram_remove, ),
> __ATTR_NULL,
> };
>
>
> so we can just echo `device_id' to add/remove devices
>
> echo 1 > /sys/class/zram-control/zram_add
> echo 1 > /sys/class/zram-control/zram_remove
>
>
> handling it in FOO_store() functions:
>
> static ssize_t zram_add_store(struct class *class,
> struct class_attribute *attr,
> char *buf)
>
>
> how about this?
That would be more conventional. There's no pretty way of doing this
really.
http://yarchive.net/comp/linux/ioctl.html does a pretty good job of the
thinking on ioctl - mainly the typelessness of it all. That's very old
and doesn't discuss the 32/64 bit compat issues.
Your patch doesn't really have this problem at this stage, but once the
ioctl interface is added, new controls which are added later should use
it, and we're likely to get into the same issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] introduce dynamic device creation/removal
On (02/27/15 14:51), Andrew Morton wrote:
> hoo boy. Creating a /dev node and doing ioctls on it is really old
> school. So old school that I've forgotten why we don't do it any more.
>
> Hopefully Alan can recall the thinking?
>
perhaps, something like
static struct class_attribute zram_class_attrs[] = {
__ATTR(zram_control, S_IWUSR | S_IRUGO,
zram_control_show, zram_control_store),
__ATTR_NULL,
};
struct class zram_class = {
.name = "zram-control",
.class_attrs= zram_class_attrs,
};
class_register(_class);
or (even better) separate control files
static struct class_attribute zram_class_attrs[] = {
__ATTR(zram_add, ),
__ATTR(zram_remove, ),
__ATTR_NULL,
};
so we can just echo `device_id' to add/remove devices
echo 1 > /sys/class/zram-control/zram_add
echo 1 > /sys/class/zram-control/zram_remove
handling it in FOO_store() functions:
static ssize_t zram_add_store(struct class *class,
struct class_attribute *attr,
char *buf)
how about this?
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/3] hugetlbfs: coordinate global and subpool reserve accounting
> @@ -3444,10 +3445,14 @@ int hugetlb_reserve_pages(struct inode *inode,
>* Check enough hugepages are available for the reservation.
>* Hand the pages back to the subpool if there are not
>*/
Better if comment is updated correspondingly.
Hillf
> - ret = hugetlb_acct_memory(h, chg);
> - if (ret < 0) {
> - hugepage_subpool_put_pages(spool, chg);
> - goto out_err;
> + if (subpool_reserved(spool))
> + ret = 0;
> + else {
> + ret = hugetlb_acct_memory(h, chg);
> + if (ret < 0) {
> + hugepage_subpool_put_pages(spool, chg);
> + goto out_err;
> + }
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/2] cpusets,isolcpus: document relationship between cpusets & isolcpus
On 2015/2/28 1:08, Rik van Riel wrote: > Document the subtly changed relationship between cpusets and isolcpus. > Turns out the old documentation did not quite match the code... > > Signed-off-by: Rik van Riel > Suggested-by: Peter Zijlstra Acked-by: Zefan Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] cpusets,isolcpus: add file to show isolated cpus in cpuset
> Subject: cpusets,isolcpus: add file to show isolated cpus in cpuset > > The previous patch makes it so the code skips over isolcpus when > building scheduler load balancing domains. This makes it hard to > see for a user which of the CPUs in a cpuset are participating in > load balancing, and which ones are isolated cpus. > > Add a cpuset.isolcpus file with info on which cpus in a cpuset are > isolated CPUs. > > This file is read-only for now. In the future we could extend things > so isolcpus can be changed at run time, for the root (system wide) > cpuset only. > > Acked-by: David Rientjes > Cc: Peter Zijlstra > Cc: Clark Williams > Cc: Li Zefan > Cc: Ingo Molnar > Cc: Luiz Capitulino > Cc: David Rientjes > Cc: Mike Galbraith > Cc: cgro...@vger.kernel.org > Signed-off-by: Rik van Riel Acked-by: Zefan Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v2 1/3] mm: remove GFP_THISNODE
On Fri, 27 Feb 2015, Christoph Lameter wrote:
> > +/*
> > + * Construct gfp mask to allocate from a specific node but do not invoke
> > reclaim
> > + * or warn about failures.
> > + */
>
> We should be triggering reclaim from slab allocations. Why would we not do
> this?
>
> Otherwise we will be going uselessly off node for slab allocations.
>
> > +static inline gfp_t gfp_exact_node(gfp_t flags)
> > +{
> > + return (flags | __GFP_THISNODE | __GFP_NOWARN) & ~__GFP_WAIT;
> > +}
> > #endif
>
> Reclaim needs to be triggered. In particular zone reclaim was made to be
> triggered from slab allocations to create more room if needed.
>
This illustrates the precise need for a patch like this that removes
GFP_THISNODE entirely: notice there's no functional change with this
patch.
GFP_THISNODE is __GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY.
The calls to cache_alloc_node() and cache_grow() modified by this
patch in mm/slab.c that pass GFP_THISNODE get caught in the page allocator
slowpath by this:
if (IS_ENABLED(CONFIG_NUMA) &&
(gfp_mask & GFP_THISNODE) == GFP_THISNODE)
goto nopage;
with today's kernel. In fact, there is no way for the slab allocator to
currently allocate exactly on one node, allow reclaim, and avoid looping
forever while suppressing the page allocation failure warning. The reason
is because of how GFP_THISNODE is defined above.
With this patch, it would be possible to modify gfp_exact_node() so that
instead of doing
return (flags | __GFP_THISNODE | __GFP_NOWARN) & ~__GFP_WAIT;
which has no functional change from today, it could be
return flags | __GFP_THISNODE | __GFP_NOWARN | __GFP_NORETRY;
so that we _can_ do reclaim for that node and avoid looping forever when
the allocation fails. These three flags are the exact same bits set in
today's GFP_THISNODE and it is, I agree, what the slab allocator really
wants to do in cache_grow(). But the conditional above is what
short-circuits such an allocation and needs to be removed, which is what
this patch does.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cpusets,isolcpus: exclude isolcpus from load balancing in cpusets
On 2015/2/26 0:38, r...@redhat.com wrote: > From: Rik van Riel > > Ensure that cpus specified with the isolcpus= boot commandline > option stay outside of the load balancing in the kernel scheduler. > > Operations like load balancing can introduce unwanted latencies, > which is exactly what the isolcpus= commandline is there to prevent. > > Previously, simply creating a new cpuset, without even touching the > cpuset.cpus field inside the new cpuset, would undo the effects of > isolcpus=, by creating a scheduler domain spanning the whole system, > and setting up load balancing inside that domain. The cpuset root > cpuset.cpus file is read-only, so there was not even a way to undo > that effect. > > This does not impact the majority of cpusets users, since isolcpus= > is a fairly specialized feature used for realtime purposes. > > Cc: Peter Zijlstra > Cc: Clark Williams > Cc: Li Zefan > Cc: Ingo Molnar > Cc: Luiz Capitulino > Cc: Mike Galbraith > Cc: cgro...@vger.kernel.org > Signed-off-by: Rik van Riel > Tested-by: David Rientjes Acked-by: Zefan Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH perf/core ] perf-probe: Warn if given uprobe event accesses memory on older kernel
(2015/02/28 11:53), Masami Hiramatsu wrote:
> Warn if given uprobe event accesses memory on older kernel.
> Until 3.14, uprobe event only supports accessing registers
> so this warns to upgrade kernel if uprobe-event returns
> -EINVAL and an argument of the event accesses memory ($stack,
> @+offset, and +|-offs() symtax).
>
> With this patch (on 3.10.0-123.13.2.el7.x86_64);
> -
> # ./perf probe -x ./perf warn_uprobe_event_compat stack=-0\(%sp\)
> Added new event:
> Failed to write event: Invalid argument
> Please upgrade your kernel to at least 3.14 to have access to feature
> -0(%sp)
> Error: Failed to add events.
> -
>
Oops,
Suggested-by: Arnaldo Carvalho de Melo
Thanks,
> Signed-off-by: Masami Hiramatsu
> ---
> tools/perf/util/probe-event.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 7c0e765..1c570c2fa7 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -2199,6 +2199,27 @@ static int get_new_event_name(char *buf, size_t len,
> const char *base,
> return ret;
> }
>
> +/* Warn if the current kernel's uprobe implementation is old */
> +static void warn_uprobe_event_compat(struct probe_trace_event *tev)
> +{
> + int i;
> + char *buf = synthesize_probe_trace_command(tev);
> +
> + /* Old uprobe event doesn't support memory dereference */
> + if (!tev->uprobes || tev->nargs == 0 || !buf)
> + goto out;
> +
> + for (i = 0; i < tev->nargs; i++)
> + if (strglobmatch(tev->args[i].value, "[$@+-]*")) {
> + pr_warning("Please upgrade your kernel to at least "
> +"3.14 to have access to feature %s\n",
> +tev->args[i].value);
> + break;
> + }
> +out:
> + free(buf);
> +}
> +
> static int __add_probe_trace_events(struct perf_probe_event *pev,
>struct probe_trace_event *tevs,
>int ntevs, bool allow_suffix)
> @@ -2295,6 +2316,8 @@ static int __add_probe_trace_events(struct
> perf_probe_event *pev,
>*/
> allow_suffix = true;
> }
> + if (ret == -EINVAL && pev->uprobes)
> + warn_uprobe_event_compat(tev);
>
> /* Note that it is possible to skip all events because of blacklist */
> if (ret >= 0 && tev->event) {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove redhat'ism from ftrace selftests.
Hi, On Tue, Feb 24, 2015 at 01:24:59PM -0500, Dave Jones wrote: > On Tue, Feb 24, 2015 at 11:22:58AM -0700, Shuah Khan wrote: > > On 02/24/2015 11:18 AM, Steven Rostedt wrote: > > > > > > Shuah, > > > > > > Can you take this in your tree? > > > > Yes I can do that. This must be the original patch email: > > https://lkml.org/lkml/2015/2/24/435 Please see below links: https://lkml.org/lkml/2014/12/10/52 https://lkml.org/lkml/2014/12/22/556 I think we can get rid of the (u)sleeps entirely since 'cat trace' itself should trigger scheduler events. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH perf/core ] perf-probe: Warn if given uprobe event accesses memory on older kernel
Warn if given uprobe event accesses memory on older kernel.
Until 3.14, uprobe event only supports accessing registers
so this warns to upgrade kernel if uprobe-event returns
-EINVAL and an argument of the event accesses memory ($stack,
@+offset, and +|-offs() symtax).
With this patch (on 3.10.0-123.13.2.el7.x86_64);
-
# ./perf probe -x ./perf warn_uprobe_event_compat stack=-0\(%sp\)
Added new event:
Failed to write event: Invalid argument
Please upgrade your kernel to at least 3.14 to have access to feature -0(%sp)
Error: Failed to add events.
-
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 7c0e765..1c570c2fa7 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2199,6 +2199,27 @@ static int get_new_event_name(char *buf, size_t len,
const char *base,
return ret;
}
+/* Warn if the current kernel's uprobe implementation is old */
+static void warn_uprobe_event_compat(struct probe_trace_event *tev)
+{
+ int i;
+ char *buf = synthesize_probe_trace_command(tev);
+
+ /* Old uprobe event doesn't support memory dereference */
+ if (!tev->uprobes || tev->nargs == 0 || !buf)
+ goto out;
+
+ for (i = 0; i < tev->nargs; i++)
+ if (strglobmatch(tev->args[i].value, "[$@+-]*")) {
+ pr_warning("Please upgrade your kernel to at least "
+ "3.14 to have access to feature %s\n",
+ tev->args[i].value);
+ break;
+ }
+out:
+ free(buf);
+}
+
static int __add_probe_trace_events(struct perf_probe_event *pev,
struct probe_trace_event *tevs,
int ntevs, bool allow_suffix)
@@ -2295,6 +2316,8 @@ static int __add_probe_trace_events(struct
perf_probe_event *pev,
*/
allow_suffix = true;
}
+ if (ret == -EINVAL && pev->uprobes)
+ warn_uprobe_event_compat(tev);
/* Note that it is possible to skip all events because of blacklist */
if (ret >= 0 && tev->event) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf: fix building error
Hi He,
On Fri, Feb 27, 2015 at 06:05:37PM +0800, He Kuang wrote:
> When build with ARCH=x86_64/i386, perf failed to compile with following
> error:
>
> tests/builtin-test.o:(.data+0x158): undefined reference to
> `test__perf_time_to_tsc'
> collect2: error: ld returned 1 exit status
> Makefile.perf:632: recipe for target 'perf' failed
> ...
>
> Which is caused commit c6e5e9fbc3ea1 ("perf tools: Fix building error
> in x86_64 when dwarf unwind is on"), ARCH test in Makefile.perf
> conflicts with tests/builtin-test.c's __x86_64__.
> To x86/x86_64 platform, ARCH should always override to x86 while
> IS_64_BIT stands for the actual architecture.
>
> Signed-off-by: He Kuang
> ---
> tools/perf/config/Makefile.arch | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
> index ff95a68..05af152 100644
> --- a/tools/perf/config/Makefile.arch
> +++ b/tools/perf/config/Makefile.arch
> @@ -29,3 +29,11 @@ ifeq ($(LP64), 1)
> else
>IS_64_BIT := 0
> endif
> +
> +ifeq ($(ARCH), x86_64)
> + override ARCH := x86
> +endif
> +
> +ifeq ($(ARCH), i386)
> + override ARCH := x86
> +endif
It seems like we need a same sed script to be applied to ARCH then.
How about this?
diff --git a/tools/perf/config/Makefile.arch b/tools/perf/config/Makefile.arch
index ff95a68741d1..e29de6e3597d 100644
--- a/tools/perf/config/Makefile.arch
+++ b/tools/perf/config/Makefile.arch
@@ -1,28 +1,15 @@
+ifndef ARCH
+ARCH := $(shell uname -m 2>/dev/null || echo not)
+endif
-uname_M := $(shell uname -m 2>/dev/null || echo not)
-
-RAW_ARCH := $(shell echo $(uname_M) | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+ARCH := $(shell echo $(ARCH) | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
-e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
-e s/tile.*/tile/ )
-# Additional ARCH settings for x86
-ifeq ($(RAW_ARCH),i386)
- ARCH ?= x86
-endif
-
-ifeq ($(RAW_ARCH),x86_64)
- ARCH ?= x86
-
- ifneq (, $(findstring m32,$(CFLAGS)))
-RAW_ARCH := x86_32
- endif
-endif
-
-ARCH ?= $(RAW_ARCH)
-
LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
ifeq ($(LP64), 1)
IS_64_BIT := 1
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] net: bcmgenet: fix throughtput regression
This patch adds bcmgenet_tx_poll for the tx_rings. This can reduce the
interrupt load and send xmit in network stack on time. This also
separated for the completion of tx_ring16 from bcmgenet_poll.
The bcmgenet_tx_reclaim of tx_ring[{0,1,2,3}] operative by an interrupt
is to be not more than a certain number TxBDs. It is caused by too
slowly reclaiming the transmitted skb. Therefore, performance
degradation of xmit after 605ad7f ("tcp: refine TSO autosizing").
Signed-off-by: Jaedon Shin
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 111 +++--
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 +
2 files changed, 87 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index ff83c46b..d2979ac 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -971,13 +971,14 @@ static inline void bcmgenet_tx_ring_int_disable(struct
bcmgenet_priv *priv,
}
/* Unlocked version of the reclaim routine */
-static void __bcmgenet_tx_reclaim(struct net_device *dev,
+static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
struct bcmgenet_tx_ring *ring)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
int last_tx_cn, last_c_index, num_tx_bds;
struct enet_cb *tx_cb_ptr;
struct netdev_queue *txq;
+ unsigned int pkts_compl = 0;
unsigned int bds_compl;
unsigned int c_index;
@@ -1005,6 +1006,7 @@ static void __bcmgenet_tx_reclaim(struct net_device *dev,
tx_cb_ptr = ring->cbs + last_c_index;
bds_compl = 0;
if (tx_cb_ptr->skb) {
+ pkts_compl++;
bds_compl = skb_shinfo(tx_cb_ptr->skb)->nr_frags + 1;
dev->stats.tx_bytes += tx_cb_ptr->skb->len;
dma_unmap_single(>dev,
@@ -1028,23 +1030,45 @@ static void __bcmgenet_tx_reclaim(struct net_device
*dev,
last_c_index &= (num_tx_bds - 1);
}
- if (ring->free_bds > (MAX_SKB_FRAGS + 1))
- ring->int_disable(priv, ring);
-
- if (netif_tx_queue_stopped(txq))
- netif_tx_wake_queue(txq);
+ if (ring->free_bds > (MAX_SKB_FRAGS + 1)) {
+ if (netif_tx_queue_stopped(txq))
+ netif_tx_wake_queue(txq);
+ }
ring->c_index = c_index;
+
+ return pkts_compl;
}
-static void bcmgenet_tx_reclaim(struct net_device *dev,
+static unsigned int bcmgenet_tx_reclaim(struct net_device *dev,
struct bcmgenet_tx_ring *ring)
{
+ unsigned int released;
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- __bcmgenet_tx_reclaim(dev, ring);
+ released = __bcmgenet_tx_reclaim(dev, ring);
spin_unlock_irqrestore(>lock, flags);
+
+ return released;
+}
+
+static int bcmgenet_tx_poll(struct napi_struct *napi, int budget)
+{
+ struct bcmgenet_tx_ring *ring =
+ container_of(napi, struct bcmgenet_tx_ring, napi);
+ unsigned int work_done = 0;
+
+ work_done = bcmgenet_tx_reclaim(ring->priv->dev, ring);
+
+ if (work_done == 0) {
+ napi_complete(napi);
+ ring->int_enable(ring->priv, ring);
+
+ return 0;
+ }
+
+ return budget;
}
static void bcmgenet_tx_reclaim_all(struct net_device *dev)
@@ -1302,10 +1326,8 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb,
struct net_device *dev)
bcmgenet_tdma_ring_writel(priv, ring->index,
ring->prod_index, TDMA_PROD_INDEX);
- if (ring->free_bds <= (MAX_SKB_FRAGS + 1)) {
+ if (ring->free_bds <= (MAX_SKB_FRAGS + 1))
netif_tx_stop_queue(txq);
- ring->int_enable(priv, ring);
- }
out:
spin_unlock_irqrestore(>lock, flags);
@@ -1621,6 +1643,7 @@ static int init_umac(struct bcmgenet_priv *priv)
struct device *kdev = >pdev->dev;
int ret;
u32 reg, cpu_mask_clear;
+ int index;
dev_dbg(>pdev->dev, "bcmgenet: init_umac\n");
@@ -1647,7 +1670,7 @@ static int init_umac(struct bcmgenet_priv *priv)
bcmgenet_intr_disable(priv);
- cpu_mask_clear = UMAC_IRQ_RXDMA_BDONE;
+ cpu_mask_clear = UMAC_IRQ_RXDMA_BDONE | UMAC_IRQ_TXDMA_BDONE;
dev_dbg(kdev, "%s:Enabling RXDMA_BDONE interrupt\n", __func__);
@@ -1674,6 +1697,10 @@ static int init_umac(struct bcmgenet_priv *priv)
bcmgenet_intrl2_0_writel(priv, cpu_mask_clear, INTRL2_CPU_MASK_CLEAR);
+ for (index = 0; index < priv->hw_params->tx_queues; index++)
+ bcmgenet_intrl2_1_writel(priv, (1 << index),
+INTRL2_CPU_MASK_CLEAR);
+
/* Enable rx/tx engine.*/
Re: [PATCH] sh_eth: Fix lost MAC address on kexec
On Fri, 2015-02-27 at 17:16 +0100, Geert Uytterhoeven wrote:
> Commit 740c7f31c094703c ("sh_eth: Ensure DMA engines are stopped before
> freeing buffers") added a call to sh_eth_reset() to the
> sh_eth_set_ringparam() and sh_eth_close() paths.
>
> However, setting the software reset bit(s) in the EDMR register resets
> the MAC Address Registers to zero. Hence after kexec, the new kernel
> doesn't detect a valid MAC address and assigns a random MAC address,
> breaking DHCP.
[...]
Sorry about that. This would also affect removing and reloading the
driver as a module, but currently I always have it built in and don't
use kexec.
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
On Sat, 2015-02-28 at 10:30 +0800, Huang Ying wrote:
> On Sat, 2015-02-28 at 01:46 +, Mel Gorman wrote:
> > On Fri, Feb 27, 2015 at 03:21:36PM +0800, Huang Ying wrote:
> > > FYI, we noticed the below changes on
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone
> > > fields into read-only, page alloc, statistics and page reclaim lines")
> > >
> > > The perf cpu-cycles for spinlock (zone->lock) increased a lot. I suspect
> > > there are some cache ping-pong or false sharing.
> > >
> >
> > Are you sure about this result? I ran similar tests here and found that
> > there was a major regression introduced near there but it was commit
> > 05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter") that
> > cause the problem and it was later reverted. On local tests on a 4-node
> > machine, commit 3484b2de9499df23c4604a513b36f96326ae81ad was within 1%
> > of the previous commit and well within the noise.
>
> I have double checked the result before sending out.
>
> Do you do the test with same kernel config and test case/parameters
> (aim7/page_test/load 6000)?
Or you can show your test case and parameters and I can try that too.
Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
On Sat, 2015-02-28 at 01:46 +, Mel Gorman wrote:
> On Fri, Feb 27, 2015 at 03:21:36PM +0800, Huang Ying wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone fields
> > into read-only, page alloc, statistics and page reclaim lines")
> >
> > The perf cpu-cycles for spinlock (zone->lock) increased a lot. I suspect
> > there are some cache ping-pong or false sharing.
> >
>
> Are you sure about this result? I ran similar tests here and found that
> there was a major regression introduced near there but it was commit
> 05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter") that
> cause the problem and it was later reverted. On local tests on a 4-node
> machine, commit 3484b2de9499df23c4604a513b36f96326ae81ad was within 1%
> of the previous commit and well within the noise.
I have double checked the result before sending out.
Do you do the test with same kernel config and test case/parameters
(aim7/page_test/load 6000)?
Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] drm/panel: Add support for AUO b101ean01 panel
The AUO b101ean01 panel is a 10.1" 1280x800 panel,
which can be supported by the simple panel driver.
Signed-off-by: huang lin
---
Changes in v5:
- increase the vsync time
.../devicetree/bindings/panel/auo,b101ean01.txt| 7 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b101ean01.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b101ean01.txt
b/Documentation/devicetree/bindings/panel/auo,b101ean01.txt
new file mode 100644
index 000..3590b07
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101ean01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,b101ean01"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e95385b..375812b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -345,6 +345,29 @@ static const struct panel_desc auo_b101aw03 = {
},
};
+static const struct drm_display_mode auo_b101ean01_mode = {
+ .clock = 72500,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 119,
+ .hsync_end = 1280 + 119 + 32,
+ .htotal = 1280 + 119 + 32 + 21,
+ .vdisplay = 800,
+ .vsync_start = 800 + 4,
+ .vsync_end = 800 + 4 + 20,
+ .vtotal = 800 + 4 + 20 + 8,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b101ean01 = {
+ .modes = _b101ean01_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+};
+
static const struct drm_display_mode auo_b101xtn01_mode = {
.clock = 72000,
.hdisplay = 1366,
@@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = _b101aw03,
}, {
+ .compatible = "auo,b101ean01",
+ .data = _b101ean01,
+ }, {
.compatible = "auo,b101xtn01",
.data = _b101xtn01,
}, {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC] mm: change mm_advise_free to clear page dirty
> -Original Message-
> From: Michal Hocko [mailto:msts...@gmail.com] On Behalf Of Michal Hocko
> Sent: Saturday, February 28, 2015 5:03 AM
> To: Wang, Yalin
> Cc: 'Minchan Kim'; Andrew Morton; linux-kernel@vger.kernel.org; linux-
> m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
> Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
>
> On Fri 27-02-15 11:37:18, Wang, Yalin wrote:
> > This patch add ClearPageDirty() to clear AnonPage dirty flag,
> > the Anonpage mapcount must be 1, so that this page is only used by
> > the current process, not shared by other process like fork().
> > if not clear page dirty for this anon page, the page will never be
> > treated as freeable.
>
> Very well spotted! I haven't noticed that during the review.
>
> > Signed-off-by: Yalin Wang
> > ---
> > mm/madvise.c | 15 +--
> > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 6d0fcb8..257925a 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd,
> unsigned long addr,
> > continue;
> >
> > page = vm_normal_page(vma, addr, ptent);
> > - if (!page)
> > + if (!page || !PageAnon(page) || !trylock_page(page))
> > continue;
>
> PageAnon check seems to be redundant because we are not allowing
> MADV_FREE on any !anon private mappings AFAIR.
I only see this check:
/* MADV_FREE works for only anon vma at the moment */
if (vma->vm_file)
return -EINVAL;
but for file private map, there are also AnonPage sometimes, do we need change
to like this:
if (vma->vm_flags & VM_SHARED)
return -EINVAL;
> >
> > if (PageSwapCache(page)) {
> > - if (!trylock_page(page))
> > + if (!try_to_free_swap(page))
> > continue;
>
> You need to unlock the page here.
Good spot.
> > -
> > - if (!try_to_free_swap(page)) {
> > - unlock_page(page);
> > - continue;
> > - }
> > -
> > - ClearPageDirty(page);
> > - unlock_page(page);
> > }
> >
> > + if (page_mapcount(page) == 1)
> > + ClearPageDirty(page);
>
> Please add a comment about why we need to ClearPageDirty even
> !PageSwapCache. Anon pages are usually not marked dirty AFAIR. The
> reason seem to be racing try_to_free_swap which sets the page that way
> (although I do not seem to remember why are we doing that in the first
> place...)
>
Use page_mapcount to judge if a page can be clear dirty flag seems
Not a very good solution, that is because we don't know how many
ptes are share this page, I am thinking if there is some good solution
For shared AnonPage.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: cma: fix CMA aligned offset calculation
On Fri, Feb 27, 2015 at 5:18 PM, Andrew Morton wrote: > On Fri, 27 Feb 2015 17:07:28 -0800 Danesh Petigara > wrote: > >> On 2/27/2015 3:54 PM, Andrew Morton wrote: >> > On Fri, 27 Feb 2015 15:52:56 -0800 Danesh Petigara >> > wrote: >> > >> >> On 2/27/2015 1:24 PM, Andrew Morton wrote: >> >>> On Tue, 24 Feb 2015 15:39:45 -0800 Danesh Petigara >> >>> wrote: >> >>> >> The CMA aligned offset calculation is incorrect for >> non-zero order_per_bit values. >> >> For example, if cma->order_per_bit=1, cma->base_pfn= >> 0x2f80 and align_order=12, the function returns >> a value of 0x17c00 instead of 0x400. >> >> This patch fixes the CMA aligned offset calculation. >> >>> >> >>> When fixing a bug please always describe the end-user visible effects >> >>> of that bug. >> >>> >> >>> Without that information others are unable to understand why you are >> >>> recommending a -stable backport. >> >>> >> >> >> >> Thank you for the feedback. I had no crash logs to show, nevertheless, I >> >> agree that a sentence describing potential effects of the bug would've >> >> helped. >> > >> > What was the reason for adding a cc:stable? >> > >> >> It was added since the commit that introduced the incorrect logic >> (b5be83e) was already picked up by v3.19. > > argh. > > afaict the bug will, under some conditions cause cma_alloc() to report > that no suitable free area is available in the arena when in fact such > regions *are* available. So it's effectively a bogus ENOMEM. > > Correct? If so, what are the conditions under which this will occur? This is correct, and it can occur for any nonzero order_per_bit value. The previous calculation was wrong and would return too-large values for the offset, so that when cma_alloc looks for free pages in the bitmap with the requested alignment > order_per_bit, it starts too far into the bitmap and so CMA allocations will fail despite there actually being plenty of free pages remaining. It will also probably have the wrong alignment. With this change, we will get the correct offset into the bitmap. One affected user is powerpc KVM, which has kvm_cma->order_per_bit set to KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, or 18 - 12 = 6. I actually had written the offset function this way originally, then tried to make it more like cma_bitmap_aligned_mask(), but screwed up the transformation and it really wasn't any easier to understand anyway. That was stupid, sorry about that. =( Best regards, Gregory -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] seccomp: switch to using asm-generic for seccomp.h
On Fri, Feb 27, 2015 at 5:36 PM, Stephen Rothwell wrote: > Hi Kees, > > On Fri, 27 Feb 2015 16:52:29 -0800 Kees Cook wrote: >> >> diff --git a/arch/arm/include/asm/seccomp.h b/arch/arm/include/asm/seccomp.h >> index 52b156b341f5..66ca6a30bf5c 100644 >> --- a/arch/arm/include/asm/seccomp.h >> +++ b/arch/arm/include/asm/seccomp.h >> @@ -1,11 +1 @@ >> -#ifndef _ASM_ARM_SECCOMP_H >> -#define _ASM_ARM_SECCOMP_H >> - >> -#include >> - >> -#define __NR_seccomp_read __NR_read >> -#define __NR_seccomp_write __NR_write >> -#define __NR_seccomp_exit __NR_exit >> -#define __NR_seccomp_sigreturn __NR_rt_sigreturn >> - >> -#endif /* _ASM_ARM_SECCOMP_H */ >> +#include > > I think that these cases (where you replace the file by a stub that > just include ) can be replaced by removing the > file completely and adding > > generic-y = seccomp.h > > to /include/asm/Kbuild Ah-ha! I thought total removal was possible, but I lacked the Kbuild piece. There are a lot of arch/ headers that are just the one line. Maybe I should send a another patch to clean up those? -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] introduce dynamic device creation/removal
On (02/28/15 10:33), Sergey Senozhatsky wrote: > > hoo boy. Creating a /dev node and doing ioctls on it is really old > > school. So old school that I've forgotten why we don't do it any more. > > > > Hopefully Alan can recall the thinking? > > oh. I thought this is how loop control works, and ioctl there doesn't look > insane to me. > > any quick hint how do you do this in a modern world so I'll redo the patch > set? > I'll change it to sysfs RW control node. -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
On Fri, Feb 27, 2015 at 03:21:36PM +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone fields
> into read-only, page alloc, statistics and page reclaim lines")
>
> The perf cpu-cycles for spinlock (zone->lock) increased a lot. I suspect
> there are some cache ping-pong or false sharing.
>
Are you sure about this result? I ran similar tests here and found that
there was a major regression introduced near there but it was commit
05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter") that
cause the problem and it was later reverted. On local tests on a 4-node
machine, commit 3484b2de9499df23c4604a513b36f96326ae81ad was within 1%
of the previous commit and well within the noise.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] seccomp: switch to using asm-generic for seccomp.h
Hi Kees, On Fri, 27 Feb 2015 16:52:29 -0800 Kees Cook wrote: > > diff --git a/arch/arm/include/asm/seccomp.h b/arch/arm/include/asm/seccomp.h > index 52b156b341f5..66ca6a30bf5c 100644 > --- a/arch/arm/include/asm/seccomp.h > +++ b/arch/arm/include/asm/seccomp.h > @@ -1,11 +1 @@ > -#ifndef _ASM_ARM_SECCOMP_H > -#define _ASM_ARM_SECCOMP_H > - > -#include > - > -#define __NR_seccomp_read __NR_read > -#define __NR_seccomp_write __NR_write > -#define __NR_seccomp_exit __NR_exit > -#define __NR_seccomp_sigreturn __NR_rt_sigreturn > - > -#endif /* _ASM_ARM_SECCOMP_H */ > +#include I think that these cases (where you replace the file by a stub that just include ) can be replaced by removing the file completely and adding generic-y = seccomp.h to /include/asm/Kbuild -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpbqoTo1Yxgt.pgp Description: OpenPGP digital signature
Re: [PATCH 0/8] introduce dynamic device creation/removal
On (02/27/15 14:51), Andrew Morton wrote: > hoo boy. Creating a /dev node and doing ioctls on it is really old > school. So old school that I've forgotten why we don't do it any more. > > Hopefully Alan can recall the thinking? oh. I thought this is how loop control works, and ioctl there doesn't look insane to me. any quick hint how do you do this in a modern world so I'll redo the patch set? -ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: cma: fix CMA aligned offset calculation
On Fri, 27 Feb 2015 17:07:28 -0800 Danesh Petigara wrote: > On 2/27/2015 3:54 PM, Andrew Morton wrote: > > On Fri, 27 Feb 2015 15:52:56 -0800 Danesh Petigara > > wrote: > > > >> On 2/27/2015 1:24 PM, Andrew Morton wrote: > >>> On Tue, 24 Feb 2015 15:39:45 -0800 Danesh Petigara > >>> wrote: > >>> > The CMA aligned offset calculation is incorrect for > non-zero order_per_bit values. > > For example, if cma->order_per_bit=1, cma->base_pfn= > 0x2f80 and align_order=12, the function returns > a value of 0x17c00 instead of 0x400. > > This patch fixes the CMA aligned offset calculation. > >>> > >>> When fixing a bug please always describe the end-user visible effects > >>> of that bug. > >>> > >>> Without that information others are unable to understand why you are > >>> recommending a -stable backport. > >>> > >> > >> Thank you for the feedback. I had no crash logs to show, nevertheless, I > >> agree that a sentence describing potential effects of the bug would've > >> helped. > > > > What was the reason for adding a cc:stable? > > > > It was added since the commit that introduced the incorrect logic > (b5be83e) was already picked up by v3.19. argh. afaict the bug will, under some conditions cause cma_alloc() to report that no suitable free area is available in the arena when in fact such regions *are* available. So it's effectively a bogus ENOMEM. Correct? If so, what are the conditions under which this will occur? This isn't hard - I want to know what the patch *does*! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Communication Framework: fix semicolon.cocci warnings
drivers/md/md-cluster.c:328:2-3: Unneeded semicolon
Removes unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Signed-off-by: Fengguang Wu
---
md-cluster.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -325,7 +325,7 @@ static void process_recvd_msg(struct mdd
pr_info("%s: %d Received message: RESYNCING from %d\n",
__func__, __LINE__, msg->slot);
break;
- };
+ }
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: cma: fix CMA aligned offset calculation
On 2/27/2015 3:54 PM, Andrew Morton wrote: > On Fri, 27 Feb 2015 15:52:56 -0800 Danesh Petigara > wrote: > >> On 2/27/2015 1:24 PM, Andrew Morton wrote: >>> On Tue, 24 Feb 2015 15:39:45 -0800 Danesh Petigara >>> wrote: >>> The CMA aligned offset calculation is incorrect for non-zero order_per_bit values. For example, if cma->order_per_bit=1, cma->base_pfn= 0x2f80 and align_order=12, the function returns a value of 0x17c00 instead of 0x400. This patch fixes the CMA aligned offset calculation. >>> >>> When fixing a bug please always describe the end-user visible effects >>> of that bug. >>> >>> Without that information others are unable to understand why you are >>> recommending a -stable backport. >>> >> >> Thank you for the feedback. I had no crash logs to show, nevertheless, I >> agree that a sentence describing potential effects of the bug would've >> helped. > > What was the reason for adding a cc:stable? > It was added since the commit that introduced the incorrect logic (b5be83e) was already picked up by v3.19. Thanks, Danesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fs: dax: do not build on ARC or SH
On Mon, 2015-02-23 at 12:29 +0100, Arnd Bergmann wrote: > The DAX implementation relies on the architecture to provide a working > copy_user_page() function, as reported by Michael Ellerman's kisskb > build bot: > > fs/dax.c: error: implicit declaration of function 'copy_user_page' > [-Werror=implicit-function-declaration]: => 266:2 > > We already have a list of architectures that are known to be incompatible, > but the list is missing ARC and SH at the moment. Further, blackfin and > c6x also lack support for this function, but are already excluded because > they do not support MMU-based kernels. > > Signed-off-by: Arnd Bergmann > Reported-by: Geert Uytterhoeven > Acked-by: Geert Uytterhoeven > --- > diff --git a/fs/Kconfig b/fs/Kconfig > index ec35851e5b71..a24d496787d6 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -36,7 +36,7 @@ source "fs/nilfs2/Kconfig" > config FS_DAX > bool "Direct Access (DAX) support" > depends on MMU > - depends on !(ARM || MIPS || SPARC) > + depends on !(ARC || ARM || MIPS || SH || SPARC) Did you mean SUPERH? > help > Direct Access (DAX) can be used on memory-backed block devices. > If the block device supports DAX and the filesystem supports DAX, > Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PULL] Yama update (4.0)
Hi, Please pull these yama changes for 4.0. Thanks! -Kees The following changes since commit 04f81f0154e4bf002be6f4d85668ce1257efa4d9: cipso: don't use IPCB() to locate the CIPSO IP option (2015-02-11 14:46:37 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/yama-4.0 for you to fetch changes up to 44aa1d4413876cca0962debc9483ba009d71737f: security/yama: Remove unnecessary selects from Kconfig. (2015-02-27 16:53:10 -0800) yama fixes Kees Cook (1): Yama: do not modify global sysctl table entry Stephen Smalley (1): security/yama: Remove unnecessary selects from Kconfig. security/yama/Kconfig| 2 -- security/yama/yama_lsm.c | 13 + 2 files changed, 5 insertions(+), 10 deletions(-) -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] seccomp: switch to using asm-generic for seccomp.h
Most architectures don't need to do anything special for the strict seccomp syscall entries. Remove the redundant headers and reduce the others. Signed-off-by: Kees Cook --- arch/arm/include/asm/seccomp.h | 12 +--- arch/microblaze/include/asm/seccomp.h | 17 + arch/mips/include/asm/seccomp.h | 7 ++- arch/parisc/include/asm/seccomp.h | 17 + arch/powerpc/include/asm/seccomp.h | 1 + arch/powerpc/include/uapi/asm/Kbuild| 1 - arch/powerpc/include/uapi/asm/seccomp.h | 16 arch/s390/include/asm/seccomp.h | 17 + arch/sh/include/asm/seccomp.h | 11 +-- arch/sparc/include/asm/seccomp.h| 16 +--- arch/x86/include/asm/seccomp.h | 21 ++--- arch/x86/include/asm/seccomp_32.h | 11 --- arch/x86/include/asm/seccomp_64.h | 17 - 13 files changed, 27 insertions(+), 137 deletions(-) create mode 100644 arch/powerpc/include/asm/seccomp.h delete mode 100644 arch/powerpc/include/uapi/asm/seccomp.h delete mode 100644 arch/x86/include/asm/seccomp_32.h delete mode 100644 arch/x86/include/asm/seccomp_64.h diff --git a/arch/arm/include/asm/seccomp.h b/arch/arm/include/asm/seccomp.h index 52b156b341f5..66ca6a30bf5c 100644 --- a/arch/arm/include/asm/seccomp.h +++ b/arch/arm/include/asm/seccomp.h @@ -1,11 +1 @@ -#ifndef _ASM_ARM_SECCOMP_H -#define _ASM_ARM_SECCOMP_H - -#include - -#define __NR_seccomp_read __NR_read -#define __NR_seccomp_write __NR_write -#define __NR_seccomp_exit __NR_exit -#define __NR_seccomp_sigreturn __NR_rt_sigreturn - -#endif /* _ASM_ARM_SECCOMP_H */ +#include diff --git a/arch/microblaze/include/asm/seccomp.h b/arch/microblaze/include/asm/seccomp.h index 0d912758a0d7..66ca6a30bf5c 100644 --- a/arch/microblaze/include/asm/seccomp.h +++ b/arch/microblaze/include/asm/seccomp.h @@ -1,16 +1 @@ -#ifndef _ASM_MICROBLAZE_SECCOMP_H -#define _ASM_MICROBLAZE_SECCOMP_H - -#include - -#define __NR_seccomp_read __NR_read -#define __NR_seccomp_write __NR_write -#define __NR_seccomp_exit __NR_exit -#define __NR_seccomp_sigreturn __NR_sigreturn - -#define __NR_seccomp_read_32 __NR_read -#define __NR_seccomp_write_32 __NR_write -#define __NR_seccomp_exit_32 __NR_exit -#define __NR_seccomp_sigreturn_32 __NR_sigreturn - -#endif /* _ASM_MICROBLAZE_SECCOMP_H */ +#include diff --git a/arch/mips/include/asm/seccomp.h b/arch/mips/include/asm/seccomp.h index f29c75cf83c6..1d8a2e2c75c1 100644 --- a/arch/mips/include/asm/seccomp.h +++ b/arch/mips/include/asm/seccomp.h @@ -2,11 +2,6 @@ #include -#define __NR_seccomp_read __NR_read -#define __NR_seccomp_write __NR_write -#define __NR_seccomp_exit __NR_exit -#define __NR_seccomp_sigreturn __NR_rt_sigreturn - /* * Kludge alert: * @@ -29,4 +24,6 @@ #endif /* CONFIG_MIPS32_O32 */ +#include + #endif /* __ASM_SECCOMP_H */ diff --git a/arch/parisc/include/asm/seccomp.h b/arch/parisc/include/asm/seccomp.h index 015f7887aa29..66ca6a30bf5c 100644 --- a/arch/parisc/include/asm/seccomp.h +++ b/arch/parisc/include/asm/seccomp.h @@ -1,16 +1 @@ -#ifndef _ASM_PARISC_SECCOMP_H -#define _ASM_PARISC_SECCOMP_H - -#include - -#define __NR_seccomp_read __NR_read -#define __NR_seccomp_write __NR_write -#define __NR_seccomp_exit __NR_exit -#define __NR_seccomp_sigreturn __NR_rt_sigreturn - -#define __NR_seccomp_read_32 __NR_read -#define __NR_seccomp_write_32 __NR_write -#define __NR_seccomp_exit_32 __NR_exit -#define __NR_seccomp_sigreturn_32 __NR_rt_sigreturn - -#endif /* _ASM_PARISC_SECCOMP_H */ +#include diff --git a/arch/powerpc/include/asm/seccomp.h b/arch/powerpc/include/asm/seccomp.h new file mode 100644 index ..66ca6a30bf5c --- /dev/null +++ b/arch/powerpc/include/asm/seccomp.h @@ -0,0 +1 @@ +#include diff --git a/arch/powerpc/include/uapi/asm/Kbuild b/arch/powerpc/include/uapi/asm/Kbuild index 7a3f795ac218..79c4068be278 100644 --- a/arch/powerpc/include/uapi/asm/Kbuild +++ b/arch/powerpc/include/uapi/asm/Kbuild @@ -25,7 +25,6 @@ header-y += posix_types.h header-y += ps3fb.h header-y += ptrace.h header-y += resource.h -header-y += seccomp.h header-y += sembuf.h header-y += setup.h header-y += shmbuf.h diff --git a/arch/powerpc/include/uapi/asm/seccomp.h b/arch/powerpc/include/uapi/asm/seccomp.h deleted file mode 100644 index 00c1d9133cfe.. --- a/arch/powerpc/include/uapi/asm/seccomp.h +++ /dev/null @@ -1,16 +0,0 @@ -#ifndef _ASM_POWERPC_SECCOMP_H -#define _ASM_POWERPC_SECCOMP_H - -#include - -#define __NR_seccomp_read __NR_read -#define __NR_seccomp_write __NR_write -#define __NR_seccomp_exit __NR_exit -#define __NR_seccomp_sigreturn __NR_rt_sigreturn - -#define __NR_seccomp_read_32 __NR_read -#define __NR_seccomp_write_32 __NR_write -#define __NR_seccomp_exit_32 __NR_exit -#define __NR_seccomp_sigreturn_32 __NR_sigreturn - -#endif /*
Re: [GIT PULL] clk/samsung: clk support for Exynos 5433 SoC
Dear Mike and Sylwester,
Gently ping.
Best Regards,
Chanwoo Choi
On Tue, Feb 24, 2015 at 8:48 AM, Chanwoo Choi wrote:
> Dear Mike and Sylwester,
>
> This pull-request was not merged on Linux 4.0-rc1.
> Did you have any plan about it?
>
> Best Regards,
> Chanwoo Choi
>
> On 02/06/2015 04:44 AM, Sylwester Nawrocki wrote:
>> Hi Mike,
>>
>> This pull request includes driver for clock controller of the Exynos
>> 5433 SoC. As the hardware is quite complex, with many peripherals and
>> corresponding clock management units the driver is rather huge. I guess
>> it will require a bit more cleanups than last time to balance lines
>> introduced in this patch set... Please review and pull if it looks OK.
>>
>> The following changes since commit e64fb42da4c6c713cfc7cad607e97e0773fa41ff:
>>
>> clk: samsung: exynos4: Add divider clock id for memory bus frequency
>> (2015-01-28 15:51:17 +0100)
>>
>> are available in the git repository at:
>>
>> git://linuxtv.org/snawrocki/samsung.git tags/v3.20-exynos5433-clk
>>
>> for you to fetch changes up to b2f0e5f28e0686c0d5db238357a2e32555e97633:
>>
>> clk: samsung: exynos5433: Move CLK_SCLK_HDMI_SPDIF_DISP clock to CMU_TOP
>> domain (2015-02-05 19:31:09 +0100)
>>
>>
>> Clock controller driver for Exynos 5433 SoC.
>>
>>
>> Chanwoo Choi (22):
>> clk: samsung: exynos5433: Add binding document for Exynos5433 clock
>> domains
>> clk: samsung: exynos5433: Add clocks using common clock framework
>> clk: samsung: exynos5433: Add MUX clocks of CMU_TOP domain
>> clk: samsung: exynos5433: Add clocks for CMU_PERIC domain
>> clk: samsung: exynos5433: Add clocks for CMU_PERIS domain
>> clk: samsung: exynos5433: Add clocks for CMU_G2D domain
>> clk: samsung: exynos5433: Add clocks for CMU_MIF domain
>> clk: samsung: exynos5433: Add clocks for CMU_DISP domain
>> clk: samsung: exynos5433: Add clocks for CMU_AUD domain
>> clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
>> clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain
>> clk: samsung: exynos5433: Add clocks for CMU_G3D domain
>> clk: samsung: exynos5433: Add clocks for CMU_GSCL domain
>> clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
>> clk: samsung: exynos5433: Add clocks for CMU_ATLAS domain
>> clk: samsung: exynos5433: Add clocks for CMU_MSCL domain
>> clk: samsung: exynos5433: Add clocks for CMU_MFC domain
>> clk: samsung: exynos5433: Add clocks for CMU_HEVC domain
>> clk: samsung: exynos5433: Add clocks for CMU_ISP domain
>> clk: samsung: exynos5433: Add clocks for CMU_CAM0 domain
>> clk: samsung: exynos5433: Add clocks for CMU_CAM1 domain
>> clk: samsung: exynos5433: Move CLK_SCLK_HDMI_SPDIF_DISP clock to
>> CMU_TOP domain
>>
>> Inha Song (1):
>> clk: samsung: Add CLKOUT driver support for Exynos5433 SoC
>>
>> .../devicetree/bindings/clock/exynos5433-clock.txt | 462 ++
>> drivers/clk/samsung/Makefile |1 +
>> drivers/clk/samsung/clk-exynos-clkout.c|2 +
>> drivers/clk/samsung/clk-exynos5433.c | 5423
>>
>> include/dt-bindings/clock/exynos5433.h | 1403 +
>> 5 files changed, 7291 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/clock/exynos5433-clock.txt
>> create mode 100644 drivers/clk/samsung/clk-exynos5433.c
>> create mode 100644 include/dt-bindings/clock/exynos5433.h
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/8] arm64: exynos5433: Enable ARMv8 based Exynos5433 (SoC) support
Hi Kukjin and Sylwester,
On Thu, Feb 26, 2015 at 5:28 PM, Chanwoo Choi wrote:
> On 02/24/2015 05:31 PM, Arnd Bergmann wrote:
>> On Tuesday 24 February 2015 14:16:44 Chanwoo Choi wrote:
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 1b8e973..d83cea0 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -154,6 +154,17 @@ config ARCH_EXYNOS
>>> help
>>> This enables support for Samsung Exynos SoC family
>>>
>>> +config ARCH_EXYNOS5433
>>> + bool "ARMv8 based Samsung Exynos5433"
>>> + select ARCH_EXYNOS
>>> + select COMMON_CLK_SAMSUNG
>>> + select HAVE_S3C_RTC if RTC_CLASS
>>> + select PINCTRL
>>> + select PINCTRL_EXYNOS
>>> +
>>> + help
>>> + This enables support for Samsung Exynos5433 SoC family
>>> +
>>> config ARCH_EXYNOS7
>>> bool "ARMv8 based Samsung Exynos7"
>>> select ARCH_EXYNOS
>>> --
>>>
>>
>> Can we collapse all these entries into one for EXYNOS? I don't
>> want to end up with endless lists like we have on arm32 when
>> there is no platform specific code that is actually controlled
>> by this anway.
>
> I agree.
>
> I check the some issue for only using the CONFIG_ARCH_EXYNOS
> insead of CONFIG_ARCH_EXYNOS7 and CONFIG_ARCH_EXYNOS5433.
>
> Each CONFIG_ARCH_EXYNOS{7|5433} configuraiton was used on following list:
> - CONFIG_ARCH_EXYNOS7
> arch/arm64/boot/dts/exynos/Makefile:1:dtb-$(CONFIG_ARCH_EXYNOS7) +=
> exynos7-espresso.dtb
> drivers/clk/samsung/Makefile:17:obj-$(CONFIG_ARCH_EXYNOS7) +=
> clk-exynos7.o
> - CONFIG_ARCH_EXYNOS5433
> drivers/clk/samsung/Makefile:13:obj-$(CONFIG_ARCH_EXYNOS5433) +=
> clk-exynos5433.o
>
> We may can fix it as following by only using 'CONFIG_ARCH_EXYNOS' without any
> specific configuration.
>
> arch/arm64/boot/dts/exynos/Makefile:1:dtb-$(CONFIG_ARCH_EXYNOS) +=
> exynos7-espresso.dtb
> drivers/clk/samsung/Makefile:17:obj-$(CONFIG_ARCH_EXYNOS) +=
> clk-exynos7.o clk-exynos5433.o
>
> I think that we need the opinion of Kukjin Kim (Exynos SoC Maintainer)
> and Sylwester Nawrocki(Samsung clock Maintainer)
I need yout opinion about using the CONFIG_ARCH_EXYNOS
instead of CONFIG_ARCH_EXYNOS7/CONFIG_ARCH_EXYNOS5433?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/8] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Fri, Feb 27, 2015 at 12:42 AM, Arnd Bergmann wrote:
> On Thursday 26 February 2015 17:18:41 Chanwoo Choi wrote:
>> I add following aliases and serial_1/serial_3 dt node in board dtsi:
>> I tested that change the alias of serial_x node.
>>
>> aliases {
>> serial0 = _1;
>> serial1 = _3;
>> };
>>
>> /* Add 'linux,stdout-path' property to print kernel log by using
>> ealycon */
>> chosen {
>> linux,stdout-path = _1;
>> };
>>
>> [snip]
>>
>> /* serial_1 is used for printing kernel log throught JIG cable */
>> _1 {
>> status = "okay";
>> };
>>
>> _3 {
>> status = "okay";
>> };
>>
>> In result, serial driver create the /dev/ttySAC0 for serial_1 and
>> /dev/ttySAC1 for serial_3.
>> But, I cannot complete the kernel booting and stop it with following kernel
>> log
>>
>> [0.00] Booting Linux on physical CPU 0x100
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 4.0.0-rc1-00066-g49bfcec-dirty (cwchoi00@chan)
>> (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG l5
>> [snip]
>> [0.00] Kernel command line: console=ttySAC1,115200
>> earlycon=exynos4210,0x14C2
>
> What is the "earlycon=exynos4210,0x14C2" doing here? Should that not just
> be
> "earlycon=exynos" or something like that when you set the correct stdout-path?
"earlycon=exynos4210,0x14C2" is correct bootparam. You can check
it on Documentation/kernel-parameters.txt as following.
exynos4210,
Use early console provided by serial driver available
on Samsung SoCs, requires selecting proper type and
a correct base address of the selected UART port. The
serial port must already be setup and configured.
Options are not yet supported.
>
>> [snip]
>> [0.651647] dma-pl330 1561.pdma: Loaded driver for PL330 DMAC-341330
>> [0.651851] dma-pl330 1561.pdma: DBUFF-32x4bytes Num_Chans-8
>> Num_Peri-32 Num_Events-32
>> [0.658566] dma-pl330 1560.pdma: Loaded driver for PL330 DMAC-341330
>> [0.662872] dma-pl330 1560.pdma: DBUFF-32x4bytes Num_Chans-8
>> Num_Peri-32 Num_Events-32
>> [0.672487] dma-pl330 1142.adma: Loaded driver for PL330 DMAC-341330
>> [ 8466.414900] dma-pl330 1142.adma: DBUFF-8x8bytes Num_Chans-8
>> Num_Peri-16 Num_Events-8
>> [ 8466.481648] 14c2.serial: ttySAC0 at MMIO 0x14c2 (irq = 21,
>> base_baud = 0) is a S3C6400/10
>> (dont' print any kernel log)
>>
>> So, I change the kernel command line about ('console' bootparam) as
>> following:
>> because tty framework must use the 'console' bootparam to print kernel log.
>> - original : Kernel command line: console=ttySAC1,115200 ... (cannot the
>> kernel log from serial driver probed)
>> - modification : Kernel command line: console=ttySAC0,115200 ... (got the
>> successful kernel booting)
>>
>> After modification, I got the successful kernel booting.
>>
>> If should use the serial_0 device and then modify the 'aliases' as following:
>> I have to modify the commandline of bootloader if the commandline of
>> bootloader is used
>> instad of default kernel command line.
>>
>> aliases {
>> serial0 = _0;
>> serial1 = _1;
>> serial2 = _3;
>> };
>
> If you need the numbers to match, maybe there is still a bug in the serial
> port
> driver and it uses some arbitrary number (e.g. probe order, or ascending
> MMIO address) for the console instead of the alias?
The serial port driver request the 'tty' device information to print kernel log.
So, bootloader is supposed to pass the 'tty' device as upper example.
But, The bootloader could not get the the 'alias' information in board dtsi.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] x86: do not save callee-preserved registers around lockdep_sys_exit_thunk
Internally, lockdep_sys_exit_thunk saves callee-clobbered registers, and calls a C function, lockdep_sys_exix. Thus, callee-preserved won't be mangled, there is no need to save them. Patch was run-tested. Signed-off-by: Denys Vlasenko CC: Linus Torvalds CC: Steven Rostedt CC: Ingo Molnar CC: Borislav Petkov CC: "H. Peter Anvin" CC: Andy Lutomirski CC: Oleg Nesterov CC: Frederic Weisbecker CC: Alexei Starovoitov CC: Will Drewry CC: Kees Cook CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/include/asm/irqflags.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h index 19355f3..9a63eae 100644 --- a/arch/x86/include/asm/irqflags.h +++ b/arch/x86/include/asm/irqflags.h @@ -179,9 +179,7 @@ static inline int arch_irqs_disabled(void) #define LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ sti; \ - SAVE_EXTRA_REGS; \ call lockdep_sys_exit_thunk; \ - RESTORE_EXTRA_REGS; \ cli; \ TRACE_IRQS_OFF; # else -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] x86: do not save callee-preserved registers around lockdep_sys_exit_thunk
Recent change to struct pt_regs handling in entry.S, among other things, changed how callee-preserved registers are saved around call to lockdep_sys_exit_thunk: #define LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ sti; \ SAVE_EXTRA_REGS; \<=== HERE LOCKDEP_SYS_EXIT; \ RESTORE_EXTRA_REGS; \ <=== HERE The change is in fact a bit fragile: now we assume that LOCKDEP_SYS_EXIT_IRQ macro is used only when there is a struct pt_regs on the stack. So far this assumption is true, but it is probably a coincidence. We can revert back to pushing registers, but this callee-preserved registers saving appears bogus. It is not necessary: they _are_ callee-preserved, and lockdep_sys_exit() does not touch them on the stack either. First two patches clean up #define maze so that we can see that LOCKDEP_SYS_EXIT macro call above is merely "call lockdep_sys_exit_thunk". Last patch removes SAVE/RESTORE. I tested this patch series and everything seems to run fine on a lockdep-enabled kernel with these lines removed. Denys Vlasenko (3): x86: move ARCH_LOCKDEP_SYS_EXIT[IRQ] defines closer to their users x86: fold ARCH_LOCKDEP_SYS_EXIT defines into their users x86: do not save callee-preserved registers around lockdep_sys_exit_thunk arch/x86/include/asm/irqflags.h | 45 + 1 file changed, 19 insertions(+), 26 deletions(-) CC: Linus Torvalds CC: Steven Rostedt CC: Ingo Molnar CC: Borislav Petkov CC: "H. Peter Anvin" CC: Andy Lutomirski CC: Oleg Nesterov CC: Frederic Weisbecker CC: Alexei Starovoitov CC: Will Drewry CC: Kees Cook CC: x...@kernel.org CC: linux-kernel@vger.kernel.org -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] x86: move ARCH_LOCKDEP_SYS_EXIT[IRQ] defines closer to their users
This change simply moves defines around (even if it's not obvious in a patch form). Nothing is changed. This is a preparation for folding ARCH_LOCKDEP_SYS_EXIT defines into their users. Signed-off-by: Denys Vlasenko CC: Linus Torvalds CC: Steven Rostedt CC: Ingo Molnar CC: Borislav Petkov CC: "H. Peter Anvin" CC: Andy Lutomirski CC: Oleg Nesterov CC: Frederic Weisbecker CC: Alexei Starovoitov CC: Will Drewry CC: Kees Cook CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/include/asm/irqflags.h | 37 + 1 file changed, 17 insertions(+), 20 deletions(-) diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h index 021bee9..55866c2 100644 --- a/arch/x86/include/asm/irqflags.h +++ b/arch/x86/include/asm/irqflags.h @@ -163,12 +163,20 @@ static inline int arch_irqs_disabled(void) return arch_irqs_disabled_flags(flags); } +#endif /* !__ASSEMBLY__ */ +#ifdef __ASSEMBLY__ +#ifdef CONFIG_TRACE_IRQFLAGS +# define TRACE_IRQS_ONcall trace_hardirqs_on_thunk; +# define TRACE_IRQS_OFF call trace_hardirqs_off_thunk; #else - -#ifdef CONFIG_X86_64 -#define ARCH_LOCKDEP_SYS_EXIT call lockdep_sys_exit_thunk -#define ARCH_LOCKDEP_SYS_EXIT_IRQ \ +# define TRACE_IRQS_ON +# define TRACE_IRQS_OFF +#endif +#ifdef CONFIG_DEBUG_LOCK_ALLOC +# ifdef CONFIG_X86_64 +#define ARCH_LOCKDEP_SYS_EXIT call lockdep_sys_exit_thunk +#define ARCH_LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ sti; \ SAVE_EXTRA_REGS; \ @@ -176,9 +184,8 @@ static inline int arch_irqs_disabled(void) RESTORE_EXTRA_REGS; \ cli; \ TRACE_IRQS_OFF; - -#else -#define ARCH_LOCKDEP_SYS_EXIT \ +# else +#define ARCH_LOCKDEP_SYS_EXIT \ pushl %eax; \ pushl %ecx; \ pushl %edx; \ @@ -186,24 +193,14 @@ static inline int arch_irqs_disabled(void) popl %edx; \ popl %ecx; \ popl %eax; - -#define ARCH_LOCKDEP_SYS_EXIT_IRQ -#endif - -#ifdef CONFIG_TRACE_IRQFLAGS -# define TRACE_IRQS_ONcall trace_hardirqs_on_thunk; -# define TRACE_IRQS_OFF call trace_hardirqs_off_thunk; -#else -# define TRACE_IRQS_ON -# define TRACE_IRQS_OFF -#endif -#ifdef CONFIG_DEBUG_LOCK_ALLOC +#define ARCH_LOCKDEP_SYS_EXIT_IRQ +# endif # define LOCKDEP_SYS_EXIT ARCH_LOCKDEP_SYS_EXIT # define LOCKDEP_SYS_EXIT_IRQ ARCH_LOCKDEP_SYS_EXIT_IRQ # else # define LOCKDEP_SYS_EXIT # define LOCKDEP_SYS_EXIT_IRQ # endif - #endif /* __ASSEMBLY__ */ + #endif -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] x86: fold ARCH_LOCKDEP_SYS_EXIT defines into their users
There is no need to have an extra level of macro indirection here. Signed-off-by: Denys Vlasenko CC: Linus Torvalds CC: Steven Rostedt CC: Ingo Molnar CC: Borislav Petkov CC: "H. Peter Anvin" CC: Andy Lutomirski CC: Oleg Nesterov CC: Frederic Weisbecker CC: Alexei Starovoitov CC: Will Drewry CC: Kees Cook CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/include/asm/irqflags.h | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h index 55866c2..19355f3 100644 --- a/arch/x86/include/asm/irqflags.h +++ b/arch/x86/include/asm/irqflags.h @@ -175,17 +175,17 @@ static inline int arch_irqs_disabled(void) #endif #ifdef CONFIG_DEBUG_LOCK_ALLOC # ifdef CONFIG_X86_64 -#define ARCH_LOCKDEP_SYS_EXIT call lockdep_sys_exit_thunk -#define ARCH_LOCKDEP_SYS_EXIT_IRQ \ +#define LOCKDEP_SYS_EXIT call lockdep_sys_exit_thunk +#define LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ sti; \ SAVE_EXTRA_REGS; \ - LOCKDEP_SYS_EXIT; \ + call lockdep_sys_exit_thunk; \ RESTORE_EXTRA_REGS; \ cli; \ TRACE_IRQS_OFF; # else -#define ARCH_LOCKDEP_SYS_EXIT \ +#define LOCKDEP_SYS_EXIT \ pushl %eax; \ pushl %ecx; \ pushl %edx; \ @@ -193,14 +193,12 @@ static inline int arch_irqs_disabled(void) popl %edx; \ popl %ecx; \ popl %eax; -#define ARCH_LOCKDEP_SYS_EXIT_IRQ +#define LOCKDEP_SYS_EXIT_IRQ # endif -# define LOCKDEP_SYS_EXIT ARCH_LOCKDEP_SYS_EXIT -# define LOCKDEP_SYS_EXIT_IRQ ARCH_LOCKDEP_SYS_EXIT_IRQ -# else +#else # define LOCKDEP_SYS_EXIT # define LOCKDEP_SYS_EXIT_IRQ -# endif +#endif #endif /* __ASSEMBLY__ */ #endif -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip 0/7] tracing: attach eBPF programs to kprobes
On Fri, Feb 27, 2015 at 4:08 PM, Alexei Starovoitov wrote:
> Hi All,
>
> This is targeting 'tip' tree, since most of the changes are perf_event
> related.
>
> V3 discussion:
> https://lkml.org/lkml/2015/2/9/738
>
> V3->V4:
> - since the boundary of stable ABI in bpf+tracepoints is not clear yet,
> I've dropped them for now.
> - bpf+syscalls are ok from stable ABI point of view, but bpf+seccomp
> would want to do very similar analysis of syscalls, so I've dropped
> them as well to take time and define common bpf+syscalls and bpf+seccomp
> infra in the future.
> - so only bpf+kprobes left. kprobes by definition is not a stable ABI,
> so bpf+kprobe is not stable ABI either. To stress on that point added
> kernel version attribute that user space must pass along with the program
> and kernel will reject programs when version code doesn't match.
> So bpf+kprobe is very similar to kernel modules, but unlike modules
> version check is not used for safety, but for enforcing 'non-ABI-ness'.
> (version check doesn't apply to bpf+sockets which are stable)
>
> 1st patch of this set is going to be shared between net-next and tip trees,
> since
> patch 2 depends on it.
>
> Patch 2 actually adds bpf+kprobe infra:
> programs receive 'struct pt_regs' on input and can walk data structures
> using bpf_probe_read() helper which is a wrapper of probe_kernel_read()
>
> Programs are attached to kprobe events via API:
>
> prog_fd = bpf_prog_load(...);
> struct perf_event_attr attr = {
> .type = PERF_TYPE_TRACEPOINT,
> .config = event_id, /* ID of just created kprobe event */
> };
> event_fd = perf_event_open(,...);
> ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
>
> Patch 3 adds bpf_ktime_get_ns() helper function, so that bpf programs can
> measure time delta between events to compute disk io latency, etc.
>
> Patch 4 adds bpf_trace_printk() helper that is used to debug programs.
> When bpf verifier sees that program is calling bpf_trace_printk() it inits
> trace_printk buffers which emits nasty 'this is debug only' banner.
> That's exactly what we want. bpf_trace_printk() is for debugging only.
>
> Patch 5 sample code that shows how to use bpf_probe_read/bpf_trace_printk
>
> Patch 6 sample code - combination of kfree_skb and sys_write tracing.
>
> Patch 7 sample code that computes disk io latency and prints it as 'heatmap'
>
> Interesting bit is that patch 6 has log2() function implemented in C
> and patch 7 has another log2() function using different algorithm in C.
> In the future if 'log2' usage becomes common, we can add it as in-kernel
> helper function, but for now bpf programs can implement them on bpf side.
>
> Another interesting bit from patch 7 is that it does approximation of
> floating point log10(X)*10 using integer arithmetic, which demonstrates
> the power of C->BPF vs traditional tracing language alternatives,
> where one would need to introduce new helper functions to add functionality,
> whereas bpf can just implement such things in C as part of the program.
>
> Next step is to prototype TCP stack instrumentation (like web10g) using
> bpf+kprobe, but without adding any new code tcp stack.
> Though kprobes are slow comparing to tracepoints, they are good enough
> for prototyping and trace_marker/debug_tracepoint ideas can accelerate
> them in the future.
>
> Alexei Starovoitov (6):
> tracing: attach BPF programs to kprobes
> tracing: allow BPF programs to call ktime_get_ns()
> tracing: allow BPF programs to call bpf_trace_printk()
> samples: bpf: simple non-portable kprobe filter example
> samples: bpf: counting example for kfree_skb and write syscall
> samples: bpf: IO latency analysis (iosnoop/heatmap)
>
> Daniel Borkmann (1):
> bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
>
> include/linux/bpf.h | 20 -
> include/linux/ftrace_event.h| 14
> include/uapi/linux/bpf.h|5 ++
> include/uapi/linux/perf_event.h |1 +
> kernel/bpf/syscall.c|7 +-
> kernel/events/core.c| 59 +
> kernel/trace/Makefile |1 +
> kernel/trace/bpf_trace.c| 177
> +++
> kernel/trace/trace_kprobe.c | 10 ++-
> samples/bpf/Makefile| 12 +++
> samples/bpf/bpf_helpers.h |6 ++
> samples/bpf/bpf_load.c | 112 +++--
> samples/bpf/bpf_load.h |3 +
> samples/bpf/libbpf.c| 10 ++-
> samples/bpf/libbpf.h|5 +-
> samples/bpf/sock_example.c |2 +-
> samples/bpf/test_verifier.c |2 +-
> samples/bpf/tracex1_kern.c | 50 +++
> samples/bpf/tracex1_user.c | 25 ++
> samples/bpf/tracex2_kern.c | 86 +++
> samples/bpf/tracex2_user.c | 95 +
> samples/bpf/tracex3_kern.c | 89
> samples/bpf/tracex3_user.c | 150
[PATCH] Input: psmouse - when comparing PNP IDs ignore case
PNP IDs are supposed to be case-insensitive and so we should compare
them as such.
Signed-off-by: Dmitry Torokhov
---
drivers/input/mouse/psmouse-base.c | 39 +++---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/input/mouse/psmouse-base.c
b/drivers/input/mouse/psmouse-base.c
index 4ccd01d..a175496 100644
--- a/drivers/input/mouse/psmouse-base.c
+++ b/drivers/input/mouse/psmouse-base.c
@@ -463,19 +463,44 @@ static int psmouse_poll(struct psmouse *psmouse)
PSMOUSE_CMD_POLL | (psmouse->pktsize << 8));
}
+static bool psmouse_check_pnp_id(const char *id, const char * const ids[])
+{
+ int i;
+
+ for (i = 0; ids[i]; i++)
+ if (!strcasecmp(id, ids[i]))
+ return true;
+
+ return false;
+}
+
/*
* psmouse_matches_pnp_id - check if psmouse matches one of the passed in ids.
*/
bool psmouse_matches_pnp_id(struct psmouse *psmouse, const char * const ids[])
{
- int i;
-
- if (!strncmp(psmouse->ps2dev.serio->firmware_id, "PNP:", 4))
- for (i = 0; ids[i]; i++)
- if (strstr(psmouse->ps2dev.serio->firmware_id, ids[i]))
- return true;
+ struct serio *serio = psmouse->ps2dev.serio;
+ char *p, *fw_id_copy, *save_ptr;
+ bool found = false;
+
+ if (!strncmp(serio->firmware_id, "PNP:", 4))
+ return false;
+
+ fw_id_copy = kstrndup(>firmware_id[4],
+ sizeof(serio->firmware_id) - 4,
+ GFP_KERNEL);
+ if (!fw_id_copy)
+ return false;
+
+ save_ptr = fw_id_copy;
+ while ((p = strsep(_id_copy, " ")) != NULL) {
+ if (psmouse_check_pnp_id(p, ids))
+ found = true;
+ break;
+ }
- return false;
+ kfree(save_ptr);
+ return found;
}
/*
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm64: qcom: Add support for Qualcomm MSM8916 SoC
Hi, Am Freitag, 27. Februar 2015, 16:14:52 schrieb Kumar Gala: > From: Abhimanyu Kapur > > Add support for Qualcomm MSM8916 SoC in arm64 Kconfig and defconfig. > Enable MSM serial driver utilized by MSM8916 and Qualcomm SoCs in > general. > > Signed-off-by: Kumar Gala > Signed-off-by: Abhimanyu Kapur > --- > arch/arm64/Kconfig | 18 ++ > arch/arm64/configs/defconfig | 4 > 2 files changed, 22 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1b8e973..f7af379 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -177,6 +177,24 @@ config ARCH_MEDIATEK > help > Support for Mediatek MT65xx & MT81xx ARMv8 SoCs > > +config ARCH_QCOM > + bool "Qualcomm Platforms" > + select ARCH_REQUIRE_GPIOLIB > + select COMMON_CLK_QCOM > + select PINCTRL > + select SOC_BUS > + help > + This enables support for the ARMv8 based Qualcomm chipsets. > + > +config ARCH_QCOM_MSM8916 > + bool "Enable Support for Qualcomm MSM8916" > + depends on ARCH_QCOM > + select MSM_GCC_8916 > + select PINCTRL_MSM8916 > + help > + This enables support for the MSM8916 chipset. If you dont > + know what do here, say N > + In [0] for a similar situation Arnd said "I would rather see only one Kconfig option per SoC family and use ARCH_MEDIATEK without any MACH_* options. We can have other options for e.g. networking chips from Mediatek that are not closely related but I would group all the phone and tablet chips under one option here. Same for the other vendors of course." [0] https://lkml.org/lkml/2015/2/25/150 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: svm: make wbinvd faster
From: David Kaplan
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, tested]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d319e0c..86ecd21 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2776,6 +2776,14 @@ static int skinit_interception(struct vcpu_svm *svm)
return 1;
}
+static int wbinvd_interception(struct vcpu_svm *svm)
+{
+ kvm_emulate_wbinvd(>vcpu);
+ skip_emulated_instruction(>vcpu);
+ return 1;
+}
+
+
static int xsetbv_interception(struct vcpu_svm *svm)
{
u64 new_bv = kvm_read_edx_eax(>vcpu);
@@ -3376,7 +3384,7 @@ static int (*const svm_exit_handlers[])(struct vcpu_svm
*svm) = {
[SVM_EXIT_STGI] = stgi_interception,
[SVM_EXIT_CLGI] = clgi_interception,
[SVM_EXIT_SKINIT] = skinit_interception,
- [SVM_EXIT_WBINVD] = emulate_on_interception,
+ [SVM_EXIT_WBINVD] = wbinvd_interception,
[SVM_EXIT_MONITOR] = monitor_interception,
[SVM_EXIT_MWAIT]= mwait_interception,
[SVM_EXIT_XSETBV] = xsetbv_interception,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip 2/7] tracing: attach BPF programs to kprobes
User interface:
struct perf_event_attr attr = {.type = PERF_TYPE_TRACEPOINT, .config =
event_id, ...};
event_fd = perf_event_open(,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
prog_fd is a file descriptor associated with BPF program previously loaded.
event_id is an ID of created kprobe
close(event_fd) - automatically detaches BPF program from it
BPF programs can call in-kernel helper functions to:
- lookup/update/delete elements in maps
- probe_read - wraper of probe_kernel_read() used to access any kernel
data structures
BPF programs receive 'struct pt_regs *' as an input
('struct pt_regs' is architecture dependent)
Note, kprobes are _not_ a stable kernel ABI, so bpf programs attached to
kprobes must be recompiled for every kernel version and user must supply correct
LINUX_VERSION_CODE in attr.kern_version during bpf_prog_load() call.
Signed-off-by: Alexei Starovoitov
---
include/linux/ftrace_event.h| 14 ++
include/uapi/linux/bpf.h|3 ++
include/uapi/linux/perf_event.h |1 +
kernel/bpf/syscall.c|7 ++-
kernel/events/core.c| 59 +++
kernel/trace/Makefile |1 +
kernel/trace/bpf_trace.c| 99 +++
kernel/trace/trace_kprobe.c | 10 +++-
8 files changed, 192 insertions(+), 2 deletions(-)
create mode 100644 kernel/trace/bpf_trace.c
diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index c674ee8f7fca..0aa535bc9f05 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -13,6 +13,7 @@ struct trace_array;
struct trace_buffer;
struct tracer;
struct dentry;
+struct bpf_prog;
struct trace_print_flags {
unsigned long mask;
@@ -252,6 +253,7 @@ enum {
TRACE_EVENT_FL_WAS_ENABLED_BIT,
TRACE_EVENT_FL_USE_CALL_FILTER_BIT,
TRACE_EVENT_FL_TRACEPOINT_BIT,
+ TRACE_EVENT_FL_KPROBE_BIT,
};
/*
@@ -265,6 +267,7 @@ enum {
* it is best to clear the buffers that used it).
* USE_CALL_FILTER - For ftrace internal events, don't use file filter
* TRACEPOINT- Event is a tracepoint
+ * KPROBE- Event is a kprobe
*/
enum {
TRACE_EVENT_FL_FILTERED = (1 << TRACE_EVENT_FL_FILTERED_BIT),
@@ -274,6 +277,7 @@ enum {
TRACE_EVENT_FL_WAS_ENABLED = (1 << TRACE_EVENT_FL_WAS_ENABLED_BIT),
TRACE_EVENT_FL_USE_CALL_FILTER = (1 <<
TRACE_EVENT_FL_USE_CALL_FILTER_BIT),
TRACE_EVENT_FL_TRACEPOINT = (1 << TRACE_EVENT_FL_TRACEPOINT_BIT),
+ TRACE_EVENT_FL_KPROBE = (1 << TRACE_EVENT_FL_KPROBE_BIT),
};
struct ftrace_event_call {
@@ -303,6 +307,7 @@ struct ftrace_event_call {
#ifdef CONFIG_PERF_EVENTS
int perf_refcount;
struct hlist_head __percpu *perf_events;
+ struct bpf_prog *prog;
int (*perf_perm)(struct ftrace_event_call *,
struct perf_event *);
@@ -548,6 +553,15 @@ event_trigger_unlock_commit_regs(struct ftrace_event_file
*file,
event_triggers_post_call(file, tt);
}
+#ifdef CONFIG_BPF_SYSCALL
+unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx);
+#else
+static inline unsigned int trace_call_bpf(struct bpf_prog *prog, void *ctx)
+{
+ return 1;
+}
+#endif
+
enum {
FILTER_OTHER = 0,
FILTER_STATIC_STRING,
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 45da7ec7d274..4486d36d2e9e 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -118,6 +118,7 @@ enum bpf_map_type {
enum bpf_prog_type {
BPF_PROG_TYPE_UNSPEC,
BPF_PROG_TYPE_SOCKET_FILTER,
+ BPF_PROG_TYPE_KPROBE,
};
/* flags for BPF_MAP_UPDATE_ELEM command */
@@ -151,6 +152,7 @@ union bpf_attr {
__u32 log_level; /* verbosity level of verifier
*/
__u32 log_size; /* size of user buffer */
__aligned_u64 log_buf;/* user supplied buffer */
+ __u32 kern_version; /* checked when type=kprobe */
};
} __attribute__((aligned(8)));
@@ -162,6 +164,7 @@ enum bpf_func_id {
BPF_FUNC_map_lookup_elem, /* void *map_lookup_elem(, ) */
BPF_FUNC_map_update_elem, /* int map_update_elem(, , ,
flags) */
BPF_FUNC_map_delete_elem, /* int map_delete_elem(, ) */
+ BPF_FUNC_probe_read, /* int bpf_probe_read(void *dst, int size,
void *src) */
__BPF_FUNC_MAX_ID,
};
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 3c8b45de57ec..ad4dade2a502 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -382,6 +382,7 @@ struct perf_event_attr {
#define PERF_EVENT_IOC_SET_OUTPUT _IO ('$', 5)
#define PERF_EVENT_IOC_SET_FILTER _IOW('$', 6, char *)
#define PERF_EVENT_IOC_ID _IOR('$', 7,
[PATCH v3 2/3] ARM: perf: Only reset PMxEVCNTCR registers on reset
The Krait specific PMxEVCNTCR register is unpredictable upon
reset. Currently we clear the register before we setup an event,
but we don't need to do that. Instead, we can iterate through all
the events and clear them once when we reset the PMU, saving a
write in the event setup path.
Cc: Neil Leeder
Cc: Ashwin Chaugule
Cc: Sheetal Sahasrabudhe
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/perf_event_v7.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 97a7eda8831a..fae6c4ea52e8 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1218,8 +1218,6 @@ static void krait_evt_setup(int idx, u32 config_base)
val |= config_base & (ARMV7_EXCLUDE_USER | ARMV7_EXCLUDE_PL1);
armv7_pmnc_write_evtsel(idx, val);
- asm volatile("mcr p15, 0, %0, c9, c15, 0" : : "r" (0));
-
if (venum_event) {
venum_pre_pmresr(, );
val = venum_read_pmresr();
@@ -1339,6 +1337,8 @@ static void krait_pmu_enable_event(struct perf_event
*event)
static void krait_pmu_reset(void *info)
{
u32 vval, fval;
+ struct arm_pmu *cpu_pmu = info;
+ u32 idx, nb_cnt = cpu_pmu->num_events;
armv7pmu_reset(info);
@@ -1350,6 +1350,13 @@ static void krait_pmu_reset(void *info)
venum_pre_pmresr(, );
venum_write_pmresr(0);
venum_post_pmresr(vval, fval);
+
+ /* Reset PMxEVNCTCR to sane default */
+ for (idx = ARMV7_IDX_CYCLE_COUNTER; idx < nb_cnt; ++idx) {
+ armv7_pmnc_select_counter(idx);
+ asm volatile("mcr p15, 0, %0, c9, c15, 0" : : "r" (0));
+ }
+
}
static int krait_event_to_bit(struct perf_event *event, unsigned int region,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip 0/7] tracing: attach eBPF programs to kprobes
Hi All,
This is targeting 'tip' tree, since most of the changes are perf_event related.
V3 discussion:
https://lkml.org/lkml/2015/2/9/738
V3->V4:
- since the boundary of stable ABI in bpf+tracepoints is not clear yet,
I've dropped them for now.
- bpf+syscalls are ok from stable ABI point of view, but bpf+seccomp
would want to do very similar analysis of syscalls, so I've dropped
them as well to take time and define common bpf+syscalls and bpf+seccomp
infra in the future.
- so only bpf+kprobes left. kprobes by definition is not a stable ABI,
so bpf+kprobe is not stable ABI either. To stress on that point added
kernel version attribute that user space must pass along with the program
and kernel will reject programs when version code doesn't match.
So bpf+kprobe is very similar to kernel modules, but unlike modules
version check is not used for safety, but for enforcing 'non-ABI-ness'.
(version check doesn't apply to bpf+sockets which are stable)
1st patch of this set is going to be shared between net-next and tip trees,
since
patch 2 depends on it.
Patch 2 actually adds bpf+kprobe infra:
programs receive 'struct pt_regs' on input and can walk data structures
using bpf_probe_read() helper which is a wrapper of probe_kernel_read()
Programs are attached to kprobe events via API:
prog_fd = bpf_prog_load(...);
struct perf_event_attr attr = {
.type = PERF_TYPE_TRACEPOINT,
.config = event_id, /* ID of just created kprobe event */
};
event_fd = perf_event_open(,...);
ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
Patch 3 adds bpf_ktime_get_ns() helper function, so that bpf programs can
measure time delta between events to compute disk io latency, etc.
Patch 4 adds bpf_trace_printk() helper that is used to debug programs.
When bpf verifier sees that program is calling bpf_trace_printk() it inits
trace_printk buffers which emits nasty 'this is debug only' banner.
That's exactly what we want. bpf_trace_printk() is for debugging only.
Patch 5 sample code that shows how to use bpf_probe_read/bpf_trace_printk
Patch 6 sample code - combination of kfree_skb and sys_write tracing.
Patch 7 sample code that computes disk io latency and prints it as 'heatmap'
Interesting bit is that patch 6 has log2() function implemented in C
and patch 7 has another log2() function using different algorithm in C.
In the future if 'log2' usage becomes common, we can add it as in-kernel
helper function, but for now bpf programs can implement them on bpf side.
Another interesting bit from patch 7 is that it does approximation of
floating point log10(X)*10 using integer arithmetic, which demonstrates
the power of C->BPF vs traditional tracing language alternatives,
where one would need to introduce new helper functions to add functionality,
whereas bpf can just implement such things in C as part of the program.
Next step is to prototype TCP stack instrumentation (like web10g) using
bpf+kprobe, but without adding any new code tcp stack.
Though kprobes are slow comparing to tracepoints, they are good enough
for prototyping and trace_marker/debug_tracepoint ideas can accelerate
them in the future.
Alexei Starovoitov (6):
tracing: attach BPF programs to kprobes
tracing: allow BPF programs to call ktime_get_ns()
tracing: allow BPF programs to call bpf_trace_printk()
samples: bpf: simple non-portable kprobe filter example
samples: bpf: counting example for kfree_skb and write syscall
samples: bpf: IO latency analysis (iosnoop/heatmap)
Daniel Borkmann (1):
bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
include/linux/bpf.h | 20 -
include/linux/ftrace_event.h| 14
include/uapi/linux/bpf.h|5 ++
include/uapi/linux/perf_event.h |1 +
kernel/bpf/syscall.c|7 +-
kernel/events/core.c| 59 +
kernel/trace/Makefile |1 +
kernel/trace/bpf_trace.c| 177 +++
kernel/trace/trace_kprobe.c | 10 ++-
samples/bpf/Makefile| 12 +++
samples/bpf/bpf_helpers.h |6 ++
samples/bpf/bpf_load.c | 112 +++--
samples/bpf/bpf_load.h |3 +
samples/bpf/libbpf.c| 10 ++-
samples/bpf/libbpf.h|5 +-
samples/bpf/sock_example.c |2 +-
samples/bpf/test_verifier.c |2 +-
samples/bpf/tracex1_kern.c | 50 +++
samples/bpf/tracex1_user.c | 25 ++
samples/bpf/tracex2_kern.c | 86 +++
samples/bpf/tracex2_user.c | 95 +
samples/bpf/tracex3_kern.c | 89
samples/bpf/tracex3_user.c | 150 +
23 files changed, 925 insertions(+), 16 deletions(-)
create mode 100644 kernel/trace/bpf_trace.c
create mode 100644 samples/bpf/tracex1_kern.c
create mode 100644 samples/bpf/tracex1_user.c
create mode 100644
[PATCH] x86: svm: use kvm_fast_pio_in()
From: David Kaplan We can make the in instruction go faster the same way the out instruction is already. Signed-off-by: David Kaplan [extracted from larger unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp --- arch/x86/kvm/svm.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index d319e0c..f8c906b 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -1899,7 +1899,7 @@ static int io_interception(struct vcpu_svm *svm) ++svm->vcpu.stat.io_exits; string = (io_info & SVM_IOIO_STR_MASK) != 0; in = (io_info & SVM_IOIO_TYPE_MASK) != 0; - if (string || in) + if (string) return emulate_instruction(vcpu, 0) == EMULATE_DONE; port = io_info >> 16; @@ -1907,6 +1907,8 @@ static int io_interception(struct vcpu_svm *svm) svm->next_rip = svm->vmcb->control.exit_info_2; skip_emulated_instruction(>vcpu); + if (in) + return kvm_fast_pio_in(vcpu, size, port); return kvm_fast_pio_out(vcpu, size, port); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] Scorpion PMU support
These patches add support for the Scorpion PMU found on devices such as msm8660, qsd8x50, etc. The first patch is some groundwork to make functions more "generic". Even then we end up copying quite a bit of code from the Krait part into the Scorpion part with only subtle tweaks because two things happen: 1. We gain another "region" register, L2LPM 2. The way to access the region registers are with different cp15 instructions I'm not sure how to make this better, suggestions are welcome. The second patch is an optimization for an implementation defined register. The final patch is the one that actually adds support for Scorpion. Changes from v2: * New patch 2 * Macros instead of an inline function for patch 1 Changes from v1: * Added stub functions for CONFIG_CPU_V7=n * Fixed L2LPM register accessors * Exposed mp and !mp versions of PMU to userspace differently (mrutland) * Dropped I-cache events that shouldn't be there (mrutland) * Fixed branch misprediction event (mrutland) Stephen Boyd (3): ARM: perf: Preparatory work for Scorpion PMU support ARM: perf: Only reset PMxEVCNTCR registers on reset ARM: perf: Add support for Scorpion PMUs Documentation/devicetree/bindings/arm/pmu.txt | 2 + arch/arm/kernel/perf_event_cpu.c | 2 + arch/arm/kernel/perf_event_v7.c | 525 +++--- 3 files changed, 470 insertions(+), 59 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 00/21] Richacls
2015-02-27 23:48 GMT+01:00 J. Bruce Fields : > I remember my main concern being how we collapse the ACL and mask bits > to map a richacl to an NFSv4 (or Samba) ACL. What richacl_apply_masks() in librichacl does and what "richacl --get" without the --raw option displays. The basic algorithms are still unchanged: http://www.bestbits.at/richacl/draft-gruenbacher-nfsv4-acls-in-posix-00.html Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] ARM: perf: Add support for Scorpion PMUs
Scorpion supports a set of local performance monitor event
selection registers (LPM) sitting behind a cp15 based interface
that extend the architected PMU events to include Scorpion CPU
and Venum VFP specific events. To use these events the user is
expected to program the lpm register with the event code shifted
into the group they care about and then point the PMNx event at
that region+group combo by writing a LPMn_GROUPx event. Add
support for this hardware.
Note: the raw event number is a pure software construct that
allows us to map the multi-dimensional number space of regions,
groups, and event codes into a flat event number space suitable
for use by the perf framework.
This is based on code originally written by Sheetal Sahasrabudhe,
Ashwin Chaugule, and Neil Leeder [1].
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/kernel/perf_event_msm.c?h=msm-3.4
Cc: Mark Rutland
Cc: Neil Leeder
Cc: Ashwin Chaugule
Cc: Sheetal Sahasrabudhe
Cc:
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/arm/pmu.txt | 2 +
arch/arm/kernel/perf_event_cpu.c | 2 +
arch/arm/kernel/perf_event_v7.c | 414 ++
3 files changed, 418 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt
b/Documentation/devicetree/bindings/arm/pmu.txt
index 75ef91d08f3b..6e54a9d88b7a 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -18,6 +18,8 @@ Required properties:
"arm,arm11mpcore-pmu"
"arm,arm1176-pmu"
"arm,arm1136-pmu"
+ "qcom,scorpion-pmu"
+ "qcom,scorpion-mp-pmu"
"qcom,krait-pmu"
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a
per-cpu
interrupt (PPI) then 1 interrupt should be specified.
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index dd9acc95ebc0..4fbf1085f75a 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -243,6 +243,8 @@ static struct of_device_id cpu_pmu_of_device_ids[] = {
{.compatible = "arm,arm1176-pmu", .data = armv6_1176_pmu_init},
{.compatible = "arm,arm1136-pmu", .data = armv6_1136_pmu_init},
{.compatible = "qcom,krait-pmu",.data = krait_pmu_init},
+ {.compatible = "qcom,scorpion-pmu", .data = scorpion_pmu_init},
+ {.compatible = "qcom,scorpion-mp-pmu", .data = scorpion_mp_pmu_init},
{},
};
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index fae6c4ea52e8..f4207a4dcb01 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -140,6 +140,23 @@ enum krait_perf_types {
KRAIT_PERFCTR_L1_DTLB_ACCESS= 0x12210,
};
+/* ARMv7 Scorpion specific event types */
+enum scorpion_perf_types {
+ SCORPION_LPM0_GROUP0= 0x4c,
+ SCORPION_LPM1_GROUP0= 0x50,
+ SCORPION_LPM2_GROUP0= 0x54,
+ SCORPION_L2LPM_GROUP0 = 0x58,
+ SCORPION_VLPM_GROUP0= 0x5c,
+
+ SCORPION_ICACHE_ACCESS = 0x10053,
+ SCORPION_ICACHE_MISS= 0x10052,
+
+ SCORPION_DTLB_ACCESS= 0x12013,
+ SCORPION_DTLB_MISS = 0x12012,
+
+ SCORPION_ITLB_MISS = 0x12021,
+};
+
/*
* Cortex-A8 HW events mapping
*
@@ -482,6 +499,49 @@ static const unsigned
krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
};
/*
+ * Scorpion HW events mapping
+ */
+static const unsigned scorpion_perf_map[PERF_COUNT_HW_MAX] = {
+ PERF_MAP_ALL_UNSUPPORTED,
+ [PERF_COUNT_HW_CPU_CYCLES] = ARMV7_PERFCTR_CPU_CYCLES,
+ [PERF_COUNT_HW_INSTRUCTIONS]= ARMV7_PERFCTR_INSTR_EXECUTED,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = ARMV7_PERFCTR_PC_WRITE,
+ [PERF_COUNT_HW_BRANCH_MISSES] = ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ [PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_CLOCK_CYCLES,
+};
+
+static const unsigned scorpion_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+ PERF_CACHE_MAP_ALL_UNSUPPORTED,
+ /*
+* The performance counters don't differentiate between read and write
+* accesses/misses so this isn't strictly correct, but it's the best we
+* can do. Writes and reads get combined.
+*/
+ [C(L1D)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV7_PERFCTR_L1_DCACHE_ACCESS,
+ [C(L1D)][C(OP_READ)][C(RESULT_MISS)] = ARMV7_PERFCTR_L1_DCACHE_REFILL,
+ [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] =
ARMV7_PERFCTR_L1_DCACHE_ACCESS,
+
[PATCH v3 1/3] ARM: perf: Preparatory work for Scorpion PMU support
Do some things to make the Krait PMU support code generic enough
to be used by the Scorpion PMU support code.
* Rename the venum register functions to be venum instead of krait
specific because the same registers exist on Scorpion
* Add some macros to decode our Krait specific event encoding that's
the same on Scorpion (modulo an extra region).
* Drop 'krait' from krait_clear_pmresrn_group() so it can be used
by Scorpion code
Signed-off-by: Stephen Boyd
---
arch/arm/kernel/perf_event_v7.c | 100 +---
1 file changed, 43 insertions(+), 57 deletions(-)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 8993770c47de..97a7eda8831a 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1103,6 +1103,12 @@ static int armv7_a17_pmu_init(struct arm_pmu *cpu_pmu)
#define KRAIT_EVENT_MASK (KRAIT_EVENT | VENUM_EVENT)
#define PMRESRn_EN BIT(31)
+#define EVENT_REGION(event)(((event) >> 12) & 0xf) /* R */
+#define EVENT_GROUP(event) ((event) & 0xf) /* G */
+#define EVENT_CODE(event) (((event) >> 4) & 0xff) /* CC */
+#define EVENT_VENUM(event) (!!(event & VENUM_EVENT)) /* N=2 */
+#define EVENT_CPU(event) (!!(event & KRAIT_EVENT)) /* N=1 */
+
static u32 krait_read_pmresrn(int n)
{
u32 val;
@@ -1141,19 +1147,19 @@ static void krait_write_pmresrn(int n, u32 val)
}
}
-static u32 krait_read_vpmresr0(void)
+static u32 venum_read_pmresr(void)
{
u32 val;
asm volatile("mrc p10, 7, %0, c11, c0, 0" : "=r" (val));
return val;
}
-static void krait_write_vpmresr0(u32 val)
+static void venum_write_pmresr(u32 val)
{
asm volatile("mcr p10, 7, %0, c11, c0, 0" : : "r" (val));
}
-static void krait_pre_vpmresr0(u32 *venum_orig_val, u32 *fp_orig_val)
+static void venum_pre_pmresr(u32 *venum_orig_val, u32 *fp_orig_val)
{
u32 venum_new_val;
u32 fp_new_val;
@@ -1170,7 +1176,7 @@ static void krait_pre_vpmresr0(u32 *venum_orig_val, u32
*fp_orig_val)
fmxr(FPEXC, fp_new_val);
}
-static void krait_post_vpmresr0(u32 venum_orig_val, u32 fp_orig_val)
+static void venum_post_pmresr(u32 venum_orig_val, u32 fp_orig_val)
{
BUG_ON(preemptible());
/* Restore FPEXC */
@@ -1193,16 +1199,11 @@ static void krait_evt_setup(int idx, u32 config_base)
u32 val;
u32 mask;
u32 vval, fval;
- unsigned int region;
- unsigned int group;
- unsigned int code;
+ unsigned int region = EVENT_REGION(config_base);
+ unsigned int group = EVENT_GROUP(config_base);
+ unsigned int code = EVENT_CODE(config_base);
unsigned int group_shift;
- bool venum_event;
-
- venum_event = !!(config_base & VENUM_EVENT);
- region = (config_base >> 12) & 0xf;
- code = (config_base >> 4) & 0xff;
- group = (config_base >> 0) & 0xf;
+ bool venum_event = EVENT_VENUM(config_base);
group_shift = group * 8;
mask = 0xff << group_shift;
@@ -1220,13 +1221,13 @@ static void krait_evt_setup(int idx, u32 config_base)
asm volatile("mcr p15, 0, %0, c9, c15, 0" : : "r" (0));
if (venum_event) {
- krait_pre_vpmresr0(, );
- val = krait_read_vpmresr0();
+ venum_pre_pmresr(, );
+ val = venum_read_pmresr();
val &= ~mask;
val |= code << group_shift;
val |= PMRESRn_EN;
- krait_write_vpmresr0(val);
- krait_post_vpmresr0(vval, fval);
+ venum_write_pmresr(val);
+ venum_post_pmresr(vval, fval);
} else {
val = krait_read_pmresrn(region);
val &= ~mask;
@@ -1236,7 +1237,7 @@ static void krait_evt_setup(int idx, u32 config_base)
}
}
-static u32 krait_clear_pmresrn_group(u32 val, int group)
+static u32 clear_pmresrn_group(u32 val, int group)
{
u32 mask;
int group_shift;
@@ -1256,23 +1257,19 @@ static void krait_clearpmu(u32 config_base)
{
u32 val;
u32 vval, fval;
- unsigned int region;
- unsigned int group;
- bool venum_event;
-
- venum_event = !!(config_base & VENUM_EVENT);
- region = (config_base >> 12) & 0xf;
- group = (config_base >> 0) & 0xf;
+ unsigned int region = EVENT_REGION(config_base);
+ unsigned int group = EVENT_GROUP(config_base);
+ bool venum_event = EVENT_VENUM(config_base);
if (venum_event) {
- krait_pre_vpmresr0(, );
- val = krait_read_vpmresr0();
- val = krait_clear_pmresrn_group(val, group);
- krait_write_vpmresr0(val);
- krait_post_vpmresr0(vval, fval);
+ venum_pre_pmresr(, );
+ val = venum_read_pmresr();
+ val = clear_pmresrn_group(val, group);
[PATCH v4 tip 3/7] tracing: allow BPF programs to call ktime_get_ns()
bpf_ktime_get_ns() is used by programs to compue time delta between events
or as a timestamp
Signed-off-by: Alexei Starovoitov
---
include/uapi/linux/bpf.h |1 +
kernel/trace/bpf_trace.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 4486d36d2e9e..101e509d1001 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -165,6 +165,7 @@ enum bpf_func_id {
BPF_FUNC_map_update_elem, /* int map_update_elem(, , ,
flags) */
BPF_FUNC_map_delete_elem, /* int map_delete_elem(, ) */
BPF_FUNC_probe_read, /* int bpf_probe_read(void *dst, int size,
void *src) */
+ BPF_FUNC_ktime_get_ns,/* u64 bpf_ktime_get_ns(void) */
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index bcce9b238dad..64b918488607 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -36,6 +36,11 @@ static u64 bpf_probe_read(u64 r1, u64 r2, u64 r3, u64 r4,
u64 r5)
return probe_kernel_read(dst, unsafe_ptr, size);
}
+static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ return ktime_get_ns();
+}
+
static struct bpf_func_proto kprobe_prog_funcs[] = {
[BPF_FUNC_probe_read] = {
.func = bpf_probe_read,
@@ -45,6 +50,11 @@ static struct bpf_func_proto kprobe_prog_funcs[] = {
.arg2_type = ARG_CONST_STACK_SIZE,
.arg3_type = ARG_ANYTHING,
},
+ [BPF_FUNC_ktime_get_ns] = {
+ .func = bpf_ktime_get_ns,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ },
};
static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id
func_id)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip 4/7] tracing: allow BPF programs to call bpf_trace_printk()
Debugging of BPF programs needs some form of printk from the program,
so let programs call limited trace_printk() with %d %u %x %p modifiers only.
Similar to kernel modules, during program load verifier checks whether program
is calling bpf_trace_printk() and if so, kernel allocates trace_printk buffers
and emits big 'this is debug only' banner.
Signed-off-by: Alexei Starovoitov
---
include/uapi/linux/bpf.h |1 +
kernel/trace/bpf_trace.c | 68 ++
2 files changed, 69 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 101e509d1001..4095f3d9a716 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -166,6 +166,7 @@ enum bpf_func_id {
BPF_FUNC_map_delete_elem, /* int map_delete_elem(, ) */
BPF_FUNC_probe_read, /* int bpf_probe_read(void *dst, int size,
void *src) */
BPF_FUNC_ktime_get_ns,/* u64 bpf_ktime_get_ns(void) */
+ BPF_FUNC_trace_printk,/* int bpf_trace_printk(const char *fmt, int
fmt_size, ...) */
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 64b918488607..bed16b6925bb 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -41,6 +41,60 @@ static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4,
u64 r5)
return ktime_get_ns();
}
+/* limited trace_printk()
+ * only %d %u %x %ld %lu %lx %lld %llu %llx %p conversion specifiers allowed
+ */
+static u64 bpf_trace_printk(u64 r1, u64 fmt_size, u64 r3, u64 r4, u64 r5)
+{
+ char *fmt = (char *) (long) r1;
+ int fmt_cnt = 0;
+ bool mod_l[3] = {};
+ int i;
+
+ /* bpf_check() guarantees that fmt points to bpf program stack and
+* fmt_size bytes of it were initialized by bpf program
+*/
+ if (fmt[fmt_size - 1] != 0)
+ return -EINVAL;
+
+ /* check format string for allowed specifiers */
+ for (i = 0; i < fmt_size; i++)
+ if (fmt[i] == '%') {
+ if (fmt_cnt >= 3)
+ return -EINVAL;
+ i++;
+ if (i >= fmt_size)
+ return -EINVAL;
+
+ if (fmt[i] == 'l') {
+ mod_l[fmt_cnt] = true;
+ i++;
+ if (i >= fmt_size)
+ return -EINVAL;
+ } else if (fmt[i] == 'p') {
+ mod_l[fmt_cnt] = true;
+ fmt_cnt++;
+ continue;
+ }
+
+ if (fmt[i] == 'l') {
+ mod_l[fmt_cnt] = true;
+ i++;
+ if (i >= fmt_size)
+ return -EINVAL;
+ }
+
+ if (fmt[i] != 'd' && fmt[i] != 'u' && fmt[i] != 'x')
+ return -EINVAL;
+ fmt_cnt++;
+ }
+
+ return __trace_printk(1/* fake ip will not be printed */, fmt,
+ mod_l[0] ? r3 : (u32) r3,
+ mod_l[1] ? r4 : (u32) r4,
+ mod_l[2] ? r5 : (u32) r5);
+}
+
static struct bpf_func_proto kprobe_prog_funcs[] = {
[BPF_FUNC_probe_read] = {
.func = bpf_probe_read,
@@ -55,6 +109,13 @@ static struct bpf_func_proto kprobe_prog_funcs[] = {
.gpl_only = true,
.ret_type = RET_INTEGER,
},
+ [BPF_FUNC_trace_printk] = {
+ .func = bpf_trace_printk,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_STACK,
+ .arg2_type = ARG_CONST_STACK_SIZE,
+ },
};
static const struct bpf_func_proto *kprobe_prog_func_proto(enum bpf_func_id
func_id)
@@ -69,6 +130,13 @@ static const struct bpf_func_proto
*kprobe_prog_func_proto(enum bpf_func_id func
default:
if (func_id < 0 || func_id >= ARRAY_SIZE(kprobe_prog_funcs))
return NULL;
+
+ if (func_id == BPF_FUNC_trace_printk)
+ /* this program might be calling bpf_trace_printk,
+* so allocate per-cpu printk buffers
+*/
+ trace_printk_init_buffers();
+
return _prog_funcs[func_id];
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip 6/7] samples: bpf: counting example for kfree_skb and write syscall
this example has two probes in one C file that attach to different kprove events
and use two different maps.
1st probe is x64 specific equivalent of dropmon. It attaches to kfree_skb,
retrevies 'ip' address of kfree_skb() caller and counts number of packet drops
at that 'ip' address. User space prints 'location - count' map every second.
2nd probe attaches to kprobe:sys_write and computes a histogram of different
write sizes
Usage:
$ sudo tracex2
location 0x81695995 count 1
location 0x816d0da9 count 2
location 0x81695995 count 2
location 0x816d0da9 count 2
location 0x81695995 count 3
location 0x816d0da9 count 2
557145+0 records in
557145+0 records out
285258240 bytes (285 MB) copied, 1.02379 s, 279 MB/s
syscall write() stats
byte_size : count distribution
1 -> 1: 3| |
2 -> 3: 0| |
4 -> 7: 0| |
8 -> 15 : 0| |
16 -> 31 : 2| |
32 -> 63 : 3| |
64 -> 127 : 1| |
128 -> 255 : 1| |
256 -> 511 : 0| |
512 -> 1023 : 1118968 |* |
Ctrl-C at any time. Kernel will auto cleanup maps and programs
$ addr2line -ape ./bld_x64/vmlinux 0x81695995 0x816d0da9
0x81695995: ./bld_x64/../net/ipv4/icmp.c:1038
0x816d0da9: ./bld_x64/../net/unix/af_unix.c:1231
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |4 ++
samples/bpf/tracex2_kern.c | 86 +++
samples/bpf/tracex2_user.c | 95
3 files changed, 185 insertions(+)
create mode 100644 samples/bpf/tracex2_kern.c
create mode 100644 samples/bpf/tracex2_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 51f6f01e5a3a..6dd272143733 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -7,6 +7,7 @@ hostprogs-y += sock_example
hostprogs-y += sockex1
hostprogs-y += sockex2
hostprogs-y += tracex1
+hostprogs-y += tracex2
test_verifier-objs := test_verifier.o libbpf.o
test_maps-objs := test_maps.o libbpf.o
@@ -14,12 +15,14 @@ sock_example-objs := sock_example.o libbpf.o
sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
+tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
always += sockex1_kern.o
always += sockex2_kern.o
always += tracex1_kern.o
+always += tracex2_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -27,6 +30,7 @@ HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include
-Wno-unused-variable
HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
HOSTLOADLIBES_tracex1 += -lelf
+HOSTLOADLIBES_tracex2 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex2_kern.c b/samples/bpf/tracex2_kern.c
new file mode 100644
index ..a1ac1f99b665
--- /dev/null
+++ b/samples/bpf/tracex2_kern.c
@@ -0,0 +1,86 @@
+/* Copyright (c) 2013-2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(long),
+ .value_size = sizeof(long),
+ .max_entries = 1024,
+};
+
+/* kprobe is NOT a stable ABI
+ * This bpf+kprobe example can stop working any time.
+ */
+SEC("events/kprobes/kfree_skb")
+int bpf_prog2(struct pt_regs *ctx)
+{
+ long loc = 0;
+ long init_val = 1;
+ long *value;
+
+ /* x64 specific: read ip of kfree_skb caller.
+* non-portable version of __builtin_return_address(0)
+*/
+ bpf_probe_read(, sizeof(loc), (void *)ctx->sp);
+
+ value = bpf_map_lookup_elem(_map, );
+ if (value)
+ *value += 1;
+ else
+ bpf_map_update_elem(_map, , _val, BPF_ANY);
+ return 0;
+}
+
+static unsigned int log2(unsigned int v)
+{
+ unsigned int r;
+ unsigned int shift;
+
+ r = (v > 0x) << 4; v >>= r;
+ shift = (v > 0xFF) << 3; v >>= shift; r |= shift;
+ shift = (v > 0xF) << 2; v >>= shift; r |= shift;
+ shift = (v > 0x3) << 1; v >>=
[PATCH v4 tip 1/7] bpf: make internal bpf API independent of CONFIG_BPF_SYSCALL ifdefs
From: Daniel Borkmann
Socket filter code and other subsystems with upcoming eBPF support should
not need to deal with the fact that we have CONFIG_BPF_SYSCALL defined or
not.
Having the bpf syscall as a config option is a nice thing and I'd expect
it to stay that way for expert users (I presume one day the default setting
of it might change, though), but code making use of it should not care if
it's actually enabled or not.
Instead, hide this via header files and let the rest deal with it.
Signed-off-by: Daniel Borkmann
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index bbfceb756452..c2e21113ecc0 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -113,8 +113,6 @@ struct bpf_prog_type_list {
enum bpf_prog_type type;
};
-void bpf_register_prog_type(struct bpf_prog_type_list *tl);
-
struct bpf_prog;
struct bpf_prog_aux {
@@ -129,11 +127,25 @@ struct bpf_prog_aux {
};
#ifdef CONFIG_BPF_SYSCALL
+void bpf_register_prog_type(struct bpf_prog_type_list *tl);
+
void bpf_prog_put(struct bpf_prog *prog);
+struct bpf_prog *bpf_prog_get(u32 ufd);
#else
-static inline void bpf_prog_put(struct bpf_prog *prog) {}
+static inline void bpf_register_prog_type(struct bpf_prog_type_list *tl)
+{
+}
+
+static inline struct bpf_prog *bpf_prog_get(u32 ufd)
+{
+ return ERR_PTR(-EOPNOTSUPP);
+}
+
+static inline void bpf_prog_put(struct bpf_prog *prog)
+{
+}
#endif
-struct bpf_prog *bpf_prog_get(u32 ufd);
+
/* verify correctness of eBPF program */
int bpf_check(struct bpf_prog *fp, union bpf_attr *attr);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 tip 7/7] samples: bpf: IO latency analysis (iosnoop/heatmap)
BPF C program attaches to blk_mq_start_request/blk_update_request kprobe events
to calculate IO latency.
For every completed block IO event it computes the time delta in nsec
and records in a histogram map: map[log10(delta)*10]++
User space reads this histogram map every 2 seconds and prints it as a 'heatmap'
using gray shades of text terminal. Black spaces have many events and white
spaces have very few events. Left most space is the smallest latency, right most
space is the largest latency in the range.
Usage:
$ sudo ./tracex3
and do 'sudo dd if=/dev/sda of=/dev/null' in other terminal.
Observe IO latencies and how different activity (like 'make kernel') affects it.
Similar experiments can be done for network transmit latencies, syscalls, etc
'-t' flag prints the heatmap using normal ascii characters:
$ sudo ./tracex3 -t
heatmap of IO latency
# - many events with this latency
- few events
|1us |10us |100us|1ms |10ms |100ms|1s |10s
*ooo. *O.#.# 221
. *# . # 125
.. .o#*..# 55
. . . . .#O # 37
.# # 175
.#*. # 37
# # 199
. . *#*. # 55
*#..*# 42
# # 266
...***Oo#*OO**o#* . # 629
# # 271
. .#o* o.*o* # 221
. . o* *#O..# 50
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile |4 ++
samples/bpf/tracex3_kern.c | 89 ++
samples/bpf/tracex3_user.c | 150
3 files changed, 243 insertions(+)
create mode 100644 samples/bpf/tracex3_kern.c
create mode 100644 samples/bpf/tracex3_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 6dd272143733..dcd850546d52 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -8,6 +8,7 @@ hostprogs-y += sockex1
hostprogs-y += sockex2
hostprogs-y += tracex1
hostprogs-y += tracex2
+hostprogs-y += tracex3
test_verifier-objs := test_verifier.o libbpf.o
test_maps-objs := test_maps.o libbpf.o
@@ -16,6 +17,7 @@ sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
+tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@@ -23,6 +25,7 @@ always += sockex1_kern.o
always += sockex2_kern.o
always += tracex1_kern.o
always += tracex2_kern.o
+always += tracex3_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -31,6 +34,7 @@ HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
HOSTLOADLIBES_tracex1 += -lelf
HOSTLOADLIBES_tracex2 += -lelf
+HOSTLOADLIBES_tracex3 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/tracex3_kern.c b/samples/bpf/tracex3_kern.c
new file mode 100644
index ..64f1c0b01a30
--- /dev/null
+++ b/samples/bpf/tracex3_kern.c
@@ -0,0 +1,89 @@
+/* Copyright (c) 2013-2015 PLUMgrid, http://plumgrid.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") my_map = {
+ .type = BPF_MAP_TYPE_HASH,
+ .key_size = sizeof(long),
+ .value_size = sizeof(u64),
+ .max_entries = 4096,
+};
+
+/* kprobe is NOT a stable ABI
+ * This bpf+kprobe example can stop working any time.
+ */
+SEC("events/kprobes/blk_mq_start_request")
+int bpf_prog1(struct pt_regs *ctx)
+{
+ long rq = ctx->di;
+ u64 val = bpf_ktime_get_ns();
+
+ bpf_map_update_elem(_map, , , BPF_ANY);
+ return 0;
+}
+
+static unsigned int log2l(unsigned long long n)
+{
+#define S(k) if (n >= (1ull << k)) { i += k; n >>= k; }
+ int i = -(n == 0);
+ S(32); S(16); S(8); S(4); S(2); S(1);
+ return i;
+#undef S
+}
+
+#define SLOTS 100
+
+struct bpf_map_def SEC("maps") lat_map = {
+ .type = BPF_MAP_TYPE_ARRAY,
+ .key_size = sizeof(u32),
+
[PATCH v4 tip 5/7] samples: bpf: simple non-portable kprobe filter example
tracex1_kern.c - C program compiled into BPF.
It attaches to kprobe:netif_receive_skb
When skb->dev->name == "lo", it prints sample debug message into trace_pipe
via bpf_trace_printk() helper function.
tracex1_user.c - corresponding user space component that:
- loads bpf program via bpf() syscall
- opens kprobes:netif_receive_skb event via perf_event_open() syscall
- attaches the program to event via ioctl(event_fd, PERF_EVENT_IOC_SET_BPF,
prog_fd);
- prints from trace_pipe
Note, this bpf program is completely non-portable. It must be recompiled
with current kernel headers. kprobe is not a stable ABI and bpf+kprobe scripts
may stop working any time.
bpf verifier will detect that it's using bpf_trace_printk() and kernel will
print warning banner:
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
bpf_trace_printk() should be used for debugging of bpf program only.
Usage:
$ sudo tracex1
ping-19826 [000] d.s2 63103.382648: : skb 880466b1ca00 len 84
ping-19826 [000] d.s2 63103.382684: : skb 880466b1d300 len 84
ping-19826 [000] d.s2 63104.382533: : skb 880466b1ca00 len 84
ping-19826 [000] d.s2 63104.382594: : skb 880466b1d300 len 84
Signed-off-by: Alexei Starovoitov
---
samples/bpf/Makefile|4 ++
samples/bpf/bpf_helpers.h |6 +++
samples/bpf/bpf_load.c | 112 ---
samples/bpf/bpf_load.h |3 ++
samples/bpf/libbpf.c| 10 +++-
samples/bpf/libbpf.h|5 +-
samples/bpf/sock_example.c |2 +-
samples/bpf/test_verifier.c |2 +-
samples/bpf/tracex1_kern.c | 50 +++
samples/bpf/tracex1_user.c | 25 ++
10 files changed, 209 insertions(+), 10 deletions(-)
create mode 100644 samples/bpf/tracex1_kern.c
create mode 100644 samples/bpf/tracex1_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index b5b3600dcdf5..51f6f01e5a3a 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -6,23 +6,27 @@ hostprogs-y := test_verifier test_maps
hostprogs-y += sock_example
hostprogs-y += sockex1
hostprogs-y += sockex2
+hostprogs-y += tracex1
test_verifier-objs := test_verifier.o libbpf.o
test_maps-objs := test_maps.o libbpf.o
sock_example-objs := sock_example.o libbpf.o
sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
+tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
# Tell kbuild to always build the programs
always := $(hostprogs-y)
always += sockex1_kern.o
always += sockex2_kern.o
+always += tracex1_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
HOSTLOADLIBES_sockex1 += -lelf
HOSTLOADLIBES_sockex2 += -lelf
+HOSTLOADLIBES_tracex1 += -lelf
# point this to your LLVM backend with bpf support
LLC=$(srctree)/tools/bpf/llvm/bld/Debug+Asserts/bin/llc
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index ca0333146006..1c872bcf5a80 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -15,6 +15,12 @@ static int (*bpf_map_update_elem)(void *map, void *key, void
*value,
(void *) BPF_FUNC_map_update_elem;
static int (*bpf_map_delete_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_delete_elem;
+static int (*bpf_probe_read)(void *dst, int size, void *unsafe_ptr) =
+ (void *) BPF_FUNC_probe_read;
+static unsigned long long (*bpf_ktime_get_ns)(void) =
+ (void *) BPF_FUNC_ktime_get_ns;
+static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) =
+ (void *) BPF_FUNC_trace_printk;
/* llvm builtin functions that eBPF C program may use to
* emit BPF_LD_ABS and BPF_LD_IND instructions
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 1831d236382b..8b42adb0b099 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -8,29 +8,64 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
+#include
+#include
+#include
#include "libbpf.h"
#include "bpf_helpers.h"
#include "bpf_load.h"
+#define DEBUGFS "/sys/kernel/debug/tracing/"
+
static char license[128];
+static int kern_version;
static bool processed_sec[128];
int map_fd[MAX_MAPS];
int prog_fd[MAX_PROGS];
+int event_fd[MAX_PROGS];
int prog_cnt;
static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
{
- int fd;
bool is_socket = strncmp(event, "socket", 6) == 0;
-
- if (!is_socket)
- /* tracing events tbd */
+ bool is_kprobe = strncmp(event, "events/kprobes/", 15) == 0;
+ enum bpf_prog_type prog_type;
+ char buf[256];
+ int fd, efd, err, id;
+ struct perf_event_attr attr = {};
+
+ attr.type =
Re: [PATCH 1/2] kasan, module, vmalloc: rework shadow allocation for modules
Andrey Ryabinin writes:
> Current approach in handling shadow memory for modules is broken.
>
> Shadow memory could be freed only after memory shadow corresponds
> it is no longer used.
> vfree() called from interrupt context could use memory its
> freeing to store 'struct llist_node' in it:
>
> void vfree(const void *addr)
> {
> ...
> if (unlikely(in_interrupt())) {
> struct vfree_deferred *p = this_cpu_ptr(_deferred);
> if (llist_add((struct llist_node *)addr, >list))
> schedule_work(>wq);
>
> Latter this list node used in free_work() which actually frees memory.
> Currently module_memfree() called in interrupt context will free
> shadow before freeing module's memory which could provoke kernel
> crash.
> So shadow memory should be freed after module's memory.
> However, such deallocation order could race with kasan_module_alloc()
> in module_alloc().
>
> Free shadow right before releasing vm area. At this point vfree()'d
> memory is not used anymore and yet not available for other allocations.
> New VM_KASAN flag used to indicate that vm area has dynamically allocated
> shadow memory so kasan frees shadow only if it was previously allocated.
>
> Signed-off-by: Andrey Ryabinin
> Cc: Dmitry Vyukov
> Cc: Rusty Russell
Acked-by: Rusty Russell
Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] kasan, module: move MODULE_ALIGN macro into
Andrey Ryabinin writes:
> include/linux/moduleloader.h is more suitable place for this macro.
> Also change alignment to PAGE_SIZE for CONFIG_KASAN=n as such
> alignment already assumed in several places.
>
> Signed-off-by: Andrey Ryabinin
> Cc: Dmitry Vyukov
> Cc: Rusty Russell
Acked-by: Rusty Russell
Thanks,
Rusty.
> ---
> include/linux/kasan.h| 4
> include/linux/moduleloader.h | 8
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5fa48a2..5bb0744 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -50,15 +50,11 @@ void kasan_krealloc(const void *object, size_t new_size);
> void kasan_slab_alloc(struct kmem_cache *s, void *object);
> void kasan_slab_free(struct kmem_cache *s, void *object);
>
> -#define MODULE_ALIGN (PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT)
> -
> int kasan_module_alloc(void *addr, size_t size);
> void kasan_free_shadow(const struct vm_struct *vm);
>
> #else /* CONFIG_KASAN */
>
> -#define MODULE_ALIGN 1
> -
> static inline void kasan_unpoison_shadow(const void *address, size_t size) {}
>
> static inline void kasan_enable_current(void) {}
> diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> index f755626..4d0cb9b 100644
> --- a/include/linux/moduleloader.h
> +++ b/include/linux/moduleloader.h
> @@ -84,4 +84,12 @@ void module_arch_cleanup(struct module *mod);
>
> /* Any cleanup before freeing mod->module_init */
> void module_arch_freeing_init(struct module *mod);
> +
> +#ifdef CONFIG_KASAN
> +#include
> +#define MODULE_ALIGN (PAGE_SIZE << KASAN_SHADOW_SCALE_SHIFT)
> +#else
> +#define MODULE_ALIGN PAGE_SIZE
> +#endif
> +
> #endif
> --
> 2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: svm: use kvm_fast_pio_in()
From: David Kaplan We can make the in instruction go faster the same way the out instruction is already. Signed-off-by: David Kaplan [extracted from larger unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp --- arch/x86/kvm/svm.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index d319e0c..f8c906b 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -1899,7 +1899,7 @@ static int io_interception(struct vcpu_svm *svm) ++svm->vcpu.stat.io_exits; string = (io_info & SVM_IOIO_STR_MASK) != 0; in = (io_info & SVM_IOIO_TYPE_MASK) != 0; - if (string || in) + if (string) return emulate_instruction(vcpu, 0) == EMULATE_DONE; port = io_info >> 16; @@ -1907,6 +1907,8 @@ static int io_interception(struct vcpu_svm *svm) svm->next_rip = svm->vmcb->control.exit_info_2; skip_emulated_instruction(>vcpu); + if (in) + return kvm_fast_pio_in(vcpu, size, port); return kvm_fast_pio_out(vcpu, size, port); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] proc: introduce /proc//lbr_stack
On Fri, Feb 27, 2015 at 11:05:45PM +0100, Peter Zijlstra wrote: > On Fri, Feb 27, 2015 at 09:54:34AM -0800, Andi Kleen wrote: > > > > perf record doesn't show where you're currently blocked. > > > > > > Of course it does; look at perf inject -s. > > > > Trace points don't support the LBR stack. > > Yes, indeed. But would it not make much more sense to squirrel the LBR > state into sched:sched_switch and teach that inject -s thing to dtrt, > than to make a proc file that's available on all archs but will only > work on 1-2 x86 uarchs and only if you're also running the right magic > perf record at the same time? Yes. It would be nice to capture the whole PMU state in trace points. There are use models for this where it can work better than sampling. But that would be a lot bigger project than this simple file, which is already quite useful with minimal effort. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4 RESEND] ocfs2: remove goto statement in ocfs2_check_dir_for_entry()
Signed-off-by: Daeseok Youn
---
RESEND: this patch is rebased by 1/4.
fs/ocfs2/dir.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index c63f2b6..b3ab2a6 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -2043,22 +2043,19 @@ int ocfs2_check_dir_for_entry(struct inode *dir,
const char *name,
int namelen)
{
- int ret;
+ int ret = 0;
struct ocfs2_dir_lookup_result lookup = { NULL, };
trace_ocfs2_check_dir_for_entry(
(unsigned long long)OCFS2_I(dir)->ip_blkno, namelen, name);
- ret = -EEXIST;
- if (ocfs2_find_entry(name, namelen, dir, ) == 0)
- goto bail;
+ if (ocfs2_find_entry(name, namelen, dir, ) == 0) {
+ ret = -EEXIST;
+ mlog_errno(ret);
+ }
- ret = 0;
-bail:
ocfs2_free_dir_lookup_result();
- if (ret)
- mlog_errno(ret);
return ret;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: cma: fix CMA aligned offset calculation
On Fri, 27 Feb 2015 15:52:56 -0800 Danesh Petigara wrote: > On 2/27/2015 1:24 PM, Andrew Morton wrote: > > On Tue, 24 Feb 2015 15:39:45 -0800 Danesh Petigara > > wrote: > > > >> The CMA aligned offset calculation is incorrect for > >> non-zero order_per_bit values. > >> > >> For example, if cma->order_per_bit=1, cma->base_pfn= > >> 0x2f80 and align_order=12, the function returns > >> a value of 0x17c00 instead of 0x400. > >> > >> This patch fixes the CMA aligned offset calculation. > > > > When fixing a bug please always describe the end-user visible effects > > of that bug. > > > > Without that information others are unable to understand why you are > > recommending a -stable backport. > > > > Thank you for the feedback. I had no crash logs to show, nevertheless, I > agree that a sentence describing potential effects of the bug would've > helped. What was the reason for adding a cc:stable? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: ALPS - fix memory leak when detection fails
This fixes memory leak introduced by commit
a09221e83e13e09a33109b9b037484eade901cea
Signed-off-by: Dmitry Torokhov
---
drivers/input/mouse/alps.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index d28726a..1bd15eb 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -2605,8 +2605,10 @@ int alps_detect(struct psmouse *psmouse, bool
set_properties)
return -ENOMEM;
error = alps_identify(psmouse, priv);
- if (error)
+ if (error) {
+ kfree(priv);
return error;
+ }
if (set_properties) {
psmouse->vendor = "ALPS";
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4 RESEND] ocfs2: need to handle error for ocfs2_journal_access_di() call
There is no error handle when ocfs2_journal_access_di() is failed.
And also it doesn't need to call ocfs2_dx_dir_insert() when
ocfs2_journal_access_db() is failed.
Signed-off-by: Daeseok Youn
---
RESEND: this patch rebased by 1/4
fs/ocfs2/dir.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index c1ab24f..c63f2b6 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1703,15 +1703,15 @@ int __ocfs2_add_entry(handle_t *handle,
insert_bh,
OCFS2_JOURNAL_ACCESS_WRITE);
- if (ocfs2_dir_indexed(dir)) {
+ if (!retval && ocfs2_dir_indexed(dir))
retval = ocfs2_dx_dir_insert(dir,
handle,
lookup);
- if (retval)
- goto bail;
- }
}
+ if (retval)
+ goto bail;
+
/* By now the buffer is marked for journaling */
offset += le16_to_cpu(de->rec_len);
if (le64_to_cpu(de->inode)) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: cma: fix CMA aligned offset calculation
On 2/27/2015 1:24 PM, Andrew Morton wrote: > On Tue, 24 Feb 2015 15:39:45 -0800 Danesh Petigara > wrote: > >> The CMA aligned offset calculation is incorrect for >> non-zero order_per_bit values. >> >> For example, if cma->order_per_bit=1, cma->base_pfn= >> 0x2f80 and align_order=12, the function returns >> a value of 0x17c00 instead of 0x400. >> >> This patch fixes the CMA aligned offset calculation. > > When fixing a bug please always describe the end-user visible effects > of that bug. > > Without that information others are unable to understand why you are > recommending a -stable backport. > Thank you for the feedback. I had no crash logs to show, nevertheless, I agree that a sentence describing potential effects of the bug would've helped. I'll keep that in mind for future submissions. Best Regards, Danesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4 RESEND] ocfs2: remove extra mlog_errno() call in __ocfs2_add_entry()
Signed-off-by: Daeseok Youn
---
RESEND: this patch is rebased by 1/4
fs/ocfs2/dir.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index 1478a50..c1ab24f 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1689,10 +1689,8 @@ int __ocfs2_add_entry(handle_t *handle,
if (ocfs2_dirent_would_fit(de, rec_len)) {
dir->i_mtime = dir->i_ctime = CURRENT_TIME;
retval = ocfs2_mark_inode_dirty(handle, dir,
parent_fe_bh);
- if (retval < 0) {
- mlog_errno(retval);
+ if (retval < 0)
goto bail;
- }
if (insert_bh == parent_fe_bh)
retval = ocfs2_journal_access_di(handle,
@@ -1709,10 +1707,8 @@ int __ocfs2_add_entry(handle_t *handle,
retval = ocfs2_dx_dir_insert(dir,
handle,
lookup);
- if (retval) {
- mlog_errno(retval);
+ if (retval)
goto bail;
- }
}
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4 V2] ocfs2: use retval instead of status for checking error
The use of 'status' in __ocfs2_add_entry() can return wrong
status when some functions are failed.
If ocfs2_journal_access_db() in __ocfs2_add_entry() is failed,
that status is saved to 'status' but return variable is 'retval'
which is saved 'success' status. In case of this, __ocfs2_add_entry()
is failed but can be returned as 'success'.
So replace 'status' with 'retval'.
Signed-off-by: Daeseok Youn
---
V2 : update changelog
fs/ocfs2/dir.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index b08050b..1478a50 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1617,7 +1617,7 @@ int __ocfs2_add_entry(handle_t *handle,
struct ocfs2_dir_entry *de, *de1;
struct ocfs2_dinode *di = (struct ocfs2_dinode *)parent_fe_bh->b_data;
struct super_block *sb = dir->i_sb;
- int retval, status;
+ int retval;
unsigned int size = sb->s_blocksize;
struct buffer_head *insert_bh = lookup->dl_leaf_bh;
char *data_start = insert_bh->b_data;
@@ -1695,22 +1695,22 @@ int __ocfs2_add_entry(handle_t *handle,
}
if (insert_bh == parent_fe_bh)
- status = ocfs2_journal_access_di(handle,
+ retval = ocfs2_journal_access_di(handle,
INODE_CACHE(dir),
insert_bh,
OCFS2_JOURNAL_ACCESS_WRITE);
else {
- status = ocfs2_journal_access_db(handle,
+ retval = ocfs2_journal_access_db(handle,
INODE_CACHE(dir),
insert_bh,
OCFS2_JOURNAL_ACCESS_WRITE);
if (ocfs2_dir_indexed(dir)) {
- status = ocfs2_dx_dir_insert(dir,
+ retval = ocfs2_dx_dir_insert(dir,
handle,
lookup);
- if (status) {
- mlog_errno(status);
+ if (retval) {
+ mlog_errno(retval);
goto bail;
}
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH, RESEND] usb: musb: fix Kconfig regression
Hi,
On Sat, Feb 28, 2015 at 12:19:41AM +0100, Arnd Bergmann wrote:
> A recent bug fix I did that was marked for stable backports
> introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY.
>
> I was missing the fact that the PHY driver already stubs out the
> omap_control_usb_set_mode, and we only need to add a dependency
> to prevent the musb-omap2430 driver from being built-in when
> the phy driver is a loadable module, but we should not prevent it
> from being built altogether when the phy driver is disabled.
>
> Signed-off-by: Arnd Bergmann
> Fixes: ca784be36cc725 ("usb: start using the control module driver")
> Acked-by: Acked-by: Pavel Machek
> Cc: # v3.9+
This patch allows me to disable redundant CONFIG_OMAP_CONTROL_PHY
from 4.0-rc1 .config and still get a working USB on Nokia N9. So:
Tested-by: Aaro Koskinen
Thanks,
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] scsi: storvsc: Always send on the selected outgoing channel
The current code always sent packets without data on the primary channel.
Properly distribute sending of packets with no data amongst all available
channels. I would like to thank Long Li for noticing this problem.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Long Li
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 5a12897..be8f12e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1362,7 +1362,7 @@ static int storvsc_do_io(struct hv_device *device,
vmscsi_size_delta),
(unsigned long)request);
} else {
- ret = vmbus_sendpacket(device->channel, vstor_packet,
+ ret = vmbus_sendpacket(outgoing_channel, vstor_packet,
(sizeof(struct vstor_packet) -
vmscsi_size_delta),
(unsigned long)request,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] scsi: storvsc: Size the queue depth based on the ringbuffer size
Size the queue depth based on the ringbuffer size. Also accomodate for the
fact that we could have multiple channels (ringbuffers) per adaptor.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Long Li
---
drivers/scsi/storvsc_drv.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 27fe850..5a12897 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -309,10 +309,15 @@ enum storvsc_request_type {
*/
static int storvsc_ringbuffer_size = (256 * PAGE_SIZE);
+static u32 max_outstanding_req_per_channel;
+
+static int storvsc_vcpus_per_sub_channel = 4;
module_param(storvsc_ringbuffer_size, int, S_IRUGO);
MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)");
+module_param(storvsc_vcpus_per_sub_channel, int, S_IRUGO);
+MODULE_PARM_DESC(vcpus_per_sub_channel, "Ratio of VCPUs to subchannels");
/*
* Timeout in seconds for all devices managed by this driver.
*/
@@ -320,7 +325,6 @@ static int storvsc_timeout = 180;
static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
-#define STORVSC_MAX_IO_REQUESTS200
static void storvsc_on_channel_callback(void *context);
@@ -1376,7 +1380,6 @@ static int storvsc_do_io(struct hv_device *device,
static int storvsc_device_configure(struct scsi_device *sdevice)
{
- scsi_change_queue_depth(sdevice, STORVSC_MAX_IO_REQUESTS);
blk_queue_max_segment_size(sdevice->request_queue, PAGE_SIZE);
@@ -1646,7 +1649,6 @@ static struct scsi_host_template scsi_driver = {
.eh_timed_out = storvsc_eh_timed_out,
.slave_configure = storvsc_device_configure,
.cmd_per_lun = 255,
- .can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
.this_id = -1,
/* no use setting to 0 since ll_blk_rw reset it to 1 */
/* currently 32 */
@@ -1686,6 +1688,7 @@ static int storvsc_probe(struct hv_device *device,
const struct hv_vmbus_device_id *dev_id)
{
int ret;
+ int num_cpus = num_online_cpus();
struct Scsi_Host *host;
struct hv_host_device *host_dev;
bool dev_is_ide = ((dev_id->driver_data == IDE_GUID) ? true : false);
@@ -1694,6 +1697,7 @@ static int storvsc_probe(struct hv_device *device,
int max_luns_per_target;
int max_targets;
int max_channels;
+ int max_sub_channels = 0;
/*
* Based on the windows host we are running on,
@@ -1719,12 +1723,18 @@ static int storvsc_probe(struct hv_device *device,
max_luns_per_target = STORVSC_MAX_LUNS_PER_TARGET;
max_targets = STORVSC_MAX_TARGETS;
max_channels = STORVSC_MAX_CHANNELS;
+ /*
+* On Windows8 and above, we support sub-channels for storage.
+* The number of sub-channels offerred is based on the number of
+* VCPUs in the guest.
+*/
+ max_sub_channels = (num_cpus / storvsc_vcpus_per_sub_channel);
break;
}
- if (dev_id->driver_data == SFC_GUID)
- scsi_driver.can_queue = (STORVSC_MAX_IO_REQUESTS *
-STORVSC_FC_MAX_TARGETS);
+ scsi_driver.can_queue = (max_outstanding_req_per_channel *
+max_sub_channels + 1);
+
host = scsi_host_alloc(_driver,
sizeof(struct hv_host_device));
if (!host)
@@ -1837,7 +1847,6 @@ static struct hv_driver storvsc_drv = {
static int __init storvsc_drv_init(void)
{
- u32 max_outstanding_req_per_channel;
/*
* Divide the ring buffer data size (which is 1 page less
@@ -1852,10 +1861,6 @@ static int __init storvsc_drv_init(void)
vmscsi_size_delta,
sizeof(u64)));
- if (max_outstanding_req_per_channel <
- STORVSC_MAX_IO_REQUESTS)
- return -EINVAL;
-
return vmbus_driver_register(_drv);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] scsi: storvsc: Increase the ring buffer size
Increase the default ring buffer size as this can significantly
improve performance especially on high latency storage back-ends.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: Long Li
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index efc6e44..27fe850 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -308,7 +308,7 @@ enum storvsc_request_type {
* This is the end of Protocol specific defines.
*/
-static int storvsc_ringbuffer_size = (20 * PAGE_SIZE);
+static int storvsc_ringbuffer_size = (256 * PAGE_SIZE);
module_param(storvsc_ringbuffer_size, int, S_IRUGO);
MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] Input: bcm-keypad: Add Broadcom keypad controller
Hi Scott, Mostly style nitpicks here... On Thu, Feb 26, 2015 at 08:08:49AM -0800, Scott Branden wrote: > Add driver for Broadcom's keypad controller. > > Broadcom Keypad controller is used to interface a SoC with a matrix-type > keypad device. The keypad controller supports multiple row and column lines. > A key can be placed at each intersection of a unique row and a unique column. > The keypad controller can sense a key-press and key-release and report the > event using a interrupt to the cpu. > > Reviewed-by: Ray Jui > Signed-off-by: Scott Branden > --- > drivers/input/keyboard/Kconfig | 10 + > drivers/input/keyboard/Makefile | 1 + > drivers/input/keyboard/bcm-keypad.c | 464 > > 3 files changed, 475 insertions(+) > create mode 100644 drivers/input/keyboard/bcm-keypad.c > > diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig > index a5d9b3f..3a0c0f2 100644 > --- a/drivers/input/keyboard/Kconfig > +++ b/drivers/input/keyboard/Kconfig > @@ -676,4 +676,14 @@ config KEYBOARD_CAP11XX > To compile this driver as a module, choose M here: the > module will be called cap11xx. > > +config KEYBOARD_BCM > + tristate "Broadcom keypad driver" > + select INPUT_MATRIXKMAP > + default ARCH_BCM_CYGNUS > + help > + Say Y here if you want to use Broadcom keypad. > + > + To compile this driver as a module, choose M here: the > + module will be called bcm-keypad. > + > endif > diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile > index febafa5..3cff8f6 100644 > --- a/drivers/input/keyboard/Makefile > +++ b/drivers/input/keyboard/Makefile > @@ -10,6 +10,7 @@ obj-$(CONFIG_KEYBOARD_ADP5589) += > adp5589-keys.o > obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o > obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o > obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o > +obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o > obj-$(CONFIG_KEYBOARD_BFIN) += bf54x-keys.o > obj-$(CONFIG_KEYBOARD_CAP11XX) += cap11xx.o > obj-$(CONFIG_KEYBOARD_CLPS711X) += clps711x-keypad.o > diff --git a/drivers/input/keyboard/bcm-keypad.c > b/drivers/input/keyboard/bcm-keypad.c > new file mode 100644 > index 000..f229ac0 > --- /dev/null > +++ b/drivers/input/keyboard/bcm-keypad.c > @@ -0,0 +1,464 @@ > +/* > + * Copyright (C) 2014 Broadcom Corporation > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation version 2. > + * > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any > + * kind, whether express or implied; without even the implied warranty > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DEFAULT_CLK_HZ 31250 > +/* Repeat period (ms) */ > +#define KEY_REPEAT_PERIOD 100 > +/* First time press dly (ms) */ > +#define KEY_REPEAT_DELAY400 > +#define MAX_ROWS8 > +#define MAX_COLS8 > + > +/* Register/field definitions */ > +#define KPCR_OFFSET 0x0080 > +#define KPCR_MODE 0x0002 > +#define KPCR_MODE_SHIFT 1 > +#define KPCR_MODE_MASK 1 > +#define KPCR_ENABLE 0x0001 > +#define KPCR_STATUSFILTERENABLE 0x8000 > +#define KPCR_STATUSFILTERTYPE_SHIFT 12 > +#define KPCR_COLFILTERENABLE0x0800 > +#define KPCR_COLFILTERTYPE_SHIFT 8 > +#define KPCR_ROWWIDTH_SHIFT 20 > +#define KPCR_COLUMNWIDTH_SHIFT 16 > + > +#define KPIOR_OFFSET 0x0084 > +#define KPIOR_ROWOCONTRL_SHIFT 24 > +#define KPIOR_ROWOCONTRL_MASK0xFF00 > +#define KPIOR_COLUMNOCONTRL_SHIFT16 > +#define KPIOR_COLUMNOCONTRL_MASK 0x00FF > +#define KPIOR_COLUMN_IO_DATA_SHIFT 0 > + > +#define KPEMR0_OFFSET0x0090 > +#define KPEMR1_OFFSET0x0094 > +#define KPEMR2_OFFSET0x0098 > +#define KPEMR3_OFFSET0x009C > +#define KPEMR_EDGETYPE_BOTH 3 > + > +#define KPSSR0_OFFSET0x00A0 > +#define KPSSR1_OFFSET0x00A4 > +#define KPSSRN_OFFSET(reg_n) (KPSSR0_OFFSET + (4 * reg_n)) > +#define KPIMR0_OFFSET0x00B0 > +#define KPIMR1_OFFSET
Re: [PATCH v2 1/2] Input: bcm-keypad: add device tree bindings
Hi Scott, On Thu, Feb 26, 2015 at 08:08:48AM -0800, Scott Branden wrote: > Documents the Broadcom keypad controller device tree bindings. > > Reviewed-by: Ray Jui > Signed-off-by: Scott Branden > --- > .../devicetree/bindings/input/brcm,bcm-keypad.txt | 108 > + > 1 file changed, 108 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt > > diff --git a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt > b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt > new file mode 100644 > index 000..e16bb2d > --- /dev/null > +++ b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt > @@ -0,0 +1,108 @@ > +* Broadcom Keypad Controller device tree bindings > + > +Broadcom Keypad controller is used to interface a SoC with a matrix-type > +keypad device. The keypad controller supports multiple row and column lines. > +A key can be placed at each intersection of a unique row and a unique column. > +The keypad controller can sense a key-press and key-release and report the > +event using a interrupt to the cpu. > + > +This binding is based on the matrix-keymap binding with the following > +changes: > + > +keypad,num-rows and keypad,num-columns are required. > + > +Required SoC Specific Properties: > +- compatible: should be "brcm,bcm-keypad" > + > +- reg: physical base address of the controller and length of memory mapped > + region. > + > +- interrupts: The interrupt number to the cpu. > + > +Board Specific Properties: > +- keypad,num-rows: Number of row lines connected to the keypad > + controller. > + > +- keypad,num-columns: Number of column lines connected to the > + keypad controller. > + > +- col-debounce-filter-period: The debounce period for the Column filter. > + > + KEYPAD_DEBOUNCE_1_ms= 0 > + KEYPAD_DEBOUNCE_2_ms= 1 > + KEYPAD_DEBOUNCE_4_ms= 2 > + KEYPAD_DEBOUNCE_8_ms= 3 > + KEYPAD_DEBOUNCE_16_ms = 4 > + KEYPAD_DEBOUNCE_32_ms = 5 > + KEYPAD_DEBOUNCE_64_ms = 6 > + KEYPAD_DEBOUNCE_128_ms = 7 > + > +- status-debounce-filter-period: The debounce period for the Status filter. > + > + KEYPAD_DEBOUNCE_1_ms= 0 > + KEYPAD_DEBOUNCE_2_ms= 1 > + KEYPAD_DEBOUNCE_4_ms= 2 > + KEYPAD_DEBOUNCE_8_ms= 3 > + KEYPAD_DEBOUNCE_16_ms = 4 > + KEYPAD_DEBOUNCE_32_ms = 5 > + KEYPAD_DEBOUNCE_64_ms = 6 > + KEYPAD_DEBOUNCE_128_ms = 7 > + > +- row-output-enabled: An optional property indicating whether the row or > + column is being used as output. If specified the row is being used > + as the output. Else defaults to column. > + > +- pull-up-enabled: An optional property indicating the Keypad scan mode. > + If specified implies the keypad scan pull-up has been enabled. > + > +- linux,keypad-no-autorepeat: An optional property indicating to > + not enable autorepeat feature. Unfortunately we've accumulated a lot of bindings for turning autorepeat on or off, I would prefer if we standardize on what gpio-keys is doing and use "autorepeat" (no "linux,") for new drivers. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
Lee Jones writes: >> I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does >> exist. What is the usecase that is covered by this patchset which is not >> used by >> CLK_IGNORE_UNUSED clock flag ? >> >> And if that reason exists, I'd like to find it in the commit message. > > The problem is applying that flag in a generic way. > > However, I guess you haven't seen this [1] yet? > > [1] https://lkml.org/lkml/2015/2/27/548 I have. And yet : 1) This won't go in a _commit_ message (as opposed to cover-letter). Moreover it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it says, up to my understanding, that is it another way to have to CLK_IGNORE_UNUSED flag applied. 2) I still fail to see why this is necessary IOW why declaring the mandatory always-on clocks with the proper flag should be augmented with a new clock list. Isn't the existing flag the generic way ? I might not understand the real motivation behind that of course, that's why I'm asking. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sys.c: Fix UNAME26 for 4.0
I'll raise my hand in agreement with Andi -- this is functionality that we do use. Tested-by: Matt Mullins -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] scsi: storvsc: Some enhancements
While testing on some high latency storage backends, to get the advertised IOPS, we have to increase the size of the ringbuffer. Address this issue. K. Y. Srinivasan (3): scsi: storvsc: Increase the ring buffer size Scsi: storvsc: Size the queue depth based on the ringbuffer size scsi: storvsc: Always send on the selected outgoing channel drivers/scsi/storvsc_drv.c | 30 +- 1 files changed, 17 insertions(+), 13 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] remoteproc/davinci: fix quoted split string checkpatch warning
On Fri, 2015-02-27 at 17:18 -0600, Suman Anna wrote: > Fix the following checkpatch warning, > WARNING: quoted string split across lines > +"\n\t\tName of DSP firmware file in /lib/firmware" > +" (if not specified defaults to 'rproc-dsp-fw')"); [] > diff --git a/drivers/remoteproc/da8xx_remoteproc.c > b/drivers/remoteproc/da8xx_remoteproc.c [] > @@ -26,8 +26,7 @@ > static char *da8xx_fw_name; > module_param(da8xx_fw_name, charp, S_IRUGO); > MODULE_PARM_DESC(da8xx_fw_name, > - "\n\t\tName of DSP firmware file in /lib/firmware" > - " (if not specified defaults to 'rproc-dsp-fw')"); > + "\n\t\tName of DSP firmware file in /lib/firmware (if not > specified defaults to 'rproc-dsp-fw')"); There's probably no value in the leading "\n\t\t" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] remoteproc/ste: add blank lines after declarations
On Fri, 2015-02-27 at 17:18 -0600, Suman Anna wrote:
> Fix couple of checkpatch warnings of the type,
> "WARNING: Missing a blank line after declarations"
[]
> diff --git a/drivers/remoteproc/ste_modem_rproc.c
> b/drivers/remoteproc/ste_modem_rproc.c
[]
> @@ -230,6 +229,7 @@ static int sproc_start(struct rproc *rproc)
> static int sproc_stop(struct rproc *rproc)
> {
> struct sproc *sproc = rproc->priv;
> +
> sproc_dbg(sproc, "stop ste-modem\n");
You could probably delete this sproc_dbg
statement too as it duplicates function tracing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts
Hi,
Am Freitag, 27. Februar 2015, 16:14:53 schrieb Kumar Gala:
> Add initial device tree support for Qualcomm MSM8916 SoC and MTP8916
> evaluation board. At the current time we only boot up a single processor.
>
> Signed-off-by: Kumar Gala
> ---
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/qcom/Makefile | 5 +
> arch/arm64/boot/dts/qcom/msm8916-mtp.dts | 21
> arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi | 24
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 188
> ++ 5 files changed, 239 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/Makefile
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dts
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916.dtsi
>
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index e0350ca..8517f15 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -5,5 +5,6 @@ dts-dirs += cavium
> dts-dirs += exynos
> dts-dirs += freescale
> dts-dirs += mediatek
> +dts-dirs += qcom
>
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile new file mode 100644
> index 000..c1ab1c3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_QCOM_MSM8916) += msm8916-mtp.dtb
> +
> +always := $(dtb-y)
> +subdir-y := $(dts-dirs)
> +clean-files := *.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
> b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts new file mode 100644
> index 000..acfe037
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
> @@ -0,0 +1,21 @@
> +/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 and
> +* only version 2 as published by the Free Software Foundation.
> +*
> +* This program is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +* GNU General Public License for more details.
> +*/
> +
> +/dts-v1/;
> +
> +#include "msm8916-mtp.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
> + compatible = "qcom,msm8916-mtp", "qcom,msm8916", "qcom,mtp";
> + qcom,board-id = <8 0>, <8 1>;
qcom,board-id seems undocumented - grep through devicetree/bindings didn't
turn up anything. [or I'm just blind]
> +};
[...]
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi new file mode 100644
> index 000..72ad0f7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -0,0 +1,188 @@
> +/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "skeleton.dtsi"
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. MSM8916";
> + compatible = "qcom,msm8916";
> + qcom,msm-id = <206 0>,
> + <248 0>,
> + <249 0>,
> + <250 0>;
same for this - nothing found in the devicetree/bindings from 4.0-rc1
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH, RESEND] usb: musb: fix Kconfig regression
A recent bug fix I did that was marked for stable backports
introduced a slightly wrong dependency on CONFIG_OMAP_CONTROL_PHY.
I was missing the fact that the PHY driver already stubs out the
omap_control_usb_set_mode, and we only need to add a dependency
to prevent the musb-omap2430 driver from being built-in when
the phy driver is a loadable module, but we should not prevent it
from being built altogether when the phy driver is disabled.
Signed-off-by: Arnd Bergmann
Fixes: ca784be36cc725 ("usb: start using the control module driver")
Acked-by: Acked-by: Pavel Machek
Cc: # v3.9+
---
Same patch as first time, now with correct recipient and with Pavel's
Ack added.
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 14e1628483d9..39db8b603627 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -79,7 +79,8 @@ config USB_MUSB_TUSB6010
config USB_MUSB_OMAP2PLUS
tristate "OMAP2430 and onwards"
- depends on ARCH_OMAP2PLUS && USB && OMAP_CONTROL_PHY
+ depends on ARCH_OMAP2PLUS && USB
+ depends on OMAP_CONTROL_PHY || !OMAP_CONTROL_PHY
select GENERIC_PHY
config USB_MUSB_AM35X
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] remoteproc/ste: add blank lines after declarations
Fix couple of checkpatch warnings of the type,
"WARNING: Missing a blank line after declarations"
Signed-off-by: Suman Anna
---
drivers/remoteproc/ste_modem_rproc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/ste_modem_rproc.c
b/drivers/remoteproc/ste_modem_rproc.c
index 16b7b7bd805b..cdfcb3f84b3b 100644
--- a/drivers/remoteproc/ste_modem_rproc.c
+++ b/drivers/remoteproc/ste_modem_rproc.c
@@ -67,8 +67,7 @@ static int sproc_load_segments(struct rproc *rproc, const
struct firmware *fw)
static const struct ste_toc_entry *sproc_find_rsc_entry(const void *data)
{
int i;
- const struct ste_toc *toc;
- toc = data;
+ const struct ste_toc *toc = data;
/* Search the table for the resource table */
for (i = 0; i < SPROC_MAX_TOC_ENTRIES &&
@@ -230,6 +229,7 @@ static int sproc_start(struct rproc *rproc)
static int sproc_stop(struct rproc *rproc)
{
struct sproc *sproc = rproc->priv;
+
sproc_dbg(sproc, "stop ste-modem\n");
return sproc->mdev->ops.power(sproc->mdev, false);
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] remoteproc checkpatch fixes
Hi Ohad, Please find couple of patches to fix a number of checkpatch warnings that have crept back into the remoteproc code. Note that I haven't fixed the warnings thrown with --strict option. regards Suman Suman Anna (3): remoteproc/ste: add blank lines after declarations remoteproc/davinci: fix quoted split string checkpatch warning remoteproc: fix various checkpatch warnings drivers/remoteproc/da8xx_remoteproc.c| 3 +-- drivers/remoteproc/remoteproc_core.c | 27 +-- drivers/remoteproc/remoteproc_internal.h | 2 +- drivers/remoteproc/ste_modem_rproc.c | 4 ++-- 4 files changed, 13 insertions(+), 23 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] remoteproc: fix various checkpatch warnings
Fix all the checkpatch warnings in the core remoteproc
code. The fixes cover the following warnings:
1. WARNING: void function return statements are not generally useful
2. WARNING: Possible unnecessary 'out of memory' message
3. WARNING: line over 80 characters
4. WARNING: braces {} are not necessary for single statement blocks
5. WARNING: Unnecessary space before function pointer arguments
Signed-off-by: Suman Anna
---
drivers/remoteproc/remoteproc_core.c | 27 +--
drivers/remoteproc/remoteproc_internal.h | 2 +-
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3cd85a638afa..fd824fc2fc45 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -143,8 +143,6 @@ static void rproc_disable_iommu(struct rproc *rproc)
iommu_detach_device(domain, dev);
iommu_domain_free(domain);
-
- return;
}
/*
@@ -422,10 +420,8 @@ static int rproc_handle_trace(struct rproc *rproc, struct
fw_rsc_trace *rsc,
}
trace = kzalloc(sizeof(*trace), GFP_KERNEL);
- if (!trace) {
- dev_err(dev, "kzalloc trace failed\n");
+ if (!trace)
return -ENOMEM;
- }
/* set the trace buffer dma properties */
trace->len = rsc->len;
@@ -500,10 +496,8 @@ static int rproc_handle_devmem(struct rproc *rproc, struct
fw_rsc_devmem *rsc,
}
mapping = kzalloc(sizeof(*mapping), GFP_KERNEL);
- if (!mapping) {
- dev_err(dev, "kzalloc mapping failed\n");
+ if (!mapping)
return -ENOMEM;
- }
ret = iommu_map(rproc->domain, rsc->da, rsc->pa, rsc->len, rsc->flags);
if (ret) {
@@ -576,10 +570,8 @@ static int rproc_handle_carveout(struct rproc *rproc,
rsc->da, rsc->pa, rsc->len, rsc->flags);
carveout = kzalloc(sizeof(*carveout), GFP_KERNEL);
- if (!carveout) {
- dev_err(dev, "kzalloc carveout failed\n");
+ if (!carveout)
return -ENOMEM;
- }
va = dma_alloc_coherent(dev->parent, rsc->len, , GFP_KERNEL);
if (!va) {
@@ -779,7 +771,8 @@ static void rproc_resource_cleanup(struct rproc *rproc)
/* clean up carveout allocations */
list_for_each_entry_safe(entry, tmp, >carveouts, node) {
- dma_free_coherent(dev->parent, entry->len, entry->va,
entry->dma);
+ dma_free_coherent(dev->parent, entry->len, entry->va,
+ entry->dma);
list_del(>node);
kfree(entry);
}
@@ -819,9 +812,8 @@ static int rproc_fw_boot(struct rproc *rproc, const struct
firmware *fw)
/* look for the resource table */
table = rproc_find_rsc_table(rproc, fw, );
- if (!table) {
+ if (!table)
goto clean_up;
- }
/* Verify that resource table in loaded fw is unchanged */
if (rproc->table_csum != crc32(0, table, tablesz)) {
@@ -922,7 +914,8 @@ static void rproc_fw_config_virtio(const struct firmware
*fw, void *context)
/* count the number of notify-ids */
rproc->max_notifyid = -1;
- ret = rproc_handle_resources(rproc, tablesz,
rproc_count_vrings_handler);
+ ret = rproc_handle_resources(rproc, tablesz,
+rproc_count_vrings_handler);
if (ret)
goto out;
@@ -1279,10 +1272,8 @@ struct rproc *rproc_alloc(struct device *dev, const char
*name,
name_len = strlen(name) + strlen(template) - 2 + 1;
rproc = kzalloc(sizeof(struct rproc) + len + name_len, GFP_KERNEL);
- if (!rproc) {
- dev_err(dev, "%s: kzalloc failed\n", __func__);
+ if (!rproc)
return NULL;
- }
if (!firmware) {
p = (char *)rproc + sizeof(struct rproc) + len;
diff --git a/drivers/remoteproc/remoteproc_internal.h
b/drivers/remoteproc/remoteproc_internal.h
index 70701a50ddfa..8041b95cb058 100644
--- a/drivers/remoteproc/remoteproc_internal.h
+++ b/drivers/remoteproc/remoteproc_internal.h
@@ -35,7 +35,7 @@ struct rproc;
* @get_boot_addr: get boot address to entry point specified in firmware
*/
struct rproc_fw_ops {
- struct resource_table *(*find_rsc_table) (struct rproc *rproc,
+ struct resource_table *(*find_rsc_table)(struct rproc *rproc,
const struct firmware *fw,
int *tablesz);
struct resource_table *(*find_loaded_rsc_table)(struct rproc *rproc,
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
