[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot time v2
>>> On 01.12.11 at 10:49, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 01/12/11 09:08, Jan Beulich wrote: >>>>> On 30.11.11 at 18:24, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: >>> + if ( ! note ) >>> + /* Ideally, this would be -ENOMEM. However, there are more >>> problems >>> + * assocated with trying to deal with -ENOMEM sensibly than just >>> + * pretending that the crash note area doesn't exist. */ >>> + return 0; >> The only current caller ignores the return value, so why the bogus >> return value? > > Originally it passed the return value back up to the cpu hotplug > notifier, but I decided that causing an -ENOMEM at this point was a > little silly given that: > 1) a lack of mem on boot will quickly kill the host in other ways, and > 2) while there is no way useful way to ensure that the crashdump kernel > gets reloaded with new notes pointers, blocking on not being able to > allocate notes is silly. > > Would you consider this enough of a problem to actually fail the > CPU_PREPARE_UP ? No, absolutely not. Ignoring the return value there is fine. >>> + if ( nr < 0 || nr >= nr_cpu_ids || !cpu_online(nr) || !crash_notes[nr] >>> ) >>> ... >>> - if ( per_cpu(crash_notes, nr) == NULL ) >>> - { >>> ... >>> - } >> I would suggest to retry allocation here. Even if this isn't suitable for >> a 32-bit kdump kernel on large systems, there#s no reason to penalize >> fully 64-bit environment. > > At this point, none of the allocation makes it suitable for a 32bit > system. For that, I need to start investigating something akin to > xalloc_below(), which is probably going to be todays task. If we have > previously failed to allocate the notes buffer (and are somehow still > running), what if anything makes it likely that we will successfully > allocate memory this time? Because memory got freed meanwhile? I'm particularly having post- boot onlining of CPUs in mind; of course, if allocation failed during boot we have bigger problems than this one. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |