Alexander Viro wrote:
>
> On Sat, 28 Apr 2001, Martin Dalecki wrote:
>
> > I think in the context you are inventig the proposed function,
> > the drivers has allways an inode at hand. And contrary to what Linus
>
> Read the patch. Almost all cases are of the "loop over partitions of foo"
>
Alexander Viro wrote:
On Sat, 28 Apr 2001, Martin Dalecki wrote:
I think in the context you are inventig the proposed function,
the drivers has allways an inode at hand. And contrary to what Linus
Read the patch. Almost all cases are of the loop over partitions of foo
kind.
says,
On Sat, 28 Apr 2001, Martin Dalecki wrote:
> I think in the context you are inventig the proposed function,
> the drivers has allways an inode at hand. And contrary to what Linus
Read the patch. Almost all cases are of the "loop over partitions of foo"
kind.
> says, drivers not just know
Alexander Viro wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function? Actually, that's what I've done in namespace
>
Alexander Viro wrote:
On Fri, 27 Apr 2001, Alexander Viro wrote:
Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
either sync_dev() or fsync_dev(). What do you think about pulling that
into the same function? Actually, that's what I've done in namespace
patch
On Sat, 28 Apr 2001, Martin Dalecki wrote:
I think in the context you are inventig the proposed function,
the drivers has allways an inode at hand. And contrary to what Linus
Read the patch. Almost all cases are of the loop over partitions of foo
kind.
says, drivers not just know about
On Fri, 27 Apr 2001, Linus Torvalds wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
> >
> > PS: last time I've separated that part of patch was a couple months
> > ago. See if something similar to the variant below would be OK with
> > you (I'll rediff it):
>
> This one looks fine.
On Fri, 27 Apr 2001, Linus Torvalds wrote:
>
> On Fri, 27 Apr 2001, Alexander Viro wrote:
> >
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function?
>
> I'd actually
On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> PS: last time I've separated that part of patch was a couple months
> ago. See if something similar to the variant below would be OK with
> you (I'll rediff it):
This one looks fine.
Linus
-
To unsubscribe from this list: send
On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> either sync_dev() or fsync_dev(). What do you think about pulling that
> into the same function?
I'd actually prefer not. I don't think it makes sense from a conceptual
On Fri, 27 Apr 2001, Alexander Viro wrote:
> Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> either sync_dev() or fsync_dev(). What do you think about pulling that
> into the same function? Actually, that's what I've done in namespace
> patch (name being
On Fri, 27 Apr 2001, Linus Torvalds wrote:
> On Fri, 27 Apr 2001, Alexander Viro wrote:
> >
> > Each of these places is an oopsable race with umount. We can't fix them
> > without touching a lot of drivers. However, we can make the future fix
> > easier if we put the above into a helper
On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> Each of these places is an oopsable race with umount. We can't fix them
> without touching a lot of drivers. However, we can make the future fix
> easier if we put the above into a helper function. Patch below does that.
I don't like the name
A lot of drivers does the following:
sb = get_super(dev);
if (sb)
invalidate_inodes(sb);
Each of these places is an oopsable race with umount. We can't fix them
without touching a lot of drivers. However, we can make the future fix
easier if we put the above into a
On Fri, 27 Apr 2001, Alexander Viro wrote:
Each of these places is an oopsable race with umount. We can't fix them
without touching a lot of drivers. However, we can make the future fix
easier if we put the above into a helper function. Patch below does that.
I don't like the name
On Fri, 27 Apr 2001, Linus Torvalds wrote:
On Fri, 27 Apr 2001, Alexander Viro wrote:
Each of these places is an oopsable race with umount. We can't fix them
without touching a lot of drivers. However, we can make the future fix
easier if we put the above into a helper function. Patch
On Fri, 27 Apr 2001, Alexander Viro wrote:
Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
either sync_dev() or fsync_dev(). What do you think about pulling that
into the same function? Actually, that's what I've done in namespace
patch (name being invalidate_dev(),
On Fri, 27 Apr 2001, Alexander Viro wrote:
Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
either sync_dev() or fsync_dev(). What do you think about pulling that
into the same function?
I'd actually prefer not. I don't think it makes sense from a conceptual
On Fri, 27 Apr 2001, Alexander Viro wrote:
PS: last time I've separated that part of patch was a couple months
ago. See if something similar to the variant below would be OK with
you (I'll rediff it):
This one looks fine.
Linus
-
To unsubscribe from this list: send the
On Fri, 27 Apr 2001, Linus Torvalds wrote:
On Fri, 27 Apr 2001, Alexander Viro wrote:
Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
either sync_dev() or fsync_dev(). What do you think about pulling that
into the same function?
I'd actually prefer not. I
On Fri, 27 Apr 2001, Linus Torvalds wrote:
On Fri, 27 Apr 2001, Alexander Viro wrote:
PS: last time I've separated that part of patch was a couple months
ago. See if something similar to the variant below would be OK with
you (I'll rediff it):
This one looks fine.
Erm? It
21 matches
Mail list logo
