linux.kernel - 26 new messages in 15 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* of/selftest: Add self tests for manipulation of properties - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/b615f15949c4ee2e?hl=en
* A minor amd64_edac fix for 3.13 - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/966a3374765f3154?hl=en
* panic: setup panic_timeout early - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/b9ad085825bd3729?hl=en
* set_dumpable: fix the theoretical race with itself - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/60f0240f00deb328?hl=en
* 3.12.0-rt2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/122282eab30eec0a?hl=en
* staging/lustre: validate open handle cookies - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b9af2ffb60231fd2?hl=en
* aio: fix D-cache aliasing issues - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/e2884c60a25d22cc?hl=en
* of: remove /proc/device-tree - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c5856b4587eb9bca?hl=en
* kstrtox: remove redundant cleanup - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/f284ec730d289d67?hl=en
* documentation: Update circular buffer for load-acquire/store-release - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/9d3de39c23ef46a9?hl=en
* Fwd: [PATCH 1/8] watchdog: davinci: change driver to use WDT core - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/7567b784f9bce690?hl=en
* Fix NX-related Oops in wistron_btns module - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9a2c66ecc07ce7cd?hl=en
* x86/copy_user.S: Remove zero byte check before copy user buffer. - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/d9930d0ca010c5a8?hl=en
* afs: dir: remove unused label out_skip - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/652928071b0d20c8?hl=en
* mm: create a separate slab for page->ptl allocation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2bb284a987e3ac30?hl=en

==============================================================================
TOPIC: of/selftest: Add self tests for manipulation of properties
http://groups.google.com/group/linux.kernel/t/b615f15949c4ee2e?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Nov 16 2013 10:00 am
From: Pantelis Antoniou


Hi Grant,

On Nov 15, 2013, at 7:46 PM, Grant Likely wrote:

> Adds a few simple test cases to ensure that addition, update and removal
> of device tree node properties works correctly.
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
> ---
> drivers/of/selftest.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/of/selftest.c b/drivers/of/selftest.c
> index e21012bde639..cb8d3e722f76 100644
> --- a/drivers/of/selftest.c
> +++ b/drivers/of/selftest.c
> @@ -30,6 +30,67 @@ static struct selftest_results {
> } \
> }
>
> +static void __init of_selftest_dynamic(void)
> +{
> + struct device_node *np;
> + struct property *prop;
> +
> + np = of_find_node_by_path("/testcase-data");
> + if (!np) {
> + pr_err("missing testcase data\n");
> + return;
> + }
> +
> + /* Array of 4 properties for the purpose of testing */
> + prop = kzalloc(sizeof(*prop) * 4, GFP_KERNEL);
> + if (!prop) {
> + selftest(0, "kzalloc() failed\n");
> + return;
> + }
> +
> + /* Add a new property - should pass*/
> + prop->name = "new-property";
> + prop->value = "new-property-data";
> + prop->length = strlen(prop->value);
> + selftest(of_add_property(np, prop) == 0, "Adding a new property failed\n");
> +
> + /* Try to add an existing property - should fail */
> + prop++;
> + prop->name = "new-property";
> + prop->value = "new-property-data-should-fail";
> + prop->length = strlen(prop->value);
> + selftest(of_add_property(np, prop) != 0,
> + "Adding an existing property should have failed\n");
> +
> + /* Try to modify an existing property - should pass */
> + prop->value = "modify-property-data-should-pass";
> + prop->length = strlen(prop->value);
> + selftest(of_update_property(np, prop) == 0,
> + "Updating an existing property should have passed\n");
> +
> + /* Try to modify non-existent property - should pass*/
> + prop++;
> + prop->name = "modify-property";
> + prop->value = "modify-missing-property-data-should-pass";
> + prop->length = strlen(prop->value);
> + selftest(of_update_property(np, prop) == 0,
> + "Updating a missing property should have passed\n");
> +
> + /* Remove property - should pass */
> + selftest(of_remove_property(np, prop) == 0,
> + "Removing a property should have passed\n");
> +
> + /* Adding very large property - should pass */
> + prop++;
> + prop->name = "large-property-PAGE_SIZEx8";
> + prop->length = PAGE_SIZE * 8;
> + prop->value = kzalloc(prop->length, GFP_KERNEL);
> + selftest(prop->value != NULL, "Unable to allocate large buffer\n");
> + if (prop->value)
> + selftest(of_add_property(np, prop) == 0,
> + "Adding a large property should have passed\n");
> +}
> +
> static void __init of_selftest_parse_phandle_with_args(void)
> {
> struct device_node *np;
> @@ -312,6 +373,7 @@ static int __init of_selftest(void)
> of_node_put(np);
>
> pr_info("start of selftest - you will see error messages\n");
> + of_selftest_dynamic();
> of_selftest_parse_phandle_with_args();
> of_selftest_property_match_string();
> of_selftest_parse_interrupts();
> --
> 1.8.3.2
>

I like this. I'll add my overlay test cases somewhere around here.

I might need to introduce some new helper functions in order to generate
the overlay completely programmatically.

Regards

-- Pantelis



--
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: Sat, Nov 16 2013 11:10 am
From: Rob Herring


On Fri, Nov 15, 2013 at 11:46 AM, Grant Likely <grant.likely@linaro.org> wrote:
> Adds a few simple test cases to ensure that addition, update and removal
> of device tree node properties works correctly.
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
> ---
> drivers/of/selftest.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)

