Re: [EXT4 set 3][PATCH 1/1] ext4 nanosecond timestamp
Aneesh Kumar K.V wrote:
Mingming Cao wrote:
On Tue, 2007-07-03 at 15:58 +0530, Kalpak Shah wrote:
On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
+
+#define EXT4_INODE_GET_XTIME(xtime, inode,
raw_inode) \
+do { \
+(inode)->xtime.tv_sec =
le32_to_cpu((raw_inode)->xtime); \
+if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ##
_extra)) \
+ext4_decode_extra_time(&(inode)->xtime, \
+ raw_inode->xtime ## _extra); \
+} while (0)
+
+#define EXT4_EINODE_GET_XTIME(xtime, einode,
raw_inode) \
+do { \
+if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime)) \
+(einode)->xtime.tv_sec =
le32_to_cpu((raw_inode)->xtime); \
+if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ##
_extra)) \
+ext4_decode_extra_time(&(einode)->xtime, \
+ raw_inode->xtime ## _extra); \
+} while (0)
+
This nanosecond patch seems to be missing the fix below which is
required for http://bugzilla.kernel.org/show_bug.cgi?id=5079
If the timestamp is set to before epoch i.e. a negative timestamp
then the file may have its date set into the future on 64-bit
systems. So when the timestamp is read it must be cast as signed.
Missed this one.
Thanks. Will update ext4 patch queue tonight with this fix.
IIRC in the conference call it was decided to not to apply this patch.
Andreas may be able to update better.
Looking at the git log i understand the core patch got applied to ext4 tree
with the comment
from Andreas. So may be we can apply this patch also.
commit 4d7bf11d649c72621ca31b8ea12b9c94af380e63
Andreas says:
This patch is now treating timestamps with the high bit set as negative
times (before Jan 1, 1970). This means we lose 1/2 of the possible range
of timestamps (lopping off 68 years before unix timestamp overflow -
now only 30 years away :-) to handle the extremely rare case of setting
timestamps into the distant past.
If we are only interested in fixing the underflow case, we could just
limit the values to 0 instead of storing negative values. At worst this
will skew the timestamp by a few hours for timezones in the far east
(files would still show Jan 1, 1970 in "ls -l" output).
That said, it seems 32-bit systems (mine at least) allow files to be set
into the past (01/01/1907 works fine) so it seems this patch is bringing
the x86_64 behaviour into sync with other kernels.
On the plus side, we have a patch that is ready to add nanosecond timestamps
to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
this extends the maximum date to 2242.
NOTE: The conference call i mentioned above is http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call
-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] locks: share more common lease code
On Tue, Jul 03, 2007 at 06:17:35PM -0400, J. Bruce Fields wrote: > On Sat, Jun 30, 2007 at 10:20:13AM +0100, Christoph Hellwig wrote: > > On Fri, Jun 29, 2007 at 03:21:25PM -0400, J. Bruce Fields wrote: > > > From: J. Bruce Fields <[EMAIL PROTECTED]> > > > > > > Share more code between setlease (used by nfsd) and fcntl. > > > > > > Also some minor cleanup. > > > > Looks good. Fine for mainline just after 2.6.23 opens. > > Thanks. (And, by the way, would it be helpful for me to translate this > kind of statement into an "acked-by: Christoph..." on the eventual > patch?) Fine with me. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> mount(8) doesn't include filesystem detection code anymore. You
> have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> (e2fsprogs) or libvolume_id (udev >= v110) is required.
Sorry, but it's really annoying to pull in a filesystem-specific devel
package for that. Having a library is fine, but please move the library
into util-linux so it's always available without another dependency. That
way xfsprogs could for example drop it's own detection library aswell.
> The package build system is now based on autotools. The build system
> supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> SUID_LDFLAGS). For more details see the README file
And this is really dumb. autotools is a completely pain in the ass and
not useful at all for linux-only tools.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Wed, 4 Jul 2007 09:42:11 +0100
> On Wed, Jul 04, 2007 at 12:11:56AM +0200, Karel Zak wrote:
> > mount(8) doesn't include filesystem detection code anymore. You
> > have to compile --with-fsprobe={blkid,volume_id}, and libblkid
> > (e2fsprogs) or libvolume_id (udev >= v110) is required.
>
> Sorry, but it's really annoying to pull in a filesystem-specific devel
> package for that. Having a library is fine, but please move the library
> into util-linux so it's always available without another dependency. That
> way xfsprogs could for example drop it's own detection library aswell.
I totally agree with Christophe, this dependency is a complete
pain for trying to do util-linux-ng development. I meant to
complain about this myself.
> > The package build system is now based on autotools. The build system
> > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS,
> > SUID_LDFLAGS). For more details see the README file
>
> And this is really dumb. autotools is a completely pain in the ass and
> not useful at all for linux-only tools.
I second this sentiment as well. It's not like we expect this stuff
to get used on other systems at all, and the only thing it's getting
used for really is to detect the awful external blkid/volume_id
dependencies.
I totally think this stuff can and should be completely eliminated.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
On Jul 4 2007 00:11, Karel Zak wrote: >newgrp: > add support for /etc/gshadow > check result from getgrnam() more carefully Hm, gshadow looks like it is really obsolete. (There is no such file anymore in suse releases since a long while. Previously, gshadow was filled with all the groups that existed.) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [EXT4 set 3][PATCH 1/1] ext4 nanosecond timestamp
On Jul 04, 2007 12:06 +0530, Aneesh Kumar K.V wrote:
> Mingming Cao wrote:
> >On Tue, 2007-07-03 at 15:58 +0530, Kalpak Shah wrote:
> >>On Sun, 2007-07-01 at 03:36 -0400, Mingming Cao wrote:
> >>>+
> >>>+#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode) \
> >>>+do { \
> >>>+ (inode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime);
> >>>\
> >>>+ if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra))
> >>>\
> >>>+ ext4_decode_extra_time(&(inode)->xtime,
> >>>\
> >>>+ raw_inode->xtime ## _extra);
> >>>\
> >>>+} while (0)
> >>>+
> >>>+#define EXT4_EINODE_GET_XTIME(xtime, einode, raw_inode)\
> >>>+do { \
> >>>+ if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime))
> >>>\
> >>>+ (einode)->xtime.tv_sec = le32_to_cpu((raw_inode)->xtime);
> >>>\
> >>>+ if (EXT4_FITS_IN_INODE(raw_inode, einode, xtime ## _extra))
> >>>\
> >>>+ ext4_decode_extra_time(&(einode)->xtime,
> >>>\
> >>>+ raw_inode->xtime ## _extra);
> >>>\
> >>>+} while (0)
> >>>+
> >>This nanosecond patch seems to be missing the fix below which is
> >>required for http://bugzilla.kernel.org/show_bug.cgi?id=5079
> >>
> >>If the timestamp is set to before epoch i.e. a negative timestamp then
> >>the file may have its date set into the future on 64-bit systems. So
> >>when the timestamp is read it must be cast as signed.
> >
> >Missed this one.
> >Thanks. Will update ext4 patch queue tonight with this fix.
>
> IIRC in the conference call it was decided to not to apply this patch.
> Andreas may be able to update better.
I wasn't on the most recent concall, and I've forgotten the details of
any discussion on a previous concall.
Care really needs to be taken here that negative timestamps are handled
properly. We can take the sign bit from the inode i_*time, but then we
need to change the load/save of the extra time to use a shift of 31
instead of 32. If we overflow the epoch we have to ensure that the high
bits of the seconds is handled correctly.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
(sorry for the late reply, just got back from holiday) On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > As I mentioned in my Linux.conf.au presentation a year and a half ago, > the main use of Streams in Windows to date has been for system > crackers to hide trojan horse code and rootkits so that system > administrators couldn't find them. :-) The only valid use of Streams in Windows I've seen was a virus checker that stored a hash of the file in a separate stream. Checking a file was a matter of rehashing it and comparing against the hash stored in the special hash data stream for that particular file. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: [ANNOUNCE] util-linux-ng 2.13-rc1
Hi Karel :) * Karel Zak <[EMAIL PROTECTED]> dixit: > The package build system is now based on autotools. The build system > supports separate CFLAGS and LDFLAGS for suid programs (SUID_CFLAGS, > SUID_LDFLAGS). For more details see the README file If you want to have configurable installation directories and configurable settings for building but with the pain of autotools, you can give "mobs" a try if you want. You will find in my homepage (see my signature below). If you find it so much big and/or you think you will be changing a pain for another pain, I can help porting. Anyway, if you don't like mobs or you just don't want to try it, that's fine, but please don't use autotools, it doesn't make much sense for a linux only project, since you will be using only the "directory choosing" part of autotools. Maybe a hand made script will help (and I can help with that, too) if you just want to have selectable directories and CFLAGS support... And thanks for util-linux-ng, I was waiting for them :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen! - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Versioning file system
On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote: > (sorry for the late reply, just got back from holiday) > > On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > > As I mentioned in my Linux.conf.au presentation a year and a half ago, > > the main use of Streams in Windows to date has been for system > > crackers to hide trojan horse code and rootkits so that system > > administrators couldn't find them. :-) > > The only valid use of Streams in Windows I've seen was a virus checker > that stored a hash of the file in a separate stream. Checking a file > was a matter of rehashing it and comparing against the hash stored in > the special hash data stream for that particular file. And even that's not a valid use. All the virus would have to do is to infect the file, and then update the "special hash data stream". Why is it that when programmers are told about streams as a potential technology choice, it makes their thinking become fuzzy? :-) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] locks: rename lease functions to reflect locks.c conventions
On Sat, Jun 30, 2007 at 10:22:43AM +0100, Christoph Hellwig wrote: > On Fri, Jun 29, 2007 at 03:21:27PM -0400, J. Bruce Fields wrote: > > From: J. Bruce Fields <[EMAIL PROTECTED]> > > > > We've been using the convention that vfs_foo is the function that calls > > a filesystem-specific foo method if it exists, or falls back on a > > generic method if it doesn't. > > > > So rename setlease to vfs_setlease, and __setlease to setlease. Keep > > setlease exported to allow filesystems to use the generic method in > > addition to doing their own bookkeeping. > > This should be moved before patch 2 and can probably go in once 2.6.23 > opens aswell. > > > @@ -1339,7 +1339,7 @@ int fcntl_getlease(struct file *filp) > > * > > * Called with kernel lock held. > > */ > > -static int __setlease(struct file *filp, long arg, struct file_lock **flp) > > +int setlease(struct file *filp, long arg, struct file_lock **flp) > > Except this shouldn't be made non-static in this patch. > > > extern int setlease(struct file *, long, struct file_lock **); > > And this prototype shouldn't be kept. If you want to use it somewhere > later in the patch series make it non-static and export it in a separate > patch. If it's ever intended to be export it should probably get a > better name aswell, e.g. generic_setlease. OK, done.--b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] locks: fix locks.c lease symbol exports
On Sat, Jun 30, 2007 at 10:23:45AM +0100, Christoph Hellwig wrote: > On Fri, Jun 29, 2007 at 03:21:28PM -0400, J. Bruce Fields wrote: > > From: J. Bruce Fields <[EMAIL PROTECTED]> > > > > Bring lease exports into line with conventions for posix locks: > > setlease() should be exported so filesystems can use it to implement > > their lease methods. > > vfs_setlease() need only be GPL-exported since only nfsd > > needs it. > > The latter should be merged in the previous patch, the first should > be a patch with making it non-static and exporting it. (after the > rename of it is merged into the patch that introduces the vfs_setlease > name) Done.--b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] gfs2: stop giving out non-cluster-coherent leases
On Sat, Jun 30, 2007 at 10:27:42AM +0100, Christoph Hellwig wrote:
> On Fri, Jun 29, 2007 at 03:21:29PM -0400, J. Bruce Fields wrote:
> > +static int gfs2_setlease(struct file *file, long arg, struct file_lock
> > **fl)
> > +{
> > + struct gfs2_sbd *sdp = GFS2_SB(file->f_mapping->host);
> > + int ret = -EOPNOTSUPP;
> > +
> > + if (sdp->sd_args.ar_localflocks) {
> > + return setlease(file, arg, fl);
> > + }
> > +
> > + /* For now fail the delegation request. Cluster file system can not
> > + allow any node in the cluster to get a local lease until it can
> > + be managed centrally by the cluster file system.
> > + */
> > + return ret;
> > +}
>
> Very odd way to write this function. It should look more like:
Agreed; I've reversed the sense of the test, as suggested, and got rid
of the superfluous local "ret".
--b.
> static int gfs2_setlease(struct file *file, long arg, struct file_lock **fl)
> {
> struct gfs2_sbd *sdp = GFS2_SB(file->f_mapping->host);
> int ret = -EOPNOTSUPP;
>
> /*
>* For now fail the delegation request. Cluster file system can not
>* allow any node in the cluster to get a local lease until it can
>* be managed centrally by the cluster file system.
>*/
> if (!sdp->sd_args.ar_localflocks)
> return -EOPNOTSUPP;
>
> return setlease(file, arg, fl);
> }
>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] nfs: disable leases over NFS
On Sat, Jun 30, 2007 at 10:25:16AM +0100, Christoph Hellwig wrote: > On Fri, Jun 29, 2007 at 03:21:30PM -0400, J. Bruce Fields wrote: > > From: J. Bruce Fields <[EMAIL PROTECTED]> > > > > As Peter Staubach says elsewhere > > (http://marc.info/?l=linux-kernel&m=118113649526444&w=2): > > > > > The problem is that some file system such as NFSv2 and NFSv3 do > > > not have sufficient support to be able to support leases correctly. > > > In particular for these two file systems, there is no over the wire > > > protocol support. > > > > > > Currently, these two file systems fail the fcntl(F_SETLEASE) call > > > accidentally, due to a reference counting difference. These file > > > systems should fail more consciously, with a proper error to > > > indicate that the call is invalid for them. > > > > Define an nfs setlease method that just returns -EOPNOTSUPP. > > > > If someone can demonstrate a real need, perhaps we could reenable > > them in the presence of the "nolock" mount option. > > I'm not a big fan of default methods that do the wrong thing instead > of just missing functionality. Would you mind just returning > -EOPNOTSUPP if ->setlease is not implemented and add it to all > the local filesystems while all the network/distributed filesystems > should not have it, not just nfs. OK, I think that may make sense, but... wow does linux ever have a lot of obscure filesystems. This might take me a little longer. --b. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dio: remove bogus refcounting BUG_ON
On Tue, 2007-07-03 at 15:28 -0700, Zach Brown wrote:
> Linus, Andrew, please apply the bug fix patch at the end of this reply
> for .22.
>
> > >>One of our perf. team ran into this while doing some runs.
> > >>I didn't see anything obvious - it looks like we converted
> > >>async IO to synchronous one. I didn't spend much time digging
> > >>around.
>
> OK, I think this BUG_ON() is just broken. I wasn't able to find any
> obvious bugs from reading the code which would cause the BUG_ON() to
> fire. If it's reproducible I'd love to hear what the recipe is.
>
> I did notice that this BUG_ON() is evaluating dio after having dropped
> it's ref :/. So it's not completely absurd to fear that it's a race
> with the dio's memory being reused, but that'd be a pretty tight race.
>
> Let's remove this stupid BUG_ON and see if that test box still has
> trouble. It might just hit the valid BUG_ON a few lines down, but this
> unsafe BUG_ON needs to go.
I went through the code multiple times, I can't find how we can trigger
the BUG_ON(). But unfortunately, our perf. team is able reproduce the
problem. Debug indicated that, the ret2 == 1 :(
Not sure how that can happen. Ideas ?
Thanks,
Badari
>
> ---
>
> dio: remove bogus refcounting BUG_ON
>
> Badari Pulavarty reported a case of this BUG_ON is triggering during
> testing. It's completely bogus and should be removed.
>
> It's trying to notice if we left references to the dio hanging around in
> the sync case. They should have been dropped as IO completed while this
> path was in dio_await_completion(). This condition will also be
> checked, via some twisty logic, by the BUG_ON(ret != -EIOCBQUEUED) a few
> lines lower. So to start this BUG_ON() is redundant.
>
> More fatally, it's dereferencing dio-> after having dropped its
> reference. It's only safe to dereference the dio after releasing the
> lock if the final reference was just dropped. Another CPU might free
> the dio in bio completion and reuse the memory after this path drops the
> dio lock but before the BUG_ON() is evaluated.
>
> This patch passed aio+dio regression unit tests and aio-stress on ext3.
>
> Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
> Cc: Badari Pulavarty <[EMAIL PROTECTED]>
>
> diff -r 509ce354ae1b fs/direct-io.c
> --- a/fs/direct-io.c Sun Jul 01 22:00:49 2007 +
> +++ b/fs/direct-io.c Tue Jul 03 14:56:41 2007 -0700
> @@ -1106,7 +1106,7 @@ direct_io_worker(int rw, struct kiocb *i
> spin_lock_irqsave(&dio->bio_lock, flags);
> ret2 = --dio->refcount;
> spin_unlock_irqrestore(&dio->bio_lock, flags);
> - BUG_ON(!dio->is_async && ret2 != 0);
> +
> if (ret2 == 0) {
> ret = dio_complete(dio, offset, ret);
> kfree(dio);
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dio: remove bogus refcounting BUG_ON
On Wed, Jul 04, 2007 at 07:25:10PM -0700, Badari Pulavarty wrote:
> On Tue, 2007-07-03 at 15:28 -0700, Zach Brown wrote:
> > Linus, Andrew, please apply the bug fix patch at the end of this reply
> > for .22.
> >
> > > >>One of our perf. team ran into this while doing some runs.
> > > >>I didn't see anything obvious - it looks like we converted
> > > >>async IO to synchronous one. I didn't spend much time digging
> > > >>around.
> >
> > OK, I think this BUG_ON() is just broken. I wasn't able to find any
> > obvious bugs from reading the code which would cause the BUG_ON() to
> > fire. If it's reproducible I'd love to hear what the recipe is.
> >
> > I did notice that this BUG_ON() is evaluating dio after having dropped
> > it's ref :/. So it's not completely absurd to fear that it's a race
> > with the dio's memory being reused, but that'd be a pretty tight race.
> >
> > Let's remove this stupid BUG_ON and see if that test box still has
> > trouble. It might just hit the valid BUG_ON a few lines down, but this
> > unsafe BUG_ON needs to go.
>
> I went through the code multiple times, I can't find how we can trigger
> the BUG_ON(). But unfortunately, our perf. team is able reproduce the
> problem. Debug indicated that, the ret2 == 1 :(
>
> Not sure how that can happen. Ideas ?
Does it trigger even if you avoid referencing dio in the BUG_ON(), i.e.
with something like ...
--- direct-io.c 2007-07-02 01:24:24.0 +0530
+++ direct-io-debug.c 2007-07-05 09:18:56.0 +0530
@@ -1104,9 +1104,10 @@ direct_io_worker(int rw, struct kiocb *i
* decide to wake the submission path atomically.
*/
spin_lock_irqsave(&dio->bio_lock, flags);
+ is_async = dio->is_async;
ret2 = --dio->refcount;
spin_unlock_irqrestore(&dio->bio_lock, flags);
- BUG_ON(!dio->is_async && ret2 != 0);
+ BUG_ON(!is_async && ret2 != 0);
if (ret2 == 0) {
ret = dio_complete(dio, offset, ret);
kfree(dio);
>
> Thanks,
> Badari
>
> >
> > ---
> >
> > dio: remove bogus refcounting BUG_ON
> >
> > Badari Pulavarty reported a case of this BUG_ON is triggering during
> > testing. It's completely bogus and should be removed.
> >
> > It's trying to notice if we left references to the dio hanging around in
> > the sync case. They should have been dropped as IO completed while this
> > path was in dio_await_completion(). This condition will also be
> > checked, via some twisty logic, by the BUG_ON(ret != -EIOCBQUEUED) a few
> > lines lower. So to start this BUG_ON() is redundant.
> >
> > More fatally, it's dereferencing dio-> after having dropped its
> > reference. It's only safe to dereference the dio after releasing the
> > lock if the final reference was just dropped. Another CPU might free
> > the dio in bio completion and reuse the memory after this path drops the
> > dio lock but before the BUG_ON() is evaluated.
> >
> > This patch passed aio+dio regression unit tests and aio-stress on ext3.
> >
> > Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
> > Cc: Badari Pulavarty <[EMAIL PROTECTED]>
> >
> > diff -r 509ce354ae1b fs/direct-io.c
> > --- a/fs/direct-io.cSun Jul 01 22:00:49 2007 +
> > +++ b/fs/direct-io.cTue Jul 03 14:56:41 2007 -0700
> > @@ -1106,7 +1106,7 @@ direct_io_worker(int rw, struct kiocb *i
> > spin_lock_irqsave(&dio->bio_lock, flags);
> > ret2 = --dio->refcount;
> > spin_unlock_irqrestore(&dio->bio_lock, flags);
> > - BUG_ON(!dio->is_async && ret2 != 0);
> > +
> > if (ret2 == 0) {
> > ret = dio_complete(dio, offset, ret);
> > kfree(dio);
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
vm/fs meetup details
Hi, The vm/fs meetup will be held September 4th from 10am till 4pm (with the option of going longer), at the University of Cambridge. Anton Altaparmakov has arranged a conference room for us with whiteboard and projector, so many thanks to him. I will send out the location and plans for meeting/getting there after we work out the best strategy for that. At the moment we have 15 people interested so far. We can have a few more people, so if you aren't cc'ed and would like to come along please let me know. We do have limited space, so I'm sorry in advance if anybody misses out. I'll post out a running list of suggested topics later, but they're really just a rough guideline. It will be a round-table kind of thing and long monologue talks won't be appropriate, however some slides or whiteboarding to interactively introduce and discuss your idea would be OK. I think we want to avoid assigning slots for specific people/topics. Feel free to propose anything, if it only gets a small amount of interest then at least you'll know who to discuss it with later :) Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
