linux.kernel - 26 new messages in 14 topics - digest
linux.kernel
http://groups.google.com/group/linux.kernel?hl=en
linux.kernel@googlegroups.com
Today's topics:
* v3.13-rc6+ regression (ARM board) - 6 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/319d06ce78cc6f61?hl=en
* Broken terminal due to echo bufferring - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7703b54a38388d29?hl=en
* at91: dt: sam9261: Added DM9000 in the device tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b947ff38bef93f1f?hl=en
* block/ps3: Remove obsolete reference to MTD - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4b358c9e90189fdf?hl=en
* Kconfig: collapse initrd in to own menu - 5 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/196ce794be2da521?hl=en
* tty: serial: Limit msm_serial_hs driver to platforms that use it - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/78640313ea9bd094?hl=en
* KVM: NULL return of kvmppc_mmu_hpte_cache_next should be handled - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/db8e3a5ca5f7a88a?hl=en
* Memory allocator semantics - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6e5ee072925a3728?hl=en
* kexec: A new system call, kexec_file_load, for in kernel kexec - 2 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/a236ab808c9846df?hl=en
* Staging: rtl8188eu: Fixed coding style issues - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2705bc06f1f0429f?hl=en
* tracing/uprobes: Add support for full argument access methods - 2 messages,
1 author
http://groups.google.com/group/linux.kernel/t/f41aaed2c446cfa8?hl=en
* futex: Avoid taking hb lock if nothing to wakeup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/af4a2848ad48ded5?hl=en
* usb: xhci: Link TRB must not occur within a USB payload burst - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/02bb633f7aaf9195?hl=en
* pci: APM X-Gene PCIe controller driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bb793bfb4a89dad9?hl=en
==============================================================================
TOPIC: v3.13-rc6+ regression (ARM board)
http://groups.google.com/group/linux.kernel/t/319d06ce78cc6f61?hl=en
==============================================================================
== 1 of 6 ==
Date: Thurs, Jan 2 2014 11:40 am
From: Linus Torvalds
On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
>
> This means these two commits don't like each other:
>
> seqcount: Add lockdep functionality to seqcount/seqlock structures
> sched_clock: Use seqcount instead of rolling our own
Does something like this fix it for you?
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400);
static struct clock_data cd = {
.mult = NSEC_PER_SEC / HZ,
+ .seq = SEQCNT_ZERO(cd.seq),
};
static u64 __read_mostly sched_clock_mask;
(The above is not even compile-tested, because x86 doesn't use
GENERIC_SCHED_CLOCK. So I did the patch blindly, but I think you get
the idea..)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 6 ==
Date: Thurs, Jan 2 2014 12:10 pm
From: John Stultz
On 01/02/2014 11:38 AM, Linus Torvalds wrote:
> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
>> This means these two commits don't like each other:
>>
>> seqcount: Add lockdep functionality to seqcount/seqlock structures
>> sched_clock: Use seqcount instead of rolling our own
> Does something like this fix it for you?
>
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400);
>
> static struct clock_data cd = {
> .mult = NSEC_PER_SEC / HZ,
> + .seq = SEQCNT_ZERO(cd.seq),
> };
>
> static u64 __read_mostly sched_clock_mask;
>
> (The above is not even compile-tested, because x86 doesn't use
> GENERIC_SCHED_CLOCK. So I did the patch blindly, but I think you get
> the idea..)
Sheesh. Just finishing up holiday email backlog and Linus already has a
fix. :)
This looks like it should fix the issue, and does build for me.
Assuming it works for Krzysztof,
Acked-by: John Stultz <john.stultz@linaro.org>
I'll do another grep pass through -rc6 to make sure no other new
uninitialized seqlock usage was added.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 3 of 6 ==
Date: Thurs, Jan 2 2014 12:40 pm
From: John Stultz
On 01/02/2014 12:03 PM, John Stultz wrote:
> On 01/02/2014 11:38 AM, Linus Torvalds wrote:
>> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
>>> This means these two commits don't like each other:
>>>
>>> seqcount: Add lockdep functionality to seqcount/seqlock structures
>>> sched_clock: Use seqcount instead of rolling our own
>> Does something like this fix it for you?
>>
>> --- a/kernel/time/sched_clock.c
>> +++ b/kernel/time/sched_clock.c
>> @@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400);
>>
>> static struct clock_data cd = {
>> .mult = NSEC_PER_SEC / HZ,
>> + .seq = SEQCNT_ZERO(cd.seq),
>> };
>>
>> static u64 __read_mostly sched_clock_mask;
>>
>> (The above is not even compile-tested, because x86 doesn't use
>> GENERIC_SCHED_CLOCK. So I did the patch blindly, but I think you get
>> the idea..)
> Sheesh. Just finishing up holiday email backlog and Linus already has a
> fix. :)
>
> This looks like it should fix the issue, and does build for me.
>
> Assuming it works for Krzysztof,
So something else may be at play. Even with Linus' patch I reproduced a
similar hang here.
Still chasing it down, but it looks like a seqlock deadlock where we're
calling read while holding the lock.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 4 of 6 ==
Date: Thurs, Jan 2 2014 12:50 pm
From: Linus Torvalds
On Thu, Jan 2, 2014 at 12:30 PM, John Stultz <john.stultz@linaro.org> wrote:
>
> So something else may be at play. Even with Linus' patch I reproduced a
> similar hang here.
>
> Still chasing it down, but it looks like a seqlock deadlock where we're
> calling read while holding the lock.
Hmm. Only with lockdep, right?
Does lockdep perhaps read the scheduler clock? Afaik, we have
lockstat_clock(), which uses local_clock(), which in turn translates
to sched_clock_cpu(smp_processor_id())..
So if that code now tries to read the scheduler clock when
update_sched_clock() is doing a update and has done a
write_seqcount_begin()...
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 5 of 6 ==
Date: Thurs, Jan 2 2014 12:50 pm
From: Stephen Boyd
On 01/02/14 12:30, John Stultz wrote:
> On 01/02/2014 12:03 PM, John Stultz wrote:
>> On 01/02/2014 11:38 AM, Linus Torvalds wrote:
>>> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
>>>> This means these two commits don't like each other:
>>>>
>>>> seqcount: Add lockdep functionality to seqcount/seqlock structures
>>>> sched_clock: Use seqcount instead of rolling our own
>>> Does something like this fix it for you?
>>>
>>> --- a/kernel/time/sched_clock.c
>>> +++ b/kernel/time/sched_clock.c
>>> @@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400);
>>>
>>> static struct clock_data cd = {
>>> .mult = NSEC_PER_SEC / HZ,
>>> + .seq = SEQCNT_ZERO(cd.seq),
>>> };
>>>
>>> static u64 __read_mostly sched_clock_mask;
>>>
>>> (The above is not even compile-tested, because x86 doesn't use
>>> GENERIC_SCHED_CLOCK. So I did the patch blindly, but I think you get
>>> the idea..)
>> Sheesh. Just finishing up holiday email backlog and Linus already has a
>> fix. :)
>>
>> This looks like it should fix the issue, and does build for me.
>>
>> Assuming it works for Krzysztof,
> So something else may be at play. Even with Linus' patch I reproduced a
> similar hang here.
>
> Still chasing it down, but it looks like a seqlock deadlock where we're
> calling read while holding the lock.
>
Do you have tracing enabled? When I moved this code over to use
seqcounts it relied on the fact that the compiler wouldn't be generating
any function calls to the tracing code. Before seqcounts got lockdep
support it all collapsed down into sched_clock() due to the use of
inline on the seqlock API.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 6 of 6 ==
Date: Thurs, Jan 2 2014 1:00 pm
From: John Stultz
On 01/02/2014 12:42 PM, Stephen Boyd wrote:
> On 01/02/14 12:30, John Stultz wrote:
>> On 01/02/2014 12:03 PM, John Stultz wrote:
>>> On 01/02/2014 11:38 AM, Linus Torvalds wrote:
>>>> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa <khalasa@piap.pl> wrote:
>>>>> This means these two commits don't like each other:
>>>>>
>>>>> seqcount: Add lockdep functionality to seqcount/seqlock structures
>>>>> sched_clock: Use seqcount instead of rolling our own
>>>> Does something like this fix it for you?
>>>>
>>>> --- a/kernel/time/sched_clock.c
>>>> +++ b/kernel/time/sched_clock.c
>>>> @@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400);
>>>>
>>>> static struct clock_data cd = {
>>>> .mult = NSEC_PER_SEC / HZ,
>>>> + .seq = SEQCNT_ZERO(cd.seq),
>>>> };
>>>>
>>>> static u64 __read_mostly sched_clock_mask;
>>>>
>>>> (The above is not even compile-tested, because x86 doesn't use
>>>> GENERIC_SCHED_CLOCK. So I did the patch blindly, but I think you get
>>>> the idea..)
>>> Sheesh. Just finishing up holiday email backlog and Linus already has a
>>> fix. :)
>>>
>>> This looks like it should fix the issue, and does build for me.
>>>
>>> Assuming it works for Krzysztof,
>> So something else may be at play. Even with Linus' patch I reproduced a
>> similar hang here.
>>
>> Still chasing it down, but it looks like a seqlock deadlock where we're
>> calling read while holding the lock.
>>
> Do you have tracing enabled? When I moved this code over to use
> seqcounts it relied on the fact that the compiler wouldn't be generating
> any function calls to the tracing code. Before seqcounts got lockdep
> support it all collapsed down into sched_clock() due to the use of
> inline on the seqlock API.
Hrm. I have tracing compiled in, I'll see if disabling it avoids the issue.
If this is the problem, I'm guessing we may need to change it to use
read_seqcount_begin_no_lockdep() then.
But I still don't have a clear sense of exactly whats happening yet.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Broken terminal due to echo bufferring
http://groups.google.com/group/linux.kernel/t/7703b54a38388d29?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 11:40 am
From: Mikulas Patocka
On Wed, 18 Dec 2013, Greg Kroah-Hartman wrote:
> On Mon, Dec 09, 2013 at 10:10:50AM -0500, Mikulas Patocka wrote:
> > Hi
> >
> > Here I'm sending another version of the patch that removes some unneeded
> > code for echo bufferring - 41 lines are removed.
>
> This should now all be resolved in Linus's tree, and this patch is not
> needed, right?
You don't need this patch if you backported
1075a6e2dc7e2a96efc417b98dd98f57fdae985d.
Mikulas
> thanks,
>
> greg k-h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: at91: dt: sam9261: Added DM9000 in the device tree
http://groups.google.com/group/linux.kernel/t/b947ff38bef93f1f?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 12:10 pm
From: Arnd Bergmann
On Thursday 02 January 2014 20:31:00 Jean-Jacques Hiblot wrote:
> > If each bus interface has a fixed range of registers, you can actually
> > collapse the upper two nodes again and just have one device per
> > chipselect.
> This is indeed the case, but I'd rather keep the top node to highlight
> the fact that all the devices are physically tied to the same bus.
How about using a top-level "simple-bus" node with the complex ranges
property but making the driver match the sub-devices with the smaller
register range then?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: block/ps3: Remove obsolete reference to MTD
http://groups.google.com/group/linux.kernel/t/4b358c9e90189fdf?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 12:20 pm
From: Jens Axboe
On 01/02/2014 11:46 AM, Geoff Levand wrote:
> On Mon, 2013-12-30 at 10:07 +0100, Geert Uytterhoeven wrote:
>> The ps3vram driver is a plain block device driver since commit
>> f507cd22035fdadd5dbb476dd05e9e7ee21c3b84 ("ps3/block: Replace mtd/ps3vram
>> by block/ps3vram").
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> ---
>> drivers/block/ps3vram.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
>> index 06a2e53e5f37..313ee641ea10 100644
>> --- a/drivers/block/ps3vram.c
>> +++ b/drivers/block/ps3vram.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * ps3vram - Use extra PS3 video ram as MTD block device.
>> + * ps3vram - Use extra PS3 video ram as block device.
>> *
>> * Copyright 2009 Sony Corporation
>> *
>
> Looks good.
>
> Jens, could you please apply.
>
> Acked-by: Geoff Levand <geoff@infradead.org>
Yup will do, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Kconfig: collapse initrd in to own menu
http://groups.google.com/group/linux.kernel/t/196ce794be2da521?hl=en
==============================================================================
== 1 of 5 ==
Date: Thurs, Jan 2 2014 12:30 pm
From: Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
Initrd support takes up 8 lines of space in the general menu,
pushing down options like OProfile or the VM event counters.
Stick it in its own menu to trim it down.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
linux.git-davehans/init/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN init/Kconfig~kconfig-initrd-collapse-in-to-menu init/Kconfig
--- linux.git/init/Kconfig~kconfig-initrd-collapse-in-to-menu 2014-01-02 11:23:59.008804083 -0800
+++ linux.git-davehans/init/Kconfig 2014-01-02 11:23:59.011804218 -0800
@@ -1223,7 +1223,7 @@ config RELAY
If unsure, say N.
-config BLK_DEV_INITRD
+menuconfig BLK_DEV_INITRD
bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
depends on BROKEN || !FRV
help
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 5 ==
Date: Thurs, Jan 2 2014 12:30 pm
From: Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
There are 7 architecures with "config SECCOMP". They all have
virtually the same help text except for those referencing the
/proc interface which was removed in 2007.
There is *NOTHING* architecture-specific about SECCOMP except
that the syscalls have per-architecture definitions, like every
other syscall. It is absurd to have the option in the
arch-specific menus.
Move it to the security menu, consolidate the 7 down to one,
and remove the embarassingly-ancient references to the /proc
interface.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-security-module@vger.kernel.org
Cc: linux-arch@vger.kernel.org
---
linux.git-davehans/arch/arm/Kconfig | 15 +--------------
linux.git-davehans/arch/microblaze/Kconfig | 18 +-----------------
linux.git-davehans/arch/mips/Kconfig | 18 +-----------------
linux.git-davehans/arch/powerpc/Kconfig | 18 +-----------------
linux.git-davehans/arch/s390/Kconfig | 18 +-----------------
linux.git-davehans/arch/sh/Kconfig | 17 +----------------
linux.git-davehans/arch/sparc/Kconfig | 18 +-----------------
linux.git-davehans/arch/x86/Kconfig | 17 +----------------
linux.git-davehans/security/Kconfig | 21 ++++++++++++++++++++-
9 files changed, 28 insertions(+), 132 deletions(-)
diff -puN arch/arm/Kconfig~consolidate-seccomp-options arch/arm/Kconfig
--- linux.git/arch/arm/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.590785275 -0800
+++ linux.git-davehans/arch/arm/Kconfig 2014-01-02 11:23:58.609786130 -0800
@@ -26,6 +26,7 @@ config ARM
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
+ select HAVE_ARCH_SECCOMP
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
select HAVE_CONTEXT_TRACKING
@@ -1842,20 +1843,6 @@ config UACCESS_WITH_MEMCPY
However, if the CPU data cache is using a write-allocate mode,
this option is unlikely to provide any performance gain.
-config SECCOMP
- bool
- prompt "Enable seccomp to safely compute untrusted bytecode"
- ---help---
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
config CC_STACKPROTECTOR
bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
help
diff -puN arch/microblaze/Kconfig~consolidate-seccomp-options arch/microblaze/Kconfig
--- linux.git/arch/microblaze/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.592785365 -0800
+++ linux.git-davehans/arch/microblaze/Kconfig 2014-01-02 11:23:58.609786130 -0800
@@ -11,6 +11,7 @@ config MICROBLAZE
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_OPROFILE
select HAVE_ARCH_KGDB
+ select HAVE_ARCH_SECCOMP
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select TRACING_SUPPORT
@@ -106,23 +107,6 @@ config CMDLINE_FORCE
Set this to have arguments from the default kernel command string
override those passed by the boot loader.
-config SECCOMP
- bool "Enable seccomp to safely compute untrusted bytecode"
- depends on PROC_FS
- default y
- help
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via /proc/<pid>/seccomp, it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
- If unsure, say Y. Only embedded should say N here.
-
endmenu
menu "Advanced setup"
diff -puN arch/mips/Kconfig~consolidate-seccomp-options arch/mips/Kconfig
--- linux.git/arch/mips/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.594785455 -0800
+++ linux.git-davehans/arch/mips/Kconfig 2014-01-02 11:23:58.610786175 -0800
@@ -10,6 +10,7 @@ config MIPS
select PERF_USE_VMALLOC
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_SECCOMP
select ARCH_HAVE_CUSTOM_GPIO_H
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_TRACE_MCOUNT_TEST
@@ -2305,23 +2306,6 @@ config PHYSICAL_START
specified in the "crashkernel=YM@XM" command line boot parameter
passed to the panic-ed kernel).
-config SECCOMP
- bool "Enable seccomp to safely compute untrusted bytecode"
- depends on PROC_FS
- default y
- help
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via /proc/<pid>/seccomp, it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
- If unsure, say Y. Only embedded should say N here.
-
config CC_STACKPROTECTOR
bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
help
diff -puN arch/powerpc/Kconfig~consolidate-seccomp-options arch/powerpc/Kconfig
--- linux.git/arch/powerpc/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.596785545 -0800
+++ linux.git-davehans/arch/powerpc/Kconfig 2014-01-02 11:23:58.611786220 -0800
@@ -101,6 +101,7 @@ config PPC
select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_LITTLE_ENDIAN
select HAVE_KPROBES
select HAVE_ARCH_KGDB
+ select HAVE_ARCH_SECCOMP
select HAVE_KRETPROBES
select HAVE_ARCH_TRACEHOOK
select HAVE_MEMBLOCK
@@ -626,23 +627,6 @@ config ARCH_WANTS_FREEZER_CONTROL
source kernel/power/Kconfig
-config SECCOMP
- bool "Enable seccomp to safely compute untrusted bytecode"
- depends on PROC_FS
- default y
- help
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via /proc/<pid>/seccomp, it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
- If unsure, say Y. Only embedded should say N here.
-
endmenu
config ISA_DMA_API
diff -puN arch/s390/Kconfig~consolidate-seccomp-options arch/s390/Kconfig
--- linux.git/arch/s390/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.597785590 -0800
+++ linux.git-davehans/arch/s390/Kconfig 2014-01-02 11:23:58.611786220 -0800
@@ -105,6 +105,7 @@ config S390
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_ARCH_JUMP_LABEL if !MARCH_G5
select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_SECCOMP
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT
select HAVE_BPF_JIT if 64BIT && PACK_STACK
@@ -608,23 +609,6 @@ menu "Executable file formats / Emulatio
source "fs/Kconfig.binfmt"
-config SECCOMP
- def_bool y
- prompt "Enable seccomp to safely compute untrusted bytecode"
- depends on PROC_FS
- help
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via /proc/<pid>/seccomp, it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
- If unsure, say Y.
-
endmenu
menu "Power Management"
diff -puN arch/sh/Kconfig~consolidate-seccomp-options arch/sh/Kconfig
--- linux.git/arch/sh/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.599785680 -0800
+++ linux.git-davehans/arch/sh/Kconfig 2014-01-02 11:23:58.612786265 -0800
@@ -10,6 +10,7 @@ config SUPERH
select HAVE_OPROFILE
select HAVE_GENERIC_DMA_COHERENT
select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_SECCOMP
select HAVE_DMA_API_DEBUG
select HAVE_DMA_ATTRS
select HAVE_PERF_EVENTS
@@ -679,22 +680,6 @@ config PHYSICAL_START
where the fail safe kernel needs to run at a different address
than the panic-ed kernel.
-config SECCOMP
- bool "Enable seccomp to safely compute untrusted bytecode"
- depends on PROC_FS
- help
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via prctl, it cannot be disabled and the task is only
- allowed to execute a few safe syscalls defined by each seccomp
- mode.
-
- If unsure, say N.
-
config CC_STACKPROTECTOR
bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
depends on SUPERH32
diff -puN arch/sparc/Kconfig~consolidate-seccomp-options arch/sparc/Kconfig
--- linux.git/arch/sparc/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.601785770 -0800
+++ linux.git-davehans/arch/sparc/Kconfig 2014-01-02 11:23:58.612786265 -0800
@@ -66,6 +66,7 @@ config SPARC64
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_CONTEXT_TRACKING
select HAVE_DEBUG_KMEMLEAK
+ select HAVE_ARCH_SECCOMP if PROC_FS
select RTC_DRV_CMOS
select RTC_DRV_BQ4802
select RTC_DRV_SUN4V
@@ -222,23 +223,6 @@ config EARLYFB
help
Say Y here to enable a faster early framebuffer boot console.
-config SECCOMP
- bool "Enable seccomp to safely compute untrusted bytecode"
- depends on SPARC64 && PROC_FS
- default y
- help
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via /proc/<pid>/seccomp, it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
- If unsure, say Y. Only embedded should say N here.
-
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SPARC64 && SMP
diff -puN arch/x86/Kconfig~consolidate-seccomp-options arch/x86/Kconfig
--- linux.git/arch/x86/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.603785860 -0800
+++ linux.git-davehans/arch/x86/Kconfig 2014-01-02 11:23:58.614786355 -0800
@@ -101,6 +101,7 @@ config X86
select GENERIC_SMP_IDLE_THREAD
select ARCH_WANT_IPC_PARSE_VERSION if X86_32
select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_SECCOMP
select BUILDTIME_EXTABLE_SORT
select GENERIC_CMOS_UPDATE
select HAVE_ARCH_SOFT_DIRTY
@@ -1601,22 +1602,6 @@ config EFI_STUB
See Documentation/efi-stub.txt for more information.
-config SECCOMP
- def_bool y
- prompt "Enable seccomp to safely compute untrusted bytecode"
- ---help---
- This kernel feature is useful for number crunching applications
- that may need to compute untrusted bytecode during their
- execution. By using pipes or other transports made available to
- the process as file descriptors supporting the read/write
- syscalls, it's possible to isolate those applications in
- their own address space using seccomp. Once seccomp is
- enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
- and the task is only allowed to execute a few safe syscalls
- defined by each seccomp mode.
-
- If unsure, say Y. Only embedded should say N here.
-
config CC_STACKPROTECTOR
bool "Enable -fstack-protector buffer overflow detection"
---help---
diff -puN security/Kconfig~consolidate-seccomp-options security/Kconfig
--- linux.git/security/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.604785905 -0800
+++ linux.git-davehans/security/Kconfig 2014-01-02 11:23:58.614786355 -0800
@@ -167,5 +167,24 @@ config DEFAULT_SECURITY
default "yama" if DEFAULT_SECURITY_YAMA
default "" if DEFAULT_SECURITY_DAC
-endmenu
+config HAVE_ARCH_SECCOMP
+ bool
+
+config SECCOMP
+ bool
+ default y
+ prompt "Enable seccomp to safely compute untrusted bytecode"
+ ---help---
+ This kernel feature is useful for number crunching applications
+ that may need to compute untrusted bytecode during their
+ execution. By using pipes or other transports made available to
+ the process as file descriptors supporting the read/write
+ syscalls, it's possible to isolate those applications in
+ their own address space using seccomp. Once seccomp is
+ enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
+ and the task is only allowed to execute a few safe syscalls
+ defined by each seccomp mode.
+ If unsure, say Y. Only embedded should say N here.
+
+endmenu
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 3 of 5 ==
Date: Thurs, Jan 2 2014 12:30 pm
From: Dave Hansen
From: Dave Hansen <dave.hansen@linux.intel.com>
This continues in a series of patches to clean up the
configuration menus. I believe they've become really hard to
navigate and there are some simple things we can do to make
things easier to find.
This creates a "Memory Options" menu and moves some things like
swap and slab configuration under them. It also moves SLUB_DEBUG
to the debugging menu.
After this patch, the menu has the following options:
[ ] Memory placement aware NUMA scheduler
[*] Enable VM event counters for /proc/vmstat
[ ] Disable heap randomization
[*] Support for paging of anonymous memory (swap)
Choose SLAB allocator (SLUB (Unqueued Allocator))
[*] SLUB per cpu partial cache
[*] SLUB: attempt to use double-cmpxchg operations
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
---
linux.git-davehans/init/Kconfig | 243 ++++++++++++++++++------------------
linux.git-davehans/mm/Kconfig.debug | 11 +
2 files changed, 135 insertions(+), 119 deletions(-)
diff -puN init/Kconfig~organize-memory-config-options init/Kconfig
--- linux.git/init/Kconfig~organize-memory-config-options 2014-01-02 11:24:20.925790194 -0800
+++ linux.git-davehans/init/Kconfig 2014-01-02 11:24:20.931790464 -0800
@@ -208,16 +208,6 @@ config DEFAULT_HOSTNAME
but you may wish to use a different default here to make a minimal
system more usable with less configuration.
-config SWAP
- bool "Support for paging of anonymous memory (swap)"
- depends on MMU && BLOCK
- default y
- help
- This option allows you to choose whether you want to have support
- for so called swap devices or swap files in your kernel that are
- used to provide more virtual memory than the actual RAM present
- in your computer. If unsure say Y.
-
config SYSVIPC
bool "System V IPC"
---help---
@@ -760,6 +750,130 @@ endchoice
endmenu # "RCU Subsystem"
+menu "Memory Options"
+
+config NUMA_BALANCING
+ bool "Memory placement aware NUMA scheduler"
+ depends on ARCH_SUPPORTS_NUMA_BALANCING
+ depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
+ depends on SMP && NUMA && MIGRATION
+ help
+ This option adds support for automatic NUMA aware memory/task placement.
+ The mechanism is quite primitive and is based on migrating memory when
+ it has references to the node the task is running on.
+
+ This system will be inactive on UMA systems.
+
+config VM_EVENT_COUNTERS
+ default y
+ bool "Enable VM event counters for /proc/vmstat" if EXPERT
+ help
+ VM event counters are needed for event counts to be shown.
+ This option allows the disabling of the VM event counters
+ on EXPERT systems. /proc/vmstat will only show page counts
+ if VM event counters are disabled.
+
+config COMPAT_BRK
+ bool "Disable heap randomization"
+ default y
+ help
+ Randomizing heap placement makes heap exploits harder, but it
+ also breaks ancient binaries (including anything libc5 based).
+ This option changes the bootup default to heap randomization
+ disabled, and can be overridden at runtime by setting
+ /proc/sys/kernel/randomize_va_space to 2.
+
+ On non-ancient distros (post-2000 ones) N is usually a safe choice.
+
+config SWAP
+ bool "Support for paging of anonymous memory (swap)"
+ depends on MMU && BLOCK
+ default y
+ help
+ This option allows you to choose whether you want to have support
+ for so called swap devices or swap files in your kernel that are
+ used to provide more virtual memory than the actual RAM present
+ in your computer. If unsure say Y.
+
+choice
+ prompt "Choose SLAB allocator"
+ default SLUB
+ help
+ This option allows to select a slab allocator.
+
+config SLAB
+ bool "SLAB"
+ help
+ The regular slab allocator that is established and known to work
+ well in all environments. It organizes cache hot objects in
+ per cpu and per node queues.
+
+config SLUB
+ bool "SLUB (Unqueued Allocator)"
+ help
+ SLUB is a slab allocator that minimizes cache line usage
+ instead of managing queues of cached objects (SLAB approach).
+ Per cpu caching is realized using slabs of objects instead
+ of queues of objects. SLUB can use memory efficiently
+ and has enhanced diagnostics. SLUB is the default choice for
+ a slab allocator.
+
+config SLOB
+ depends on EXPERT
+ bool "SLOB (Simple Allocator)"
+ help
+ SLOB replaces the stock allocator with a drastically simpler
+ allocator. SLOB is generally more space efficient but
+ does not perform as well on large systems.
+
+endchoice
+
+config SLUB_CPU_PARTIAL
+ default y
+ depends on SLUB && SMP
+ bool "SLUB per cpu partial cache"
+ help
+ Per cpu partial caches accellerate objects allocation and freeing
+ that is local to a processor at the price of more indeterminism
+ in the latency of the free. On overflow these caches will be cleared
+ which requires the taking of locks that may cause latency spikes.
+ Typically one would choose no for a realtime system.
+
+config SLUB_ATTEMPT_CMPXCHG_DOUBLE
+ default y
+ depends on SLUB && HAVE_CMPXCHG_DOUBLE
+ bool "SLUB: attempt to use double-cmpxchg operations"
+ help
+ Some CPUs support instructions that let you do a large double-word
+ atomic cmpxchg operation. This keeps the SLUB fastpath from
+ needing to disable interrupts.
+
+ If you are unsure, say y.
+
+config MMAP_ALLOW_UNINITIALIZED
+ bool "Allow mmapped anonymous memory to be uninitialized"
+ depends on EXPERT && !MMU
+ default n
+ help
+ Normally, and according to the Linux spec, anonymous memory obtained
+ from mmap() has it's contents cleared before it is passed to
+ userspace. Enabling this config option allows you to request that
+ mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
+ providing a huge performance boost. If this option is not enabled,
+ then the flag will be ignored.
+
+ This is taken advantage of by uClibc's malloc(), and also by
+ ELF-FDPIC binfmt's brk and stack allocator.
+
+ Because of the obvious security issues, this option should only be
+ enabled on embedded devices where you control what is run in
+ userspace. Since that isn't generally a problem on no-MMU systems,
+ it is normally safe to say Y here.
+
+ See Documentation/nommu-mmap.txt for more information.
+
+endmenu # "Memory Optionse
+
config IKCONFIG
tristate "Kernel .config support"
---help---
@@ -840,18 +954,6 @@ config NUMA_BALANCING_DEFAULT_ENABLED
If set, automatic NUMA balancing will be enabled if running on a NUMA
machine.
-config NUMA_BALANCING
- bool "Memory placement aware NUMA scheduler"
- depends on ARCH_SUPPORTS_NUMA_BALANCING
- depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
- depends on SMP && NUMA && MIGRATION
- help
- This option adds support for automatic NUMA aware memory/task placement.
- The mechanism is quite primitive and is based on migrating memory when
- it has references to the node the task is running on.
-
- This system will be inactive on UMA systems.
-
menuconfig CGROUPS
boolean "Control Group support"
depends on EVENTFD
@@ -1529,103 +1631,6 @@ config DEBUG_PERF_USE_VMALLOC
endmenu
-config VM_EVENT_COUNTERS
- default y
- bool "Enable VM event counters for /proc/vmstat" if EXPERT
- help
- VM event counters are needed for event counts to be shown.
- This option allows the disabling of the VM event counters
- on EXPERT systems. /proc/vmstat will only show page counts
- if VM event counters are disabled.
-
-config SLUB_DEBUG
- default y
- bool "Enable SLUB debugging support" if EXPERT
- depends on SLUB && SYSFS
- help
- SLUB has extensive debug support features. Disabling these can
- result in significant savings in code size. This also disables
- SLUB sysfs support. /sys/slab will not exist and there will be
- no support for cache validation etc.
-
-config COMPAT_BRK
- bool "Disable heap randomization"
- default y
- help
- Randomizing heap placement makes heap exploits harder, but it
- also breaks ancient binaries (including anything libc5 based).
- This option changes the bootup default to heap randomization
- disabled, and can be overridden at runtime by setting
- /proc/sys/kernel/randomize_va_space to 2.
-
- On non-ancient distros (post-2000 ones) N is usually a safe choice.
-
-choice
- prompt "Choose SLAB allocator"
- default SLUB
- help
- This option allows to select a slab allocator.
-
-config SLAB
- bool "SLAB"
- help
- The regular slab allocator that is established and known to work
- well in all environments. It organizes cache hot objects in
- per cpu and per node queues.
-
-config SLUB
- bool "SLUB (Unqueued Allocator)"
- help
- SLUB is a slab allocator that minimizes cache line usage
- instead of managing queues of cached objects (SLAB approach).
- Per cpu caching is realized using slabs of objects instead
- of queues of objects. SLUB can use memory efficiently
- and has enhanced diagnostics. SLUB is the default choice for
- a slab allocator.
-
-config SLOB
- depends on EXPERT
- bool "SLOB (Simple Allocator)"
- help
- SLOB replaces the stock allocator with a drastically simpler
- allocator. SLOB is generally more space efficient but
- does not perform as well on large systems.
-
-endchoice
-
-config SLUB_CPU_PARTIAL
- default y
- depends on SLUB && SMP
- bool "SLUB per cpu partial cache"
- help
- Per cpu partial caches accellerate objects allocation and freeing
- that is local to a processor at the price of more indeterminism
- in the latency of the free. On overflow these caches will be cleared
- which requires the taking of locks that may cause latency spikes.
- Typically one would choose no for a realtime system.
-
-config MMAP_ALLOW_UNINITIALIZED
- bool "Allow mmapped anonymous memory to be uninitialized"
- depends on EXPERT && !MMU
- default n
- help
- Normally, and according to the Linux spec, anonymous memory obtained
- from mmap() has it's contents cleared before it is passed to
- userspace. Enabling this config option allows you to request that
- mmap() skip that if it is given an MAP_UNINITIALIZED flag, thus
- providing a huge performance boost. If this option is not enabled,
- then the flag will be ignored.
-
- This is taken advantage of by uClibc's malloc(), and also by
- ELF-FDPIC binfmt's brk and stack allocator.
-
- Because of the obvious security issues, this option should only be
- enabled on embedded devices where you control what is run in
- userspace. Since that isn't generally a problem on no-MMU systems,
- it is normally safe to say Y here.
-
- See Documentation/nommu-mmap.txt for more information.
-
config PROFILING
bool "Profiling support"
help
diff -puN mm/Kconfig.debug~organize-memory-config-options mm/Kconfig.debug
--- linux.git/mm/Kconfig.debug~organize-memory-config-options 2014-01-02 11:24:20.927790284 -0800
+++ linux.git-davehans/mm/Kconfig.debug 2014-01-02 11:24:20.931790464 -0800
@@ -27,3 +27,14 @@ config PAGE_POISONING
config PAGE_GUARD
bool
select WANT_PAGE_DEBUG_FLAGS
+
+config SLUB_DEBUG
+ default y
+ bool "Enable SLUB debugging support" if EXPERT
+ depends on SLUB && SYSFS
+ help
+ SLUB has extensive debug support features. Disabling these can
+ result in significant savings in code size. This also disables
+ SLUB sysfs support. /sys/slab will not exist and there will be
+ no support for cache validation etc.
+
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 4 of 5 ==
Date: Thurs, Jan 2 2014 1:10 pm
From: Mimi Zohar
On Thu, 2014-01-02 at 12:20 -0800, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> There are 7 architecures with "config SECCOMP". They all have
> virtually the same help text except for those referencing the
> /proc interface which was removed in 2007.
>
> There is *NOTHING* architecture-specific about SECCOMP except
> that the syscalls have per-architecture definitions, like every
> other syscall. It is absurd to have the option in the
> arch-specific menus.
>
> Move it to the security menu, consolidate the 7 down to one,
> and remove the embarassingly-ancient references to the /proc
> interface.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: linux-security-module@vger.kernel.org
> Cc: linux-arch@vger.kernel.org
> ---
>
> linux.git-davehans/arch/arm/Kconfig | 15 +--------------
> linux.git-davehans/arch/microblaze/Kconfig | 18 +-----------------
> linux.git-davehans/arch/mips/Kconfig | 18 +-----------------
> linux.git-davehans/arch/powerpc/Kconfig | 18 +-----------------
> linux.git-davehans/arch/s390/Kconfig | 18 +-----------------
> linux.git-davehans/arch/sh/Kconfig | 17 +----------------
> linux.git-davehans/arch/sparc/Kconfig | 18 +-----------------
> linux.git-davehans/arch/x86/Kconfig | 17 +----------------
> linux.git-davehans/security/Kconfig | 21 ++++++++++++++++++++-
> 9 files changed, 28 insertions(+), 132 deletions(-)
>
> diff -puN arch/arm/Kconfig~consolidate-seccomp-options arch/arm/Kconfig
> --- linux.git/arch/arm/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.590785275 -0800
> +++ linux.git-davehans/arch/arm/Kconfig 2014-01-02 11:23:58.609786130 -0800
> @@ -26,6 +26,7 @@ config ARM
> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
> + select HAVE_ARCH_SECCOMP
> select HAVE_ARCH_TRACEHOOK
> select HAVE_BPF_JIT
> select HAVE_CONTEXT_TRACKING
> @@ -1842,20 +1843,6 @@ config UACCESS_WITH_MEMCPY
> However, if the CPU data cache is using a write-allocate mode,
> this option is unlikely to provide any performance gain.
>
> -config SECCOMP
> - bool
> - prompt "Enable seccomp to safely compute untrusted bytecode"
> - ---help---
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> config CC_STACKPROTECTOR
> bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
> help
> diff -puN arch/microblaze/Kconfig~consolidate-seccomp-options arch/microblaze/Kconfig
> --- linux.git/arch/microblaze/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.592785365 -0800
> +++ linux.git-davehans/arch/microblaze/Kconfig 2014-01-02 11:23:58.609786130 -0800
> @@ -11,6 +11,7 @@ config MICROBLAZE
> select ARCH_WANT_OPTIONAL_GPIOLIB
> select HAVE_OPROFILE
> select HAVE_ARCH_KGDB
> + select HAVE_ARCH_SECCOMP
> select HAVE_DMA_ATTRS
> select HAVE_DMA_API_DEBUG
> select TRACING_SUPPORT
> @@ -106,23 +107,6 @@ config CMDLINE_FORCE
> Set this to have arguments from the default kernel command string
> override those passed by the boot loader.
>
> -config SECCOMP
> - bool "Enable seccomp to safely compute untrusted bytecode"
> - depends on PROC_FS
> - default y
> - help
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via /proc/<pid>/seccomp, it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> - If unsure, say Y. Only embedded should say N here.
> -
> endmenu
>
> menu "Advanced setup"
> diff -puN arch/mips/Kconfig~consolidate-seccomp-options arch/mips/Kconfig
> --- linux.git/arch/mips/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.594785455 -0800
> +++ linux.git-davehans/arch/mips/Kconfig 2014-01-02 11:23:58.610786175 -0800
> @@ -10,6 +10,7 @@ config MIPS
> select PERF_USE_VMALLOC
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_TRACEHOOK
> + select HAVE_ARCH_SECCOMP
> select ARCH_HAVE_CUSTOM_GPIO_H
> select HAVE_FUNCTION_TRACER
> select HAVE_FUNCTION_TRACE_MCOUNT_TEST
> @@ -2305,23 +2306,6 @@ config PHYSICAL_START
> specified in the "crashkernel=YM@XM" command line boot parameter
> passed to the panic-ed kernel).
>
> -config SECCOMP
> - bool "Enable seccomp to safely compute untrusted bytecode"
> - depends on PROC_FS
> - default y
> - help
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via /proc/<pid>/seccomp, it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> - If unsure, say Y. Only embedded should say N here.
> -
> config CC_STACKPROTECTOR
> bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
> help
> diff -puN arch/powerpc/Kconfig~consolidate-seccomp-options arch/powerpc/Kconfig
> --- linux.git/arch/powerpc/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.596785545 -0800
> +++ linux.git-davehans/arch/powerpc/Kconfig 2014-01-02 11:23:58.611786220 -0800
> @@ -101,6 +101,7 @@ config PPC
> select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_LITTLE_ENDIAN
> select HAVE_KPROBES
> select HAVE_ARCH_KGDB
> + select HAVE_ARCH_SECCOMP
> select HAVE_KRETPROBES
> select HAVE_ARCH_TRACEHOOK
> select HAVE_MEMBLOCK
> @@ -626,23 +627,6 @@ config ARCH_WANTS_FREEZER_CONTROL
>
> source kernel/power/Kconfig
>
> -config SECCOMP
> - bool "Enable seccomp to safely compute untrusted bytecode"
> - depends on PROC_FS
> - default y
> - help
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via /proc/<pid>/seccomp, it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> - If unsure, say Y. Only embedded should say N here.
> -
> endmenu
>
> config ISA_DMA_API
> diff -puN arch/s390/Kconfig~consolidate-seccomp-options arch/s390/Kconfig
> --- linux.git/arch/s390/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.597785590 -0800
> +++ linux.git-davehans/arch/s390/Kconfig 2014-01-02 11:23:58.611786220 -0800
> @@ -105,6 +105,7 @@ config S390
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_JUMP_LABEL if !MARCH_G5
> select HAVE_ARCH_SECCOMP_FILTER
> + select HAVE_ARCH_SECCOMP
> select HAVE_ARCH_TRACEHOOK
> select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT
> select HAVE_BPF_JIT if 64BIT && PACK_STACK
> @@ -608,23 +609,6 @@ menu "Executable file formats / Emulatio
>
> source "fs/Kconfig.binfmt"
>
> -config SECCOMP
> - def_bool y
> - prompt "Enable seccomp to safely compute untrusted bytecode"
> - depends on PROC_FS
> - help
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via /proc/<pid>/seccomp, it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> - If unsure, say Y.
> -
> endmenu
>
> menu "Power Management"
> diff -puN arch/sh/Kconfig~consolidate-seccomp-options arch/sh/Kconfig
> --- linux.git/arch/sh/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.599785680 -0800
> +++ linux.git-davehans/arch/sh/Kconfig 2014-01-02 11:23:58.612786265 -0800
> @@ -10,6 +10,7 @@ config SUPERH
> select HAVE_OPROFILE
> select HAVE_GENERIC_DMA_COHERENT
> select HAVE_ARCH_TRACEHOOK
> + select HAVE_ARCH_SECCOMP
> select HAVE_DMA_API_DEBUG
> select HAVE_DMA_ATTRS
> select HAVE_PERF_EVENTS
> @@ -679,22 +680,6 @@ config PHYSICAL_START
> where the fail safe kernel needs to run at a different address
> than the panic-ed kernel.
>
> -config SECCOMP
> - bool "Enable seccomp to safely compute untrusted bytecode"
> - depends on PROC_FS
> - help
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via prctl, it cannot be disabled and the task is only
> - allowed to execute a few safe syscalls defined by each seccomp
> - mode.
> -
> - If unsure, say N.
> -
> config CC_STACKPROTECTOR
> bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)"
> depends on SUPERH32
> diff -puN arch/sparc/Kconfig~consolidate-seccomp-options arch/sparc/Kconfig
> --- linux.git/arch/sparc/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.601785770 -0800
> +++ linux.git-davehans/arch/sparc/Kconfig 2014-01-02 11:23:58.612786265 -0800
> @@ -66,6 +66,7 @@ config SPARC64
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_CONTEXT_TRACKING
> select HAVE_DEBUG_KMEMLEAK
> + select HAVE_ARCH_SECCOMP if PROC_FS
> select RTC_DRV_CMOS
> select RTC_DRV_BQ4802
> select RTC_DRV_SUN4V
> @@ -222,23 +223,6 @@ config EARLYFB
> help
> Say Y here to enable a faster early framebuffer boot console.
>
> -config SECCOMP
> - bool "Enable seccomp to safely compute untrusted bytecode"
> - depends on SPARC64 && PROC_FS
> - default y
> - help
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via /proc/<pid>/seccomp, it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> - If unsure, say Y. Only embedded should say N here.
> -
> config HOTPLUG_CPU
> bool "Support for hot-pluggable CPUs"
> depends on SPARC64 && SMP
> diff -puN arch/x86/Kconfig~consolidate-seccomp-options arch/x86/Kconfig
> --- linux.git/arch/x86/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.603785860 -0800
> +++ linux.git-davehans/arch/x86/Kconfig 2014-01-02 11:23:58.614786355 -0800
> @@ -101,6 +101,7 @@ config X86
> select GENERIC_SMP_IDLE_THREAD
> select ARCH_WANT_IPC_PARSE_VERSION if X86_32
> select HAVE_ARCH_SECCOMP_FILTER
> + select HAVE_ARCH_SECCOMP
> select BUILDTIME_EXTABLE_SORT
> select GENERIC_CMOS_UPDATE
> select HAVE_ARCH_SOFT_DIRTY
> @@ -1601,22 +1602,6 @@ config EFI_STUB
>
> See Documentation/efi-stub.txt for more information.
>
> -config SECCOMP
> - def_bool y
> - prompt "Enable seccomp to safely compute untrusted bytecode"
> - ---help---
> - This kernel feature is useful for number crunching applications
> - that may need to compute untrusted bytecode during their
> - execution. By using pipes or other transports made available to
> - the process as file descriptors supporting the read/write
> - syscalls, it's possible to isolate those applications in
> - their own address space using seccomp. Once seccomp is
> - enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> - and the task is only allowed to execute a few safe syscalls
> - defined by each seccomp mode.
> -
> - If unsure, say Y. Only embedded should say N here.
> -
> config CC_STACKPROTECTOR
> bool "Enable -fstack-protector buffer overflow detection"
> ---help---
> diff -puN security/Kconfig~consolidate-seccomp-options security/Kconfig
> --- linux.git/security/Kconfig~consolidate-seccomp-options 2014-01-02 11:23:58.604785905 -0800
> +++ linux.git-davehans/security/Kconfig 2014-01-02 11:23:58.614786355 -0800
> @@ -167,5 +167,24 @@ config DEFAULT_SECURITY
> default "yama" if DEFAULT_SECURITY_YAMA
> default "" if DEFAULT_SECURITY_DAC
>
> -endmenu
> +config HAVE_ARCH_SECCOMP
> + bool
> +
> +config SECCOMP
> + bool
Hi Dave,
I haven't looked at the other 'CONFIG_HAVE' options, but shouldn't
'HAVE_ARCH_SECCOMP' be dependent on 'SECCOMP'?
Mimi
> + default y
> + prompt "Enable seccomp to safely compute untrusted bytecode"
> + ---help---
> + This kernel feature is useful for number crunching applications
> + that may need to compute untrusted bytecode during their
> + execution. By using pipes or other transports made available to
> + the process as file descriptors supporting the read/write
> + syscalls, it's possible to isolate those applications in
> + their own address space using seccomp. Once seccomp is
> + enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> + and the task is only allowed to execute a few safe syscalls
> + defined by each seccomp mode.
>
> + If unsure, say Y. Only embedded should say N here.
> +
> +endmenu
> _
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 5 of 5 ==
Date: Thurs, Jan 2 2014 1:20 pm
From: Dave Hansen
On 01/02/2014 01:08 PM, Mimi Zohar wrote:
>> > +config HAVE_ARCH_SECCOMP
>> > + bool
>> > +
>> > +config SECCOMP
>> > + bool
>
> I haven't looked at the other 'CONFIG_HAVE' options, but shouldn't
> 'HAVE_ARCH_SECCOMP' be dependent on 'SECCOMP'?
Ahh, you're backwards, but right. :)
I forgot to make sure that SECCOMP depends on the architecture option
being set. Fixed patch is attached.
==============================================================================
TOPIC: tty: serial: Limit msm_serial_hs driver to platforms that use it
http://groups.google.com/group/linux.kernel/t/78640313ea9bd094?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Jan 2 2014 12:30 pm
From: Arnd Bergmann
On Thursday 02 January 2014 12:20:21 Stephen Boyd wrote:
> Yes, we plan to add the code for dma based serial devices into the
> msm_serial.c driver. In the process we'll use the linux DMA apis instead
> of using mach specific ones.
Ok, very good.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Thurs, Jan 2 2014 12:30 pm
From: Stephen Boyd
On 01/02/14 10:10, Arnd Bergmann wrote:
> On Monday 30 December 2013, Stephen Boyd wrote:
>> The msm_serial_hs driver uses mach specific dma APIs. This is not
>> compatible with the multi-platform ARM effort. Let's only compile
>> this driver on MSM devices that are prepared to support it;
>> allowing the DT based MSM devices to enter the multi-platform ARM
>> build.
>>
>> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> Do you have a plan to deal with this in the future? Aren't you going
> to need it in the future on modern SoCs?
>
Yes, we plan to add the code for dma based serial devices into the
msm_serial.c driver. In the process we'll use the linux DMA apis instead
of using mach specific ones.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: KVM: NULL return of kvmppc_mmu_hpte_cache_next should be handled
http://groups.google.com/group/linux.kernel/t/db8e3a5ca5f7a88a?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 12:40 pm
From: Alexander Graf
On 02.12.2013, at 11:21, Zhouyi Zhou <zhouzhouyi@gmail.com> wrote:
> NULL return of kvmppc_mmu_hpte_cache_next should be handled
>
> Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
Thanks, applied to kvm-ppc-queue.
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Memory allocator semantics
http://groups.google.com/group/linux.kernel/t/6e5ee072925a3728?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 12:40 pm
From: "Paul E. McKenney"
Hello!
From what I can see, the Linux-kernel's SLAB, SLOB, and SLUB memory
allocators would deal with the following sort of race:
A. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(gp) = r1;
CPU 1: r2 = ACCESS_ONCE(gp); if (r2) kfree(r2);
However, my guess is that this should be considered an accident of the
current implementation rather than a feature. The reason for this is
that I cannot see how you would usefully do (A) above without also allowing
(B) and (C) below, both of which look to me to be quite destructive:
B. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(shared_x) = r1;
CPU 1: r2 = ACCESS_ONCE(shared_x); if (r2) kfree(r2);
CPU 2: r3 = ACCESS_ONCE(shared_x); if (r3) kfree(r3);
This results in the memory being on two different freelists.
C. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(shared_x) = r1;
CPU 1: r2 = ACCESS_ONCE(shared_x); r2->a = 1; r2->b = 2;
CPU 2: r3 = ACCESS_ONCE(shared_x); if (r3) kfree(r3);
CPU 3: r4 = kmalloc(...); r4->s = 3; r4->t = 4;
This results in the memory being used by two different CPUs,
each of which believe that they have sole access.
But I thought I should ask the experts.
So, am I correct that kernel hackers are required to avoid "drive-by"
kfree()s of kmalloc()ed memory?
Thanx, Paul
PS. To the question "Why would anyone care about (A)?", then answer
is "Inquiring programming-language memory-model designers want
to know."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: kexec: A new system call, kexec_file_load, for in kernel kexec
http://groups.google.com/group/linux.kernel/t/a236ab808c9846df?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Jan 2 2014 12:40 pm
From: Vivek Goyal
On Fri, Dec 20, 2013 at 03:20:16PM -0800, Kees Cook wrote:
> On Fri, Dec 20, 2013 at 3:11 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> >
> >> On Thu, Dec 19, 2013 at 01:54:39PM +0100, Torsten Duwe wrote:
> >>> On Tue, Nov 26, 2013 at 09:27:59AM -0500, Vivek Goyal wrote:
> >
> >>> IMO it's up to user land to search lists of certificates, and present
> >>> only the final chain of trust to the kernel for checking.
> >>>
> >>> ELF is the preferred format for most sane OSes and firmware, and a detached
> >>> signature would probably be simplest to check. If we have the choice,
> >>> without restrictions from braindead boot loaders, ELF should be first.
> >>> And if the pesigning isn't usable and another sig is needed anyway,
> >>> why not apply that to vmlinux(.gz) ?
> >>
> >> I have yet to look deeper into it that if we can sign elf images and
> >> just use elf loader. And can use space extract the elf image out of
> >> a bzImage and pass it to kernel.
> >>
> >> Even if it is doable, one disadvantage seemed to be that extracted
> >> elf images will have to be written to a file so thta it's file descriptor
> >> can be passed to kernel. And that assumed writable root and we chrome
> >> folks seems to have setups where root is not writable.
> >
> > In that case the chrome folks would simply have to use an ELF format
> > kernel and not a bzImage.
>
> If we're doing fd origin verification (not signatures), can't we
> continue to use a regular bzImage?
If secureboot is enabled, it enforces module signature verification. I
think similar will happen for kexec too. How would kernel know that on
a secureboot platform fd original verification will happen and it is
sufficient.
I personally want to support bzImage as well (apart from ELF) because
distributions has been shipping bzImage for a long time and I don't
want to enforce a change there because of secureboot. It is not necessary.
Right now I am thinking more about storing detached bzImage signatures
and passing those signatures to kexec system call.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Thurs, Jan 2 2014 1:00 pm
From: "H. Peter Anvin"
On 01/02/2014 12:39 PM, Vivek Goyal wrote:
>
> If secureboot is enabled, it enforces module signature verification. I
> think similar will happen for kexec too. How would kernel know that on
> a secureboot platform fd original verification will happen and it is
> sufficient.
>
> I personally want to support bzImage as well (apart from ELF) because
> distributions has been shipping bzImage for a long time and I don't
> want to enforce a change there because of secureboot. It is not necessary.
> Right now I am thinking more about storing detached bzImage signatures
> and passing those signatures to kexec system call.
>
Since the secureboot scenario probably means people will be signing
those kernels, and those kernels are going to be EFI images, that in
order to have "one kernel, one signature" there will be a desire to
support signed PE images. Yes, PE is ugly but it shouldn't be too bad.
However, it is probably one of those things that can be dealt with one
bit at a time.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Staging: rtl8188eu: Fixed coding style issues
http://groups.google.com/group/linux.kernel/t/2705bc06f1f0429f?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 12:50 pm
From: Tim Jester-Pfadt
Fixed indentation coding style issues on rtw_io.c
Signed-off-by: Tim Jester-Pfadt <t.jp@gmx.de>
---
drivers/staging/rtl8188eu/core/rtw_io.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_io.c b/drivers/staging/rtl8188eu/core/rtw_io.c
index 10c9c65..6be6c50 100644
--- a/drivers/staging/rtl8188eu/core/rtw_io.c
+++ b/drivers/staging/rtl8188eu/core/rtw_io.c
@@ -205,9 +205,9 @@ void _rtw_read_mem(struct adapter *adapter, u32 addr, u32 cnt, u8 *pmem)
_func_enter_;
if (adapter->bDriverStopped || adapter->bSurpriseRemoved) {
- RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
- ("rtw_read_mem:bDriverStopped(%d) OR bSurpriseRemoved(%d)",
- adapter->bDriverStopped, adapter->bSurpriseRemoved));
+ RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
+ ("rtw_read_mem:bDriverStopped(%d) OR bSurpriseRemoved(%d)",
+ adapter->bDriverStopped, adapter->bSurpriseRemoved));
return;
}
_read_mem = pintfhdl->io_ops._read_mem;
@@ -239,9 +239,9 @@ void _rtw_read_port(struct adapter *adapter, u32 addr, u32 cnt, u8 *pmem)
_func_enter_;
if (adapter->bDriverStopped || adapter->bSurpriseRemoved) {
- RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
- ("rtw_read_port:bDriverStopped(%d) OR bSurpriseRemoved(%d)",
- adapter->bDriverStopped, adapter->bSurpriseRemoved));
+ RT_TRACE(_module_rtl871x_io_c_, _drv_info_,
+ ("rtw_read_port:bDriverStopped(%d) OR bSurpriseRemoved(%d)",
+ adapter->bDriverStopped, adapter->bSurpriseRemoved));
return;
}
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: tracing/uprobes: Add support for full argument access methods
http://groups.google.com/group/linux.kernel/t/f41aaed2c446cfa8?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Jan 2 2014 1:00 pm
From: Steven Rostedt
On Mon, 16 Dec 2013 13:32:14 +0900
Namhyung Kim <namhyung@kernel.org> wrote:
> From: Namhyung Kim <namhyung.kim@lge.com>
>
> Enable to fetch other types of argument for the uprobes. IOW, we can
> access stack, memory, deref, bitfield and retval from uprobes now.
>
> The format for the argument types are same as kprobes (but @SYMBOL
> type is not supported for uprobes), i.e:
>
> @ADDR : Fetch memory at ADDR
> $stackN : Fetch Nth entry of stack (N >= 0)
> $stack : Fetch stack address
> $retval : Fetch return value
> +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address
>
> Note that the retval only can be used with uretprobes.
>
> Original-patch-by: Hyeoncheol Lee <cheol.lee@lge.com>
Where was the original patch posted? And can we get Hyeoncheol's SOB for
this?
Thanks!
-- Steve
> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> Documentation/trace/uprobetracer.txt | 25 +++++++++++++++++++++++++
> kernel/trace/trace_probe.c | 34 ++++++++++++++++++++++------------
> 2 files changed, 47 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt
> index 8f1a8b8956fc..6e5cff263e2b 100644
> --- a/Documentation/trace/uprobetracer.txt
> +++ b/Documentation/trace/uprobetracer.txt
> @@ -31,6 +31,31 @@ Synopsis of uprobe_tracer
>
> FETCHARGS : Arguments. Each probe can have up to 128 args.
> %REG : Fetch register REG
> + @ADDR : Fetch memory at ADDR (ADDR should be in userspace)
> + $stackN : Fetch Nth entry of stack (N >= 0)
> + $stack : Fetch stack address.
> + $retval : Fetch return value.(*)
> + +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
> + NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
> + FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
> + (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield
> + are supported.
> +
> + (*) only for return probe.
> + (**) this is useful for fetching a field of data structures.
> +
> +Types
> +-----
> +Several types are supported for fetch-args. Uprobe tracer will access memory
> +by given type. Prefix 's' and 'u' means those types are signed and unsigned
> +respectively. Traced arguments are shown in decimal (signed) or hex (unsigned).
> +String type is a special type, which fetches a "null-terminated" string from
> +user space.
> +Bitfield is another special type, which takes 3 parameters, bit-width, bit-
> +offset, and container-size (usually 32). The syntax is;
> +
> + b<bit-width>@<bit-offset>/<container-size>
> +
>
> Event Profiling
> ---------------
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index 8f7a2b6d389d..a130d612e705 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -255,12 +255,18 @@ fail:
> }
>
> /* Special function : only accept unsigned long */
> -static __kprobes void fetch_stack_address(struct pt_regs *regs,
> - void *dummy, void *dest)
> +static __kprobes void fetch_kernel_stack_address(struct pt_regs *regs,
> + void *dummy, void *dest)
> {
> *(unsigned long *)dest = kernel_stack_pointer(regs);
> }
>
> +static __kprobes void fetch_user_stack_address(struct pt_regs *regs,
> + void *dummy, void *dest)
> +{
> + *(unsigned long *)dest = user_stack_pointer(regs);
> +}
> +
> static fetch_func_t get_fetch_size_function(const struct fetch_type *type,
> fetch_func_t orig_fn,
> const struct fetch_type *ftbl)
> @@ -305,7 +311,8 @@ int traceprobe_split_symbol_offset(char *symbol, unsigned long *offset)
> #define PARAM_MAX_STACK (THREAD_SIZE / sizeof(unsigned long))
>
> static int parse_probe_vars(char *arg, const struct fetch_type *t,
> - struct fetch_param *f, bool is_return)
> + struct fetch_param *f, bool is_return,
> + bool is_kprobe)
> {
> int ret = 0;
> unsigned long param;
> @@ -317,13 +324,16 @@ static int parse_probe_vars(char *arg, const struct fetch_type *t,
> ret = -EINVAL;
> } else if (strncmp(arg, "stack", 5) == 0) {
> if (arg[5] == '\0') {
> - if (strcmp(t->name, DEFAULT_FETCH_TYPE_STR) == 0)
> - f->fn = fetch_stack_address;
> + if (strcmp(t->name, DEFAULT_FETCH_TYPE_STR))
> + return -EINVAL;
> +
> + if (is_kprobe)
> + f->fn = fetch_kernel_stack_address;
> else
> - ret = -EINVAL;
> + f->fn = fetch_user_stack_address;
> } else if (isdigit(arg[5])) {
> ret = kstrtoul(arg + 5, 10, ¶m);
> - if (ret || param > PARAM_MAX_STACK)
> + if (ret || (is_kprobe && param > PARAM_MAX_STACK))
> ret = -EINVAL;
> else {
> f->fn = t->fetch[FETCH_MTD_stack];
> @@ -350,13 +360,9 @@ static int parse_probe_arg(char *arg, const struct fetch_type *t,
> ftbl = is_kprobe ? kprobes_fetch_type_table : uprobes_fetch_type_table;
> BUG_ON(ftbl == NULL);
>
> - /* Until uprobe_events supports only reg arguments */
> - if (!is_kprobe && arg[0] != '%')
> - return -EINVAL;
> -
> switch (arg[0]) {
> case '$':
> - ret = parse_probe_vars(arg + 1, t, f, is_return);
> + ret = parse_probe_vars(arg + 1, t, f, is_return, is_kprobe);
> break;
>
> case '%': /* named register */
> @@ -377,6 +383,10 @@ static int parse_probe_arg(char *arg, const struct fetch_type *t,
> f->fn = t->fetch[FETCH_MTD_memory];
> f->data = (void *)param;
> } else {
> + /* uprobes don't support symbols */
> + if (!is_kprobe)
> + return -EINVAL;
> +
> ret = traceprobe_split_symbol_offset(arg + 1, &offset);
> if (ret)
> break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Thurs, Jan 2 2014 1:10 pm
From: Steven Rostedt
On Thu, 2 Jan 2014 15:58:27 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 16 Dec 2013 13:32:14 +0900
> Namhyung Kim <namhyung@kernel.org> wrote:
>
> > From: Namhyung Kim <namhyung.kim@lge.com>
> >
> > Enable to fetch other types of argument for the uprobes. IOW, we can
> > access stack, memory, deref, bitfield and retval from uprobes now.
> >
> > The format for the argument types are same as kprobes (but @SYMBOL
> > type is not supported for uprobes), i.e:
> >
> > @ADDR : Fetch memory at ADDR
> > $stackN : Fetch Nth entry of stack (N >= 0)
> > $stack : Fetch stack address
> > $retval : Fetch return value
> > +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address
> >
> > Note that the retval only can be used with uretprobes.
> >
> > Original-patch-by: Hyeoncheol Lee <cheol.lee@lge.com>
>
> Where was the original patch posted? And can we get Hyeoncheol's SOB for
> this?
>
Was this the other part of patch 11? Still should have Hyeoncheol's
signed-off-by. If you already had it on the original (before the split)
then we can add it here too, as he already signed off on the code that
this was based on.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: futex: Avoid taking hb lock if nothing to wakeup
http://groups.google.com/group/linux.kernel/t/af4a2848ad48ded5?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 1:00 pm
From: Davidlohr Bueso
On Thu, 2014-01-02 at 11:23 -0800, Linus Torvalds wrote:
> On Thu, Jan 2, 2014 at 7:05 AM, Davidlohr Bueso <davidlohr@hp.com> wrote:
> >
> > In futex_wake() there is clearly no point in taking the hb->lock if we know
> > beforehand that there are no tasks to be woken.
>
> Btw, I think we could optimize this a bit further for the wakeup case.
>
> wake_futex() does a get_task_struct(p)/put_task_struct(p) around its
> actual waking logic, and I don't think that's necessary. The task
> structures are RCU-delayed, and the task cannot go away until the
> "q->lock_ptr = NULL" afaik, so you could replace that atomic inc/dec
> with just a RCU read region.
I had originally explored making the whole plist thing more rcu aware
but never got to anything worth sharing. What you say does make a lot of
sense, however, I haven't been able to see any actual improvements. It
doesn't hurt however, so I'd have no problem adding such patch to the
lot.
>
> Maybe it's not a big deal ("wake_up_state()" ends up getting the task
> struct pi_lock anyway, so it's not like we can avoid toucing the task
> structure), but I'm getting the feeling that we're doing a lot of
> unnecessary work here.
I passed this idea through my wakeup measuring program and didn't notice
hardly any difference, just noise, even for large amounts of futexes.
I believe that peterz's idea of lockless batch wakeups is the next step
worth looking into for futexes -- even though the spurious wakeup
problem can become a real pain.
Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: usb: xhci: Link TRB must not occur within a USB payload burst
http://groups.google.com/group/linux.kernel/t/02bb633f7aaf9195?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 1:10 pm
From: Mark Lord
On 14-01-02 02:15 PM, Sarah Sharp wrote:
> On Tue, Dec 31, 2013 at 12:40:16PM -0800, walt wrote:
..
>> Unfortunately this patch causes a regression when copying large files to my
>> outboard USB3 drive. (Nothing at all to do with networking.)
>>
>> When I try to copy a large (20GB) file to the USB3 drive, the copy dies after
>> about 7GB, the ext4 journal aborts and the drive is remounted read-only.
>>
>> This bug is 100% reproducible (always pretty close to 7GB) and reverting this
>> patch completely fixes the problem.
>
> Ok, I had feared that would be a consequence of this patch. I think the
> problem is that the usb-storage driver submitted an URB with more
> scatter-gather entries than would fit on the ring segment, the xHCI
> driver rejected the URB with -ENOMEM, and the SCSI core eventually gave
> up on the SCSI command.
Is there not a block layer / scheduler tunable for max sg entries or something?
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: pci: APM X-Gene PCIe controller driver
http://groups.google.com/group/linux.kernel/t/bb793bfb4a89dad9?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 2 2014 1:10 pm
From: Bjorn Helgaas
On Mon, Dec 23, 2013 at 1:02 AM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> This patch adds the AppliedMicro X-gene SOC PCIe controller driver.
> APM X-Gene PCIe controller supports maximum upto 8 lanes and
> GEN3 speed. X-Gene has maximum 5 PCIe ports supported.
>
> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
Since Jason requested "lspci" output, I'm waiting for him to review
these before applying them.
Also, please include a MAINTAINERS update showing who should approve
future changes to this file.
Bjorn
> ---
> drivers/pci/host/Kconfig | 5 +
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/pcie-xgene.c | 1017 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1023 insertions(+)
> create mode 100644 drivers/pci/host/pcie-xgene.c
>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 47d46c6..6d8fcbc 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -33,4 +33,9 @@ config PCI_RCAR_GEN2
> There are 3 internal PCI controllers available with a single
> built-in EHCI/OHCI host controller present on each one.
>
> +config PCI_XGENE
> + bool "X-Gene PCIe controller"
> + depends on ARCH_XGENE
> + depends on OF
> +
> endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 13fb333..a0bdfa7 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
> obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
> obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
> +obj-$(CONFIG_PCI_XGENE) += pcie-xgene.o
> diff --git a/drivers/pci/host/pcie-xgene.c b/drivers/pci/host/pcie-xgene.c
> new file mode 100644
> index 0000000..c9403c3
> --- /dev/null
> +++ b/drivers/pci/host/pcie-xgene.c
> @@ -0,0 +1,1017 @@
> +/**
> + * APM X-Gene PCIe Driver
> + *
> + * Copyright (c) 2013 Applied Micro Circuits Corporation.
> + *
> + * Author: Tanmay Inamdar <tinamdar@apm.com>.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/pci.h>
> +#include <linux/slab.h>
> +#include <linux/memblock.h>
> +#include <linux/io.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_pci.h>
> +#include <linux/jiffies.h>
> +#include <linux/clk-private.h>
> +#ifdef CONFIG_ARM64
> +#include <asm/pcibios.h>
> +#else
> +#include <asm/mach/pci.h>
> +
posted by twitter @ 2:51 PM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home