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 resultfilp_open calls dentry_open after call to open_namei that checks for permissions.>+ * permision call. only nfsd_open call dentry_open directly withoutnfsd_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 gotBut 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. ***