Messages in this thread |  | | | Date | Tue, 2 Jun 2009 10:08:14 +0300 | | Subject | Re: [PATCH 04/23] vfs: Introduce infrastructure for revoking a file | | From | Pekka Enberg <> |
| |
Hi Eric,
On Tue, Jun 2, 2009 at 9:51 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Pekka Enberg <penberg@cs.helsinki.fi> writes: > >> Hi Eric, >> >> On Tue, Jun 2, 2009 at 12:50 AM, Eric W. Biederman >> <ebiederm@xmission.com> wrote: >>> +#ifdef CONFIG_FILE_HOTPLUG >>> + >>> +static bool file_in_use(struct file *file) >>> +{ >>> + struct task_struct *leader, *task; >>> + bool in_use = false; >>> + int i; >>> + >>> + rcu_read_lock(); >>> + do_each_thread(leader, task) { >>> + for (i = 0; i < MAX_FILE_HOTPLUG_LOCK_DEPTH; i++) { >>> + if (task->file_hotplug_lock[i] == file) { >>> + in_use = true; >>> + goto found; >>> + } >>> + } >>> + } while_each_thread(leader, task); >>> +found: >>> + rcu_read_unlock(); >>> + return in_use; >>> +} >> >> This seems rather heavy-weight. If we're going to use this >> infrastructure for forced unmount, I think this will be a problem. > >> Can't we two this in two stages: (1) mark a bit that forces >> file_hotplug_read_trylock to always fail and (2) block until the last >> remaining in-kernel file_hotplug_read_unlock() has executed? > > Yes there is room for more optimization in the slow path. > I haven't noticed being a problem yet so I figured I would start > with stupid and simple.
Yup, just wanted to point it out.
On Tue, Jun 2, 2009 at 9:51 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > I can easily see two passes. The first setting the flag an calling > f_op->dead. The second some kind of consolidate walk through the task > list, allowing checking on multiple files at once. > > I'm not ready to consider anything that will add cost to the fast > path in the file descriptors though.
Makes sense.
Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |