Re: Bugs on Linux 2.6.18-rc2 sg code?

[Matthew Wilcox <matthew@wil.cx>]

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.