All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 3/4] tracing: Check that number of vals matches number of synth event fields
From: Tom Zanussi @ 2020-02-14 22:56 UTC (permalink / raw)
  To: rostedt; +Cc: artem.bityutskiy, mhiramat, linux-kernel
In-Reply-To: <cover.1581720155.git.zanussi@kernel.org>

Commit 7276531d4036('tracing: Consolidate trace() functions')
inadvertently dropped the synth_event_trace() and
synth_event_trace_array() checks that verify the number of values
passed in matches the number of fields in the synthetic event being
traced, so add them back.

Signed-off-by: Tom Zanussi <zanussi@kernel.org>
---
 kernel/trace/trace_events_hist.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 913760d2d505..95d4c871f87b 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -1885,6 +1885,11 @@ int synth_event_trace(struct trace_event_file *file, unsigned int n_vals, ...)
 		return ret;
 	}
 
+	if (n_vals != state.event->n_fields) {
+		ret = -EINVAL;
+		goto out;
+	}
+
 	va_start(args, n_vals);
 	for (i = 0, n_u64 = 0; i < state.event->n_fields; i++) {
 		u64 val;
@@ -1921,7 +1926,7 @@ int synth_event_trace(struct trace_event_file *file, unsigned int n_vals, ...)
 		}
 	}
 	va_end(args);
-
+out:
 	__synth_event_trace_end(&state);
 
 	return ret;
@@ -1960,6 +1965,11 @@ int synth_event_trace_array(struct trace_event_file *file, u64 *vals,
 		return ret;
 	}
 
+	if (n_vals != state.event->n_fields) {
+		ret = -EINVAL;
+		goto out;
+	}
+
 	for (i = 0, n_u64 = 0; i < state.event->n_fields; i++) {
 		if (state.event->fields[i]->is_string) {
 			char *str_val = (char *)(long)vals[i];
@@ -1991,7 +2001,7 @@ int synth_event_trace_array(struct trace_event_file *file, u64 *vals,
 			n_u64++;
 		}
 	}
-
+out:
 	__synth_event_trace_end(&state);
 
 	return ret;
-- 
2.14.1


^ permalink raw reply related

* [PATCH v2 4/4] tracing: Fix number printing bug in print_synth_event()
From: Tom Zanussi @ 2020-02-14 22:56 UTC (permalink / raw)
  To: rostedt; +Cc: artem.bityutskiy, mhiramat, linux-kernel
In-Reply-To: <cover.1581720155.git.zanussi@kernel.org>

Fix a varargs-related bug in print_synth_event() which resulted in
strange output and oopses on 32-bit x86 systems. The problem is that
trace_seq_printf() expects the varargs to match the format string, but
print_synth_event() was always passing u64 values regardless.  This
results in unspecified behavior when unpacking with va_arg() in
trace_seq_printf().

Add a function that takes the size into account when calling
trace_seq_printf().

Before:

  modprobe-1731  [003] ....   919.039758: gen_synth_test: next_pid_field=777(null)next_comm_field=hula hoops ts_ns=1000000 ts_ms=1000 cpu=3(null)my_string_field=thneed my_int_field=598(null)

After:

 insmod-1136  [001] ....    36.634590: gen_synth_test: next_pid_field=777 next_comm_field=hula hoops ts_ns=1000000 ts_ms=1000 cpu=1 my_string_field=thneed my_int_field=598

Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Tom Zanussi <zanussi@kernel.org>
---
 kernel/trace/trace_events_hist.c | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 95d4c871f87b..b991168cf4ef 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -821,6 +821,29 @@ static const char *synth_field_fmt(char *type)
 	return fmt;
 }
 
+static void print_synth_event_num_val(struct trace_seq *s,
+				      char *print_fmt, char *name,
+				      int size, u64 val, char *space)
+{
+	switch (size) {
+	case 1:
+		trace_seq_printf(s, print_fmt, name, (u8)val, space);
+		break;
+
+	case 2:
+		trace_seq_printf(s, print_fmt, name, (u16)val, space);
+		break;
+
+	case 4:
+		trace_seq_printf(s, print_fmt, name, (u32)val, space);
+		break;
+
+	default:
+		trace_seq_printf(s, print_fmt, name, val, space);
+		break;
+	}
+}
+
 static enum print_line_t print_synth_event(struct trace_iterator *iter,
 					   int flags,
 					   struct trace_event *event)
@@ -859,10 +882,13 @@ static enum print_line_t print_synth_event(struct trace_iterator *iter,
 		} else {
 			struct trace_print_flags __flags[] = {
 			    __def_gfpflag_names, {-1, NULL} };
+			char *space = (i == se->n_fields - 1 ? "" : " ");
 
-			trace_seq_printf(s, print_fmt, se->fields[i]->name,
-					 entry->fields[n_u64],
-					 i == se->n_fields - 1 ? "" : " ");
+			print_synth_event_num_val(s, print_fmt,
+						  se->fields[i]->name,
+						  se->fields[i]->size,
+						  entry->fields[n_u64],
+						  space);
 
 			if (strcmp(se->fields[i]->type, "gfp_t") == 0) {
 				trace_seq_puts(s, " (");
-- 
2.14.1


^ permalink raw reply related

* [PATCH v2 2/4] tracing: Make synth_event trace functions endian-correct
From: Tom Zanussi @ 2020-02-14 22:56 UTC (permalink / raw)
  To: rostedt; +Cc: artem.bityutskiy, mhiramat, linux-kernel
In-Reply-To: <cover.1581720155.git.zanussi@kernel.org>

synth_event_trace(), synth_event_trace_array() and
__synth_event_add_val() write directly into the trace buffer and need
to take endianness into account, like trace_event_raw_event_synth()
does.

Signed-off-by: Tom Zanussi <zanussi@kernel.org>
---
 kernel/trace/trace_events_hist.c | 62 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 58 insertions(+), 4 deletions(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 483b3fd1094f..913760d2d505 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -1898,7 +1898,25 @@ int synth_event_trace(struct trace_event_file *file, unsigned int n_vals, ...)
 			strscpy(str_field, str_val, STR_VAR_LEN_MAX);
 			n_u64 += STR_VAR_LEN_MAX / sizeof(u64);
 		} else {
-			state.entry->fields[n_u64] = val;
+			struct synth_field *field = state.event->fields[i];
+
+			switch (field->size) {
+			case 1:
+				*(u8 *)&state.entry->fields[n_u64] = (u8)val;
+				break;
+
+			case 2:
+				*(u16 *)&state.entry->fields[n_u64] = (u16)val;
+				break;
+
+			case 4:
+				*(u32 *)&state.entry->fields[n_u64] = (u32)val;
+				break;
+
+			default:
+				state.entry->fields[n_u64] = val;
+				break;
+			}
 			n_u64++;
 		}
 	}
@@ -1950,7 +1968,26 @@ int synth_event_trace_array(struct trace_event_file *file, u64 *vals,
 			strscpy(str_field, str_val, STR_VAR_LEN_MAX);
 			n_u64 += STR_VAR_LEN_MAX / sizeof(u64);
 		} else {
-			state.entry->fields[n_u64] = vals[i];
+			struct synth_field *field = state.event->fields[i];
+			u64 val = vals[i];
+
+			switch (field->size) {
+			case 1:
+				*(u8 *)&state.entry->fields[n_u64] = (u8)val;
+				break;
+
+			case 2:
+				*(u16 *)&state.entry->fields[n_u64] = (u16)val;
+				break;
+
+			case 4:
+				*(u32 *)&state.entry->fields[n_u64] = (u32)val;
+				break;
+
+			default:
+				state.entry->fields[n_u64] = val;
+				break;
+			}
 			n_u64++;
 		}
 	}
