Ext3 users - Sep 2002 - ->journal_info sharing

Hello, Stephen,

It seem that in the presence of several jornalling file systems in the
kernel some mechanism is needed for proper sharing of the ->journal_info
pointer in the task_struct.

One journalled file system can indirectly call another during page fault
in copy_from_user, quota file modification, or

__alloc_pages()->balance_classzone()->shrink_cache()->vm_writeback()

sequence. (Actually, I don't understand when prevents ext3 from
re-entering itself in such a case.)

Can we replace 

struct task_struct {
  ...
  void *journal_info;
};

with 

struct fs_activation;

struct fs_activation {
  struct super_block   *super;
  struct fs_activation *parent;
};

struct task_struct {
  ...
  struct fs_activation *journal_info;
};

Such that each file system can store original ->journal_info in the
->parent field and restore it on exit.

All fs_activation for nested file system calls are then chained through
->parent's and file system can easily check whether it is already in the
call chain, etc.

Of course, fs_activation will be actually embedded into file system
specific data structure (handle_t for ext3, reiser4_context for reiser4).

Does this make sense?

Nikita.

Hi,

On Thu, Sep 26, 2002 at 02:05:57PM +0400, Nikita Danilov wrote:
 
> It seem that in the presence of several jornalling file systems in the
> kernel some mechanism is needed for proper sharing of the ->journal_info
> pointer in the task_struct.
Yep.
> One journalled file system can indirectly call another during page fault
> in copy_from_user, quota file modification, or
> 
>
__alloc_pages()->balance_classzone()->shrink_cache()->vm_writeback()
> 
> sequence. (Actually, I don't understand when prevents ext3 from
> re-entering itself in such a case.)
Ext3 just has to be very, very careful either to be prepared for the
recursion in advance, or to avoid it by controlling when objects
appear dirty to the VM above, or to detect the recusion and back out,
marking the object still-dirty so that it gets flushed again later.
The ext3_writepage() code, for example, exits with a noop and does a
SetPageDirty if it detects a recursion.
> struct task_struct {
>   ...
>   void *journal_info;
> };
> 
> with 
> 
> struct fs_activation;
> 
> struct fs_activation {
>   struct super_block   *super;
>   struct fs_activation *parent;
> };
Well, the jbd layer is in theory usable in cases where there's no
super_block (eg. a journaled soft raid5 layer), so a generic "void *
owner" might be more appropriate.  And having to allocate a new object
each time makes little sense: for ext3, we already have lightweight
per-task handles, so embedding the fs_activation in that would make
more sense for me, and having a pointer to the parent in the
activation object makes little sense if that object is already in the
parent.

So I'd just say let's do

struct fs_activation {
	void * owner;
}

and then whatever object we currently point journal_info at can simply
be required to have a fs_activation object inside it as the first
field in the struct.

If we do that, then the "owner *" cookie is an adequate uniqifier, and
we don't need any other pointers in the fs_activation itself because a
simple cast is enough to get us to the parent object.

Cheers,
 Stephen