* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Rich Felker @ 2015-08-26 2:16 UTC (permalink / raw)
To: Greg Ungerer
Cc: linux-embedded, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <55DD15AA.5040503@uclinux.org>
On Wed, Aug 26, 2015 at 11:26:02AM +1000, Greg Ungerer wrote:
> Hi Rich,
>
> On 21/08/15 05:11, Rich Felker wrote:
> > From: Rich Felker <dalias@libc.org>
> >
> > On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
> > overlap with all but the last PAGE_SIZE bytes of the stack. This leads
> > to catastrophic memory reuse/corruption if brk is used. Fix by setting
> > the brk area to zero size to disable its use.
> >
> > Signed-off-by: Rich Felker <dalias@libc.org>
>
> It would make sense to run this by David Howells <dhowells@redhat.com>,
> I think he wrote this code (added to CC list).
Thanks. I have another follow-up patch to submit soon that uses the
existing ELF_FDPIC_FLAG_CONSTDISP code in binfmt_elf_fdpic.c to load
normal, non-FDPIC ELF files on NOMMU, so I'll make sure to CC him on
that too.
> I have no problem with it, so:
>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
>
> > ---
> >
> > There is no reason for the kernel to be providing a brk area at all on
> > NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
> > NOMMU targets, and musl libc goes out of its way to avoid using brk
> > that might run into the stack.
>
> I recall a long time back someone was playing with the idea of setting
> the brk to the unused parts of the last data area page. (Somewhat like
> this code seems to be trying). That scheme still allocated the full
> requested stack size (IIRC) though. And that would have been on bFLT
> executables. Anyway, just some historical reference, not really
> relevant now.
For what it's worth, musl's malloc rounds the initial brk up to a page
boundary, but the dynamic linker recovers any partial page at the end
of the data segment and donates it to malloc without brk's help. So
even though brk will fail and malloc will fall back to mmap, this
otherwise-wasted space does get recovered and used.
Rich
^ permalink raw reply
* Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Greg Ungerer @ 2015-08-26 1:26 UTC (permalink / raw)
To: Rich Felker, linux-embedded
Cc: Paul Gortmaker, Matt Mackall, David Woodhouse, Alexander Viro,
linux-fsdevel, linux-kernel, David Howells
In-Reply-To: <20150820191106.GA9655@brightrain.aerifal.cx>
Hi Rich,
On 21/08/15 05:11, Rich Felker wrote:
> From: Rich Felker <dalias@libc.org>
>
> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
> overlap with all but the last PAGE_SIZE bytes of the stack. This leads
> to catastrophic memory reuse/corruption if brk is used. Fix by setting
> the brk area to zero size to disable its use.
>
> Signed-off-by: Rich Felker <dalias@libc.org>
It would make sense to run this by David Howells <dhowells@redhat.com>,
I think he wrote this code (added to CC list).
I have no problem with it, so:
Acked-by: Greg Ungerer <gerg@uclinux.org>
> ---
>
> There is no reason for the kernel to be providing a brk area at all on
> NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
> NOMMU targets, and musl libc goes out of its way to avoid using brk
> that might run into the stack.
I recall a long time back someone was playing with the idea of setting
the brk to the unused parts of the last data area page. (Somewhat like
this code seems to be trying). That scheme still allocated the full
requested stack size (IIRC) though. And that would have been on bFLT
executables. Anyway, just some historical reference, not really
relevant now.
Regards
Greg
> --- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 +0000
> +++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 +0000
> @@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct
> PAGE_ALIGN(current->mm->start_brk);
>
> #else
> - /* create a stack and brk area big enough for everyone
> - * - the brk heap starts at the bottom and works up
> - * - the stack starts at the top and works down
> - */
> + /* create a stack area and zero-size brk area */
> stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK;
> if (stack_size < PAGE_SIZE * 2)
> stack_size = PAGE_SIZE * 2;
> @@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct
>
> current->mm->brk = current->mm->start_brk;
> current->mm->context.end_brk = current->mm->start_brk;
> - current->mm->context.end_brk +=
> - (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0;
> current->mm->start_stack = current->mm->start_brk + stack_size;
> #endif
>
>
^ permalink raw reply
* [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
From: Rich Felker @ 2015-08-20 19:11 UTC (permalink / raw)
To: linux-embedded
Cc: Greg Ungerer, Paul Gortmaker, Matt Mackall, David Woodhouse,
Alexander Viro, linux-fsdevel, linux-kernel
From: Rich Felker <dalias@libc.org>
On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to
overlap with all but the last PAGE_SIZE bytes of the stack. This leads
to catastrophic memory reuse/corruption if brk is used. Fix by setting
the brk area to zero size to disable its use.
Signed-off-by: Rich Felker <dalias@libc.org>
---
There is no reason for the kernel to be providing a brk area at all on
NOMMU; the bFLT loader does not provide one, uClibc never uses brk on
NOMMU targets, and musl libc goes out of its way to avoid using brk
that might run into the stack.
--- fs/binfmt_elf_fdpic.c.orig 2015-08-20 18:05:19.089888654 +0000
+++ fs/binfmt_elf_fdpic.c 2015-08-20 18:10:01.519871432 +0000
@@ -374,10 +388,7 @@ static int load_elf_fdpic_binary(struct
PAGE_ALIGN(current->mm->start_brk);
#else
- /* create a stack and brk area big enough for everyone
- * - the brk heap starts at the bottom and works up
- * - the stack starts at the top and works down
- */
+ /* create a stack area and zero-size brk area */
stack_size = (stack_size + PAGE_SIZE - 1) & PAGE_MASK;
if (stack_size < PAGE_SIZE * 2)
stack_size = PAGE_SIZE * 2;
@@ -400,8 +411,6 @@ static int load_elf_fdpic_binary(struct
current->mm->brk = current->mm->start_brk;
current->mm->context.end_brk = current->mm->start_brk;
- current->mm->context.end_brk +=
- (stack_size > PAGE_SIZE) ? (stack_size - PAGE_SIZE) : 0;
current->mm->start_stack = current->mm->start_brk + stack_size;
#endif
^ permalink raw reply
* [PATCH v3 v4.2-rc1] printk: make extended printk support conditional on netconsole
From: Tejun Heo @ 2015-07-03 16:22 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: pmladek, David S. Miller, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Kay Sievers, Josh Triplett,
Linux Embedded, Geert Uytterhoeven
In-Reply-To: <20150702162141.GC30677@mtj.duckdns.org>
6fe29354befe ("printk: implement support for extended console
drivers") implemented extended printk support for extended netconsole.
The code added was miniscule but it added static 8k buffer
unconditionally unnecessarily bloating the kernel for cases where
extended netconsole is not used.
This patch introduces CONFIG_PRINTK_CON_EXTENDED which is selected by
CONFIG_NETCONSOLE. If the config option is not set, extended printk
support is compiled out along with the static buffer.
Verified 8k reduction in vmlinux bss when !CONFIG_NETCONSOLE.
v2: Added a warning for cases where CON_EXTENDED is requested while
CONFIG_PRINTK_CON_EXTENDED is disabled as suggested by Petr.
v3: Moved ext console enable info messages into the inc function.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
---
drivers/net/Kconfig | 1 +
init/Kconfig | 3 +++
kernel/printk/printk.c | 38 ++++++++++++++++++++++++++++++++++----
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 019fcef..39587f1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -195,6 +195,7 @@ config GENEVE
config NETCONSOLE
tristate "Network console logging support"
+ select PRINTK_CON_EXTENDED
---help---
If you want to log kernel messages over the network, enable this.
See <file:Documentation/networking/netconsole.txt> for details.
diff --git a/init/Kconfig b/init/Kconfig
index bcc41bd..cd281ab 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1438,6 +1438,9 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CON_EXTENDED
+ bool
+
config BUG
bool "BUG() support" if EXPERT
default y
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index cf8c242..841ea4d 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -84,6 +84,10 @@ static struct lockdep_map console_lock_dep_map = {
};
#endif
+#ifdef CONFIG_PRINTK_CON_EXTENDED
+
+#define CONSOLE_EXT_LOG_BUF_LEN CONSOLE_EXT_LOG_MAX
+
/*
* Number of registered extended console drivers.
*
@@ -96,6 +100,33 @@ static struct lockdep_map console_lock_dep_map = {
*/
static int nr_ext_console_drivers;
+static void inc_nr_ext_console_drivers(void)
+{
+ if (!nr_ext_console_drivers++)
+ pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
+}
+
+static void dec_nr_ext_console_drivers(void)
+{
+ nr_ext_console_drivers--;
+}
+
+#else /* CONFIG_PRINTK_CON_EXTENDED */
+
+#define CONSOLE_EXT_LOG_BUF_LEN 0
+#define nr_ext_console_drivers 0
+
+static void inc_nr_ext_console_drivers(void)
+{
+ WARN_ONCE(true, "printk: CON_EXTENDED requested when !CONFIG_PRINTK_CON_EXTENDED\n");
+}
+
+static void dec_nr_ext_console_drivers(void)
+{
+}
+
+#endif /* CONFIG_PRINTK_CON_EXTENDED */
+
/*
* Helper macros to handle lockdep when locking/unlocking console_sem. We use
* macros instead of functions so that _RET_IP_ contains useful information.
@@ -2224,7 +2255,7 @@ static void console_cont_flush(char *text, size_t size)
*/
void console_unlock(void)
{
- static char ext_text[CONSOLE_EXT_LOG_MAX];
+ static char ext_text[CONSOLE_EXT_LOG_BUF_LEN];
static char text[LOG_LINE_MAX + PREFIX_MAX];
static u64 seen_seq;
unsigned long flags;
@@ -2562,8 +2593,7 @@ void register_console(struct console *newcon)
}
if (newcon->flags & CON_EXTENDED)
- if (!nr_ext_console_drivers++)
- pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
+ inc_nr_ext_console_drivers();
if (newcon->flags & CON_PRINTBUFFER) {
/*
@@ -2638,7 +2668,7 @@ int unregister_console(struct console *console)
}
if (!res && (console->flags & CON_EXTENDED))
- nr_ext_console_drivers--;
+ dec_nr_ext_console_drivers();
/*
* If this isn't the last console and it has CON_CONSDEV set, we
^ permalink raw reply related
* Re: [PATCH v2 v4.2-rc1] printk: make extended printk support conditional on netconsole
From: Tejun Heo @ 2015-07-03 15:25 UTC (permalink / raw)
To: Petr Mladek
Cc: Linus Torvalds, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded, geert
In-Reply-To: <20150703140352.GD32664@pathway.suse.cz>
On Fri, Jul 03, 2015 at 04:07:34PM +0200, Petr Mladek wrote:
> > @@ -2561,9 +2591,11 @@ void register_console(struct console *newcon)
> > console_drivers->next = newcon;
> > }
> >
> > - if (newcon->flags & CON_EXTENDED)
> > - if (!nr_ext_console_drivers++)
> > + if (newcon->flags & CON_EXTENDED) {
> > + if (!nr_ext_console_drivers)
> > pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
>
> I would move the check and the message into
> inc_nr_ext_console_drivers() when CONFIG_PRINTK_CON_EXTENDED is
> defined. It does not make sense if we do not increment the counter.
It doesn't make any difference as it gets compiled out anyway but yeah
moving it into the inc function makes more sense. Updating the patch.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 v4.2-rc1] printk: make extended printk support conditional on netconsole
From: Petr Mladek @ 2015-07-03 14:07 UTC (permalink / raw)
To: Tejun Heo
Cc: Linus Torvalds, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded, geert
In-Reply-To: <20150702162141.GC30677@mtj.duckdns.org>
On Thu 2015-07-02 12:21:41, Tejun Heo wrote:
> 6fe29354befe ("printk: implement support for extended console
> drivers") implemented extended printk support for extended netconsole.
> The code added was miniscule but it added static 8k buffer
> unconditionally unnecessarily bloating the kernel for cases where
> extended netconsole is not used.
>
> This patch introduces CONFIG_PRINTK_CON_EXTENDED which is selected by
> CONFIG_NETCONSOLE. If the config option is not set, extended printk
> support is compiled out along with the static buffer.
>
> Verified 8k reduction in vmlinux bss when !CONFIG_NETCONSOLE.
>
> v2: Added a warning for cases where CON_EXTENDED is requested while
> CONFIG_PRINTK_CON_EXTENDED is disabled as suggested by Petr.
>
> Cc: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-and-suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Petr Mladek <pmladek@suse.cz>
There is still one small thing that might get improved, see below.
But it is not that important and might be solved later. I am sorry
for not noticing it last time.
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index cf8c242..f719118 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -84,6 +84,10 @@ static struct lockdep_map console_lock_dep_map = {
> };
> #endif
>
> +#ifdef CONFIG_PRINTK_CON_EXTENDED
> +
> +#define CONSOLE_EXT_LOG_BUF_LEN CONSOLE_EXT_LOG_MAX
> +
> /*
> * Number of registered extended console drivers.
> *
> @@ -96,6 +100,32 @@ static struct lockdep_map console_lock_dep_map = {
> */
> static int nr_ext_console_drivers;
>
> +static void inc_nr_ext_console_drivers(void)
> +{
> + nr_ext_console_drivers++;
> +}
> +
> +static void dec_nr_ext_console_drivers(void)
> +{
> + nr_ext_console_drivers--;
> +}
> +
> +#else /* CONFIG_PRINTK_CON_EXTENDED */
> +
> +#define CONSOLE_EXT_LOG_BUF_LEN 0
> +#define nr_ext_console_drivers 0
> +
> +static void inc_nr_ext_console_drivers(void)
> +{
> + WARN_ONCE(true, "printk: CON_EXTENDED requested when !CONFIG_PRINTK_CON_EXTENDED\n");
> +}
> +
> +static void dec_nr_ext_console_drivers(void)
> +{
> +}
> +
> +#endif /* CONFIG_PRINTK_CON_EXTENDED */
> +
> /*
> * Helper macros to handle lockdep when locking/unlocking console_sem. We use
> * macros instead of functions so that _RET_IP_ contains useful information.
> @@ -2561,9 +2591,11 @@ void register_console(struct console *newcon)
> console_drivers->next = newcon;
> }
>
> - if (newcon->flags & CON_EXTENDED)
> - if (!nr_ext_console_drivers++)
> + if (newcon->flags & CON_EXTENDED) {
> + if (!nr_ext_console_drivers)
> pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
I would move the check and the message into
inc_nr_ext_console_drivers() when CONFIG_PRINTK_CON_EXTENDED is
defined. It does not make sense if we do not increment the counter.
Best Regards,
Petr
^ permalink raw reply
* [PATCH v2 v4.2-rc1] printk: make extended printk support conditional on netconsole
From: Tejun Heo @ 2015-07-02 16:21 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: pmladek, David S. Miller, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Kay Sievers, Josh Triplett,
Linux Embedded, Geert Uytterhoeven
In-Reply-To: <20150629233140.GA7711@mtj.duckdns.org>
6fe29354befe ("printk: implement support for extended console
drivers") implemented extended printk support for extended netconsole.
The code added was miniscule but it added static 8k buffer
unconditionally unnecessarily bloating the kernel for cases where
extended netconsole is not used.
This patch introduces CONFIG_PRINTK_CON_EXTENDED which is selected by
CONFIG_NETCONSOLE. If the config option is not set, extended printk
support is compiled out along with the static buffer.
Verified 8k reduction in vmlinux bss when !CONFIG_NETCONSOLE.
v2: Added a warning for cases where CON_EXTENDED is requested while
CONFIG_PRINTK_CON_EXTENDED is disabled as suggested by Petr.
Cc: Petr Mladek <pmladek@suse.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/net/Kconfig | 1 +
init/Kconfig | 3 +++
kernel/printk/printk.c | 40 ++++++++++++++++++++++++++++++++++++----
3 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 019fcef..39587f1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -195,6 +195,7 @@ config GENEVE
config NETCONSOLE
tristate "Network console logging support"
+ select PRINTK_CON_EXTENDED
---help---
If you want to log kernel messages over the network, enable this.
See <file:Documentation/networking/netconsole.txt> for details.
diff --git a/init/Kconfig b/init/Kconfig
index bcc41bd..cd281ab 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1438,6 +1438,9 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CON_EXTENDED
+ bool
+
config BUG
bool "BUG() support" if EXPERT
default y
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index cf8c242..f719118 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -84,6 +84,10 @@ static struct lockdep_map console_lock_dep_map = {
};
#endif
+#ifdef CONFIG_PRINTK_CON_EXTENDED
+
+#define CONSOLE_EXT_LOG_BUF_LEN CONSOLE_EXT_LOG_MAX
+
/*
* Number of registered extended console drivers.
*
@@ -96,6 +100,32 @@ static struct lockdep_map console_lock_dep_map = {
*/
static int nr_ext_console_drivers;
+static void inc_nr_ext_console_drivers(void)
+{
+ nr_ext_console_drivers++;
+}
+
+static void dec_nr_ext_console_drivers(void)
+{
+ nr_ext_console_drivers--;
+}
+
+#else /* CONFIG_PRINTK_CON_EXTENDED */
+
+#define CONSOLE_EXT_LOG_BUF_LEN 0
+#define nr_ext_console_drivers 0
+
+static void inc_nr_ext_console_drivers(void)
+{
+ WARN_ONCE(true, "printk: CON_EXTENDED requested when !CONFIG_PRINTK_CON_EXTENDED\n");
+}
+
+static void dec_nr_ext_console_drivers(void)
+{
+}
+
+#endif /* CONFIG_PRINTK_CON_EXTENDED */
+
/*
* Helper macros to handle lockdep when locking/unlocking console_sem. We use
* macros instead of functions so that _RET_IP_ contains useful information.
@@ -2224,7 +2254,7 @@ static void console_cont_flush(char *text, size_t size)
*/
void console_unlock(void)
{
- static char ext_text[CONSOLE_EXT_LOG_MAX];
+ static char ext_text[CONSOLE_EXT_LOG_BUF_LEN];
static char text[LOG_LINE_MAX + PREFIX_MAX];
static u64 seen_seq;
unsigned long flags;
@@ -2561,9 +2591,11 @@ void register_console(struct console *newcon)
console_drivers->next = newcon;
}
- if (newcon->flags & CON_EXTENDED)
- if (!nr_ext_console_drivers++)
+ if (newcon->flags & CON_EXTENDED) {
+ if (!nr_ext_console_drivers)
pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
+ inc_nr_ext_console_drivers();
+ }
if (newcon->flags & CON_PRINTBUFFER) {
/*
@@ -2638,7 +2670,7 @@ int unregister_console(struct console *console)
}
if (!res && (console->flags & CON_EXTENDED))
- nr_ext_console_drivers--;
+ dec_nr_ext_console_drivers();
/*
* If this isn't the last console and it has CON_CONSDEV set, we
^ permalink raw reply related
* Re: [PATCH v4.2-rc1] printk: make extended printk support conditional on netconsole
From: Petr Mladek @ 2015-07-01 16:05 UTC (permalink / raw)
To: Tejun Heo
Cc: Linus Torvalds, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded, Geert Uytterhoeven
In-Reply-To: <20150629233140.GA7711@mtj.duckdns.org>
On Mon 2015-06-29 19:31:40, Tejun Heo wrote:
> 6fe29354befe ("printk: implement support for extended console
> drivers") implemented extended printk support for extended netconsole.
> The code added was miniscule but it added static 8k buffer
> unconditionally unnecessarily bloating the kernel for cases where
> extended netconsole is not used.
>
> This patch introduces CONFIG_PRINTK_CON_EXTENDED which is selected by
> CONFIG_NETCONSOLE. If the config option is not set, extended printk
> support is compiled out along with the static buffer.
>
> Verified 8k reduction in vmlinux bss when !CONFIG_NETCONSOLE.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-and-suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> Linus, Andrew.
>
> This removes an unnecessary 8k bss bloat introduced during v4.2-rc1
> merge window on certain configs. The original patch was routed
> through -mm. How should this be routed?
>
> Thanks.
>
> drivers/net/Kconfig | 1 +
> init/Kconfig | 3 +++
> kernel/printk/printk.c | 33 +++++++++++++++++++++++++++++----
> 3 files changed, 33 insertions(+), 4 deletions(-)
[...]
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
[...]
> @@ -2561,9 +2584,11 @@ void register_console(struct console *ne
> console_drivers->next = newcon;
> }
>
> - if (newcon->flags & CON_EXTENDED)
> - if (!nr_ext_console_drivers++)
> + if (newcon->flags & CON_EXTENDED) {
> + if (!nr_ext_console_drivers)
> pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
> + inc_nr_ext_console_drivers();
We should handle also the situation when CON_EXTENDED is set
and CONFIG_PRINTK_CON_EXTENDED is not set by mistake. Otherwise,
we will not increment nr_ext_console_drivers here => ext_text will
not be filled in console_unlock() => call_console_drivers()
will print nothing for the CON_EXTENDED console.
At least, I would print an error here. Something like.
#ifndef CONFIG_PRINTK_CON_EXTENDED
pr_err("The registered extended console will print nothing because the kernel is not compiled with PRINTK_CON_EXTENDED\n");
#endif
I wonder if there is a good identification of the console that can be printed.
Otherwise, it looks fine to me.
Best Regards,
Petr
^ permalink raw reply
* [PATCH v4.2-rc1] printk: make extended printk support conditional on netconsole
From: Tejun Heo @ 2015-06-29 23:31 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: pmladek, David S. Miller, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Kay Sievers, Josh Triplett,
Linux Embedded, Geert Uytterhoeven
In-Reply-To: <20150629161355.GS15805@mtj.duckdns.org>
6fe29354befe ("printk: implement support for extended console
drivers") implemented extended printk support for extended netconsole.
The code added was miniscule but it added static 8k buffer
unconditionally unnecessarily bloating the kernel for cases where
extended netconsole is not used.
This patch introduces CONFIG_PRINTK_CON_EXTENDED which is selected by
CONFIG_NETCONSOLE. If the config option is not set, extended printk
support is compiled out along with the static buffer.
Verified 8k reduction in vmlinux bss when !CONFIG_NETCONSOLE.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Linus, Andrew.
This removes an unnecessary 8k bss bloat introduced during v4.2-rc1
merge window on certain configs. The original patch was routed
through -mm. How should this be routed?
Thanks.
drivers/net/Kconfig | 1 +
init/Kconfig | 3 +++
kernel/printk/printk.c | 33 +++++++++++++++++++++++++++++----
3 files changed, 33 insertions(+), 4 deletions(-)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -195,6 +195,7 @@ config GENEVE
config NETCONSOLE
tristate "Network console logging support"
+ select PRINTK_CON_EXTENDED
---help---
If you want to log kernel messages over the network, enable this.
See <file:Documentation/networking/netconsole.txt> for details.
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1438,6 +1438,9 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CON_EXTENDED
+ bool
+
config BUG
bool "BUG() support" if EXPERT
default y
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -84,6 +84,10 @@ static struct lockdep_map console_lock_d
};
#endif
+#ifdef CONFIG_PRINTK_CON_EXTENDED
+
+#define CONSOLE_EXT_LOG_BUF_LEN CONSOLE_EXT_LOG_MAX
+
/*
* Number of registered extended console drivers.
*
@@ -96,6 +100,25 @@ static struct lockdep_map console_lock_d
*/
static int nr_ext_console_drivers;
+static void inc_nr_ext_console_drivers(void)
+{
+ nr_ext_console_drivers++;
+}
+
+static void dec_nr_ext_console_drivers(void)
+{
+ nr_ext_console_drivers--;
+}
+
+#else /* CONFIG_PRINTK_CON_EXTENDED */
+
+#define CONSOLE_EXT_LOG_BUF_LEN 0
+#define nr_ext_console_drivers 0
+static void inc_nr_ext_console_drivers(void) { }
+static void dec_nr_ext_console_drivers(void) { }
+
+#endif /* CONFIG_PRINTK_CON_EXTENDED */
+
/*
* Helper macros to handle lockdep when locking/unlocking console_sem. We use
* macros instead of functions so that _RET_IP_ contains useful information.
@@ -2224,7 +2247,7 @@ out:
*/
void console_unlock(void)
{
- static char ext_text[CONSOLE_EXT_LOG_MAX];
+ static char ext_text[CONSOLE_EXT_LOG_BUF_LEN];
static char text[LOG_LINE_MAX + PREFIX_MAX];
static u64 seen_seq;
unsigned long flags;
@@ -2561,9 +2584,11 @@ void register_console(struct console *ne
console_drivers->next = newcon;
}
- if (newcon->flags & CON_EXTENDED)
- if (!nr_ext_console_drivers++)
+ if (newcon->flags & CON_EXTENDED) {
+ if (!nr_ext_console_drivers)
pr_info("printk: continuation disabled due to ext consoles, expect more fragments in /dev/kmsg\n");
+ inc_nr_ext_console_drivers();
+ }
if (newcon->flags & CON_PRINTBUFFER) {
/*
@@ -2638,7 +2663,7 @@ int unregister_console(struct console *c
}
if (!res && (console->flags & CON_EXTENDED))
- nr_ext_console_drivers--;
+ dec_nr_ext_console_drivers();
/*
* If this isn't the last console and it has CON_CONSDEV set, we
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: josh @ 2015-06-29 16:50 UTC (permalink / raw)
To: Tejun Heo
Cc: Geert Uytterhoeven, pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Linux Embedded
In-Reply-To: <20150629161355.GS15805@mtj.duckdns.org>
On Mon, Jun 29, 2015 at 12:13:55PM -0400, Tejun Heo wrote:
> On Mon, Jun 29, 2015 at 06:11:40PM +0200, Geert Uytterhoeven wrote:
> > On Mon, Jun 29, 2015 at 5:49 PM, Tejun Heo <tj@kernel.org> wrote:
> > > On Mon, Jun 29, 2015 at 05:47:49PM +0200, Geert Uytterhoeven wrote:
> > >> > netconsole itself is optional & modular. I'm not sure making further
> > >> > splits is called for, especially given the use cases.
> > >>
> > >> It could be a hidden option, selected by its users (e.g. netconsole).
> > >
> > > Hmmm... what do you mean?
> >
> > init/Kconfig:
> >
> > config PRINTK_EXT_LOG
> > bool
> >
> > drivers/net/Kconfig:
> >
> > config NETCONSOLE
> > tristate "Network console logging support"
> > select PRINTK_EXT_LOG
> >
> > kernel/printk/printk.c:
> >
> > void console_unlock(void)
> > {
> > #ifdef CONFIG_PRINTK_EXT_LOG
> > static char ext_text[CONSOLE_EXT_LOG_MAX];
> > #endif
>
> OIC, hmmm... yeah, I think doing it on-demand would be better but will
> try to find out which way is better.
Allocating the buffer dynamically is fine, but in that case the code to
do so should ideally be compiled out. Since printk is used by almost
*all* kernels, while netconsole is not, it's more critical to avoid
allowing printk's size to balloon.
- Josh Triplett
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: Tejun Heo @ 2015-06-29 16:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded
In-Reply-To: <CAMuHMdX-cA3RccXF2kBifMEyT8e14rURp9Li_WFm7ODBOti=QQ@mail.gmail.com>
On Mon, Jun 29, 2015 at 06:11:40PM +0200, Geert Uytterhoeven wrote:
> On Mon, Jun 29, 2015 at 5:49 PM, Tejun Heo <tj@kernel.org> wrote:
> > On Mon, Jun 29, 2015 at 05:47:49PM +0200, Geert Uytterhoeven wrote:
> >> > netconsole itself is optional & modular. I'm not sure making further
> >> > splits is called for, especially given the use cases.
> >>
> >> It could be a hidden option, selected by its users (e.g. netconsole).
> >
> > Hmmm... what do you mean?
>
> init/Kconfig:
>
> config PRINTK_EXT_LOG
> bool
>
> drivers/net/Kconfig:
>
> config NETCONSOLE
> tristate "Network console logging support"
> select PRINTK_EXT_LOG
>
> kernel/printk/printk.c:
>
> void console_unlock(void)
> {
> #ifdef CONFIG_PRINTK_EXT_LOG
> static char ext_text[CONSOLE_EXT_LOG_MAX];
> #endif
OIC, hmmm... yeah, I think doing it on-demand would be better but will
try to find out which way is better.
Thanks!
--
tejun
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: Geert Uytterhoeven @ 2015-06-29 16:11 UTC (permalink / raw)
To: Tejun Heo
Cc: pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded
In-Reply-To: <20150629154914.GQ15805@mtj.duckdns.org>
On Mon, Jun 29, 2015 at 5:49 PM, Tejun Heo <tj@kernel.org> wrote:
> On Mon, Jun 29, 2015 at 05:47:49PM +0200, Geert Uytterhoeven wrote:
>> > netconsole itself is optional & modular. I'm not sure making further
>> > splits is called for, especially given the use cases.
>>
>> It could be a hidden option, selected by its users (e.g. netconsole).
>
> Hmmm... what do you mean?
init/Kconfig:
config PRINTK_EXT_LOG
bool
drivers/net/Kconfig:
config NETCONSOLE
tristate "Network console logging support"
select PRINTK_EXT_LOG
kernel/printk/printk.c:
void console_unlock(void)
{
#ifdef CONFIG_PRINTK_EXT_LOG
static char ext_text[CONSOLE_EXT_LOG_MAX];
#endif
etc.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: josh @ 2015-06-29 16:11 UTC (permalink / raw)
To: Tejun Heo
Cc: Geert Uytterhoeven, pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Linux Embedded
In-Reply-To: <20150629154914.GQ15805@mtj.duckdns.org>
On Mon, Jun 29, 2015 at 11:49:14AM -0400, Tejun Heo wrote:
> On Mon, Jun 29, 2015 at 05:47:49PM +0200, Geert Uytterhoeven wrote:
> > > netconsole itself is optional & modular. I'm not sure making further
> > > splits is called for, especially given the use cases.
> >
> > It could be a hidden option, selected by its users (e.g. netconsole).
>
> Hmmm... what do you mean?
config PRINTK_BITS_THAT_NETCONSOLE_NEEDS
(no help text or prompt)
config NETCONSOLE
select PRINTK_BITS_THAT_NETCONSOLE_NEEDS
That would ensure that the bits added to printk don't get compiled in
unless CONFIG_NETCONSOLE=y.
- Josh Triplett
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: Tejun Heo @ 2015-06-29 15:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded
In-Reply-To: <CAMuHMdXTn0+z4PV9UVZZmpMdk_-JUc4x-GqZweOhQyYMTzSOGQ@mail.gmail.com>
On Mon, Jun 29, 2015 at 05:47:49PM +0200, Geert Uytterhoeven wrote:
> > netconsole itself is optional & modular. I'm not sure making further
> > splits is called for, especially given the use cases.
>
> It could be a hidden option, selected by its users (e.g. netconsole).
Hmmm... what do you mean?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: Geert Uytterhoeven @ 2015-06-29 15:47 UTC (permalink / raw)
To: Tejun Heo
Cc: pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded
In-Reply-To: <20150629152805.GM15805@mtj.duckdns.org>
Hi Tejun,
On Mon, Jun 29, 2015 at 5:28 PM, Tejun Heo <tj@kernel.org> wrote:
> On Mon, Jun 29, 2015 at 11:20:41AM +0200, Geert Uytterhoeven wrote:
>> On Wed, Apr 29, 2015 at 4:45 PM, Tejun Heo <tj@kernel.org> wrote:
>> > --- a/kernel/printk/printk.c
>> > +++ b/kernel/printk/printk.c
>>
>> > @@ -2196,6 +2227,7 @@ out:
>> > */
>> > void console_unlock(void)
>> > {
>> > + static char ext_text[CONSOLE_EXT_LOG_MAX];
>>
>> Can you please
>> a) make this feature optional,
>
> netconsole itself is optional & modular. I'm not sure making further
> splits is called for, especially given the use cases.
It could be a hidden option, selected by its users (e.g. netconsole).
>> b) (de)allocate this buffer dynamically when the first/last console with
>> CON_EXTENDED set is (un)registered?
>
> But yeah, making the buffer allocated on demand should be simple
> enough. Will get to it.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: Tejun Heo @ 2015-06-29 15:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded
In-Reply-To: <CAMuHMdWwH-3kx1ma5KE=fP94by8boxM_QYqPKpU=YJw8t3hYeg@mail.gmail.com>
Hello,
On Mon, Jun 29, 2015 at 11:20:41AM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 29, 2015 at 4:45 PM, Tejun Heo <tj@kernel.org> wrote:
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
>
> > @@ -2196,6 +2227,7 @@ out:
> > */
> > void console_unlock(void)
> > {
> > + static char ext_text[CONSOLE_EXT_LOG_MAX];
>
> Can you please
> a) make this feature optional,
netconsole itself is optional & modular. I'm not sure making further
splits is called for, especially given the use cases.
> b) (de)allocate this buffer dynamically when the first/last console with
> CON_EXTENDED set is (un)registered?
But yeah, making the buffer allocated on demand should be simple
enough. Will get to it.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 3/3] printk: implement support for extended console drivers
From: Geert Uytterhoeven @ 2015-06-29 9:20 UTC (permalink / raw)
To: Tejun Heo
Cc: pmladek, Andrew Morton, David S. Miller,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Kay Sievers,
Josh Triplett, Linux Embedded
In-Reply-To: <1430318704-32374-4-git-send-email-tj@kernel.org>
Hi Tejun,
On Wed, Apr 29, 2015 at 4:45 PM, Tejun Heo <tj@kernel.org> wrote:
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2196,6 +2227,7 @@ out:
> */
> void console_unlock(void)
> {
> + static char ext_text[CONSOLE_EXT_LOG_MAX];
Can you please
a) make this feature optional,
b) (de)allocate this buffer dynamically when the first/last console with
CON_EXTENDED set is (un)registered?
Your patch is at the top of the bloat-o-meter output (against v4.1):
add/remove: 388/154 grow/shrink: 1309/269 up/down: 92366/-44878 (47488)
function old new delta
ext_text - 8192 +8192
do_con_trol - 4824 +4824
path_openat 1416 4224 +2808
tvec_bases 4 2080 +2076
ip_do_fragment - 1824 +1824
unix_stream_read_generic - 1452 +1452
ext4_ext_shift_extents - 1350 +1350
ext4_insert_range - 1174 +1174
bpf_prepare_filter 264 1430 +1166
proc_pid_cmdline_read - 1020 +1020
and unlike the others, this one is not that difficult to fix.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* plumbers device tree track -- last call
From: Frank Rowand @ 2015-06-19 17:44 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
devicetree-spec-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l
The Plumbers conference has officially filled up and
closed registration BUT I might be able to get one or
two more people into the conference.
If you think that your presence will provide a positive
contribution to the device tree track, please email me
by Monday afternoon (California time, PDT, UTC-7:00),
with a very brief comment on why your attendance will
be useful.
Regards,
Frank Rowand
^ permalink raw reply
* Re: Device Tree at Plumbers, early registration ends Friday
From: Frank Rowand @ 2015-06-01 7:22 UTC (permalink / raw)
To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <556A2D56.4060401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 5/30/2015 2:36 PM, Frank Rowand wrote:
> The "Linux Plumbers Device Tree" track was accepted by the Plumbers
> conference.
The above is a pasto, ycch. The track is, of course:
Device Tree Tools, Validation, and Troubleshooting
>
> The DEADLINE for EARLY BIRD REGISTRATION at a reduced price
> ends Friday, June 5.
>
> I have a limited number of free registration discounts available for
> presenters at the device tree track.
>
> General information about plumbers is at:
>
> http://linuxplumbersconf.org/2015/
>
> Plumbers will be co-located with LinuxCon North America in Seattle
> (Plumbers is Aug 19-21, Linuxcon is Aug 17-19).
>
> On Wed Aug 19 there is a shared technical track between the two
> conferences. The schedule for that track should be announced very
> soon now. Preliminary results are that I will be presenting a talk
> on DT debugging in that track.
>
> LinuxCon North America info is at:
>
> http://events.linuxfoundation.org/events/linuxcon-north-america
>
>
> Hope to see many of you in Seattle.
>
> Regards,
>
> Frank Rowand
>
^ permalink raw reply
* Device Tree at Plumbers, looking for topics and session leaders
From: Frank Rowand @ 2015-05-30 21:39 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
I am looking for additional topics to include in the device tree track
at Plumbers 2015.
I am also soliciting people who would like to be session leaders or
scribes.
I have a limited number of free registration discounts available for
session leaders / presenters.
The format at Plumbers is less about presentations and more about
discussions. So enough slides and presentation to set the foundation
of the discussion. Then lots of talking.
The role of the session leader is to
- present a balanced description of the topic / subject area
- ensure multiple view points and alternatives are heard
If you want to help shape the future of device tree, then your
role as a member of the audience is to talk. To provide ideas,
inspiration, your experiences, how the world you live in may be
different than the one that I live in.
The track description is:
The Linux Plumbers 2015 Device Tree Tools, Validation, and
Troubleshooting track focuses on tools (programs and scripts),
techniques, and core support to enable creation of correct device
trees and to support troubleshooting and debugging of incorrect
device trees, drivers, and subsystems.
The tools encompass static (build and pre-boot) and dynamic (boot and
run-time) environments.
Areas of interest include
- inspection
- verification and validation
- troubleshooting
- debugging
- core support for debugging
- unit tests
- designing and implementing drivers for effective debugging
- impact of overlays (boot and run-time updates to the device tree)
- bindings
- documentation
Topics unrelated to the overall track but of current Device Tree
interest may be accepted if there is available time
- ordering of device creation and driver binding
Please contact me if you plan to attend the device tree track. If
you are also attending other tracks, please list those tracks so that
the Plumbers planning committee can try to minimize the schedule
conflicts between tracks.
General information about plumbers is at:
http://linuxplumbersconf.org/2015/
Plumbers will be co-located with LinuxCon North America in Seattle
(Plumbers is Aug 19-21, Linuxcon is Aug 17-19).
Hope to see many of you in Seattle.
Regards,
Frank Rowand
^ permalink raw reply
* Device Tree at Plumbers, early registration ends Friday
From: Frank Rowand @ 2015-05-30 21:36 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
linux-embedded-u79uwXL29TY76Z2rM5mHXA,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
The "Linux Plumbers Device Tree" track was accepted by the Plumbers
conference.
The DEADLINE for EARLY BIRD REGISTRATION at a reduced price
ends Friday, June 5.
I have a limited number of free registration discounts available for
presenters at the device tree track.
General information about plumbers is at:
http://linuxplumbersconf.org/2015/
Plumbers will be co-located with LinuxCon North America in Seattle
(Plumbers is Aug 19-21, Linuxcon is Aug 17-19).
On Wed Aug 19 there is a shared technical track between the two
conferences. The schedule for that track should be announced very
soon now. Preliminary results are that I will be presenting a talk
on DT debugging in that track.
LinuxCon North America info is at:
http://events.linuxfoundation.org/events/linuxcon-north-america
Hope to see many of you in Seattle.
Regards,
Frank Rowand
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Jon Loeliger @ 2015-05-26 16:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, Rowand, Frank,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matt Porter,
Gaurav Minocha
In-Reply-To: <10482596.MaespZJCtk@wuerfel>
So, like, Arnd Bergmann said:
> On Tuesday 14 April 2015 10:36:15 Rob Herring wrote:
> >
> > > 4) Identifying additional people who should attend the device tree track.
> >
> > Arnd Bergmann
> > Matt Porter
> > Jon Loeliger
> > Gaurav Minocha
>
> Sorry, I won't be there. I should have replied earlier, but I'll be on
> parental leave at the time.
>
> Arnd
Arnd,
OK. Hard to believe, but it looks like I have enough
ducks in a row to attend Plumber's this year!
Thanks,
jdl
^ permalink raw reply
* LPC 2015 Boot, Init, and Config microconf RFC and Invitation
From: Mehaffey, John @ 2015-05-06 22:51 UTC (permalink / raw)
To: celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org,
dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
lxc-devel-cunTk1MwBs9qMoObBWhMNEqPaTDuhLve2LY78lusg7I@public.gmane.org
Cc: kate.stewart-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
mswilson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
The Boot, Init, and Config microconference is inviting interested parties to comment on proposed topics and show their interest in attending.
Proposed topics are at http://wiki.linuxplumbersconf.org/2015:boot_init_and_config, and include containers, tinification, systemd tuning, k/dbus, early kernel tracing, other embedded/fastboot improvements, and an alternative net boot protocol.
There are likely more proposed topics than will comfortably fit in a 3-hour microconf, please indicate your attendance and interest on the wiki page so that we can plan accordingly.
If you are interested in leading a topic, please let us know!
Sincerely,
John Mehaffey, Kate Stewart, Matthew Wilson
^ permalink raw reply
* Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
From: David Gibson @ 2015-05-06 3:28 UTC (permalink / raw)
To: Rob Herring
Cc: Rob Landley, Rowand, Frank,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqKkZYEMdYmh=JkA6O34a+7mKy=SgB2XxzgTM70mihgQeQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]
On Mon, May 04, 2015 at 06:20:35PM -0500, Rob Herring wrote:
> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
> > On 04/11/2015 02:20 PM, Rowand, Frank wrote:
> >> In recent years there have been proposed tools to aid in the creation of valid
> >> device trees and in debugging device tree issues. An example of this is the
> >> various approaches proposed (with source code provided) to validate device tree
> >> source against valid bindings. As of today, device tree related tools,
> >> techniques, and debugging infrastructure have not progressed very far. I have
> >> submitted a device tree related proposal for the Linux Plumbers 2015 conference
> >> to spur action and innovation in such tools, techniques, and debugging
> >> infrastructure.
> >>
> >> The current title of the track is "Device Tree Tools, Validation, and
> >> Troubleshooting". The proposal is located at
> >>
> >> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
> >
> > Want I want to do is:
> >
> > 1) Download an archive of device tree files describing a bunch of
> > boards. (Both dts and corresponding dtb files, with maybe a .txt telling
> > me about the board and the -append line qemu needs to give it any
> > board-specific kernel command line stuff like "console=myserialport".)
>
> The dts half is here[1]. It is a kernel repository automatically
> stripped of everything but dts files.
>
> > 2) Feed one of the dtb files to qemu to instantiate a bunch of devices.
>
> I'd like this too. The QEMU maintainers don't really agree. I think
> the ARM virt platform is the wrong way around with QEMU generating the
> DT. There was a patch series to allow sysbus devices to be created on
> the command line like you can with PCI. This would have allowed a
> front end script to generate a QEMU command line from a DT. I'm not
> sure if it ever got in.
I suggested something like this several years ago to Anthony Liguori
who didn't much like it. However qemu has changed a fair bit since
then, so it might be worth revisiting.
It's a big job though - lots of integration work with qemu's
configuration core. In particular allowing this without breaking
migrations or the various qapis is not straightforward.
> It would lower the bar to adding new platforms to just writing models
> for blocks perhaps. I'm not sure there's enough interest. The number
> of ARM platforms supported in QEMU is much less than the kernel.
I havea presentation proposal for KVM Forum covering some ideas which
could be at least first steps towards doing this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
From: Rob Herring @ 2015-05-05 19:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rowand, Frank,
celinux-dev-idqoXFIVOFIh9xQPArXXUATG8MYbGj4l@public.gmane.org,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdV7xfbBYL5fhudObdwNVJ0L_1_h0ozT+U4Lpx=Mu9UGhw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
+Ian
On Tue, May 5, 2015 at 2:34 AM, Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi Rob
>
> On Tue, May 5, 2015 at 1:20 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, May 1, 2015 at 4:22 PM, Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> wrote:
>>> On 04/11/2015 02:20 PM, Rowand, Frank wrote:
>>>> In recent years there have been proposed tools to aid in the creation of valid
>>>> device trees and in debugging device tree issues. An example of this is the
>>>> various approaches proposed (with source code provided) to validate device tree
>>>> source against valid bindings. As of today, device tree related tools,
>>>> techniques, and debugging infrastructure have not progressed very far. I have
>>>> submitted a device tree related proposal for the Linux Plumbers 2015 conference
>>>> to spur action and innovation in such tools, techniques, and debugging
>>>> infrastructure.
>>>>
>>>> The current title of the track is "Device Tree Tools, Validation, and
>>>> Troubleshooting". The proposal is located at
>>>>
>>>> http://wiki.linuxplumbersconf.org/2015:device_tree_tools_validation_and_trouble_shooting
>>>
>>> Want I want to do is:
>>>
>>> 1) Download an archive of device tree files describing a bunch of
>>> boards. (Both dts and corresponding dtb files, with maybe a .txt telling
>>> me about the board and the -append line qemu needs to give it any
>>> board-specific kernel command line stuff like "console=myserialport".)
>>
>> The dts half is here[1]. It is a kernel repository automatically
>> stripped of everything but dts files.
>>
>> [1] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
>
> Great!
>
> While "git log" has the "--nomerges" option, cgit hasn't, making it hard to see
> the actual changes through the forest of merges.
>
> Any chance merge commits not causing any changes can be stripped out, too?
That's a question for Ian.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox