* Re: [PATCH 2/7] powerpc/mm: 64-bit 4k: use a PMD-based virtual page table
From: Benjamin Herrenschmidt @ 2011-05-24 2:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110523183100.36c54904@schlenkerla.am.freescale.net>
On Mon, 2011-05-23 at 18:31 -0500, Scott Wood wrote:
> On Tue, 24 May 2011 06:51:01 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Is your linear mapping bolted ? If it is you may be able to cut out most
> > of the save/restore stuff (SRR0,1, ...) since with a normal walk you
> > won't take nested misses.
>
> It is bolted -- we ignore anything we can't map with 16 entries. The only
> semi-realistic case I can think of where we might bump into that (and thus
> want non-bolted memory), especially with more than negligible loss compared
> to the size of memory, is AMP with a non-zero start address where we have
> to stick with smaller pages due to alignment. Even so, 16 times the
> alignment of the start of RAM doesn't seem that unreasonable a limit. The
> 32-bit limit of 3 entries for lowmem is a bit more troublesome there.
Ok so in this case, it might be worth doing a separate of TLB miss
handlers without all the context save/restore business... would also
make re-entrant CRITs and MCs easier to deal with.
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
From: Benjamin Herrenschmidt @ 2011-05-24 3:40 UTC (permalink / raw)
To: Tirumala Marri; +Cc: Paul Mackerras, Ayman El-Khashab, linuxppc-dev
In-Reply-To: <6a09a426f126fb315b773fc207d68eb9@mail.gmail.com>
On Thu, 2011-05-12 at 11:16 -0700, Tirumala Marri wrote:
> So what is the best way to handle this? It appears (based
> on the comments of others and my own experience) that there
> is no DCR that exists and behaves the way that previous SOCs
> behaved to give us the link status?
The register above
> PECFGn_DLLSTA is actually in the PCIe configuration space so
> we would have to map that in to be able to read that
> register during the link check. Is that correct or ok?
> [marri] yes, you need to program DCR register access these local PCIE_CFG
> registers.
We do I think, tho we might have to re-order some stuff. I'm facing a
similar issue with some internal design here, I'm thinking off adding a
new hook to the ppc4xx_pciex_hwops for link checking to replace the SDR
business.
The interesting question of course is whether that 460SX stuff is the
same as what we're using internally :-)
> I've communicated with some people over email and they had
> tried the (PESDRn_HSSLySTS) register. Recognizing that
> there exists one of these for each port/lane, is there a way
> to use this one? It is in the indirect DCR space. I'd
> tried this myself and never did get it to do anything but I
> could have been looking at the wrong lane or something.
> [marri]This is at SERDES level. If this link up doesn't necessarily
> Overall stack is up. This is mostly used for BIST and diagnostics.
>
> Lastly, what was the reason for forcing the original code to
> be GEN-1 speeds?
> [marri] Gen-2 need some extra checks compared to Gen-1.
> There were not many Gen-2 devices at the time of submission
> To test them.
Can we fix that ?
Cheers,
Ben.
^ permalink raw reply
* Re: Kernel cannot see PCI device
From: Prashant Bhole @ 2011-05-24 4:55 UTC (permalink / raw)
To: Bjorn Helgaas, Benjamin Herrenschmidt
Cc: linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <BANLkTi=bs31L=C+XWGeXG49xuFVzt+omgA@mail.gmail.com>
Hi,
On Fri, May 20, 2011 at 4:49 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Thu, May 19, 2011 at 5:12 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Thu, 2011-05-19 at 11:58 -0600, Bjorn Helgaas wrote:
>>> The scan below PCIX0 (bus 0001:00) doesn't find anything. =A0You really
>>> need a powerpc expert to help here, but in their absence, my guess
>>> would be something's wrong with config space access, so I would start
>>> by just adding some printks to ppc4xx_probe_pcix_bridge() to see if
>>> the rsrc_cfg address looks reasonable. =A0You might need a chip spec or
>>> maybe you can compare it to the device tree (I have no idea what the
>>> relation between the device tree and OF is).
>>>
>>> You mentioned the u-boot "pci 2" command earlier. =A0It found a device
>>> on bus 2, which means there must be at least one P2P bridge to get you
>>> from bus 0 to bus 2. =A0So the output of "pci 0", "pci 1", "pci 80", an=
d
>>> "pci 81" (to compare with what Linux found) would be interesting.
>>
>> Well, if it's PCIe, there's the "virtual" P2P bridge of the root
>> complex.
>>
>> The question is on what PCIe is his device connected, the one that we
>> see or the one that's disabled in the device-tree.
>
> I *think* the device Prashant is looking for ("02.00.00 =A0 0x1000
> 0x0072 =A0 =A0 Mass storage controller 0x00") is below the PCI-X bridge;
> at least the canyonlands.dts he posted says that PCIX0 leads to buses
> 0-3f.
>
Fixed the problem by soft resetting the PCIe port in the function
ppc460ex_pciex_port_init_hw().
Is it a right thing to do?
Following is the patch for kernel 2.6.38.4:
---------------------------------------------------------------------------=
-----------
--- linux-2.6.38.4/arch/powerpc/sysdev/ppc4xx_pci.c.orig 2011-05-24
10:02:38.000000000 +0530
+++ linux-2.6.38.4/arch/powerpc/sysdev/ppc4xx_pci.c 2011-05-24
10:07:17.000000000 +0530
@@ -876,6 +876,20 @@
u32 val;
u32 utlset1;
+ switch (port->index)
+ {
+ case 0:
+ mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST, 0x0);
+ mdelay(10);
+ break;
+ case 1:
+ mtdcri(SDR0, PESDR1_460EX_PHY_CTL_RST, 0x0);
+ mdelay(10);
+ break;
+ default:
+ break;
+ }
+
if (port->endpoint)
val =3D PTYPE_LEGACY_ENDPOINT << 20;
else
---------------------------------------------------------------------------=
-----------
- Prashant
^ permalink raw reply
* RE: PCI DMA to user mem on mpc83xx
From: David Laight @ 2011-05-24 8:15 UTC (permalink / raw)
To: Andre Schwarz, Ira W. Snyder; +Cc: LinuxPPC List
In-Reply-To: <4DDA2509.6070702@matrix-vision.de>
=20
> we have a pretty old PCI device driver here that needs some
> basic rework running on 2.6.27 on several MPC83xx.
> It's a simple char-device with "give me some data" implemented
> using read() resulting in zero-copy DMA to user mem.
>=20
> There's get_user_pages() working under the hood along with=20
> SetPageDirty() and page_cache_release().
Does that dma use the userspace virtual address, or the
physical address - or are you remapping the user memory into
kernel address space.
If the memory is remapped into the kernel address space, the
cost of the mmu and tlb operations (especially on MP systems)
is such that a dma to kernel memory followed by copyout/copytouser
may well be faster!
That may even be the case even if the dma is writing to the
user virtual (or physical) addresses when it is only
necessary to ensure the memory page is resident and that
the caches are coherent.
In any case the second copy is probably far faster than the
PCI one!
I've recently written driver that supports a pread/pwrite interface
to the memory windows on a PCIe card. It was important to use
dma for the PCIe transfers (to get a sensible transfer size).
I overlapped the copyin/copyout with the next dma transfer.
The dma's are fast enough that it is worth spinning waiting
for completion - but slow enough to make the overlapped
operation worthwhile (same speed as a single word pio transfer).
David
^ permalink raw reply
* Re: [PATCH] oprofile, powerpc: Handle events that raise an exception without overflowing
From: Robert Richter @ 2011-05-24 9:27 UTC (permalink / raw)
To: Eric B Munson
Cc: oprofile-list@lists.sf.net, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1306160560-5309-1-git-send-email-emunson@mgebm.net>
On 23.05.11 10:22:40, Eric B Munson wrote:
> Commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 fixes a situation on POWER7
> where events can roll back if a specualtive event doesn't actually complete.
> This can raise a performance monitor exception. We need to catch this to ensure
> that we reset the PMC. In all cases the PMC will be less than 256 cycles from
> overflow.
>
> This patch lifts Anton's fix for the problem in perf and applies it to oprofile
> as well.
>
> Signed-off-by: Eric B Munson <emunson@mgebm.net>
> Cc: <stable@kernel.org> # as far back as it applies cleanly
> ---
> arch/powerpc/oprofile/op_model_power4.c | 24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
I applied the fix to oprofile/urgent.
Thanks Eric,
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* Re: PCI DMA to user mem on mpc83xx
From: Andre Schwarz @ 2011-05-24 9:47 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: LinuxPPC List
In-Reply-To: <20110523172727.GA21717@ovro.caltech.edu>
Ira,
> On Mon, May 23, 2011 at 11:12:41AM +0200, Andre Schwarz wrote:
>> Ira,
>>
>> we have a pretty old PCI device driver here that needs some basic rework
>> running on 2.6.27 on several MPC83xx.
>> It's a simple char-device with "give me some data" implemented using
>> read() resulting in zero-copy DMA to user mem.
>>
>> There's get_user_pages() working under the hood along with
>> SetPageDirty() and page_cache_release().
>>
>> Main goal is to prepare a sg-list that gets fed into a DMA controller.
>>
>> I wonder if there's a more up-to-date/efficient and future proof scheme
>> of creating the mapping.
>>
>>
>> Could you provide some pointers or would you stick to the current scheme ?
>>
> This scheme is the best you'll come up with for zero-copy IO. I used
> get_user_pages_fast(), but otherwise my implementation was the same.
> These interfaces should be fairly future proof.
excellent - thanks.
Will stick to it then ...
> In the end, I realized that most of my transfers were 4 bytes in length,
> and zero copy IO was a waste of effort. I decided to use mmap instead.
>
I'm using 98% page sized (4KiB) scatter gather transfers summing up to
~80MiB/sec sustained throughput.
Cheers,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* Re: PCI DMA to user mem on mpc83xx
From: Andre Schwarz @ 2011-05-24 10:02 UTC (permalink / raw)
To: David Laight; +Cc: LinuxPPC List, Ira W. Snyder
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AD4B@saturn3.aculab.com>
David,
>> we have a pretty old PCI device driver here that needs some
>> basic rework running on 2.6.27 on several MPC83xx.
>> It's a simple char-device with "give me some data" implemented
>> using read() resulting in zero-copy DMA to user mem.
>>
>> There's get_user_pages() working under the hood along with
>> SetPageDirty() and page_cache_release().
> Does that dma use the userspace virtual address, or the
> physical address - or are you remapping the user memory into
> kernel address space.
no mapping at all AFAIK.
I'm using get_user_pages() followed by allocation of a struct
scatterlist being filled with sg_set_page().
After the transfer the pages are marked dirty using SetPageDirty().
> If the memory is remapped into the kernel address space, the
> cost of the mmu and tlb operations (especially on MP systems)
> is such that a dma to kernel memory followed by copyout/copytouser
> may well be faster!
no mapping.
> That may even be the case even if the dma is writing to the
> user virtual (or physical) addresses when it is only
> necessary to ensure the memory page is resident and that
> the caches are coherent.
All I need is physical addresses of user mem.
Since the allocating user driver is using mlock() and there's no swap I
expect to be safe ... is this a stupid assumption ?
> In any case the second copy is probably far faster than the
> PCI one!
huh - I observed memcpy() to be very expensive (at least on 83xx PowerPC).
> I've recently written driver that supports a pread/pwrite interface
> to the memory windows on a PCIe card. It was important to use
> dma for the PCIe transfers (to get a sensible transfer size).
> I overlapped the copyin/copyout with the next dma transfer.
> The dma's are fast enough that it is worth spinning waiting
> for completion - but slow enough to make the overlapped
> operation worthwhile (same speed as a single word pio transfer).
Thanks for your feedback.
Cheers,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* [PATCH 1/1] powerpc: Update MAX_HCALL_OPCODE to reflect page coalescing
From: Brian King @ 2011-05-24 13:40 UTC (permalink / raw)
To: benh; +Cc: brking, linuxppc-dev
When page coalescing support was added recently, the MAX_HCALL_OPCODE
define was not updated for the newly added H_GET_MPP_X hcall.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/powerpc/include/asm/hvcall.h~powerpc_max_hcall_opcode arch/powerpc/include/asm/hvcall.h
--- linux-2.6/arch/powerpc/include/asm/hvcall.h~powerpc_max_hcall_opcode 2011-05-20 09:33:45.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/include/asm/hvcall.h 2011-05-20 09:33:58.000000000 -0500
@@ -236,7 +236,7 @@
#define H_HOME_NODE_ASSOCIATIVITY 0x2EC
#define H_BEST_ENERGY 0x2F4
#define H_GET_MPP_X 0x314
-#define MAX_HCALL_OPCODE H_BEST_ENERGY
+#define MAX_HCALL_OPCODE H_GET_MPP_X
#ifndef __ASSEMBLY__
_
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Will Drewry @ 2011-05-24 15:59 UTC (permalink / raw)
To: Steven Rostedt, Ingo Molnar, Peter Zijlstra, Frederic Weisbecker
Cc: linux-mips, linux-sh, Heiko Carstens, Oleg Nesterov,
David Howells, Paul Mackerras, Ralf Baechle, H. Peter Anvin,
sparclinux, Jiri Slaby, linux-s390, Russell King, x86,
James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Tejun Heo, Thomas Gleixner, linux-arm-kernel,
Michal Marek, Michal Simek, linuxppc-dev, linux-kernel,
Eric Paris, Paul Mundt, Martin Schwidefsky, linux390,
Andrew Morton, agl, David S. Miller
In-Reply-To: <BANLkTiki8aQJbFkKOFC+s6xAEiuVyMM5MQ@mail.gmail.com>
On Thu, May 19, 2011 at 4:05 PM, Will Drewry <wad@chromium.org> wrote:
> On Thu, May 19, 2011 at 7:22 AM, Steven Rostedt <rostedt@goodmis.org> wro=
te:
>> On Wed, 2011-05-18 at 21:07 -0700, Will Drewry wrote:
>>
>>> Do event_* that return non-void exist in the tree at all now? =A0I've
>>> looked at the various tracepoint macros as well as some of the other
>>> handlers (trace_function, perf_tp_event, etc) and I'm not seeing any
>>> places where a return value is honored nor could be. =A0At best, the
>>> perf_tp_event can be short-circuited it in the hlist_for_each, but
>>> it'd still need a way to bubble up a failure and result in not calling
>>> the trace/event that the hook precedes.
>>
>> No, none of the current trace hooks have return values. That was what I
>> was talking about how to implement in my previous emails.
>
> Led on by complete ignorance, I think I'm finally beginning to untwist
> the different pieces of the tracing infrastructure. =A0Unfortunately,
> that means I took a few wrong turns along the way...
>
> I think function tracing looks something like this:
>
> ftrace_call has been injected into at a specific callsite. =A0Upon hit:
> 1. ftrace_call triggers
> 2. does some checks then calls ftrace_trace_function (via mcount instrs)
> 3. ftrace_trace_function may be a single func or a list. For a list it
> will be: ftrace_list_func
> 4. ftrace_list_func calls each registered hook for that function in a
> while loop ignoring return values
> 5. registered hook funcs may then track the call, farm it out to
> specific sub-handlers, etc.
>
> This seems to be a red herring for my use case :/ though this helped
> me understand your back and forth (Ingo & Steve) regarding dynamic
> versus explicit events.
>
>
> System call tracing is done via kernel/tracepoint.c events fed in via
> arch/[arch]/kernel/ptrace.c where it calls trace_sys_enter. =A0This
> yields direct sys_enter and sys_exit event sources (and an event class
> to hook up per-system call events). =A0This means that
> ftrace_syscall_enter() does the event prep prior to doing a filter
> check comparing the ftrace_event object for the given syscall_nr to
> the event data. =A0perf_sysenter_enter() is similar but it pushes the
> info over to perf_tp_event to be matched not against the global
> syscall event entry, but against any sub-event in the linked list on
> that syscall's event.
>
> Is that roughly an accurate representation of the two? =A0I wish I
> hadn't gotten distracted along the function path, but at least I
> learned something (and it is relevant to the larger scope of this
> thread's discussion).
>
>
> After doing that digging, it looks like providing hook call
> pre-emption and return value propagation will be a unique and fun task
> for each tracer and event subsystem. =A0If I look solely at tracepoints,
> a generic change would be to make the trace_##subsys function return
> an int (which I think was the event_vfs_getname proposal?). =A0The other
> option is to change the trace_sys_enter proto to include a 'int
> *retcode'.
>
> That change would allow the propagation of some sort of policy
> information. =A0To put it to use, seccomp mode 1 could be implemented on
> top of trace_syscalls. =A0The following changes would need to happen:
> 1. dummy metadata should be inserted for all unhooked system calls
> 2. perf_trace_buf_submit would need to return an int or a new
> TRACE_REG_SECCOMP_REGISTER handler would need to be setup in
> syscall_enter_register.
> 3. If perf is abused, a "kill/fail_on_discard" bit would be added to
> event->attrs.
> 4. perf_trace_buf_submit/perf_tp_event will return 0 for no matches,
> 'n' for the number of event matches, and -EACCES/? if a
> 'fail_on_discard' event is seen.
> 5. perf_syscall_enter would set *retcode =3D perf_trace_buf_submit()'s re=
tcode
> 6. trace_sys_enter() would need to be moved to be the first entry
> arch/../kernel/ptrace.c for incoming syscalls
> 7. if trace_sys_enter() yields a negative return code, then
> do_exit(SIGKILL) the process and return.
>
> Entering into seccomp mode 1 would require adding a =A0"0" filter for
> every system call number (which is why we need a dummy event call for
> them since failing to check the bitmask can't be flagged
> fail_on_discard) with the fail_on_discard bit. =A0For the three calls
> that are allowed, a '1' filter would be set.
>
> That would roughly implement seccomp mode 1. =A0It's pretty ugly and the
> fact that every system call that's disallowed has to be blacklisted is
> not ideal. =A0An alternate model would be to just use the seccomp mode
> as we do today and let secure_computing() handle the return code of "#
> of matches". =A0If it the # of matches is 0, it terminates. A
> 'fail_on_discard' bit then would only be good to stop further
> tracepoint callback evaluation. =A0This approach would also *almost* nix
> the need to provide dummy syscall hooks. =A0(Since sigreturn isn't
> hooked on x86 because it uses ptregs fixup, a dummy would still be
> needed to apply a "1" filter to.)
>
> Even with that tweak to move to a whitelist model, the perf event
> evaluation and tracepoint callback ordering is still not guaranteed.
> Without changing tracepoint itself, all other TPs will still execute.
> And for perf events, it'll be first-come-first-serve until a
> fail_on_discard is hit.
>
> After using seccomp mode=3D1 as the sample case to reduce scope, it's
> possible to ignore it for now :) and look at the seccomp-filter/mode=3D2
> case. =A0The same mechanism could be used to inject more expressive
> filters. =A0This would be done over the sys_perf_event_open() interface
> assuming the new attr is added to stop perf event list enumeration.
> Assuming a whitelist model, a call to prctl(PR_SET_SECCOMP, 2) would
> be needed (maybe with the ON_EXEC flag option too to mirror the
> event->attr on-exec bit). That would yield the ability to register
> perf events for system calls then use ioctl() to SET_FILTER on them.
>
> Reducing the privileges of the filters after installation could be
> done with another attribute bit like 'set_filter_ands'. =A0If that is
> also set on the event, and a filter is installed to ensure that
> sys_perf_event_open is blocked, then it should be reasonably sane.
>
> I'd need to add a PERF_EVENT_IOC_GET_FILTER handler to allow
> extracting the settings.
>
> Clearly, I haven't written the code for that yet, though making the
> change for a single platform shouldn't be too much code.
>
> So that leaves me with some questions:
> - Is this the type of reuse that was being encouraged?
> - Does it really make sense to cram this through the perf interface
> and events? =A0While the changed attributes are innocuous and
> potentially reusable, it seems that a large amount of the perf
> facilities are exposed that could have weird side effects, but I'm
> sure I still don't fully grok the perf infrastructure.
> - Does extending one tracepoint to provide return values via a pointer
> make sense? I'd hesitate to make all tracepoint hooks return an int by
> default.
> - If all tracepoints returned an int, what would the standard value
> look like - or would it need to be per tracepoint impl?
> - How is ambiguity resolved if multiple perf_events are registered for
> a syscall with different filters? =A0Maybe a 'stop_on_match'? though
> ordering is still a problem then.
> - Is there a way to affect a task-wide change without a seccomp flag
> (or new task_struct entry) via the existing sys_perf_event_open
> syscall? =A0I considered suggesting a attr bit call 'secure_computing'
> that when an event with the bit is enabled, it automagically forces
> the task into seccomp enforcement mode, but that, again, seemed
> hackish.
>
> While I like the idea of sharing the tracepoints infrastructure and
> the trace_syscalls hooks as well as using a pre-existing interface
> with very minor changes, I'm worried that the complexity of the
> interface and of the infrastructure might undermine the ability to
> continue meeting the desired security goals. =A0I had originally stayed
> very close to the seccomp world because of how trivial it is to review
> the code and verify its accuracy/effectiveness. =A0This approach leaves
> a lot of gaps for kernel code to seep through and a fair amount of
> ambiguity in what locked down syscall filters might look like.
>
> To me, the best part of the above is that it shows that even if we go
> with a prctl SET_SECCOMP_FILTER-style interface, it is completely
> certain that if a perf/ftrace-based security infrastructure is on our
> future, it will be entirely compatible -- even if the prctl()
> interface is just the "simpler" interface at that point somewhere down
> the road.
>
>
> Regardless, I'll hack up a proof of concept based on the outline
> above. Perhaps something more elegant will emerge once I start
> tweaking the source, but I'm still seeing too many gaps to be
> comfortable so far.
>
>
> [[There is a whole other approach to this too. We could continue with
> the prctl() interface and mirror the trace_sys_enter model for
> secure_computing(). =A0 Instead of keeping a seccomp_t-based hlist of
> events, they could be stored in a new hlist for seccomp_events in
> struct ftrace_event_call. =A0The ftrace filters would be installed there
> and the seccomp_syscall_enter() function could do the checks and pass
> up some state data on the task's seccomp_t that indicates it needs to
> do_exit(). =A0That would likely reduce the amount of code in
> seccomp_filter.c pretty seriously (though not entirely
> beneficially).]]
>
>
> Thanks again for all the feedback and insights! I really hope we can
> come to an agreeable approach for implementing kernel attack surface
> reduction.
Just a quick follow up. I have a PoC of the perf-based system call
filtering code in place which uses seccomp.mode as a task_context
flag, adds require_secure and err_on_discard perf_event_attrs, and
enforces these new events terminate the process in perf_syscall_enter
via a return value on perf_buf_submit. This lets a call like:
LD_LIBRARY_PATH=3D/host/home/wad/kernel.uml/tests/
/host/home/wad/kernel.uml/tests/perf record \
-S \
-e 'syscalls:sys_enter_access' \
-e 'syscalls:sys_enter_brk' \
-e 'syscalls:sys_enter_close' \
-e 'syscalls:sys_enter_exit_group' \
-e 'syscalls:sys_enter_fcntl64' \
-e 'syscalls:sys_enter_fstat64' \
-e 'syscalls:sys_enter_getdents64' \
-e 'syscalls:sys_enter_getpid' \
-e 'syscalls:sys_enter_getuid' \
-e 'syscalls:sys_enter_ioctl' \
-e 'syscalls:sys_enter_lstat64' \
-e 'syscalls:sys_enter_mmap_pgoff' \
-e 'syscalls:sys_enter_mprotect' \
-e 'syscalls:sys_enter_munmap' \
-e 'syscalls:sys_enter_open' \
-e 'syscalls:sys_enter_read' \
-e 'syscalls:sys_enter_stat64' \
-e 'syscalls:sys_enter_time' \
-e 'syscalls:sys_enter_newuname' \
-e 'syscalls:sys_enter_write' --filter "fd =3D=3D 1" \
/bin/ls
run successfully while omitting a syscall or passing in --filter "fd
=3D=3D 0" properly terminates it. (ignoring the need for execve and
set_thread_area for PoC purposes).
The change avoids defining a new trace call type or a huge number of
internal changes and hides seccomp.mode=3D2 from ABI-exposure in prctl,
but the attack surface is non-trivial to verify, and I'm not sure if
this ABI change makes sense. It amounts to:
include/linux/ftrace_event.h | 4 +-
include/linux/perf_event.h | 10 +++++---
kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++++=
---
kernel/seccomp.c | 8 ++++++
kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
5 files changed, 82 insertions(+), 16 deletions(-)
And can be found here: http://static.dataspill.org/perf_secure/v1/
If there is any interest at all, I can post it properly to this giant
CC list. However, it's unclear to me where this thread stands. I
also see a completely independent path for implementing system call
filtering now, but I'll hold off posting that patch until I see where
this goes.
Any guidance will be appreciated - thanks again!
will
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-24 16:20 UTC (permalink / raw)
To: Will Drewry
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, Ingo Molnar,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
kees.cook, linux-arm-kernel, Michal Marek, Michal Simek,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <BANLkTim9UyYAGhg06vCFLxkYPX18cPymEQ@mail.gmail.com>
On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
> include/linux/ftrace_event.h | 4 +-
> include/linux/perf_event.h | 10 +++++---
> kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++=
++---
> kernel/seccomp.c | 8 ++++++
> kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
> 5 files changed, 82 insertions(+), 16 deletions(-)=20
I strongly oppose to the perf core being mixed with any sekurity voodoo
(or any other active role for that matter).
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Thomas Gleixner @ 2011-05-24 16:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, Ingo Molnar,
Serge E. Hallyn, Steven Rostedt, Martin Schwidefsky, kees.cook,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1306254027.18455.47.camel@twins>
On Tue, 24 May 2011, Peter Zijlstra wrote:
> On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
> > include/linux/ftrace_event.h | 4 +-
> > include/linux/perf_event.h | 10 +++++---
> > kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++++---
> > kernel/seccomp.c | 8 ++++++
> > kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
> > 5 files changed, 82 insertions(+), 16 deletions(-)
>
> I strongly oppose to the perf core being mixed with any sekurity voodoo
> (or any other active role for that matter).
Amen. We have enough crap to cleanup in perf/ftrace already, so we
really do not need security magic added to it.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Will Drewry @ 2011-05-24 19:00 UTC (permalink / raw)
To: Thomas Gleixner, Peter Zijlstra, Steven Rostedt, Ingo Molnar,
Frederic Weisbecker
Cc: linux-mips, linux-sh, Heiko Carstens, Oleg Nesterov,
David Howells, Paul Mackerras, Ralf Baechle, H. Peter Anvin,
sparclinux, Jiri Slaby, linux-s390, Russell King, x86,
James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Tejun Heo, linux-arm-kernel, Michal Marek,
Michal Simek, linuxppc-dev, linux-kernel, Eric Paris, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <alpine.LFD.2.02.1105241823540.3078@ionos>
On Tue, May 24, 2011 at 11:25 AM, Thomas Gleixner <tglx@linutronix.de> wrot=
e:
> On Tue, 24 May 2011, Peter Zijlstra wrote:
>
>> On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
>> > =A0include/linux/ftrace_event.h =A0| =A0 =A04 +-
>> > =A0include/linux/perf_event.h =A0 =A0| =A0 10 +++++---
>> > =A0kernel/perf_event.c =A0 =A0 =A0 =A0 =A0 | =A0 49 ++++++++++++++++++=
+++++++++++++++++++---
>> > =A0kernel/seccomp.c =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A08 ++++++
>> > =A0kernel/trace/trace_syscalls.c | =A0 27 +++++++++++++++++-----
>> > =A05 files changed, 82 insertions(+), 16 deletions(-)
>>
>> I strongly oppose to the perf core being mixed with any sekurity voodoo
>> (or any other active role for that matter).
>
> Amen. We have enough crap to cleanup in perf/ftrace already, so we
> really do not need security magic added to it.
Thanks for the quick responses!
I agree, but I'm left a little bit lost now w.r.t. the comments around
reusing the ABI. If perf doesn't make sense (which certainly seems
wrong from a security interface perspective), then the preexisting
ABIs I know of for this case are as follows:
- /sys/kernel/debug/tracing/*
- prctl(PR_SET_SECCOMP* (or /proc/...)
Both would require expansion. The latter was reused by the original
patch series. The former doesn't expose much in the way of per-task
event filtering -- ftrace_pids doesn't translate well to
ftrace_syscall_enter-based enforcement. I'd expect we'd need
ftrace_event_call->task_events (like ->perf_events), and either
explore them in ftrace_syscall_enter or add a new tracepoint handler,
ftrace_task_syscall_enter, via something like TRACE_REG_TASK_REGISTER.
It could then do whatever it wanted with the successful or
unsuccessful matching against predicates, stacking or not, which could
be used for a seccomp-like mechanism. However, bubbling that change
up to the non-existent interfaces in debug/tracing could be a
challenge too (Registration would require an alternate flow like perf
to call TRACE_REG_*? Do they become
tracing/events/subsystem/event/task/<tid>/<filter_string_N>? ...?).
This is all just a matter of programming... but at this point, I'm not
seeing the clear shared path forward. Even with per-task ftrace
access in debug/tracing, that would introduce a reasonably large
change to the system and add a new ABI, albeit in debug/tracing. If
the above (or whatever the right approach is) comes into existence,
then any prctl(PR_SET_SECCOMP) ABI could have the backend
implementation to modify the same data. I'm not putting it like this
to say that I'm designing to be obsolete, but to show that the defined
interface wouldn't conflict if ftrace does overlap more in the future.
Given the importance of a clearly defined interface for security
functionality, I'd be surprised to see all the pieces come together in
the near future in such a way that a transition would be immediately
possible -- I'm not even sure what the ftrace roadmap really is!
Would it be more desirable to put a system call filtering interface on
a miscdev (like /dev/syscall_filter) instead of in /proc or prctl (and
not reuse seccomp at all)? I'm not clear what the onus is to justify
a change in the different ABI areas, but I see system call filtering
as an important piece of system security and would like to determine
if there is a viable path forward, or if this will need to be
revisited in another 2 years.
thanks again!
will
^ permalink raw reply
* Re: [PATCH v2 2/7] mmc: sdhci: eliminate sdhci_of_host and sdhci_of_data
From: Wolfram Sang @ 2011-05-24 19:26 UTC (permalink / raw)
To: Shawn Guo
Cc: Chris Ball, sameo, Arnd Bergmann, patches, devicetree-discuss,
linux-mmc, Saeed Bishara, Xiaobo Xie, kernel, Mike Rapoport,
Olof Johansson, Anton Vorontsov, linuxppc-dev, Albert Herranz,
linux-arm-kernel
In-Reply-To: <1304601778-13837-3-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
On Thu, May 05, 2011 at 09:22:53PM +0800, Shawn Guo wrote:
> The patch migrates the use of sdhci_of_host and sdhci_of_data to
> sdhci_pltfm_host and sdhci_pltfm_data, so that the former pair can
> be eliminated.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
We might be able to get rid of the migrated entries in sdhci-pltfm.h, but this
is a task for later IMO.
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/7] mmc: sdhci: make sdhci-of device drivers self registered
From: Wolfram Sang @ 2011-05-24 19:32 UTC (permalink / raw)
To: Shawn Guo
Cc: Chris Ball, sameo, Arnd Bergmann, patches, devicetree-discuss,
linux-mmc, Saeed Bishara, Xiaobo Xie, kernel, Mike Rapoport,
Olof Johansson, Anton Vorontsov, linuxppc-dev, Albert Herranz,
linux-arm-kernel
In-Reply-To: <1304601778-13837-4-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]
On Thu, May 05, 2011 at 09:22:54PM +0800, Shawn Guo wrote:
> The patch turns the sdhci-of-core common stuff into helper functions
> added into sdhci-pltfm.c, and makes sdhci-of device drviers self
> registered using the same pair of .probe and .remove used by
> sdhci-pltfm device drivers.
>
> As a result, sdhci-of-core.c and sdhci-of.h can be eliminated with
> those common things merged into sdhci-pltfm.c and sdhci-pltfm.h
> respectively.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
After taking care of Anton's comment and fixing this minor thingie...
> +#ifdef CONFIG_OF
> +static bool sdhci_of_wp_inverted(struct device_node *np)
> +{
> + if (of_get_property(np, "sdhci,wp-inverted", NULL))
> + return true;
> +
> + /* Old device trees don't have the wp-inverted property. */
> +#ifdef CONFIG_PPC
> + return machine_is(mpc837x_rdb) || machine_is(mpc837x_mds);
> +#else
> + return false;
> +#endif
/* CONFIG_PPC */ after #endif
> +}
> +
> +void sdhci_get_of_property(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + const __be32 *clk;
> + int size;
> +
> + if (of_device_is_available(np)) {
> + if (of_get_property(np, "sdhci,auto-cmd12", NULL))
> + host->quirks |= SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12;
> +
> + if (of_get_property(np, "sdhci,1-bit-only", NULL))
> + host->quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
> +
> + if (sdhci_of_wp_inverted(np))
> + host->quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
> +
> + clk = of_get_property(np, "clock-frequency", &size);
> + if (clk && size == sizeof(*clk) && *clk)
> + pltfm_host->clock = be32_to_cpup(clk);
> + }
> +}
> +#else
> +void sdhci_get_of_property(struct platform_device *pdev) {}
> +#endif
/* CONFIG_OF */
you can add
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] mmc: sdhci: consolidate sdhci-of-esdhc and sdhci-esdhc-imx
From: Wolfram Sang @ 2011-05-24 19:40 UTC (permalink / raw)
To: Shawn Guo
Cc: Chris Ball, sameo, Arnd Bergmann, patches, devicetree-discuss,
linux-mmc, Saeed Bishara, Xiaobo Xie, kernel, Mike Rapoport,
Olof Johansson, Anton Vorontsov, linuxppc-dev, Albert Herranz,
linux-arm-kernel
In-Reply-To: <1304601778-13837-6-git-send-email-shawn.guo@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]
On Thu, May 05, 2011 at 09:22:56PM +0800, Shawn Guo wrote:
> This patch is to consolidate SDHCI driver for Freescale eSDHC
> controller found on both MPCxxx and i.MX platforms. It merges
> sdhci-of-esdhc.c into sdhci-esdhc.c, so that the same pair of
> .probe/.remove hook works with eSDHC for two platforms.
>
> As the results, sdhci-of-esdhc.c and sdhci-esdhc.h are removed, and
> header esdhc.h containing the definition of esdhc_platform_data is
> put into the public folder.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
I agree with Anton about not merging the two...
> +#ifndef CONFIG_MMC_SDHCI_ESDHC_IMX
> +#define cpu_is_mx25() (0)
> +#define cpu_is_mx35() (0)
> +#define cpu_is_mx51() (0)
> +#define cpu_is_imx() (0)
> +#else
> +#define cpu_is_imx() (1)
> +#endif
... e.g. that looks a bit frightening.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-24 19:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <1306254027.18455.47.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
> > include/linux/ftrace_event.h | 4 +-
> > include/linux/perf_event.h | 10 +++++---
> > kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++++---
> > kernel/seccomp.c | 8 ++++++
> > kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
> > 5 files changed, 82 insertions(+), 16 deletions(-)
>
> I strongly oppose to the perf core being mixed with any sekurity voodoo
> (or any other active role for that matter).
I'd object to invisible side-effects as well, and vehemently so. But note how
intelligently it's used here: it's explicit in the code, it's used explicitly
in kernel/seccomp.c and the event generation place in
kernel/trace/trace_syscalls.c.
So this is a really flexible solution IMO and does not extend events with some
invisible 'active' role. It extends the *call site* with an open-coded active
role - which active role btw. already pre-existed.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-24 20:08 UTC (permalink / raw)
To: Will Drewry
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, James Morris, Linus Torvalds, Ingo Molnar,
kees.cook, Serge E. Hallyn, Steven Rostedt, Tejun Heo,
Thomas Gleixner, linux-arm-kernel, Michal Marek, Michal Simek,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <BANLkTim9UyYAGhg06vCFLxkYPX18cPymEQ@mail.gmail.com>
* Will Drewry <wad@chromium.org> wrote:
> The change avoids defining a new trace call type or a huge number of internal
> changes and hides seccomp.mode=2 from ABI-exposure in prctl, but the attack
> surface is non-trivial to verify, and I'm not sure if this ABI change makes
> sense. It amounts to:
>
> include/linux/ftrace_event.h | 4 +-
> include/linux/perf_event.h | 10 +++++---
> kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++++---
> kernel/seccomp.c | 8 ++++++
> kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
> 5 files changed, 82 insertions(+), 16 deletions(-)
>
> And can be found here: http://static.dataspill.org/perf_secure/v1/
Wow, i'm very impressed how few changes you needed to do to support this!
So, firstly, i don't think we should change perf_tp_event() at all - the
'observer' codepaths should be unaffected.
But there could be a perf_tp_event_ret() or perf_tp_event_check() entry that
code like seccomp which wants to use event results can use.
Also, i'm not sure about the seccomp details and assumptions that were moved
into the perf core. How about passing in a helper function to
perf_tp_event_check(), where seccomp would define its seccomp specific helper
function?
That looks sufficiently flexible. That helper function could be an 'extra
filter' kind of thing, right?
Also, regarding the ABI and the attr.err_on_discard and attr.require_secure
bits, they look a bit too specific as well.
attr.err_on_discard: with the filter helper function passed in this is probably
not needed anymore, right?
attr.require_secure: this is basically used to *force* the creation of
security-controlling filters, right? It seems to me that this could be done via
a seccomp ABI extension as well, without adding this to the perf ABI. That
seccomp call could check whether the right events are created and move the task
to mode 2 only if that prereq is met - or something like that.
> If there is any interest at all, I can post it properly to this giant
> CC list. [...]
I'd suggest to trim the Cc: list aggressively - anyone interested in the
discussion can pick it up on lkml - and i strongly suspect that most of the Cc:
participants would want to be off the Cc: :-)
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-24 20:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, kees.cook,
Serge E. Hallyn, Steven Rostedt, Tejun Heo, Thomas Gleixner,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110524195435.GC27634@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
> > > include/linux/ftrace_event.h | 4 +-
> > > include/linux/perf_event.h | 10 +++++---
> > > kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++++---
> > > kernel/seccomp.c | 8 ++++++
> > > kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
> > > 5 files changed, 82 insertions(+), 16 deletions(-)
> >
> > I strongly oppose to the perf core being mixed with any sekurity voodoo
> > (or any other active role for that matter).
>
> I'd object to invisible side-effects as well, and vehemently so. But note how
> intelligently it's used here: it's explicit in the code, it's used explicitly
> in kernel/seccomp.c and the event generation place in
> kernel/trace/trace_syscalls.c.
>
> So this is a really flexible solution IMO and does not extend events with
> some invisible 'active' role. It extends the *call site* with an open-coded
> active role - which active role btw. already pre-existed.
Also see my other mail - i think this seccomp code is too tied in to the perf
core and ABI - but this is fixable IMO.
The fundamental notion that a generator subsystem of events can use filter
results as well (such as kernel/trace/trace_syscalls.c.) for its own purposes
is pretty robust though.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Steven Rostedt @ 2011-05-24 20:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Ralf Baechle, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, James Morris, Linus Torvalds, Ingo Molnar,
kees.cook, Serge E. Hallyn, Tejun Heo, Thomas Gleixner,
linux-arm-kernel, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Eric Paris, Paul Mundt,
Martin Schwidefsky, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110524200815.GD27634@elte.hu>
On Tue, 2011-05-24 at 22:08 +0200, Ingo Molnar wrote:
> * Will Drewry <wad@chromium.org> wrote:
> But there could be a perf_tp_event_ret() or perf_tp_event_check() entry that
> code like seccomp which wants to use event results can use.
We should name it something else. The "perf_tp.." is a misnomer as it
has nothing to do with performance monitoring. "dynamic_event_.." maybe,
as it is dynamic to the affect that we can use jump labels to enable or
disable it.
-- Steve
^ permalink raw reply
* Re: Kernel cannot see PCI device
From: Benjamin Herrenschmidt @ 2011-05-24 21:43 UTC (permalink / raw)
To: Prashant Bhole
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Stefan Roese,
linuxppc-dev, Tirumala Marri
In-Reply-To: <BANLkTi=J5EFvs3nHDQXNQfyd0EejWJvzcQ@mail.gmail.com>
On Tue, 2011-05-24 at 10:25 +0530, Prashant Bhole wrote:
> Fixed the problem by soft resetting the PCIe port in the function
> ppc460ex_pciex_port_init_hw().
> Is it a right thing to do?
> Following is the patch for kernel 2.6.38.4:
> --------------------------------------------------------------------------------------
> --- linux-2.6.38.4/arch/powerpc/sysdev/ppc4xx_pci.c.orig 2011-05-24
> 10:02:38.000000000 +0530
> +++ linux-2.6.38.4/arch/powerpc/sysdev/ppc4xx_pci.c 2011-05-24
> 10:07:17.000000000 +0530
> @@ -876,6 +876,20 @@
> u32 val;
> u32 utlset1;
>
> + switch (port->index)
> + {
> + case 0:
> + mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST, 0x0);
> + mdelay(10);
> + break;
> + case 1:
> + mtdcri(SDR0, PESDR1_460EX_PHY_CTL_RST, 0x0);
> + mdelay(10);
> + break;
> + default:
> + break;
> + }
> +
> if (port->endpoint)
> val = PTYPE_LEGACY_ENDPOINT << 20;
> else
> --------------------------------------------------------------------------------------
Well, it's odd that you'd have to do that, maybe something the
bootloader is doing ?
I personally don't mind but I'd like Stefan and/or Tirumala opinion on
this.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2] hw_breakpoint: Let the user choose not to build it (and perf too)
From: Frederic Weisbecker @ 2011-05-24 21:52 UTC (permalink / raw)
To: LKML
Cc: linuxppc-dev, Peter Zijlstra, Frederic Weisbecker,
H . Peter Anvin, Will Deacon, LKML, Paul Mundt, Jason Wessel,
Ingo Molnar, Prasad, Thomas Gleixner
Mostly just a rebase against latest upstream
updates and acks from Will Deacon added In this second version.
Please tell me if you are ok with this set.
Thanks.
---
Frederic Weisbecker (6):
hw_breakpoints: Split hardware breakpoints config
hw_breakpoints: Migrate breakpoint conditional build under new config
x86: Allow the user not to build hw_breakpoints
hw_breakpoints: Breakpoints arch ability don't need perf events
hw_breakpoints: Only force perf events if breakpoints are selected
hw_breakpoints: Drop remaining misplaced dependency on perf
arch/Kconfig | 1 -
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/hw_breakpoint.h | 4 +-
arch/arm/include/asm/processor.h | 2 +-
arch/arm/kernel/Makefile | 2 +-
arch/arm/kernel/entry-header.S | 2 +-
arch/arm/kernel/ptrace.c | 4 +-
arch/powerpc/Kconfig | 2 +-
arch/powerpc/include/asm/cputable.h | 4 +-
arch/powerpc/include/asm/hw_breakpoint.h | 6 ++--
arch/powerpc/include/asm/processor.h | 4 +-
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/process.c | 18 ++++++++--------
arch/powerpc/kernel/ptrace.c | 13 ++++++-----
arch/powerpc/lib/Makefile | 2 +-
arch/sh/Kconfig | 2 +-
arch/sh/kernel/Makefile | 2 +-
arch/sh/kernel/cpu/sh4a/Makefile | 2 +-
arch/x86/Kconfig | 3 +-
arch/x86/include/asm/debugreg.h | 33 ++++++++++++++++++++++++++++-
arch/x86/kernel/Makefile | 3 +-
arch/x86/kernel/process.c | 1 +
arch/x86/kernel/ptrace.c | 17 +++++++++++++++
include/linux/hw_breakpoint.h | 6 ++--
include/linux/perf_event.h | 4 +-
include/linux/ptrace.h | 6 ++--
include/linux/sched.h | 2 +-
init/Kconfig | 11 ++++++++++
kernel/events/Makefile | 2 +-
kernel/events/core.c | 4 +-
kernel/ptrace.c | 4 +-
samples/Kconfig | 2 +-
32 files changed, 115 insertions(+), 57 deletions(-)
^ permalink raw reply
* [PATCH 1/6] hw_breakpoints: Split hardware breakpoints config
From: Frederic Weisbecker @ 2011-05-24 21:52 UTC (permalink / raw)
To: LKML
Cc: Peter Zijlstra, Frederic Weisbecker, Will Deacon, LKML,
Paul Mundt, Prasad, Ingo Molnar, linuxppc-dev
In-Reply-To: <1306273947-8410-1-git-send-email-fweisbec@gmail.com>
The hardware breakpoint config is only made of an ability. An
arch that support this feature selects HAVE_HW_BREAKPOINT. If so,
the feature is definetly built-in, the user can't decide to turn
it off. As hw_breakpoints depend on perf, it also makes perf
a mandatory feature. The whole is quite a piece of code and
may not be desired on some embedded systems.
In order to prepare to make this optable by the user, split the
config into the more traditional couple (ability, user choice) by
providing a new HW_BREAKPOINT config. It is default on and depends
on CONFIG_EXPERT because breakpoint ptrace requests are part of the
usual user ABI. The user must know what he's doing before turning
that off.
For now, only the archs that already implemented a conditional
HAVE_HW_BREAKPOINT can turn off HW_BREAKPOINT. x86 and sh have it
always selected because they need more background work to support
this new modularity.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
---
arch/sh/Kconfig | 1 +
arch/x86/Kconfig | 1 +
init/Kconfig | 10 ++++++++++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 4b89da2..0d4d124 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -44,6 +44,7 @@ config SUPERH32
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_ARCH_KGDB
select HAVE_HW_BREAKPOINT
+ select HW_BREAKPOINT
select HAVE_MIXED_BREAKPOINTS_REGS
select PERF_EVENTS
select ARCH_HIBERNATION_POSSIBLE if MMU
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc6c53a..8b49bff 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -54,6 +54,7 @@ config X86
select HAVE_KERNEL_XZ
select HAVE_KERNEL_LZO
select HAVE_HW_BREAKPOINT
+ select HW_BREAKPOINT
select HAVE_MIXED_BREAKPOINTS_REGS
select PERF_EVENTS
select HAVE_PERF_EVENTS_NMI
diff --git a/init/Kconfig b/init/Kconfig
index d886b1e..76ae53e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -924,6 +924,16 @@ menuconfig EXPERT
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.
+config HW_BREAKPOINT
+ bool "Hardware breakpoints" if EXPERT
+ depends on HAVE_HW_BREAKPOINT
+ default y
+ help
+ Hardware breakpoints are a feature implemented by most CPUs
+ to trigger an event when an instruction or data fetch
+ matches a given pattern. This is typically used by ptrace
+ and perf events.
+
config UID16
bool "Enable 16-bit UID system calls" if EXPERT
depends on ARM || BLACKFIN || CRIS || FRV || H8300 || X86_32 || M68K || (S390 && !64BIT) || SUPERH || SPARC32 || (SPARC64 && COMPAT) || UML || (X86_64 && IA32_EMULATION)
--
1.7.3.2
^ permalink raw reply related
* [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events
From: Frederic Weisbecker @ 2011-05-24 21:52 UTC (permalink / raw)
To: LKML
Cc: Peter Zijlstra, Frederic Weisbecker, Will Deacon, LKML,
Paul Mundt, Prasad, Ingo Molnar, linuxppc-dev
In-Reply-To: <1306273947-8410-1-git-send-email-fweisbec@gmail.com>
The breakpoint support ability in an arch is not related
to the fact perf events is built or not. HAVE_HW_BREAKPOINT
only shows an ability so this dependency makes no sense
anymore. Archs that select HAVE_HW_BREAKPOINT already
ensure that perf event is built.
Remove that dependency.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
---
arch/Kconfig | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index f78c2be..ce4be89 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -149,7 +149,6 @@ config HAVE_DEFAULT_NO_SPIN_MUTEXES
config HAVE_HW_BREAKPOINT
bool
- depends on PERF_EVENTS
config HAVE_MIXED_BREAKPOINTS_REGS
bool
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config
From: Frederic Weisbecker @ 2011-05-24 21:52 UTC (permalink / raw)
To: LKML
Cc: Peter Zijlstra, Frederic Weisbecker, LKML, Paul Mundt, Prasad,
Ingo Molnar, linuxppc-dev
In-Reply-To: <1306273947-8410-1-git-send-email-fweisbec@gmail.com>
Migrate conditional hw_breakpoint code compilation under
the new config to prepare for letting the user chose whether
or not to build this feature
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
---
arch/arm/include/asm/hw_breakpoint.h | 4 ++--
arch/arm/include/asm/processor.h | 2 +-
arch/arm/kernel/Makefile | 2 +-
| 2 +-
arch/arm/kernel/ptrace.c | 4 ++--
arch/powerpc/include/asm/cputable.h | 4 ++--
arch/powerpc/include/asm/hw_breakpoint.h | 6 +++---
arch/powerpc/include/asm/processor.h | 4 ++--
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/process.c | 18 +++++++++---------
arch/powerpc/kernel/ptrace.c | 13 +++++++------
arch/powerpc/lib/Makefile | 2 +-
arch/sh/kernel/Makefile | 2 +-
arch/sh/kernel/cpu/sh4a/Makefile | 2 +-
include/linux/hw_breakpoint.h | 6 +++---
include/linux/perf_event.h | 4 ++--
include/linux/ptrace.h | 6 +++---
include/linux/sched.h | 2 +-
kernel/events/Makefile | 2 +-
kernel/events/core.c | 4 ++--
kernel/ptrace.c | 4 ++--
samples/Kconfig | 2 +-
22 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/arch/arm/include/asm/hw_breakpoint.h b/arch/arm/include/asm/hw_breakpoint.h
index f389b27..fc6ba18 100644
--- a/arch/arm/include/asm/hw_breakpoint.h
+++ b/arch/arm/include/asm/hw_breakpoint.h
@@ -5,7 +5,7 @@
struct task_struct;
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
struct arch_hw_breakpoint_ctrl {
u32 __reserved : 9,
@@ -128,6 +128,6 @@ int hw_breakpoint_slots(int type);
#else
static inline void clear_ptrace_hw_breakpoint(struct task_struct *tsk) {}
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif /* __KERNEL__ */
#endif /* _ARM_HW_BREAKPOINT_H */
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index b2d9df5..b86d135 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -30,7 +30,7 @@
#endif
struct debug_info {
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
struct perf_event *hbp[ARM_MAX_HBP_SLOTS];
#endif
};
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 8d95446..e6c4b04 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -47,7 +47,7 @@ obj-$(CONFIG_HAVE_TCM) += tcm.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_SWP_EMULATE) += swp_emulate.o
CFLAGS_swp_emulate.o := -Wa,-march=armv7-a
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o
AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
--git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index 051166c..fbc7cc9 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -171,7 +171,7 @@
@ we can access the debug registers safely.
@
.macro debug_entry, fsr
-#if defined(CONFIG_HAVE_HW_BREAKPOINT) && defined(CONFIG_PREEMPT)
+#if defined(CONFIG_HW_BREAKPOINT) && defined(CONFIG_PREEMPT)
ldr r4, =0x40f @ mask out fsr.fs
and r5, r4, \fsr
cmp r5, #2 @ debug exception
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 8182f45..07be604 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -468,7 +468,7 @@ static int ptrace_setvfpregs(struct task_struct *tsk, void __user *data)
}
#endif
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
/*
* Convert a virtual register number into an index for a thread_info
* breakpoint array. Breakpoints are identified using positive numbers
@@ -765,7 +765,7 @@ long arch_ptrace(struct task_struct *child, long request,
break;
#endif
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
case PTRACE_GETHBPREGS:
if (ptrace_get_breakpoints(child) < 0)
return -ESRCH;
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 1833d1a..36b5568 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -538,9 +538,9 @@ static inline int cpu_has_feature(unsigned long feature)
& feature);
}
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
#define HBP_NUM 1
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h
index 1c33ec1..6ecd3b6 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -24,7 +24,7 @@
#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
#ifdef __KERNEL__
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
struct arch_hw_breakpoint {
bool extraneous_interrupt;
@@ -65,10 +65,10 @@ static inline void hw_breakpoint_disable(void)
}
extern void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs);
-#else /* CONFIG_HAVE_HW_BREAKPOINT */
+#else /* CONFIG_HW_BREAKPOINT */
static inline void hw_breakpoint_disable(void) { }
static inline void thread_change_pc(struct task_struct *tsk,
struct pt_regs *regs) { }
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif /* __KERNEL__ */
#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index de1967a..3fe688d 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -207,14 +207,14 @@ struct thread_struct {
#ifdef CONFIG_PPC64
unsigned long start_tb; /* Start purr when proc switched in */
unsigned long accum_tb; /* Total accumilated purr for process */
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
struct perf_event *ptrace_bps[HBP_NUM];
/*
* Helps identify source of single-step exception and subsequent
* hw-breakpoint enablement
*/
struct perf_event *last_hit_ubp;
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3bb2a3e..5df8585 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -36,7 +36,7 @@ obj-y := cputable.o ptrace.o syscalls.o \
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o idle_book3e.o
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index f74f355..3faf61a 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -353,7 +353,7 @@ static void switch_booke_debug_regs(struct thread_struct *new_thread)
prime_debug_regs(new_thread);
}
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
-#ifndef CONFIG_HAVE_HW_BREAKPOINT
+#ifndef CONFIG_HW_BREAKPOINT
static void set_debug_reg_defaults(struct thread_struct *thread)
{
if (thread->dabr) {
@@ -361,7 +361,7 @@ static void set_debug_reg_defaults(struct thread_struct *thread)
set_dabr(0);
}
}
-#endif /* !CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* !CONFIG_HW_BREAKPOINT */
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
int set_dabr(unsigned long dabr)
@@ -469,10 +469,10 @@ struct task_struct *__switch_to(struct task_struct *prev,
* For PPC_BOOK3S_64, we use the hw-breakpoint interfaces that would
* schedule DABR
*/
-#ifndef CONFIG_HAVE_HW_BREAKPOINT
+#ifndef CONFIG_HW_BREAKPOINT
if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
set_dabr(new->thread.dabr);
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif
@@ -672,11 +672,11 @@ void flush_thread(void)
{
discard_lazy_cpu_state();
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
flush_ptrace_hw_breakpoint(current);
-#else /* CONFIG_HAVE_HW_BREAKPOINT */
+#else /* CONFIG_HW_BREAKPOINT */
set_debug_reg_defaults(¤t->thread);
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
}
void
@@ -694,9 +694,9 @@ void prepare_to_copy(struct task_struct *tsk)
flush_altivec_to_thread(current);
flush_vsx_to_thread(current);
flush_spe_to_thread(current);
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
flush_ptrace_hw_breakpoint(tsk);
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
}
/*
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index a6ae1cf..18c687e 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -877,7 +877,7 @@ void user_disable_single_step(struct task_struct *task)
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
void ptrace_triggered(struct perf_event *bp, int nmi,
struct perf_sample_data *data, struct pt_regs *regs)
{
@@ -893,17 +893,17 @@ void ptrace_triggered(struct perf_event *bp, int nmi,
attr.disabled = true;
modify_user_hw_breakpoint(bp, &attr);
}
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
int ret;
struct thread_struct *thread = &(task->thread);
struct perf_event *bp;
struct perf_event_attr attr;
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
* For embedded processors we support one DAC and no IAC's at the
@@ -932,7 +932,8 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
/* Ensure breakpoint translation bit is set */
if (data && !(data & DABR_TRANSLATION))
return -EIO;
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+
+#ifdef CONFIG_HW_BREAKPOINT
if (ptrace_get_breakpoints(task) < 0)
return -ESRCH;
@@ -978,7 +979,7 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
ptrace_put_breakpoints(task);
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
/* Move contents to the DABR register */
task->thread.dabr = data;
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 166a6a0..515d044 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -19,7 +19,7 @@ obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
checksum_wrappers_64.o hweight_64.o
obj-$(CONFIG_XMON) += sstep.o ldstfp.o
obj-$(CONFIG_KPROBES) += sstep.o ldstfp.o
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += sstep.o ldstfp.o
+obj-$(CONFIG_HW_BREAKPOINT) += sstep.o ldstfp.o
ifeq ($(CONFIG_PPC64),y)
obj-$(CONFIG_SMP) += locks.o
diff --git a/arch/sh/kernel/Makefile b/arch/sh/kernel/Makefile
index 77f7ae1..9d5075c 100644
--- a/arch/sh/kernel/Makefile
+++ b/arch/sh/kernel/Makefile
@@ -45,7 +45,7 @@ obj-$(CONFIG_HIBERNATION) += swsusp.o
obj-$(CONFIG_DWARF_UNWINDER) += dwarf.o
obj-$(CONFIG_PERF_EVENTS) += perf_event.o perf_callchain.o
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST) += localtimer.o
ccflags-y := -Werror
diff --git a/arch/sh/kernel/cpu/sh4a/Makefile b/arch/sh/kernel/cpu/sh4a/Makefile
index cc122b1..5bec639 100644
--- a/arch/sh/kernel/cpu/sh4a/Makefile
+++ b/arch/sh/kernel/cpu/sh4a/Makefile
@@ -46,4 +46,4 @@ obj-y += $(clock-y)
obj-$(CONFIG_SMP) += $(smp-y)
obj-$(CONFIG_GENERIC_GPIO) += $(pinmux-y)
obj-$(CONFIG_PERF_EVENTS) += perf_event.o
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += ubc.o
+obj-$(CONFIG_HW_BREAKPOINT) += ubc.o
diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h
index d1e55fe..9aad682 100644
--- a/include/linux/hw_breakpoint.h
+++ b/include/linux/hw_breakpoint.h
@@ -31,7 +31,7 @@ enum bp_type_idx {
#include <linux/perf_event.h>
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
extern int __init init_hw_breakpoint(void);
@@ -108,7 +108,7 @@ static inline struct arch_hw_breakpoint *counter_arch_bp(struct perf_event *bp)
return &bp->hw.info;
}
-#else /* !CONFIG_HAVE_HW_BREAKPOINT */
+#else /* !CONFIG_HW_BREAKPOINT */
static inline int __init init_hw_breakpoint(void) { return 0; }
@@ -144,7 +144,7 @@ static inline struct arch_hw_breakpoint *counter_arch_bp(struct perf_event *bp)
return NULL;
}
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif /* __KERNEL__ */
#endif /* _LINUX_HW_BREAKPOINT_H */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 3412684..6a65fbf 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -491,7 +491,7 @@ struct perf_guest_info_callbacks {
unsigned long (*get_guest_ip)(void);
};
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
#include <asm/hw_breakpoint.h>
#endif
@@ -556,7 +556,7 @@ struct hw_perf_event {
struct { /* software */
struct hrtimer hrtimer;
};
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
struct { /* breakpoint */
struct arch_hw_breakpoint info;
struct list_head bp_list;
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 9178d5c..9ff2641 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -190,7 +190,7 @@ static inline void ptrace_init_task(struct task_struct *child, bool ptrace)
__ptrace_link(child, current->parent);
}
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
atomic_set(&child->ptrace_bp_refcnt, 1);
#endif
}
@@ -354,12 +354,12 @@ extern int task_current_syscall(struct task_struct *target, long *callno,
unsigned long args[6], unsigned int maxargs,
unsigned long *sp, unsigned long *pc);
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
extern int ptrace_get_breakpoints(struct task_struct *tsk);
extern void ptrace_put_breakpoints(struct task_struct *tsk);
#else
static inline void ptrace_put_breakpoints(struct task_struct *tsk) { }
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
#endif /* __KERNEL */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 781abd1..b575989 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1537,7 +1537,7 @@ struct task_struct {
unsigned long memsw_nr_pages; /* uncharged mem+swap usage */
} memcg_batch;
#endif
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
atomic_t ptrace_bp_refcnt;
#endif
};
diff --git a/kernel/events/Makefile b/kernel/events/Makefile
index 1ce23d3..3659100 100644
--- a/kernel/events/Makefile
+++ b/kernel/events/Makefile
@@ -3,4 +3,4 @@ CFLAGS_REMOVE_core.o = -pg
endif
obj-y := core.o
-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
+obj-$(CONFIG_HW_BREAKPOINT) += hw_breakpoint.o
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0fc34a3..9f19c33 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5616,7 +5616,7 @@ static void perf_event_free_filter(struct perf_event *event)
#endif /* CONFIG_EVENT_TRACING */
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
void perf_bp_event(struct perf_event *bp, void *data)
{
struct perf_sample_data sample;
@@ -6207,7 +6207,7 @@ perf_event_alloc(struct perf_event_attr *attr, int cpu,
if (task) {
event->attach_state = PERF_ATTACH_TASK;
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
/*
* hw_breakpoint is a bit difficult here..
*/
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index dc7ab65..4c2cff7 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -881,7 +881,7 @@ asmlinkage long compat_sys_ptrace(compat_long_t request, compat_long_t pid,
}
#endif /* CONFIG_COMPAT */
-#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#ifdef CONFIG_HW_BREAKPOINT
int ptrace_get_breakpoints(struct task_struct *tsk)
{
if (atomic_inc_not_zero(&tsk->ptrace_bp_refcnt))
@@ -895,4 +895,4 @@ void ptrace_put_breakpoints(struct task_struct *tsk)
if (atomic_dec_and_test(&tsk->ptrace_bp_refcnt))
flush_ptrace_hw_breakpoint(tsk);
}
-#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* CONFIG_HW_BREAKPOINT */
diff --git a/samples/Kconfig b/samples/Kconfig
index 41063e7..d1e41e9 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -40,7 +40,7 @@ config SAMPLE_KRETPROBES
config SAMPLE_HW_BREAKPOINT
tristate "Build kernel hardware breakpoint examples -- loadable module only"
- depends on HAVE_HW_BREAKPOINT && m
+ depends on HW_BREAKPOINT && m
help
This builds kernel hardware breakpoint example modules.
--
1.7.3.2
^ permalink raw reply related
* [PATCH 5/6] hw_breakpoints: Only force perf events if breakpoints are selected
From: Frederic Weisbecker @ 2011-05-24 21:52 UTC (permalink / raw)
To: LKML
Cc: Peter Zijlstra, Frederic Weisbecker, Will Deacon, LKML,
Paul Mundt, Prasad, Ingo Molnar, linuxppc-dev
In-Reply-To: <1306273947-8410-1-git-send-email-fweisbec@gmail.com>
Previously, arch were forced to always build perf events if they
supported hw_breakpoints.
Now that the user can choose not to build hw_breakpoints, let
only force perf events if hw_breakpoints are selected.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
---
arch/sh/Kconfig | 1 -
arch/x86/Kconfig | 1 -
init/Kconfig | 1 +
3 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 0d4d124..d59e6c2 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -46,7 +46,6 @@ config SUPERH32
select HAVE_HW_BREAKPOINT
select HW_BREAKPOINT
select HAVE_MIXED_BREAKPOINTS_REGS
- select PERF_EVENTS
select ARCH_HIBERNATION_POSSIBLE if MMU
select SPARSE_IRQ
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fb28dd9..5317f42 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -55,7 +55,6 @@ config X86
select HAVE_KERNEL_LZO
select HAVE_HW_BREAKPOINT
select HAVE_MIXED_BREAKPOINTS_REGS
- select PERF_EVENTS
select HAVE_PERF_EVENTS_NMI
select ANON_INODES
select HAVE_ARCH_KMEMCHECK
diff --git a/init/Kconfig b/init/Kconfig
index 76ae53e..9ae3555 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -927,6 +927,7 @@ menuconfig EXPERT
config HW_BREAKPOINT
bool "Hardware breakpoints" if EXPERT
depends on HAVE_HW_BREAKPOINT
+ select PERF_EVENTS
default y
help
Hardware breakpoints are a feature implemented by most CPUs
--
1.7.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox