| To: | Alex Elder <aelder@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 1/4] xfs: PF_FSTRANS should never be set in ->writepage |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Wed, 25 May 2011 03:46:37 -0400 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <1306289929.2823.120.camel@doink> |
| References: | <20110428125546.696493391@xxxxxxxxxxxxxxxxxxxxxx> <20110428130514.146517168@xxxxxxxxxxxxxxxxxxxxxx> <1306289929.2823.120.camel@doink> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Tue, May 24, 2011 at 09:18:49PM -0500, Alex Elder wrote: > On Thu, 2011-04-28 at 08:55 -0400, Christoph Hellwig wrote: > > Now that we reject direct reclaim in addition to always using GFP_NOFS > > allocation there's no chance we'll ever end up in ->writepage with > > PF_FSTRANS set. Add a WARN_ON if we hit this case, and stop checking > > if we'd actually need to start a transaction. > > > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > > Do the radix_tree_preload(GFP_KERNEL) calls in > xfs_iget_cache_miss() and xfs_mru_cache_insert() > pose any risk here? (I haven't really looked > closely, I just noticed that these were cases we > did not use GFP_NOFS.) They don't, given that we don't allow reclaim to proceed into ->writepage any more. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2/4] xfs: remove the unused ilock_nowait codepath in writepage, Alex Elder |
|---|---|
| Next by Date: | Re: [PATCH] xfstests: add test 254 for testing basic btrfs volume functionality, Christoph Hellwig |
| Previous by Thread: | Re: [PATCH 1/4] xfs: PF_FSTRANS should never be set in ->writepage, Alex Elder |
| Next by Thread: | Re: [PATCH 2/4] xfs: remove the unused ilock_nowait codepath in writepage, Alex Elder |
| Indexes: | [Date] [Thread] [Top] [All Lists] |