On Wed, May 31, 2017 at 08:31:35AM +0800, Qu Wenruo wrote: > >> Yes it's hard to find such deadlock especially when lockdep will not > >> detect it. > >> > >> And this makes the advantage of using stack memory in v3 patch more obvious. > >> > >> I didn't realize the extra possible deadlock when memory pressure is > >> high, and to make completely correct usage of GFP_ flags we should let > >> caller to choose its GFP_ flag, which will introduce more modification > >> and more possibility to cause problem. > >> > >> So now I prefer the stack version a little more. > > > > The difference is that the stack version will always consume the stack > > at runtime. The dynamic allocation will not, but we have to add error > > handling and make sure we use right gfp flags. So it's runtime vs review > > trade off, I choose to spend time on review. > > OK, then I'll update the patchset to allow passing gfp flags for each > reservation. You mean to add gfp flags to extent_changeset_alloc and update the direct callers or to add gfp flags to the whole reservation codepath? I strongly prefer to use GFP_NOFS for now, although it's not ideal. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
