Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753777AbbGUJNL (ORCPT ); Tue, 21 Jul 2015 05:13:11 -0400 Received: from smtp.citrix.com ([66.165.176.89]:9016 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750783AbbGUJNI (ORCPT ); Tue, 21 Jul 2015 05:13:08 -0400 X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="282836768" Message-ID: <55AE0D1E.1070203@citrix.com> Date: Tue, 21 Jul 2015 11:13:02 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Bob Liu , CC: , , Subject: Re: [PATCH 3/3] xen-blkback: rm BUG_ON() in purge_persistent_gnt() References: <1437449441-2964-1-git-send-email-bob.liu@oracle.com> <1437449441-2964-3-git-send-email-bob.liu@oracle.com> In-Reply-To: <1437449441-2964-3-git-send-email-bob.liu@oracle.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1846 Lines: 44 El 21/07/15 a les 5.30, Bob Liu ha escrit: > This BUG_ON() will be triggered when previous purge work haven't finished. > It's reasonable under pretty extreme load and should not panic the system. > > Signed-off-by: Bob Liu > --- > drivers/block/xen-blkback/blkback.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c > index ced9677..b90ac8e 100644 > --- a/drivers/block/xen-blkback/blkback.c > +++ b/drivers/block/xen-blkback/blkback.c > @@ -394,7 +394,9 @@ static void purge_persistent_gnt(struct xen_blkif *blkif) > > pr_debug("Going to purge %u persistent grants\n", num_clean); > > - BUG_ON(!list_empty(&blkif->persistent_purge_list)); > + if (!list_empty(&blkif->persistent_purge_list)) > + return; > + I see the problem with this, there's a check for work_pending before this BUG_ON, but it doesn't account if the work is currently running. I would rather prefer to replace the work_pending check with work_busy instead, which will also take into account if the work is still running. The comment on work_busy however makes me nervous: * Test whether @work is currently pending or running. There is no * synchronization around this function and the test result is * unreliable and only useful as advisory hints or for debugging. AFAICT I think it should be safe because we don't have concurrent purge_persistent_gnt calls, but I'm no expert on Linux workqueues. It also makes me wonder why we have such a half-baked function in the Linux kernel. Roger. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/