public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "\"Jan H. Schönherr\"" <schnhrr@cs.tu-berlin.de>
To: Kay Sievers <kay@vrfy.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] printk: drop ambiguous LOG_CONT flag
Date: Fri, 28 Sep 2012 16:49:45 +0200	[thread overview]
Message-ID: <5065B909.1060907@cs.tu-berlin.de> (raw)
In-Reply-To: <CAPXgP11SN7cx7NW0Jv46g+KAvFPo61Ptczochzy4Ub83bjHn1Q@mail.gmail.com>

Am 28.09.2012 16:34, schrieb Kay Sievers:
> On Fri, Sep 28, 2012 at 10:25 AM, Jan H. Schönherr
> That fails the racing task test, and a cont user that was nicely
> merged before is now all in separate records.

I guess, I need to extend my test cases. Do you have something
ready that I could use?

> It seems, unconditionally using the cont buffer like in your patch,
> for all incoming messages just makes the entire cont merge buffer
> dance useless when it comes to races.

I see. :(

> The current behaviour has the advantage, that non-cont users will not
> race against a cont user (which is like 99.x% of the races I expect).
> The cont buffer is currently only used when we expect a cont user,
> non-cont users happening in the middle of a cont-print will not flush
> the and disturb the cont buffer.

That should be fixable by using a second set of flags, owner, and so on
within vprintk... I still think, that getting rid of of remotely tracking
the flags is worth something.

(Ideally, we should also be able to correctly reassemble multiple
simultaneous cont users. But that it still a bit out of scope I think.)

Given that I'm able to fix the racing case, would you be in favor of
this approach, or should we stick to the earlier version?

Regards
Jan

  reply	other threads:[~2012-09-28 14:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-26 17:58 [PATCH] printk: drop ambiguous LOG_CONT flag Jan H. Schönherr
2012-09-26 21:15 ` Greg Kroah-Hartman
2012-09-26 22:33   ` "Jan H. Schönherr"
2012-09-27 13:39     ` Kay Sievers
2012-09-27 15:46       ` "Jan H. Schönherr"
2012-09-27 16:04         ` "Jan H. Schönherr"
2012-09-28  8:25           ` Jan H. Schönherr
2012-09-28 14:34             ` Kay Sievers
2012-09-28 14:49               ` "Jan H. Schönherr" [this message]
2012-09-28 14:56                 ` Kay Sievers
2012-10-08 19:24                   ` Kay Sievers
2012-10-08 19:54                     ` "Jan H. Schönherr"
2012-10-08 19:56                       ` Kay Sievers
2012-11-02  3:53                         ` Kay Sievers
2012-11-02 22:37                           ` "Jan H. Schönherr"
2012-11-02 23:36                             ` Greg Kroah-Hartman
2012-11-03 21:12                               ` [PATCH resend] " Jan H. Schönherr
2012-11-10 18:47                                 ` "Jan H. Schönherr"
2012-10-08 23:10                       ` [PATCH] " Joe Perches
2012-09-28  2:28         ` Kay Sievers

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=5065B909.1060907@cs.tu-berlin.de \
    --to=schnhrr@cs.tu-berlin.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    /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