mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-21 11:44:01 +08:00
0bcc181618
Based upon initial work by Keiichi Kii <k-keiichi@bx.jp.nec.com>.
This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via configfs. Documentation is also updated
accordingly.
Issues and brief design overview:
(1) Kernel-initiated creation / destruction of kernel objects is not
possible with configfs -- the lifetimes of the "config items" is managed
exclusively from userspace. But netconsole must support boot/module
params too, and these are parsed in kernel and hence netpolls must be
setup from the kernel. Joel Becker suggested to separately manage the
lifetimes of the two kinds of netconsole_target objects -- those created
via configfs mkdir(2) from userspace and those specified from the
boot/module option string. This adds complexity and some redundancy here
and also means that boot/module param-created targets are not exposed
through the configfs namespace (and hence cannot be updated / destroyed
dynamically). However, this saves us from locking / refcounting
complexities that would need to be introduced in configfs to support
kernel-initiated item creation / destroy there.
(2) In configfs, item creation takes place in the call chain of the
mkdir(2) syscall in the driver subsystem. If we used an ioctl(2) to
create / destroy objects from userspace, the special userspace program is
able to fill out the structure to be passed into the ioctl and hence
specify attributes such as local interface that are required at the time
we set up the netpoll. For configfs, this information is not available at
the time of mkdir(2). So, we keep all newly-created targets (via
configfs) disabled by default. The user is expected to set various
attributes appropriately (including the local network interface if
required) and then write(2) "1" to the "enabled" attribute. Thus,
netpoll_setup() is then called on the set parameters in the context of
_this_ write(2) on the "enabled" attribute itself. This design enables
the user to reconfigure existing netconsole targets at runtime to be
attached to newly-come-up interfaces that may not have existed when
netconsole was loaded or when the targets were actually created. All this
effectively enables us to get rid of custom ioctls.
(3) Ultra-paranoid configfs attribute show() and store() operations, with
sanity and input range checking, using only safe string primitives, and
compliant with the recommendations in Documentation/filesystems/sysfs.txt.
(4) A new function netpoll_print_options() is created in the netpoll API,
that just prints out the configured parameters for a netpoll structure.
netpoll_parse_options() is modified to use that and it is also exported to
be used from netconsole.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
Acked-by: Keiichi Kii <k-keiichi@bx.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
157 lines
6.0 KiB
Plaintext
157 lines
6.0 KiB
Plaintext
|
|
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
|
|
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
|
|
|
|
Please send bug reports to Matt Mackall <mpm@selenic.com>
|
|
and Satyam Sharma <satyam.sharma@gmail.com>
|
|
|
|
Introduction:
|
|
=============
|
|
|
|
This module logs kernel printk messages over UDP allowing debugging of
|
|
problem where disk logging fails and serial consoles are impractical.
|
|
|
|
It can be used either built-in or as a module. As a built-in,
|
|
netconsole initializes immediately after NIC cards and will bring up
|
|
the specified interface as soon as possible. While this doesn't allow
|
|
capture of early kernel panics, it does capture most of the boot
|
|
process.
|
|
|
|
Sender and receiver configuration:
|
|
==================================
|
|
|
|
It takes a string configuration parameter "netconsole" in the
|
|
following format:
|
|
|
|
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
|
|
|
|
where
|
|
src-port source for UDP packets (defaults to 6665)
|
|
src-ip source IP to use (interface address)
|
|
dev network interface (eth0)
|
|
tgt-port port for logging agent (6666)
|
|
tgt-ip IP address for logging agent
|
|
tgt-macaddr ethernet MAC address for logging agent (broadcast)
|
|
|
|
Examples:
|
|
|
|
linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
|
|
|
|
or
|
|
|
|
insmod netconsole netconsole=@/,@10.0.0.2/
|
|
|
|
It also supports logging to multiple remote agents by specifying
|
|
parameters for the multiple agents separated by semicolons and the
|
|
complete string enclosed in "quotes", thusly:
|
|
|
|
modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/"
|
|
|
|
Built-in netconsole starts immediately after the TCP stack is
|
|
initialized and attempts to bring up the supplied dev at the supplied
|
|
address.
|
|
|
|
The remote host can run either 'netcat -u -l -p <port>' or syslogd.
|
|
|
|
Dynamic reconfiguration:
|
|
========================
|
|
|
|
Dynamic reconfigurability is a useful addition to netconsole that enables
|
|
remote logging targets to be dynamically added, removed, or have their
|
|
parameters reconfigured at runtime from a configfs-based userspace interface.
|
|
[ Note that the parameters of netconsole targets that were specified/created
|
|
from the boot/module option are not exposed via this interface, and hence
|
|
cannot be modified dynamically. ]
|
|
|
|
To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the
|
|
netconsole module (or kernel, if netconsole is built-in).
|
|
|
|
Some examples follow (where configfs is mounted at the /sys/kernel/config
|
|
mountpoint).
|
|
|
|
To add a remote logging target (target names can be arbitrary):
|
|
|
|
cd /sys/kernel/config/netconsole/
|
|
mkdir target1
|
|
|
|
Note that newly created targets have default parameter values (as mentioned
|
|
above) and are disabled by default -- they must first be enabled by writing
|
|
"1" to the "enabled" attribute (usually after setting parameters accordingly)
|
|
as described below.
|
|
|
|
To remove a target:
|
|
|
|
rmdir /sys/kernel/config/netconsole/othertarget/
|
|
|
|
The interface exposes these parameters of a netconsole target to userspace:
|
|
|
|
enabled Is this target currently enabled? (read-write)
|
|
dev_name Local network interface name (read-write)
|
|
local_port Source UDP port to use (read-write)
|
|
remote_port Remote agent's UDP port (read-write)
|
|
local_ip Source IP address to use (read-write)
|
|
remote_ip Remote agent's IP address (read-write)
|
|
local_mac Local interface's MAC address (read-only)
|
|
remote_mac Remote agent's MAC address (read-write)
|
|
|
|
The "enabled" attribute is also used to control whether the parameters of
|
|
a target can be updated or not -- you can modify the parameters of only
|
|
disabled targets (i.e. if "enabled" is 0).
|
|
|
|
To update a target's parameters:
|
|
|
|
cat enabled # check if enabled is 1
|
|
echo 0 > enabled # disable the target (if required)
|
|
echo eth2 > dev_name # set local interface
|
|
echo 10.0.0.4 > remote_ip # update some parameter
|
|
echo cb:a9:87:65:43:21 > remote_mac # update more parameters
|
|
echo 1 > enabled # enable target again
|
|
|
|
You can also update the local interface dynamically. This is especially
|
|
useful if you want to use interfaces that have newly come up (and may not
|
|
have existed when netconsole was loaded / initialized).
|
|
|
|
Miscellaneous notes:
|
|
====================
|
|
|
|
WARNING: the default target ethernet setting uses the broadcast
|
|
ethernet address to send packets, which can cause increased load on
|
|
other systems on the same ethernet segment.
|
|
|
|
TIP: some LAN switches may be configured to suppress ethernet broadcasts
|
|
so it is advised to explicitly specify the remote agents' MAC addresses
|
|
from the config parameters passed to netconsole.
|
|
|
|
TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
|
|
|
|
ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
|
|
|
|
TIP: in case the remote logging agent is on a separate LAN subnet than
|
|
the sender, it is suggested to try specifying the MAC address of the
|
|
default gateway (you may use /sbin/route -n to find it out) as the
|
|
remote MAC address instead.
|
|
|
|
NOTE: the network device (eth1 in the above case) can run any kind
|
|
of other network traffic, netconsole is not intrusive. Netconsole
|
|
might cause slight delays in other traffic if the volume of kernel
|
|
messages is high, but should have no other impact.
|
|
|
|
NOTE: if you find that the remote logging agent is not receiving or
|
|
printing all messages from the sender, it is likely that you have set
|
|
the "console_loglevel" parameter (on the sender) to only send high
|
|
priority messages to the console. You can change this at runtime using:
|
|
|
|
dmesg -n 8
|
|
|
|
or by specifying "debug" on the kernel command line at boot, to send
|
|
all kernel messages to the console. A specific value for this parameter
|
|
can also be set using the "loglevel" kernel boot option. See the
|
|
dmesg(8) man page and Documentation/kernel-parameters.txt for details.
|
|
|
|
Netconsole was designed to be as instantaneous as possible, to
|
|
enable the logging of even the most critical kernel bugs. It works
|
|
from IRQ contexts as well, and does not enable interrupts while
|
|
sending packets. Due to these unique needs, configuration cannot
|
|
be more automatic, and some fundamental limitations will remain:
|
|
only IP networks, UDP packets and ethernet devices are supported.
|