linux-kernel - Re: in kernel 2.6.x, tun/tap nic supports vlan packets

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: <20140424052447.GC17409@1wt.eu>
Date:	Thu, 24 Apr 2014 07:24:47 +0200
From:	Willy Tarreau <w@....eu>
To:	zhuyj <zyjzyj2000@...il.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	joe@...ches.com, julia.lawall@...6.fr, dingtianhong@...wei.com,
	linux-kernel@...r.kernel.org, jasowang@...hat.com, mst@...hat.com,
	"Yang, Zhangle (Eric)" <Zhangle.Yang@...driver.com>,
	"Wu, Kuaikuai" <Kuaikuai.Wu@...driver.com>,
	"Tao, Yue" <Yue.Tao@...driver.com>
Subject: Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On Thu, Apr 24, 2014 at 10:10:08AM +0800, zhuyj wrote:
> On 04/23/2014 07:41 PM, Ben Hutchings wrote:
> >On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote:
> >>On 04/23/2014 01:53 AM, Ben Hutchings wrote:
> >[...]
> >>>For what it's worth, I would recommend against applying this.  I don't
> >>>think even Red Hat has backported the VLAN changes, and they have been
> >>>quite aggressive about backporting features to RHEL 6.
> >>If we do not merge these patches, maybe RHEL 6 can not make tap driver
> >>support vlan well.
> >RHEL 6 isn't based on 2.6.32.y, they do all their own backporting.
> Hi, Ben
> 
> It is well known that extraction vlan tag is not implemented in kernel 
> 2.6.32.y.  Kernel 2.6.32.y depends on nic hardware to extract vlan tag.
> So if the patches are not applied, tap driver can not support vlan well.

What Ben is saying is that RHEL doesn't use 2.6.32.y, but did their own
fork of 2.6.32 so even if we merged your patch, they wouldn't pick it
from this tree anyway. However they could possibly take your patch if
some customers requested the feature even if it's not in 2.6.32.y.

Clearly, the fact that nobody complained about this in 4.5 years of
2.6.32 means that there's no particular reason any user would suddenly
miss it now. 2.6.32.y is mostly used to update existing deployments but
rarely for new deployments. That's why the usefulness of your backport
in this kernel for its users is likely limited, and at the same time
the risk of causing a regression is far from being null for existing
users (eg: if some worked around the issue a different way, their
workaround would likely not work anymore).

Best regards,
Willy

--
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/