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 8C26BD58D50 for ; Mon, 25 Nov 2024 14:42:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 091B46B0083; Mon, 25 Nov 2024 09:42:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 01A546B0088; Mon, 25 Nov 2024 09:42:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD6176B0089; Mon, 25 Nov 2024 09:42:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BC1F86B0083 for ; Mon, 25 Nov 2024 09:42:02 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3B7351C7111 for ; Mon, 25 Nov 2024 14:42:02 +0000 (UTC) X-FDA: 82824881958.12.C15F8E2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id C5152A0004 for ; Mon, 25 Nov 2024 14:41:57 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gxPMeu9P; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732545717; a=rsa-sha256; cv=none; b=fA3i4uL6t8/jj7raVJlgXAHMX8wOMO5xdDWyxTJ4VuJScv6UqIcB2KXiJ+jgeydL0H9+w6 I4PldKKBFAOWxyqHO2IXmFeCAcWNuQV3/4awSdlSMC+BMsiGzeCawEzWJk1q6bHUzyh0Km oa37yhUGjsacyVK9DfToCd5uGLSNoq0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gxPMeu9P; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf25.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732545717; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=46wCtS3Eh2MWHiDHvSqDOE0J1G+zlgwVIrX5wgmHpV8=; b=u/fyQeG2j3Tn+3Z0P6dsxcn8PHITiPsT1qHb2Pb0tIApOuzYoxgoew75RKVV+TrsYLmm9Z BZb9Oj6zApoApZY6QDG9A9lwyYpeMf6Rl484lqr7/LAuWgMcv4IUADiTiuO0vE9eTNkOj8 TNsx8Whf+tvxAEJgn6IdhvpVxSc6Y7E= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732545719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=46wCtS3Eh2MWHiDHvSqDOE0J1G+zlgwVIrX5wgmHpV8=; b=gxPMeu9PHHjx6Oyw0VNLauLKzVKRu1D9xMcMQwofSnaL8kP9FkK6M8j+uTAMuCt9Z3AkpA ho14xvXB/ZfQAoJnlcha+8azbdAvhKambU7YABobi0QP1WpVhmwcmz3ZozrdOoYMoh33v1 5D47O7PspPaBzeH6NQABUnBAULsRGDE= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-527-bEyv-BAOPx6TDm6pRFxqBA-1; Mon, 25 Nov 2024 09:41:55 -0500 X-MC-Unique: bEyv-BAOPx6TDm6pRFxqBA-1 X-Mimecast-MFC-AGG-ID: bEyv-BAOPx6TDm6pRFxqBA Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6BFA41954B0A; Mon, 25 Nov 2024 14:41:52 +0000 (UTC) Received: from localhost (unknown [10.72.113.10]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 28945195E483; Mon, 25 Nov 2024 14:41:50 +0000 (UTC) Date: Mon, 25 Nov 2024 22:41:45 +0800 From: Baoquan He To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org, Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Vivek Goyal , Dave Young , Thomas Huth , Cornelia Huck , Janosch Frank , Claudio Imbrenda , Eric Farman , Andrew Morton Subject: Re: [PATCH v1 03/11] fs/proc/vmcore: disallow vmcore modifications after the vmcore was opened Message-ID: References: <20241025151134.1275575-1-david@redhat.com> <20241025151134.1275575-4-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Stat-Signature: jh9n3ksq8cpo3on5xqcn4sxbs96tykqi X-Rspamd-Queue-Id: C5152A0004 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732545717-248229 X-HE-Meta: U2FsdGVkX183pOQwYdVm2G2jt5Y+3YGAL7R3hYGtIRSDi9qf9jexsyJcmtzhTggStc49kTeyj5BUuaKgBkRdNJ4WC0oGHWbcuikK0Rozrg8u4LPFiL8Iz0+oNP6tqvmXFIaxt818BmnVhEqXKll5rbkyfLHN5RX7A8hwDjX93fbfPFmx389+03ee7LHhC8qjr6FmHW6JviUG5KHkjF/bJ6c3t3D7TNfpZsOTyjcvhyOCIHbHEoRXLS/8o6a9ttxVotelF686QPa+MMz342Lz3dnA+eSZ6nuKewmWNKAGyOEE8s9daZ5uy4+C+mwP8vBnZPu3CFAJi9MyMxi85kEM0tcCuTBoAMG0M1RBQw5Zr0EI6biEmptX8h+OsjAygriVJABkm2pvCpmcnimwSBSLKARB2liHIRIpngkFktVqDzxTqPnhdUSyNcyXRO2Xsi7kQZPGaxtjK0W6JCf3Hyy5r4rRMBi7iwEsN5iMi47jCcSh6immD70NhXw9/t+9ZrlJdGa0o0oU+iGdyGTS3FiL4aObkcUJu1pCAz0sJFQqbTJG1nxEmGJ+dYJkUBciZnWrVS3+KxCTJEoL+X+Xhk8M95Ddsk8nnzBUiWA/Xo4RSEnsMg+bDUJhltC/JijdMgwKIon0srV/92K0b83mRy0ByliYOfa0DI5KU+PkL7BDOnVu9KwxZx5hY61537XtlKQP3nwDcF3FG49CYrshg7iZZQA5zfWf/5ptfDN+v3a0V4ipIkrmFOAj8dagnGB3IBOQ8f0hYIEJj3Gk7RUc/VaEYH87rXRw8Rob+Vv4I/MyfeNgCNBAgbTJXDNQx0qHKDL5nGp37xR0pYalLxZyGI8Jhg/6LbwU0Ipyn4UXDYLgyY0IuyBazcgG3w0sDNz6jSAjOlchR/PKZerBBMKlsiRIU88+M/Qb5fLuqpXlSj27XZfk6i81L0sCz0XuPOQgAyv4CuD3RAijqbVRwF9LoVJ q2Rb2nvc ab8nRejNLZpjpsFiQJBQlHNO7BfHGzBF16NBTmSC9baFMdFk6arB6E70JZUcCB+IctTnWTIRoMgzkdTDu1XlTeEPpgZIXJJRIgoBKtl0VuiZkU8kPS8wVUr2/P1U8tuLvGfP28Aa5PFu5LfTaQOoWvFFIx7J9U55jXfWqOaOQZDPykqA97O4oPsb+/t4hbOHp98URHokBUFLP6U+QrXnMLKMBCSxZljWbPVA4TiGDI9aMywDrYsjrOGzeXeXmxsMm+Xw4xDXpK4Hq+oQBzMckfKxQSG3qsNceK8uWyGOw75OXAoQNVs/wG8HsQSxIOJg3+aHmAA0oAuM8UxK+WP2ErRgOnEYSQpiERVR4 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: List-Subscribe: List-Unsubscribe: On 11/22/24 at 10:30am, David Hildenbrand wrote: > On 22.11.24 10:16, Baoquan He wrote: > > On 10/25/24 at 05:11pm, David Hildenbrand wrote: > > ......snip... > > > @@ -1482,6 +1470,10 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) > > > return -EINVAL; > > > } > > > + /* We'll recheck under lock later. */ > > > + if (data_race(vmcore_opened)) > > > + return -EBUSY; > > > > Hi, > > > As I commented to patch 7, if vmcore is opened and closed after > > checking, do we need to give up any chance to add device dumping > > as below? > > > > fd = open(/proc/vmcore); > > ...do checking; > > close(fd); > > > > quit any device dump adding; > > > > run makedumpfile on s390; > > ->fd = open(/proc/vmcore); > > -> try to dump; > > ->close(fd); > > The only reasonable case where this could happen (with virtio_mem) would be > when you hotplug a virtio-mem device into a VM that is currently in the > kdump kernel. However, in this case, the device would not provide any memory > we want to dump: > > (1) The memory was not available to the 1st (crashed) kernel, because > the device got hotplugged later. > (2) Hotplugged virtio-mem devices show up with "no plugged memory", > meaning there wouldn't be even something to dump. > > Drivers will be loaded (as part of the kernel or as part of the initrd) > before any kdump action is happening. Similarly, just imagine your NIC > driver not being loaded when you start dumping to a network share ... > > This should similarly apply to vmcoredd providers. > > There is another concern I had at some point with changing the effective > /proc/vmcore size after someone already opened it, and might assume the size > will stay unmodified (IOW, the file was completely static before vmcoredd > showed up). > > So unless there is a real use case that requires tracking whether the file > is no longer open, to support modifying the vmcore afterwards, we should > keep it simple. > > I am not aware of any such cases, and my experiments with virtio_mem showed > that the driver get loaded extremely early from the initrd, compared to when > we actually start messing with /proc/vmcore from user space. Hmm, thanks for sharing your thoughts. I personally think if we could, we had better make code as robust as possible. Here, since we have already integrated the lock with one vmcore_mutex, whether the vmcoredd is added before or after /proc/vmcore opening/closing, it won't harm. The benefit is it works well with the current kwown case, virtio-mem probing, makedumpfile running. And it also works well with other possible cases, e.g if you doubt virtio-mem dumping and want to debug, you set rd.break or take any way to drop into emengency shell of kdump kernel, you can play it to poke virtio-mem module again and run makedumpfile manually or reversing the order or taking any testing. Then kernel implementation should not preset that user space have to run the makedumpfile after the much earlier virtio-mem probing. If we implement codes according to preset userspace scenario, that limit the future adapttion, IMHO.