netdev - Re: [PATCH 3.4] xen-netback: allow changing the MAC address of the interface

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:	Fri, 6 Jun 2014 22:02:47 +0200
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	David Miller <davem@...emloft.net>, stable@...r.kernel.org,
	msw@...zon.com, netdev@...r.kernel.org, xen-devel@...ts.xen.org,
	konrad.wilk@...cle.com
Subject: Re: [PATCH 3.4] xen-netback: allow changing the MAC address of the
 interface

On Fri, Jun 06, 2014 at 06:56:23AM -0700, Greg KH wrote:
> On Fri, Jun 06, 2014 at 03:04:17PM +0200, Daniel Kiper wrote:
> > On Thu, Jun 05, 2014 at 04:14:58PM -0700, Greg KH wrote:
> > > On Thu, Jun 05, 2014 at 02:58:44PM -0700, David Miller wrote:
> > > > From: Daniel Kiper <daniel.kiper@...cle.com>
> > > > Date: Mon,  2 Jun 2014 21:46:20 +0200
> > > >
> > > > > From: Matt Wilson <msw@...zon.com>
> > > > >
> > > > > Sometimes it is useful to be able to change the MAC address of the
> > > > > interface for netback devices. For example, when using ebtables it may
> > > > > be useful to be able to distinguish traffic from different interfaces
> > > > > without depending on the interface name.
> > > > >
> > > > > Reported-by: Nikita Borzykh <sample.n@...il.com>
> > > > > Reported-by: Paul Harvey <stockingpaul@...mail.com>
> > > > > Cc: netdev@...r.kernel.org
> > > > > Cc: xen-devel@...ts.xen.org
> > > > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > > > > Acked-by: Ian Campbell <ian.campbell@...rix.com>
> > > > > Signed-off-by: Matt Wilson <msw@...zon.com>
> > > > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > > > > Signed-off-by: David S. Miller <davem@...emloft.net>
> > > > > (cherry picked from commit 4a633a602c26497b8285a202830829d3be007c7b)
> > > > >
> > > > > Signed-off-by: Daniel Kiper <daniel.kiper@...cle.com>
> > > > > Tested-by: Daniel Kiper <daniel.kiper@...cle.com>
> > > > > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> > > >
> > > > I don't think this is suitable for -stable.
> > > >
> > > > -stable should be restricted bug fixes for things that either
> > > > are extremely serious, or hit a very huge segment of the user
> > > > base.
> > > >
> > > > This issue does not quality for either condition.
> > >
> > > Yeah, it seems like a new feature to me, I'll drop it from my to-apply
> > > queue.
> >
> > Yes, in fact it is, however, without it toolstack pollute /var/log/xen/xen-hotplug.log
> > with "RTNETLINK answers: Operation not supported" error when every domain is started.
> > Additionally, it is simple two liner and it should not break anything (Konrad and
> > I did some tests and everything looks OK). I do not mention that from time to time
> > we add some features like support for new hardware with just new device ID (e.g.
> > USB devices). So that is why I decided to post this patch to stable.
>
> New device ids and quirks to existing drivers are valid stable patches
> (see Documentation/stable_kernel_rules.txt), but new features usually
> are not.

There is something like that:
 - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
   security issue, or some "oh, that's not good" issue.  In short,
   something critical.

I think that this is "oh, that's not good" issue type. Of course it
is not so critical but a bit annoying. Hence, could we have it in 3.4
or "NO" is your the last word in that case?

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