All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jukka Ollila <jiiksteri@gmail.com>
Cc: linux-kernel@vger.kernel.org, kay@vrfy.org, jbeulich@novell.com,
	greg@kroah.com, torvalds@linux-foundation.org
Subject: Regression - /proc/kmsg does not (always) block for 1-byte reads
Date: Fri, 6 Jul 2012 20:38:25 +0100	[thread overview]
Message-ID: <20120706203825.20ce3e47@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <CAGoecWyMKF4gC7FaoBCrBs+rD=u6oJRHS5Q2qVkkwoZZ1_4RCg@mail.gmail.com>

On Fri, 6 Jul 2012 20:45:44 +0300
Jukka Ollila <jiiksteri@gmail.com> wrote:

> Hello,
> 
> A few days ago I filed a kernel regression report concerning a change
> in /proc/kmsg behaviour with short reads:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=44211
> 
> The comments suggest that this is probably intentional, but that it
> would be best make sure that the current semantics wrt short reads are
> as intended.
> 
> The problem appears on a Debian (unstable) system that drains
> /proc/kmsg into a separate fifo read by klogd(8):
> 
> /bin/dd bs=1 if=/proc/kmsg  of=/var/run/klogd/kmsg
> 
> With the recent kernel logging changes this /bin/dd exits immediately,
> as 1-byte reads are shorter than any log message could possibly be and
> read() returns 0. No dd feeding the fifo results in no logging and a
> rather unhappy klogd on the reading end of /var/run/klogd/kmsg.
> 
> I suppose a safe solution is to only do reads that are big enough for
> any single kernel message, but this is still a change that affects
> user space being shipped, so some might find it surprising.
> 
> I don't know what other distros do. Is it just Debian being the odd one out?

If this is observed on an actual standard distro userspace and breaks it
then its a regression and it needs fixing or reverting.

Cc'ing Linus

  parent reply	other threads:[~2012-07-06 19:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06 17:45 Bug 44211 - /proc/kmsg does not (always) block for 1-byte reads Jukka Ollila
2012-07-06 17:55 ` Greg KH
2012-07-06 18:46   ` Jukka Ollila
2012-07-08 12:37   ` Kay Sievers
2012-07-08 12:59     ` Alan Cox
2012-07-08 13:06       ` Kay Sievers
2012-07-06 19:38 ` Alan Cox [this message]
2012-07-06 20:30   ` Regression " Linus Torvalds
2012-07-07 21:19     ` Kay Sievers
2012-07-08  2:09       ` Kay Sievers
2012-08-10 12:56       ` Jan Engelhardt
2012-07-06 22:05   ` Jukka Ollila
2012-07-06 22:09     ` Linus Torvalds
2012-07-08  0:33     ` 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=20120706203825.20ce3e47@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=greg@kroah.com \
    --cc=jbeulich@novell.com \
    --cc=jiiksteri@gmail.com \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 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.