@@ -2069,8 +2106,25 @@ static int __synth_event_add_val(const char *field_name, u64 val,
 
 		str_field = (char *)&entry->fields[field->offset];
 		strscpy(str_field, str_val, STR_VAR_LEN_MAX);
-	} else
-		entry->fields[field->offset] = val;
+	} else {
+		switch (field->size) {
+		case 1:
+			*(u8 *)&trace_state->entry->fields[field->offset] = (u8)val;
+			break;
+
+		case 2:
+			*(u16 *)&trace_state->entry->fields[field->offset] = (u16)val;
+			break;
+
+		case 4:
+			*(u32 *)&trace_state->entry->fields[field->offset] = (u32)val;
+			break;
+
+		default:
+			trace_state->entry->fields[field->offset] = val;
+			break;
+		}
+	}
  out:
 	return ret;
 }
-- 
2.14.1


^ permalink raw reply related

* [PATCH v2 1/4] tracing: Make sure synth_event_trace() example always uses u64
From: Tom Zanussi @ 2020-02-14 22:56 UTC (permalink / raw)
  To: rostedt; +Cc: artem.bityutskiy, mhiramat, linux-kernel
In-Reply-To: <cover.1581720155.git.zanussi@kernel.org>

synth_event_trace() is the varargs version of synth_event_trace_array(),
which takes an array of u64, as do synth_event_add_val() et al.

To not only be consistent with those, but also to address the fact
that synth_event_trace() expects every arg to be of the same type
since it doesn't also pass in e.g. a format string, the caller needs
to make sure all args are of the same type, u64.  u64 is used because
it needs to accomodate the largest type available in synthetic events,
which is u64.

This fixes the bug reported by the kernel test robot/Rong Chen as
reported here:

  https://lore.kernel.org/lkml/20200212113444.GS12867@shao2-debian/

Reported-by: kernel test robot <rong.a.chen@intel.com>
Signed-off-by: Tom Zanussi <zanussi@kernel.org>
---
 kernel/trace/synth_event_gen_test.c | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/kernel/trace/synth_event_gen_test.c b/kernel/trace/synth_event_gen_test.c
index 4aefe003cb7c..6866280a9b10 100644
--- a/kernel/trace/synth_event_gen_test.c
+++ b/kernel/trace/synth_event_gen_test.c
@@ -111,11 +111,11 @@ static int __init test_gen_synth_cmd(void)
 	/* Create some bogus values just for testing */
 
 	vals[0] = 777;			/* next_pid_field */
-	vals[1] = (u64)"hula hoops";	/* next_comm_field */
+	vals[1] = (u64)(long)"hula hoops";	/* next_comm_field */
 	vals[2] = 1000000;		/* ts_ns */
 	vals[3] = 1000;			/* ts_ms */
 	vals[4] = smp_processor_id();	/* cpu */
-	vals[5] = (u64)"thneed";	/* my_string_field */
+	vals[5] = (u64)(long)"thneed";	/* my_string_field */
 	vals[6] = 598;			/* my_int_field */
 
 	/* Now generate a gen_synth_test event */
@@ -218,11 +218,11 @@ static int __init test_empty_synth_event(void)
 	/* Create some bogus values just for testing */
 
 	vals[0] = 777;			/* next_pid_field */
-	vals[1] = (u64)"tiddlywinks";	/* next_comm_field */
+	vals[1] = (u64)(long)"tiddlywinks";	/* next_comm_field */
 	vals[2] = 1000000;		/* ts_ns */
 	vals[3] = 1000;			/* ts_ms */
 	vals[4] = smp_processor_id();	/* cpu */
-	vals[5] = (u64)"thneed_2.0";	/* my_string_field */
+	vals[5] = (u64)(long)"thneed_2.0";	/* my_string_field */
 	vals[6] = 399;			/* my_int_field */
 
 	/* Now trace an empty_synth_test event */
@@ -290,11 +290,11 @@ static int __init test_create_synth_event(void)
 	/* Create some bogus values just for testing */
 
 	vals[0] = 777;			/* next_pid_field */
-	vals[1] = (u64)"tiddlywinks";	/* next_comm_field */
+	vals[1] = (u64)(long)"tiddlywinks";	/* next_comm_field */
 	vals[2] = 1000000;		/* ts_ns */
 	vals[3] = 1000;			/* ts_ms */
 	vals[4] = smp_processor_id();	/* cpu */
-	vals[5] = (u64)"thneed";	/* my_string_field */
+	vals[5] = (u64)(long)"thneed";	/* my_string_field */
 	vals[6] = 398;			/* my_int_field */
 
 	/* Now generate a create_synth_test event */
@@ -330,7 +330,7 @@ static int __init test_add_next_synth_val(void)
 		goto out;
 
 	/* next_comm_field */
-	ret = synth_event_add_next_val((u64)"slinky", &trace_state);
+	ret = synth_event_add_next_val((u64)(long)"slinky", &trace_state);
 	if (ret)
 		goto out;
 
@@ -350,7 +350,7 @@ static int __init test_add_next_synth_val(void)
 		goto out;
 
 	/* my_string_field */
-	ret = synth_event_add_next_val((u64)"thneed_2.01", &trace_state);
+	ret = synth_event_add_next_val((u64)(long)"thneed_2.01", &trace_state);
 	if (ret)
 		goto out;
 
@@ -396,12 +396,12 @@ static int __init test_add_synth_val(void)
 	if (ret)
 		goto out;
 
-	ret = synth_event_add_val("next_comm_field", (u64)"silly putty",
+	ret = synth_event_add_val("next_comm_field", (u64)(long)"silly putty",
 				  &trace_state);
 	if (ret)
 		goto out;
 
-	ret = synth_event_add_val("my_string_field", (u64)"thneed_9",
+	ret = synth_event_add_val("my_string_field", (u64)(long)"thneed_9",
 				  &trace_state);
 	if (ret)
 		goto out;
@@ -423,13 +423,13 @@ static int __init test_trace_synth_event(void)
 
 	/* Trace some bogus values just for testing */
 	ret = synth_event_trace(create_synth_test, 7,	/* number of values */
-				444,			/* next_pid_field */
-				(u64)"clackers",	/* next_comm_field */
-				1000000,		/* ts_ns */
-				1000,			/* ts_ms */
-				smp_processor_id(),	/* cpu */
-				(u64)"Thneed",		/* my_string_field */
-				999);			/* my_int_field */
+				(u64)444,		/* next_pid_field */
+				(u64)(long)"clackers",	/* next_comm_field */
+				(u64)1000000,		/* ts_ns */
+				(u64)1000,		/* ts_ms */
+				(u64)smp_processor_id(),/* cpu */
+				(u64)(long)"Thneed",	/* my_string_field */
+				(u64)999);		/* my_int_field */
 	return ret;
 }
 
-- 
2.14.1


^ permalink raw reply related

* [PATCH v2 0/4] tracing: synth_event_trace fixes
From: Tom Zanussi @ 2020-02-14 22:56 UTC (permalink / raw)
  To: rostedt; +Cc: artem.bityutskiy, mhiramat, linux-kernel

Hi Steve,

This is v2 of this patchset.  It adds a new patch, 'tracing: Fix
number printing bug in print_synth_event()' that fixes the problem you
reported with (null) printing in the synth event trace output on
32-bit systems.  It turns out to be nothing to do with these fixes or
the new stuff in 5.6 - the problem exists in 5.5 as well and can also
cause oopses as well when reading the trace file when synthetic evens
are present.

The only other change from v1 is a change to 'tracing: Check that
number of vals matches number of synth event fields' to not directly
return -EINVAL, but only after calling __synth_event_trace_end().

I've tested on both 32-bit x86 and x86_64, both the synth module test
and selftests and everything looks ok here.

Thanks,

Tom

v1 text:

Sorry, it took me some time to get a 32-bit x86 system up and running
here in order to build and test things on i386.  These patches pass
both selftests and the synth_event_gen_test testing, although the bug
where (null) prints after every integer field in the trace output is
still there and is there even before these or yesterday's patches - I
have a suspicion it's been there for awhile but nobody looked at
synthetic event trace output on i386.  In any case, I'm going to
continue looking into that - it's a weird situation where nothing gets
put in the final %s in the format string on i386 so shows as (null),
even though it looks like it's there.  Anyway..

Here are 3 bugfix patches, the first of which fixes the bug seen by
the test robot, and the other two are patches that fix a couple things
I noticed when doing the first patch.

