[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[patch #1754] [Patch #1754] store_{read, write} abort program when LEN i

From: noreply
Subject: [patch #1754] [Patch #1754] store_{read, write} abort program when LEN is not aligned
Date: Sun, 03 Aug 2003 10:28:32 -0400
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

Patch #1754 has been updated. 

Category: libstore
Status: Open
Summary: store_{read,write} abort program when LEN is not aligned


Date: Wed 07/23/03 at 13:35
By: ogi

* Copyright years are updated.

Date: Thu 07/31/03 at 22:46
By: marcus

The assert is there to catch bugs in libstore using programs, which usually 
only access store blocks with aligned boundaries.

Do you have an application which doesn't do this, or did you see a Hurd program 
using libstore in a way that triggers the assertion?


Date: Fri 08/01/03 at 09:15
By: ogi

I hit this problem while patching e2fsprogs to work with libstore.  e2fsprogs 
uses some unaligned reads from block devices.

If libstore was internal library in the Hurd, I would agree with you.  But 
native Hurd programs (not in the Hurd distribution) can legally want to use the 
library, so libstore must behave correctly on invalid arguments.  For example, 
munmap returns EINVAL if address is not aligned, it doesn't throw assertion 
failure.  What is the difference between munmap and store_read so that 
store_read have to not return EINVAL on invalid arguments?

Moreover, every program that uses store_read must check if I/O errors occured.  
So the EINVAL will always be caught ;-)

Date: Fri 08/01/03 at 12:41
By: marcus

Why does e2fsprogs unaligned reads?  I would like to discuss what it does, 
independently of resolving this patch.

I agree that eventually we want to make libstore more robust  But before we can 
do that, we must check that all existing callers, at least those in the Hurd 
code, but preferably also parted etc, do check the return value properly.  Can 
you please do that?


Date: Sat 08/02/03 at 13:46
By: ogi

In e2fsprogs, the I/O function that reads data is io_channel_read_blk. It 
accepts _number of blocks_.  But if this count is negative, then its negated 
value is accepted as _number of bytes_.   For example, this is used in 
e2fsprogs/lib/ext2fs/rw_bitmaps:read_bitmaps.  Of course, this is not a problem 
when you use Unix API.

I'm willing to check all the Hurd for calls to store_read and store_write, but 
I don't know any other program, except parted, that uses libstore.  If there 
is, please tell me.

Date: Sat 08/02/03 at 23:50
By: marcus

I am confused.  Are you saying that e2fsprogs does read bytes rather than 
blocks from the store?  In that case an EINVAL would not help it, except make 
it fail properly instead aborting it.  Or is that only how you found out about 
this problem?

I don't think there is any other program than parted.  I am more worried about 
the Hurd itself.  If you can check its callers, then I am willing to put the 
change in, independently of what e2fsprogs does, for the reasons you gave.


Date: Sun 08/03/03 at 15:58
By: ogi

This is the way how I found the problem.

When caller of io_channel_read_blk wants to read bytes (not blocks), the number 
of bytes is rounded to store->block_size, and after store_read, only the 
desired bytes are copied to the caller-supplied buffer.  Fortunately, the 
starting offset is always measured in blocks, and never in bytes.

Date: Sun 08/03/03 at 16:28
By: marcus

I am still confused.  If e2fsprogs does the right thing wrt reading only 
blocks, how did you find out about the assertion?  Did you actually see the 
assertion being triggered, or was the patch the result of source studying?


For more info, visit:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]