Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4519216ybf; Wed, 4 Mar 2020 05:38:17 -0800 (PST) X-Google-Smtp-Source: ADFU+vu9X8T5nwJl44vHL9iAmpiNTdaKTq1f03I9ahM+i9sW5Bq2Wil+3/BYRPLwo3z4x/k+cJhG X-Received: by 2002:a05:6830:57:: with SMTP id d23mr2362111otp.224.1583329097521; Wed, 04 Mar 2020 05:38:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583329097; cv=none; d=google.com; s=arc-20160816; b=QDTraGC3GgF+PLbiHbJTvqI0HvsEl7DU5R3NchIM8DUkJct9cdHCxMrYlzB+2kCZVh 5RJAbKT6iSutH96i3lXJl073Pw2IB5PGRTdIm5przZGq7WfdtAsaUiuHo84mDny98arS 99/FJr3i35VrEnv2RkF4Jl1YipQei1+7I2BiE5DnBthl5Ljgcfi86Bqenz09WY+6v7Kx yMtJLvwbHcQuQBd95XRaf23PjLdC8OKWrcHn0XtJKWfAZYIX9uUvv4tY6HIVIILnD3jp qrJ+6pG5O9kqIC49O6AFhAPAZyFBEeJzXgDkjhKgmnrKRcKfkcUfcYhaU2ApXtemWEjL V36g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dcwWwR1DoLZF4l0dUEZFH0CZvetxwjzkUKcn+Z8FXmE=; b=dGoBMD/vHCQiSOGXOnVGlmsyXGcD3OXU4pFwBHRBEmV2o1N8euUIB5isGQomkBiu9Y WohVgsqCYLpFYIBH19P4YoZeAKZeErZT/FBcq75CV04xDrNvbXeWY7dmQs1cu6b9NYDB 5X2Z62JqyqXtmi3rBJgnTc6Io8E1VoBXghpUZGZzgVionZleOz5fW7gp1Bk1ERZdfwhX KJLmDpUtit7xWlNxuJeWvox6Dpu2vNfd40/Q7uufx/BkY3wHh3kQslUUdLlPuKZKdxN7 2FN5+5VjjrdYUUOSTmRmQ0Nya+3FxMi1d7K3FR6GJoPaU44rnR61SXijnEoAcLN1qmKg l7jw== 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 f204si1286278oib.16.2020.03.04.05.38.05; Wed, 04 Mar 2020 05:38:17 -0800 (PST) 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 S1729513AbgCDNho (ORCPT + 99 others); Wed, 4 Mar 2020 08:37:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:59622 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729461AbgCDNhn (ORCPT ); Wed, 4 Mar 2020 08:37:43 -0500 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 D9E02B12A; Wed, 4 Mar 2020 13:37:40 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id B36D61E0E99; Wed, 4 Mar 2020 14:37:38 +0100 (CET) Date: Wed, 4 Mar 2020 14:37:38 +0100 From: Jan Kara To: He Zhe Cc: Christoph Hellwig , jack@suse.cz, Jens Axboe , viro@zeniv.linux.org.uk, bvanassche@acm.org, keith.busch@intel.com, tglx@linutronix.de, mwilck@suse.com, yuyufen@huawei.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: disk revalidation updates and OOM Message-ID: <20200304133738.GF21048@quack2.suse.cz> References: <93b395e6-5c3f-0157-9572-af0f9094dbd7@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93b395e6-5c3f-0157-9572-af0f9094dbd7@windriver.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! On Mon 02-03-20 11:55:44, He Zhe wrote: > Since the following commit > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-5.5/disk-revalidate&id=6917d0689993f46d97d40dd66c601d0fd5b1dbdd > until now(v5.6-rc4), > > If we start udisksd service of systemd(v244), systemd-udevd will scan > /dev/hdc (the cdrom device created by default in qemu(v4.2.0)). > systemd-udevd will endlessly run and cause OOM. Thanks for report! The commit you mention has this: There is a small behavior change in that we now send the kevent change notice also if we were not invalidating but no partitions were found, which seems like the right thing to do. And apparently this confuses systemd-udevd because it tries to open /dev/hdc in response to KOBJ_CHANGE event on that device and the open calls rescan_partitions() which generates another KOBJ_CHANGE event. So I'm afraid we'll have to revert to the old behavior of not sending KOBJ_CHANGE event when there are no partitions found. Christoph? Honza -- Jan Kara SUSE Labs, CR