linux-kernel - Re: [PATCH] printk: add option to print cpu id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Aug 2012 19:19:31 -0700
From:	"Pandita, Vikram" <vikram.pandita@...com>
To:	Kay Sievers <kay@...y.org>
Cc:	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	Mike Turquette <mturquette@...aro.org>,
	Vimarsh Zutshi <vimarsh.zutshi@...il.com>
Subject: Re: [PATCH] printk: add option to print cpu id

Kay

On Thu, Aug 2, 2012 at 5:06 PM, Kay Sievers <kay@...y.org> wrote:
> On Fri, Aug 3, 2012 at 1:50 AM, Pandita, Vikram <vikram.pandita@...com> wrote:
>> On Thu, Aug 2, 2012 at 1:08 PM, Kay Sievers <kay@...y.org> wrote:
>
>>> How is that supposed to be useful?
>>>
>>> The prefix is added while exporting data from the kmsg buffer, which
>>> is just the CPU that *reads* the data from the buffer, not the one
>>> that has *written* the data it into it.
>>
>> I don't think so.
>> I can see the backtrace of the printk() call looks like follows:
>>
>> print_cpuid
>>  print_prefix
>>   msg_print_text
>>    console_unlock
>>     vprint_emit
>>      printk
>>
>> Now this is a synchronous path, where in the buffer is getting filled
>> with cpuid and timer info from the printk() calling context.
>> So you should get the right CPU id with the trace - with the exception
>> that i pointed out earlier for preemption.
>>
>>>
>>> Do I miss anything here?
>>
>> This is my understanding of the printk framework.
>> At least the print_time and print_cpuid seems to be happening
>> synchronously wrt printk
>
> Printk is a store-and-forward-model, and it always was. There is no
> guarantee at all, that the data is immediately flushed to the console
> by the same CPU, it just happens to be in most cases. It's pretty
> common though, that a different task is doing that work when it gets
> the console lock, and that is not a matter of preemption, it's normal
> and expected operation. The data which CPU has emitted the text is
> just not available. It would need to be stored in the records, for
> this to work.
>
> Your patch just prints the CPU that writes to the console, not
> necessarily the one that has stored the data. I think the second one
> is which is what you are looking for, but that is not what the patch
> does.
>

I did not understand well the complexity of the console layer. Thanks
for enlightenment :-)
Would be nice if you have any suggestion to get this done the right way.

First look i could guess this would do, but need to study further:

@@ -1550,6 +1550,9 @@ asmlinkage int vprintk_emit(int facility, int level,
                          NULL, 0, recursion_msg, printed_len);
        }

+       text_len = print_cpuid(text);
+       text += text_len;
+
        /*
         * The printf needs to come first; we need the syslog
         * prefix which might be passed-in as a parameter.
@@ -1582,6 +1585,13 @@ asmlinkage int vprintk_emit(int facility, int level,
                }
        }

+       /* Adjust for cpu-id string */
+       if (printk_cpuid) {
+               strncpy(text - 4, textbuf, 4);
+               text -= 4;
+               text_len += 4;
+       }
+
        if (level == -1)
                level = default_message_loglevel;



> Also dmesg and syslog uses the same logic and would put-out all
> entirely wrong CPU information with it, because the original
> information is long gone.
>
> Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/