The previous patch I sent, changing u64 to long for the test robot bug
did fix that problem too, but on i386 systems that would reduce every
field to 32 bits, which isn't what we want either.  The new patch
doesn't change the code in synth_event_trace() - it still uses u64
just like synth_event_trace_array() which takes an array of u64.
Without any further information such as a format string, I don't know
of a better way to deal with the varargs version, other than require
it get passed what it expects, u64 params.

The second patch adds the same endianness fix as for
trace_event_raw_event_synth(), and the last one just adds back a
missing check fot synth_event_trace() and synth_event_trace_array().

Thanks,

Tom

The following changes since commit 359c92c02bfae1a6f1e8e37c298e518fd256642c:

  Merge tag 'dax-fixes-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm (2020-02-11 16:52:08 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/zanussi/linux-trace.git ftrace/synth-event-gen-fixes2-v2

Tom Zanussi (4):
  tracing: Make sure synth_event_trace() example always uses u64
  tracing: Make synth_event trace functions endian-correct
  tracing: Check that number of vals matches number of synth event
    fields
  tracing: Fix number printing bug in print_synth_event()

 kernel/trace/synth_event_gen_test.c |  34 ++++++------
 kernel/trace/trace_events_hist.c    | 108 +++++++++++++++++++++++++++++++++---
 2 files changed, 116 insertions(+), 26 deletions(-)

-- 
2.14.1


^ permalink raw reply

* Re: [PATCH 2/3] random: rng-seed source is utf-8
From: Mark Salyzyn @ 2020-02-14 22:55 UTC (permalink / raw)
  To: Theodore Y. Ts'o, Rob Herring
  Cc: Masami Hiramatsu, linux-kernel@vger.kernel.org,
	Android Kernel Team, Arnd Bergmann, Greg Kroah-Hartman,
	Richard Henderson, Mark Brown, Kees Cook, Hsin-Yi Wang,
	Vasily Gorbik, Andrew Morton, Steven Rostedt, Mike Rapoport,
	Arvind Sankar, Dominik Brodowski, Thomas Gleixner,
	Alexander Potapenko, Jonathan Corbet, Mauro Carvalho Chehab,
	Josh Poimboeuf, Pawan Gupta, Juergen Gross,
	Linux Doc Mailing List
In-Reply-To: <20200214224744.GC439135@mit.edu>

On 2/14/20 2:47 PM, Theodore Y. Ts'o wrote:
> On Fri, Feb 14, 2020 at 01:58:35PM -0600, Rob Herring wrote:
>> On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>>> From: Mark Salyzyn <salyzyn@android.com>
>>>
>>> commit 428826f5358c922dc378830a1717b682c0823160
>>> ("fdt: add support for rng-seed") makes the assumption that the data
>>> in rng-seed is binary, when it is typically constructed of utf-8
>> Typically? Why is that?
>>
>>> characters which has a bitness of roughly 6 to give appropriate
>>> credit due for the entropy.
> This is why I really think what gets specified via the boot command
> line, or bootconfig, should specify the bits of entropy and the
> entropy seed *separately*, so it can be specified explicitly, instead
> of assuming that *everyone knows* that rng-seed is either (a) a binary
> string, or (b) utf-8, or (c) a hex string.  The fact is, everyone does
> *not* know, or everyone will have a different implementation, which
> everyone will say is *obviously* the only way to go....
>
> 	      	     		     	  - Ted

Given that the valid option are between 4 (hex), 6 (utf-8) or 8 
(binary), we can either split the difference and accept 6; or take a 
pass at the values and determine which of the set they belong to 
[0-9a-fA-F], [!-~] or [\000-\377]  nor need to separately specify.

-- Mark


^ permalink raw reply

* [PATCH 6/7] of/address: use range parser for of_dma_get_range
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>

of_dma_get_range() does the same ranges parsing as
of_pci_range_parser_one(), so let's refactor of_dma_get_range() to use
it instead.

This commit is no functional change. Subsequent commits will parse more
than the 1st dma-ranges entry.

Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/of/address.c | 38 +++++++++++++-------------------------
 1 file changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 6d33f849f114..a2c45812a50e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -939,10 +939,11 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 {
 	struct device_node *node = of_node_get(np);
 	const __be32 *ranges = NULL;
-	int len, naddr, nsize, pna;
+	int len;
 	int ret = 0;
 	bool found_dma_ranges = false;
-	u64 dmaaddr;
+	struct of_range_parser parser;
+	struct of_range range;
 
 	while (node) {
 		ranges = of_get_property(node, "dma-ranges", &len);
@@ -967,33 +968,20 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 		goto out;
 	}
 
-	naddr = of_bus_n_addr_cells(node);
-	nsize = of_bus_n_size_cells(node);
-	pna = of_n_addr_cells(node);
-	if ((len / sizeof(__be32)) % (pna + naddr + nsize)) {
-		ret = -EINVAL;
-		goto out;
-	}
+	of_dma_range_parser_init(&parser, node);
+
+	for_each_of_range(&parser, &range) {
+		pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+			 range.bus_addr, range.cpu_addr, range.size);
+
+		*dma_addr = range.bus_addr;
+		*paddr = range.cpu_addr;
+		*size = range.size;
 
-	/* dma-ranges format:
-	 * DMA addr	: naddr cells
-	 * CPU addr	: pna cells
-	 * size		: nsize cells
-	 */
-	dmaaddr = of_read_number(ranges, naddr);
-	*paddr = of_translate_dma_address(node, ranges + naddr);
-	if (*paddr == OF_BAD_ADDR) {
-		pr_err("translation of DMA address(%llx) to CPU address failed node(%pOF)\n",
-		       dmaaddr, np);
-		ret = -EINVAL;
 		goto out;
 	}
-	*dma_addr = dmaaddr;
-
-	*size = of_read_number(ranges + naddr + pna, nsize);
 
-	pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
-		 *dma_addr, *paddr, *size);
+	pr_err("translation of DMA ranges failed on node(%pOF)\n", np);
 
 out:
 	of_node_put(node);
-- 
2.20.1


^ permalink raw reply related

* [PATCH 5/7] of/address: Rework of_pci_range parsing for non-PCI buses
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>

The only PCI specific part of of_pci_range_parser_one() is the handling
of the 3rd address cell. Rework it to work on regular 1 and 2 cell
addresses.

Use defines and a union to avoid a treewide renaming of the parsing
helpers and struct.

Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/of/address.c       | 33 +++++++++++++++++++++------------
 include/linux/of_address.h | 12 +++++++++---
 2 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5d608d7c10d6..6d33f849f114 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -694,12 +694,12 @@ EXPORT_SYMBOL(of_get_address);
 static int parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node, const char *name)
 {
-	const int na = 3, ns = 2;
 	int rlen;
 
 	parser->node = node;
 	parser->pna = of_n_addr_cells(node);
-	parser->np = parser->pna + na + ns;
+	parser->na = of_bus_n_addr_cells(node);
+	parser->ns = of_bus_n_size_cells(node);
 	parser->dma = !strcmp(name, "dma-ranges");
 
 	parser->range = of_get_property(node, name, &rlen);
@@ -724,20 +724,28 @@ int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
 	return parser_init(parser, node, "dma-ranges");
 }
 EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init);
+#define of_dma_range_parser_init of_pci_dma_range_parser_init
 
 struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
 						struct of_pci_range *range)
 {
-	const int na = 3, ns = 2;
+	int na = parser->na;
+	int ns = parser->ns;
+	int np = parser->pna + na + ns;
 
 	if (!range)
 		return NULL;
 
-	if (!parser->range || parser->range + parser->np > parser->end)
+	if (!parser->range || parser->range + np > parser->end)
 		return NULL;
 
-	range->flags = of_bus_pci_get_flags(parser->range);
-	range->pci_addr = of_read_number(parser->range + 1, ns);
+	if (parser->na == 3)
+		range->flags = of_bus_pci_get_flags(parser->range);
+	else
+		range->flags = 0;
+
+	range->pci_addr = of_read_number(parser->range, na);
+
 	if (parser->dma)
 		range->cpu_addr = of_translate_dma_address(parser->node,
 				parser->range + na);
@@ -746,15 +754,16 @@ struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
 				parser->range + na);
 	range->size = of_read_number(parser->range + parser->pna + na, ns);
 
