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=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 53AD8C63697 for ; Mon, 23 Nov 2020 19:18:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A45362063A for ; Mon, 23 Nov 2020 19:18:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=fieldses.org header.i=@fieldses.org header.b="ETHKjR/Z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731346AbgKWTSl (ORCPT ); Mon, 23 Nov 2020 14:18:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729407AbgKWTSk (ORCPT ); Mon, 23 Nov 2020 14:18:40 -0500 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7B60C0613CF for ; Mon, 23 Nov 2020 11:18:40 -0800 (PST) Received: by fieldses.org (Postfix, from userid 2815) id 136896E9E; Mon, 23 Nov 2020 14:18:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 136896E9E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1606159120; bh=zRTd0JW2WYfrCxNiuuBaQoEJkhlTooZf+VHyw2Vetfw=; h=Date:To:Cc:Subject:References:In-Reply-To:From:From; b=ETHKjR/ZqqgwSRZ/+izFiCGhc5CTjB92QIScT3p0b1xsGXNaYtBnyRgZD5/Phg5/z RxJ7iOyC4zd3B0jILnP/rhpJIjd1dAx7IY0hprUcdPEW4hweObGK0oewXc8sALwvOO KOYoNtzFmdWjr0vOtooZYPjFJrv3kF2/2boQbZd4= Date: Mon, 23 Nov 2020 14:18:40 -0500 To: Chuck Lever Cc: linux-nfs@vger.kernel.org Subject: Re: [PATCH v2 005/118] NFSD: Replace the internals of the READ_BUF() macro Message-ID: <20201123191840.GH32599@fieldses.org> References: <160590425404.1340.8850646771948736468.stgit@klimt.1015granger.net> <160590445271.1340.9408337302317384948.stgit@klimt.1015granger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160590445271.1340.9408337302317384948.stgit@klimt.1015granger.net> User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, Nov 20, 2020 at 03:34:12PM -0500, Chuck Lever wrote: > @@ -396,7 +281,7 @@ nfsd4_decode_fattr(struct nfsd4_compoundargs *argp, u32 *bmval, > READ_BUF(4); len += 4; > nace = be32_to_cpup(p++); > > - if (nace > compoundargs_bytes_left(argp)/20) > + if (nace > xdr_stream_remaining(argp->xdr) / sizeof(struct nfs4_ace)) Picky C question: is the compiler guaranteed to pack that struct in the obvious way? That aside, I'm not comfortable assuming the struct could never change to, say, include something that's useful during processing but doesn't appear on the wire. Also, that change isn't actually logically related to the rest of the patch, so it's the sort of thing I'd expect separated out. --b.