From: John Ogness <john.ogness@linutronix.de>
To: Scott Wood <swood@redhat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-rt-users@vger.kernel.org
Subject: Re: [PATCH] printk: kmsg_dump: remove mutex usage
Date: Thu, 25 Apr 2019 08:51:26 +0200 [thread overview]
Message-ID: <87v9z2inm9.fsf@linutronix.de> (raw)
In-Reply-To: <1a771e7bfe8f7cc296809307cc75372c7cec42be.camel@redhat.com> (Scott Wood's message of "Wed, 24 Apr 2019 15:07:25 -0500")
On 2019-04-24, Scott Wood <swood@redhat.com> wrote:
> On Wed, 2019-04-24 at 16:36 +0200, John Ogness wrote:
>> @@ -2830,16 +2829,18 @@ void kmsg_dump(enum kmsg_dump_reason reason)
>> if (dumper->max_reason && reason > dumper->max_reason)
>> continue;
>>
>> - /* initialize iterator with data about the stored records */
>> - dumper->active = true;
>> + /*
>> + * use a local copy to avoid modifying the
>> + * iterator used by any other cpus/contexts
>> + */
>> + memcpy(&dumper_local, dumper, sizeof(dumper_local));
>>
>> - kmsg_dump_rewind(dumper);
>> + /* initialize iterator with data about the stored records */
>> + dumper_local.active = true;
>> + kmsg_dump_rewind(&dumper_local);
>>
>> /* invoke dumper which will iterate over records */
>> - dumper->dump(dumper, reason);
>> -
>> - /* reset iterator */
>> - dumper->active = false;
>> + dumper_local.dump(&dumper_local, reason);
>> }
>
> When would a dumper (or anything else that checks it) ever see active be
> false?
A valid question. Originally I wanted to completely remove the active
flag. But really the rt patchset is not the place for these kinds of
changes. I am currently reworking printk (for mainline) and I will
evaluate the purpose/usefulness of the active flag for that work.
>> rcu_read_unlock();
>> }
>> @@ -2951,9 +2952,7 @@ bool kmsg_dump_get_line(struct kmsg_dumper *dumper,
>> bool syslog,
>> {
>> bool ret;
>>
>> - mutex_lock(&kmsg_dump_lock);
>> ret = kmsg_dump_get_line_nolock(dumper, syslog, line, size, len);
>> - mutex_unlock(&kmsg_dump_lock);
>>
>> return ret;
>> }
>> @@ -3105,9 +3104,7 @@ void kmsg_dump_rewind_nolock(struct kmsg_dumper
>> *dumper)
>> */
>> void kmsg_dump_rewind(struct kmsg_dumper *dumper)
>> {
>> - mutex_lock(&kmsg_dump_lock);
>> kmsg_dump_rewind_nolock(dumper);
>> - mutex_unlock(&kmsg_dump_lock);
>> }
>> EXPORT_SYMBOL_GPL(kmsg_dump_rewind);
>>
>
> Any reason not to get rid of the wrappers now that the lock's gone?
I wanted my patch to be as less intrusive as possible. For my mainline
work I will look into eliminating the wrappers.
John Ogness
next prev parent reply other threads:[~2019-04-25 6:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 21:56 kmsg_dump() sleeping while atomic Scott Wood
2019-04-24 14:36 ` [PATCH] printk: kmsg_dump: remove mutex usage John Ogness
2019-04-24 20:07 ` Scott Wood
2019-04-25 6:51 ` John Ogness [this message]
2019-04-30 15:10 ` Sebastian Andrzej Siewior
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=87v9z2inm9.fsf@linutronix.de \
--to=john.ogness@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=swood@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 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.