All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Matthew Wilcox <willy@infradead.org>, Gao Xiang <hsiangkao@aol.com>
Cc: Chao Yu <yuchao0@huawei.com>, Richard Weinberger <richard@nod.at>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>,
	linux-erofs@lists.ozlabs.org, Miao Xie <miaoxie@huawei.com>,
	Fang Wei <fangwei1@huawei.com>, Gao Xiang <gaoxiang25@huawei.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] staging: erofs: fix an error handling in erofs_readdir()
Date: Sun, 18 Aug 2019 18:39:52 +0800	[thread overview]
Message-ID: <c624d057-cd42-515c-cff8-cf68340401e0@kernel.org> (raw)
In-Reply-To: <20190818025339.GB14592@bombadil.infradead.org>

On 2019-8-18 10:53, Matthew Wilcox wrote:
> On Sun, Aug 18, 2019 at 10:32:45AM +0800, Gao Xiang wrote:
>> On Sat, Aug 17, 2019 at 07:20:55PM -0700, Matthew Wilcox wrote:
>>> On Sun, Aug 18, 2019 at 09:56:31AM +0800, Gao Xiang wrote:
>>>> @@ -82,8 +82,12 @@ static int erofs_readdir(struct file *f, struct dir_context *ctx)
>>>>  		unsigned int nameoff, maxsize;
>>>>  
>>>>  		dentry_page = read_mapping_page(mapping, i, NULL);
>>>> -		if (IS_ERR(dentry_page))
>>>> -			continue;
>>>> +		if (IS_ERR(dentry_page)) {
>>>> +			errln("fail to readdir of logical block %u of nid %llu",
>>>> +			      i, EROFS_V(dir)->nid);
>>>> +			err = PTR_ERR(dentry_page);
>>>> +			break;
>>>
>>> I don't think you want to use the errno that came back from
>>> read_mapping_page() (which is, I think, always going to be -EIO).
>>> Rather you want -EFSCORRUPTED, at least if I understand the recent
>>> patches to ext2/ext4/f2fs/xfs/...
>>
>> Thanks for your reply and noticing this. :)
>>
>> Yes, as I talked with you about read_mapping_page() in a xfs related
>> topic earlier, I think I fully understand what returns here.
>>
>> I actually had some concern about that before sending out this patch.
>> You know the status is
>>    PG_uptodate is not set and PG_error is set here.
>>
>> But we cannot know it is actually a disk read error or due to
>> corrupted images (due to lack of page flags or some status, and
>> I think it could be a waste of page structure space for such
>> corrupted image or disk error)...
>>
>> And some people also like propagate errors from insiders...
>> (and they could argue about err = -EFSCORRUPTED as well..)
>>
>> I'd like hear your suggestion about this after my words above?
>> still return -EFSCORRUPTED?
> 
> I don't think it matters whether it's due to a disk error or a corrupted
> image.  We can't read the directory entry, so we should probably return
> -EFSCORRUPTED.  Thinking about it some more, read_mapping_page() can
> also return -ENOMEM, so it should probably look something like this:
> 
> 		err = 0;
> 		if (dentry_page == ERR_PTR(-ENOMEM))
> 			err = -ENOMEM;
> 		else if (IS_ERR(dentry_page)) {
> 			errln("fail to readdir of logical block %u of nid %llu",
> 			      i, EROFS_V(dir)->nid);
> 			err = -EFSCORRUPTED;

Well, if there is real IO error happen under filesystem, we should return -EIO
instead of EFSCORRUPTED?

The right fix may be that doing sanity check on on-disk blkaddr, and return
-EFSCORRUPTED if the blkaddr is invalid and propagate the error to its caller
erofs_readdir(), IIUC below error info.

> [36297.354090] attempt to access beyond end of device
> [36297.354098] loop17: rw=0, want=29887428984, limit=1953128
> [36297.354107] attempt to access beyond end of device
> [36297.354109] loop17: rw=0, want=29887428480, limit=1953128
> [36301.827234] attempt to access beyond end of device
> [36301.827243] loop17: rw=0, want=29887428480, limit=1953128

Thanks,

> 		}
> 
> 		if (err)
> 			break;
> 

