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: <fd356a5b3bba495ca84744c8b96a345a@BY2PR0301MB0711.namprd03.prod.outlook.com>
Date:	Thu, 28 Aug 2014 03:41:41 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Dexuan Cui <decui@...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: Dexuan Cui
> Sent: Wednesday, August 27, 2014 8:22 PM
> To: KY Srinivasan; Sitsofe Wheeler
> Cc: Greg Kroah-Hartman; Haiyang Zhang; devel@...uxdriverproject.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!

Thank you all. I will submit a patch with the pre-allocated per-cpu page for this.

K. Y
> 
> 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/