LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Joel Fernandes <joel@joelfernandes.org>
To: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com, Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>,
Kees Cook <keescook@chromium.org>,
Tony Luck <tony.luck@intel.com>
Subject: Re: [RFC 3/6] pstore: remove max argument from ramoops_get_next_prz
Date: Fri, 26 Oct 2018 12:22:06 -0700 [thread overview]
Message-ID: <20181026192206.GC187415@joelaf.mtv.corp.google.com> (raw)
In-Reply-To: <20181026180042.52199-3-joel@joelfernandes.org>
On Fri, Oct 26, 2018 at 11:00:39AM -0700, Joel Fernandes (Google) wrote:
> From the code flow, the 'max' checks are already being done on the prz
> passed to ramoops_get_next_prz. Lets remove it to simplify this function
> and reduce its arguments.
>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> fs/pstore/ram.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index cbfdf4b8e89d..3055e05acab1 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -124,14 +124,14 @@ static int ramoops_pstore_open(struct pstore_info *psi)
> }
>
> static struct persistent_ram_zone *
> -ramoops_get_next_prz(struct persistent_ram_zone *przs[], uint *c, uint max,
> +ramoops_get_next_prz(struct persistent_ram_zone *przs[], uint *c,
> u64 *id, enum pstore_type_id *typep, bool update)
> {
> struct persistent_ram_zone *prz;
> int i = (*c)++;
>
> /* Give up if we never existed or have hit the end. */
> - if (!przs || i >= max)
> + if (!przs)
> return NULL;
>
> prz = przs[i];
Ah, looks like I may have introduced an issue here since 'i' isn't checked by
the caller for the single prz case, its only checked for the multiple prz
cases, so something like below could be folded in. I still feel its better
than passing the max argument.
Another thought is, even better we could have a different function when
there's only one prz and not have to pass an array, just pass the first
element? Something like...
ramoops_get_next_prz_single(struct persistent_ram_zone *prz, uint *c,
enum pstore_type_id *typep, bool update)
And for the _single case, we also wouldn't need to pass id so that's another
argument less.
Let me know what you think, otherwise something like the below will need to
be folded in to fix this patch... thanks.
----8<---
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 5702b692bdb9..061d2af2485b 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -268,17 +268,19 @@ static ssize_t ramoops_pstore_read(struct pstore_record *record)
}
}
- if (!prz_ok(prz))
+ if (!prz_ok(prz) && !cxt->console_read_cnt) {
prz = ramoops_get_next_prz(&cxt->cprz, &cxt->console_read_cnt,
record, 0);
+ }
- if (!prz_ok(prz))
+ if (!prz_ok(prz) && !cxt->pmsg_read_cnt)
prz = ramoops_get_next_prz(&cxt->mprz, &cxt->pmsg_read_cnt,
record, 0);
/* ftrace is last since it may want to dynamically allocate memory. */
if (!prz_ok(prz)) {
- if (!(cxt->flags & RAMOOPS_FLAG_FTRACE_PER_CPU)) {
+ if (!(cxt->flags & RAMOOPS_FLAG_FTRACE_PER_CPU) &&
+ !cxt->ftrace_read_cnt) {
prz = ramoops_get_next_prz(cxt->fprzs,
&cxt->ftrace_read_cnt, record, 0);
} else {
next prev parent reply other threads:[~2018-10-26 19:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 18:00 [RFC 1/6] pstore: map pstore types to names Joel Fernandes (Google)
2018-10-26 18:00 ` [RFC 2/6] pstore: remove type argument from ramoops_get_next_prz Joel Fernandes (Google)
2018-10-26 19:05 ` Kees Cook
2018-10-26 18:00 ` [RFC 3/6] pstore: remove max " Joel Fernandes (Google)
2018-10-26 19:22 ` Joel Fernandes [this message]
2018-10-26 19:27 ` Kees Cook
2018-10-26 19:40 ` Joel Fernandes
2018-10-26 19:22 ` Kees Cook
2018-10-26 18:00 ` [RFC 4/6] pstore: further reduce ramoops_get_next_prz arguments by passing record Joel Fernandes (Google)
2018-10-26 19:32 ` Kees Cook
2018-10-26 19:36 ` Joel Fernandes
2018-10-26 18:00 ` [RFC 5/6] pstore: donot treat empty buffers as valid Joel Fernandes (Google)
2018-10-26 19:39 ` Kees Cook
2018-10-26 20:22 ` Joel Fernandes
2018-10-26 18:00 ` [RFC 6/6] Revert "pstore/ram_core: Do not reset restored zone's position and size" Joel Fernandes (Google)
2018-10-26 18:16 ` Kees Cook
2018-10-26 18:22 ` Joel Fernandes
2018-10-26 19:42 ` Kees Cook
2018-10-26 20:09 ` Joel Fernandes
2018-10-26 19:04 ` [RFC 1/6] pstore: map pstore types to names Kees Cook
2018-10-26 20:35 ` Joel Fernandes
2018-10-26 20:41 ` Kees Cook
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=20181026192206.GC187415@joelaf.mtv.corp.google.com \
--to=joel@joelfernandes.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--subject='Re: [RFC 3/6] pstore: remove max argument from ramoops_get_next_prz' \
/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
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).