-	parser->range += parser->np;
+	parser->range += np;
 
 	/* Now consume following elements while they are contiguous */
-	while (parser->range + parser->np <= parser->end) {
-		u32 flags;
+	while (parser->range + np <= parser->end) {
+		u32 flags = 0;
 		u64 pci_addr, cpu_addr, size;
 
-		flags = of_bus_pci_get_flags(parser->range);
-		pci_addr = of_read_number(parser->range + 1, ns);
+		if (parser->na == 3)
+			flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range, na);
 		if (parser->dma)
 			cpu_addr = of_translate_dma_address(parser->node,
 					parser->range + na);
@@ -770,7 +779,7 @@ struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
 			break;
 
 		range->size += size;
-		parser->range += parser->np;
+		parser->range += np;
 	}
 
 	return range;
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 8d12bf18e80b..763022ed3456 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -10,20 +10,27 @@ struct of_pci_range_parser {
 	struct device_node *node;
 	const __be32 *range;
 	const __be32 *end;
-	int np;
+	int na;
+	int ns;
 	int pna;
 	bool dma;
 };
+#define of_range_parser of_pci_range_parser
 
 struct of_pci_range {
-	u64 pci_addr;
+	union {
+		u64 pci_addr;
+		u64 bus_addr;
+	};
 	u64 cpu_addr;
 	u64 size;
 	u32 flags;
 };
+#define of_range of_pci_range
 
 #define for_each_of_pci_range(parser, range) \
 	for (; of_pci_range_parser_one(parser, range);)
