Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2153827pxb; Mon, 8 Mar 2021 16:07:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJzaaeXKohWY9709JIaroEuB0DapOipqcbYzlxM/bPn3fOS4MAJRP5Inkojh/puD3F+9LuM1 X-Received: by 2002:a17:906:2710:: with SMTP id z16mr16903963ejc.176.1615248429935; Mon, 08 Mar 2021 16:07:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615248429; cv=none; d=google.com; s=arc-20160816; b=ijY1kZpNoYL81evSEK4131ZB5m9B0K7qtbNm176VunXvMMSwoRLnhLcUQZlVWPYdyv xjy5a/cO/+g78HI2ECqcHGKiBeGI0bv1BUMJuWYD5wK7KweodWOxwxjmzc6BAaIfFhcv S2ySeydXRYsgliDT4G0DhDdhCZTz0tRGe+Z28XkEwUSFFnCOO0P/mi0TfpP3PcA1ijcH cv1403Wl8EQFBEsazmk/GIZJla2fCG9N9DXDisrCXelOTEDCYxp1GIa41LaQzQKYt1rV Bx3Sg4vkGtE8MAVTl+A1JObsQtYas2wS8Ep2mQepeGQJGpiy57kzMzhWylkeQt+RfM5A BQQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1dqCVTG2109HqZ5qitjhQym98S7SrqCwUMAJTjbj+9Y=; b=snb69xq9ECFTOjs14/Ga67HqDYvT9dOUuLaa8QEFVg1ifZRelOgiOGZzXYF4sKVHv4 nnUSzNTlTtjKuIFWOKN6EM0ACLFmvInhFSLlLASzRQjdnaRfuGJPbbcvFHdNME4eqGRU zu85TkyU3Az/6HHdS7J9GjP2ts5+zUeftI4tUhpJ/GsNOFfmRcnU+sJRgE6l6DGbItWF mLcfStQ36Fa/rR+/Tb4GIskzfwoCD2C05A7hW1wXpJynsyxllGRf2CPueZ8ocFZKp2iw Fs6JfFOseutsixV2kyXjmRzMUZBqsv29JRJQ0D4vz15ldH6u3s38xlRBBtIvxTnIhXxO sKCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UEihR8Cr; 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 i6si7551105ejz.383.2021.03.08.16.06.47; Mon, 08 Mar 2021 16:07:09 -0800 (PST) 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=UEihR8Cr; 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 S230460AbhCIAFf (ORCPT + 99 others); Mon, 8 Mar 2021 19:05:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229627AbhCIAFX (ORCPT ); Mon, 8 Mar 2021 19:05:23 -0500 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5B36C06174A; Mon, 8 Mar 2021 16:05:23 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id o9so11994095iow.6; Mon, 08 Mar 2021 16:05:23 -0800 (PST) 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=1dqCVTG2109HqZ5qitjhQym98S7SrqCwUMAJTjbj+9Y=; b=UEihR8CrE4FeNvT2OdS7bRAfFJCmRPsb30Kiepa47DNk2DE7zZbdu+v6dLRCJfRBCO oRwRvLNClbJaUy5/ecqwuAWxT5sW1ijnnlfn2osB6d9V7I6PD5SClj98hqqAlzk0YiTi Kz8NkwSO1Ts26CcybddV9OyUWdDndv3VPBlFEkusMyTOyW5Skb17fmNoWrNThK3nNtcY WhCy8NNJIy7prx5fKzFWuoBkcJCn0Thh6PTC8bGOP8LmKZBsglQXDo9LiIv5DLP5uxLY AefbjUIWHSznFSoHWpa9nSdJJg/siTERIO7DByP+cOdkVI1O3d27tCAyQMvWO5IvfdGA GQWg== 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=1dqCVTG2109HqZ5qitjhQym98S7SrqCwUMAJTjbj+9Y=; b=pp8117bgi5sketlHPV5AJ9jrYSyCnpjsM4CdKKKREaWitKJphvVudoGmvtwuJhiJlf PwT7nOJbxTeT/kvsLG4J9DFMmrbvFgYbVSMnOYWDK9pnZkPlXs8Wr4qavW29JwbabzgO FHJhQonHQhDkFxe3sbdzEXWMnGa6+WiXYiKOyaKIcuEH7WgrIzMGY446qVbWyyDSB8w+ DT2YsMgWcqxGdE/JnSho4Mzo6Nc58EinKW7yhU0dwyqdbiHob19iaizPGXk+VjDLx+eM o3N1fRMS4WPElz7fzigN5ufK4jBnn7Drj77x8CyKDLWzodlS4gXKo5o8lyG9/aOe39QW 0zXw== X-Gm-Message-State: AOAM533bpGav2iCMjpJSr0EL0dLLX9bX/Wb6HKMA35YP0Yg2NK8mlOdB wnEAkYnkOJWX/TS9/ZNd8C9LD72NnGexgv0HvNw= X-Received: by 2002:a02:9042:: with SMTP id y2mr26340053jaf.94.1615248322889; Mon, 08 Mar 2021 16:05:22 -0800 (PST) MIME-Version: 1.0 References: <20210305094107.13743-1-vincent.whitchurch@axis.com> In-Reply-To: From: ronnie sahlberg Date: Tue, 9 Mar 2021 10:05:11 +1000 Message-ID: Subject: Re: [PATCH] CIFS: Prevent error log on spurious oplock break To: Shyam Prasad N Cc: Vincent Whitchurch , CIFS , samba-technical , LKML , Steve French , kernel@axis.com, Pavel Shilovsky Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 7, 2021 at 8:52 PM Shyam Prasad N via samba-technical wrote: > > Hi Vincent, > > The reason for rejecting the request maybe a number of things like: > corrupted request, stale request (for some old session), or for a > wrong handle. > I don't think we should treat any of these cases as a success. I agree with Shyam here. We shouldn't change the return value to pretend success just to suppress a warning. However, if it is common to trigger with false positives we might want to something to prevent it from spamming the logs. These messages could be useful if we encounter bugs in our leasing code, or bugs in server lease code, so we should't throw them away completely. But if false positives are common ... Some thoughts I and Stever brainstormed about could be to change the code in the demiltiplex thread where we currently dump the packets that were "invalid" to maybe: * log once as VFS and then log any future ones as FYI * log once as VFS and then only make the others available via dynamic trace points * rate limit it so we only log it once every n minutes? (this is overkill?) > > Also, from the MS-SMB2 documentation: > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/4f35576a-6f3b-40f0-a832-1c30b0afccb3 > > "The client MUST locate the file in the GlobalFileTable using the > LeaseKey in the Lease Break Notification. If a file is not found, no > further processing is required." > > So I don't think we should be changing the logic here. > If SMB v1 had a different behaviour, we should check if that is as per > the protocol documentation. If not, change it. > > Regards, > Shyam > > On Fri, Mar 5, 2021 at 3:12 PM Vincent Whitchurch > wrote: > > > > The SMB1 version of ->is_oplock_break() returns true even if the FileId > > is not found, as long as the oplock break notification message structure > > itself appears to be valid. A true return value makes > > cifs_demultiplex_thread() to not print an error message for such > > packets. > > > > However, the SMB2 version returns false in such cases, leading to an > > error "No task to wake, unknown frame received!" followed by a hexdump > > of the packet header being printed by cifs_demultiplex_thread(). > > > > Note that before commit fa9c2362497fbd64788063288d ("CIFS: Fix SMB2 > > oplock break processing"), SMB2 also returned true for the case where a > > connection was found but the FileId was not, but it's not clear to me if > > that commit really intended to change the behaviour of the error prints. > > > > Change the behaviour of SMB2 to be the same as SMB1 and avoid the error > > messages for these packets which we ignore as per the spec. > > > > Signed-off-by: Vincent Whitchurch > > --- > > fs/cifs/smb2misc.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c > > index 60d4bd1eae2b..3ea3bda64083 100644 > > --- a/fs/cifs/smb2misc.c > > +++ b/fs/cifs/smb2misc.c > > @@ -679,7 +679,7 @@ smb2_is_valid_lease_break(char *buffer) > > } > > spin_unlock(&cifs_tcp_ses_lock); > > cifs_dbg(FYI, "Can not process lease break - no lease matched\n"); > > - return false; > > + return true; > > } > > > > bool > > @@ -755,7 +755,7 @@ smb2_is_valid_oplock_break(char *buffer, struct TCP_Server_Info *server) > > } > > spin_unlock(&cifs_tcp_ses_lock); > > cifs_dbg(FYI, "Can not process oplock break for non-existent connection\n"); > > - return false; > > + return true; > > } > > > > void > > -- > > 2.28.0 > > > > > -- > Regards, > Shyam >