On 05/23/18 at 01:59pm, Omar Sandoval wrote: > From: Omar Sandoval <[email protected]> > > 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 <[email protected]> > --- > 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 <[email protected]> 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 > [email protected] > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
