All of lore.kernel.org
 help / color / mirror / Atom feed
From: Isaac Chanin <chanin@WPI.EDU>
To: Hans Reiser <reiser@namesys.com>
Cc: Steve Olivieri <steve86@WPI.EDU>,
	reiserfs-list@namesys.com,
	Alexander Zarochentcev <zam@namesys.com>,
	vs <vs@thebsh.namesys.com>
Subject: Re: Reiser4 SCSI Bug?
Date: Sat, 29 Oct 2005 19:13:44 -0400	[thread overview]
Message-ID: <43640228.7080807@wpi.edu> (raw)
In-Reply-To: <43639DFA.1020107@namesys.com>

Hi Hans,

I don't think it's a device driver problem.  My fix derived simply from 
noticing that the function where the problem originates is bvec_alloc_bs 
in fs/bio.c.

To trace, the problem goes something like:
(fs/reiser4/wander.c) write_jnodes_to_disk_extent -> (fs/bio.c)
bio_alloc -> bio_alloc_bioset -> bvec_alloc_bs

In any case, BIO_MAX_PAGES is defined to be 256 in include/linux/bio.h, 
thus bvec_alloc_bs returns null, likewise bio_alloc_bioset does the 
same, as does bio_alloc.  And thus the error in wander.c.

Looking at the problem from the other direction, the max_blocks check 
that was already in wander.c looks like:

max_blocks = bdev_get_queue(super->s_bdev)->max_sectors >> 
(super->s_blocksize_bits - 9);

I'd look into the construction of the super block around 
s_blocksize_bits, or however max_sectors is derived, to see if there're 
any problems there (I suppose a device driver very well could be giving 
a bad value that gets used somewhere in that code), but I really don't 
know the reiser4 code well enough to do so.  In any case, as a temporary 
(or perhaps permanent, as it seems that the limit is hardcoded in the 
kernel anyways) solution it would probably be better to put the min(256, 
...) check around where max_blocks is set rather than around nr_blocks 
inside the while loop.


Isaac


Hans Reiser wrote:
> Thanks Isaac!
> 
> Does IDE have a different maximum?  Is there a non-hack way to discover
> the maximum of the device driver underneath?
> 
> Hans
> 
> Isaac Chanin wrote:
> 
> 
>>Steve Olivieri wrote:
>> 
>>
>>
>>>Greetings!
>>>
>>>I have a Maxtor Atlas II 15k, 147GB SCSI hard disk and an LSI Logic
>>>LSI21320 Ultra320 SCSI Host Bus Adapter for PCI-X (though it's running in
>>>a PCI slot).  I have partitioned it and installed a temporary Gentoo
>>>system with the reiserfs filesytem.  My boot partition uses ext2.  These
>>>partitions seem perfectly stable.  I have booted this temporary system
>>>multiple times and I have attempted to use it to install a permanent
>>>system with the reiser4 filesystem.
>>>
>>>After making the fileystems on each partition and mounting them, I was
>>>able to download two tarballs (the stage and portage snapshot).  While
>>>extracting the first, the terminal seems to hang.
>>>
>>>I switched to another terminal to see what was wrong.  Everything works
>>>great until I try to do anything at all on a reiser4 partition.  Then,
>>>this terminal also hangs.  Repeat until I'm out of terminals.
>>>
>>>I've been able to repeat this problem a number of times.  The only
>>>messages in my log file claimed that a flush failed (with code -12, if I
>>>remember correctly).  I do not have access to the logs at this time but I
>>>will try to get them soon.
>>>
>>>I am running a 2.6.13-ck8 kernel patched with the 2.6.13 reiser4 patchset.
>>>Patitions were made using the 1.0.5 reiser4progs/libaal.  In the past, I
>>>have also replicated this problem using a 2.6.12-gentoo kernel with the
>>>2.6.12 patchset and 1.0.5 reiser4progs/libaal.
>>>
>>>Is there something that I can do to fix this problem?  Is it a known bug?
>>>
>>>Also, I am not on the mailing list and I would appreciate it if I could be
>>>cc'd with any information about this problem.
>>>
>>>Thanks,
>>>Steve
>>>
>>>
>>>
>>>
>>>   
>>>
>>
>>Hey Steve,
>>
>>The problem appears to be in the fs/reiser4/wander.c file.  In short,
>>nr_blocks passed to bio_alloc ends up being too big; in my testing 1024,
>>whereas the maximum the called functions will properly deal with is 256.
>>
>>The attached patch adds a hacky fix for this problem, but perhaps someone
>>who knows the code better should go through and take a look why max_blocks
>>and nr in write_jnodes_to_disk_extent in wander.c do not always have a
>>shared minimum of no greater than 256.
>>
>>Hope this helps,
>>Isaac
>> 
>>
>>------------------------------------------------------------------------
>>
>>--- /mnt/gentoo/usr/src/linux/fs/reiser4/wander.c	2005-10-28 19:27:02.301541280 -0400
>>+++ linux/fs/reiser4/wander.c	2005-10-28 19:29:37.000000000 -0400
>>@@ -1241,7 +1241,7 @@
>>
>>	while (nr > 0) {
>>		struct bio *bio;
>>-		int nr_blocks = min(nr, max_blocks);
>>+		int nr_blocks = min(min(nr, max_blocks), 256);
>>		int i;
>>		int nr_used;
>>
>>
> 
> 
> 

  reply	other threads:[~2005-10-29 23:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-28 17:49 Reiser4 SCSI Bug? Steve Olivieri
2005-10-29  0:27 ` Isaac Chanin
2005-10-29 16:06   ` Hans Reiser
2005-10-29 23:13     ` Isaac Chanin [this message]
2005-10-29 23:18       ` Hans Reiser
2005-10-29 23:33         ` Isaac Chanin
2005-10-30  3:22           ` Hans Reiser
2005-10-30  0:35             ` Isaac Chanin
2005-10-30  6:42               ` Hans Reiser
2005-10-31  2:18                 ` Steve Olivieri
2005-10-31  3:48                   ` Isaac Chanin
2005-10-31 18:31                     ` Steve Olivieri
2005-10-31  6:24       ` Alexander Zarochentsev
2005-10-31  7:42         ` Alexander Zarochentsev
2005-10-31  8:23           ` Hans Reiser
2005-10-30 22:36 ` Michael James

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=43640228.7080807@wpi.edu \
    --to=chanin@wpi.edu \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=steve86@WPI.EDU \
    --cc=vs@thebsh.namesys.com \
    --cc=zam@namesys.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.