* Re: [PATCH] fs: report direct io constraints through file_getattr
From: Christoph Hellwig @ 2026-07-10 4:35 UTC (permalink / raw)
To: Keith Busch
Cc: Christoph Hellwig, Keith Busch, linux-block, linux-ext4,
linux-f2fs-devel, linux-fsdevel, linux-xfs, axboe, jack, brauner,
cem, jaegeuk, aalbersh, tytso
In-Reply-To: <ak-mQqt-a-jy6ZoV@kbusch-mbp>
On Thu, Jul 09, 2026 at 07:46:42AM -0600, Keith Busch wrote:
> On Thu, Jul 09, 2026 at 09:13:52AM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 07, 2026 at 06:18:43PM -0700, Keith Busch wrote:
> >
> > > + fa->fsx_dio_mem_align = bdev_dma_alignment(bdev) + 1;
> > > + fa->fsx_dio_offset_align = bdev_logical_block_size(bdev);
> > > + fa->fsx_dio_read_offset_align = bdev_logical_block_size(bdev);
> > > + fa->fsx_dio_virt_boundary_align = bdev_virt_boundary_alignment(bdev);
> > > + fa->fsx_max_segments = bdev_max_segments(bdev);
> >
> > How is the max_segments value defined in a way that is meaningful to
> > userspace?
>
> It tells you how many sub-sector vectors you can submit in your
> readv/writev before it needs to add up to a logical block size.
>
> Ex: 4k logical block size, 4 byte DMA, 256 max segments. You can define
> 4-byte iov's in your command, but you'll hit the max segment count
> before you have a valid IO if they're all that small.
Ah, makes sense. But besides the missing documentation I think
max_segments is a bit of a misleading name for that.
Something like max_vecs_per_block (although we don't expose blocks
in the UAPI) or max_vecs_per_granularity (I think grammar wants a word
with me for that, though...) might be a bit more suitable.
> > > @@ -145,6 +155,8 @@ static int file_attr_to_fileattr(const struct file_attr *fattr,
> > >
> > > if (fattr->fa_xflags & ~mask)
> > > return -EINVAL;
> > > + if (fattr->fa_pad)
> > > + return -EINVAL;
> >
> > How is this related?
>
> I had to add a padding field to the struct to account for the implicit
> hole in 64-bit and to ensure the struct is the same size for 32-bit.
> It's a reserved field, so we have to ensure the current kernel doesn't
> support any value here in case we define this field for something else
> in the future.
Ah, right.
^ permalink raw reply
* Re: [PATCH v19 31/40] dept: assign unique dept_key to each distinct wait_for_completion() caller
From: Byungchul Park @ 2026-07-10 5:53 UTC (permalink / raw)
To: Gary Guo
Cc: linux-kernel, max.byungchul.park, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, bjorn3_gh,
lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <DJSEK3KA2ECQ.1512A4KGOBSCV@garyguo.net>
On Tue, Jul 07, 2026 at 03:18:29PM +0100, Gary Guo wrote:
> On Mon Jul 6, 2026 at 7:19 AM BST, Byungchul Park wrote:
> > wait_for_completion() can be used at various points in the code and it's
> > very hard to distinguish wait_for_completion()s between different usages.
> > Using a single dept_key for all the wait_for_completion()s could trigger
> > false positive reports.
> >
> > Assign unique dept_key to each distinct wait_for_completion() caller to
> > avoid false positive reports.
> >
> > While at it, add a rust helper for wait_for_completion() to avoid build
> > errors.
>
> This will cause Rust code to share the same dept_key, so it will have all the
> false positives that the change is trying to avoid.
Thank you for the input.
> In general it is easy to create Rust bindings for static inline C functions
> because it'll be just some computation, while creating bindings for C
> function-like macros that define additional statics can be challenging.
>
> Is dept_key similar to lock_class_key, where only the address matters? If so,
> the approach that I use in
> https://lore.kernel.org/rust-for-linux/DJP0CDOR98N5.29BK8PUFRWRUK@garyguo.net
Yes, dept_key is similar to lock_class_key. IIUC, the way you tried for
lock_class_key can be applied to DEPT too. I will do:
1) add 'key' parameter to sdt_might_sleep_start_timeout()
2) introduce init_completion_dkey() to allow custom keys
3) remove init_completion_dmap() and adjust the existing users
Just in case, it's worth noting that the custom keys must be
well-managed using e.g. dept_key_destroy() when the key gets freed.
Byungchul
> could be used for dept_key as well, then we can keep Rust `wait_for_completion`
> still a function; otherwise we have to turn it into a macro too on the Rust side
> to create such statics, which isn't ideal.
>
> Best,
> Gary
>
> >
> > Signed-off-by: Byungchul Park <byungchul@sk.com>
> > ---
> > include/linux/completion.h | 100 +++++++++++++++++++++++++++++++------
> > kernel/sched/completion.c | 60 +++++++++++-----------
> > rust/helpers/completion.c | 5 ++
> > 3 files changed, 120 insertions(+), 45 deletions(-)
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox