linux-kernel - Re: Keeping network device renaming working in the presence of netconsole?

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]

Message-ID: <87k4yup9bd.fsf@spindle.srvr.nix>
Date:	Sat, 17 Oct 2009 12:08:06 +0100
From:	Nix <nix@...eri.org.uk>
To:	Matt Mackall <mpm@...enic.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Keeping network device renaming working in the presence of netconsole?

On 16 Oct 2009, Matt Mackall said:

> On Fri, 2009-10-16 at 20:43 +0100, Nix wrote:
>> This breaks userspace more than slightly if you rely on udev's
>> persistent net generator rules to keep network interface names constant,
>> or if you rename the lot to something more memorable than ethN. Any
>> userspace setup of that interface, assignment of additional addresses,
>> routing, MTU setting et al is all toast: and you can't stop using
>> interface renaming unless you like your interfaces to change identities
>> intermittently (but we've had that flamewar).
>
> A device definitely does have to be up for netconsole to work.

Thought so (hell, it brings it up itself). (I wish I knew how BMCs did
it, shadowing a real network device with a virtual one which can be
independently up and has a different MAC and everything. Probably it
takes hardware hacks.)

> But as far as I know, there's no good reason you can't rename an
> interface that's up.

I'll hack out the test and see what happens :)

> But back to your original problem: netconsole is actually probably a
> poor match for debugging suspend/resume as getting from an off state to
> a working state in the network driver takes a non-trivial amount of
> code.

I'm resuming from hibernation using TuxOnIce, so the network device has
initialized conventionally before the process state starts to
load, though it isn't *up* yet. (IIRC, anyway.)

(I probably used the wrong term: I always get suspension and hibernation
mixed up. This is a desktop, so the likelihood of suspend-to-RAM working
seemed remote, and also seemed unlikely to achieve the sorts of power
savings I was looking for.)

(Why TuxOnIce rather than swsusp? 'cos TuxOnIce was the only thing I
could ever get to work, is why, and 'cos it Just Worked until 2.6.31
when it suddenly started oopsing and panicking all over the place
in numerous exciting ways.)

> A useful technique here is capturing kernel message buffers in RAM
> across resets, something that can be done on most systems (provided you
> can disable memory test). Alternately, you might look at firewire
> techniques.

Neither of those work if the machine's been powered off for nine hours :)
--
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/