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 943EFC32750 for ; Mon, 12 Aug 2019 21:19:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5C52C2070C for ; Mon, 12 Aug 2019 21:19:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565644768; bh=dHo2t329Id4otpA/Rrjyv9seqUsvy6Z6EEJcEyMJIMw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=W22N28nDaPAjx+9xQYvQLUeIWocyGL8DaQM07u4N4WQK8kIfPlpgIi7sIqIMGlE3J 5L2HHeIb+0GOykv613f437T0twfvlob//+Bci8BcuNCLmqLcLv5za9G7ImfUVKNIny 280cjzYD6WSGyuk7/ZW8xl5w2roN5a7eLKTqhLhc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727260AbfHLVT1 (ORCPT ); Mon, 12 Aug 2019 17:19:27 -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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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?