[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJK669bqRF6WiQ8=21pEyUB565i80CeN0eniWcPBxXNLCOcxXA@mail.gmail.com>
Date: Fri, 7 Sep 2012 11:24:24 +0200
From: Sjur Brændeland <sjurbren@...il.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Rusty Russell <rusty@...tcorp.com.au>,
Ohad Ben-Cohen <ohad@...ery.com>,
Amit Shah <amit.shah@...hat.com>, linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
virtualization@...ts.linux-foundation.org
Subject: Re: [RFC 1/2] virtio_console: Add support for DMA memory allocation
Hi Michael.
>> Not just fail to work, the kernel will panic on the BUG_ON().
>> Remoteproc gets the virtio configuration from firmware loaded
>> from user space. So this type of problem might be triggered
>> for other virtio drivers as well.
>
> how?
...
>> Even if we fix this particular problem, the general problem
>> still exists: bogus virtio declarations in remoteproc's firmware
>> may cause BUG_ON().
>
> which BUG_ON exactly?
I am afraid I have been barking up the wrong tree here.
Please ignore my previous rambling about panics related
to device features.
I hit the BUG() in virtio_check_driver_offered_feature():
First I did not declare the feature because DMA was not set:
static unsigned int features[] = {
...
#if VIRTIO_CONSOLE_HAS_DMA
VIRTIO_CONSOLE_F_DMA_MEM,
#endif
};
and then in probe I checked if the feature was supported:
virtio_has_feature(vdev, VIRTIO_CONSOLE_F_DMA_MEM)
This triggered the BUG() in virtio_check_driver_offered_feature(),
because the driver was asking for a unknown-feature.
I can get avoid this by simply checking the devices feature bits directly
instead of using virtio_has_feature().
Regards,
Sjur
--
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/
Powered by blists - more mailing lists