From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E42F0C433FE for ; Thu, 12 May 2022 16:41:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C1286B0074; Thu, 12 May 2022 12:41:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 671996B0075; Thu, 12 May 2022 12:41:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55FBE6B0078; Thu, 12 May 2022 12:41:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 47FF26B0074 for ; Thu, 12 May 2022 12:41:55 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 286E8612DD for ; Thu, 12 May 2022 16:41:55 +0000 (UTC) X-FDA: 79457657790.24.E706ECB Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf28.hostedemail.com (Postfix) with ESMTP id A61F4C00A6 for ; Thu, 12 May 2022 16:41:33 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id q18so5409779pln.12 for ; Thu, 12 May 2022 09:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6TwX+Uem+RX7yFMEQloRfhp790CWUfMnBz6v8ZFXqWw=; b=W0iepvlelCLBuiCrQ0b37NsVuwjZqmnDvDuXQwTxPwqmfcisydLXhlvB+5bIBxb9Mo DDIm9SAd9GCqOj8Y1mqJ3sPE2DDD2VG+CyW+x8zKZGJ1ncvmUcgmSj5NWAatP+ff85TH ZnWqN4wW+Xvd09HvOI7ErGXsWF0qITMEkVBE8CptKkPKH0y41qpN2h8EhYFt/EnyW95X LUnS06SYFHbr1Fd4ZdIEgY2aNXkWlf7fBX3yTTPM4sIzGKDRzP8t5PBqeY5+wGCWKGeI 4l9xLi0L1UoF0RefF/g+HEKdfK0lgVXEOyZZ3Lz8Yy/OIJTAikD/cX/wCLx1Gu2ea24/ QN8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=6TwX+Uem+RX7yFMEQloRfhp790CWUfMnBz6v8ZFXqWw=; b=SM6Ps8b187YJizkAV35DO6XmDuc7Vsf0xhcigX3uauTEoVG8dKoLC62XeOVDouotNT gA/NFJwGOQiRIK3uTp4k+KHDi02bSadKVrTlEwgPXmRr41IYZBvl+tEQMZaCDlbuwso7 VImNw3WaGLmTXu+uFUyq4GJyOGKlR88oa5/zpjd2SbWf0K3THyuAgs1JC08bOro2+u7I AX8mr6Bkx6OXze0ZqL23tqNdtcRV3ZZb5FDcVEGqWccBdfWU3qZwDKyU7jiA5V3n8RY1 Dip7G6Pbd9ZBXG8tnPQn3MB2+kCZyyppYsaw+xfPbGcYgdun+a6lBjXjheklA9Mv8xLv D37A== X-Gm-Message-State: AOAM532YDU3CzzzcC661ghKdYlASvFZF6JH4kBq5+9NC2dWWdedYzmsr GHTj1fH9wiBvQ25p+N8xfvg= X-Google-Smtp-Source: ABdhPJzsb54QRB11Kg0xwOQPwsZz32Td9eLOjqUbH9eOlCaQUD4CO9IvOZZ+4QXL8vYjVErb6WonGA== X-Received: by 2002:a17:902:ab96:b0:159:1ff:4ea0 with SMTP id f22-20020a170902ab9600b0015901ff4ea0mr779294plr.60.1652373713356; Thu, 12 May 2022 09:41:53 -0700 (PDT) Received: from localhost ([2620:10d:c090:400::4:6c64]) by smtp.gmail.com with ESMTPSA id x4-20020a62fb04000000b0050dc76281a9sm46574pfm.131.2022.05.12.09.41.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 May 2022 09:41:52 -0700 (PDT) Date: Thu, 12 May 2022 06:41:51 -1000 From: Tejun Heo To: Byungchul Park Cc: torvalds@linux-foundation.org, damien.lemoal@opensource.wdc.com, linux-ide@vger.kernel.org, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, peterz@infradead.org, will@kernel.org, tglx@linutronix.de, rostedt@goodmis.org, joel@joelfernandes.org, sashal@kernel.org, daniel.vetter@ffwll.ch, chris@chris-wilson.co.uk, duyuyang@gmail.com, johannes.berg@intel.com, tytso@mit.edu, willy@infradead.org, david@fromorbit.com, amir73il@gmail.com, gregkh@linuxfoundation.org, kernel-team@lge.com, linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@kernel.org, minchan@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com, sj@kernel.org, jglisse@redhat.com, dennis@kernel.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, vbabka@suse.cz, ngupta@vflare.org, linux-block@vger.kernel.org, paolo.valente@linaro.org, josef@toxicpanda.com, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, jack@suse.cz, jack@suse.com, jlayton@kernel.org, dan.j.williams@intel.com, hch@infradead.org, djwong@kernel.org, dri-devel@lists.freedesktop.org, rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com, hamohammed.sa@gmail.com, 42.hyeyoo@gmail.com, mcgrof@kernel.org, holt@sgi.com Subject: Re: [REPORT] syscall reboot + umh + firmware fallback Message-ID: References: <1652354304-17492-1-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1652354304-17492-1-git-send-email-byungchul.park@lge.com> X-Rspamd-Queue-Id: A61F4C00A6 X-Stat-Signature: 5xmom6ftot1e8n3ifq6h3a81h1ub4fwy Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=W0iepvle; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf28.hostedemail.com: domain of htejun@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=htejun@gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1652373693-1978 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote: > > 1. wait_for_completion_killable_timeout() doesn't need someone to wake it up > > to make forward progress because it will unstick itself after timeout > > expires. > > I have a question about this one. Yes, it would never been stuck thanks > to timeout. However, IIUC, timeouts are not supposed to expire in normal > cases. So I thought a timeout expiration means not a normal case so need > to inform it in terms of dependency so as to prevent further expiraton. > That's why I have been trying to track even timeout'ed APIs. > > Do you think DEPT shouldn't track timeout APIs? If I was wrong, I > shouldn't track the timeout APIs any more. Without actually surveying the use cases, I can't say for sure but my experience has been that we often get pretty creative with timeouts and it's something people actively think about and monitor (and it's usually not subtle). Given that, I'm skeptical about how much value it'd add for a dependency checker to warn about timeouts. It might be net negative than the other way around. > > 2. complete_all() from __fw_load_abort() isn't the only source of wakeup. > > The fw loader can be, and mainly should be, woken up by firmware loading > > actually completing instead of being aborted. > > This is the point I'd like to ask. In normal cases, fw_load_done() might > happen, of course, if the loading gets completed. However, I was > wondering if the kernel ensures either fw_load_done() or fw_load_abort() > to be called by *another* context while kernel_halt(). We'll have to walk through the code to tell that. On a cursory look tho, up until that point (just before shutting down usermode helper), I don't see anything which would actively block firmware loading. Thanks. -- tejun