On Thu, Apr 11, 2013 at 01:48:26PM -0700, Eric W. Biederman wrote:
> Last time I was looking at this I was noticing that there is a lock
> (mmap_sem?) that is held over every ->vm_op->foo() call. If that is
> true today it should be possible to just grab that lock and change
> vm_ops. That
Al Viro writes:
> On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
>> 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
>> remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
>> now it's going away. What should we do to its VMAs? Right now sysfs
Al Viro v...@zeniv.linux.org.uk writes:
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
4) nasty semantics issue - mmap() vs. revoke (of any sort, including
remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
now it's going away. What should we do to its VMAs?
On Thu, Apr 11, 2013 at 01:48:26PM -0700, Eric W. Biederman wrote:
Last time I was looking at this I was noticing that there is a lock
(mmap_sem?) that is held over every -vm_op-foo() call. If that is
true today it should be possible to just grab that lock and change
vm_ops. That makes for
Al Viro wrote:
> BTW, snd_card_disconnect() doesn't do anything to existing mappings; smells
> like a bug, and there we do have ones with non-trivial ->mmap(). Could
> ALSA folks comment?
I don't know of any hotplug sound driver that maps memory from a device.
All hotplug buses (PCIe, USB,
Al Viro wrote:
BTW, snd_card_disconnect() doesn't do anything to existing mappings; smells
like a bug, and there we do have ones with non-trivial -mmap(). Could
ALSA folks comment?
I don't know of any hotplug sound driver that maps memory from a device.
All hotplug buses (PCIe, USB, FireWire)
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
> 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
> remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
> now it's going away. What should we do to its VMAs? Right now sysfs
> and procfs get away
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
> 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
> remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
> now it's going away. What should we do to its VMAs? Right now sysfs
> and procfs get away
On Fri, Apr 05, 2013 at 09:51:37PM +0100, Al Viro wrote:
> On Fri, Apr 05, 2013 at 12:56:09PM -0700, Greg Kroah-Hartman wrote:
> > > 4) nasty semantics issue - mmap() vs. revoke (of any sort, including
> > > remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
> > > now it's
On Fri, Apr 05, 2013 at 12:56:09PM -0700, Greg Kroah-Hartman wrote:
> Which methods do you mean here?
file->f_op->some_method()
> The vfs core would call start_using(), or would filesystems / drivers
> need to do this?
The former; we have relatively few places that call file_operations
members
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
> After some digging in procfs logics for revoking further file IO after
> remove_proc_entry() (and figuring out what to do for debugfs - it also
> needs something similar), I think I've got something that has potential
> to become a working
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
After some digging in procfs logics for revoking further file IO after
remove_proc_entry() (and figuring out what to do for debugfs - it also
needs something similar), I think I've got something that has potential
to become a working
On Fri, Apr 05, 2013 at 12:56:09PM -0700, Greg Kroah-Hartman wrote:
Which methods do you mean here?
file-f_op-some_method()
The vfs core would call start_using(), or would filesystems / drivers
need to do this?
The former; we have relatively few places that call file_operations
members
On Fri, Apr 05, 2013 at 09:51:37PM +0100, Al Viro wrote:
On Fri, Apr 05, 2013 at 12:56:09PM -0700, Greg Kroah-Hartman wrote:
4) nasty semantics issue - mmap() vs. revoke (of any sort, including
remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
now it's going away.
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
4) nasty semantics issue - mmap() vs. revoke (of any sort, including
remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
now it's going away. What should we do to its VMAs? Right now sysfs
and procfs get away with
On Fri, Apr 05, 2013 at 05:29:32AM +0100, Al Viro wrote:
4) nasty semantics issue - mmap() vs. revoke (of any sort, including
remove_proc_entry(), etc.). Suppose a revokable file had been mmapped;
now it's going away. What should we do to its VMAs? Right now sysfs
and procfs get away with
After some digging in procfs logics for revoking further file IO after
remove_proc_entry() (and figuring out what to do for debugfs - it also
needs something similar), I think I've got something that has potential
to become a working revoke(2) with very low overhead. It will require
some
After some digging in procfs logics for revoking further file IO after
remove_proc_entry() (and figuring out what to do for debugfs - it also
needs something similar), I think I've got something that has potential
to become a working revoke(2) with very low overhead. It will require
some
18 matches
Mail list logo
