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:	Mon, 03 Dec 2012 18:40:32 -0600
From:	Josh Hunt <>
To:	Andrew Morton <>
CC:	"" <>,
	"" <>,
	"" <>,
	"" <>,
	Jens Axboe <>
Subject: Re: [PATCH] block: Restore /proc/partitions to not display non-partitionable
 removable devices

On 12/03/2012 06:06 PM, Andrew Morton wrote:
> On Mon, 19 Nov 2012 18:56:49 -0800
> Josh Hunt <> wrote:
>> We found with newer kernels we started seeing the cdrom device showing
>> up in /proc/partitions, but it was not there before. Looking into this I found
>> that commit d27769ec... block: add GENHD_FL_NO_PART_SCAN introduces this change
>> in behavior. It's not clear to me from the commit's changelog if this change was
>> intentional or not. This comment still remains:
>> /* Don't show non-partitionable removeable devices or empty devices */
>> so I've decided to send a patch to restore the behavior of not printing
>> unpartitionable removable devices.
> d27769ec was merged in August 2011, so I after all this time, your fix
> could be viewed as "changing existing behaviour".
> So perhaps it would be best to leave things alone.  Is there any
> particular problem with the post-Aug, 2011 behaviour?

We caught this by a script that parses /proc/partitions and made some 
assumptions about the contents therein. It had worked fine up until when 
this behavior changed. We were able to modify our script to get what we 

The patch was meant to do two things: 1) understand if this was an 
unintended change and 2) if so, propose a solution to resolve it. Since 
the comment was left in the source I believe either a) my patch should 
be applied or b) a new patch with the comment removed should be put in 
since it's no longer correct. I did not think this type of change to 
kernel abi was generally acceptable.

While the commit is over a year old, it changes behavior which had been 
in tact for a while (years?) from what I can tell. We were running 3.0 
with stable updates until we upgraded to 3.2 and hit this. Neither of 
these are what I would consider "old" kernels.

Thanks for looking at this.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists