lkml.org 
[lkml]   [2001]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.4.10-pre11
On Tue, Sep 18, 2001 at 05:31:48AM -0400, Alexander Viro wrote:
>
>
> On Mon, 17 Sep 2001, Linus Torvalds wrote:
>
> > This also merges the blkdev in page cache patch, and that will hopefully
> > make it noticeably easier to do the "do bread() with page cache too", at
> > which point a lot of the current ugly synchronization issues will go away.
>
> Umm... Linus, had you actually read through the fs/block_device.c part
> of that? It's not just ugly as hell, it's (AFAICS) not hard to oops
> if you have several inodes sharing major:minor. ->bd_inode and its

can you show an exploit? I cannot reproduce any problem here:

root@athlon:/tmp > cp -a /dev/hda hda.1
root@athlon:/tmp > cp -a /dev/hda hda.2
root@athlon:/tmp > cp hda.1 /dev/null & cp hda.2 /dev/null &
[1] 24981
[2] 24982
root@athlon:/tmp > fg
cp hda.2 /dev/null

root@athlon:/tmp > fg
cp hda.1 /dev/null

root@athlon:/tmp >

> treatment are bogus. Please, read it through and consider reverting -
> in its current state code is an ugly mess.

what other design solution do you propose rather both inodes sharing the
i_mapping across the different inodes like I did?

I found more handy to just bump the i_count of the first inode and
referencing it from the bd_inode, rather than dynamically allocating the
i_mapping and have a bd_mapping, but if you prefer to dynamically
allocate the i_mapping rather than using the i_data of the fist inode we
can change that of course. Not sure what's the mess in the patch you're
talking about, could you elaborate?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.239 / U:7.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site