Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 31 Jan 2020 13:44:19 -0800
From:   "Luck, Tony" <tony.luck@intel.com>
To:     Pavel Machek <pavel@denx.de>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Fenghua Yu <fenghua.yu@intel.com>,
        "David S. Miller" <davem@davemloft.net>,
        Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 4.19 36/55] drivers/net/b44: Change to non-atomic bit
 operations on pwol_mask
Message-ID: <20200131214419.GA19569@agluck-desk2.amr.corp.intel.com>
References: <20200130183608.563083888@linuxfoundation.org>
 <20200130183615.120752961@linuxfoundation.org>
 <20200131125730.GA20888@duo.ucw.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200131125730.GA20888@duo.ucw.cz>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jan 31, 2020 at 01:57:31PM +0100, Pavel Machek wrote:
> And I wonder if this is even good idea for mainline. x86 architecture
> is here for long time, and I doubt Intel is going to break it like
> this. Do you have documentation pointer? 

Intel isn't breaking this legacy behaviour. But it is building h/w that
allows s/w to opt-in to a mode that will generate an #AC trap for
a split lock.  One such processor ("Icelake") is already shipping.

Some Linux use cases (real-time) really, really want to avoid the cost
of a split-lock.  There's a patch in TIP that will enable this #AC on
split-lock mode on processors that support it.

Thus it's a good idea to clean up any places in the kernel that will
cause #AC when that mode is enabled. I think mainline should be
taking any patches for split lock cleanup.

Stable is a different question.  The patch to enable the #AC should
not be backported to stable. So the only way an old kernel would hit
this would be if the BIOS enabled the #AC. Really that should only
happen on a system where the developers have validated that the
entire software stack has been checked for split locks.

Is net/b44 a device that is still being included on current systems?
Or is it a legacy device that has been superceeded by something else?
If there isn't going to be a b44 on an Icelake or newer system, then
perhaps we should not worry so much about fixing the driver.

-Tony