Does this need to depend on or select OF_DYNAMIC?

Rob
--
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: A minor amd64_edac fix for 3.13
http://groups.google.com/group/linux.kernel/t/966a3374765f3154?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Nov 16 2013 10:20 am
From: Linus Torvalds


On Sat, Nov 16, 2013 at 3:12 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Sat, Nov 16, 2013 at 02:50:49AM -0800, Linus Torvalds wrote:
>
>> The most common reason seems to be that your email provide is
>> associated with spam, sometimes just because of a shared ISP.
>
> Sure, it is one: https://www.hetzner.de/

Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of
complaints. See for example

http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/

which puts it #2 _worldwide_ in September. I have no idea how accurate
that is, but..

I would suggest everybody who uses hetzner actively drop them, and
talk publicly about *why* they drop them. Your business may not be all
that lucrative to them (compared to the spam), but still..

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 2 ==
Date: Sat, Nov 16 2013 10:30 am
From: Borislav Petkov


On Sat, Nov 16, 2013 at 10:10:05AM -0800, Linus Torvalds wrote:
> Ahh. Yes. Googling for "hetzner online spam", and there's a *lot* of
> complaints. See for example
>
> http://www.spamrankings.net/rankv2/2013/09/01/monthly/world/volume/cbl/all/regular/

Yowza, this is just great! :-(

> which puts it #2 _worldwide_ in September. I have no idea how accurate
> that is, but..

And they were #3 in August. So a steady rise ...

> I would suggest everybody who uses hetzner actively drop them, and
> talk publicly about *why* they drop them. Your business may not be all
> that lucrative to them (compared to the spam), but still..

Yeah, I hear they're not that great otherwise either, regardless of how
they handle (or not) spam.

@Frank, we need to have a serious talk, you and I :-)

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: panic: setup panic_timeout early
http://groups.google.com/group/linux.kernel/t/b9ad085825bd3729?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Nov 16 2013 10:50 am
From: Felipe Contreras


On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
> * Felipe Contreras <felipe.contreras@gmail.com> wrote:

> Anyway, the fact that you are argumentative even with Linus gives me
> little hope that you will improve your communication patterns with
> _me_, so I'm personally done arguing with you.

How am I being argumentative? I avoided all arguments.

>> You don't want to argue? Then don't argue. Apply the patch. [...]
>
> *Plonk*.

This is exactly the opposite of what is conducive to less argumentation.

If you are not going to comment on the patch, then don't say anything.

The patch is good, and the fact that both you and Linus are avoiding
any comments in the patch itself doesn't speak well for your
intentions to avoid argumentation.

So I ask you again. Do you see something wrong with the patch?

--
Felipe Contreras
--
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 3 ==
Date: Sat, Nov 16 2013 12:20 pm
From: Levente Kurusa


2013-11-16 19:46 keltezéssel, Felipe Contreras írta:
> On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> Anyway, the fact that you are argumentative even with Linus gives me
>> little hope that you will improve your communication patterns with
>> _me_, so I'm personally done arguing with you.
>
> How am I being argumentative? I avoided all arguments.
>
>>> You don't want to argue? Then don't argue. Apply the patch. [...]
>>
>> *Plonk*.
>
> This is exactly the opposite of what is conducive to less argumentation.
>
> If you are not going to comment on the patch, then don't say anything.
>
> The patch is good, and the fact that both you and Linus are avoiding
> any comments in the patch itself doesn't speak well for your
> intentions to avoid argumentation.
>
> So I ask you again. Do you see something wrong with the patch?
>

Yes, you.

--
Regards,
Levente Kurusa
--
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 3 ==
Date: Sat, Nov 16 2013 12:30 pm
From: Levente Kurusa


2013-11-16 19:46 keltezéssel, Felipe Contreras írta:
> On Sat, Nov 16, 2013 at 11:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> * Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> Anyway, the fact that you are argumentative even with Linus gives me
>> little hope that you will improve your communication patterns with
>> _me_, so I'm personally done arguing with you.
>
> How am I being argumentative? I avoided all arguments.
>
>>> You don't want to argue? Then don't argue. Apply the patch. [...]
>>
>> *Plonk*.
>
> This is exactly the opposite of what is conducive to less argumentation.
>
> If you are not going to comment on the patch, then don't say anything.
>
> The patch is good, and the fact that both you and Linus are avoiding
> any comments in the patch itself doesn't speak well for your
> intentions to avoid argumentation.
>
> So I ask you again. Do you see something wrong with the patch?
>

Out-of-joke, the patch is now in an 'appliable' state.

You can add my:
Reviewed-by: Levente Kurusa <levex@linux.com>

--
Regards,
Levente Kurusa
--
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: set_dumpable: fix the theoretical race with itself
http://groups.google.com/group/linux.kernel/t/60f0240f00deb328?hl=en
==============================================================================

== 1 of 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


set_dumpable() updates MMF_DUMPABLE_MASK in a non-trivial way to
ensure that get_dumpable() can't observe the intermediate state,
but this all can't help if multiple threads call set_dumpable()
at the same time.

And in theory commit_creds()->set_dumpable(SUID_DUMP_ROOT) racing
with sys_prctl()->set_dumpable(SUID_DUMP_DISABLE) can result in
SUID_DUMP_USER.

Change this code to update both bits atomically via cmpxchg().

Note: this assumes that it is safe to mix bitops and cmpxchg. IOW,
if, say, an architecture implements cmpxchg() using the locking
(like arch/parisc/lib/bitops.c does), then it should use the same
locks for set_bit/etc.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/exec.c | 49 +++++++++++++++----------------------------------
1 files changed, 15 insertions(+), 34 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index bb8afc1..613c9dc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1621,43 +1621,24 @@ EXPORT_SYMBOL(set_binfmt);

