linux-kernel - Re: linux-next: Tree for August 27

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]

Message-ID: <20080829070515.GL20055@kernel.dk>
Date:	Fri, 29 Aug 2008 09:05:16 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, dm-devel@...hat.com,
	Tejun Heo <tj@...nel.org>
Subject: Re: linux-next: Tree for August 27

On Fri, Aug 29 2008, Bartlomiej Zolnierkiewicz wrote:
> 
> [ Thanks to Ingo for handling x86-vs-UP build fix ]
> 
> On Wednesday 27 August 2008, Bartlomiej Zolnierkiewicz wrote:
> 
> [...]
> 
> > However now I'm getting device-mapper errors on 'cryptsetup create':
> > 
> > dmesg:
> > ...
> > device-mapper: core: bdget failed in dm_suspend
> > device-mapper: ioctl: device doesn't appear to be in the dev hash table.
> > ...
> > 
> > cryptsetup:
> > ...
> > Command failed: device-mapper: resume ioctl failed: Invalid argument
> > ...
> > 
> > next-20080826 is fine
> 
> next-20080828 still isn't, The Lucky Winner is:
> 
> commit 9617fc8f8e599166590fe339de78a50bc5ab5e93
> Author: Tejun Heo <tj@...nel.org>
> Date:   Mon Aug 25 19:56:08 2008 +0900
> 
>     block: move __dev from disk to part0
> 
>     Move disk->__dev to part0->__dev.  This simplifies bdget_disk() and
>     lookup_devt() and allows common sysfs attributes to be unified.
>     part_to_disk() is updated to handle part0 -> disk.
> 
>     Signed-off-by: Tejun Heo <tj@...nel.org>
>     Signed-off-by: Jens Axboe <jens.axboe@...cle.com>
> 
> Fix:
> 
> From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> Subject: [PATCH] block: fix part0 handling in bdget_disk() / blk_lookup_devt()
> 
> part0 is a "special" partition and doesn't need to have capacity set - this
> fixes regression caused by "block: move __dev from disk to part0" commit.
> 
> Cc: Tejun Heo <tj@...nel.org>
> Cc: Jens Axboe <jens.axboe@...cle.com>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
> ---
> Jens, please integrate it into the original commit if feasible.

Thanks Bart, I folded it into the original commit.

> 
>  block/genhd.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: b/block/genhd.c
> ===================================================================
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -543,7 +543,7 @@ extern struct block_device *bdget_disk(s
>  	struct block_device *bdev = NULL;
>  
>  	part = disk_get_part(disk, partno);
> -	if (part && part->nr_sects)
> +	if (part && (part->nr_sects || partno == 0))
>  		bdev = bdget(part_devt(part));
>  	disk_put_part(part);
>  
> @@ -1001,7 +1001,7 @@ dev_t blk_lookup_devt(const char *name, 
>  			continue;
>  
>  		part = disk_get_part(disk, partno);
> -		if (part && part->nr_sects) {
> +		if (part && (part->nr_sects || partno == 0)) {
>  			devt = part_devt(part);
>  			disk_put_part(part);
>  			break;
> --
> 
> On the somehow related topic - CONFIG_DEBUG_BLOCK_EXT_DEVT which is
> introduced by commit 3e5ba59bbab878f60b8b87004ac55a464bddc819 ("block:
> implement CONFIG_DEBUG_BLOCK_EXT_DEVT") is way too intrusive to be
> enabled by default if CONFIG_DEBUG_KERNEL is set as it easily results
> in no longer bootable systems (+ help entry for the new option says
> "Say N if you are unsure.").
> 
> Tejun/Jens: please consider changing this.

I have change the default to 'n' for now.

-- 
Jens Axboe

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