[BIO] Bounce queue in bio_add_page
diff mbox series

Message ID 20031101044619.GA15628@gondor.apana.org.au
State New, archived
Headers show
Series
  • [BIO] Bounce queue in bio_add_page
Related show

Commit Message

Herbert Xu Nov. 1, 2003, 4:46 a.m. UTC
Hi:

Currently bio_add_page will allow segments to be counted as merged
before they've been bounced.  This can create bio's that exceed
limits set by the driver/hardware.  This bug can be triggered on
HIGHMEM machines as well as ISA block devices such as AHA1542.

Here is a hack that works around it by bouncing the queue before
recounting the segments.

Cheers,

Comments

Herbert Xu Nov. 1, 2003, 10:05 a.m. UTC | #1
On Sat, Nov 01, 2003 at 03:46:19PM +1100, herbert wrote:
> 
> Currently bio_add_page will allow segments to be counted as merged
> before they've been bounced.  This can create bio's that exceed
> limits set by the driver/hardware.  This bug can be triggered on
> HIGHMEM machines as well as ISA block devices such as AHA1542.
> 
> Here is a hack that works around it by bouncing the queue before
> recounting the segments.

That patch chained bio's together which is prone to deadlock.  I've
modified __blk_queue_bounce to only allocate a new bio if it hasn't
been bounced already.  Unfortunately it has to allocate one with the
maximum number of bvecs so it's even more of a hack.

Hopefully someone else can come up with a better fix.

Cheers,
Jens Axboe Nov. 3, 2003, 12:25 p.m. UTC | #2
On Sat, Nov 01 2003, Herbert Xu wrote:
> On Sat, Nov 01, 2003 at 03:46:19PM +1100, herbert wrote:
> > 
> > Currently bio_add_page will allow segments to be counted as merged
> > before they've been bounced.  This can create bio's that exceed
> > limits set by the driver/hardware.  This bug can be triggered on
> > HIGHMEM machines as well as ISA block devices such as AHA1542.
> > 
> > Here is a hack that works around it by bouncing the queue before
> > recounting the segments.
> 
> That patch chained bio's together which is prone to deadlock.  I've
> modified __blk_queue_bounce to only allocate a new bio if it hasn't
> been bounced already.  Unfortunately it has to allocate one with the
> maximum number of bvecs so it's even more of a hack.
> 
> Hopefully someone else can come up with a better fix.

I think the best fix would be to simply not allow more than one page
that needs to be bounced to a bio. The problem is that the whole bio and
bio_vec allocations needs to be duplicated for highmem bouncing, and
that really doesn't thrill me. So a single mempool for bio, and single
entry bio_vec would be a lot leaner. I'll see if I can squeeze out a
prototype today.

I totally agree with your analysis of the problem, though.
Herbert Xu Nov. 3, 2003, 8:52 p.m. UTC | #3
On Mon, Nov 03, 2003 at 01:25:00PM +0100, Jens Axboe wrote:
> 
> I think the best fix would be to simply not allow more than one page
> that needs to be bounced to a bio. The problem is that the whole bio and

Here is an alternative solution, what if we simply disregarded high
pages when doing the recount?  Something like this,
Jens Axboe Nov. 4, 2003, 8:49 a.m. UTC | #4
On Tue, Nov 04 2003, Herbert Xu wrote:
> On Mon, Nov 03, 2003 at 01:25:00PM +0100, Jens Axboe wrote:
> > 
> > I think the best fix would be to simply not allow more than one page
> > that needs to be bounced to a bio. The problem is that the whole bio and
> 
> Here is an alternative solution, what if we simply disregarded high
> pages when doing the recount?  Something like this,

That could work, but it breaks the rule that counts are always accurate.
I'd have to audit some drivers to rule that completely safe, although it
seems harmless. The idea is sound, though.
Herbert Xu Nov. 4, 2003, 9:03 a.m. UTC | #5
On Tue, Nov 04, 2003 at 09:49:30AM +0100, Jens Axboe wrote:
> 
> That could work, but it breaks the rule that counts are always accurate.

Yes, it means that recount may return a higher value but it is never
lower.

I think it should be safe though as recount is not always called (it is
only called if the phys/hw segments exceed the limits).  In the cases
where it is not called you may be looking at an overestimate anyway.

Thanks,
Jens Axboe Nov. 4, 2003, 9:03 a.m. UTC | #6
On Tue, Nov 04 2003, Herbert Xu wrote:
> On Tue, Nov 04, 2003 at 09:49:30AM +0100, Jens Axboe wrote:
> > 
> > That could work, but it breaks the rule that counts are always accurate.
> 
> Yes, it means that recount may return a higher value but it is never
> lower.

Precisely. Historically, that would have caused panics in some drivers
even though it is safe :)

> I think it should be safe though as recount is not always called (it is
> only called if the phys/hw segments exceed the limits).  In the cases
> where it is not called you may be looking at an overestimate anyway.

I think it is safe too, just want to make absolutely sure.
Jens Axboe Nov. 5, 2003, 9:48 a.m. UTC | #7
On Tue, Nov 04 2003, Jens Axboe wrote:
> > I think it should be safe though as recount is not always called (it is
> > only called if the phys/hw segments exceed the limits).  In the cases
> > where it is not called you may be looking at an overestimate anyway.
> 
> I think it is safe too, just want to make absolutely sure.

I don't see any problems with this approach, I'll commit the code.
Thanks!
Herbert Xu Nov. 6, 2003, 9:09 p.m. UTC | #8
On Wed, Nov 05, 2003 at 10:48:55AM +0100, Jens Axboe wrote:
> 
> I don't see any problems with this approach, I'll commit the code.

Actually, please hold onto that patch if possible, I've just received
a report that it maybe causing worse problems than the one it solves.

I'll get back to you.

Cheers,
Herbert Xu Nov. 7, 2003, 11:23 a.m. UTC | #9
On Fri, Nov 07, 2003 at 08:09:00AM +1100, herbert wrote:
> On Wed, Nov 05, 2003 at 10:48:55AM +0100, Jens Axboe wrote:
> > 
> > I don't see any problems with this approach, I'll commit the code.
> 
> Actually, please hold onto that patch if possible, I've just received
> a report that it maybe causing worse problems than the one it solves.
> 
> I'll get back to you.

OK, looks like the crash is unrelated to this change.  Here is
the dump:

LILO 22.5.8 boot: Linux
Loading Linux..................................
BIOS data check successful
Linux version 2.6.0-test9.custom586.1 (root@sitvanit) (gcc version 3.3.2 (Debian)) #1 Wed Nov 5 23:33:12 IST 2003
BIOS-provided physical RAM map:
 BIOS-88: 0000000000000000 - 000000000009f000 (usable)
 BIOS-88: 0000000000100000 - 0000000002400000 (usable)
36MB LOWMEM available.
On node 0 totalpages: 9216
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 5120 pages, LIFO batch:1
  HighMem zone: 0 pages, LIFO batch:1
DMI not present.
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=Linux ro root=301 console=tty0 console=ttyS0,9600n8
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 256 (order 8: 2048 bytes)
Detected 83.274 MHz processor.
Console: colour VGA+ 80x25
Memory: 33292k/36864k available (1003k kernel code, 3136k reserved, 358k data, 272k init, 0k highmem)
Calibrating delay loop... 162.30 BogoMIPS
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (ungzip failed); looks like an initrd
Freeing initrd memory: 956k freed
Intel Pentium with F0 0F bug - workaround enabled.
CPU: Intel OverDrive PODP5V83 stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.00 entry at 0xea100, last bus=0
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
spurious 8259A interrupt: IRQ7.
ikconfig 0.7 with /proc/config*
VFS: Disk quotas dquot_6.5.1
devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Initializing Cryptographic API
pty: 256 Unix98 ptys configured
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
ttyS1 at I/O 0x2f8 (irq = 3) is a 16450
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 956 blocks [1 disk] into ram disk... |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\done.
VFS: Mounted root (cramfs filesystem).
Freeing unused kernel memory: 272k freed
initrd-tools: 0.1.54
warning: can't open /etc/mtab: No such file or directory
NET: Registered protocol family 1
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Module ide_probe_mod cannot be unloaded due to unsafe usage in include/linux/module.h:483
hda: WDC AC2420H, ATA DISK drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 830760 sectors (425 MB) w/128KiB Cache, CHS=989/15/56
 /dev/ide/host0/bus0/target0/lun0: p1 p2
