From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04DC4C43334 for ; Wed, 6 Jul 2022 16:18:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232606AbiGFQSk (ORCPT ); Wed, 6 Jul 2022 12:18:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234053AbiGFQSb (ORCPT ); Wed, 6 Jul 2022 12:18:31 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADBD8DFE1 for ; Wed, 6 Jul 2022 09:18:29 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 7E1AB68B05; Wed, 6 Jul 2022 18:18:25 +0200 (CEST) Date: Wed, 6 Jul 2022 18:18:25 +0200 From: Christoph Hellwig To: Keith Busch Cc: John Garry , axboe@fb.com, hch@lst.de, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme: Fix nvme_setup_command metadata trace event for cdw10 Message-ID: <20220706161825.GA1962@lst.de> References: <1657095398-114310-1-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 06, 2022 at 10:13:22AM -0600, Keith Busch wrote: > Did you test what the trace looks like afte this? We're losing valuable trace > data here. The field is supposed to get CDW's 10 - 15, so that's 24 bytes. I > don't know why it cares that the address of the field being read is only 4 > bytes; we want everything that comes after it too. Because accesses should not spawn boundaries of members in structs unless copying the entire struct. If we want to trace the various fields we need to individually assign them. Anyway, I'm dropping this patch from nvme-5.19 for now to let the discussion conclude.