From: hyeongseok <hyeongseok@gmail.com>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: "device-mapper development" <dm-devel@redhat.com>,
김형석 <hyeongseok.kim@lge.com>, "Mike Snitzer" <snitzer@redhat.com>,
"Alasdair Kergon" <agk@redhat.com>
Subject: Re: [dm-devel] [PATCH] dm verity: skip verity work on I/O errors when system is shutting down
Date: Mon, 7 Dec 2020 08:18:39 +0900 [thread overview]
Message-ID: <7fda3da9-e0b1-abdd-4bde-3a46405536f5@gmail.com> (raw)
In-Reply-To: <CABCJKueAPHNqdq=k6AhhxDR-oQdNs8+=BhmY8wGdgNcwr_-KMQ@mail.gmail.com>
On 12/5/20 8:03 AM, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 3:46 PM hyeongseok <hyeongseok@gmail.com> wrote:
>> On 12/4/20 2:22 AM, Sami Tolvanen wrote:
>>> Hi,
>>>
>>> On Wed, Dec 2, 2020 at 4:48 PM Hyeongseok Kim <hyeongseok@gmail.com> wrote:
>>>> If emergency system shutdown is called, like by thermal shutdown,
>>>> dm device could be alive when the block device couldn't process
>>>> I/O requests anymore. In this status, the handling of I/O errors
>>>> by new dm I/O requests or by those already in-flight can lead to
>>>> a verity corruption state, which is misjudgment.
>>>> So, skip verity work for I/O error when system is shutting down.
>>> Thank you for the patch. I agree that attempting to correct I/O errors
>>> when the system is shutting down, and thus generating more I/O that's
>>> likely going to fail, is not a good idea.
>>>
>>>> Signed-off-by: Hyeongseok Kim <hyeongseok@gmail.com>
>>>> ---
>>>> drivers/md/dm-verity-target.c | 12 +++++++++++-
>>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
>>>> index f74982dcbea0..ba62c537798b 100644
>>>> --- a/drivers/md/dm-verity-target.c
>>>> +++ b/drivers/md/dm-verity-target.c
>>>> @@ -64,6 +64,15 @@ struct buffer_aux {
>>>> int hash_verified;
>>>> };
>>>>
>>>> +/*
>>>> + * While system shutdown, skip verity work for I/O error.
>>>> + */
>>>> +static inline bool verity_is_system_shutting_down(void)
>>>> +{
>>>> + return system_state == SYSTEM_HALT || system_state == SYSTEM_POWER_OFF
>>>> + || system_state == SYSTEM_RESTART;
>>>> +}
>>> Which of these states does the system get to during an emergency
>>> shutdown? Can we simplify this by changing the test to system_state >
>>> SYSTEM_RUNNING?
>> I only saw that it was SYSTEM_POWER_OFF or SYSTEM_RESTART, I wonder if
>> I/O error can occur in SYSTEM_SUSPEND state.
> OK, so think the current version is fine then.
>
>> As far as I know, this could be happen in emergency shutdown case,
>> can you explain if you have a case when I/O error can occur by
>> SYSTEM_SUSPEND?
> No, I don't have a case where that would happen.
>
>>> Otherwise, this looks good to me. However, I'm now wondering if an I/O
>>> error should ever result in verity_handle_err() being called. Without
>>> FEC, dm-verity won't call verity_handle_err() when I/O fails, but with
>>> FEC enabled, it currently does, assuming error correction fails. Any
>>> thoughts?
>> Yes, I have thought about this, and to be honest, I think verity or FEC
>> should not call verity_handle_error() in case of I/O errors.
> I tend to agree. We could simply check the original bio->bi_status in
> verity_verify_io() and if we failed to correct an I/O error, return an
> error instead of going into verity_handle_err(). Any thoughts?
>
>> But, because I couldn't know the ability of FEC, I only focused on not
>> breaking curent logics other than system shutdown && I/O errors case.
> Sure, makes sense. We can addrwess that separately.
Sounds reasonable. I hope the next improvements.
>
> Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
>
> Sami
>
Thank you for the review.
Hyeongseok
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2020-12-07 10:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-03 0:46 [dm-devel] [PATCH] dm verity: skip verity work on I/O errors when system is shutting down Hyeongseok Kim
2020-12-03 17:22 ` Sami Tolvanen
2020-12-03 23:46 ` hyeongseok
2020-12-04 23:03 ` Sami Tolvanen
2020-12-06 23:18 ` hyeongseok [this message]
2020-12-10 1:03 ` Hyeongseok Kim
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=7fda3da9-e0b1-abdd-4bde-3a46405536f5@gmail.com \
--to=hyeongseok@gmail.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=hyeongseok.kim@lge.com \
--cc=samitolvanen@google.com \
--cc=snitzer@redhat.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;
as well as URLs for NNTP newsgroup(s).