> > > + iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
> > > + __GFP_NORETRY);
> > > + if (!iter.start) {
> > > + dev_warn(pfdev->dev, "failed to allocate devcoredump file\n");
> > > + return;
> > > + }
> > > ...
> > > + memset(iter.hdr, 0, iter.data - iter.start);
> >
> > Why are we using __GFP_NOWARN and __GFP_NORETRY? Why not plain vmalloc?
> >
> > Also, why vmalloc instead of vzalloc? (Or adding __GFP_ZERO to the list
> > of __vmalloc flags if __GFP_NOWARN/__GFP_NORETRY are really needed?) Are
> > there relevant performance or security considerations?
>
> I borrowed this code from Etnaviv a while ago and the same doubt struck me
> then. My understanding of its intended behaviour is that because the dump file
> might be huge, we don't want the memory manager to trigger the OOM killer and
> annoy quite a few running processes because of a debug feature. Also since the
> code already handles the situation when an allocation fails by refusing to
> generate a dump, there's no need for the allocator to generate specific error
> messages.
>
> So I guess it boils down to 'if there's quite enough memory to allocate a huge
> dump file, go ahead, otherwise don't reclaim any processes' pages for something
> that isn't essential'.
>
> I don't see much use for __GFP_ZERO in this case, because the dump file gets
> memcpy'd with the contents of every single bo so whatever the original
> contents of the memory were at the time of the allocation, they're overwritten
> immediately.
I think that's a reasonable explanation, bearing in mind I'm firmly a
userspace person ;-)
Please add a comment explaining the assumptions here, though, because
the code will live longer than this ML thread.
> I've also rebased v3 on top of drm-misc-next and the compiler error because of
> the removed panfrost_job structure member is gone.
Excellent