mount: fs type ext3 not supported by kernel
INIT: version 2.85 booting
Starting Bootlog daemon: Adding 318352k swap on /dev/hda2.  Priority:-1 extents:1
Real Time Clock Driver v1.12
SCSI subsystem initialized
Configuring Adaptec (SCSI-ID 7) at IO:134, IRQ 15, DMA priority 6
scsi0 : Adaptec 1542
isa bounce pool size: 16 pages
  Vendor: SEAGATE   Model: ST19171N          Rev: 0024
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 17783112 512-byte hdwr sectors (9105 MB)
SCSI device sda: drive cache: write through
 /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (288 buckets, 2304 max) - 300 bytes per conntrack
smc-ultra.c:v2.02 2/3/98 Donald Becker (becker@cesdis.gsfc.nasa.gov)
eth0: SMC EtherEZ at 0x280, 00 00 C0 ED 9C C6,assigned  IRQ 10 memory 0xc8000-0xc9fff.
ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)
Last modified Nov 1, 2000 by Paul Gortmaker
NE*000 ethercard probe at 0x300: 00 40 05 14 a0 2c
eth1: NE2000 found at 0x300, using IRQ 5.
nfs warning: mount version older than kernel
bootlogd.
------------[ cut here ]------------
kernel BUG at mm/filemap.c:329!
invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[<c012d4e7>]    Not tainted
EFLAGS: 00010246
EIP is at unlock_page+0x17/0x40
eax: 00000000   ebx: c100e448   ecx: 0000001c   edx: c100e448
esi: c105a058   edi: c1304f20   ebp: c0257ebc   esp: c0257e58
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c0256000 task=c0224c80)
Stack: c10e3114 00000001 c015f09e c1304f20 00000000 00011000 c01496ed c1304f20 
       00011000 00000000 00011000 c1304f20 c01a252f c1304f20 00011000 00000000 
       00011000 c1304f20 00000000 00000000 00000000 00000000 c12f8b30 c029ace0 
Call Trace:
 [<c015f09e>] mpage_end_io_read+0x4e/0x70
 [<c01496ed>] bio_endio+0x3d/0x60
 [<c01a252f>] __end_that_request_first+0x1ef/0x210
 [<c01a2567>] end_that_request_first+0x17/0x20
 [<c30c9768>] scsi_end_request+0x28/0xb0 [scsi_mod]
 [<c30c9b5a>] scsi_io_completion+0x1da/0x470 [scsi_mod]
 [<c30428bc>] sd_rw_intr+0x7c/0x240 [sd_mod]
 [<c30c5a01>] scsi_finish_command+0x81/0xe0 [scsi_mod]
 [<c30c5826>] scsi_softirq+0xd6/0x200 [scsi_mod]
 [<c011c453>] do_softirq+0x93/0xa0
 [<c010cea6>] do_IRQ+0xd6/0x110
 [<c0105000>] _stext+0x0/0x20
 [<c010b6c8>] common_interrupt+0x18/0x20
 [<c01088a0>] default_idle+0x0/0x30
 [<c0105000>] _stext+0x0/0x20
 [<c01088c4>] default_idle+0x24/0x30
 [<c0108935>] cpu_idle+0x25/0x40
 [<c02586a9>] start_kernel+0x159/0x190

Code: 0f 0b 49 01 3e cc 20 c0 39 36 75 03 5b 5e c3 89 f0 31 c9 ba 
 <0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing
Jens Axboe Nov. 7, 2003, 11:25 a.m. UTC | #10
On Fri, Nov 07 2003, Herbert Xu wrote:
> On Fri, Nov 07, 2003 at 08:09:00AM +1100, herbert wrote:
> > On Wed, Nov 05, 2003 at 10:48:55AM +0100, Jens Axboe wrote:
> > > 
> > > I don't see any problems with this approach, I'll commit the code.
> > 
> > Actually, please hold onto that patch if possible, I've just received
> > a report that it maybe causing worse problems than the one it solves.
> > 
> > I'll get back to you.

