Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp276732ybl; Tue, 7 Jan 2020 06:03:55 -0800 (PST) X-Google-Smtp-Source: APXvYqy83ABOSYH8Ld+d7EcYr6uMvU8wWm8kqIkvFVfvB2PZeptdyJzEd0ztaDpjPuCXRPaL02VA X-Received: by 2002:a9d:6ac1:: with SMTP id m1mr109371862otq.101.1578405835230; Tue, 07 Jan 2020 06:03:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578405835; cv=none; d=google.com; s=arc-20160816; b=FDtXayi/z8lJpeoCmxXo4io2VPzHDAbwFQzTHgKGQ82wrYCqhwS+p4Z+Ou2pOE5II3 dbzWqirNFnd+FdEUXrx0MpUL+6mjVYEDU7xfRjnSOYoHvZRq/PdAWQsPteXXfZGnH8HR djUC57hjoUNmvF3tiK3bcHnZTbIl9SWd+7T8Pi/HTrHzwcnkqDEgIkZQ2yn+VcIBCygj MWzuy2AGqhvAc7ylHtFOie0pa5FnPcRCskKmWofFEPLutjv7YPiL+g1X1GC9BERrhpOV f/w/cvm0q87gvRR0VXwplOlYUKII8/radkIKHR04CixTmDEUVfk1AMEWInCbRpFLxFCq O2hQ== 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:cc:from:references:to:subject:dkim-signature; bh=KMSZRJ2KkrIcw9LBhIKUV3xr6gpPQCCmKje4ZsF/tOI=; b=pPF8r/OMQxfiRGYXiS8oyoeMbY9W+QC8PgIpDpacdEZiH4kqYVeOTWSMyXh9ZEMkGE iTx41XjiCXveiRSocZxImPmZSxguuOkJ/gG1CDvPapgBVa3g/T4RO9v1mCuVtIz5cXCn Xjsu+RMX0Au169e75aQ8IEeKQDMvTyKoEVtbDq/rDc9KMyAOkJHPlNeWQO7d3cXukvI0 WAA2123bgRUTyRI8w/Z0+Qlf0xh9oiHuEoBtPiw7PvEQFIPTw3bF6lmgz1CX3Apgpvdo 2G01cWgxNffWdPCqSuPmhwpg5B6RLgQ8epAsZqVnXunqRQ+Mzy9k1HUpzS0Fa8fYIJno sVNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OZa3hb5d; 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=pass (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 j24si35716738otk.76.2020.01.07.06.03.23; Tue, 07 Jan 2020 06:03:55 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OZa3hb5d; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728272AbgAGOCA (ORCPT + 99 others); Tue, 7 Jan 2020 09:02:00 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:47506 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727858AbgAGOB7 (ORCPT ); Tue, 7 Jan 2020 09:01:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578405718; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KMSZRJ2KkrIcw9LBhIKUV3xr6gpPQCCmKje4ZsF/tOI=; b=OZa3hb5dbIT8qyp0tQwuTNlbrgmxaALGzz5pKjTtxi0sPR02/54DgCIrkB/3TaJQpX2u4r NlSYwZ153pdgYPU7waCZHu0SIQL8LwwFiYzWT2mau3/9nNWKmVp70kH3Ak2geXEjPWKJpi wTeexx7/GLOTRtvCnTu9MkDsyMKNwyE= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-155-Y_1qOG1zOraWf08cUilgjw-1; Tue, 07 Jan 2020 09:01:57 -0500 X-MC-Unique: Y_1qOG1zOraWf08cUilgjw-1 Received: by mail-wm1-f71.google.com with SMTP id c4so4135961wmb.8 for ; Tue, 07 Jan 2020 06:01:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KMSZRJ2KkrIcw9LBhIKUV3xr6gpPQCCmKje4ZsF/tOI=; b=AW9zRx6O6/NtJ2hO52aNeFmrKQzJV3xZfW3HLHgyF0fwu3HS/u/tC6slCLd0yu+33Y ObxietCi2mtnqzyexbDiSdQiiACUptGxaqX2Y4Ivu7xf7boBoUWWTCr/iqrhB2mwfLTd Uh76rpzHAMWXA4GEIJuk4gaoL7s83LD9d0qlsCV27cCZohMHbE9iiDRBfJ5tGXePlABu NMv+iJJ3cINb9PwD8NNc49WQmJEDKgCfXDbNPq42qRmCzdpB33b2IwYE8E7TN3QJpFFp on7BZndRtzexLnzBaITSDxXLfhGiyVlVAjZ5s+grhoNycMOu4vozb0WvyiKZkZimpcse VKYA== X-Gm-Message-State: APjAAAV8N/VEExvewki7yEdRA4PRz8jEAVj7vtA3FVxBjQf1vdUJEkvK 4B66VurNYcH70Ch8w6kHbbcoxJFawHjTDk+fZUEVYjnvlxh56BZEGLvTK5lw6XXrHRr/IZvbs+j MBMHmm5EWmPNsCK4L18asmzft X-Received: by 2002:a5d:62c8:: with SMTP id o8mr108263621wrv.316.1578405716542; Tue, 07 Jan 2020 06:01:56 -0800 (PST) X-Received: by 2002:a5d:62c8:: with SMTP id o8mr108263582wrv.316.1578405716256; Tue, 07 Jan 2020 06:01:56 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c6d:4079:b74c:e329? ([2001:b07:6468:f312:c6d:4079:b74c:e329]) by smtp.gmail.com with ESMTPSA id x7sm75775317wrq.41.2020.01.07.06.01.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jan 2020 06:01:55 -0800 (PST) Subject: Re: [PATCH next] KVM: Fix debugfs_simple_attr.cocci warnings To: Chen Wandun , rkrcmar@redhat.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <1577151674-67949-1-git-send-email-chenwandun@huawei.com> From: Paolo Bonzini Cc: Nicolai Stange Message-ID: <4f193d99-ee9b-5217-c2f6-3a8a96bf1534@redhat.com> Date: Tue, 7 Jan 2020 15:01:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <1577151674-67949-1-git-send-email-chenwandun@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/12/19 02:41, Chen Wandun wrote: > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE > for debugfs files. > > Semantic patch information: > Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file() > imposes some significant overhead as compared to > DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe(). > > Signed-off-by: Chen Wandun This patch was sent probably already two or three times, and every time I've not been able to understand what is this significant overhead. With DEFINE_DEBUGFS_ATTRIBUTE: - the fops member is debugfs_open_proxy_file_operations, which calls replace_fops so that the fops->read member is debugfs_attr_read on the opened file - debugfs_attr_read does ret = debugfs_file_get(dentry); if (unlikely(ret)) return ret; ret = simple_attr_read(file, buf, len, ppos); debugfs_file_put(dentry); With DEFINE_SIMPLE_ATTRIBUTE: - the fops member is debugfs_full_proxy_open, and after __full_proxy_fops_init fops->read is initialized to full_proxy_read - full_proxy_read does r = debugfs_file_get(dentry); if (unlikely(r)) return r; real_fops = debugfs_real_fops(filp); r = real_fops->name(args); debugfs_file_put(dentry); return r; where real_fops->name is again just simple_attr_read. So the overhead is really just one kzalloc every time the file is opened. I could just apply the patch, but it wouldn't solve the main issue, which is that there is a function with a scary name ("debugfs_create_file_unsafe") that can be used in very common circumstances (with DEFINE_DEBUGFS_ATTRIBUTE. Therefore, we could instead fix the root cause and avoid using the scary API: - remove from the .cocci patch the change from debugfs_create_file to debugfs_create_file_unsafe. Only switch DEFINE_SIMPLE_ATTRIBUTE to DEFINE_DEBUGFS_ATTRIBUTE - change debugfs_create_file to automatically detect the "easy" case that does not need proxying of fops; something like this: const struct file_operations *proxy_fops; /* * Any struct file_operations defined by means of * DEFINE_DEBUGFS_ATTRIBUTE() is protected against file removals * and thus does not need proxying of read and write fops. */ if (!fops || (fops->llseek == no_llseek && ((!fops->read && !fops->read_iter) || fops->read == debugfs_attr_read) && ((!fops->write && !fops->write_iter) || fops->write == debugfs_attr_write) && !fops->poll && !fops->unlocked_ioctl) return debugfs_create_file_unsafe(name, mode, parent, data, fops); /* These are not supported by __full_proxy_fops_init. */ WARN_ON_ONCE(fops->read_iter || fops->write_iter); return __debugfs_create_file(name, mode, parent, data, &debugfs_full_proxy_file_operations, fops); CCing Nicolai Stange who first introduced debugfs_create_file_unsafe. Thanks, Paolo