Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp52796imm; Tue, 24 Jul 2018 13:51:55 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdlXMSuOtmsZTwk0pzugNW5mnazUo6sYZnWbWr7QR5ANy6ypqY7fP+VfC2ykG7i198HXygh X-Received: by 2002:a62:cc4d:: with SMTP id a74-v6mr19332467pfg.200.1532465515424; Tue, 24 Jul 2018 13:51:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532465515; cv=none; d=google.com; s=arc-20160816; b=sIyN4oIcV+uPGY8ZvsRcvMKEntxdCbDlUpfmmA/lrLt8vSOxq9DnlPAu2AnwLbzvFu 8b0GR/O+GQkvaVo/tqY1rCERUHhjnNZR5LnQs8ifLS/Uh12NSdjg5vgnLkIBZhd84pVu C+ohcULw/n3AMJFOiqvE3HXSilEApIexOP1+lEe9eG7IRBx7guY9I5AAkLaepWQgHW8U QLk3qXXOKdTCmFrc7amggBJVjQAYiGozcx5BI2mVNqKb7VjJxKrY9BBv0suSM+DQ6mBo UviruODYRG3iR8UE6uby9dZrLww7tp3XvneMZK7aR5Byvp6cNeD6Pp7FCU7znWzv4fgf 1mQw== 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 :arc-authentication-results; bh=cwF+qbDHnYTV7Sh9fvLsur8Ro8N41hQDnP3qllEw3R8=; b=xzb+oZd81qy4se1sxO471oPKbXZy3lgFx0vpdtzi56a1pAmzfQsTwx0G5bPuhFT8HY JHmN+ewsvtIuvgzQez2Lj4raSqaKliNHeX891VLsI4SqFi0kansfq1TjydZge9GTdPn1 ns4PyjYwss7XjdhI9n0/uK+erAxCAGZWhEN5o4yMiEslQkghkm10nZfMarGpfsX438Qo k2+gy3TxQAbJQGocbAHLbw9Aoj8M7dM7QlXPUacQqaO3QiyA9ytjk6Kqx6SkR4aqDRFM paqI1EA5lIcMvXg0kI4Bv1qasKmXSF08Mmu4zH1ASJsFBTTJ0dc1ItPlsEkxYZHQmLpk urZg== 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 g1-v6si11299682pld.11.2018.07.24.13.51.40; Tue, 24 Jul 2018 13:51:55 -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 S2388889AbeGXV6R (ORCPT + 99 others); Tue, 24 Jul 2018 17:58:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:52892 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388812AbeGXV6R (ORCPT ); Tue, 24 Jul 2018 17:58:17 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (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 1EC5620856; Tue, 24 Jul 2018 20:50:01 +0000 (UTC) Date: Tue, 24 Jul 2018 16:49:59 -0400 From: Steven Rostedt To: Masami Hiramatsu Cc: Ingo Molnar , Shuah Khan , Tom Zanussi , Hiraku Toyooka , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/3] [BUGFIX] tracing: Fix double free of event_trigger_data Message-ID: <20180724164959.3cbc1422@gandalf.local.home> In-Reply-To: <20180725000909.6c8b2f3881ee75c4f6bd466b@kernel.org> References: <153149923649.11274.14970833360963898112.stgit@devbox> <153149926702.11274.12489440326560729788.stgit@devbox> <20180723221006.60cc7aa9@vmware.local.home> <20180725000909.6c8b2f3881ee75c4f6bd466b@kernel.org> X-Mailer: Claws Mail 3.16.0 (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 Wed, 25 Jul 2018 00:09:09 +0900 Masami Hiramatsu wrote: > Hmm, your patch seems to leak a memory since event_trigger_init() will > be called twice on same trigger_data (Note that event_trigger_init() > does not init ref counter, but increment it.) So we should decrement > it when we find it is succeeded. Moreover, if register_trigger() Good catch, and easily fixed. > fails before calling data->ops->init() (see -EEXIST case), the ref > counter will be 0 (-1 +1). But if it fails after data->ops->init(), > the ref counter will be 1 (-1 +1 +1). It still be unstable. > (Ah, that means we may have another trouble...) I'm not sure there's a problem here. I now have: out_reg: /* Up the trigger_data count to make sure reg doesn't free it on failuer */ event_trigger_init(trigger_ops, trigger_data); ret = cmd_ops->reg(glob, trigger_ops, trigger_data, file); /* * The above returns on success the # of functions enabled, * but if it didn't find any functions it returns zero. * Consider no functions a failure too. */ if (!ret) { ret = -ENOENT; } else if (ret > 0) ret = 0; /* Down the counter of trigger_data or free it if not used anymore */ event_trigger_free(trigger_ops, trigger_data); out: return ret; Thus we increment trigger_data before calling reg, and free it afterward. But if reg() did an init too, then the event_trigger_free() just decs the ref counter. As for register_trigger() > > > > > P.S. This brings up another minor bug. The failure should return ENOMEM > > not ENOENT. > > Hmm it seems we should review the register_trigger() implementation. > It should return the return value of trace_event_trigger_enable_disable(), > shouldn't it? > Yeah, that's not done well. I'll fix it up. Thanks for pointing it out. -- Steve