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: <1295ed070903140433h14a7070es27885b254af0a90e@mail.gmail.com>
Date:	Sat, 14 Mar 2009 13:33:02 +0200
From:	Pantelis Koukousoulas <pktoss@...il.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	David Miller <davem@...emloft.net>, dcbw@...hat.com,
	netdev@...r.kernel.org, markmc@...hat.com
Subject: Re: [PATCH] Make virtio_net support carrier detection

On Sat, Mar 14, 2009 at 12:40 PM, Pantelis Koukousoulas
<pktoss@...il.com> wrote:
>> I don't think it was straightforward at all.  Current virtio_net "cards"
>> don't support carrier detection.  We reported that (correctly) to userspace,
>> like every other driver which doesn't support carrier detect.
>>
>> So why is virtio_net different?  Or should all devices which can't detect
>> carrier set it to on, so older NetworkManagers work?
>>
>
[snip]
>
> So, I still propose my version for 2.6.29 / -stable and then mark's
> commit applies
> on top of that just fine (just don't delete the netif_carrier_on)  and
> adds the feature
> of the user being able to set the status to on / off explicitly if
> they have a new version
> of qemu / virtio while still doing the "right thing" for current versions.
>
> Therefore, I guess I should resend my patch to netdev with reworked comments
> to reflect this discussion. Hope that is ok with you too.
>
> Pantelis

Or, we can merge the extra netif_carrier_on (what your patch did) to
mark's commit
and just add that full thing to 2.6.29 (as 2 patches probably because
of git, but
one next to the other please for bisection / readability reasons).

I just tested this solution with a self-made livecd, it applies
cleanly and works fine :)
(it might be ~42 lines instead of 2 but it is still trivial enough to
be confident that
nothing will break).

This way we get the expected result for every combination of current and future
versions of qemu / kernel without ever having one "lie" to the other or innocent
users becoming frustrated.

Again:
 (1) My version: smallest, only takes into account current "hardware",
might lead
   to a surprise for someone that uses a future qemu with 2.6.29, does
set_link off
   and expects to see "operation not supported" in ethtool instead of
"Link detected: yes".

 (2) Mark's commit: proper implementation (does both the hardware and
driver part),
       but will only work right for future qemu versions.

 (3) The 2 merged: work for all combinations of current and future
kernel / qemu.
   42 lines instead of 2 but just as unlikely to cause breakage.


I 'd be happy with either (3) in 2.6.29, or (1) in 2.6.29 and (2) in 2.6.30.

Just please don't select to "do nothing". That would be wrong :)

Pantelis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