From patchwork Thu Dec 19 17:08:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roland Dreier X-Patchwork-Id: 3383581 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A85B9C0D4A for ; Thu, 19 Dec 2013 17:08:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7D9882062F for ; Thu, 19 Dec 2013 17:08:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 076082062A for ; Thu, 19 Dec 2013 17:08:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753780Ab3LSRIw (ORCPT ); Thu, 19 Dec 2013 12:08:52 -0500 Received: from na3sys010aog107.obsmtp.com ([74.125.245.82]:47298 "HELO na3sys010aog107.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753582Ab3LSRIv (ORCPT ); Thu, 19 Dec 2013 12:08:51 -0500 Received: from mail-qc0-f173.google.com ([209.85.216.173]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUrMoIwIql2cYS+4qO1CPMBVBgPm0Tpz+@postini.com; Thu, 19 Dec 2013 09:08:51 PST Received: by mail-qc0-f173.google.com with SMTP id m20so1148455qcx.4 for ; Thu, 19 Dec 2013 09:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OwVc0pjwwK774MxS4aR9wto/W7Zr0uqiDB0T/GlsvWs=; b=Wci/aFfAEaoI308YUvk1zhgCofZwzcb/fOcbV+dlPR5Eoqou3EAMdt0RNOHe6TskiJ K+M+o9/qqTYOEI6pXP8wdM9+Qr339mJ5jg65ssYD5VvBN+5CEnfqdFZn/SFOUYQTjtMO nwU8wSsS0+e7FEo/vwTCQOLvoxtQzS7gmby4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OwVc0pjwwK774MxS4aR9wto/W7Zr0uqiDB0T/GlsvWs=; b=IaavEhWuT1ypZJYKwgFmb2gkU/JmpTuQPnlVrHHjBDpUGXo97hGabBHuYx+Ynol2Na YA2p5ph0v4yI9ioDWmclQR8WMy6xMsHUZh/+4+25imnEmEJr1NGr7tPedI0m1wsoapGV 0QMTGtV8GWeAnGWtXGil6Cu6Ho0p0C2ccsqz4xHVapXfY7+FB6B9OqyFR5zMf7m7Ago3 ZxnH47EpXIBFYo2vOEtVhLGeaxAuMZXD55ZIS3sNqoImFcovcDFY1QT2Q8WQ9jpGCXj5 1U7CpPgGju+ypICKyME0tA5XlR9Kg2AEaN7wY1uU/fOOr0od3MzD5DerurMPSneg50S8 v/wg== X-Gm-Message-State: ALoCoQkU4RsgYvAgMXXl7kJSk/PlQzJvVX+iYuQizEQWRkZ2o70s0BU28MX8EDVuaGd6/7cd8TcNMynRIZfX9AuXM758CJMfXJd4FryOYiPOTpcd5RukNo1uGx+ENZ9LDwt0kbcyLJ6AjXP9VztJ1DVa62DSi5cX7AWTpgcrRZJKEySbQ0fQ520= X-Received: by 10.224.121.140 with SMTP id h12mr4795689qar.41.1387472930724; Thu, 19 Dec 2013 09:08:50 -0800 (PST) X-Received: by 10.224.121.140 with SMTP id h12mr4795669qar.41.1387472930568; Thu, 19 Dec 2013 09:08:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.95.66 with HTTP; Thu, 19 Dec 2013 09:08:25 -0800 (PST) In-Reply-To: <1387459287.11925.52.camel@localhost.localdomain> References: <1387459287.11925.52.camel@localhost.localdomain> From: Roland Dreier Date: Thu, 19 Dec 2013 09:08:25 -0800 Message-ID: Subject: Re: [PATCHv4 for-3.13 00/10] create_flow/destroy_flow fixes for v3.13 To: Yann Droneaud Cc: Or Gerlitz , linux-rdma Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > Unfortunately, some patches in V4 were replacement for patches in V3. > In this particular case, I've rework the commit messages in V4, so these > changes might be lost. > And I'm a bit disappointed about this particular patch applied with a > conflict fix: > > https://git.kernel.org/cgit/linux/kernel/git/roland/infiniband.git/commit/?h=for-next&id=2f92baf8313756fd32da4d2a24abc67c8f4f7026 > > if (!access_ok(VERIFY_WRITE, > (const void __user *) (unsigned long) ex_hdr.response, > (hdr.out_words + ex_hdr.provider_out_words) * 8)) > return -EFAULT; > > https://git.kernel.org/cgit/linux/kernel/git/roland/infiniband.git/tree/drivers/infiniband/core/uverbs_main.c?h=for-next&id=2f92baf8313756fd32da4d2a24abc67c8f4f7026#n679 > > Checking for write access on a pointer to const doesn't sound right. > It's harmless, and, if sparse/coccinelle doesn't have a check for such, > it should be added to report a warning. Sorry for that mistake. I've fixed that conflict fix to get rid of the const. I've also pulled in the changelog updates. However, I still prefer not moving all the casts out into every place where we use INIT_UDATA(), so I'd prefer something like the patch below. I integrated that into the series and pushed out the result (since everyone seems OK with rebasing for-next). Please let me know what you think. From: Roland Dreier Date: Thu, 19 Dec 2013 08:37:03 -0800 Subject: [PATCH] IB/uverbs: Set pointers to NULL if length is 0 in INIT_UDATA() Trying to have a ternary operator to choose between NULL (or 0) and the real pointer value in invocations leads to an impossible choice between a sparse error about a literal 0 used as a NULL pointer, and a gcc warning about "pointer/integer type mismatch in conditional expression." Rather than clutter the source with more casts, move the ternary operator into the INIT_UDATA() macro, which makes it easier to use and simplifies its callers. Reported-by: Yann Droneaud Signed-off-by: Roland Dreier --- drivers/infiniband/core/uverbs.h | 12 ++++++------ drivers/infiniband/core/uverbs_main.c | 11 ++++------- 2 files changed, 10 insertions(+), 13 deletions(-) ex_hdr.provider_out_words * 8); -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/infiniband/core/uverbs.h b/drivers/infiniband/core/uverbs.h index 9879568aed8c..d2defbbdb5da 100644 --- a/drivers/infiniband/core/uverbs.h +++ b/drivers/infiniband/core/uverbs.h @@ -47,12 +47,12 @@ #include #include -#define INIT_UDATA(udata, ibuf, obuf, ilen, olen) \ - do { \ - (udata)->inbuf = (const void __user *) (ibuf); \ - (udata)->outbuf = (void __user *) (obuf); \ - (udata)->inlen = (ilen); \ - (udata)->outlen = (olen); \ +#define INIT_UDATA(udata, ibuf, obuf, ilen, olen) \ + do { \ + (udata)->inbuf = (ilen) ? (const void __user *) (ibuf) : NULL; \ + (udata)->outbuf = (olen) ? (void __user *) (obuf) : NULL; \ + (udata)->inlen = (ilen); \ + (udata)->outlen = (olen); \ } while (0) /* diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c index 34386943ebcf..76b6f217a13e 100644 --- a/drivers/infiniband/core/uverbs_main.c +++ b/drivers/infiniband/core/uverbs_main.c @@ -676,15 +676,12 @@ static ssize_t ib_uverbs_write(struct file *filp, const char __user *buf, return -EINVAL; } - INIT_UDATA(&ucore, - (hdr.in_words) ? buf : 0, - (unsigned long)ex_hdr.response, - hdr.in_words * 8, - hdr.out_words * 8); + INIT_UDATA(&ucore, buf, (unsigned long)ex_hdr.response, + hdr.in_words * 8, hdr.out_words * 8); INIT_UDATA(&uhw, - (ex_hdr.provider_in_words) ? buf + ucore.inlen : 0, - (ex_hdr.provider_out_words) ? (unsigned long)ex_hdr.response + ucore.outlen : 0, + buf + ucore.inlen, + (unsigned long) ex_hdr.response + ucore.outlen, ex_hdr.provider_in_words * 8,