+#define for_each_of_range for_each_of_pci_range
 
 /* Translate a DMA address from device space to CPU space */
 extern u64 of_translate_dma_address(struct device_node *dev,
@@ -142,4 +149,3 @@ static inline int of_pci_range_to_resource(struct of_pci_range *range,
 #endif /* CONFIG_OF_ADDRESS && CONFIG_PCI */
 
 #endif /* __OF_ADDRESS_H */
-
-- 
2.20.1


^ permalink raw reply related

* [igt-dev] ✗ GitLab.Pipeline: failure for lib: Update selftests to use dynamic subtests
From: Patchwork @ 2020-02-14 22:53 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev
In-Reply-To: <20200214214829.4054673-1-chris@chris-wilson.co.uk>

== Series Details ==

Series: lib: Update selftests to use dynamic subtests
URL   : https://patchwork.freedesktop.org/series/73486/
State : failure

== Summary ==

ERROR! This series introduces new undocumented tests:

dmabuf@all
drm_mm@all
i915_selftest@live
i915_selftest@mock
i915_selftest@perf
kms_selftest@all

Can you document them as per the requirement in the [CONTRIBUTING.md]?

[Documentation] has more details on how to do this.

Here are few examples:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/0316695d03aa46108296b27f3982ec93200c7a6e
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/443cc658e1e6b492ee17bf4f4d891029eb7a205d

Thanks in advance!

[CONTRIBUTING.md]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/CONTRIBUTING.md#L19
[Documentation]: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-gpu-tools-Core.html#igt-describe

Other than that, pipeline status: SUCCESS.

see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/108900 for the overview.

== Logs ==

For more details see: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/108900
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply

* Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices
From: Jason A. Donenfeld @ 2020-02-14 22:53 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Netdev
In-Reply-To: <1b132351-d4a7-851c-ac98-0a48c8d90797@gmail.com>

On Fri, Feb 14, 2020 at 11:30 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Also note that UDP sockets have SOCK_RCU_FREE flag set, so core
> networking also respect one RCU grace period before freeing them.

       if (use_call_rcu)
               call_rcu(&sk->sk_rcu, __sk_destruct);
       else
               __sk_destruct(&sk->sk_rcu);

Ah, that's handy indeed.

> It is possible that no extra synchronize_{net|rcu}() call is needed,
> but this is left as an exercise for future kernels :)

Cool, yea, sounds like something I should play with for 5.7.

Sending v3 out in a few minutes.

^ permalink raw reply

* [PATCH 4/7] of: Drop struct of_pci_range.pci_space field
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>

There's no more users of struct of_pci_range.pci_space field, so remove it.

Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/of/address.c       | 1 -
 include/linux/of_address.h | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 846045a48395..5d608d7c10d6 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -736,7 +736,6 @@ struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
 	if (!parser->range || parser->range + parser->np > parser->end)
 		return NULL;
 
-	range->pci_space = be32_to_cpup(parser->range);
 	range->flags = of_bus_pci_get_flags(parser->range);
 	range->pci_addr = of_read_number(parser->range + 1, ns);
 	if (parser->dma)
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index eac7ab109df4..8d12bf18e80b 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -16,7 +16,6 @@ struct of_pci_range_parser {
 };
 
 struct of_pci_range {
-	u32 pci_space;
 	u64 pci_addr;
 	u64 cpu_addr;
 	u64 size;
-- 
2.20.1


^ permalink raw reply related

* [meta-python][PATCH] python3-click: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 22:52 UTC (permalink / raw)
  To: openembedded-devel

Signed-off-by: Derek Straka <derek@asterius.io>
---
 .../recipes-devtools/python/python-click.inc  | 25 ------------------
 .../python/python3-click_7.0.bb               | 26 ++++++++++++++++++-
 2 files changed, 25 insertions(+), 26 deletions(-)
 delete mode 100644 meta-python/recipes-devtools/python/python-click.inc

diff --git a/meta-python/recipes-devtools/python/python-click.inc b/meta-python/recipes-devtools/python/python-click.inc
deleted file mode 100644
index f9dfd5627f..0000000000
--- a/meta-python/recipes-devtools/python/python-click.inc
+++ /dev/null
@@ -1,25 +0,0 @@
-SUMMARY = "A simple wrapper around optparse for powerful command line utilities."
-DESCRIPTION = "\
-Click is a Python package for creating beautiful command line interfaces \
-in a composable way with as little code as necessary. It's the "Command \
-Line Interface Creation Kit". It's highly configurable but comes with \
-sensible defaults out of the box."
-HOMEPAGE = "http://click.pocoo.org/"
-LICENSE = "BSD-3-Clause"
-LIC_FILES_CHKSUM = "file://LICENSE.rst;md5=c13ed890b210a882c1778216694c98c7"
-
-SRC_URI[md5sum] = "7f53d50f7b7373ebc7963f9ff697450a"
-SRC_URI[sha256sum] = "5b94b49521f6456670fdb30cd82a4eca9412788a93fa6dd6df72c94d5a8ff2d7"
-
-UPSTREAM_CHECK_REGEX = "click/(?P<pver>\d+(\.\d+)+)/"
-
-CLEANBROKEN = "1"
-
-RDEPENDS_${PN} += "\
-    ${PYTHON_PN}-io \
-    ${PYTHON_PN}-threading \
-    "
-
-BBCLASSEXTEND = "native nativesdk"
-
-PYPI_PACKAGE = "Click"
diff --git a/meta-python/recipes-devtools/python/python3-click_7.0.bb b/meta-python/recipes-devtools/python/python3-click_7.0.bb
index 1920644042..cfa3e0fe4f 100644
--- a/meta-python/recipes-devtools/python/python3-click_7.0.bb
+++ b/meta-python/recipes-devtools/python/python3-click_7.0.bb
@@ -1,2 +1,26 @@
+SUMMARY = "A simple wrapper around optparse for powerful command line utilities."
+DESCRIPTION = "\
+Click is a Python package for creating beautiful command line interfaces \
+in a composable way with as little code as necessary. It's the "Command \
+Line Interface Creation Kit". It's highly configurable but comes with \
+sensible defaults out of the box."
+HOMEPAGE = "http://click.pocoo.org/"
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE.rst;md5=c13ed890b210a882c1778216694c98c7"
+
+SRC_URI[md5sum] = "7f53d50f7b7373ebc7963f9ff697450a"
+SRC_URI[sha256sum] = "5b94b49521f6456670fdb30cd82a4eca9412788a93fa6dd6df72c94d5a8ff2d7"
+
+PYPI_PACKAGE = "Click"
 inherit pypi setuptools3
-require python-click.inc
+
+UPSTREAM_CHECK_REGEX = "click/(?P<pver>\d+(\.\d+)+)/"
+
+CLEANBROKEN = "1"
+
+RDEPENDS_${PN} += "\
+    ${PYTHON_PN}-io \
+    ${PYTHON_PN}-threading \
+    "
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1



^ permalink raw reply related

* Re: [PATCH v2 5/5] common/overlay: silence some mount messages for fuse-overlayfs
From: Amir Goldstein @ 2020-02-14 22:51 UTC (permalink / raw)
  To: Mauricio Faria de Oliveira; +Cc: fstests, overlayfs
In-Reply-To: <20200214151848.8328-6-mfo@canonical.com>

On Fri, Feb 14, 2020 at 5:19 PM Mauricio Faria de Oliveira
<mfo@canonical.com> wrote:
>
> When mouting fuse-overlayfs there are some messages that make
> the tests report failures due to output mismatch; ignore them:
>
>   uid=unchanged
>   uid=unchanged
>   upperdir=/mnt/test/ovl-upper
>   workdir=/mnt/test/ovl-work
>   lowerdir=/mnt/test/ovl-lower
>   mountpoint=/mnt/test/ovl-mnt
>
> For other filesystem types (e.g., overlay and aufs) make sure to
> only print non-null output, to avoid blank lines output mismatch.
>
> And return the status of the mount command, not other commands.
>
> Currently, running './check -overlay' tests (excluding generic/062)
> the numbers for fuse-overlayfs on loop devices on v5.4-based Ubuntu
> kernel with the fuse-overlayfs package from Ubuntu Eoan/19.10 are:
>
>  - Ran: 530
>  - Not run: 395
>  - Failures: 29
>
> And hopefully this helps with testing for fuse-overlayfs too.
>
> Steps:
>
>   $ export OVL_FSTYP=fuse.fuse-overlayfs
>   $ export FSTYP=ext4
>   $ export TEST_DEV=/dev/loop0
>   $ export TEST_DIR=/mnt/test
>   $ export SCRATCH_DEV=/dev/loop1
>   $ export SCRATCH_MNT=/mnt/scratch
>
>   $ sudo mkfs.$FSTYP -F $TEST_DEV
>   $ sudo mkfs.$FSTYP -F $SCRATCH_DEV
>   $ sudo mkdir $TEST_DIR $SCRATCH_MNT
>
>   $ cat <<EOF >/tmp/exclude-tests
>   generic/062
>   EOF
>
>   $ sudo -E ./check -overlay -E /tmp/exclude-tests
>
> Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
> ---
>  common/overlay | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/common/overlay b/common/overlay
> index a1076926c23f..27f3c08252ee 100644
> --- a/common/overlay
> +++ b/common/overlay
> @@ -19,6 +19,8 @@ _overlay_mount_dirs()
>         local upperdir=$2
>         local workdir=$3
>         local options
> +       local output
> +       local rc
>         shift 3
>
>         options="-o lowerdir=$lowerdir -o upperdir=$upperdir -o workdir=$workdir"
> @@ -26,7 +28,23 @@ _overlay_mount_dirs()
>                 options="-o br=$upperdir=rw -o br=$lowerdir=ro"
>         fi
>
> -       $MOUNT_PROG -t $OVL_FSTYP $options `_common_dev_mount_options $*`
> +       options="$options `_common_dev_mount_options $*`"
> +       output="`$MOUNT_PROG -t $OVL_FSTYP $options 2>&1`"
> +       rc=$?
> +
> +       if [ "$OVL_FSTYP" = "fuse.fuse-overlayfs" ]; then
> +               # Less verbosity to avoid output mismatch.
> +               echo "$output" | grep -v \
> +                       -e "^uid=" \
> +                       -e "^upperdir=" \
> +                       -e "^lowerdir=" \
> +                       -e "^workdir=" \
> +                       -e "^mountpoint="
> +       elif [ -n "$output" ]; then
> +               echo "$output"
> +       fi
> +
> +       return $rc

rc will always be 0 because it holds the return code of the assignment
expression 'output=...', not the return code of mount.

Does fuse mount verbose output go to stdout or to stderr?
I don't think we ever care about stdout of this mount command
on golden output - it is always assumed to be silent and
only a silent or noisy stderr is verified in golden output.
So if I am not mistaken and if fuse verbose output it to stdout,
then maybe would be enough to redirect stdout to /dev/null?

Thanks,
Amir.

^ permalink raw reply

* [PATCH 3/7] powerpc: Drop using struct of_pci_range.pci_space field
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>

Let's use the struct of_pci_range.flags field instead so we can remove
the pci_space field.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 arch/powerpc/kernel/pci-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index c6c03416a151..d0074ad73aa3 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -728,7 +728,7 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			       " MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
 			       range.cpu_addr, range.cpu_addr + range.size - 1,
 			       range.pci_addr,
-			       (range.pci_space & 0x40000000) ?
+			       (range.flags & IORESOURCE_PREFETCH) ?
 			       "Prefetch" : "");
 
 			/* We support only 3 memory ranges */
-- 
2.20.1


^ permalink raw reply related

* [PATCH 2/7] microblaze: Drop using struct of_pci_range.pci_space field
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>

Let's use the struct of_pci_range.flags field instead so we can remove
the pci_space field.

Just drop the debug prints as there's plenty of debug output in
drivers/of/address.c which can be enabled.

Cc: Michal Simek <monstr@monstr.eu>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 arch/microblaze/pci/pci-common.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 58cc4965bd3e..60a58c0015f2 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -433,10 +433,6 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 	pr_debug("Parsing ranges property...\n");
 	for_each_of_pci_range(&parser, &range) {
 		/* Read next ranges element */
-		pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-				range.pci_space, range.pci_addr);
-		pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-					range.cpu_addr, range.size);
 
 		/* If we failed translation or got a zero-sized region
 		 * (some FW try to feed us with non sensical zero sized regions
@@ -486,7 +482,7 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
 			pr_info(" MEM 0x%016llx..0x%016llx -> 0x%016llx %s\n",
 				range.cpu_addr, range.cpu_addr + range.size - 1,
 				range.pci_addr,
-				(range.pci_space & 0x40000000) ?
+				(range.flags & IORESOURCE_PREFETCH) ?
 				"Prefetch" : "");
 
 			/* We support only 3 memory ranges */