Well too late, it's in the kernel tree. I've been running it here for
some days as well, haven't seen any problems. It also looks fine to me,
so...

> OK, looks like the crash is unrelated to this change.  Here is
> the dump:
> 
> ------------[ cut here ]------------
> kernel BUG at mm/filemap.c:329!
> invalid operand: 0000 [#1]
> CPU:    0
> EIP:    0060:[<c012d4e7>]    Not tainted
> EFLAGS: 00010246
> EIP is at unlock_page+0x17/0x40
> eax: 00000000   ebx: c100e448   ecx: 0000001c   edx: c100e448
> esi: c105a058   edi: c1304f20   ebp: c0257ebc   esp: c0257e58
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, threadinfo=c0256000 task=c0224c80)
> Stack: c10e3114 00000001 c015f09e c1304f20 00000000 00011000 c01496ed c1304f20 
>        00011000 00000000 00011000 c1304f20 c01a252f c1304f20 00011000 00000000 
>        00011000 c1304f20 00000000 00000000 00000000 00000000 c12f8b30 c029ace0 
> Call Trace:
>  [<c015f09e>] mpage_end_io_read+0x4e/0x70
>  [<c01496ed>] bio_endio+0x3d/0x60
>  [<c01a252f>] __end_that_request_first+0x1ef/0x210
>  [<c01a2567>] end_that_request_first+0x17/0x20
>  [<c30c9768>] scsi_end_request+0x28/0xb0 [scsi_mod]
>  [<c30c9b5a>] scsi_io_completion+0x1da/0x470 [scsi_mod]
>  [<c30428bc>] sd_rw_intr+0x7c/0x240 [sd_mod]
>  [<c30c5a01>] scsi_finish_command+0x81/0xe0 [scsi_mod]
>  [<c30c5826>] scsi_softirq+0xd6/0x200 [scsi_mod]
>  [<c011c453>] do_softirq+0x93/0xa0
>  [<c010cea6>] do_IRQ+0xd6/0x110
>  [<c0105000>] _stext+0x0/0x20
>  [<c010b6c8>] common_interrupt+0x18/0x20
>  [<c01088a0>] default_idle+0x0/0x30
>  [<c0105000>] _stext+0x0/0x20
>  [<c01088c4>] default_idle+0x24/0x30
>  [<c0108935>] cpu_idle+0x25/0x40
>  [<c02586a9>] start_kernel+0x159/0x190

Could be related, someone is doing an unlock on an already unlocked
page. Is this the same system that saw the bounce problem initially?
Herbert Xu Nov. 7, 2003, 11:28 a.m. UTC | #11
On Fri, Nov 07, 2003 at 12:25:55PM +0100, Jens Axboe wrote:
> 
> Could be related, someone is doing an unlock on an already unlocked
> page. Is this the same system that saw the bounce problem initially?

Yes, see http://bugs.debian.org/218566 for details.
Jens Axboe Nov. 7, 2003, 11:32 a.m. UTC | #12
On Fri, Nov 07 2003, Herbert Xu wrote:
> On Fri, Nov 07, 2003 at 12:25:55PM +0100, Jens Axboe wrote:
> > 
> > Could be related, someone is doing an unlock on an already unlocked
> > page. Is this the same system that saw the bounce problem initially?
> 
> Yes, see http://bugs.debian.org/218566 for details.

Then there's likely just some other bug wrt bouncing. Hmm, does this
work?

===== mm/highmem.c 1.47 vs edited =====
--- 1.47/mm/highmem.c	Thu Oct  9 15:03:32 2003
+++ edited/mm/highmem.c	Fri Nov  7 12:32:03 2003
@@ -402,6 +402,8 @@
 		to->bv_len = from->bv_len;
 		to->bv_offset = from->bv_offset;
 
