shadow@clusterfs.com
2007-Jan-15  09:16 UTC
[Lustre-devel] [Bug 10796] dbench 16 oops with lustre exported over NFS
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10796
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #9319 is|0                           |1
           obsolete|                            |
Created an attachment (id=9341)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9341&action=view)
minor changes
chages with last patch.
1. for set MDS_OPEN_OWNEROVERRIDE uses FMODE_WRITE instead of O_WRONLY.
2. few spaces cleanups.
green@clusterfs.com
2007-Jan-15  15:48 UTC
[Lustre-devel] [Bug 10796] dbench 16 oops with lustre exported over NFS
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10796
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9341|review?(green@clusterfs.com)|review+
               Flag|                            |
(From update of attachment 9341)
my comments are pretty minor this time.
I decided to correct some of your comments in hopes it would be easier to read
them later.
The only big change I still think we might need is that d_rehash();d_unhash();
change to init_list_head
of some sort, may be with configure check. Otherwise is good.
>@@ -383,10 +383,15 @@ int ll_file_open(struct inode *inode, st
>-                if (oit.it_flags & O_CREAT)
>+                /* kernel only call f_op->open in dentry_open.
calls
>+                 * filp_open call dentry_open after open_namei where check
result
filp_open calls dentry_open after call to open_namei that checks for
permissions.
>+                 * permision call. only nfsd_open call dentry_open directly
without
nfsd_open calls...
>+                 * check permision and because it this check is safe.
checking permissions and because of that this code below is safe.
>@@ -492,8 +501,7 @@ out_och_free:
>                 }
>                 up(&lli->lli_och_sem);
>         }
>-
>-        return rc;
>+        RETURN(rc);
> }
this change is wrong. Please drop it, we cannot reach it without going through
GOTO() and thta will print rc
in the log already.
>@@ -475,7 +477,13 @@ static int lookup_it_finish(struct ptlrp
>                         ll_d_add(*de, inode);
>                         spin_unlock(&dcache_lock);
>                 } else {
>-                        (*de)->d_inode = NULL; 
>+                        /* Lustre don`t want hash dentry if don`t have
lock,
We do not want to hash the dentry is we don''t have a lock.
>+                         * but if this dentry used for d_move kernel got
But if this dentry is later used in d_move, we''d hit uninitialised list
head
>+                         * panic when tried access to dentry->d_hash and
d_hash is NULL.
d_hash, so we just do this to
>+                         * init d_hash field but leave dentry unhashed.
(bug 10796)
>+                         */
>+                        d_rehash(*de);
>+                        d_drop(*de);
Now, I understand that we are trying to avoid having a configure check(s) as
different kernels might
have this different, but taking dcache lock twice is not exactly cheap either.
So it worth at least putting a comment here that just initialiseing list head
is possible here.
(in case we ever face perf problems due to this later)
Amd just doing a list head init is probably still much more desirable even at
the expense of one more configure check.
>+static int ll_new_node(struct inode *dir, struct qstr *name,
>+                          char *tgt, int mode,
>+                          int rdev, struct dentry *dchild)
> {
...
>+
>+        if (dchild) {
>+                err = ll_prep_inode(sbi->ll_osc_exp, &inode,
request, 0,
>+                                    dchild->d_sb);
>+                if (err)
>+                     GOTO(err_exit, err);
>+
>+                d_drop(dchild);
>+                d_instantiate(dchild, inode);
>+                EXIT;
>+        }
you need to move that EXIT here, after the bracket.
shadow@clusterfs.com
2007-Jan-16  08:43 UTC
[Lustre-devel] [Bug 10796] dbench 16 oops with lustre exported over NFS
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10796
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #9341 is|0                           |1
           obsolete|                            |
Created an attachment (id=9346)
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
 --> (https://bugzilla.lustre.org/attachment.cgi?id=9346&action=view)
add changelog entry
shadow@clusterfs.com
2007-Jan-29  22:15 UTC
[Lustre-devel] [Bug 10796] dbench 16 oops with lustre exported over NFS
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by using the following link: https://bugzilla.lustre.org/show_bug.cgi?id=10796 Created an attachment (id=9445) Please don''t reply to lustre-devel. Instead, comment in Bugzilla by using the following link: --> (https://bugzilla.lustre.org/attachment.cgi?id=9445&action=view) patch with fixes from b_releases_1_4_9 attaches patch includes two fixes founted while testing b_release_1_4_9 (and landed into b_release_1_4_8).
shadow@clusterfs.com
2007-Feb-01  09:20 UTC
[Lustre-devel] [Bug 10796] dbench 16 oops with lustre exported over NFS
Please don''t reply to lustre-devel. Instead, comment in Bugzilla by
using the following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10796
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stuart.mclaren@hp.com
*** Bug 11179 has been marked as a duplicate of this bug. ***