From patchwork Tue Jan 5 09:31:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: ?? X-Patchwork-Id: 7953461 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D47999F38D for ; Tue, 5 Jan 2016 09:33:16 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0A80D20384 for ; Tue, 5 Jan 2016 09:33:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 21B4820382 for ; Tue, 5 Jan 2016 09:33:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbcAEJcn (ORCPT ); Tue, 5 Jan 2016 04:32:43 -0500 Received: from mailout4.samsung.com ([203.254.224.34]:45989 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbcAEJcl (ORCPT ); Tue, 5 Jan 2016 04:32:41 -0500 Received: from epcpsbgm1new.samsung.com (epcpsbgm1 [203.254.230.26]) by mailout4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O0H02HQQ3U12D10@mailout4.samsung.com>; Tue, 05 Jan 2016 18:32:39 +0900 (KST) X-AuditID: cbfee61a-f79266d000003652-84-568b8db75bbc Received: from epmmp1.local.host ( [203.254.227.16]) by epcpsbgm1new.samsung.com (EPCPMTA) with SMTP id FC.F4.13906.7BD8B865; Tue, 5 Jan 2016 18:32:39 +0900 (KST) Received: from yuchao ([109.123.105.89]) by mmp1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0O0H0071J3T3W870@mmp1.samsung.com>; Tue, 05 Jan 2016 18:32:39 +0900 (KST) From: Chao Yu To: 'Jaegeuk Kim' Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <1451784366-14261-1-git-send-email-jaegeuk@kernel.org> In-reply-to: <1451784366-14261-1-git-send-email-jaegeuk@kernel.org> Subject: RE: [f2fs-dev] [PATCH 1/3] f2fs: check the page status filled from disk Date: Tue, 05 Jan 2016 17:31:51 +0800 Message-id: <00a101d1479c$02ae9080$080bb180$@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: AQJbHXhCd6W0MPVptkb1cVFEtFzf6J3Y1ylg Content-language: zh-cn X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsVy+t9jAd3tvd1hBhunclk8WT+L2eLSIneL PXtPslhc3jWHzYHFY9OqTjaP3Qs+M3l83iQXwBzFZZOSmpNZllqkb5fAlfGn6yRrwSKRin37 XjM2MB4V6GLk5JAQMJHYd+0AK4QtJnHh3nq2LkYuDiGBpYwSV/ZvYIVwXjFK/FvVygxSxSag IrG84z8TiC0ioCbRu28KmM0skCkxof8FO4gtJOAkMf38fLB6TgFnifd31jGC2MICARLLziwB s1kEVCVW/r8LZvMKWEpc3d/DDmELSvyYfI8FYqaWxPqdx6Hmy0tsXvOWGeJSBYkdZ18zQtxg JHG06yEzRI24xMYjt1gmMArNQjJqFpJRs5CMmoWkZQEjyypGidSC5ILipPRcw7zUcr3ixNzi 0rx0veT83E2M4Ah4JrWD8eAu90OMAhyMSjy8HC+7woRYE8uKK3MPMUpwMCuJ8AoWdocJ8aYk VlalFuXHF5XmpBYfYpTmYFES5629FBkmJJCeWJKanZpakFoEk2Xi4JRqYLwgrVl+eXFwev3/ wOX9rbZFLjYzxZKOzqxbbdvJGym5SMGnS7p6D9vqmSsfPixndXHQ33Ly8W7xO2cKtka8X/ZK qEVIuOuOFmfPisWrGXjKmr8l2pirTKrol1hcohfctaRA6fxP/VCGL80/5Jn7dQQLX/7vU55i /UZXamVhv0j//mt8BldzlFiKMxINtZiLihMBR2ieJXwCAAA= Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Jaegeuk, > -----Original Message----- > From: Jaegeuk Kim [mailto:jaegeuk@kernel.org] > Sent: Sunday, January 03, 2016 9:26 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/3] f2fs: check the page status filled from disk > > After reading a page, we need to check whether there is any error. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/data.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 89a978c..11b2111 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -448,6 +448,14 @@ repeat: > > /* wait for read completion */ > lock_page(page); > + if (unlikely(!PageUptodate(page))) { > + f2fs_put_page(page, 1); > + return ERR_PTR(-EIO); There is a convention in get_new_data_page, anyway we should release ipage if there is any error occurs, but I think it will be ok to return directly since it seems impossible the new dentry page has its real block address. To avoid any bug here or wrong usage, how about add bug_on as following patch? From d92f0f34493b27ef28da67c446d552ce721b5d6f Mon Sep 17 00:00:00 2001 From: Chao Yu Date: Tue, 5 Jan 2016 15:28:56 +0800 Subject: [PATCH] f2fs: add f2fs_bug_on in get_new_data_page In get_new_data_page, locked inode page should not be hold before get_read_data_page, this patch adds f2fs_bug_on to detect this condition. Signed-off-by: Chao Yu --- fs/f2fs/data.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 48f0bd3..2c5e3f6 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -440,6 +440,8 @@ repeat: zero_user_segment(page, 0, PAGE_CACHE_SIZE); SetPageUptodate(page); } else { + f2fs_bug_on(F2FS_I_SB(inode), ipage); + f2fs_put_page(page, 1); page = get_read_data_page(inode, index, READ_SYNC, true);