@@ -1121,4 +1117,3 @@ int early_find_capability(struct pci_controller *hose, int bus, int devfn,
 {
 	return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
 }
-
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Shakeel Butt @ 2020-02-14 22:48 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Johannes Weiner, Tejun Heo, Greg Thelen, Michal Hocko,
	Vladimir Davydov, Andrew Morton, Cgroups, linux-mm,
	Roman Gushchin, LKML
In-Reply-To: <CANn89iLe7KVjaechEhtV4=QRy4s8qBQDiX9e8LX_xq8tunrQNA@mail.gmail.com>

On Fri, Feb 14, 2020 at 2:38 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Fri, Feb 14, 2020 at 2:24 PM Shakeel Butt <shakeelb@google.com> wrote:
> >
> > We are testing network memory accounting in our setup and noticed
> > inconsistent network memory usage and often unrelated cgroups network
> > usage correlates with testing workload. On further inspection, it
> > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> > irq context specially for cgroup v1.
> >
> > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> > and kind of assumes that this can only happen from sk_clone_lock()
> > and the source sock object has already associated cgroup. However in
> > cgroup v1, where network memory accounting is opt-in, the source sock
> > can be unassociated with any cgroup and the new cloned sock can get
> > associated with unrelated interrupted cgroup.
> >
> > Cgroup v2 can also suffer if the source sock object was created by
> > process in the root cgroup or if sk_alloc() is called in irq context.
> > The fix is to just do nothing in interrupt.
>
> So, when will the association be done ?
> At accept() time ?
> Is it done already ?
>

I think in the current code if the association is skipped at
allocation time then the sock will remain unassociated for its
lifetime.

Maybe we can add the association in the later stages but it seems like
it is not a simple task i.e. edbe69ef2c90f ("Revert "defer call to
mem_cgroup_sk_alloc()"").

Shakeel


^ permalink raw reply

* Re: [PATCH 2/3] random: rng-seed source is utf-8
From: Theodore Y. Ts'o @ 2020-02-14 22:47 UTC (permalink / raw)
  To: Rob Herring
  Cc: Masami Hiramatsu, linux-kernel@vger.kernel.org,
	Android Kernel Team, Mark Salyzyn, Arnd Bergmann,
	Greg Kroah-Hartman, Richard Henderson, Mark Brown, Kees Cook,
	Hsin-Yi Wang, Vasily Gorbik, Andrew Morton, Steven Rostedt,
	Mike Rapoport, Arvind Sankar, Dominik Brodowski, Thomas Gleixner,
	Alexander Potapenko, Jonathan Corbet, Mauro Carvalho Chehab,
	Josh Poimboeuf, Pawan Gupta, Juergen Gross,
	Linux Doc Mailing List
In-Reply-To: <CAL_Jsq+BDfWgGTVtppD-JEFHZRqpc00WaV2N7c6qsPBSaxOEPw@mail.gmail.com>

On Fri, Feb 14, 2020 at 01:58:35PM -0600, Rob Herring wrote:
> On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > From: Mark Salyzyn <salyzyn@android.com>
> >
> > commit 428826f5358c922dc378830a1717b682c0823160
> > ("fdt: add support for rng-seed") makes the assumption that the data
> > in rng-seed is binary, when it is typically constructed of utf-8
> 
> Typically? Why is that?
> 
> > characters which has a bitness of roughly 6 to give appropriate
> > credit due for the entropy.

This is why I really think what gets specified via the boot command
line, or bootconfig, should specify the bits of entropy and the
entropy seed *separately*, so it can be specified explicitly, instead
of assuming that *everyone knows* that rng-seed is either (a) a binary
string, or (b) utf-8, or (c) a hex string.  The fact is, everyone does
*not* know, or everyone will have a different implementation, which
everyone will say is *obviously* the only way to go....

	      	     		     	  - Ted

^ permalink raw reply

* [meta-python][PATCH] python3-chardet: consolidate inc and bb files into a single bb file
From: Derek Straka @ 2020-02-14 22:48 UTC (permalink / raw)
  To: openembedded-devel

Signed-off-by: Derek Straka <derek@asterius.io>
---
 .../python/python-chardet.inc                 | 23 ---------------
 .../python/python3-chardet_3.0.4.bb           | 29 +++++++++++++++----
 2 files changed, 23 insertions(+), 29 deletions(-)
 delete mode 100644 meta-python/recipes-devtools/python/python-chardet.inc

diff --git a/meta-python/recipes-devtools/python/python-chardet.inc b/meta-python/recipes-devtools/python/python-chardet.inc
deleted file mode 100644
index 6305299780..0000000000
--- a/meta-python/recipes-devtools/python/python-chardet.inc
+++ /dev/null
@@ -1,23 +0,0 @@
-SUMMARY = "Universal encoding detector for Python 2 and 3"
-LICENSE = "LGPL-2.1"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=a6f89e2100d9b6cdffcea4f398e37343"
-
-inherit pypi
-
-# setup.py of chardet needs this.
-DEPENDS += "${PYTHON_PN}-pytest-runner-native"
-
-SRC_URI[md5sum] = "7dd1ba7f9c77e32351b0a0cfacf4055c"
-SRC_URI[sha256sum] = "84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae"
-
-BBCLASSEXTEND = "native nativesdk"
-
-PACKAGES =+ "${PN}-cli"
-RDEPENDS_${PN}-cli = "${PN} "
-FILES_${PN}-cli += " \
-    ${PYTHON_SITEPACKAGES_DIR}/chardet/cli \
-"
-
-RDEPENDS_${PN}_class-target += " \
-    ${PYTHON_PN}-logging \
-"
diff --git a/meta-python/recipes-devtools/python/python3-chardet_3.0.4.bb b/meta-python/recipes-devtools/python/python3-chardet_3.0.4.bb
index 38d8122ce9..80785b8d4e 100644
--- a/meta-python/recipes-devtools/python/python3-chardet_3.0.4.bb
+++ b/meta-python/recipes-devtools/python/python3-chardet_3.0.4.bb
@@ -1,7 +1,24 @@
-inherit setuptools3
-require python-chardet.inc
+SUMMARY = "Universal encoding detector for Python 2 and 3"
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=a6f89e2100d9b6cdffcea4f398e37343"
 
-do_install_append () {
-    # rename scripts that would conflict with the Python 2 build of chardet
-    mv ${D}${bindir}/chardetect ${D}${bindir}/chardetect3
-}
+SRC_URI[md5sum] = "7dd1ba7f9c77e32351b0a0cfacf4055c"
+SRC_URI[sha256sum] = "84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae"
+
+# setup.py of chardet needs this.
+DEPENDS += "${PYTHON_PN}-pytest-runner-native"
+
+inherit pypi setuptools3
+
+PACKAGES =+ "${PN}-cli"
+FILES_${PN}-cli += " \
+    ${PYTHON_SITEPACKAGES_DIR}/chardet/cli \
+"
+
+RDEPENDS_${PN}-cli = "${PN} "
+
+RDEPENDS_${PN}_class-target += " \
+    ${PYTHON_PN}-logging \
+"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1



^ permalink raw reply related

* Re: [PATCH v2 9/9] perf,tracing: Allow function tracing when !RCU
From: Steven Rostedt @ 2020-02-14 22:48 UTC (permalink / raw)
  To: Kim Phillips
  Cc: Peter Zijlstra, linux-kernel, linux-arch, mingo, joel, gregkh,
	gustavo, tglx, paulmck, josh, mathieu.desnoyers, jiangshanlai
In-Reply-To: <121a6b11-2fe1-6d9b-2861-a8ef8b42c452@amd.com>

On Fri, 14 Feb 2020 14:38:14 -0600
Kim Phillips <kim.phillips@amd.com> wrote:

> On 2/12/20 3:01 PM, Peter Zijlstra wrote:
> > Since perf is now able to deal with !rcu_is_watching() contexts,
> > remove the restraint.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> >  kernel/trace/trace_event_perf.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- a/kernel/trace/trace_event_perf.c
> > +++ b/kernel/trace/trace_event_perf.c
> > @@ -477,7 +477,7 @@ static int perf_ftrace_function_register
> >  {
> >  	struct ftrace_ops *ops = &event->ftrace_ops;
> >  
> > -	ops->flags   = FTRACE_OPS_FL_RCU;
> > +	ops->flags   = 0;
> >  	ops->func    = perf_ftrace_function_call;
> >  	ops->private = (void *)(unsigned long)nr_cpu_ids;  
> 
> If this is the last user of the flag, should all remaining
> FTRACE_OPS_FL_RCU references be removed, too?

Let's wait till Peter's patches goes through a merge cycle or two. I
want to make sure there's no other RCU issues that pop up before we
remove this infrastructure.

-- Steve

^ permalink raw reply

* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Shakeel Butt @ 2020-02-14 22:48 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Johannes Weiner, Tejun Heo, Greg Thelen, Michal Hocko,
	Vladimir Davydov, Andrew Morton, Cgroups, linux-mm,
	Roman Gushchin, LKML
In-Reply-To: <CANn89iLe7KVjaechEhtV4=QRy4s8qBQDiX9e8LX_xq8tunrQNA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Feb 14, 2020 at 2:38 PM Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Fri, Feb 14, 2020 at 2:24 PM Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > We are testing network memory accounting in our setup and noticed
> > inconsistent network memory usage and often unrelated cgroups network
> > usage correlates with testing workload. On further inspection, it
> > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> > irq context specially for cgroup v1.
> >
> > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> > and kind of assumes that this can only happen from sk_clone_lock()
> > and the source sock object has already associated cgroup. However in
> > cgroup v1, where network memory accounting is opt-in, the source sock
> > can be unassociated with any cgroup and the new cloned sock can get
> > associated with unrelated interrupted cgroup.
> >
> > Cgroup v2 can also suffer if the source sock object was created by
> > process in the root cgroup or if sk_alloc() is called in irq context.
> > The fix is to just do nothing in interrupt.
>
> So, when will the association be done ?
> At accept() time ?
> Is it done already ?
>

I think in the current code if the association is skipped at
allocation time then the sock will remain unassociated for its
lifetime.

Maybe we can add the association in the later stages but it seems like
it is not a simple task i.e. edbe69ef2c90f ("Revert "defer call to
mem_cgroup_sk_alloc()"").

Shakeel

^ permalink raw reply

* [meta-oe][PATCH] packagegroup-meta-oe: Remove python2 packages from packagegroup-meta-oe-devtools
From: Khem Raj @ 2020-02-14 22:47 UTC (permalink / raw)
  To: openembedded-devel

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
index 777623ba88..bad4aa769e 100644
--- a/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
+++ b/meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
@@ -116,7 +116,6 @@ RDEPENDS_packagegroup-meta-oe-devtools ="\
     mpich msgpack-c nlohmann-json openocd pax-utils \
     ipc-run libdbd-mysql-perl libdbi-perl libio-pty-perl php \
     protobuf protobuf-c python3-distutils-extra \
-    python-cpuset python-distutils-extra python-futures python-pygobject \
     rapidjson serialcheck sip3 tclap uftrace uw-imap valijson \
     xmlrpc-c yajl yasm \
     ${@bb.utils.contains("DISTRO_FEATURES", "x11", "geany geany-plugins glade tk", "", d)} \
-- 
2.25.0



^ permalink raw reply related

* [PATCH 1/7] of/address: Move range parser code out of CONFIG_PCI
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig
In-Reply-To: <20200214224322.20030-1-robh@kernel.org>

In preparation to make the range parsing code work for non-PCI buses,
move the parsing functions out from the CONFIG_PCI #ifdef.

Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/of/address.c | 215 ++++++++++++++++++++++---------------------
 1 file changed, 109 insertions(+), 106 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index e8a39c3ec4d4..846045a48395 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -100,6 +100,28 @@ static unsigned int of_bus_default_get_flags(const __be32 *addr)
 	return IORESOURCE_MEM;
 }
 
+static unsigned int of_bus_pci_get_flags(const __be32 *addr)
+{
+	unsigned int flags = 0;
+	u32 w = be32_to_cpup(addr);
+
+	if (!IS_ENABLED(CONFIG_PCI))
+		return 0;
+
+	switch((w >> 24) & 0x03) {
+	case 0x01:
+		flags |= IORESOURCE_IO;
+		break;
+	case 0x02: /* 32 bits */
+	case 0x03: /* 64 bits */
+		flags |= IORESOURCE_MEM;
+		break;
+	}
+	if (w & 0x40000000)
+		flags |= IORESOURCE_PREFETCH;
+	return flags;
+}
+
 #ifdef CONFIG_PCI
 /*
  * PCI bus specific translator
@@ -125,25 +147,6 @@ static void of_bus_pci_count_cells(struct device_node *np,
 		*sizec = 2;
 }
 
-static unsigned int of_bus_pci_get_flags(const __be32 *addr)
-{
-	unsigned int flags = 0;
-	u32 w = be32_to_cpup(addr);
-
-	switch((w >> 24) & 0x03) {
-	case 0x01:
-		flags |= IORESOURCE_IO;
-		break;
-	case 0x02: /* 32 bits */
-	case 0x03: /* 64 bits */
-		flags |= IORESOURCE_MEM;
-		break;
-	}
-	if (w & 0x40000000)
-		flags |= IORESOURCE_PREFETCH;
-	return flags;
-}
-
 static u64 of_bus_pci_map(__be32 *addr, const __be32 *range, int na, int ns,
 		int pna)
 {
@@ -234,93 +237,6 @@ int of_pci_address_to_resource(struct device_node *dev, int bar,
 }
 EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
 
-static int parser_init(struct of_pci_range_parser *parser,
-			struct device_node *node, const char *name)
-{
-	const int na = 3, ns = 2;
-	int rlen;
-
-	parser->node = node;
-	parser->pna = of_n_addr_cells(node);
-	parser->np = parser->pna + na + ns;
-	parser->dma = !strcmp(name, "dma-ranges");
-
-	parser->range = of_get_property(node, name, &rlen);
-	if (parser->range == NULL)
-		return -ENOENT;
-
-	parser->end = parser->range + rlen / sizeof(__be32);
-
-	return 0;
-}
-
-int of_pci_range_parser_init(struct of_pci_range_parser *parser,
-				struct device_node *node)
-{
-	return parser_init(parser, node, "ranges");
-}
-EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
-
-int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
-				struct device_node *node)
-{
-	return parser_init(parser, node, "dma-ranges");
-}
-EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init);
-
-struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
-						struct of_pci_range *range)
-{
-	const int na = 3, ns = 2;
-
-	if (!range)
-		return NULL;
-
-	if (!parser->range || parser->range + parser->np > parser->end)
-		return NULL;
-
-	range->pci_space = be32_to_cpup(parser->range);
-	range->flags = of_bus_pci_get_flags(parser->range);
-	range->pci_addr = of_read_number(parser->range + 1, ns);
-	if (parser->dma)
-		range->cpu_addr = of_translate_dma_address(parser->node,
-				parser->range + na);
-	else
-		range->cpu_addr = of_translate_address(parser->node,
-				parser->range + na);
-	range->size = of_read_number(parser->range + parser->pna + na, ns);
-
-	parser->range += parser->np;
-
-	/* Now consume following elements while they are contiguous */
-	while (parser->range + parser->np <= parser->end) {
-		u32 flags;
-		u64 pci_addr, cpu_addr, size;
-
-		flags = of_bus_pci_get_flags(parser->range);
-		pci_addr = of_read_number(parser->range + 1, ns);
-		if (parser->dma)
-			cpu_addr = of_translate_dma_address(parser->node,
-					parser->range + na);
-		else
-			cpu_addr = of_translate_address(parser->node,
-					parser->range + na);
-		size = of_read_number(parser->range + parser->pna + na, ns);
-
-		if (flags != range->flags)
-			break;
-		if (pci_addr != range->pci_addr + range->size ||
-		    cpu_addr != range->cpu_addr + range->size)
-			break;
-
-		range->size += size;
-		parser->range += parser->np;
-	}
-
-	return range;
-}
-EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
-
 /*
  * of_pci_range_to_resource - Create a resource from an of_pci_range
  * @range:	the PCI range that describes the resource
@@ -775,6 +691,93 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+static int parser_init(struct of_pci_range_parser *parser,
+			struct device_node *node, const char *name)
+{
+	const int na = 3, ns = 2;
+	int rlen;
+
+	parser->node = node;
+	parser->pna = of_n_addr_cells(node);
+	parser->np = parser->pna + na + ns;
+	parser->dma = !strcmp(name, "dma-ranges");
+
+	parser->range = of_get_property(node, name, &rlen);
+	if (parser->range == NULL)
+		return -ENOENT;
+
+	parser->end = parser->range + rlen / sizeof(__be32);
+
+	return 0;
+}
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+				struct device_node *node)
+{
+	return parser_init(parser, node, "ranges");
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+int of_pci_dma_range_parser_init(struct of_pci_range_parser *parser,
+				struct device_node *node)
+{
+	return parser_init(parser, node, "dma-ranges");
+}
+EXPORT_SYMBOL_GPL(of_pci_dma_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser *parser,
+						struct of_pci_range *range)
+{
+	const int na = 3, ns = 2;
+
+	if (!range)
+		return NULL;
+
+	if (!parser->range || parser->range + parser->np > parser->end)
+		return NULL;
+
+	range->pci_space = be32_to_cpup(parser->range);
+	range->flags = of_bus_pci_get_flags(parser->range);
+	range->pci_addr = of_read_number(parser->range + 1, ns);
+	if (parser->dma)
+		range->cpu_addr = of_translate_dma_address(parser->node,
+				parser->range + na);
+	else
+		range->cpu_addr = of_translate_address(parser->node,
+				parser->range + na);
+	range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+	parser->range += parser->np;
+
+	/* Now consume following elements while they are contiguous */
+	while (parser->range + parser->np <= parser->end) {
+		u32 flags;
+		u64 pci_addr, cpu_addr, size;
+
+		flags = of_bus_pci_get_flags(parser->range);
+		pci_addr = of_read_number(parser->range + 1, ns);
+		if (parser->dma)
+			cpu_addr = of_translate_dma_address(parser->node,
+					parser->range + na);
+		else
+			cpu_addr = of_translate_address(parser->node,
+					parser->range + na);
+		size = of_read_number(parser->range + parser->pna + na, ns);
+
+		if (flags != range->flags)
+			break;
+		if (pci_addr != range->pci_addr + range->size ||
+		    cpu_addr != range->cpu_addr + range->size)
+			break;
+
+		range->size += size;
+		parser->range += parser->np;
+	}
+
+	return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
 static u64 of_translate_ioport(struct device_node *dev, const __be32 *in_addr,
 			u64 size)
 {
-- 
2.20.1


^ permalink raw reply related

* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
From: Alistair Francis @ 2020-02-14 22:39 UTC (permalink / raw)
  To: Joseph Myers
  Cc: Florian Weimer, GNU C Library, Arnd Bergmann, Vineet Gupta,
	Palmer Dabbelt, Zong Li, Alistair Francis, Adhemerval Zanella,
	Maciej W. Rozycki, arcml
In-Reply-To: <alpine.DEB.2.21.2002120123230.3988@digraph.polyomino.org.uk>

On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 11 Feb 2020, Alistair Francis wrote:
>
> > > > diff --git a/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> > > > new file mode 100644
> > > > index 0000000000..0da3bdeb5d
> > > > --- /dev/null
> > > > +++ b/sysdeps/unix/sysv/linux/riscv/bits/typesizes.h
> > >
> > > I was hoping newer arches could simply use the asm-generic one ?
> >
> > We need to specify that RV32 uses a 64-bit time_t. The generic ones
> > don't do that for 32-bit arches.
>
> Since it seems we'd like future 32-bit ports of glibc to use 64-bit time
> and offsets, we should make that as easy as possible.
>
> That is, you need an RISC-V-specific bits/timesize.h.  But you shouldn't
> need an RISC-V-specific bits/typesizes.h - rather, make the linux/generic
> one do the right thing for __TIME_T_TYPE based on bits/timesize.h.  And
> have some other header that 32-bit linux/generic ports can use to say
> whether they use the 64-bit offset/stat/statfs interface, that
> bits/typesizes.h can use together with its existing __LP64__ check, and
> make the definitions of __OFF_T_TYPE etc. check that as well, and then you
> shouldn't need an RISC-V-specific bits/typesizes.h - the RISC-V-specific
> headers should be strictly minimal.  (No architecture-specific
> bits/time64.h headers should be needed in any case.)

Ok, I have updated this. I'll send the patch once my "Always use
32-bit time_t for certain syscalls" series is in (the headers are
changed in that series).

