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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 7C284C10F11 for ; Thu, 25 Apr 2019 00:36:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 42492214C6 for ; Thu, 25 Apr 2019 00:36:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="2PZRdc8k" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388075AbfDYAgX (ORCPT ); Wed, 24 Apr 2019 20:36:23 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:37642 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388039AbfDYAgW (ORCPT ); Wed, 24 Apr 2019 20:36:22 -0400 Received: by mail-qt1-f195.google.com with SMTP id z16so22553916qtn.4 for ; Wed, 24 Apr 2019 17:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=xclC02gf/w3t074I39NRCaaCIZMOYyWVvrF+cNrhhg4=; b=2PZRdc8kOU0PZrIFObFw+15e9w8F4KfH/B4Bzjol2QA1lph7x7i1Rr0Lu7A+mx57hc Qpbdybs4OPZbQxsqw4LQe5ejJzYwHgyYgxPpRpyIYVPgu1YiyVL9yKx/Y059jLj0AOzE smGCZAogH0zJMeeUyKk93AWz/uU3cPzEkEjpRgzZshIIdACSclfPPUGiZk0+qgtGvl3a XfQMQZrILouz8jgMf4ycFjtjCB+oPsvdgJ1UKd/f5SwgOvDm3SN/bLLaWQsV9tM8jnnm MBvkE2zTtRjaFE9Aj952wCoil2T9pGJ+6KhIMPFeHI0zCBskChD+ETYYWnh+YkXmsaBD XsLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=xclC02gf/w3t074I39NRCaaCIZMOYyWVvrF+cNrhhg4=; b=se33AKRpZculUlzxbalRcPbPN7iVm1rhuHYHrRUAuoWZLxx//mRHwnD+21WYdtXY0K rSSm7OIOL6ubFGz5MjBzqtuHuvCsu4Oulx4tIGYo9z46GzoxnjSiBJgCoZ2BxXuvb1qD Fc/OpWmwwdKCuJJ7TJ8Hs7J5ekHd3QaKDBwDSkqPQOfCtf4v9wikweE4xmnMg/9nwwUH y7A8TLi1pBUma744Ms2dV2PWLyEPAVbulAMtXg7C1cGlrJQLmjXo2rS8aDUr6HZbba8q hBh0HNWgdjB6sXBmUuAXomAxOmDFoVur4oP0WM2QkqeL8nDNHzS/pdyO9cRlQynMxytx G4WQ== X-Gm-Message-State: APjAAAWKcFq/OxGakoI3R0MklaaIe1KENRFPAUyrLyhIK5xkSrcbwMnj hu7pQZxtLOgzHTnCg9hUvdwNYQ== X-Google-Smtp-Source: APXvYqwzG1DT0906EmdGr4XSpO1KdzNI9JZWZ/Yx8KDiC0xrTCwJontGHACloBdkGflyMtSfx1rcTw== X-Received: by 2002:a0c:9973:: with SMTP id i48mr28858884qvd.9.1556152581710; Wed, 24 Apr 2019 17:36:21 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id y18sm6009815qtm.47.2019.04.24.17.36.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Apr 2019 17:36:21 -0700 (PDT) Date: Wed, 24 Apr 2019 17:36:16 -0700 From: Jakub Kicinski To: Dan Carpenter Cc: Parav Pandit , netdev@vger.kernel.org, Leon Romanovsky , Eli Cohen , Doug Ledford , Jason Gunthorpe , "linux-rdma@vger.kernel.org" , "kernel-janitors@vger.kernel.org" Subject: Re: [PATCH] IB/mlx5: add checking for "vf" from do_setvfinfo() Message-ID: <20190424173616.03e69af2@cakuba.netronome.com> In-Reply-To: <20190424140820.GB14798@kadam> References: <20190412175504.GA20857@kadam> <20190415094610.GO6095@kadam> <20190416082112.GA27670@kadam> <20190420095102.GA14798@kadam> <20190423154943.GC14820@kadam> <20190424140820.GB14798@kadam> Organization: Netronome Systems, Ltd. 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 Wed, 24 Apr 2019 17:08:20 +0300, Dan Carpenter wrote: > To me making "vf" a u32 throughout seems like a good idea but it's an > extensive patch and I'm not really able to test it at all. But maybe > there is a better place to check for negatives. Or maybe we are already > checking for negatives and I haven't seen it. (I don't know this code > very well at all). Could we please add the checks in the core? We already have the infra in place for calculating dump sizes - i.e. int num_vfs = dev_num_vf(dev->dev.parent); We just need to validate the set params. Callback parameters should really be validated by the core to the extent possible, unfortunately driver authors have little incentive to improve that once an API is implemented, realistically we all need to support old kernels wouldn't do the checking..