[PATCH] md: Fix single printks with multiple KERN_<level>s

Noticed-by: Russell King
Signed-off-by: Joe Perches
---
> Note that KERN_foo in the middle of strings, even after a newline are
> preserved in the output. So:
>
> printk(KERN_WARNING "BUG: Your driver calls ioremap() on system memory. This leads\n"
> KERN_WARNING "to architecturally unpredictable behaviour on ARMv6+, and ioremap()\n"
> KERN_WARNING "will fail in the next kernel release. Please fix your driver.\n");
>
> results in <4>'s appearing on the console. I've always written code
> over the last 15 years assuming that after any newline in printk output,
> the log level gets reset and so needs a new log level specifier.
>
> Sounds like this is something which needs auditing as a result of your
> change, and sounds like its something that kernelnewbies people could
> do. My own greps haven't revealed any cases though.

drivers/md/raid1.c | 5 +++--
drivers/md/raid10.c | 5 +++--
drivers/md/raid5.c | 1 -
3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 45f8324..e05381b 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1027,8 +1027,9 @@ static void error(mddev_t *mddev, mdk_rdev_t *rdev)
} else
set_bit(Faulty, &rdev->flags);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
- printk(KERN_ALERT "md/raid1:%s: Disk failure on %s, disabling device.\n"
- KERN_ALERT "md/raid1:%s: Operation continuing on %d devices.\n",
+ printk(KERN_ALERT
+ "md/raid1:%s: Disk failure on %s, disabling device.\n"
+ "md/raid1:%s: Operation continuing on %d devices.\n",
mdname(mddev), bdevname(rdev->bdev, b),
mdname(mddev), conf->raid_disks - mddev->degraded);
}
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index c67aa54..686543d 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1051,8 +1051,9 @@ static void error(mddev_t *mddev, mdk_rdev_t *rdev)
}
set_bit(Faulty, &rdev->flags);
set_bit(MD_CHANGE_DEVS, &mddev->flags);
- printk(KERN_ALERT "md/raid10:%s: Disk failure on %s, disabling device.\n"
- KERN_ALERT "md/raid10:%s: Operation continuing on %d devices.\n",
+ printk(KERN_ALERT
+ "md/raid10:%s: Disk failure on %s, disabling device.\n"
+ "md/raid10:%s: Operation continuing on %d devices.\n",
mdname(mddev), bdevname(rdev->bdev, b),
mdname(mddev), conf->raid_disks - mddev->degraded);
}
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index dc574f3..316fbe7 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1721,7 +1721,6 @@ static void error(mddev_t *mddev, mdk_rdev_t *rdev)
set_bit(Faulty, &rdev->flags);
printk(KERN_ALERT
"md/raid:%s: Disk failure on %s, disabling device.\n"
- KERN_ALERT
"md/raid:%s: Operation continuing on %d devices.\n",
mdname(mddev),
bdevname(rdev->bdev, b),

Re: [PATCH] md: Fix single printks with multiple KERN_<level>s

On Tue, 23 Nov 2010 16:57:40 -0800
Joe Perches wrote:

> Noticed-by: Russell King
> Signed-off-by: Joe Perches

Applied by: NeilBrown

Thanks a lot!

NeilBrown


> ---
> > Note that KERN_foo in the middle of strings, even after a newline are
> > preserved in the output. So:
> >
> > printk(KERN_WARNING "BUG: Your driver calls ioremap() on system memory. This leads\n"
> > KERN_WARNING "to architecturally unpredictable behaviour on ARMv6+, and ioremap()\n"
> > KERN_WARNING "will fail in the next kernel release. Please fix your driver.\n");
> >
> > results in <4>'s appearing on the console. I've always written code
> > over the last 15 years assuming that after any newline in printk output,
> > the log level gets reset and so needs a new log level specifier.
> >
> > Sounds like this is something which needs auditing as a result of your
> > change, and sounds like its something that kernelnewbies people could
> > do. My own greps haven't revealed any cases though.
>
> drivers/md/raid1.c | 5 +++--
> drivers/md/raid10.c | 5 +++--
> drivers/md/raid5.c | 1 -
> 3 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 45f8324..e05381b 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -1027,8 +1027,9 @@ static void error(mddev_t *mddev, mdk_rdev_t *rdev)
> } else
> set_bit(Faulty, &rdev->flags);
> set_bit(MD_CHANGE_DEVS, &mddev->flags);
> - printk(KERN_ALERT "md/raid1:%s: Disk failure on %s, disabling device.\n"
> - KERN_ALERT "md/raid1:%s: Operation continuing on %d devices.\n",
> + printk(KERN_ALERT
> + "md/raid1:%s: Disk failure on %s, disabling device.\n"
> + "md/raid1:%s: Operation continuing on %d devices.\n",
> mdname(mddev), bdevname(rdev->bdev, b),
> mdname(mddev), conf->raid_disks - mddev->degraded);
> }
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index c67aa54..686543d 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -1051,8 +1051,9 @@ static void error(mddev_t *mddev, mdk_rdev_t *rdev)
> }
> set_bit(Faulty, &rdev->flags);
> set_bit(MD_CHANGE_DEVS, &mddev->flags);
> - printk(KERN_ALERT "md/raid10:%s: Disk failure on %s, disabling device.\n"
> - KERN_ALERT "md/raid10:%s: Operation continuing on %d devices.\n",
> + printk(KERN_ALERT
> + "md/raid10:%s: Disk failure on %s, disabling device.\n"
> + "md/raid10:%s: Operation continuing on %d devices.\n",
> mdname(mddev), bdevname(rdev->bdev, b),
> mdname(mddev), conf->raid_disks - mddev->degraded);
> }
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index dc574f3..316fbe7 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -1721,7 +1721,6 @@ static void error(mddev_t *mddev, mdk_rdev_t *rdev)
> set_bit(Faulty, &rdev->flags);
> printk(KERN_ALERT
> "md/raid:%s: Disk failure on %s, disabling device.\n"
> - KERN_ALERT
> "md/raid:%s: Operation continuing on %d devices.\n",
> mdname(mddev),
> bdevname(rdev->bdev, b),
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html