Ah, that's what I had in mind while writing my last email, I thought the
rcu_head and the parameters to the call_rcu were living in the
files_struct. I should have better checked the code. In short
rcu_fd_array and friend are just artificial structs dynamically
allocated just for the purpose of the rcu freeing of the memory. This
has the advantage of also saving some byte during production, and of
course my suggestion to take rcu_head at the end of the struct was in
turn flawed as well, it's not going to make a real difference since the
rcu_head will be used during call_rcu anyways and the rcu freeing path
has to be a very uncommon path in first place.
> out as we are not freeing the entire files_struct but a couple of fields in
> it. So it may happen that before the callback for one files_struct is processed
> we queue another one for the same files_struct.
I see, the dynamic allocation of the rcu_fd_array and friend solve the
multiple call_rcu on the same files_struct problem very cleanly.
Ok, so please forget my last email, your last patch looks fine. Thanks!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/