/*
* set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags. It modifies lower two bits of mm->flags, but
- * these bits are not changed atomically. So get_dumpable can observe the
- * intermediate state. To avoid doing unexpected behavior, get get_dumpable
- * return either old dumpable or new one by paying attention to the order of
- * modifying the bits.
- *
- * dumpable | mm->flags (binary)
- * old new | initial interim final
- * ---------+-----------------------
- * 0 1 | 00 01 01
- * 0 2 | 00 10(*) 11
- * 1 0 | 01 00 00
- * 1 2 | 01 11 11
- * 2 0 | 11 10(*) 00
- * 2 1 | 11 11 01
- *
- * (*) get_dumpable regards interim value of 10 as 11.
+ * stores them into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
- switch (value) {
- case SUID_DUMP_DISABLE:
- clear_bit(MMF_DUMPABLE, &mm->flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, &mm->flags);
- break;
- case SUID_DUMP_USER:
- set_bit(MMF_DUMPABLE, &mm->flags);
- smp_wmb();
- clear_bit(MMF_DUMP_SECURELY, &mm->flags);
- break;
- case SUID_DUMP_ROOT:
- set_bit(MMF_DUMP_SECURELY, &mm->flags);
- smp_wmb();
- set_bit(MMF_DUMPABLE, &mm->flags);
- break;
- }
+ unsigned long old, new;
+
+ do {
+ old = ACCESS_ONCE(mm->flags);
+ new = old & ~MMF_DUMPABLE_MASK;
+
+ switch (value) {
+ case SUID_DUMP_ROOT:
+ new |= (1 << MMF_DUMP_SECURELY);
+ case SUID_DUMP_USER:
+ new |= (1<< MMF_DUMPABLE);
+ }
+
+ } while (cmpxchg(&mm->flags, old, new) != old);
}

int __get_dumpable(unsigned long mm_flags)
--
1.5.5.1


--
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 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


On 11/15, Kees Cook wrote:
>
> On Fri, Nov 15, 2013 at 12:36 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > unless I missed something, this is the fix, not cleanup ?
> >
> > If commit_creds()->set_dumpable(SUID_DUMP_ROOT) races with
> > sys_prctl()->set_dumpable(SUID_DUMP_DISABLE), we can get
> > SUID_DUMP_USER afaics.
> >
> > Yes, yes, even if I am right this race is very unlikely.
>
> Hm, yes, that is a fix then. I struggle to imagine it being
> exploitable (i.e. control over both threads, one at least already with
> a different cred, etc), but it certainly does look like a bug.

Yes, yes, sure, this is only theoretical.

OK, I am sending the patches to lkml. I didn't dare to keep your ack,
please review v2 (v1 confused bit-mask with bit-number, and in theory
we need ACCESS_ONCE).

It would be really nice if someone can ack the "it is safe to mix
bitops and cmpxchg" assumption mentioned in the changelog.


Alex, Josh, this also partly reverts 179899fd5dc780fe "coredump:
update coredump-related headers", I think fs/coredump.h buys nothing.

Oleg.

fs/coredump.c | 1 -
fs/coredump.h | 6 -----
fs/exec.c | 61 +++++--------------------------------------------
include/linux/sched.h | 25 ++++++++++++++-----
4 files changed, 24 insertions(+), 69 deletions(-)

--
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 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


Nobody actually needs MMF_DUMPABLE/MMF_DUMP_SECURELY, there
are only used to enforce the encoding of SUID_DUMP_* enum in
mm->flags & MMF_DUMPABLE_MASK.

Now that set_dumpable() updates both bits atomically we can
kill them and simply store the value "as is" in 2 lower bits.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/exec.c | 18 +++---------------
include/linux/sched.h | 4 +---
2 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 613c9dc..5303005 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1620,8 +1620,7 @@ void set_binfmt(struct linux_binfmt *new)
EXPORT_SYMBOL(set_binfmt);

/*
- * set_dumpable converts traditional three-value dumpable to two flags and
- * stores them into mm->flags.
+ * set_dumpable stores three-value SUID_DUMP_* into mm->flags.
*/
void set_dumpable(struct mm_struct *mm, int value)
{
@@ -1629,24 +1628,13 @@ void set_dumpable(struct mm_struct *mm, int value)

do {
old = ACCESS_ONCE(mm->flags);
- new = old & ~MMF_DUMPABLE_MASK;
-
- switch (value) {
- case SUID_DUMP_ROOT:
- new |= (1 << MMF_DUMP_SECURELY);
- case SUID_DUMP_USER:
- new |= (1<< MMF_DUMPABLE);
- }
-
+ new = (old & ~MMF_DUMPABLE_MASK) | value;
} while (cmpxchg(&mm->flags, old, new) != old);
}

int __get_dumpable(unsigned long mm_flags)
{
- int ret;
-
- ret = mm_flags & MMF_DUMPABLE_MASK;
- return (ret > SUID_DUMP_USER) ? SUID_DUMP_ROOT : ret;
+ return mm_flags & MMF_DUMPABLE_MASK;
}

/*
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 838a3d9..828c00d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -326,10 +326,8 @@ extern int get_dumpable(struct mm_struct *mm);
#define SUID_DUMP_ROOT 2 /* Dump as root */

/* mm flags */
-/* dumpable bits */
-#define MMF_DUMPABLE 0 /* core dump is permitted */
-#define MMF_DUMP_SECURELY 1 /* core file is readable only by root */

+/* for SUID_DUMP_* above */
#define MMF_DUMPABLE_BITS 2
#define MMF_DUMPABLE_MASK ((1 << MMF_DUMPABLE_BITS) - 1)

--
1.5.5.1


--
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 4 ==
Date: Sat, Nov 16 2013 11:10 am
From: Oleg Nesterov


1. Remove fs/coredump.h. It is not clear why do we need it,
it only declares __get_dumpable(), signal.c includes it
for no reason.

2. Now that get_dumpable() and __get_dumpable() are really
trivial make them inline in linux/sched.h.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
fs/coredump.c | 1 -
fs/coredump.h | 6 ------
fs/exec.c | 18 ------------------
include/linux/sched.h | 21 +++++++++++++++++----
4 files changed, 17 insertions(+), 29 deletions(-)
delete mode 100644 fs/coredump.h

diff --git a/fs/coredump.c b/fs/coredump.c
index 9bdeca1..4bc92c7 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -40,7 +40,6 @@

#include <trace/events/task.h>
#include "internal.h"
-#include "coredump.h"

#include <trace/events/sched.h>

diff --git a/fs/coredump.h b/fs/coredump.h
deleted file mode 100644
index e39ff07..0000000
--- a/fs/coredump.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef _FS_COREDUMP_H
-#define _FS_COREDUMP_H
-
-extern int __get_dumpable(unsigned long mm_flags);
-
-