Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3311854ybt; Sat, 4 Jul 2020 12:41:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYPtyC23nHiQShuHy0v+GnJJHxkHj/HSj+02+wjQUShm4l5CPTpbtPHsyTHYSWVhiCEjRV X-Received: by 2002:aa7:d043:: with SMTP id n3mr49021362edo.102.1593891710497; Sat, 04 Jul 2020 12:41:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593891710; cv=none; d=google.com; s=arc-20160816; b=dgiTaQy0wtw8TN/34Z7mgpc6qBdg2pMCKE4UfnvibXGvGFVelEZAdnl/zCRj09xHxq MQHgE8VCBlfZ6MOiPbH5c6Qcz337QXUMX7nsPyIyaBpu+3hvWq40E4gAGTz8FJzyADhA 9bWYJj39lr2G7gnp8pcyExDa9xaByJrVuZLJu0Tzn0X2J8NPriJiU/zQWIfByDJF8OGg 5Nn07s95WGz0KJ0tidh6uaPjazoxmwdu+JsLQcVXe1znnrkJXQDO+GQAcuT0ULPq7r4Z TiNyk2ZlZaMNDabfDHYjnDyByLc8czeoztWoYGu8dn0KJ+O08n8PbVCaYEJRu3y5+Jsy aBQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=oaguPC34T7R0o5+DoNQSjRDr1tEmYY+rGX3DoLh4xf8=; b=F/pUg/6Shtj7afBJzplGimms8h76/Gf9pEQRcVaiEkXs8oe4fr4WqzRsHz6BocI6Dm YcXPRRa31DQCybJFrmb2SfmJPH1HwbuPI3AT5CIX7RhSJiKBfWKy5LDjEQkyznfhsQBo Uj9uZ2obi5mCqHqpJVMHo6WVGsQrjAcQFO9YrOvKka1P/E0bw5sH4cXrh+74kFAHixsl fLpEBcCnXsi3sFdXSoqjKkQxHrfe3hi1yvyAqvGakTpjRGolg/8BYupkg1dGBh08PNwL WczkhxLcTWslXaIBv0NeDUrwHnUejYoTMVVeIU2sL2zUJN6/QdrRCfxhKNlS0w6euD0l Igjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UqQlaqT7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g15si6462987edy.200.2020.07.04.12.41.27; Sat, 04 Jul 2020 12:41:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UqQlaqT7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727084AbgGDTlT (ORCPT + 99 others); Sat, 4 Jul 2020 15:41:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726153AbgGDTlT (ORCPT ); Sat, 4 Jul 2020 15:41:19 -0400 Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAAAAC061794; Sat, 4 Jul 2020 12:41:18 -0700 (PDT) Received: by mail-il1-x141.google.com with SMTP id t4so16681718iln.1; Sat, 04 Jul 2020 12:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oaguPC34T7R0o5+DoNQSjRDr1tEmYY+rGX3DoLh4xf8=; b=UqQlaqT7Hr64mfOELSvx1Wr9DuwUyUEsOQFLfZLOzCNJEbzYE+7u+wQFpS+2aYI5XU JBmMm3PyTEmTUd+hQDkw/w393xyUdgyaaQL+rgpTTTvsUuf0XUxvtP6X9iYLY/LaeuuB HI5S3DYdndoix8ToVO30hJjXgLULga2v/wd3m8Syav7o2hfOP9/CAGOOFYBVXhSVIUWr czNTCHLDr2U0Bv0Fk6Tkng8KosYcdMZTaJMcBIgDc1jLRknGgrxddMasIUql60sjBffi tLaUYWSTq0M3wvGsTJ3bf+u5+C76wUmolpkFPwuomPtOQspzOYGxQdCYtbIZw590E++2 skwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oaguPC34T7R0o5+DoNQSjRDr1tEmYY+rGX3DoLh4xf8=; b=bDYgHdcl9S61VqchsKh1nws/+i8FK5SQYaZ6lzIQmc+JmT80bCrNc2Ff+Wtsb2g1S/ H9P4nAMtpuM59e82wn6/kkSo3O4lw5SgMu8bsrxX1BuMPie0Ar30Wyz2bFxdbtqcrQXb UX2ezFVxrL9FJmWjdcXha43TjQTOd++P6fQOuLa50js5t4usZnNWuS9bliy7wUUXri7s 7IW9p7noCEv1xyhdO7iA0kFxDEBU1obkwHqY3o3Fli5dfbsXzTL8l2y2KYjpcKCdiKH7 G68WrWxVkyLefgUc4zda2yF5Scf0f0I9zsYigYsF/L5PKpe1TCtj/dF4poScnqz0WcMp dJiA== X-Gm-Message-State: AOAM5326eCKZ1n/YJllvOaQ5HvXR4Yznl7s4z6L0FtIDU2gw34lCwnQV +6dUAD9X0JsnoRf3wyxLrKLrScAUWayZnl4x1gI= X-Received: by 2002:a92:5a05:: with SMTP id o5mr17808012ilb.237.1593891678038; Sat, 04 Jul 2020 12:41:18 -0700 (PDT) MIME-Version: 1.0 References: <20200703182010.1867-1-bruceshenzk@gmail.com> In-Reply-To: From: Alexander Duyck Date: Sat, 4 Jul 2020 12:41:07 -0700 Message-ID: Subject: Re: [PATCH] net: fm10k: check size from dma region To: Zekun Shen Cc: Jeff Kirsher , "David S. Miller" , Jakub Kicinski , intel-wired-lan , Netdev , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 4, 2020 at 9:37 AM Zekun Shen wrote: > > On Sat, Jul 04, 2020 at 09:05:48AM -0700, Alexander Duyck wrote: > > The upper limitation for the size should be 2K or FM10K_RX_BUFSZ, not > > PAGE_SIZE. Otherwise you are still capable of going out of bounds > > because the offset is used within the page to push the start of the > > region up by 2K. > PAGE_SIZE can drop the warning, as the dma allocated size is PAGE_SIZE. Yes, but the point I was getting at is that if you are just going to squelch the warning, but leave the code broken then the warning isn't of any use and might as well be discarded. Either you limit the value to 2K which is what the hardware is expected to max out at anyway, or you just skip the warning and assume hardware will do the right thing. I'm not even sure this patch is worth the effort if it is just using some dummy value that is still broken and simply squelches the warning. Could you provide more information about how you are encountering the error? Is this something you are seeing with an actual fm10k device, or is this something found via code review or static analysis? > > If this is actually fixing the warning it makes me wonder if the code > > performing the check is broken itself since we would still be > > accessing outside of the accessible DMA range. > The unbounded size is only passed to fm10k_add_rx_frag, which expects > and checks size to be less than FM10K_RX_HDR_LEN which is 256. > > In this way, any boundary between 256 and 4K should work. I could address > that with a second version. I was referring to the code in the DMA-API that is generating the warning being broken, not the code itself. If you can tell me how you are getting to the warning it would be useful. Anything over FM10K_RX_BUFSZ will break things. I think that is what you are missing. The driver splits a single 4K page into 2 pieces and then gives half off to the stack and uses the other half for the next receive. If you have a value over 2K you are going to be overwritting data in another buffer and/or attempting to access memory outside the DMA region. Both of which would likely cause significant issues and likely panic the system.