mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: COTTE@de.ibm.com
To: linux-kernel@vger.kernel.org
Subject: BUG: race-cond with partition-check and ll_rw_blk (all platforms, 2.4.*!)
Date: Thu, 7 Jun 2001 13:44:56 +0200	[thread overview]
Message-ID: <C1256A64.0040C10D.00@d12mta11.de.ibm.com> (raw)

[-- 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!

             reply	other threads:[~2001-06-07 14:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-07 11:44 COTTE [this message]
2001-06-07 21:10 Andries.Brouwer
2001-06-08  7:52 COTTE

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C1256A64.0040C10D.00@d12mta11.de.ibm.com \
    --to=cotte@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®