+		lock_page(to->bv_page);
+
 		if (rw == WRITE) {
 			char *vto, *vfrom;
Herbert Xu Nov. 7, 2003, 10:52 p.m. UTC | #13
On Fri, Nov 07, 2003 at 12:32:35PM +0100, Jens Axboe wrote:
> On Fri, Nov 07 2003, Herbert Xu wrote:
> > On Fri, Nov 07, 2003 at 12:25:55PM +0100, Jens Axboe wrote:
> > > 
> > > Could be related, someone is doing an unlock on an already unlocked
> > > page. Is this the same system that saw the bounce problem initially?
> > 
> > Yes, see http://bugs.debian.org/218566 for details.
> 
> Then there's likely just some other bug wrt bouncing. Hmm, does this
> work?

It's OK, it turns out that he applied my earlier patch which called
blk_queue_bounce() in blk_add_page.  That obviously breaks down when
the bio is bounced since the real end_io functions haven't been set
yet.

So this problem is resolved.

Thanks,
Jens Axboe Nov. 8, 2003, 9:29 a.m. UTC | #14
On Sat, Nov 08 2003, Herbert Xu wrote:
> On Fri, Nov 07, 2003 at 12:32:35PM +0100, Jens Axboe wrote:
> > On Fri, Nov 07 2003, Herbert Xu wrote:
> > > On Fri, Nov 07, 2003 at 12:25:55PM +0100, Jens Axboe wrote:
> > > > 
> > > > Could be related, someone is doing an unlock on an already unlocked
> > > > page. Is this the same system that saw the bounce problem initially?
> > > 
> > > Yes, see http://bugs.debian.org/218566 for details.
> > 
> > Then there's likely just some other bug wrt bouncing. Hmm, does this
> > work?
> 
> It's OK, it turns out that he applied my earlier patch which called
> blk_queue_bounce() in blk_add_page.  That obviously breaks down when
> the bio is bounced since the real end_io functions haven't been set
> yet.
> 
> So this problem is resolved.

Great, I'm a lot more relieved now.

Patch
diff mbox series

Index: kernel-source-2.5/include/linux/bio.h
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/include/linux/bio.h,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 bio.h
--- kernel-source-2.5/include/linux/bio.h	28 Sep 2003 04:44:21 -0000	1.1.1.8
+++ kernel-source-2.5/include/linux/bio.h	1 Nov 2003 04:36:28 -0000
@@ -239,7 +239,8 @@ 
 
 extern inline void bio_init(struct bio *);
 
-extern int bio_add_page(struct bio *, struct page *, unsigned int,unsigned int);
+extern int bio_add_page(struct bio **, struct page *, unsigned int,
+			unsigned int);
 extern int bio_get_nr_vecs(struct block_device *);
 extern struct bio *bio_map_user(struct block_device *, unsigned long,
 				unsigned int, int);
Index: kernel-source-2.5/fs/bio.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/fs/bio.c,v
retrieving revision 1.1.1.13
diff -u -r1.1.1.13 bio.c
--- kernel-source-2.5/fs/bio.c	28 Sep 2003 04:44:16 -0000	1.1.1.13
+++ kernel-source-2.5/fs/bio.c	1 Nov 2003 04:36:00 -0000
@@ -292,9 +292,10 @@ 
  *	number of reasons, such as the bio being full or target block
  *	device limitations.
  */
-int bio_add_page(struct bio *bio, struct page *page, unsigned int len,
+int bio_add_page(struct bio **bio_orig, struct page *page, unsigned int len,
 		 unsigned int offset)
 {
+	struct bio *bio = *bio_orig;
 	request_queue_t *q = bdev_get_queue(bio->bi_bdev);
 	int retried_segments = 0;
 	struct bio_vec *bvec;
@@ -324,6 +325,8 @@ 
 
 		bio->bi_flags &= ~(1 << BIO_SEG_VALID);
 		retried_segments = 1;
+		blk_queue_bounce(q, &bio);
+		*bio_orig = bio;
 	}
 
 	/*
@@ -410,7 +413,7 @@ 
 		/*
 		 * sorry...
 		 */
-		if (bio_add_page(bio, pages[i], bytes, offset) < bytes)
+		if (bio_add_page(&bio, pages[i], bytes, offset) < bytes)
 			break;
 
 		len -= bytes;
Index: kernel-source-2.5/fs/direct-io.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/fs/direct-io.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 direct-io.c
--- kernel-source-2.5/fs/direct-io.c	8 Oct 2003 19:24:14 -0000	1.1.1.9
+++ kernel-source-2.5/fs/direct-io.c	1 Nov 2003 04:36:59 -0000
@@ -503,7 +503,7 @@ 
 {
 	int ret;
 
-	ret = bio_add_page(dio->bio, dio->cur_page,
+	ret = bio_add_page(&dio->bio, dio->cur_page,
 			dio->cur_page_len, dio->cur_page_offset);
 	if (ret == dio->cur_page_len) {
 		dio->pages_in_io--;
Index: kernel-source-2.5/fs/mpage.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/fs/mpage.c,v
retrieving revision 1.1.1.8
diff -u -r1.1.1.8 mpage.c
--- kernel-source-2.5/fs/mpage.c	22 Aug 2003 23:53:13 -0000	1.1.1.8
+++ kernel-source-2.5/fs/mpage.c	1 Nov 2003 04:37:27 -0000
@@ -296,7 +296,7 @@ 
 	}
 
 	length = first_hole << blkbits;
-	if (bio_add_page(bio, page, length, 0) < length) {
+	if (bio_add_page(&bio, page, length, 0) < length) {
 		bio = mpage_bio_submit(READ, bio);
 		goto alloc_new;
 	}
@@ -540,7 +540,7 @@ 
 	}
 
 	length = first_unmapped << blkbits;
-	if (bio_add_page(bio, page, length, 0) < length) {
+	if (bio_add_page(&bio, page, length, 0) < length) {
 		bio = mpage_bio_submit(WRITE, bio);
 		goto alloc_new;
 	}
Index: kernel-source-2.5/fs/xfs/pagebuf/page_buf.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/fs/xfs/pagebuf/page_buf.c,v
retrieving revision 1.1.1.15
diff -u -r1.1.1.15 page_buf.c
--- kernel-source-2.5/fs/xfs/pagebuf/page_buf.c	8 Oct 2003 19:24:01 -0000	1.1.1.15
+++ kernel-source-2.5/fs/xfs/pagebuf/page_buf.c	1 Nov 2003 04:40:46 -0000
@@ -1346,7 +1346,7 @@ 
 		bio->bi_end_io = bio_end_io_pagebuf;
 		bio->bi_private = pb;
 
-		bio_add_page(bio, pb->pb_pages[0], PAGE_CACHE_SIZE, 0);
+		bio_add_page(&bio, pb->pb_pages[0], PAGE_CACHE_SIZE, 0);
 		size = 0;
 
 		atomic_inc(&pb->pb_io_remaining);
@@ -1390,7 +1390,7 @@ 
 		if (nbytes > size)
 			nbytes = size;
 
-		if (bio_add_page(bio, pb->pb_pages[map_i],
+		if (bio_add_page(&bio, pb->pb_pages[map_i],
 					nbytes, offset) < nbytes)
 			break;
 
Index: kernel-source-2.5/drivers/mtd/devices/blkmtd.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/mtd/devices/blkmtd.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 blkmtd.c
--- kernel-source-2.5/drivers/mtd/devices/blkmtd.c	22 Aug 2003 23:51:04 -0000	1.1.1.9
+++ kernel-source-2.5/drivers/mtd/devices/blkmtd.c	1 Nov 2003 04:45:27 -0000
@@ -146,7 +146,7 @@ 
 		bio->bi_sector = page->index << (PAGE_SHIFT-9);
 		bio->bi_private = &event;
 		bio->bi_end_io = bi_read_complete;
-		if(bio_add_page(bio, page, PAGE_SIZE, 0) == PAGE_SIZE) {
+		if(bio_add_page(&bio, page, PAGE_SIZE, 0) == PAGE_SIZE) {
 			submit_bio(READ, bio);
 			blk_run_queues();
 			wait_for_completion(&event);
@@ -213,7 +213,7 @@ 
 		bio->bi_bdev = blkdev;
 	}
 
-	if(bio_add_page(bio, page, PAGE_SIZE, 0) != PAGE_SIZE) {
+	if(bio_add_page(&bio, page, PAGE_SIZE, 0) != PAGE_SIZE) {
 		blkmtd_write_out(bio);
 		bio = NULL;
 		goto retry;