netdev - Re: [net PATCH v4 5/6] virtio: add pci_down/pci

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]

Date:   Sun, 15 Jan 2017 20:04:30 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Jason Wang <jasowang@...hat.com>, mst@...hat.com
Cc:     john.r.fastabend@...el.com, netdev@...r.kernel.org,
        alexei.starovoitov@...il.com, daniel@...earbox.net
Subject: Re: [net PATCH v4 5/6] virtio: add pci_down/pci_up configuration

On 17-01-15 07:57 PM, Jason Wang wrote:
> 
> 
> On 2017年01月16日 08:01, John Fastabend wrote:
>> In virtio_net we need to do a full reset of the device to support
>> queue reconfiguration and also we can trigger this via ethtool
>> commands. So instead of open coding this in net driver push this
>> into generic code in virtio. This also avoid exporting a handful
>> of internal virtio routines.
> 
> Looks like this is not a pci specific stuffs. And there's some driver left (e.g
> scsi and block).
> 
> In fact, I'm not sure touching other drivers is really needed. Maybe we can just:
> - move virtio_device_freeze(), virtio_device_restore() and .freeze/.restore in
> virtio_driver out of CONFIG_PM_SLEEP
> - move virtnet_freeze() and virtnet_restore() out of CONFIG_PM_SLEEP
> - introduce virtio_net_reset() and call
> virtio_device_freeze()/virtio_device_restore() there
> 

Michael, what do you think? I was following your suggestion on writing a
generic virtio reset here. I don't have a preference either way.

> Another possible issue for sleep/hibernation is xdp_prog were not restored, if
> this is not XDP intended, we'd better fix this.

Yep this bug exists even without this series. I'll add it to my list of things
to fix. Along with small packet max_mtu.

> 
> Thanks
> 
> [...]