Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1187191ybe; Wed, 11 Sep 2019 10:42:00 -0700 (PDT) X-Google-Smtp-Source: APXvYqzi4jID+76z19VzlHR/yPSC4sys/5THD9cu/1m+RP2Ts8MbS8BhNBSgdwG2ZdIeWDMQsRyA X-Received: by 2002:a17:906:c7d0:: with SMTP id dc16mr30643603ejb.30.1568223720302; Wed, 11 Sep 2019 10:42:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568223720; cv=none; d=google.com; s=arc-20160816; b=ZbqCaJIiOToScpdwljbXp4MsfBP46KoSk/h9OFPMSzl5TEwbbjd77E2VwcQAqGZLhk 1C2Lokl96diyGiFXFrxwlyeyaQ67M1iC09maKd/BEbayElkaYokr6kIgnaFhrVSc0cjM r4vNXnlpKxOx+hPeZio9qPzLuXzOqfQ/rYFVCY+6P2XcC+nZwN20wOtZ5gsrXJ1jyUIU lYUJcyvr714ktrNCxUa9qRKNvm5pIA90TENgBeQMwYdv8rhIZHPEOKSkUqHwq7mGa1Hn OAlPA5Ym0v3aj3a5+ugz7T2L8VaoC/Sp4THJ38jiBjR/sgrLj6O2ev2Bz1ZFnvoIIu5Y /CZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=6NR7Q25BA7WxrOnFzlwxy7QGB9WB19+k1lIZyjhUgUk=; b=uHecEXiv8tlL4DunUPsKJ8FHtNpyYcMgc0i12triyuJvPZMVlUHZcS/8v3LedE0U0a Ou7AeUKbbOoICe5sI7/2n/gFNBrYHv+2lX915ryGR1/Ltaty1NEG/pFMKfqDmYi+11tI xXXoiAzmj/wJnAHTl/KBdW9jx16r5y0sbyo4DNId6PLXFIuqkDJk8SqJL5x0sSGAAoeW +EHba9iQK2dDox6mJFYAEVAr8CaM4iF8s4uVM0YwzA4d2VDmUjZshSzSJU3/B3ciu8Qh 4jg6hNveS2D74t8kBNalxAaLFBIiKIKdURKsVN+Ezo/Oi+wra0YqbO18d3GVmaRpMSaT q11w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v39si14102318edc.234.2019.09.11.10.41.21; Wed, 11 Sep 2019 10:42:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729585AbfIKRk4 (ORCPT + 99 others); Wed, 11 Sep 2019 13:40:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39000 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729517AbfIKRk4 (ORCPT ); Wed, 11 Sep 2019 13:40:56 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EFD7B10B78; Wed, 11 Sep 2019 17:40:55 +0000 (UTC) Received: from [172.16.176.1] (ovpn-64-2.rdu2.redhat.com [10.10.64.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F05619C6A; Wed, 11 Sep 2019 17:40:55 +0000 (UTC) From: "Benjamin Coddington" To: "Chuck Lever" Cc: "Jason L Tibbitts III" , "Bruce Fields" , "Wolfgang Walter" , "Linux NFS Mailing List" , km@cm4all.com, linux-kernel@vger.kernel.org Subject: Re: Regression in 5.1.20: Reading long directory fails Date: Wed, 11 Sep 2019 13:40:54 -0400 Message-ID: <8D7EFCEB-4AE6-4963-B66F-4A8EEA5EA42A@redhat.com> In-Reply-To: References: <4418877.15LTP4gqqJ@stwm.de> <4198657.JbNDGbLXiX@h2o.as.studentenwerk.mhn.de> <20190906144837.GD17204@fieldses.org> <75F810C6-E99E-40C3-B5E1-34BA2CC42773@oracle.com> <0089DF80-3A1C-4F0B-A200-28FF7CFD0C65@oracle.com> <429B2B1F-FB55-46C5-8BC5-7644CE9A5894@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 11 Sep 2019 17:40:56 +0000 (UTC) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 11 Sep 2019, at 13:29, Chuck Lever wrote: >> On Sep 11, 2019, at 1:26 PM, Benjamin Coddington >> wrote: >> >> >> On 11 Sep 2019, at 12:39, Chuck Lever wrote: >> >>>> On Sep 11, 2019, at 12:25 PM, Benjamin Coddington >>>> wrote: >>>> >> >>>> Instead, I think we want to make sure the mic falls squarely into >>>> the tail >>>> every time. >>> >>> I'm not clear how you could do that. The length of the page data is >>> not >>> known to the client before it parses the reply. Are you suggesting >>> that >>> gss_unwrap should do it somehow? >> >> Is it too niave to always put the mic at the end of the tail? > > The size of the page content is variable. > > The only way the MIC will fall into the tail is if the page content is > exactly the largest expected size. When the page content is smaller > than > that, the receive logic will place part or all of the MIC in ->pages. Ok, right. But what I meant is that xdr_buf_read_netobj() should be renamed and repurposed to be "move the mic from wherever it is to the end of xdr_buf's tail". But now I see what you mean, and I also see that it is already trying to do that.. and we don't want to overlap the copy.. So, really, we need the tail to be larger than twice the mic.. less 1. That means the fix is probably just increasing rslack for krb5i. Ben