In the hypothetical case where a CMN event is opened with a software
group leader that already has some other hardware sibling, currently
arm_cmn_val_add_event() could try to interpret the other event's data
as an arm_cmn_hw_event, which is not great since we dereference a
pointer from there... Thankfully the way to be more robust is to be
less clever - stop trying to special-case software events and simply
skip any event that isn't for our PMU.
Signed-off-by: Robin Murphy <robin.mur...@arm.com>
---
drivers/perf/arm-cmn.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 11fb2234b10f..f8c9be9fa6c0 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -1652,7 +1652,7 @@ static void arm_cmn_val_add_event(struct arm_cmn *cmn,
struct arm_cmn_val *val,
enum cmn_node_type type;
int i;
- if (is_software_event(event))
+ if (event->pmu != &cmn->pmu)
return;
type = CMN_EVENT_TYPE(event);
@@ -1693,9 +1693,6 @@ static int arm_cmn_validate_group(struct arm_cmn *cmn,
struct perf_event *event)
if (leader == event)
return 0;
- if (event->pmu != leader->pmu && !is_software_event(leader))
- return -EINVAL;
-
val = kzalloc(sizeof(*val), GFP_KERNEL);
if (!val)
return -ENOMEM;
--
2.39.2.101.g768bb238c484.dirty
