Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp612525pxb; Thu, 15 Apr 2021 02:19:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6E70hhocyw/AMvmVeM/lfLp5PRo0FVZ7VMVPLrFLsLFLYfooByJP6ymijojsxGnHrTuSf X-Received: by 2002:a05:6402:4407:: with SMTP id y7mr2932298eda.247.1618478368761; Thu, 15 Apr 2021 02:19:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618478368; cv=none; d=google.com; s=arc-20160816; b=F7dEgQsdO2L5My4GwXKZhk5JqyEduYemOzSVvCupPb7ScWWFg3MrwwPMqnvzAgpa4D /vitIQqtjzLW5IlMIoj4u0xmuvvhfBsor/rsjFl9jtaRp7UvsYrGuVfH9LxPh9Twqfzt I4W04O7HnJ+2SKUG6Ko9Imf7lfb35zt84ronhBNiMoueTRX8AiMNXUSU0hT77ONhbfiX V96KuTPv1V2aGit4x1j/ydhILmrxfzrKqXASgd+5ifH6JHd2qL34HKRwU595o65SbUAE B4lJflbKsIqJ3EzLDvLUZFY1amrXQ6962HPSWmu3JwYSBmo6JeDJu49oqzF7oyY//g/F PK7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:ironport-sdr:ironport-sdr; bh=DpvSv3c1X0tK7oy3Ef8QHDkdQbf+b14BV87a427yqO0=; b=gBkKlQ7K2JSaWgqBG/wiDuZ2ju1/UvzAaxqMsGsGf08zb8EBULxsV055uVMSnvMBxf DJrMlmXTe8/z5vSTs39akB1FCcLUkDoRRuqUzAlI3ChAPMtg9864voWWq/iYcYUoyp9d xEq0y9dcC7Alnpl6zBz1vMZVhCudWIjoYibTcM8sOM4wZ1+MvnnJ+Pf0EuRBwozoU9pq W4kI6iOODt+tc+V3JXfbHnkKDjTRr9Sd12kc69MCOFKcrCCgyBUv8QajEPOpMAFCFNGj 0ZtLaDEI+SSND0vWjSjlHSz76xSifKg6JII/iVPkZIHmhsnlqeFZ78Buy6Jzh0bIMG/A DHcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t1si1644954eju.712.2021.04.15.02.19.05; Thu, 15 Apr 2021 02:19:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232089AbhDOJQW (ORCPT + 99 others); Thu, 15 Apr 2021 05:16:22 -0400 Received: from mga17.intel.com ([192.55.52.151]:46106 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232045AbhDOJQW (ORCPT ); Thu, 15 Apr 2021 05:16:22 -0400 IronPort-SDR: nmxAxwT0SUB9RB4NFRYHGZV0aRUQzvumiiu1EolkW5jPOSG7/HOq/6vAKrM/GRV1+6SXeWPE5N 0M05fj59F74g== X-IronPort-AV: E=McAfee;i="6200,9189,9954"; a="174926267" X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="174926267" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2021 02:15:59 -0700 IronPort-SDR: oQzuUcMoI2vuuTWGgalGtjzFaNKicnORnfko2KcYGHKjpMVSgEiKGP4DuQNd43Ko1WctR9kX+z gtHcrgNmqpvA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,223,1613462400"; d="scan'208";a="461551520" Received: from black.fi.intel.com (HELO black.fi.intel.com.) ([10.237.72.28]) by orsmga001.jf.intel.com with ESMTP; 15 Apr 2021 02:15:57 -0700 From: Alexander Shishkin To: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, Andy Shevchenko , Alexander Shishkin Subject: [PATCH] stm class: Use correct UUID APIs Date: Thu, 15 Apr 2021 12:15:55 +0300 Message-Id: <20210415091555.88085-1-alexander.shishkin@linux.intel.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andy Shevchenko It appears that the STM code didn't manage to accurately decypher the delicate inner workings of an alternative thought process behind the UUID API and directly called generate_random_uuid() that clearly needs to be a static function in lib/uuid.c. At the same time, said STM code is poking directly at the byte array inside the uuid_t when it uses the UUID for its internal purposes. Fix these two transgressions by using intended APIs instead. Signed-off-by: Andy Shevchenko [ash: changed back to uuid_t and updated the commit message] Signed-off-by: Alexander Shishkin --- drivers/hwtracing/stm/p_sys-t.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/stm/p_sys-t.c b/drivers/hwtracing/stm/p_sys-t.c index 360b5c03df95..8254971c02e7 100644 --- a/drivers/hwtracing/stm/p_sys-t.c +++ b/drivers/hwtracing/stm/p_sys-t.c @@ -92,7 +92,7 @@ static void sys_t_policy_node_init(void *priv) { struct sys_t_policy_node *pn = priv; - generate_random_uuid(pn->uuid.b); + uuid_gen(&pn->uuid); } static int sys_t_output_open(void *priv, struct stm_output *output) @@ -292,6 +292,7 @@ static ssize_t sys_t_write(struct stm_data *data, struct stm_output *output, unsigned int m = output->master; const unsigned char nil = 0; u32 header = DATA_HEADER; + u8 uuid[UUID_SIZE]; ssize_t sz; /* We require an existing policy node to proceed */ @@ -322,7 +323,8 @@ static ssize_t sys_t_write(struct stm_data *data, struct stm_output *output, return sz; /* GUID */ - sz = stm_data_write(data, m, c, false, op->node.uuid.b, UUID_SIZE); + export_uuid(uuid, &op->node.uuid); + sz = stm_data_write(data, m, c, false, uuid, sizeof(op->node.uuid)); if (sz <= 0) return sz; -- 2.30.2