Tejun Heo <tj@xxxxxxxxxx> writes: > Hello, Eric. > > Eric W. Biederman wrote: >> A couple of weeks ago I found myself looking at the uio, seeing that >> it does not support pci hot-unplug, and thinking "Great yet another >> implementation of hotunplug logic that needs to be added". >> >> I decided to see what it would take to add a generic implementation of >> the code we have for supporting hot unplugging devices in sysfs, proc, >> sysctl, tty_io, and now almost in the tun driver. >> >> Not long after I touched the tun driver and made it safe to delete the >> network device while still holding it's file descriptor open I someone >> else touch the code adding a different feature and my careful work >> went up in flames. Which brought home another point at the best of it >> this is ultimately complex tricky code that subsystems should not need >> to worry about. > > I like the way it's headed. I'm trying to add similar 'revoke' or > 'sever' mechanism at block and char device layers so that low level > drivers don't have to worry about object lifetimes and so on. Doing > it at the file layer makes sense and can probably replace whatever > mechanism at the chardev. > > The biggest obstacle was the extra in-use reference count overhead. I > thought it could be solved by implementing generic percpu reference > count similar to the one used for module reference counting. Hot path > overhead could be reduced to local_t cmpxchg (w/o LOCK prefix) on > per-cpu variable + one branch, which was pretty good. The problem was > that space and access overhead for dynamic per-cpu variables wasn't > too good, so I started working on dynamic percpu allocator. > > The dynamic per-cpu allocator is pretty close to completion. Only > several archs need to be converted and it's likely to happen during > next few months. The plan after that was 1. add per-cpu local_t > accessors (might replace local_t completely) 2. add generic per-cpu > reference counter and move module reference counting to it > 3. implement block/chardev sever (or revoke) support. > > I think #3 can be merged with what you're working on. What do you > think? Sounds reasonable. Do you know of a case where we actually have multiple tasks accessing a file simultaneously? I just instrumented up my patch an so far the only case I have found are multiple processes closing the same file. Some weird part of bash forking extra processes. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
