Re: [PATCH] printk: use mutex lock to stop syslog_seq from going wild

[Kay Sievers]

On Sat, Jun 16, 2012 at 3:21 PM, Yuanhan Liu
<yuanhan.liu@xxxxxxxxxxxxxxx> wrote:
> Although syslog_seq and log_next_seq stuff are protected by logbuf_lock
> spin log, it's not enough. Say we have two processes A and B, and let
> syslog_seq = N, while log_next_seq = N + 1, and the two processes both
> come to syslog_print at almost the same time. And No matter which
> process get the spin lock first, it will increase syslog_seq by one,
> then release spin lock; thus later, another process increase syslog_seq
> by one again. In this case, syslog_seq is bigger than syslog_next_seq.
> And latter, it would make:
> Â wait_event_interruptiable(log_wait, syslog != log_next_seq)
> don't wait any more even there is no new write comes. Thus it introduce
> a infinite loop reading.
>
> I can easily see this kind of issue by the following steps:
> Â# cat /proc/kmsg # at meantime, I don't kill rsyslog
> Â Â Â Â Â Â Â Â Â # So they are the two processes.
> Â# xinit     Â# I added drm.debug=6 in the kernel parameter line,
> Â Â Â Â Â Â Â Â Â # so that it will produce lots of message and let that
> Â Â Â Â Â Â Â Â Â # issue happen
>
> It's 100% reproducable on my side. And my disk will be filled up by
> /var/log/messages in a quite short time.
>
> So, introduce a mutex_lock to stop syslog_seq from going wild just like
> what devkmsg_read() does. It does fix this issue as expected.
>
> v2: use mutex_lock_interruptiable() instead (comments from Kay)
>
> Cc: Kay Sievers <kay@xxxxxxxx>
> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@xxxxxxxxxxxxxxx>

Acked-By: Kay Sievers <kay@xxxxxxxx>

Thanks again for finding and fixing it.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/