Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Oleg Nesterov
On 08/13, Jan Kara wrote: > > On Thu 13-08-15 15:36:16, Oleg Nesterov wrote: > > On 08/13, Jan Kara wrote: > > > > > > Looking into this again, it would seem somewhat cleaner to me to move the > > > destruction to deactivate_locked_super() instead. > > > > Heh ;) You know, I was looking at

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Jan Kara
On Thu 13-08-15 15:36:16, Oleg Nesterov wrote: > On 08/13, Jan Kara wrote: > > > > On Tue 11-08-15 19:04:16, Oleg Nesterov wrote: > > > > > > So this is just the temporary kludge which helps us to avoid the > > > conflicts with the changes which will be (hopefully) routed via > > > rcu tree. > > >

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Oleg Nesterov
On 08/13, Jan Kara wrote: > > On Tue 11-08-15 19:04:16, Oleg Nesterov wrote: > > > > So this is just the temporary kludge which helps us to avoid the > > conflicts with the changes which will be (hopefully) routed via > > rcu tree. > > > > Signed-off-by: Oleg Nesterov > > Looking into this again,

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Jan Kara
On Tue 11-08-15 19:04:16, Oleg Nesterov wrote: > Of course, this patch is ugly as hell. It will be (partially) > reverted later. We add it to ensure that other WIP changes in > percpu_rw_semaphore won't break fs/super.c. > > We do not even need this change right now, percpu_free_rwsem() > is fine

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Jan Kara
On Tue 11-08-15 19:04:16, Oleg Nesterov wrote: Of course, this patch is ugly as hell. It will be (partially) reverted later. We add it to ensure that other WIP changes in percpu_rw_semaphore won't break fs/super.c. We do not even need this change right now, percpu_free_rwsem() is fine in

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Jan Kara
On Thu 13-08-15 15:36:16, Oleg Nesterov wrote: On 08/13, Jan Kara wrote: On Tue 11-08-15 19:04:16, Oleg Nesterov wrote: So this is just the temporary kludge which helps us to avoid the conflicts with the changes which will be (hopefully) routed via rcu tree. Signed-off-by:

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Oleg Nesterov
On 08/13, Jan Kara wrote: On Tue 11-08-15 19:04:16, Oleg Nesterov wrote: So this is just the temporary kludge which helps us to avoid the conflicts with the changes which will be (hopefully) routed via rcu tree. Signed-off-by: Oleg Nesterov o...@redhat.com Looking into this again,

Re: [PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-13 Thread Oleg Nesterov
On 08/13, Jan Kara wrote: On Thu 13-08-15 15:36:16, Oleg Nesterov wrote: On 08/13, Jan Kara wrote: Looking into this again, it would seem somewhat cleaner to me to move the destruction to deactivate_locked_super() instead. Heh ;) You know, I was looking at

[PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-11 Thread Oleg Nesterov
Of course, this patch is ugly as hell. It will be (partially) reverted later. We add it to ensure that other WIP changes in percpu_rw_semaphore won't break fs/super.c. We do not even need this change right now, percpu_free_rwsem() is fine in atomic context. But we are going to change this, it

[PATCH v2 7/8] shift percpu_counter_destroy() into destroy_super_work()

2015-08-11 Thread Oleg Nesterov
Of course, this patch is ugly as hell. It will be (partially) reverted later. We add it to ensure that other WIP changes in percpu_rw_semaphore won't break fs/super.c. We do not even need this change right now, percpu_free_rwsem() is fine in atomic context. But we are going to change this, it