Messages in this thread | | | Date | Fri, 1 May 2009 15:21:33 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs |
| |
On Fri, 1 May 2009 23:59:32 +0200 Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, May 1, 2009 at 21:26, Andrew Morton <akpm@linux-foundation.org> wrote: > > On Fri, 1 May 2009 13:16:22 +0200 > > Kay Sievers <kay.sievers@vrfy.org> wrote: > > > >> On Fri, May 1, 2009 at 07:29, Andrew Morton <akpm@linux-foundation.org> wrote: > >> > >> > dev->type->nodename() might have failed due to -ENOMEM, in which case > >> > it seems wrong to assume that it returned NULL for <whatever reason you > >> > thought it might want to return NULL>. > >> > > >> > It's all a bit confused. > >> > >> This logic is only for providing a custom name hint. Only a few > >> devices need that at all. If the allocation fails, the default name > >> will be used, not the custom name. > > > > But that's bad, isn't it? __It means that the kernel will come up with > > one name if the memory allocation succeeded, and a different name if > > the allocation failed. > > Yeah, sure, it's bad. But I think we have pretty much lost anyway, if > we run into oom at this stage. > > What should we do instead? If we, for some reason, can not get a > possible custom name?
Not much - just sayin'.
Presumably the page allocator will have given a big spew, so the operator knows what went wrong.
| |