linux-kernel - Re: [PATCH 02/10] block: fix genhd refcounting in blkio_policy_parse_and

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:	Wed, 19 Oct 2011 16:51:46 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	axboe@...nel.dk, linux-kernel@...r.kernel.org, ctalbott@...gle.com,
	rni@...gle.com, containers@...ts.linux-foundation.org,
	kay.sievers@...y.org
Subject: Re: [PATCH 02/10] block: fix genhd refcounting in
 blkio_policy_parse_and_set()

Hello, again.

(cc'ing containers list and Kay)

The original thread is at

  http://thread.gmane.org/gmane.linux.kernel/1205150/focus=1205160

and it's about retaining blkiocg rules across device destruction.

On Wed, Oct 19, 2011 at 03:07:17PM -0700, Tejun Heo wrote:
> On Wed, Oct 19, 2011 at 03:05:53PM -0700, Tejun Heo wrote:
> > Hmmm.... I don't know.  If we're gonna bind rule existence to that of
> 
> Heh, I meant to say, "if those two are unbound,"
> 
> > device, wouldn't it be better to simply not check whether the device
> > exists?  The current behavior seems pretty confusing to me.

I've been thinking about it and the more I think about it, the current
behavior seems just wrong.  Device node # doesn't mean anything before
a device actually appears there.  There is no way userland can know
deterministically how the device node allocation would end up.

For example, sd allocates minors according to internal ida allocation
which is freed on scsi_disk_release() - ie. when all *kernel*
references go away which the userland has no way to find out until
after new device comes up with a different devt.

For EXT_DEVT devices, this becomes even less meaingful.  There is
absolutely no guarantee what devno would mean what.  devno which is
currently assigned to the whole disk now can be reassigned to a
partition.  There absolutely is no rule regarding who gets what
numbers.  ie. This can end up with rules pointing to partitions.

Moreover, it doesn't even make the implementation simpler.  blkiocg
currently keeps a separate list of policies so that they don't
disappear along with blkg's.

The only way applying rules to dynamic devices can work is doing the
proper dynamic configuration off udev and friends.

Can we *please* get rid of this misfeature?

Thank you.

-- 
tejun
--
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/