Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5101072ybi; Tue, 28 May 2019 07:33:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqynE3uQj5HLZ0PZxS5UT/CgRgJrG5C9SfQUDmaJD8txkSctoX3tGTnIyVLYjLWbLG7NSf1R X-Received: by 2002:a62:ea0a:: with SMTP id t10mr143184856pfh.236.1559054028560; Tue, 28 May 2019 07:33:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559054028; cv=none; d=google.com; s=arc-20160816; b=o62eKkPeb5XELDLfKsukalfKcwGV8E6vlHJl7zQ6yanD+lymdR46sAwE2RvhTsKPyu qsF4P7jT7HDSUQK+IaEoj/+Ft3inOdZNTaM4SpShMA+P6iohkGHpC6HaVBYDKu5s6Laz Lqbg9wc0TR4FGQFheuacWQKH6u6OfCZCEEBLoy3KpY85083QK5eF3b55A9xyL/87yoPf ZBx3kKSIo47Qeb4Psa8I1t4dW0DHcGXVIqkLgpv1p85+q6A4CNyxBwS7f7/XwFbVcDbX qF/0SML9Ad+pOSh2iMowCQ4tLgJvqwq1FL24rGi8X43Ytbzj6rczKhiziFx3FLO4xqL6 EoAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=Q0GPyIP0qLUCZc0k2ct4a0hMvL754LFUHW4FWHu306Y=; b=tt7v83ging+lZECTXO2ce7TSLPqkdj1TTy10xBwWGyCbweEwcebu013S5lcIr1D+HW a4/LlOMAd0+NCTuys/RB29IfOXXVU55swMPlU7+hm5Nedtot3lYY95+veSB22wXgeW3j 7fFNUGLvPnaTaK6jmi/43ZOFtG5lzarBe03lwZdY1xd7IwsD+kU8YP9n6OxNNJISuknW 4NTg81RoIresb5StSZ073wyk8M4izB18a04Ir4Acd/i0kT9I8skl0jhNoNBbKKAI7/NY Gu+LvXqWtqv9ll3kw/3u1s3Hj+C+Aknpd+QHJcHkmTnyhnbrNcJMLQ7ScWbLO3bCIGML sVjA== 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; 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 t1si22547825pgc.565.2019.05.28.07.33.33; Tue, 28 May 2019 07:33:48 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727239AbfE1OaC (ORCPT + 99 others); Tue, 28 May 2019 10:30:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36530 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbfE1OaB (ORCPT ); Tue, 28 May 2019 10:30:01 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B8E7A7E42F; Tue, 28 May 2019 14:30:01 +0000 (UTC) Received: from prarit.bos.redhat.com (prarit-guest.khw1.lab.eng.bos.redhat.com [10.16.200.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1796C10027C5; Tue, 28 May 2019 14:30:00 +0000 (UTC) Subject: Re: [PATCH] modules: fix livelock in add_unformed_module() From: Prarit Bhargava To: Barret Rhoden , Jessica Yu Cc: linux-kernel@vger.kernel.org, Heiko Carstens , David Arcari References: <20190510184204.225451-1-brho@google.com> Message-ID: Date: Tue, 28 May 2019 10:30:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 28 May 2019 14:30:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/22/19 1:08 PM, Prarit Bhargava wrote: > > > On 5/13/19 10:37 AM, Barret Rhoden wrote: >> Hi - >> > > Hey Barret, my apologies for not getting back to you earlier. I got caught up > in something that took me away from this issue. > >> On 5/13/19 7:23 AM, Prarit Bhargava wrote: >> [snip] >>> A module is loaded once for each cpu. >> >> Does one CPU succeed in loading the module, and the others fail with EEXIST? >> >>> My follow-up patch changes from wait_event_interruptible() to >>> wait_event_interruptible_timeout() so the CPUs are no longer sleeping and can >>> make progress on other tasks, which changes the return values from >>> wait_event_interruptible(). >>> >>> https://marc.info/?l=linux-kernel&m=155724085927589&w=2 >>> >>> I believe this also takes your concern into account? >> >> That patch might work for me, but I think it papers over the bug where the check >> on old->state that you make before sleeping (was COMING || UNFORMED, now !LIVE) >> doesn't match the check to wake up in finished_loading(). >> >> The reason the issue might not show up in practice is that your patch basically >> polls, so the condition checks in finished_loading() are only a quicker exit. >> >> If you squash my patch into yours, I think it will cover that case. Though if >> polling is the right answer here, it also raises the question of whether or not >> we even need finished_loading(). >> > > The more I look at this I think you're right. Let me do some additional testing > with your patch + my original patch. > I have done testing on arm64, s390x, ppc64le, ppc64, and x86 and have not seen any issues. Jessica, how would you like me to proceed? Would you like an updated patch with Signed-off's from both Barret & myself? P. > P. > > >> Barret