Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2422859pxy; Tue, 3 Aug 2021 06:14:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvTjGDUlGX58C0/IarISOA1LMrA79W/sQbWTOzPtA5xcWG+fmsdJ/o9HfSeXuKyDkG8mbB X-Received: by 2002:a05:6602:1790:: with SMTP id y16mr1911560iox.12.1627996497505; Tue, 03 Aug 2021 06:14:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627996497; cv=none; d=google.com; s=arc-20160816; b=Va75o81afIhoBs51jbtPN420YumI7AXRf9eYhpvXywqmHMRisqaKPh0n8ig6uawRon Xc1XUcUQhFb5eu7jvqcrBHkFwgry78ioXUqyY/W5IOsPd1b79mVMTCmNevnBnONEWX80 9Cq9MIPb9LQ142LyL+hYyZASAFQjYGj5Z2H0AUIfkzNRVjxlGkbPhKGXxKHbIEmArxWK SvH8oppF87rqAZWq+soBDtF5T5Wc9Na4rPQxDCw0W9t9BAkHjKTKcCBHLNsCTij/iXn5 L6zpeKo2hrnRIfSrbr4lLDx2Wh4yrZQIcKIy9YkFK4pA3b07Uk9HJeG4maAgdf8jSOSA Ji3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9T9HXQ3PgN3jaVxZADVdmQ4EnjWr32CrawQXNS+6Mm4=; b=gnNl7NwLJR1yq57PUrO+Pd8ZWf6s6TsHneGb+f+EOFkTHIwFiuSZqFyXXA6XGojlli d8FXe0IaZ7onkUcj/4L/asDRS4CSIj80q4vYl12jwfl4cxOLE3Us1PA2ltw0blyRP5PC 6gHAusZnqQ8H4KEKQ86k7rNYmD7+FqwkoocWzhqQfVhacvSoviyxDwzUNL7L1iv2UmoA HdHr6VOFxTqeq1EZSR3o9cq+7qPnc+d+6kVfo9aFB1XeyWUdDVi6g/rhr2RHraBL/z6h zphdr+d9H53KTRav6ELv5G+zvmJfMpyKuP9deejbflMAYpaSpBOEZtb8R1NsU132TwzE 31mQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sQCZPKuo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k14si15128215ion.22.2021.08.03.06.14.45; Tue, 03 Aug 2021 06:14:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sQCZPKuo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236417AbhHCNMV (ORCPT + 99 others); Tue, 3 Aug 2021 09:12:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:33300 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236351AbhHCNME (ORCPT ); Tue, 3 Aug 2021 09:12:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 607A360F8F; Tue, 3 Aug 2021 13:11:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1627996313; bh=G9QZGioog0e7pS11z7Di9y9T7Cul6LuoangPMjmp7do=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sQCZPKuox08viEWmQ1Vwdngj3jDYEtbBL3Z9zsohNDjLiqS1XGHC3OPoIDWEJzKDE ncOVT/DxqvlWY5abrYUO9v9/4XOJOaVaRJ0eVngCzWjg9f/cwgFCJbAlbpyENrNDRu heB9jxxVK0kD3RAAb5EqjdYJOMyc8DMQdf/Ap8rk= Date: Tue, 3 Aug 2021 15:11:51 +0200 From: Greg KH To: Paolo Bonzini Cc: Alexey Kardashevskiy , "Kernel Mailing List, Linux" , kvm Subject: Re: [RFC PATCH kernel] KVM: Stop leaking memory in debugfs Message-ID: References: <20210730043217.953384-1-aik@ozlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 03, 2021 at 02:52:17PM +0200, Paolo Bonzini wrote: > On Tue, Aug 3, 2021 at 1:16 PM Greg KH wrote: > > On Fri, Jul 30, 2021 at 02:32:17PM +1000, Alexey Kardashevskiy wrote: > > > snprintf(dir_name, sizeof(dir_name), "%d-%d", task_pid_nr(current), fd); > > > kvm->debugfs_dentry = debugfs_create_dir(dir_name, kvm_debugfs_dir); > > > + if (IS_ERR_OR_NULL(kvm->debugfs_dentry)) { > > > + pr_err("Failed to create %s\n", dir_name); > > > + return 0; > > > + } > > > > It should not matter if you fail a debugfs call at all. > > > > If there is a larger race at work here, please fix that root cause, do > > not paper over it by attempting to have debugfs catch the issue for you. > > I don't think it's a race, it's really just a bug that is intrinsic in how > the debugfs files are named. You can just do something like this: > > #include > #include > #include > #include > #include > #include > #include > int main() { > int kvmfd = open("/dev/kvm", O_RDONLY); > int fd = ioctl(kvmfd, KVM_CREATE_VM, 0); > if (fork() == 0) { > printf("before: %d\n", fd); > sleep(2); > } else { > close(fd); > sleep(1); > int fd = ioctl(kvmfd, KVM_CREATE_VM, 0); > printf("after: %d\n", fd); > wait(NULL); > } > } > > So Alexey's patch is okay and I've queued it, though with pr_warn_ratelimited > instead of pr_err. So userspace can create kvm resources with duplicate names? That feels wrong to me. But if all that is "duplicate" is the debugfs kvm directory, why not ask debugfs if it is already present before trying to create it again? That way you will not have debugfs complain about duplicate files/directories. thanks, greg k-h