netdev - Re: [PATCH net-next 0/1] netvsc: another VF datapath fix

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] [day] [month] [year] [list]

Date:   Wed, 9 Aug 2017 07:41:43 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     devel@...uxdriverproject.org, haiyangz@...rosoft.com,
        sthemmin@...rosoft.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/1] netvsc: another VF datapath fix

On Wed, 09 Aug 2017 11:03:05 +0200
Vitaly Kuznetsov <vkuznets@...hat.com> wrote:

> Stephen Hemminger <stephen@...workplumber.org> writes:
> 
> > The following would allow udev a chance at the device.
> >  
> 
> This would of course work but the approach is a bit hackish and can
> still fail on a loaded system. Raising the pause interval would be an
> option, but again, probably not the best one.
> 
> Let me try to send an RFC removing the check it dev_change_name() and if
> it turns out that it can't be removed we can go back to your patch. But
> in case it can we can leave without it.
> 
> Thanks,

I don't want to require change of semantics of core networking code
for one driver. Changing name of up device has been blocked for so
long that allowing it might break existing userspace apps. It might
be ok in the future, but netvsc needs to work without that change.