WARNING: multiple messages have this Message-ID (diff)
From: chao@kernel.org (Chao Yu)
Subject: [PATCH v2] staging: erofs: fix an error handling in erofs_readdir()
Date: Sun, 18 Aug 2019 18:39:52 +0800	[thread overview]
Message-ID: <c624d057-cd42-515c-cff8-cf68340401e0@kernel.org> (raw)
In-Reply-To: <20190818025339.GB14592@bombadil.infradead.org>

On 2019-8-18 10:53, Matthew Wilcox wrote:
> On Sun, Aug 18, 2019@10:32:45AM +0800, Gao Xiang wrote:
>> On Sat, Aug 17, 2019@07:20:55PM -0700, Matthew Wilcox wrote:
>>> On Sun, Aug 18, 2019@09:56:31AM +0800, Gao Xiang wrote:
>>>> @@ -82,8 +82,12 @@ static int erofs_readdir(struct file *f, struct dir_context *ctx)
>>>>  		unsigned int nameoff, maxsize;
>>>>  
>>>>  		dentry_page = read_mapping_page(mapping, i, NULL);
>>>> -		if (IS_ERR(dentry_page))
>>>> -			continue;
>>>> +		if (IS_ERR(dentry_page)) {
>>>> +			errln("fail to readdir of logical block %u of nid %llu",
>>>> +			      i, EROFS_V(dir)->nid);
>>>> +			err = PTR_ERR(dentry_page);
>>>> +			break;
>>>
>>> I don't think you want to use the errno that came back from
>>> read_mapping_page() (which is, I think, always going to be -EIO).
>>> Rather you want -EFSCORRUPTED, at least if I understand the recent
>>> patches to ext2/ext4/f2fs/xfs/...
>>
>> Thanks for your reply and noticing this. :)
>>
>> Yes, as I talked with you about read_mapping_page() in a xfs related
>> topic earlier, I think I fully understand what returns here.
>>
>> I actually had some concern about that before sending out this patch.
>> You know the status is
>>    PG_uptodate is not set and PG_error is set here.
>>
>> But we cannot know it is actually a disk read error or due to
>> corrupted images (due to lack of page flags or some status, and
>> I think it could be a waste of page structure space for such
>> corrupted image or disk error)...
>>
>> And some people also like propagate errors from insiders...
>> (and they could argue about err = -EFSCORRUPTED as well..)
>>
>> I'd like hear your suggestion about this after my words above?
>> still return -EFSCORRUPTED?
> 
> I don't think it matters whether it's due to a disk error or a corrupted
> image.  We can't read the directory entry, so we should probably return
> -EFSCORRUPTED.  Thinking about it some more, read_mapping_page() can
> also return -ENOMEM, so it should probably look something like this:
> 
> 		err = 0;
> 		if (dentry_page == ERR_PTR(-ENOMEM))
> 			err = -ENOMEM;
> 		else if (IS_ERR(dentry_page)) {
> 			errln("fail to readdir of logical block %u of nid %llu",
> 			      i, EROFS_V(dir)->nid);
> 			err = -EFSCORRUPTED;

Well, if there is real IO error happen under filesystem, we should return -EIO
instead of EFSCORRUPTED?

The right fix may be that doing sanity check on on-disk blkaddr, and return
-EFSCORRUPTED if the blkaddr is invalid and propagate the error to its caller
erofs_readdir(), IIUC below error info.

> [36297.354090] attempt to access beyond end of device
> [36297.354098] loop17: rw=0, want=29887428984, limit=1953128
> [36297.354107] attempt to access beyond end of device
> [36297.354109] loop17: rw=0, want=29887428480, limit=1953128
> [36301.827234] attempt to access beyond end of device
> [36301.827243] loop17: rw=0, want=29887428480, limit=1953128

Thanks,

> 		}
> 
> 		if (err)
> 			break;
> 

  parent reply	other threads:[~2019-08-18 10:40 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-18  1:48 [PATCH] staging: erofs: fix an error handling in erofs_readdir() Gao Xiang
2019-08-18  1:48 ` Gao Xiang
2019-08-18  1:56 ` [PATCH v2] " Gao Xiang
2019-08-18  1:56   ` Gao Xiang
2019-08-18  2:20   ` Matthew Wilcox
2019-08-18  2:20     ` Matthew Wilcox
2019-08-18  2:32     ` Gao Xiang
2019-08-18  2:32       ` Gao Xiang
2019-08-18  2:53       ` Matthew Wilcox
2019-08-18  2:53         ` Matthew Wilcox
2019-08-18  3:01         ` Gao Xiang
2019-08-18  3:01           ` Gao Xiang
2019-08-18  3:18           ` [PATCH] " Gao Xiang
2019-08-18  3:18             ` Gao Xiang
2019-08-18 12:07             ` kbuild test robot
2019-08-18 12:07               ` kbuild test robot
2019-08-18 12:07               ` kbuild test robot
2019-08-18 13:17             ` kbuild test robot
2019-08-18 13:17               ` kbuild test robot
2019-08-18 13:17               ` kbuild test robot
2019-08-18 13:25               ` Gao Xiang
2019-08-18 13:25                 ` Gao Xiang
2019-08-20  6:50                 ` Philip Li
2019-08-20  6:50                   ` Philip Li
2019-08-20  6:50                   ` Philip Li
2019-08-20  6:50                   ` Gao Xiang
2019-08-20  6:50                     ` Gao Xiang
2019-08-20  6:50                     ` Gao Xiang
2019-08-20  6:58                     ` Li, Philip
2019-08-20  6:58                       ` Li, Philip
2019-08-20  6:58                       ` Li, Philip
2019-08-20  7:16                       ` Gao Xiang
2019-08-20  7:16                         ` Gao Xiang
2019-08-20  7:16                         ` Gao Xiang
2019-08-18  3:21           ` [PATCH v3 RESEND] " Gao Xiang
2019-08-18  3:21             ` Gao Xiang
2019-08-18  8:33             ` Richard Weinberger
2019-08-18  8:33               ` Richard Weinberger
2019-08-18  9:10               ` Gao Xiang
2019-08-18  9:10                 ` Gao Xiang
2019-08-18  9:18                 ` [PATCH v3 RESEND] staging: erofs: fix an error handling in erofs_readdir()y Gao Xiang
2019-08-18  9:18                   ` Gao Xiang
2019-08-18 11:52             ` [PATCH v3 RESEND] staging: erofs: fix an error handling in erofs_readdir() Sasha Levin
2019-08-18 12:29             ` Chao Yu
2019-08-18 12:29               ` Chao Yu
2019-08-18 12:33             ` Matthew Wilcox
2019-08-18 12:33               ` Matthew Wilcox
2019-08-18 12:38               ` Gao Xiang
2019-08-18 12:38                 ` Gao Xiang
2019-08-18 12:54                 ` [PATCH v4] " Gao Xiang
2019-08-18 12:54                   ` Gao Xiang
2019-08-19  0:08                   ` Sasha Levin
2019-08-18 10:39         ` Chao Yu [this message]
2019-08-18 10:39           ` [PATCH v2] " Chao Yu
2019-08-18 10:52           ` Gao Xiang
2019-08-18 10:52             ` Gao Xiang
2019-08-18 12:28             ` Chao Yu
2019-08-18 12:28               ` Chao Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c624d057-cd42-515c-cff8-cf68340401e0@kernel.org \
    --to=chao@kernel.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=fangwei1@huawei.com \
    --cc=gaoxiang25@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hsiangkao@aol.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miaoxie@huawei.com \
    --cc=richard@nod.at \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.org \
    --cc=yuchao0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.