Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1384767ybb; Thu, 9 Apr 2020 00:39:03 -0700 (PDT) X-Google-Smtp-Source: APiQypIggbXkeyMkTpXaKJ1bKp9gS6EBTmUqGYYh9/WVP2aqTEAoeIWX+65CjVHYON8vCPscdp5H X-Received: by 2002:a4a:e0d1:: with SMTP id e17mr2833390oot.53.1586417943664; Thu, 09 Apr 2020 00:39:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586417943; cv=none; d=google.com; s=arc-20160816; b=t78YypsTpC792mf4zir7fPB3hVm/wRKuke57zr0tjeeAupD0N0YMdhqbogIPfAYwNZ J50i4KKQwcDYQ9WuuX8IwluA/gO/Eu9eXAtxQNbWnWC2wGK3PoszQbU7slz8xINjb3kt Jtfuxbm/wXWL4iEsHamm6y84rSMT1F9pQqr9/MXkExiir47vLx/zXhtM92s60rNXOkFh RYwExiJHelhBZb0IPEnTQERD6eRakjtzqwQqyowEM2S8W+bXNjVdRVlzP6GouRfDK2aq 1AAnQB1uwiJ4kg6ONzAgncblWCEhSgKI1OESee8XG3TKB0qqvMLpVDUbhn4c4lZctQbU cPcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=GkbYp4gapX9g07SrUc/YNii+vmHlZ4+BITdKx/oObWE=; b=XB3qZcd11ZTwN8f6uZ6nIqS6WwWeMM9nuXa0CtuTEPZZNqgBdV+gC9lDvsvoXZIOqa bZcF05QgCzCrBrEhj0j5WiWoR8+Jktwo5QV1PmEvfijgZjJ/+ck7FA5EHqRhz6IMbXCN J8UfEe3kzQLM4K9PbNvIV2t51olnxWZjBXBggAl6nkThY4wBzYo6Zcy2jb8Mp3bLrlDG gaQMU6ZwS3aDgLezQCiumSbyZeqcBe/mXXhlRCz0oKrN1if5rfYa8ErKFvYZLgHhszro KGMFWMf31Qihh5C+e4uS4sGJyzJwlsnRBW9wLx1xQquqyEv8sbVwJu4aMwbf3SJiFHqn M3vg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si2908711oix.67.2020.04.09.00.38.48; Thu, 09 Apr 2020 00:39:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726666AbgDIHgg (ORCPT + 99 others); Thu, 9 Apr 2020 03:36:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:57642 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726082AbgDIHgg (ORCPT ); Thu, 9 Apr 2020 03:36:36 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 37471ADA3; Thu, 9 Apr 2020 07:36:35 +0000 (UTC) Date: Thu, 9 Apr 2020 09:36:34 +0200 From: Daniel Wagner To: "Ewan D. Milne" Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, "James E.J. Bottomley" , "Martin K. Petersen" Subject: Re: [PATCH] scsi: core: Rate limit "rejecting I/O" messages Message-ID: <20200409073634.t2xgdhoyb4jmidnp@beryllium.lan> References: <20200408171012.76890-1-dwagner@suse.de> <120ce7f4cd1fd070e1f7c353223c21b8e4f29337.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <120ce7f4cd1fd070e1f7c353223c21b8e4f29337.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ewan, On Wed, Apr 08, 2020 at 03:16:27PM -0400, Ewan D. Milne wrote: > On Wed, 2020-04-08 at 19:10 +0200, Daniel Wagner wrote: > > --- a/drivers/scsi/scsi_lib.c > > +++ b/drivers/scsi/scsi_lib.c > > @@ -1217,7 +1217,7 @@ scsi_prep_state_check(struct scsi_device *sdev, > > struct request *req) > > */ > > if (!sdev->offline_already) { > > sdev->offline_already = true; > > - sdev_printk(KERN_ERR, sdev, > > + sdev_printk_ratelimited(KERN_ERR, sdev, > > "rejecting I/O to offline > > device\n"); > > I would really prefer we not do it this way if at all possible. > It loses information we may need to debug SAN outage problems. Understood. > The reason I didn't use ratelimit is that the ratelimit structure is > per-instance of the ratelimit call here, not per-device. So this > doesn't work right -- it will drop messages for other devices. I didn't really think this through. Sorry. > > - sdev_printk(KERN_ERR, sdev, > > + sdev_printk_ratelimited(KERN_ERR, sdev, > > "rejecting I/O to dead device\n"); > > I practice I hardly see this message, do you actually have a case > where this happens? If so perhaps add another flag similar to > offline_already? > > The offline message happens a *lot*, we get a ton of them for each > active device when the queues are unblocked when a target goes away. I've missed commit b0962c53bde9 ("scsi: core: avoid repetitive logging of device offline messages") which should address the report I got in our enterprise kernel. I was over eager to rate limit the 'dead device' as well. It seem no need for this patch. Let me backport the commit and see what our customer has to say. Thanks for the help! Daniel