Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752066AbbHTJJc (ORCPT ); Thu, 20 Aug 2015 05:09:32 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:57827 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751943AbbHTJJa (ORCPT ); Thu, 20 Aug 2015 05:09:30 -0400 X-AuditID: cbfee61b-f79706d000001b96-8b-55d59948a70b From: Chao Yu To: "'Jaegeuk Kim'" Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <1439593751-21879-1-git-send-email-jaegeuk@kernel.org> In-reply-to: <1439593751-21879-1-git-send-email-jaegeuk@kernel.org> Subject: RE: [f2fs-dev] [PATCH 1/2] f2fs: handle failed bio allocation Date: Thu, 20 Aug 2015 17:08:24 +0800 Message-id: <01b801d0db27$e8b9e9d0$ba2dbd70$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQFaoAjn54AsIe0uJja8pok+3EhfDp8A0Vyw Content-language: zh-cn X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsVy+t9jAV2PmVdDDZ7M0bB4sn4Ws8WlRe4W e/aeZLG4vGsOmwOLx6ZVnWweuxd8ZvL4vEkugDmKyyYlNSezLLVI3y6BK2PNEfWCPcIVHWcm sDcwXuDvYuTkkBAwkZh5cRMThC0mceHeerYuRi4OIYGljBJH/nxih3BeMUp86V7ADlLFJqAi sbzjP1iHiICaRO++KWA2s0CmxIT+F2A1QgJOEt9O3geLcwo4S2zZdgssLizgJvGi5QQbiM0i oCpx5858VhCbV8BSYuKTGWwQtqDEj8n3WCBmakms33kcar68xOY1b5khLlWQ2HH2NSPEDUYS bU3H2CFqxCU2HrnFMoFRaBaSUbOQjJqFZNQsJC0LGFlWMUqkFiQXFCel5xrlpZbrFSfmFpfm pesl5+duYgSH/zPpHYyHd7kfYhTgYFTi4b0gfDVUiDWxrLgy9xCjBAezkgivnw5QiDclsbIq tSg/vqg0J7X4EKM0B4uSOK++yaZQIYH0xJLU7NTUgtQimCwTB6dUA2NBHMOuNM/SxNWlDuxr fHXjXVRX1DQz6d95vmtTT66Fe27vnym9TltM3T71/4t6e+h7csXNI6K5NtUKXyXsevSun1uU 4NrKcrU+fkJdiaP5vGfGvI4LrB4lcGiZzPr3/LNMyt/1LvJpxx4rrlgglFRRLX44u1nMclV4 tEum6aKbq2dFzy70U2Ipzkg01GIuKk4EAGOmy6x7AgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2674 Lines: 68 Hi Jaegeuk, > -----Original Message----- > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org] > Sent: Saturday, August 15, 2015 7:09 AM > To: linux-kernel@vger.kernel.org; linux-fsdevel@vger.kernel.org; > linux-f2fs-devel@lists.sourceforge.net > Cc: Jaegeuk Kim > Subject: [f2fs-dev] [PATCH 1/2] f2fs: handle failed bio allocation > > As the below comment of bio_alloc_bioset, f2fs can allocate multiple bios at the > same time. So, we can't guarantee that bio is allocated all the time. > > " > * When @bs is not NULL, if %__GFP_WAIT is set then bio_alloc will always be > * able to allocate a bio. This is due to the mempool guarantees. To make this > * work, callers must never allocate more than 1 bio at a time from this pool. > * Callers that need to allocate more than 1 bio must always submit the > * previously allocated bio for IO before attempting to allocate a new one. > * Failure to do so can cause deadlocks under memory pressure. > " > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/data.c | 3 +-- > fs/f2fs/f2fs.h | 15 +++++++++++++++ > fs/f2fs/segment.c | 14 +++++++++++--- > 3 files changed, 27 insertions(+), 5 deletions(-) > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index cad9ebe..726e58b 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -90,8 +90,7 @@ static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, block_t blk_addr, > { > struct bio *bio; > > - /* No failure on bio allocation */ > - bio = bio_alloc(GFP_NOIO, npages); How about using __GFP_NOFAIL flag to avoid failing in bio_alloc instead of adding opencode endless loop in code? We can see the reason in this commit 647757197cd3 ("mm: clarify __GFP_NOFAIL deprecation status ") "__GFP_NOFAIL is documented as a deprecated flag since commit 478352e789f5 ("mm: add comment about deprecation of __GFP_NOFAIL"). This has discouraged people from using it but in some cases an opencoded endless loop around allocator has been used instead. So the allocator is not aware of the de facto __GFP_NOFAIL allocation because this information was not communicated properly. Let's make clear that if the allocation context really cannot afford failure because there is no good failure policy then using __GFP_NOFAIL is preferable to opencoding the loop outside of the allocator." BTW, I found that f2fs_kmem_cache_alloc also could be replaced, we could fix them together. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/