* Re: BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!)
@ 2001-06-07 21:10 Andries.Brouwer
0 siblings, 0 replies; 3+ messages in thread
From: Andries.Brouwer @ 2001-06-07 21:10 UTC (permalink / raw)
To: COTTE, linux-kernel
From: COTTE@de.ibm.com
We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that time, which has been called by register_disk, which our
device driver issues after a disk has been formatted.
Grok_partitions first initializes blk_size[major] with a NULL
pointer, detects the partitions and then assigns the original
value to blk_size[major] again.
Here's the interresting code from these functions, I cut some
irrelevant things out:
From grok_paritions:
blk_size[dev->major] = NULL;
check_partition(dev, MKDEV(dev->major, first_minor), 1 + first_minor);
if (dev->sizes != NULL) {
blk_size[dev->major] = dev->sizes;
};
From generic_make_request:
if (blk_size[major]) {
if (blk_size[major][MINOR(bh->b_rdev)]) {
Can anyone explain to me, why grok_partitions has to clear
this pointer?
Well, among the irrelevant details you left out is the fact that
it is not
blk_size[dev->major] = NULL;
but
if(!dev->sizes)
blk_size[dev->major] = NULL;
...
if (dev->sizes)
blk_size[dev->major] = dev->sizes;
So, the idea is that either this major has an array with sizes,
and then one can find it in blk_size[dev->major], or it hasn't.
You seem to have a situation where dev->sizes is NULL but
blk_size[dev->major] is not? What device is this?
Andries
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!)
@ 2001-06-08 7:52 COTTE
0 siblings, 0 replies; 3+ messages in thread
From: COTTE @ 2001-06-08 7:52 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
Hi Andries, Hi List!
Andries, thank you for your quick response,
>Well, among the irrelevant details you left out is the fact that
>it is not
> blk_size[dev->major] = NULL;
>but
> if(!dev->sizes)
> blk_size[dev->major] = NULL;
Well, this is absoloutely right, the behaviour to clear blk_size when
dev->sizes
is NULL looks sensible to me. But seven lines below it says
-unconditionaly-:
blk_size[dev->major] = NULL;
>So, the idea is that either this major has an array with sizes,
>and then one can find it in blk_size[dev->major], or it hasn't.
>You seem to have a situation where dev->sizes is NULL but
>blk_size[dev->major] is not? What device is this?
Our dev->sizes holds a pointer which (normally, when grok_partitions is
not running currently). We are running the dasd-device driver for channel
attached disks on mainframe architectures (drivers/s390/block/dasd*).
mit freundlichem Gruß / with kind regards
Carsten Otte
IBM Deutschland Entwicklung GmbH
Linux for 390/zSeries Development - Device Driver Team
Phone: +49/07031/16-4076
IBM internal phone: *120-4076
--
We are Linux.
Resistance indicates that you're missing the point!
Andries.Brouwer@cwi.nl on 06/07/2001 11:10:52 PM
Please respond to Andries.Brouwer@cwi.nl
To: Carsten Otte/Germany/IBM@IBMDE, linux-kernel@vger.kernel.org
cc:
Subject: Re: BUG: race-cond with partition-check and ll_rw_blk (all
platforms, 2.4.*!)
[-- Attachment #2: Type: text/plain, Size: 1442 bytes --]
From: COTTE@de.ibm.com
We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that time, which has been called by register_disk, which our
device driver issues after a disk has been formatted.
Grok_partitions first initializes blk_size[major] with a NULL
pointer, detects the partitions and then assigns the original
value to blk_size[major] again.
Here's the interresting code from these functions, I cut some
irrelevant things out:
From grok_paritions:
blk_size[dev->major] = NULL;
check_partition(dev, MKDEV(dev->major, first_minor), 1 +
first_minor);
if (dev->sizes != NULL) {
blk_size[dev->major] = dev->sizes;
};
From generic_make_request:
if (blk_size[major]) {
if (blk_size[major][MINOR(bh->b_rdev)]) {
Can anyone explain to me, why grok_partitions has to clear
this pointer?
...
if (dev->sizes)
blk_size[dev->major] = dev->sizes;
So, the idea is that either this major has an array with sizes,
and then one can find it in blk_size[dev->major], or it hasn't.
You seem to have a situation where dev->sizes is NULL but
blk_size[dev->major] is not? What device is this?
Andries
^ permalink raw reply [flat|nested] 3+ messages in thread
* BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!)
@ 2001-06-07 11:44 COTTE
0 siblings, 0 replies; 3+ messages in thread
From: COTTE @ 2001-06-07 11:44 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
Hi kernel-list-readers!
We just had a problem when running some formatting-utils on
a large amount of disks synchronously: We got a NULL-pointer
violation when accessig blk_size[major] for our major number.
Further research showed, that grok_partitions was running at
that time, which has been called by register_disk, which our
device driver issues after a disk has been formatted.
Grok_partitions first initializes blk_size[major] with a NULL
pointer, detects the partitions and then assigns the original
value to blk_size[major] again.
Here's the interresting code from these functions, I cut some
irrelevant things out:
>From grok_paritions:
blk_size[dev->major] = NULL;
check_partition(dev, MKDEV(dev->major, first_minor), 1 + first_minor);
if (dev->sizes != NULL) {
blk_size[dev->major] = dev->sizes;
};
>From generic_make_request:
if (blk_size[major]) {
if (blk_size[major][MINOR(bh->b_rdev)]) {
printk(KERN_INFO
"attempt to access beyond end of device\n");
printk(KERN_INFO "%s: rw=%d, want=%ld, limit=%d\n",
kdevname(bh->b_rdev), rw,
(sector + count)>>1,
blk_size[major][MINOR(bh->b_rdev)]);
}\x1d
Can anyone explain to me, why grok_partitions has to clear
this pointer? Why is this all done without any lock which causes
race conditions all over the block-device layer (for example
generic_make_request() in ll_rw_blk.c first checks if the pointer
is set and afterwards accesses the array behind the pointer)?
mit freundlichem Gru
[-- Attachment #2: Type: text/plain, Size: 260 bytes --]
ß / with kind regards
Carsten Otte
IBM Deutschland Entwicklung GmbH
Linux for 390/zSeries Development - Device Driver Team
Phone: +49/07031/16-4076
IBM internal phone: *120-4076
--
We are Linux.
Resistance indicates that you're missing the point!
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-06-08 7:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-07 21:10 BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!) Andries.Brouwer
-- strict thread matches above, loose matches on Subject: below --
2001-06-08 7:52 COTTE
2001-06-07 11:44 COTTE
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).