From: Chao Yu <chao@kernel.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: gregkh@linuxfoundation.org, devel@driverdev.osuosl.org,
Gao Xiang <gaoxiang25@huawei.com>, Chao Yu <yuchao0@huawei.com>,
linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/8] staging: erofs: separate erofs_get_meta_page
Date: Mon, 13 Aug 2018 20:34:29 +0800 [thread overview]
Message-ID: <c7ba72fd-8224-c277-3c05-931eaa275ee3@kernel.org> (raw)
In-Reply-To: <20180813110405.3qoburir3ds5ux33@mwanda>
On 2018/8/13 19:04, Dan Carpenter wrote:
> On Sun, Aug 12, 2018 at 10:01:44PM +0800, Chao Yu wrote:
>> --- a/drivers/staging/erofs/data.c
>> +++ b/drivers/staging/erofs/data.c
>> @@ -39,31 +39,44 @@ static inline void read_endio(struct bio *bio)
>> }
>>
>> /* prio -- true is used for dir */
>> -struct page *erofs_get_meta_page(struct super_block *sb,
>> - erofs_blk_t blkaddr, bool prio)
>> +struct page *__erofs_get_meta_page(struct super_block *sb,
>> + erofs_blk_t blkaddr, bool prio, bool nofail)
>> {
>> - struct inode *bd_inode = sb->s_bdev->bd_inode;
>> - struct address_space *mapping = bd_inode->i_mapping;
>> + struct inode *const bd_inode = sb->s_bdev->bd_inode;
>> + struct address_space *const mapping = bd_inode->i_mapping;
>> + /* prefer retrying in the allocator to blindly looping below */
>> + const gfp_t gfp = mapping_gfp_constraint(mapping, ~__GFP_FS) |
>> + (nofail ? __GFP_NOFAIL : 0);
>> + unsigned int io_retries = nofail ? EROFS_IO_MAX_RETRIES_NOFAIL : 0;
>> struct page *page;
>>
>> repeat:
>> - page = find_or_create_page(mapping, blkaddr,
>> - /*
>> - * Prefer looping in the allocator rather than here,
>> - * at least that code knows what it's doing.
>> - */
>> - mapping_gfp_constraint(mapping, ~__GFP_FS) | __GFP_NOFAIL);
>> -
>> - BUG_ON(!page || !PageLocked(page));
>> + page = find_or_create_page(mapping, blkaddr, gfp);
>> + if (unlikely(page == NULL)) {
>> + DBG_BUGON(nofail);
>> + return ERR_PTR(-ENOMEM);
>> + }
>> + DBG_BUGON(!PageLocked(page));
>>
>> if (!PageUptodate(page)) {
>> struct bio *bio;
>> int err;
>>
>> - bio = erofs_grab_bio(sb, blkaddr, 1, read_endio, true);
>> + bio = erofs_grab_bio(sb, blkaddr, 1, read_endio, nofail);
>> + if (unlikely(bio == NULL)) {
>> + DBG_BUGON(nofail);
>> + err = -ENOMEM;
>> +err_out:
>> + unlock_page(page);
>> + put_page(page);
>> + return ERR_PTR(err);
>
>
> Put this err_out stuff at the bottom of the function so that we don't
> have to do backward hops to get to it.
Agreed, we can move error path at the bottom of this function.
>
>> + }
>>
>> err = bio_add_page(bio, page, PAGE_SIZE, 0);
>> - BUG_ON(err != PAGE_SIZE);
>> + if (unlikely(err != PAGE_SIZE)) {
>> + err = -EFAULT;
>> + goto err_out;
> ^^^^^^^^^^^^
> Like this. Generally avoid backwards hops if you can.
>
>> + }
>>
>> __submit_bio(bio, REQ_OP_READ,
>> REQ_META | (prio ? REQ_PRIO : 0));
>> @@ -72,6 +85,7 @@ struct page *erofs_get_meta_page(struct super_block *sb,
>>
>> /* the page has been truncated by others? */
>> if (unlikely(page->mapping != mapping)) {
>> +unlock_repeat:
>
> The question mark in the "truncated by others?" is a little concerning.
Yup, we can remove the question mark.
> It's slightly weird that we don't check "io_retries" on this path.
We don't need to cover this path since io_retries is used for accounting retry
time only when IO occurs.
Thanks,
>
>> unlock_page(page);
>> put_page(page);
>> goto repeat;
>> @@ -79,10 +93,12 @@ struct page *erofs_get_meta_page(struct super_block *sb,
>>
>> /* more likely a read error */
>> if (unlikely(!PageUptodate(page))) {
>> - unlock_page(page);
>> - put_page(page);
>> -
>> - page = ERR_PTR(-EIO);
>> + if (io_retries) {
>> + --io_retries;
>> + goto unlock_repeat;
>> + }
>> + err = -EIO;
>> + goto err_out;
>
> regards,
> dan carpenter
>
next prev parent reply other threads:[~2018-08-13 12:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-12 14:01 [PATCH 0/8] staging: erofs: fix some issues and clean up codes Chao Yu
2018-08-12 14:01 ` [PATCH 1/8] staging: erofs: introduce erofs_grab_bio Chao Yu
2018-08-12 14:01 ` [PATCH 2/8] staging: erofs: separate erofs_get_meta_page Chao Yu
2018-08-13 11:04 ` Dan Carpenter
2018-08-13 11:23 ` Gao Xiang
2018-08-13 12:34 ` Chao Yu [this message]
2018-08-12 14:01 ` [PATCH 3/8] staging: erofs: add error handling for xattr submodule Chao Yu
2018-08-13 2:00 ` Chao Yu
2018-08-13 2:36 ` Gao Xiang
2018-08-13 2:56 ` [PATCH v2 " Gao Xiang
2018-08-13 8:15 ` [PATCH " Chao Yu
2018-08-13 11:47 ` Dan Carpenter
2018-08-13 12:17 ` Gao Xiang
2018-08-13 12:25 ` Dan Carpenter
2018-08-13 13:40 ` Gao Xiang
2018-08-13 13:50 ` Dan Carpenter
2018-08-13 12:40 ` Dan Carpenter
2018-08-13 12:46 ` Gao Xiang
2018-08-13 12:46 ` Chao Yu
2018-08-12 14:01 ` [PATCH 4/8] staging: erofs: cleanup z_erofs_vle_work_{lookup, register} Chao Yu
2018-08-13 12:00 ` Dan Carpenter
2018-08-13 12:37 ` Gao Xiang
2018-08-13 13:05 ` Dan Carpenter
2018-08-13 13:19 ` Gao Xiang
2018-08-12 14:01 ` [PATCH 5/8] staging: erofs: rearrange vle clustertype definitions Chao Yu
2018-08-12 14:01 ` [PATCH 6/8] staging: erofs: fix vle_decompressed_index_clusterofs Chao Yu
2018-08-13 12:03 ` Dan Carpenter
2018-08-13 13:01 ` Gao Xiang
2018-08-12 14:01 ` [PATCH 7/8] staging: erofs: fix integer overflow on 32-bit platform Chao Yu
2018-08-12 14:01 ` [PATCH 8/8] staging: erofs: fix compression mapping beyond EOF 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=c7ba72fd-8224-c277-3c05-931eaa275ee3@kernel.org \
--to=chao@kernel.org \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gaoxiang25@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome