All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] vmcore-dmesg: fix infinite loop if log buffer wraps around
@ 2018-05-23 20:59 Omar Sandoval
  2018-05-24  2:07 ` Baoquan He
  0 siblings, 1 reply; 3+ messages in thread
From: Omar Sandoval @ 2018-05-23 20:59 UTC (permalink / raw)
  To: kexec, Simon Horman; +Cc: kernel-team

From: Omar Sandoval <osandov@fb.com>

We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
were redirecting the output to a file, it wouldn't stop until it filled
up the disk. This only happened when the dmesg buffer had filled up and
wrapped around. It turns out that when we hit the end of the buffer, we
are looping back to the first record instead of the beginning of the
buffer, which will always loop forever.

Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf")
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
 vmcore-dmesg/vmcore-dmesg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c
index e340ef4..7972788 100644
--- a/vmcore-dmesg/vmcore-dmesg.c
+++ b/vmcore-dmesg/vmcore-dmesg.c
@@ -689,7 +689,7 @@ static void dump_dmesg_structured(int fd)
 		 */
 		loglen = struct_val_u16(buf, log_offset_len);
 		if (!loglen)
-			current_idx = log_first_idx;
+			current_idx = 0;
 		else
 			/* Move to next record */
 			current_idx += loglen;
-- 
2.9.5


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] vmcore-dmesg: fix infinite loop if log buffer wraps around
  2018-05-23 20:59 [PATCH] vmcore-dmesg: fix infinite loop if log buffer wraps around Omar Sandoval
@ 2018-05-24  2:07 ` Baoquan He
  2018-05-25  9:57   ` Simon Horman
  0 siblings, 1 reply; 3+ messages in thread
From: Baoquan He @ 2018-05-24  2:07 UTC (permalink / raw)
  To: Omar Sandoval; +Cc: kernel-team, Simon Horman, kexec

On 05/23/18 at 01:59pm, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
> 
> We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
> were redirecting the output to a file, it wouldn't stop until it filled
> up the disk. This only happened when the dmesg buffer had filled up and
> wrapped around. It turns out that when we hit the end of the buffer, we
> are looping back to the first record instead of the beginning of the
> buffer, which will always loop forever.
> 
> Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf")
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
>  vmcore-dmesg/vmcore-dmesg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c
> index e340ef4..7972788 100644
> --- a/vmcore-dmesg/vmcore-dmesg.c
> +++ b/vmcore-dmesg/vmcore-dmesg.c
> @@ -689,7 +689,7 @@ static void dump_dmesg_structured(int fd)
>  		 */
>  		loglen = struct_val_u16(buf, log_offset_len);
>  		if (!loglen)
> -			current_idx = log_first_idx;
> +			current_idx = 0;

Looks like a good fix, ack it.

Acked-by: Baoquan He <bhe@redhat.com>

Strange it isn't found until now, the case which log_next_idx is before
log_first_idx sholdn't be seen rarely.


Thanks
Baoquan


>  		else
>  			/* Move to next record */
>  			current_idx += loglen;
> -- 
> 2.9.5
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] vmcore-dmesg: fix infinite loop if log buffer wraps around
  2018-05-24  2:07 ` Baoquan He
@ 2018-05-25  9:57   ` Simon Horman
  0 siblings, 0 replies; 3+ messages in thread
From: Simon Horman @ 2018-05-25  9:57 UTC (permalink / raw)
  To: Baoquan He; +Cc: Omar Sandoval, kexec, kernel-team

On Thu, May 24, 2018 at 10:07:17AM +0800, Baoquan He wrote:
> On 05/23/18 at 01:59pm, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@fb.com>
> > 
> > We hit a bug where vmcore-dmesg would get stuck in a loop, and since we
> > were redirecting the output to a file, it wouldn't stop until it filled
> > up the disk. This only happened when the dmesg buffer had filled up and
> > wrapped around. It turns out that when we hit the end of the buffer, we
> > are looping back to the first record instead of the beginning of the
> > buffer, which will always loop forever.
> > 
> > Fixes: e08d26b3b7f1 ("vmcore-dmesg: avoid allocating large memory chunk for log buf")
> > Signed-off-by: Omar Sandoval <osandov@fb.com>
> > ---
> >  vmcore-dmesg/vmcore-dmesg.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c
> > index e340ef4..7972788 100644
> > --- a/vmcore-dmesg/vmcore-dmesg.c
> > +++ b/vmcore-dmesg/vmcore-dmesg.c
> > @@ -689,7 +689,7 @@ static void dump_dmesg_structured(int fd)
> >  		 */
> >  		loglen = struct_val_u16(buf, log_offset_len);
> >  		if (!loglen)
> > -			current_idx = log_first_idx;
> > +			current_idx = 0;
> 
> Looks like a good fix, ack it.
> 
> Acked-by: Baoquan He <bhe@redhat.com>
> 
> Strange it isn't found until now, the case which log_next_idx is before
> log_first_idx sholdn't be seen rarely.

Thanks, applied.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-05-25  9:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-23 20:59 [PATCH] vmcore-dmesg: fix infinite loop if log buffer wraps around Omar Sandoval
2018-05-24  2:07 ` Baoquan He
2018-05-25  9:57   ` Simon Horman

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.