linux-kernel - Re: [RFC PATCH RT] netconsole: enable netconsole on PREEMPT

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 05 May 2014 16:10:51 -0300
From:	Daniel Bristot de Oliveira <bristot@...hat.com>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>,
	linux-rt-users@...r.kernel.org
CC:	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH RT] netconsole: enable netconsole on PREEMPT_RT

On 05/01/2014 11:15 AM, Paul Gortmaker wrote:
> Chances are the two real targets above were using the
> same igb network driver.  I wonder if it matters what
> underlying nic is used for netconsole?

These three machines are using different drivers:

+----------+------------+
| Machine  | Nic Module |
+----------+------------+
| Xeon     | tg3        |
| core i5  | r8169      |
| KVM VM   | virtio_net |
+----------+------------+

Netconsole uses the function netpoll_send_udp to send a packet,
and netpool_send_udp calls the driver's ".ndo_start_xmit" function.
So it end up calling the NIC driver, but it's not "hardware 
dependent".

> It is probably worthwhile to do some data mining into why
> it was disabled in the 1st place.  I can't say I recall, and
> it is possible that the reason has long since become irrelevant,
> even though the patch has been carried forward over time.

Figure out why it was disabled is one objective of this RFC :-).
I did not found any message about some error of netconsole on RT 
kernel. I enabled the netconsole waiting for some obscure bug,
but surprisingly it always worked fine.

> Or it may be that your testing simply doesn't cover the use
> case where netconsole will spew sleeping while atomic...

In order to test netconsole, I developed a (very simple) module to call
the printk using the sysfs interface [1]. This module creates a sysfs
file that calls printk passing the wrote message as the printk message. 

This module runs in 4 execution modes:
[n]one:     call printk
[i]rq:      call printk inside an irq disabled section
[p]reempt:  call printk inside a preempt disabled section
[x]:        call printk alternating the above modes

I ran the tests injecting printk using this four modes, using
concurrent threads, for example one thread per core injecting printk.

The point is, when the printk is called, firstly it stores the
message in the log buffer, and then it try to grab the console lock to
print the messages to the registered consoles. To grab the console
lock, printk calls the function console_trylock_for_printk. This
function, on a kernel configured with PREEMPT_RT_FULL, will check
if the system is in atomic. If the system is in atomic, it will fail,
and printk will not call the console drivers (this test is
implemented on patch printk-rt-aware.patch). The message will be
be printed to the console after, by a kworker, calling the
netconsole on the preemptive context. This is another good thing
for the RT kernel, as it can't be called inside an atomic section,
and it didn't disables the preemption and IRQs, it does not add a
possible point of latency.

[1] http://bristot.eti.br/files/netconsole/printk_inject.tar.gz

-- Daniel Bristot
--
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/