Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933932AbcLHAg3 (ORCPT ); Wed, 7 Dec 2016 19:36:29 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:37122 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932441AbcLHAg2 (ORCPT ); Wed, 7 Dec 2016 19:36:28 -0500 MIME-Version: 1.0 In-Reply-To: <20161207.145240.1636297838792223189.davem@davemloft.net> References: <20161207.135127.789629809982860453.davem@davemloft.net> <20161207.145240.1636297838792223189.davem@davemloft.net> From: "Jason A. Donenfeld" Date: Thu, 8 Dec 2016 01:29:42 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Misalignment, MIPS, and ip_hdr(skb)->version To: David Miller Cc: Dave Taht , Netdev , linux-mips@linux-mips.org, LKML , WireGuard mailing list Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 888 Lines: 16 On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote: > The only truly difficult case to handle is GRE encapsulation. Is > that the situation you are running into? > > If not, please figure out what the header configuration looks like > in the case that hits for you, and what the originating device is > just in case it is a device driver issue. My case is my own driver and my own protocol, which uses a 13 byte header. I can, if absolutely necessary, change the protocol to add another byte of padding. Or I can choose not to decrypt in place but rather use a different trick, like overwriting the header during decryption, though this removes some of the scatterwalk optimizations when src and dst are the same. Or something else. I wrote the top email of this thread inquiring about just exactly how bad it is to call netif_rx(skb) when skb->data is unaligned.