linux-kernel - Re: [PATCH v2] Support for write stream IDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 05 May 2015 18:09:18 -0400
From:	"Martin K. Petersen" <martin.petersen@...cle.com>
To:	Jens Axboe <axboe@...com>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Jeff Moyer <jmoyer@...hat.com>, <linux-kernel@...r.kernel.org>,
	<linux-fsdevel@...r.kernel.org>, <adilger@...ger.ca>,
	<david@...morbit.com>
Subject: Re: [PATCH v2] Support for write stream IDs

>>>>> "Jens" == Jens Axboe <axboe@...com> writes:

Jens> I'm not trying to make a shortcut. I deliberately do not want to
Jens> make ID generation/assignment part of the kernel. There's no
Jens> reason that can't exist outside of the kernel, in a libstreamid or
Jens> similar.

That just perpetuates the broken model, though. Why wouldn't we want to
have stream ids readily available inside the kernel to tag journals,
filesystem metadata, data migration, who knows what?

Having storage micromanage the stream IDs is a non-starter. And it'll
also break things like software RAID, btrfs, LVM, anything that involves
multiple devices. ID X on first RAID disk then needs to be mapped to ID
Y on the second, etc.

The only sensible solution is for the kernel to manage the stream
IDs. And for them to be plentiful. The storage device is free to ignore
them, do LRU or whatever it pleases to manage them if it has an internal
limit on number of open streams, etc.

Jens> The current API doesn't have any real limits (it'll work from
Jens> 1..MAX_UINT), and the transport part handles 255 streams at the
Jens> moment. The latter can be easily extended, we can just steal a few
Jens> more bits. Making it 1023 would be a one liner.

I'm not so worried about the implementation. I'm more worried about it
being conducive to the broken proposal that's on the table.

-- 
Martin K. Petersen	Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/