[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJK669bhVfgnxuF6wVtdnzs2bgiJ2HzgwfWw4uZ=EqTdm43Jow@mail.gmail.com>
Date: Wed, 5 Sep 2012 20:15:36 +0200
From: Sjur Brændeland <sjurbren@...il.com>
To: "Michael S. Tsirkin" <mst@...hat.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Ohad Ben-Cohen <ohad@...ery.com>
Cc: Amit Shah <amit.shah@...hat.com>, linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
virtualization@...ts.linux-foundation.org,
Sjur Brændeland <sjur.brandeland@...ricsson.com>
Subject: Re: [RFC 1/2] virtio_console: Add support for DMA memory allocation
Hi Michael.
>> If the device then asks for VIRTIO_CONSOLE_F_DMA_MEM
>> when DMA is not supported, virtio will do BUG_ON() from
>> virtio_check_driver_offered_feature().
>>
>> Is this acceptable or should we add a check in virtcons_probe()
>> and let the probing fail instead?
>>
>> E.g:
>> /* Refuse to bind if F_DMA_MEM request cannot be met */
>> if (!VIRTIO_CONSOLE_HAS_DMA &&
>> (vdev->config->get_features(vdev) & (1 << VIRTIO_CONSOLE_F_DMA_MEM))){
>> dev_err(&vdev->dev,
>> "DMA_MEM requested, but arch does not support DMA\n");
>> err = -EINVAL;
>> goto fail;
>> }
>>
>> Regards,
>> Sjur
>
> Failing probe would be cleaner. But there is still a problem:
> old driver will happily bind to that device and then
> fail to work, right?
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.
> virtio pci has revision id for this, but remoteproc doesn't
> seem to have anything similar. Or did I miss it?
No there are currently no sanity check of
virtio type and feature bits in remoteproc.
One option may be to add this...
> If not -
> we probably need to use a different
> device id, and not a feature bit.
But if I create a new virtio console type, remoteproc
could still call the existing virtio_console with random
bad feature bits, causing kernel panic.
Even if we fix this particular problem, the general problem
still exists: bogus virtio declarations in remoteproc's firmware
may cause BUG_ON(). (Note the fundamental difference
between visualizations and remoteproc. For remoteproc
the virtio configuration comes from binaries loaded from
user space).
So maybe we should look for a more generic solution, e.g.
changing virtio probe functionality so that devices with
bad feature bits will not trigger BUG_ON(), but rather refuse
to bind the driver.
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