From: sashiko-bot@kernel.org
To: "Baolin Liu" <liubaolin12138@163.com>
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v4 6/7] ntfs3: add iomap tracepoints
Date: Thu, 20 Aug 2026 09:19:40 +0000 [thread overview]
Message-ID: <20260820091941.3ABC11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820090504.950475-7-liubaolin12138@163.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Data truncation of 64-bit inode number to 32-bit unsigned long in trace events on 32-bit architectures.
--
--- Patch [6]: [PATCH v4 6/7] ntfs3: add iomap tracepoints ---
commit 6e265a35dba7936f19ebddff3d05806b6ce60f0a
Author: Baolin Liu <liubaolin@kylinos.cn>
ntfs3: add iomap tracepoints
This commit adds trace events for ntfs_iomap_begin() and ntfs_iomap_end()
to help observe iomap mapping activity.
> diff --git a/include/trace/events/ntfs3.h b/include/trace/events/ntfs3.h
> index e39765bc062f1..e0c0c44ce318f 100644
> --- a/include/trace/events/ntfs3.h
> +++ b/include/trace/events/ntfs3.h
[ ... ]
> +TRACE_EVENT(ntfs3_iomap_begin,
> + TP_PROTO(struct inode *inode, loff_t offset, loff_t length,
> + unsigned int flags),
> + TP_ARGS(inode, offset, length, flags),
> + TP_STRUCT__entry(
> + __field(unsigned long, ino)
[Severity: Low]
Is unsigned long wide enough for the inode number here? In struct inode,
i_ino is defined as a u64. On 32-bit architectures, won't assigning
inode->i_ino to an unsigned long silently truncate high inode numbers?
Could this be changed to use u64 instead?
> + __field(loff_t, offset)
> + __field(loff_t, length)
> + __field(dev_t, dev)
> + __field(unsigned int, flags)
> + ),
> + TP_fast_assign(
> + __entry->ino = inode->i_ino;
[ ... ]
> +TRACE_EVENT(ntfs3_iomap_end,
> + TP_PROTO(struct inode *inode, loff_t pos, loff_t length,
> + ssize_t written, unsigned int flags),
> + TP_ARGS(inode, pos, length, written, flags),
> + TP_STRUCT__entry(
> + __field(unsigned long, ino)
[Severity: Low]
Does this field also risk truncating the u64 inode->i_ino when running on
32-bit architectures?
> + __field(loff_t, pos)
> + __field(loff_t, length)
> + __field(ssize_t, written)
> + __field(dev_t, dev)
> + __field(unsigned int, flags)
> + ),
> + TP_fast_assign(
> + __entry->ino = inode->i_ino;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260820090504.950475-1-liubaolin12138@163.com?part=6
next prev parent reply other threads:[~2026-08-20 9:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 9:04 [PATCH v4 0/7] ntfs3: add tracepoints for core filesystem paths Baolin Liu
2026-08-20 9:04 ` [PATCH v4 1/7] ntfs3: add mount and log replay tracepoints Baolin Liu
2026-08-20 9:04 ` [PATCH v4 2/7] ntfs3: add namei tracepoints Baolin Liu
2026-08-20 9:05 ` [PATCH v4 3/7] ntfs3: add create inode tracepoint Baolin Liu
2026-08-20 9:05 ` [PATCH v4 4/7] ntfs3: add directory index tracepoints Baolin Liu
2026-08-20 9:17 ` sashiko-bot
2026-08-20 9:05 ` [PATCH v4 5/7] ntfs3: add allocation tracepoints Baolin Liu
2026-08-20 9:05 ` [PATCH v4 6/7] ntfs3: add iomap tracepoints Baolin Liu
2026-08-20 9:19 ` sashiko-bot [this message]
2026-08-20 9:05 ` [PATCH v4 7/7] ntfs3: add file I/O tracepoints Baolin Liu
2026-08-20 9:19 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260820091941.3ABC11F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=liubaolin12138@163.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox