From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA34CC31E40 for ; Mon, 12 Aug 2019 21:19:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7331C2070C for ; Mon, 12 Aug 2019 21:19:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565644767; bh=dHo2t329Id4otpA/Rrjyv9seqUsvy6Z6EEJcEyMJIMw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=z15lY+2wNozkzW55Q11lHv3OSF4VqYXrjoUnlgBqcC6YPoadmeo4gTlO+ysea3tin F1yM+904eaI3EMY63/WJUWwTMyx5gXmcHFciuiYHSNwlacxm7uNWnp/MACfA7KrnGu Np70Y4WNK9lP8bhbrWu/m9Ul+n52yrzppJJSZUpY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727151AbfHLVT0 (ORCPT ); Mon, 12 Aug 2019 17:19:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:58732 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726530AbfHLVT0 (ORCPT ); Mon, 12 Aug 2019 17:19:26 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 26DD0206C2; Mon, 12 Aug 2019 21:19:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565644765; bh=dHo2t329Id4otpA/Rrjyv9seqUsvy6Z6EEJcEyMJIMw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XyRII+3I9wWVWSEqAOP7ZcGdiajnySWhn+aeL+QjbQeopq1r8BppDCR7LG+WCZTaC rhX8JnwudyqzoxJPmWfE9gCemQK+DLgIsu4tnU1xB8d8BwM4X/tFP/ypcGwOIo0ei5 qidMBcxIItLjf+ISX6m2+F3bbZnLUpPWTUODQd9U= Date: Mon, 12 Aug 2019 14:19:24 -0700 From: Andrew Morton To: Ivan Khoronzhuk Cc: bjorn.topel@intel.com, linux-mm@kvack.org, xdp-newbies@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, ast@kernel.org, magnus.karlsson@intel.com Subject: Re: [PATCH v2 bpf-next] mm: mmap: increase sockets maximum memory size pgoff for 32bits Message-Id: <20190812141924.32136e040904d0c5a819dcb1@linux-foundation.org> In-Reply-To: <20190812124326.32146-1-ivan.khoronzhuk@linaro.org> References: <20190812113429.2488-1-ivan.khoronzhuk@linaro.org> <20190812124326.32146-1-ivan.khoronzhuk@linaro.org> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, 12 Aug 2019 15:43:26 +0300 Ivan Khoronzhuk wrote: > The AF_XDP sockets umem mapping interface uses XDP_UMEM_PGOFF_FILL_RING > and XDP_UMEM_PGOFF_COMPLETION_RING offsets. The offsets seems like are > established already and are part of configuration interface. > > But for 32-bit systems, while AF_XDP socket configuration, the values > are to large to pass maximum allowed file size verification. > The offsets can be tuned ofc, but instead of changing existent > interface - extend max allowed file size for sockets. What are the implications of this? That all code in the kernel which handles mapped sockets needs to be audited (and tested) for correctly handling mappings larger than 4G on 32-bit machines? Has that been done? Are we confident that we aren't introducing user-visible buggy behaviour into unsuspecting legacy code? Also... what are the user-visible runtime effects of this change? Please send along a paragraph which explains this, for the changelog. Does this patch fix some user-visible problem? If so, should be code be backported into -stable kernels?