<div dir="ltr"><div>I have posted a question earlier and I have confirmed that this is running in an infinite loop. However, I discovered that the infinite loop is happening inside kernel code. Specifically inside the kmalloc function. I know this is highly improbable, but I believe that this is the case. <br>
<br></div><div>The line of code that cause the infinite loop is in bold below and starts with buf =<br><br></div><div>If I comment this line out then it does not hang. If I uncomment it then it does. Further, more no print statements after that line are being printed and I have it surrounded by print statements.<br>
</div><div><br>KMALLOC is a macro defined as<br># define KMALLOC(a,b) kmalloc((a),(b))<br><br></div><div>The last line being printed:<br>b0b0b0 4096<br></div><div>4096 being the size of buffer. <br><br>
</div><div><br></div><div>The get_buffer method is called quite a few times before the last time where it goes into an infinite loop. I am thinking there could be a memory leak or if memory is low this can happen? <br><br>
</div><div>An advice on how to tackle this issue would be greatly appreciated. <br><br></div><div>Thanks.<br><br></div><div><br><br>static inline struct buffer *get_buffer(void)<br>{<br> /* XXX: __get_free_page should be used. KMALLOC is for small stuff < PAGE_SIZE */<br>
struct buffer *buf;<br> printk(KERN_EMERG " b0b0b0 %d\n", sizeof(struct buffer));<br>
<b> buf = KMALLOC(sizeof(struct buffer), GFP_KERNEL);</b><br> print_entry_location();<br> printk(KERN_EMERG " b1b1b1\n");<br> //if (buf) //i commented these out<br> //buf->ptr = buf->data + INIT_LOC; //i commented these out<br>
printk(KERN_EMERG " b1b1b1\n");<br>
print_exit_location();<br> return NULL; //i changed it to return null so the next function just exits<br>}<br><br><br><br></div><div>Additional info<br>struct buffer {<br> char *ptr;<br> char data[DATA_SIZE];<br>
};<br>#define DATA_SIZE (PAGE_SIZE - sizeof(int))<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 2:23 PM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 25 Jul 2013 13:56:47 -0400, Salam Farhat said:<br>
<br>
> When the guest OS freezes I get the following messages seen below. I would<br>
> like to know what is a good approach for debugging this issue. I am not<br>
> sure what a process stall is. Is that a deadlock?<br>
><br>
><br>
> [ 780.357876] BUG: soft lockup - CPU#0 stuck for 22s! [nautilus:1382]<br>
> [ 780.361658] Process nautilus (pid: 1382, ti=dca12000 task=dc837230 task.ti=d)<br>
> [ 780.361658]<br>
> Stack:<br>
> [ 780.361658] Call Trace:<br>
> [ 780.361658] Code: 90 b8 43 64 03 c1 b9 40 64 03 c1 e9 49 ff ff ff 90 55 ba 0<br>
> [ 808.356372] BUG: soft lockup - CPU#0 stuck for 22s!<br>
<br>
</div>That's probably not a deadlock. That's code stuck in an infinite loop,<br>
probably while running in a non-interruptible state.<br>
<br>
Too bad we didn't get a stack dump out of it, that would tell us what<br>
code is hung in a loop.<br>
<br>
For debugging deadlocks, turning on CONFIG_PROVE_LOCKING=y in the .config<br>
is the best bet - that will fire an alert not only when the kernel *does*<br>
lock up, but also if there's even a *possible* deadlock (for instance, if one<br>
section takes 2 locks in the order A B, it will trigger if it ever spots<br>
another chunk of code taking B and then A - even if that doesn't actually<br>
trigger a deadlock because neither lock is held at the time).<br>
<br>
<br>
</blockquote></div><br></div>