Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755454Ab3FKQnQ (ORCPT ); Tue, 11 Jun 2013 12:43:16 -0400 Received: from mail-bk0-f53.google.com ([209.85.214.53]:46118 "EHLO mail-bk0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754843Ab3FKQnN (ORCPT ); Tue, 11 Jun 2013 12:43:13 -0400 From: Robert Richter To: Borislav Petkov Cc: Ingo Molnar , Peter Zijlstra , Arnaldo Carvalho de Melo , Jiri Olsa , linux-kernel@vger.kernel.org, Robert Richter , Robert Richter Subject: [PATCH v2 14/14] perf, persistent: Allow multiple users for an event Date: Tue, 11 Jun 2013 18:42:40 +0200 Message-Id: <1370968960-22527-15-git-send-email-rric@kernel.org> X-Mailer: git-send-email 1.8.1.1 In-Reply-To: <1370968960-22527-1-git-send-email-rric@kernel.org> References: <1370968960-22527-1-git-send-email-rric@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3383 Lines: 114 From: Robert Richter Usually a fd close leads to the release of the event too. For persistent events this is different as the events should be permanently enabled in the system. Using reference counting to avoid releasing an event during a fd close. This also allows it to have multiple users (open file descriptors) for a single persistent event. While at this, we don't need desc->fd any longer. The fd is attached to a task and reference counting keeps the event. Removing desc->fd. Signed-off-by: Robert Richter Signed-off-by: Robert Richter --- kernel/events/persistent.c | 46 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c index 8be7c05..dd20b55 100644 --- a/kernel/events/persistent.c +++ b/kernel/events/persistent.c @@ -11,7 +11,6 @@ struct pers_event_desc { struct perf_event *event; struct list_head plist; - int fd; }; struct pers_event { @@ -88,6 +87,18 @@ out: return event; } +static void detach_persistent_event(struct pers_event_desc *desc) +{ + list_del(&desc->plist); + kfree(desc); +} + +static void release_persistent_event(struct perf_event *event) +{ + perf_event_disable(event); + perf_event_release_kernel(event); +} + static void del_persistent_event(int cpu, struct perf_event_attr *attr) { struct pers_event_desc *desc; @@ -100,12 +111,14 @@ static void del_persistent_event(int cpu, struct perf_event_attr *attr) goto out; event = desc->event; - list_del(&desc->plist); - - perf_event_disable(event); - perf_event_release_kernel(event); - put_unused_fd(desc->fd); - kfree(desc); + /* + * We primarily want to remove desc from the list. If there + * are no open files, the refcount is 0 and we need to release + * the event too. + */ + detach_persistent_event(desc); + if (atomic_long_dec_and_test(&event->refcount)) + release_persistent_event(event); out: mutex_unlock(&per_cpu(pers_events_lock, cpu)); } @@ -182,6 +195,7 @@ fail: int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr) { struct pers_event_desc *desc; + struct perf_event *event; int event_fd = -ENODEV; if (cpu >= (unsigned)nr_cpu_ids) @@ -190,13 +204,25 @@ int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr) mutex_lock(&per_cpu(pers_events_lock, cpu)); desc = get_persistent_event(cpu, attr); - if (!desc) + + /* Increment refcount to keep event on put_event() */ + if (!desc || !atomic_long_inc_not_zero(&desc->event->refcount)) goto out; event_fd = anon_inode_getfd("[pers_event]", &perf_fops, desc->event, O_RDONLY); - if (event_fd >= 0) - desc->fd = event_fd; + + if (event_fd < 0) { + event = desc->event; + if (WARN_ON(atomic_long_dec_and_test(&event->refcount))) { + /* + * May not happen since decrementing refcount is + * protected by pers_events_lock. + */ + detach_persistent_event(desc); + release_persistent_event(event); + } + } out: mutex_unlock(&per_cpu(pers_events_lock, cpu)); -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/