* Hemant Kumar hem...@linux.vnet.ibm.com wrote:
# perf kvm stat report -p 60515
Analyze events for pid(s) 60515, all VCPUs:
VM-EXITSamples Samples% Time%Min Time Max
Time Avg time
H_DATA_STORAGE 500635.30% 0.13% 1.94us
* Michael Ellerman m...@ellerman.id.au wrote:
We just merged a patch series that was first sent in 2013. Some
things take time to get right.
The first attempt to get symbolic event name support into perf was
sent in 2010, that's FIVE years ago [1].
kgdb took even longer, I think it
* Sukadev Bhattiprolu suka...@linux.vnet.ibm.com wrote:
This is another attempt to resurrect Andi Kleen's patchset so users
can specify perf events by their event names rather than raw codes.
This is a rebase of Andi Kleen's patchset from Jul 30, 2014[1] to 4.0.
(I fixed minor and not so
* Michael Ellerman m...@ellerman.id.au wrote:
On Tue, 2015-04-14 at 10:55 +0200, Ingo Molnar wrote:
* Sukadev Bhattiprolu suka...@linux.vnet.ibm.com wrote:
This is another attempt to resurrect Andi Kleen's patchset so users
can specify perf events by their event names rather than raw
* Peter Zijlstra pet...@infradead.org wrote:
On Thu, Apr 02, 2015 at 12:42:27PM +0200, Ingo Molnar wrote:
So why not use a suitable CPU_DOWN* notifier for this, instead of open
coding it all into a random place in the hotplug machinery?
Because notifiers are crap? ;-) [...]
No doubt
* Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
On 04/02/2015 04:12 PM, Ingo Molnar wrote:
* Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
It was found when doing a hotplug stress test on POWER, that the machine
either hit softlockups or rcu_sched stall warnings. The issue
* Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
It was found when doing a hotplug stress test on POWER, that the machine
either hit softlockups or rcu_sched stall warnings. The issue was
traced to commit 7cba160ad789a powernv/cpuidle: Redesign idle states
management, which exposed the
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+ unsigned long old_start, unsigned long old_end,
+ unsigned long new_start, unsigned long new_end)
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+ unsigned long
mremap() call.
I'm fine with your original, imperfect, KISS approach. Sorry about
this detour ...
Reviewed-by: Ingo Molnar mi...@kernel.org
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
* Laurent Dufour lduf...@linux.vnet.ibm.com wrote:
I argue we should use the right condition to clear vdso_base: if
the vDSO gets at least partially unmapped. Otherwise there's
little point in the whole patch: either correctly track whether
the vDSO is OK, or don't ...
That's a
* Laurent Dufour lduf...@linux.vnet.ibm.com wrote:
Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to
* Laurent Dufour lduf...@linux.vnet.ibm.com wrote:
+static inline void arch_unmap(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+ if (start = mm-context.vdso_base mm-context.vdso_base end)
+
* Ingo Molnar mi...@kernel.org wrote:
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+ unsigned long old_start, unsigned long old_end,
+ unsigned long new_start, unsigned long new_end
* Laurent Dufour lduf...@linux.vnet.ibm.com wrote:
Some architecture would like to be triggered when a memory area is moved
through the mremap system call.
This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is
* Mel Gorman mgor...@suse.de wrote:
Elapsed time is primarily worse on one benchmark -- numa01 which is
an adverse workload. The user time differences are also dominated by
that benchmark
4.0.0-rc1 4.0.0-rc1
3.19.0
* Mel Gorman mgor...@suse.de wrote:
xfsrepair
4.0.0-rc1 4.0.0-rc1
3.19.0
vanilla slowscan-v2
vanilla
Min real-fsmark1157.41 ( 0.00%) 1150.38 (
* Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar mi...@kernel.org wrote:
And the patch Dave bisected to is a relatively simple patch. Why
not simply revert it to see whether that cures much of the
problem?
So the problem
* Mel Gorman mgor...@suse.de wrote:
Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
Across the board the 4.0-rc1 numbers are much slower, and the
degradation is far worse when using the large memory footprint
configs. Perf points straight at the cause - this is
with building the rest.
Ok, this looks really good - for all patches:
Reviewed-by: Ingo Molnar mi...@kernel.org
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
definitions were
identical.
Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Ingo Molnar mi...@kernel.org
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
* Kees Cook keesc...@chromium.org wrote:
On Mon, Mar 2, 2015 at 11:31 PM, Ingo Molnar mi...@kernel.org wrote:
* Kees Cook keesc...@chromium.org wrote:
To address the offset2lib ASLR weakness[1], this separates ET_DYN
ASLR from mmap ASLR, as already done on s390. The architectures
* Kees Cook keesc...@chromium.org wrote:
Most architectures don't need to do anything special for the strict
seccomp syscall entries. Remove the redundant headers and reduce the
others.
19 files changed, 27 insertions(+), 137 deletions(-)
Lovely cleanup factor.
Just to make sure, are you
() made available
via the new CONFIG_ARCH_HAS_ELF_RANDOMIZE. For these architectures,
arch_randomize_brk() is collapsed as well.
This is an alternative to the solutions in:
https://lkml.org/lkml/2015/2/23/442
Looks good so far:
Reviewed-by: Ingo Molnar mi...@kernel.org
While reviewing
CONFIG_ARCH_HAS_ELF_RANDOMIZE. For
these architectures, arch_randomize_brk() is collapsed as
well.
This is an alternative to the solutions in:
https://lkml.org/lkml/2015/2/23/442
Nice!
Acked-by: Ingo Molnar mi...@kernel.org
Thanks,
Ingo
* Anton Blanchard an...@samba.org wrote:
Every now and then I end up with an undebuggable issue
because multiple CPUs hit something at the same time and
everything is interleaved:
CR: 4882 XER:
,RI
c003dc72fd10
,LE
* Hector Marco Gisbert hecma...@upv.es wrote:
+unsigned long randomize_et_dyn(unsigned long base)
+{
+ unsigned long ret;
+ if ((current-personality ADDR_NO_RANDOMIZE) ||
+ !(current-flags PF_RANDOMIZE))
+ return base;
+ ret = base + mmap_rnd();
+
* Ingo Molnar mi...@kernel.org wrote:
* Anton Blanchard an...@samba.org wrote:
+static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int die_owner = -1;
+static unsigned int die_nest_count;
+
+unsigned long __die_spin_lock_irqsave(void)
+{
+ unsigned long
* Anton Blanchard an...@samba.org wrote:
+static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int die_owner = -1;
+static unsigned int die_nest_count;
+
+unsigned long __die_spin_lock_irqsave(void)
+{
+ unsigned long flags;
+ int cpu;
+
+ /* racy, but
* Scott Wood scottw...@freescale.com wrote:
On Mon, 2015-02-09 at 21:40 +0100, Andi Kleen wrote:
I'll NAK any external 'download area' (and I told that Andi
before): tools/perf/event-tables/ or so is a good enough
'download area' with fast enough update cycles.
The proposal was
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
arch/powerpc/perf/e6500-events-list.h | 289
++
That's a lot of events to stuff in the kernel, would a
userspace list not be more convenient?
ISTR
* Jiri Olsa jo...@redhat.com wrote:
On Mon, Feb 09, 2015 at 11:07:38AM +0100, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
arch/powerpc/perf/e6500-events-list.h | 289
* Arnaldo Carvalho de Melo a...@kernel.org wrote:
Hi Ingo,
Please consider pulling, it has my latest perf/urgent pull content,
please let me know if you don't want it to be submitted like that, i.e. if
you have any problems with my latest perf/urgent pull request and I'll try
to
* Anton Blanchard an...@samba.org wrote:
I have a busy ppc64le KVM box where guests sometimes hit the
infamous kernel BUG at kernel/smpboot.c:134! issue during
boot:
BUG_ON(td-cpu != smp_processor_id());
Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output
* Arnaldo Carvalho de Melo a...@kernel.org wrote:
Hi Ingo,
Please consider pulling, I guess the changes are minor of affect just
some
non-core feature, so it is you call if you prefer to pull it into perf/urgent
instead.
Best Regards,
- Arnaldo
The following changes since
* Arnaldo Carvalho de Melo a...@kernel.org wrote:
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit f373da34282560c60f0c197690eecb1b2dc49fc0:
Merge tag 'perf-core-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Looks good, but this is not a valid SOB sequence: if Suzuki wrote the
patch then he should be the first SOB (and should
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2014/07/16 22:28), Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2014/07/15 16:16), Benjamin Herrenschmidt wrote:
On Tue, 2014-07-15 at 13:19 +1000, Michael Ellerman wrote:
Signed-off
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2014/07/15 16:16), Benjamin Herrenschmidt wrote:
On Tue, 2014-07-15 at 13:19 +1000, Michael Ellerman wrote:
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Reported-by: Tony Luck tony.l...@gmail.com
Tested-by:
* Rusty Russell ru...@rustcorp.com.au wrote:
Ingo Molnar mi...@kernel.org writes:
* Madhavan Srinivasan ma...@linux.vnet.ibm.com wrote:
Performance data for different FAULT_AROUND_ORDER values from 4 socket
Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
* Madhavan Srinivasan ma...@linux.vnet.ibm.com wrote:
Performance data for different FAULT_AROUND_ORDER values from 4 socket
Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
is used to get the stddev values. Test ran in v3.14 kernel (Baseline) and
v3.15-rc1 for
* Madhavan Srinivasan ma...@linux.vnet.ibm.com wrote:
Performance data for different FAULT_AROUND_ORDER values from 4 socket
Power7 system (128 Threads and 128GB memory) is below. perf stat with
repeat of 5 is used to get the stddev values. This patch create
FAULT_AROUND_ORDER Kconfig
* Ingo Molnar mi...@kernel.org wrote:
* Madhavan Srinivasan ma...@linux.vnet.ibm.com wrote:
Performance data for different FAULT_AROUND_ORDER values from 4
socket Power7 system (128 Threads and 128GB memory) is below. perf
stat with repeat of 5 is used to get the stddev values
* Madhavan Srinivasan ma...@linux.vnet.ibm.com wrote:
Performance data for different FAULT_AROUND_ORDER values from 4 socket
Power7 system (128 Threads and 128GB memory) is below. Fault around order
(FAO)
value of 3 looks more advantageous.
FAULT_AROUND_ORDER Baseline1
* Paul Gortmaker paul.gortma...@windriver.com wrote:
On Feb 4, 2014 3:52 PM, Paul Gortmaker paul.gortma...@windriver.com
wrote:
We've had this in linux-next for 2+ weeks (thanks Stephen!) as a
linux-stable like queue of patches, and as can be seen here:
* Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Ingo,
On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar mi...@kernel.org wrote:
So, if you meant Linus to pull it, you probably want to cite a real
Git URI along the lines of:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg
...@mprc.pku.edu.cn
CC: Thomas Gleixner t...@linutronix.de
CC: Ingo Molnar mi...@redhat.com
CC: H. Peter Anvin h...@zytor.com
CC: x...@kernel.org
---
drivers/parport/Kconfig | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/parport/Kconfig b/drivers/parport
* Alexei Starovoitov a...@plumgrid.com wrote:
on x86 system with net.core.bpf_jit_enable = 1
sudo tcpdump -i eth1 'tcp port 22'
causes the warning:
[ 56.766097] Possible unsafe locking scenario:
[ 56.766097]
[ 56.780146]CPU0
[ 56.786807]
[ 56.793188]
* Eric Dumazet eduma...@google.com wrote:
1)
I took a brief look at arch/x86/net/bpf_jit_comp.c while reviewing this
patch.
You need to split up bpf_jit_compile(), it's an obscenely large, ~600
lines long function. We don't do that in modern, maintainable kernel code.
2)
by other kernel
subsystems as well? In particular tracing filters could make use of
it, but it would also allow safe probe points.
That was exactly the reasons to generalize bpf as I proposed.
Ok, cool :-)
For the x86 bits:
Acked-by: Ingo Molnar mi...@kernel.org
Thanks,
Ingo
t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: Ralf Baechle r...@linux-mips.org
Cc: linux-m...@linux-mips.org
Cc: Benjamin Herrenschmidt b
* Timothy Pepper timothy.c.pep...@linux.intel.com wrote:
On Wed 25 Sep at 09:30:49 +0200 mi...@kernel.org said:
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
- info.low_limit = PAGE_SIZE;
+ info.low_limit = max(PAGE_SIZE, PAGE_ALIGN(mmap_min_addr));
.
+ initially work for you. As of this writing the exact hardware
+ interface is strongly in flux, so no good recommendation can be
+ made.
config CRASH_DUMP
bool kernel crash dumps
Acked-by: Ingo Molnar mi...@kernel.org
Thanks,
Ingo
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
From: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Hi Ingo,
Please consider pulling.
There was a long delay in processing patches related to my vacations
that took longer than antecipated to being addressed.
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
From: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Hi Ingo,
Please consider pulling,
Regards,
- Arnaldo
The following changes since commit e5302920da9ef23f9d19d4e9ac85704cc25bee7a:
perf: Fix interrupt handler
* Michael Ellerman mich...@ellerman.id.au wrote:
On Tue, Jul 09, 2013 at 10:14:34AM +0200, Peter Zijlstra wrote:
On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
So something like they have on ARM?
vince@pandaboard:/sys/bus/event_source/devices$ ls -l
lrwxrwxrwx
* Peter Zijlstra pet...@infradead.org wrote:
On Thu, Jul 04, 2013 at 10:52:18PM +1000, Michael Ellerman wrote:
I don't think it even needs libpfm4, just some csv files in tools/perf
would do the trick.
Right; I think Stephane and Jiri are in favour of creating a 'new'
project that
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
From: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit c0ffaf3655fab1909a920c8f30ba1722932d01bb:
watchdog: Remove softlockup_thresh from
* Russell King - ARM Linux li...@arm.linux.org.uk wrote:
So, if you want to use this, then you should update the CONFIG_BUG text
to include a warning to this effect:
Warning: if CONFIG_BUG is turned off, and control flow reaches
a BUG(), the system behaviour will be undefined.
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
From: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit cb16b91a449afd01b85ec4e59f30449d11c4acd7:
s390: Fix a header dependencies related
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit 152fefa921535665f95840c08062844ab2f5593e:
Merge tag 'perf-core-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
in the variable name as a parameter.
Changelog[v2]
- [Jiri Olsa] No need to define PMU_EVENT_PTR()
Signed-off-by: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Acked-by: Jiri Olsa jo...@redhat.com
Cc: Andi Kleen a...@linux.intel.com
Cc: Anton Blanchard an...@au1.ibm.com
Cc: Ingo Molnar mi
leaks in exit paths.
. Use memdup where applicable
. Remove some die() calls, allowing callers to handle exit paths
gracefully.
. Correct typo in tools Makefile, fix from Borislav Petkov.
. Add 'perf bench numa mem' NUMA performance measurement suite, from Ingo
Molnar.
. Handle
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit 203e04c16330c880538588e932743f404ee4fd66:
Merge tag 'perf-core-for-mingo' of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
changing trace_clocks
Feng Tang (1):
perf browser: Don't show scripts menu for 'perf top'
Hiraku Toyooka (1):
tracing: Change tracer's integer flags to bool
Ingo Molnar (2):
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/.../acme/linux
into perf/core
Merge
Note that I had to do a number of conflict resolutions between
perf/urgent (now upstream) and perf/core, related to UAPI fixes:
commit f0b9abfb044649bc452fb2fb975ff2fd599cc6a3
Merge: adc1ef1 1b3c393
Author: Ingo Molnar mi...@kernel.org
Date: Sat Dec 8 15:25:06 2012 +0100
Merge branch
* Arnaldo Carvalho de Melo a...@infradead.org wrote:
Hi Ingo,
Tested using a cross-compiler and directly on a Raspberry pi (ARM) with
raspbian.
Please consider pulling.
- Arnaldo
The following changes since commit 18423d3562f396206e0928a71177eeb2edfed077:
Merge tag
* Andrew Morton a...@linux-foundation.org wrote:
On Mon, 20 Aug 2012 16:52:29 +0300
Kirill A. Shutemov kirill.shute...@linux.intel.com wrote:
Clearing a 2MB huge page will typically blow away several levels of CPU
caches. To avoid this only cache clear the 4K area around the fault
.
+ *
+ * However, some user programs are fine with this. They can
+ * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
*/
-#if defined(__powerpc64__) !defined(__KERNEL__)
+#if !defined(__SANE_USERSPACE_TYPES__) defined(__powerpc64__)
!defined(__KERNEL__)
Acked-by: Ingo Molnar mi
* Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Jul 20, 2011 at 7:58 AM, Peter Zijlstra a.p.zijls...@chello.nl
wrote:
Right, so we can either merge my scary patches now and have 3.0
boot on 16+ node machines (and risk breaking something), or delay
them until 3.0.1 and
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Fri, 2011-07-01 at 14:15 +0200, Ingo Molnar wrote:
+/* WARNING: This is going to override the generic definition whenever
+ * pseries is built-in regardless of what platform is active at boot
+ * time. This is fine for now
---
Ingo, Thomas: Who needs to ack the x86 bit ? I'd like to send that
to Linus asap with the powerpc fix.
Acked-by: Ingo Molnar mi...@elte.hu
(btw., you can consider obvious cleanups as being implicitly acked by
me and don't need to block fixes on me.)
Thanks,
Ingo
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
Just compiling pseries in the kernel causes it to override
memory_block_size_bytes() regardless of what is the runtime
platform.
This cleans up the implementation of that function, fixing
a bug or two while at it, so that it's
* Peter Zijlstra pet...@infradead.org wrote:
But face it, you can argue until you're blue in the face,
That is not a technical argument though - and i considered and
answered every valid technical argument made by you and Thomas.
You were either not able to or not willing to counter them.
* Pavel Machek pa...@ucw.cz wrote:
On Mon 2011-05-16 10:36:05, James Morris wrote:
On Fri, 13 May 2011, Ingo Molnar wrote:
How do you reason about the behavior of the system as a whole?
I argue that this is the LSM and audit subsystems designed right: in the
long
run
* Thomas Gleixner t...@linutronix.de wrote:
We do _NOT_ make any decision based on the trace point so
what's the pre-existing active role in the syscall entry
code?
The seccomp code we are discussing in this thread.
That's proposed code and has absolutely nothing to do with
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 May 2011, Ingo Molnar wrote:
* Peter Zijlstra pet...@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
* Peter Zijlstra pet...@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
* Will Drewry w...@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
* Ingo Molnar mi...@elte.hu wrote:
* Peter Zijlstra pet...@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
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
On Wed, May 18, 2011 at 11:31 AM, Milton Miller milt...@bga.com wrote:
So the real question should be why is x86-32 supplying a broken writeq
instead of letting drivers work
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of
the
way multiple callbacks can be registered. How would
* Will Drewry w...@chromium.org wrote:
This is *far* more generic still yields the same short-term end result as
far as your sandboxing is concerned.
Almost :/ [...]
Hey that's a pretty good result from a subsystem that was not written with your
usecase in mind *at all* ;-)
[...] I
* James Morris jmor...@namei.org wrote:
On Tue, 17 May 2011, Ingo Molnar wrote:
I'm not sure i get your point.
Your example was not complete as described. After an apparently simple
specification, you've since added several qualifiers and assumptions, [...]
I havent added any
* David Laight david.lai...@aculab.com wrote:
[...] unfortunately it worked by looking at the user-space buffers on system
call entry - and a multithreaded program can easily arrange to update them
after the initial check! [...]
Such problems of reliability/persistency of security checks
* Arnd Bergmann a...@arndb.de wrote:
On Saturday 14 May 2011, Will Drewry wrote:
Depending on integration, it could even be limited to ioctl commands
that are appropriate to a known fd if the fd is opened prior to
entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed
with
* Will Drewry w...@chromium.org wrote:
Note, i'm not actually asking for the moon, a pony and more.
I fully submit that we are yet far away from being able to do a full LSM
via this mechanism.
What i'm asking for is that because the syscall point steps taken by Will
look very
* Will Drewry w...@chromium.org wrote:
I agree with you on many of these points! However, I don't think that the
views around LSMs, perf/ftrace infrastructure, or the current seccomp
filtering implementation are necessarily in conflict. Here is my
understanding of how the different
* James Morris jmor...@namei.org wrote:
On Fri, 13 May 2011, Ingo Molnar wrote:
Say i'm a user-space sandbox developer who wants to enforce that sandboxed
code should only be allowed to open files in /home/sandbox/, /lib/ and
/usr/lib/.
It is a simple and sensible security
* Steven Rostedt rost...@goodmis.org wrote:
I'm a bit nervous about the 'active' role of (trace_)events, because of the
way multiple callbacks can be registered. How would:
err = event_x();
if (err == -EACCESS) {
be handled? [...]
The default behavior would be something
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote:
this is a security mechanism
Who says? [...]
Kernel developers/maintainers of the affected code.
We have security hooks all around the kernel, which can deny/accept execution
at various
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
err = event_vfs_getname(result);
I really think we should not do this. Events like we have them should be
inactive, totally passive entities, only observe but not affect execution
* Peter Zijlstra pet...@infradead.org wrote:
Why should we have two callbacks next to each other:
event_vfs_getname(result);
result = check_event_vfs_getname(result);
if one could do it all?
Did you actually read the bit where I said that check_event_* (although
I still
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote:
event_vfs_getname(result);
result = check_event_vfs_getname(result);
Another fundamental difference is how to treat the callback chains for
these two.
Observers
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run all active callbacks as well.
For example if this is used for three stacked security policies - as if 3
LSM
modules were stacked at once. We'd
* Peter Zijlstra pet...@infradead.org wrote:
Cut the microblaze list since its bouncy.
On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote:
I think the sanest semantics is to run
* Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2011-05-13 at 14:49 +0200, Ingo Molnar wrote:
So given that by your own admission it makes sense to share the facilities
at
the low level, i also argue that it makes sense to share as high up as
possible.
I'm not saying any
* James Morris jmor...@namei.org wrote:
On Thu, 12 May 2011, Ingo Molnar wrote:
Funnily enough, back then you wrote this:
I'm concerned that we're seeing yet another security scheme being
designed on
the fly, without a well-formed threat model, and without taking
Ok, i like the direction here, but i think the ABI should be done differently.
In this patch the ftrace event filter mechanism is used:
* Will Drewry w...@chromium.org wrote:
+static struct seccomp_filter *alloc_seccomp_filter(int syscall_nr,
+
* Kees Cook kees.c...@canonical.com wrote:
Hi,
On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote:
1) We already have a specific ABI for this: you can set filters for events
via
an event fd.
Why not extend that mechanism instead and improve *both* your sandboxing
101 - 200 of 334 matches
Mail list logo
