Re: port-xen/47057: Xen NetBSD DomU file system trash under Linux Dom0

[Roger Pau Monné <roger.pau%citrix.com@localhost>]

On 20/10/12 17:57, Manuel Bouyer wrote:
> On Sat, Oct 20, 2012 at 05:48:08PM +0200, Roger Pau Monné wrote:
>>>
>>>> Will compile a new kernel with -g and let's see
>>>> what I can get, but I bet xenbus_thread is blocked at:
>>>>
>>>> 831: printk("XENBUS error %d while reading message\n", err);
>>>>
>>>> In fact I'm going to replace that with a panic.
>>>
>>> Maybe just a printf instead of a printk at first.
>>
>> Tried that in the past (replacing the printk with a printf), and then I
>> just get in an infite printf loop, intf->rsp_cons and intf->rsp_prod are
>> corrupted, check_indexes in xb_read always returns false and this leads
>> to a infinite loop in xenbus_thread because process_msg always return error.
>>
>> I've now compiled a kernel that has the panic and prints the ring
>> indexes. What's the best way to check who modifies intf->rsp_cons and
>> intf->rsp_prod? Will ddb watch work on this kind of memory region?
> 
> You can try, but at first glance I'd say it won't work. 
> 
> Can you determine if it's cons or prod (or both) which is corrupted,
> and in which way ? What are the values when it's corrupted ?
> Are they always the same ?

This is a trim of what I think is relevant, the first lines correspond
to the last known values of prod and cons before the corruption, and the
rest is quite self explanatory:

xenbus_xs (process_msg:763) xb_read hdr 0.
xb_read: cons: 3470 prod: 3473
Finished read of 3 bytes (0 to go)
xenbus_xs (process_msg:776) xb_read body 0.
xenbus_xs (process_msg:811) process_msg: type 7 body OK.
xenbus_xs (read_reply:134) read_reply: type 7 body OK.
xenbus_xs (xs_talkv:224) read done.

[…]

xb_read: cons: 2403996137 prod: 3531897424
xb_read EIO
xenbus_xs (process_msg:763) xb_read hdr 5.
panic: XENBUS error 5 while reading message

cpu0: Begin traceback...
printf_nolog() at netbsd:printf_nolog
xenbus_thread() at netbsd:xenbus_thread+0x140