[lkml]   [2015]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCHSET] printk, netconsole: implement reliable netconsole

On Fri, Apr 17, 2015 at 02:55:37PM -0400, David Miller wrote:
> > * The bulk of patches are to pipe extended log messages to console
> > drivers and let netconsole relay them to the receiver (and quite a
> > bit of refactoring in the process), which, regardless of the
> > reliability logic, is beneficial as we're currently losing
> > structured logging (dictionary) and other metadata over consoles and
> > regardless of where the reliability logic is implemented, it's a lot
> > easier to have messages IDs.
> I do not argue against cleanups and good restructuring of the existing
> code. But you have decided to mix that up with something that is not
> exactly non-controversial.

Is the controlversial part referring to sending extended messages or
the reliability part or both?

> You'd do well to seperate the cleanups from the fundamental changes,
> so they can be handled separately.

Hmmm... yeah, probably would have been a better idea. FWIW, the
patches are stacked roughly in the order of escalating
controversiness. Will split the series up.

> > * The only thing necessary for reliable transmission are timer and
> > netpoll. There sure are cases where they go down too but there's a
> > pretty big gap between those two going down and userland getting
> > hosed, but where to put the retransmission and reliability logic
> > definitely is debatable.
> I fundamentally disagree, exactly on this point.
> If you take an OOPS in a software interrupt handler (basically, all of
> the networking receive paths and part of the transmit paths, for
> example) you're not going to be taking timer interrupts.

Sure, if irq handling is hosed, this won't work but I think there are
enough other failure modes like oopsing while holding a mutex or
falling into infinite loop while holding task_list lock (IIRC we had
something simliar a while ago due to iterator bug). Whether being
more robust in those cases is worthwhile is definitely debatable. I
thought the added complexity was small enough but the judgement can
easily fall on the other side.

> And that's the value of netconsole, the chance (albeit not %100) of
> getting messages in those scenerios.

None of the changes harm that in any way. Anyways, I'll split up the
extended message and the rest.



 \ /
  Last update: 2015-04-17 22:21    [W:0.097 / U:1.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site