On Sat, Aug 19, 2006 at 10:41:09AM -0700, Andrew Morton wrote: > ow, GFP_ATOMIC is bad. Can we avoid that? I believe all the GFP_ATOMIC calls in sg.c can be downgraded to GFP_KERNEL. sg_add_sfp is only called from sg_open(), so the GFP_ATOMIC there can be downgraded to GFP_KERNEL. There's one in sg_common_write that can be downgraded. It's called from sg_write and sg_ioctl (via sg_new_write). No locks are held at those points. st_map_user_pages uses GFP_ATOMIC. It's only called from sg_build_direct, which is only called from sg_start_req, which is only called from sg_new_write, which is safe per above. sg_page_malloc uses GFP_ATOMIC. It's only called from sg_build_indirect. sg_build_indirect is called from sg_start_req (previously shown safe), and sg_build_reserve. sg_build_reserve is safe as it's only called from sg_ioctl and sg_add_sfp (previously shown safe). sg_build_sgat is called from sg_build_direct and sg_build_indirect, both of which have previously been shown safe. Please check my reasoning, but I'm pretty confident that none of these paths are called with any locks held. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
