Tetsuo Handa wrote:
> Pavel Machek wrote:
> > > + * Please use this wrapper function which will be updated in the future
> > > to read
> > > + * @tsk->comm in a consistent way.
> > > + */
> > > +static inline int commcmp(const struct task_struct *tsk, const char
> > > *comm)
> > > +{
> > > + retu
On Wed 2014-01-08 23:19:04, Tetsuo Handa wrote:
> Pavel Machek wrote:
> > > > > I'm not nacking this, just stating my view.
> > > >
> > > > And I believe Andrew clearly stated his view, on the very topic you
> > > > asked him on.
> > >
> > > I believe Andrew's view:
> > >
> > > On Sat, 2013-12-2
Pavel Machek wrote:
> > > > I'm not nacking this, just stating my view.
> > >
> > > And I believe Andrew clearly stated his view, on the very topic you
> > > asked him on.
> >
> > I believe Andrew's view:
> >
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 1
On Tue, Jan 7, 2014 at 6:56 PM, Pavel Machek wrote:
>> The additional cost of using current vs NULL is ~zero.
>
> The additional cost of current vs NULL is cca 8 bytes per caller. Test
> for NULL is cca 4 bytes, maybe 20 bytes total. I believe it is worth
> it.
It depends (typical answer ;-)
On
> > > I'm not nacking this, just stating my view.
> >
> > And I believe Andrew clearly stated his view, on the very topic you
> > asked him on.
>
> I believe Andrew's view:
>
> On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> >
On Tue, 2014-01-07 at 09:37 +0100, Pavel Machek wrote:
> On Mon 2014-01-06 17:03:55, Joe Perches wrote:
> > On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
> > > > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > > > > []
> > > > > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *
On Mon 2014-01-06 17:03:55, Joe Perches wrote:
> On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
> > > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > > > []
> > > > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf,
> > > > > > char *end, void *ptr,
> > > > > > {
On Tue, 2014-01-07 at 01:16 +0100, Pavel Machek wrote:
> > > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > > []
> > > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf, char
> > > > > *end, void *ptr,
> > > > > {
> > > > > int default_width = 2 * sizeof(void *) + (
Hi!
> > > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > []
> > > > @@ -1232,7 +1248,7 @@ char *pointer(const char *fmt, char *buf, char
> > > > *end, void *ptr,
> > > > {
> > > > int default_width = 2 * sizeof(void *) + (spec.flags & SPECIAL
> > > > ? 2 : 0);
> > > >
> > > > -
On Tue, 2014-01-07 at 06:41 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> > > Joe Perches wrote:
> > > > Is this really necessary?
> > > No problem. %pT[012] are simply optimization (reducing number of function
> > > arguments for savin
Joe Perches wrote:
> On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > Is this really necessary?
> > No problem. %pT[012] are simply optimization (reducing number of function
> > arguments for saving text size) and therefore I can drop them.
> > What about below pa
On Mon 2014-01-06 23:00:56, Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> > > > Since my purpose is to make reading of task_struct->comm consistent,
> > > > %pT-like
> > > > extension is what I want for centralizing pointer dereferences.
> >
On Mon, 2014-01-06 at 23:00 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > Is this really necessary?
> No problem. %pT[012] are simply optimization (reducing number of function
> arguments for saving text size) and therefore I can drop them.
> What about below patch?
Hi Tetsuo. Just a nit.
Joe Perches wrote:
> On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> > > Since my purpose is to make reading of task_struct->comm consistent,
> > > %pT-like
> > > extension is what I want for centralizing pointer dereferences.
> >
> > If we have no objections for %pT[C012] patch,
>
> I
Pavel Machek wrote:
> > + * Please use this wrapper function which will be updated in the future to
> > read
> > + * @tsk->comm in a consistent way.
> > + */
> > +static inline int commcmp(const struct task_struct *tsk, const char *comm)
> > +{
> > + return strcmp(tsk->comm, comm);
> > +}
>
> I
Hi!
> + * Please use this wrapper function which will be updated in the future to
> read
> + * @tsk->comm in a consistent way.
> + */
> +static inline int commcmp(const struct task_struct *tsk, const char *comm)
> +{
> + return strcmp(tsk->comm, comm);
> +}
Is this useful to something? Print
On Sun, 2014-01-05 at 12:15 +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Since my purpose is to make reading of task_struct->comm consistent,
> > %pT-like
> > extension is what I want for centralizing pointer dereferences.
>
> If we have no objections for %pT[C012] patch,
I still believe
Tetsuo Handa wrote:
> Since my purpose is to make reading of task_struct->comm consistent, %pT-like
> extension is what I want for centralizing pointer dereferences.
If we have no objections for %pT[C012] patch, I'd like to propose a counterpart
patch for users reading/copying task_struct->comm fo
I'm planning to convert task_struct->comm to use RCU so that they always get
consistent result. Inconsistent result (e.g. trailing '\0' byte is emitted when
printing string argument) is caused by breaking a rule that the string argument
must not change during the function when it is passed as "cons
On Fri, Jan 3, 2014 at 9:39 AM, Joe Perches wrote:
> On Fri, 2014-01-03 at 09:08 -0800, Kees Cook wrote:
>> I'm on board with the idea of embedding comm/pid/whatever,
>
> I still think the space reduction isn't worth the
> complication.
>
>> but I
>> either missed or do not understand why a secon
On Fri, 2014-01-03 at 09:08 -0800, Kees Cook wrote:
> I'm on board with the idea of embedding comm/pid/whatever,
I still think the space reduction isn't worth the
complication.
> but I
> either missed or do not understand why a second format-start character
> is being added. I think this will co
On Wed, Jan 1, 2014 at 8:49 PM, Tetsuo Handa
wrote:
> From: Tetsuo Handa
> Date: Thu, 2 Jan 2014 13:37:14 +0900
> Subject: [PATCH v3] lib/vsprintf: support built-in tokens
>
> The vast majority of ->comm accesses are accessing current->comm, for
> debug reasons. I'm counting 350-odd sites. At all
Hi!
> > > > #define PRINTK_PID "\002"
> > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> > > >
> > > > printk(PRINTK_TASK_ID ": hair on fire\n");
> > > >
> > > > It's certainly compact. I doubt if there's any existing code which
> > > > deliberately prints control chars?
> >
Joe Perches wrote:
> On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > > > previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting
> > > > only
> > > > one byte compared t
btw: Those -6.6 field width uses really are just for debugging
and I think should be removed. I didn't notice any other uses of
field widths and current->. Are there any?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Wed, 2014-01-01 at 19:02 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > > previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting
> > > only
> > > one byte compared to my previous choice.
> >
> >
Joe Perches wrote:
> > This choice (i.e. reserve only '\xFF') is more resource economy than my
> > previous choice (i.e. reserve '\x7F' to '\xFF') at the cost of wasting only
> > one byte compared to my previous choice.
>
> I supposed that's better.
>
> Is there a particularly utility/reason to u
On Wed, 2014-01-01 at 14:34 +0900, Tetsuo Handa wrote:
> I think we want formatting directive support because we have users shown
> below.
>
> fs/afs/internal.h: printk("[%-6.6s] "FMT"\n", current->comm
> ,##__VA_ARGS__)
> fs/cachefiles/internal.h: printk(KERN_DEBUG "[%-6.6s] "FMT"\
Joe Perches wrote:
> > Please describe your format and rules (e.g. what byte starts a built-in
> > token;
> > what bytes are used for representing variable name, what separates flags,
> > field
> > width and precision options from variable name if these options are
> > specified,
> > what byte t
On Tue, 2013-12-31 at 15:53 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > Also I prefer using ASCII SUB (26 \x1a \032 ^z) or maybe
> > PU1 - 145 or PU2 - 146, as an initiator byte as it takes
> > up much less of the control word space instead of using
> > multiple values like \x80, \x81, \x82
Joe Perches wrote:
> I get:
>
> $ grep-2.5.4 -rP --include=*.[ch] -oh \
>
> "\b(?:printk|[a-z_]+_(?:printk|emerg|alert|crit|err|warn|notice|info|debug|dbg))[^;]*\bcurrent->[\w_]+"
> * | \
> grep -P -oh "\bcurrent->[\w_]+"| sort | uniq -c | sort -rn
> 380 current->pid
> 267 current->c
On Sun, 2013-12-29 at 21:13 +0900, Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Joe Perches wrote:
> > > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > > >
> > > > > > > #define PRINTK_PID "\002"
> > > > > > > #defin
Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > >
> > > > > > #define PRINTK_PID "\002"
> > > > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> >
> > > > > >
> > > > >
On Sun, 2013-12-29 at 09:32 +0900, Tetsuo Handa wrote:
> Joe Perches wrote:
> > On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > >
> > > > > > #define PRINTK_PID "\002"
> > > > > > #define PRINTK_TASK_ID "\003" /* "comm
Joe Perches wrote:
> On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> > On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> >
> > > > > #define PRINTK_PID "\002"
> > > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
>
> > > > >
> > > > > printk(PRINTK_TASK_ID ": ha
On Sat, 2013-12-28 at 12:08 -0800, Andrew Morton wrote:
> On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
>
> > > > #define PRINTK_PID "\002"
> > > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> > > >
> > > > printk(PRINTK_TASK_ID ": hair on fire\n");
> > > >
> > > > It'
On Sat, 28 Dec 2013 11:53:25 -0800 Joe Perches wrote:
> > > #define PRINTK_PID "\002"
> > > #define PRINTK_TASK_ID "\003" /* "comm:pid" */
> > >
> > > printk(PRINTK_TASK_ID ": hair on fire\n");
> > >
> > > It's certainly compact. I doubt if there's any existing code which
> > > de
On Sat, 2013-12-28 at 20:25 +0100, Geert Uytterhoeven wrote:
> On Sat, Dec 28, 2013 at 8:25 PM, Andrew Morton
> wrote:
> >> Is any of the "\x" (backslash + character) unused and thus available?
> >
> > I guess control characters would work.
> >
> > #define PRINTK_COMM "\001"
>
> Not that one,
On Sat, Dec 28, 2013 at 8:25 PM, Andrew Morton
wrote:
>> Is any of the "\x" (backslash + character) unused and thus available?
>
> I guess control characters would work.
>
> #define PRINTK_COMM "\001"
Not that one, cfr. include/linux/kern_levels.h ;-)
> #define PRINTK_PID "\002"
> #defi
On Sat, 28 Dec 2013 19:57:50 +0100 Geert Uytterhoeven
wrote:
> > If we introduce a character which compiler does not know that follows the %
> > character, compiler would be confused when checking type of corresponding
> > argument.
> >
> >> I wonder if there's some way in which we can invent a
On Sat, Dec 28, 2013 at 4:43 AM, Tetsuo Handa
wrote:
> Andrew Morton wrote:
>> which is painful, so we also provide the new vsprintf token as a
>> convenience:
>>
>> pr_warn("%|: hair on fire\n");
>>
>> but I don't know what we can use in place of %|.
>
> We are using %pEXTENSION where EXTEN
Andrew Morton wrote:
> which is painful, so we also provide the new vsprintf token as a
> convenience:
>
> pr_warn("%|: hair on fire\n");
>
> but I don't know what we can use in place of %|.
We are using %pEXTENSION where EXTENSION is [A-Za-z0-9]* because compiler does
not need to understa
On Wed, 25 Dec 2013 21:37:33 +0900 Tetsuo Handa
wrote:
> Some examples for converting direct ->comm users are shown below.
>
> pr_info("comm=%s\n", p->comm);=> pr_info("comm=%pTC\n", p);
> pr_info("%s[%u]\n", p->comm, p->pid); => pr_info("%pT0\n", p);
> pr_info("%s
On Wed, 2013-12-25 at 21:37 +0900, Tetsuo Handa wrote:
> This patch introduces %pTC format specifier for reading task_struct->comm
> and %pT0 %pT1 %pT2 format specifiers for reading task_struct->comm and
> task_struct->pid.
[]
> pr_info("comm=%s\n", p->comm);=> pr_info("comm=%pTC\
>From 545dae06c6690a0c937e082ed984f828a2ea7aa2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 25 Dec 2013 18:16:17 +0900
Subject: [PATCH] lib/vsprintf: add %pT[C012] format specifier
Since task_struct->comm can be modified by other threads while the current
thread is reading it,
45 matches
Mail list logo
