add changelog

3 files changed, 59 insertions, 2 deletions

diff --git a/kmsg-escape.patch b/kmsg-escape.patch
index 15867fa..7a01496 100644
--- a/kmsg-escape.patch
+++ b/kmsg-escape.patch
@@ -1,3 +1,15 @@
+From: Kay Sievers <kay@vrfy.org>
+Subject: kmsg: escape the backslash character while exporting data
+
+Non-printable characters in the log data are hex-escaped to ensure safe
+post processing. We need to escape a backslash we find in the data, to be
+able to distinguish it from a backslash we add for the escaping.
+
+Also escape the non-printable character 127.
+
+Thanks to Miloslav Trmac for the heads up.
+
+Signed-off-by: Kay Sievers <kay@vrfy.org>
 ---
  kernel/printk.c |    4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
@@ -9,7 +21,7 @@
  		unsigned char c = log_text(msg)[i];
  
 -		if (c < ' ' || c >= 128)
-+		if (c < ' ' || c >= 128 || c == '\\')
++		if (c < ' ' || c >= 127 || c == '\\')
  			len += sprintf(user->buf + len, "\\x%02x", c);
  		else
  			user->buf[len++] = c;
@@ -18,7 +30,7 @@
  			}
  
 -			if (c < ' ' || c >= 128) {
-+			if (c < ' ' || c >= 128 || c == '\\') {
++			if (c < ' ' || c >= 127 || c == '\\') {
  				len += sprintf(user->buf + len, "\\x%02x", c);
  				continue;
  			}
diff --git a/kmsg-facility-len.patch b/kmsg-facility-len.patch
index ed9d8fc..70fd915 100644
--- a/kmsg-facility-len.patch
+++ b/kmsg-facility-len.patch
@@ -1,3 +1,19 @@
+From: Kay Sievers <kay@vrfy.org>
+Subject: kmsg: add the facility number to the syslog prefix
+
+After the recent split of facility and level into separate variables,
+we miss the facility value (always 0 for kernel-originated messages)
+in the syslog prefix.
+
+On Tue, Jul 3, 2012 at 12:45 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
+> Static checkers complain about the impossible condition here.
+>
+> In 084681d14e ('printk: flush continuation lines immediately to
+> console'), we changed msg->level from being a u16 to being an unsigned
+> 3 bit bitfield.
+
+Cc: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Kay Sievers <kay@vrfy.org>
 ---
  kernel/printk.c |    7 ++++---
  1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kmsg-nonblock-race.patch b/kmsg-nonblock-race.patch
index f7b7088..6e766f2 100644
--- a/kmsg-nonblock-race.patch
+++ b/kmsg-nonblock-race.patch
@@ -1,3 +1,32 @@
+From: Kay Sievers <kay@vrfy.org>
+Subject: kmsg: properly handle concurrent non-blocking read() from /proc/kmsg
+
+The /proc/kmsg read() interface is internally simply wired up to a sequence
+of syslog() syscalls, which might are racy between their checks and actions,
+regarding concurrency.
+
+In the (very uncommon) case of concurrent readers of /dev/kmsg, relying on
+usual O_NONBLOCK behavior, the recently introduced mutex might block an
+O_NONBLOCK reader in read(), when poll() returns for it, but another process
+has already read the data in the meantime. We've seen that while running
+artificial test setups and tools that "fight" about /proc/kmsg data.
+
+This restores the original /proc/kmsg behavior, where in case of concurrent
+read()s, poll() might wake up but the read() syscall will just return 0 to
+the caller, while another process has "stolen" the data.
+
+This is in the general case not the expected behavior, but it is the exact
+same one, that can easily be triggered with a 3.4 kernel, and some tools
+might just rely on it.
+
+The mutex is not needed, the original integrity issue which introduced it,
+is in the meantime covered by:
+  "fill buffer with more than a single message for SYSLOG_ACTION_READ"
+  116e90b23f74d303e8d607c7a7d54f60f14ab9f2
+
+Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>
+Cc: Jan Beulich <JBeulich@suse.com>
+Signed-off-by: Kay Sievers <kay@vrfy.org>
 ---
  kernel/printk.c |    9 +--------
  1 file changed, 1 insertion(+), 8 deletions(-)