On Thu, 11 Oct 2012, Ming Lei wrote: > Oliver, sorry for missing list. > > On Wed, Oct 10, 2012 at 10:12 PM, Oliver Neukum <oneukum@xxxxxxx> wrote: > > > Which components? We generally don't do that. We may have > > a problem with locks being held though. > > As I pointed out before, rebind may be involved to reset path, and probe(), > disconnect(), some sysfs things will call GFP_KERNEL allocation of course. > > At least, in theory, one by one convert can't avoid it except that > all function calls can be controlled by its caller, but that is not > practical. > > > This is much harder than it sounds. > > Keeping allowed gfp_flag inside task_struct should be one solution, and > let that teach mm to allocate memory, see the draft idea below: This makes a lot of sense. It remains to be seen whether you can convince the people on LKML to allow a new field to be added to task_struct. > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 8e1be1c..36a1e77 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2595,7 +2595,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, > unsigned int cpuset_mems_cookie; > int alloc_flags = ALLOC_WMARK_LOW|ALLOC_CPUSET; > > - gfp_mask &= gfp_allowed_mask; > + gfp_mask &= gfp_allowed_mask & tsk_get_allowd_gfp(current); This cries out for an inline function because it is repeated in so many places -- wherever gfp_allowed_mask is used. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
