search for: active_stack

Hi, All, These four patches are all related to ocfs2 on hard readonly mount. patch 1 fix oops when umount ocfs2 on hard readonly device. Because ocfs2_dismount_volume() will call ocfs2_cluster_hangup() and then call ocfs2_stack_driver_put(), will hit BUG_ON(active_stack == NULL). patch 2 fix oops when do ls or cat in ocfs2 on hard readonly device. Because ocfs2_open_lock() will call ocfs2_cluster_lock() and then call ocfs2_dlm_lock(), but active_stack is NULL. patch 3 fix bug of http://oss.oracle.com/bugzilla/show_bug.cgi?id=1322 ocfs2_statfs, ocfs2_fiemap, ocf...

...OL_GPL(ocfs2_dlm_lock_status); -/* - * Why don't we cast to ocfs2_meta_lvb? The "clean" answer is that we - * don't cast at the glue level. The real answer is that the header - * ordering is nigh impossible. - */ +int ocfs2_dlm_lvb_valid(union ocfs2_dlm_lksb *lksb) +{ + return active_stack->sp_ops->lvb_valid(lksb); +} +EXPORT_SYMBOL_GPL(ocfs2_dlm_lvb_valid); + void *ocfs2_dlm_lvb(union ocfs2_dlm_lksb *lksb) { return active_stack->sp_ops->lock_lvb(lksb); diff --git a/fs/ocfs2/stackglue.h b/fs/ocfs2/stackglue.h index c571af3..03a44d6 100644 --- a/fs/ocfs2/stackglue.h ++...

The only non-fix here is Joel's new configfs convenience macros, but nobody is using them yet, so I think the patch is safe. By the way, these patches (as usual) are all rebased on top of your latest tree. I think that since the vast majority of ocfs2 and configfs patches are self-contained and within a small area of the kernel that this should probably be fine. If you feel otherwise however,

The following series of patches comprises the bulk of our outstanding changes for Ocfs2. Aside from the usual set of cleanups and fixes that were inappropriate for 2.6.25, there are a few highlights: The '/sys/o2cb' directory has been moved to '/sys/fs/o2cb'. The new location meshes better with modern sysfs layout. A symbolic link has been placed in the old location so as to