Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5967701ybe; Tue, 10 Sep 2019 11:28:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqwM2uFaMBFuxQhTrn9SxWVolxlhTKR2xhKaeREKJ7FzUuuuqQy/IaSvObuIKFQ/7m6nGEqr X-Received: by 2002:a17:906:fae1:: with SMTP id lu33mr26175892ejb.131.1568140126269; Tue, 10 Sep 2019 11:28:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568140126; cv=none; d=google.com; s=arc-20160816; b=n7NS5xwsbU8v2LDgpePS9dL5hbA7E7harO8FGhysf5gZQWW0s2+mbJeUMHgyf1xz8X ImvokypOyKxvcvju0zPf9+EUgqsQzNsom9p+4Mtzhtv1yRizy8bY+fP7C/tTHtsno+GR cbvko8kNGh69AQkP6/c8nn22LFcQiH2HWhFBi3xMGIMMzVrtGhaAVRfEM2w5KHlknaNX 7GXDILu0UnTX1e4Cfww1zfHCv4obrJKxTtKkUVnj3xrIoliBo6ZGOSlI4wBXSYhu+ieD CQ7KU/v4hLL3Vhp5jvVMGl1YDrC/gHUehOEaLEYj3EYOAsN7RFK7HB2BEyd2OqdyTA0C P5UA== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=JoarQMeFyXmMtY+zu+vqGmLqpiCG3+4ipfsaAN6aDdA=; b=jkasRmYz1N7pgiDcnWu7Maanj0ohFd/2fwkGoCSRuj6bvcHUr7YdG8B/l/zcFcf6WB ar4kn3fcxzMjNIW/Ory2mjb3Inekm5lXs1iTPBuaUwAhuxwpTG/eJ99lBUGd+ta0Dv1P eH4Yst0MZzpsdsXfY/NxujBDnJeiu4TqBFUp26higbFgqeBh+0IwkF+TBM62/hVYW8Ze f9Ck//81Sz03l9tSFwtCgehc0sasq5Vm7aZmXSKsZVkvfpDb2ltiVACkuKIcbT+6mo8S AwWVwQrEczOx2fybW8NjYaGJEG3K9YOIClMBrIAc/xvAkIn5IM0UIEc+6Vd8x8bifC6Z gHQA== 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 e14si10896695edd.417.2019.09.10.11.28.22; Tue, 10 Sep 2019 11:28:46 -0700 (PDT) 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 S1727380AbfIIOy1 (ORCPT + 99 others); Mon, 9 Sep 2019 10:54:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:38570 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726126AbfIIOy1 (ORCPT ); Mon, 9 Sep 2019 10:54:27 -0400 Received: from oasis.local.home (unknown [148.69.85.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EAF2C206CD; Mon, 9 Sep 2019 14:54:25 +0000 (UTC) Date: Mon, 9 Sep 2019 10:54:24 -0400 From: Steven Rostedt To: Changbin Du Cc: Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] ftrace: simplify ftrace hash lookup code Message-ID: <20190909105424.6769b552@oasis.local.home> In-Reply-To: <20190909003159.10574-1-changbin.du@gmail.com> References: <20190909003159.10574-1-changbin.du@gmail.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 9 Sep 2019 08:31:59 +0800 Changbin Du wrote: > Function ftrace_lookup_ip() will check empty hash table. So we don't > need extra check outside. > > Signed-off-by: Changbin Du > > --- > v2: fix incorrect code remove. > --- > kernel/trace/ftrace.c | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index f9821a3374e9..92aab854d3b1 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -1463,8 +1463,7 @@ static bool hash_contains_ip(unsigned long ip, > */ > return (ftrace_hash_empty(hash->filter_hash) || > __ftrace_lookup_ip(hash->filter_hash, ip)) && > - (ftrace_hash_empty(hash->notrace_hash) || > - !__ftrace_lookup_ip(hash->notrace_hash, ip)); > + !ftrace_lookup_ip(hash->notrace_hash, ip); I don't care for this part. I've nacked this change in the past. Why? let's compare the changes: return (ftrace_hash_empty(hash->filter_hash) || __ftrace_lookup_ip(hash->filter_hash, ip)) && (ftrace_hash_empty(hash->notrace_hash) || !__ftrace_lookup_ip(hash->notrace_hash, ip)); vs: return (ftrace_hash_empty(hash->filter_hash) || __ftrace_lookup_ip(hash->filter_hash, ip)) && !ftrace_lookup_ip(hash->notrace_hash, ip); The issue I have with this is that it abstracts out the difference between the filter_hash and the notrace_hash. Sometimes open coded works better if it is compared to something that is similar. The current code I see: Return true if (filter_hash is empty or ip exists in filter_hash and notrace_hash is empty or it does not exist in notrace_hash With your update I see: Return true if filter_hash is empty or ip exists in filter_hash and ip does not exist in notrace_hash It makes it not easy to see if what happens if notrace_hash is empty Hmm, come to think of it, perhaps we should change ftrace_lookup_ip() to include what to do on empty. Maybe: bool ftrace_lookup_ip(struct ftrace_hash *hash, unsigned long ip, bool empty_result) { if (ftrace_hash_empty(hash)) return empty_result; return __ftrace_lookup_ip(hash, ip); } Then we can change the above to: return ftrace_lookup_ip(hash->filter_hash, ip, true) && !ftrace_lookup_ip(hash->notrace_hash, ip, false); That would probably work better. Want to send that update? -- Steve > } > > /* > @@ -6036,11 +6035,7 @@ clear_func_from_hash(struct ftrace_init_func > *func, struct ftrace_hash *hash) { > struct ftrace_func_entry *entry; > > - if (ftrace_hash_empty(hash)) > - return; > - > - entry = __ftrace_lookup_ip(hash, func->ip); > - > + entry = ftrace_lookup_ip(hash, func->ip); > /* > * Do not allow this rec to match again. > * Yeah, it may waste some memory, but will be removed