On Tue, Mar 16, 2021 at 09:54:01AM -0400, Sasha Levin wrote:
On Tue, Mar 16, 2021 at 06:46:10AM +0100, gregkh@linuxfoundation.org wrote:
On Mon, Mar 15, 2021 at 07:56:02PM +0000, Vladimir Oltean wrote:
+Andrew, Vivien,
On Mon, Mar 15, 2021 at 02:53:26PM +0100, gregkh@linuxfoundation.org wrote:
From: Greg Kroah-Hartman gregkh@linuxfoundation.org
From: Vladimir Oltean vladimir.oltean@nxp.com
[ Upstream commit a3b0b6479700a5b0af2c631cb2ec0fb7a0d978f2 ]
At the moment, taggers are left with the task of ensuring that the skb headers are writable (which they aren't, if the frames were cloned for TX timestamping, for flooding by the bridge, etc), and that there is enough space in the skb data area for the DSA tag to be pushed.
Moreover, the life of tail taggers is even harder, because they need to ensure that short frames have enough padding, a problem that normal taggers don't have.
The principle of the DSA framework is that everything except for the most intimate hardware specifics (like in this case, the actual packing of the DSA tag bits) should be done inside the core, to avoid having code paths that are very rarely tested.
So provide a TX reallocation procedure that should cover the known needs of DSA today.
Note that this patch also gives the network stack a good hint about the headroom/tailroom it's going to need. Up till now it wasn't doing that. So the reallocation procedure should really be there only for the exceptional cases, and for cloned packets which need to be unshared.
Signed-off-by: Vladimir Oltean vladimir.oltean@nxp.com Tested-by: Christian Eggers ceggers@arri.de # For tail taggers only Tested-by: Kurt Kanzenbach kurt@linutronix.de Reviewed-by: Florian Fainelli f.fainelli@gmail.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org
For context, Sasha explains here: https://www.spinics.net/lists/stable-commits/msg190151.html (the conversation is somewhat truncated, unfortunately, because stable-commits@vger.kernel.org ate my replies) that 13 patches were backported to get the unrelated commit 9200f515c41f ("net: dsa: tag_mtk: fix 802.1ad VLAN egress") to apply cleanly with git-am.
I am not strictly against this, even though I would have liked to know that the maintainers were explicitly informed about it.
Greg, could you make your stable backporting emails include the output of ./get_maintainer.pl into the list of recipients? Thanks.
I cc: everyone on the signed-off-by list on the patch, why would we need to add more? A maintainer should always be on that list automatically.
Oh, hm, could this be an issue with subsystems that have a shared maintainership model? In that scenario not all maintainers will sign-off on a commit.
So a shared maintainer trusts their co-maintainer for reviewing patches for Linus's tree and all future kernels, but NOT into an old backported stable tree? I doubt that, trust should be the same for both.
thanks,
greg k-h