| Message ID | 1435645609-20387-2-git-send-email-kernel@kyup.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Tue, Jun 30, 2015 at 09:26:49AM +0300, Nikolay Borisov wrote: > Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes > possible deadlocks in the page writeback path. > > Signed-off-by: Nikolay Borisov <kernel@kyup.com> I've added this to the ext4.git tree, thanks. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/02/2015 09:14 AM, Theodore Ts'o wrote: > On Tue, Jun 30, 2015 at 09:26:49AM +0300, Nikolay Borisov wrote: >> Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes >> possible deadlocks in the page writeback path. >> >> Signed-off-by: Nikolay Borisov <kernel@kyup.com> > > I've added this to the ext4.git tree, thanks. > > - Ted Thanks! Just a question that popped to my mind after discussing with a colleague - Is GFP_NOFS enough here or should it be GFP_NOIO? Presumably the latter is a stronger guarantee that we are not going to hit any fs/writeback related code? Nikolay -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 02, 2015 at 09:16:34AM +0300, Nikolay Borisov wrote: > > Just a question that popped to my mind after discussing with a colleague > - Is GFP_NOFS enough here or should it be GFP_NOIO? Presumably the > latter is a stronger guarantee that we are not going to hit any > fs/writeback related code? GFP_NOFS is fine here; file system code calls the I/O codepaths, but device driver code doesn't call fs code. Put another way, if there are pages that are backed by a block device, which can be cleaned without going through the FS code paths, it's fine to let that happen while we are inside file system code. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index e003a1e..87ba10d 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -503,7 +503,7 @@ __read_extent_tree_block(const char *function, unsigned int line, struct buffer_head *bh; int err; - bh = sb_getblk(inode->i_sb, pblk); + bh = sb_getblk_gfp(inode->i_sb, pblk, __GFP_MOVABLE | GFP_NOFS); if (unlikely(!bh)) return ERR_PTR(-ENOMEM); @@ -1088,7 +1088,7 @@ static int ext4_ext_split(handle_t *handle, struct inode *inode, err = -EIO; goto cleanup; } - bh = sb_getblk(inode->i_sb, newblock); + bh = sb_getblk_gfp(inode->i_sb, newblock, __GFP_MOVABLE | GFP_NOFS); if (unlikely(!bh)) { err = -ENOMEM; goto cleanup; @@ -1282,7 +1282,7 @@ static int ext4_ext_grow_indepth(handle_t *handle, struct inode *inode, if (newblock == 0) return err; - bh = sb_getblk(inode->i_sb, newblock); + bh = sb_getblk_gfp(inode->i_sb, newblock, __GFP_MOVABLE | GFP_NOFS); if (unlikely(!bh)) return -ENOMEM; lock_buffer(bh);
Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes possible deadlocks in the page writeback path. Signed-off-by: Nikolay Borisov <kernel@kyup.com> --- fs/ext4/extents.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)