From: Richard Weinberger <richard@nod.at>
To: pavi1729 <pavitra1729@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: Query on ubifs_assert
Date: Tue, 07 Jul 2015 09:37:05 +0200 [thread overview]
Message-ID: <559B81A1.7010302@nod.at> (raw)
In-Reply-To: <CAMf7+Lj93m55AD0ORfvumxEF5NrZUjhkSZ-X6h2JZLtoRNLcAQ@mail.gmail.com>
Am 07.07.2015 um 09:29 schrieb pavi1729:
> Richard,
> Just wondering ..
>
> On Wed, Jul 1, 2015 at 7:41 PM, Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
>> On Wed, Jul 1, 2015 at 1:03 PM, pavi1729 <pavitra1729@gmail.com> wrote:
>>> Hi,
>>>
>>> FILE: fs/ubifs/misc.h :
>>> FUNCTION : ubifs_compr_present
>>>
>>> "ubifs_compr_present" function has "ubifs_assert" which checks for the
>>> valid compression value
>>> and does a stack_dump if not.
>>>
>>> Could there be a case where the "compr_type" is corrupt; if yes, then
>>> does a stack_dump suffice?
>>> Thus if compr_type is invalid then the below return is not reliable.
>>> return !!ubifs_compressors[compr_type]->capi_name;
>>
>> If compr_type is invalid something nasty is happening and the kernel will crash
>> at some point.
>> But using the ubifs_assert() we can see at least what went wrong.
> .. if we know for sure that, the kernel will crash, then why not panic
> here and halt the system.
> We know for sure that it is going to crash anyways.
Because we don't want to stop the machine. Maybe only the current thread
dies...
But I'm sure some ubifs_assert() could be converted to WARN_ON().
Thanks,
//richard
next prev parent reply other threads:[~2015-07-07 7:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-01 11:03 Query on ubifs_assert pavi1729
2015-07-01 14:11 ` Richard Weinberger
2015-07-01 18:24 ` pavi1729
2015-07-07 7:29 ` pavi1729
2015-07-07 7:37 ` Richard Weinberger [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-07-01 11:10 pavi1729
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=559B81A1.7010302@nod.at \
--to=richard@nod.at \
--cc=linux-mtd@lists.infradead.org \
--cc=pavitra1729@gmail.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.