Alistair

>
> At some point (or indeed now) we might flip the default for linux/generic
> so the architectures needing an architecture-specific header are only the
> older 32-bit linux/generic architectures that have support for 32-bit
> times and offsets, and the newer ones with no such support don't need such
> a header.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

^ permalink raw reply

* [PATCH 0/7] of: Support multiple dma-ranges entries
From: Rob Herring @ 2020-02-14 22:43 UTC (permalink / raw)
  To: devicetree, Frank Rowand
  Cc: Michal Simek, Arnd Bergmann, Linus Walleij, linuxppc-dev,
	linux-kernel, Paul Mackerras, Robin Murphy, Christoph Hellwig

The DT DMA offset and mask/size setup for the DMA API only parses the 
first dma-ranges entry. This is not sufficient for some platforms. As we 
already support multiple ranges entries for the PCI specific parsing 
functions, let's refactor those to be general enough to handle both PCI 
and normal buses. Then we can have one instance of range parsing code by 
using it in of_dma_get_range().

Rob

Rob Herring (7):
  of/address: Move range parser code out of CONFIG_PCI
  microblaze: Drop using struct of_pci_range.pci_space field
  powerpc: Drop using struct of_pci_range.pci_space field
  of: Drop struct of_pci_range.pci_space field
  of/address: Rework of_pci_range parsing for non-PCI buses
  of/address: use range parser for of_dma_get_range
  of/address: Support multiple 'dma-ranges' entries

 arch/microblaze/pci/pci-common.c |   7 +-
 arch/powerpc/kernel/pci-common.c |   2 +-
 drivers/of/address.c             | 273 +++++++++++++++++--------------
 include/linux/of_address.h       |  13 +-
 4 files changed, 157 insertions(+), 138 deletions(-)


base-commit: bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9
-- 
2.20.1


^ permalink raw reply

* Re: [PATCH v2] cgroup: memcg: net: do not associate sock with unrelated cgroup
From: Shakeel Butt @ 2020-02-14 22:44 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: Johannes Weiner, Eric Dumazet, Tejun Heo, Greg Thelen,
	Michal Hocko, Vladimir Davydov, Andrew Morton, Cgroups, Linux MM,
	LKML
In-Reply-To: <20200214223303.GA60585@carbon.dhcp.thefacebook.com>

On Fri, Feb 14, 2020 at 2:33 PM Roman Gushchin <guro@fb.com> wrote:
>
> On Fri, Feb 14, 2020 at 02:24:15PM -0800, Shakeel Butt wrote:
> > We are testing network memory accounting in our setup and noticed
> > inconsistent network memory usage and often unrelated cgroups network
> > usage correlates with testing workload. On further inspection, it
> > seems like mem_cgroup_sk_alloc() and cgroup_sk_alloc() are broken in
> > irq context specially for cgroup v1.
> >
> > mem_cgroup_sk_alloc() and cgroup_sk_alloc() can be called in irq context
> > and kind of assumes that this can only happen from sk_clone_lock()
> > and the source sock object has already associated cgroup. However in
> > cgroup v1, where network memory accounting is opt-in, the source sock
> > can be unassociated with any cgroup and the new cloned sock can get
> > associated with unrelated interrupted cgroup.
> >
> > Cgroup v2 can also suffer if the source sock object was created by
> > process in the root cgroup or if sk_alloc() is called in irq context.
> > The fix is to just do nothing in interrupt.
> >
> > Fixes: 2d7580738345 ("mm: memcontrol: consolidate cgroup socket tracking")
> > Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
> > Signed-off-by: Shakeel Butt <shakeelb@google.com>
> > ---
> >
> > Changes since v1:
> > - Fix cgroup_sk_alloc() too.
> >
> >  kernel/cgroup/cgroup.c | 4 ++++
> >  mm/memcontrol.c        | 4 ++++
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> > index 9a8a5ded3c48..46e5f5518fba 100644
> > --- a/kernel/cgroup/cgroup.c
> > +++ b/kernel/cgroup/cgroup.c
> > @@ -6449,6 +6449,10 @@ void cgroup_sk_alloc(struct sock_cgroup_data *skcd)
> >               return;
> >       }
> >
> > +     /* Do not associate the sock with unrelated interrupted task's memcg. */
>                                                                        ^^^^^
>                                                                        cgroup?
> > +     if (in_interrupt())
> > +             return;
> > +
> >       rcu_read_lock();
> >
> >       while (true) {
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 63bb6a2aab81..f500da82bfe8 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -6697,6 +6697,10 @@ void mem_cgroup_sk_alloc(struct sock *sk)
> >               return;
> >       }
>
> Can you, please, include the stacktrace into the commit log?
> Except a minor typo (see above),
> Reviewed-by: Roman Gushchin <guro@fb.com>
>
> A really good catch.
>

Thanks, I will add the stack trace and fix the typo.

Shakeel


^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.