linux-kernel - RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at ffff880077800004 (hv_ringbuffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <EE124450C0AAF944A40DD71E61F878C9973DAC@SINEX14MBXC418.southpacific.corp.microsoft.com>
Date:	Thu, 28 Aug 2014 03:21:59 +0000
From:	Dexuan Cui <decui@...rosoft.com>
To:	KY Srinivasan <kys@...rosoft.com>,
	Sitsofe Wheeler <sitsofe@...il.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PANIC, hyperv] BUG: unable to handle kernel paging request at
 ffff880077800004 (hv_ringbuffer_write)

> -----Original Message-----
> From: linux-kernel-owner@...r.kernel.org [mailto:linux-kernel-
> owner@...r.kernel.org] On Behalf Of KY Srinivasan
> Sent: Thursday, August 28, 2014 7:14 AM
> > > > From: Sitsofe Wheeler [mailto:sitsofe@...il.com]
> > > > Sent: Wednesday, August 27, 2014 9:19 AM
> > > >
> > > > > BTW, with the patch below, hyperv_fb can work now, BUT,
> > > > > *occasionally*,
> > > > > storvsc_probe() -> ... -> vmbus_open() -> can fail due to
> > > > > HV_STATUS_INVALID_ALIGNMENT...
> > > >
> > > > I applied your new patch on top of KY's pieces (it applied cleanly)
> > > > and while it doesn't blow up, one warning is printed out and the UP
> > > > boot seemed to stall after input: TPPS/2 message (but pressing
> > > > ctrl-alt-delete allows the system to reboot cleanly).
> > >
> > > First let me thank you guys for looking into this issue. Looking at
> > > your dmesg, it looked like storvsc probe failed as Dexuan had seen.
> > > Since the failure appears to be alignment related, perhaps we could
> > > test with allocating a page all the time (and getting rid of the
> > > kmalloc). Sitsofe, here is a patch based on Dexuan's patch. If this
> > > works, I will probably minimize failure cases by pre-allocating
> > > per-cpu pages for this.:
> >
> > After some modifications to apply on top of your previous patches
> applying
> > this latest patch has cured the issues surrounding hyperv_fb issues on
> boot.

This always-use-page-allocation patch of KY works for me too. :-)


> > The only issue seen on boot now is similar to
> > https://lkml.org/lkml/2014/8/19/227 ...
Hi Sitsofe,
I don't see this issue.
Do you still see the issue for EVERY boot after you applied KY's
always-use-page-allocation patch?
I doubt that because in the log of the above link:

[   34.628072] hv_netvsc vmbus_0_15: net device safe to remove
[   34.676573] hv_netvsc: hv_netvsc channel opened successfully
[   34.860292] hv_netvsc vmbus_0_15 eth1: unable to establish send buffer's gpadl
[   34.948983] hv_netvsc vmbus_0_15 eth1: unable to connect to NetVSP - 4

Here the 4 is just HV_STATUS_INVALID_ALIGNMENT -- it should be fixed
by the patch.

> 
> That is good to hear. I was under the impression that this issue would be
> resolved with all the cleanup we have done. The last patch-set I posted
> earlier today has the fix for vmbus_open  bug that Dexuan had identified.
> 
> If you could try with the BUG_ON elimination patch-set I sent out earlier
> today with the fix in hv.c that I had sent that would be great.
> >
> > How come previous alignment efforts weren't working out?
I'm not sure.
If we trust the hypervisor, I would guess in hv_post_message()
1) We'd better add "aligned_msg->reserved = 0;"
2) Should we make sure  "aligned_msg->payload_size % 8 == 0"? IMO
   aligned_msg->payload is an array of 8-byte.

> I have chosen to always allocate a page and so alignment won't be
> an issue. I want to eliminate failure in this path and so, I will most likely
> do a per-cpu pre-allocation of this buffer.
This is a good idea!

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