On Fri, Jun 15, 2018 at 06:47:17AM +0100, Al Viro wrote:
> On Wed, Jun 13, 2018 at 11:21:30AM +0200, Miklos Szeredi wrote:
> > Looked at some other options... What coda mmap does looks very
> > dubious. It only sets f_mapping, not vm_file. That's going to get
> > into all sorts of trouble when
On Fri, Jun 15, 2018 at 06:47:17AM +0100, Al Viro wrote:
> On Wed, Jun 13, 2018 at 11:21:30AM +0200, Miklos Szeredi wrote:
> > Looked at some other options... What coda mmap does looks very
> > dubious. It only sets f_mapping, not vm_file. That's going to get
> > into all sorts of trouble when
On Wed, Jun 13, 2018 at 11:21:30AM +0200, Miklos Szeredi wrote:
> On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote:
> > On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
>
> >> I hate it, but... consider path_open() objections withdrawn for now.
>
> Is that an ACK for the pull if I follow
On Wed, Jun 13, 2018 at 11:21:30AM +0200, Miklos Szeredi wrote:
> On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote:
> > On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
>
> >> I hate it, but... consider path_open() objections withdrawn for now.
>
> Is that an ACK for the pull if I follow
Al Viro:
> I'd managed to push that particular nest of horrors out of mind ;-/
> Having dug out my notes from back then and grepped around... The real
> mess is not even /proc/*/maps - it's /proc/*/map_files/* and yes, the
> reasons for that kludge are still valid ;-/
:::
> Uses of
Al Viro:
> I'd managed to push that particular nest of horrors out of mind ;-/
> Having dug out my notes from back then and grepped around... The real
> mess is not even /proc/*/maps - it's /proc/*/map_files/* and yes, the
> reasons for that kludge are still valid ;-/
:::
> Uses of
On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote:
> On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
>> I hate it, but... consider path_open() objections withdrawn for now.
Is that an ACK for the pull if I follow up with fixes for mmap botch, etc?
>> Uses of ->vm_file (and rules for
On Tue, Jun 12, 2018 at 8:31 PM, Al Viro wrote:
> On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
>> I hate it, but... consider path_open() objections withdrawn for now.
Is that an ACK for the pull if I follow up with fixes for mmap botch, etc?
>> Uses of ->vm_file (and rules for
On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
> On Tue, Jun 12, 2018 at 11:24:39AM +0200, Miklos Szeredi wrote:
>
> > > Note that anything that uses file_dentry() anywhere near ->open(),
> > > ->read_iter() or ->write_iter() is an instant trouble with your scheme.
> > > Such as
> > >
On Tue, Jun 12, 2018 at 07:24:23PM +0100, Al Viro wrote:
> On Tue, Jun 12, 2018 at 11:24:39AM +0200, Miklos Szeredi wrote:
>
> > > Note that anything that uses file_dentry() anywhere near ->open(),
> > > ->read_iter() or ->write_iter() is an instant trouble with your scheme.
> > > Such as
> > >
On Tue, Jun 12, 2018 at 11:24:39AM +0200, Miklos Szeredi wrote:
> > Note that anything that uses file_dentry() anywhere near ->open(),
> > ->read_iter() or ->write_iter() is an instant trouble with your scheme.
> > Such as
> > int nfs_open(struct inode *inode, struct file *filp)
> > {
> >
On Tue, Jun 12, 2018 at 11:24:39AM +0200, Miklos Szeredi wrote:
> > Note that anything that uses file_dentry() anywhere near ->open(),
> > ->read_iter() or ->write_iter() is an instant trouble with your scheme.
> > Such as
> > int nfs_open(struct inode *inode, struct file *filp)
> > {
> >
On Tue, Jun 12, 2018 at 4:40 AM, Al Viro wrote:
> On Tue, Jun 12, 2018 at 03:29:26AM +0100, Al Viro wrote:
>
>> It might (or might not) work for the filesystems you'd been testing
>> on, but it's a lot of trouble waiting to happen. Hell, try and use
>> ecryptfs as lower layer, see how fast it'll
On Tue, Jun 12, 2018 at 4:40 AM, Al Viro wrote:
> On Tue, Jun 12, 2018 at 03:29:26AM +0100, Al Viro wrote:
>
>> It might (or might not) work for the filesystems you'd been testing
>> on, but it's a lot of trouble waiting to happen. Hell, try and use
>> ecryptfs as lower layer, see how fast it'll
On Tue, Jun 12, 2018 at 03:29:26AM +0100, Al Viro wrote:
> It might (or might not) work for the filesystems you'd been testing
> on, but it's a lot of trouble waiting to happen. Hell, try and use
> ecryptfs as lower layer, see how fast it'll blow up. Sure, it's
> a dumb testcase, but I don't
On Tue, Jun 12, 2018 at 03:29:26AM +0100, Al Viro wrote:
> It might (or might not) work for the filesystems you'd been testing
> on, but it's a lot of trouble waiting to happen. Hell, try and use
> ecryptfs as lower layer, see how fast it'll blow up. Sure, it's
> a dumb testcase, but I don't
On Mon, Jun 11, 2018 at 09:09:04AM +0200, Miklos Szeredi wrote:
[context: opening files in layers with unholy mix of overlayfs
->f_path and layer's ->f_inode/->f_op]
> I'd really like to get there some time but...
>
> List of basic requirements:
>
> - Private mmap of overlay file shares page
On Mon, Jun 11, 2018 at 09:09:04AM +0200, Miklos Szeredi wrote:
[context: opening files in layers with unholy mix of overlayfs
->f_path and layer's ->f_inode/->f_op]
> I'd really like to get there some time but...
>
> List of basic requirements:
>
> - Private mmap of overlay file shares page
On Sun, Jun 10, 2018 at 6:13 AM, Al Viro wrote:
> On Tue, May 29, 2018 at 04:43:14PM +0200, Miklos Szeredi wrote:
>> Implement file operations on a regular overlay file. The underlying file
>> is opened separately and cached in ->private_data.
>>
>> It might be worth making an exception for such
On Sun, Jun 10, 2018 at 6:13 AM, Al Viro wrote:
> On Tue, May 29, 2018 at 04:43:14PM +0200, Miklos Szeredi wrote:
>> Implement file operations on a regular overlay file. The underlying file
>> is opened separately and cached in ->private_data.
>>
>> It might be worth making an exception for such
On Tue, May 29, 2018 at 04:43:14PM +0200, Miklos Szeredi wrote:
> Implement file operations on a regular overlay file. The underlying file
> is opened separately and cached in ->private_data.
>
> It might be worth making an exception for such files when accounting in
> nr_file to confirm to
On Tue, May 29, 2018 at 04:43:14PM +0200, Miklos Szeredi wrote:
> Implement file operations on a regular overlay file. The underlying file
> is opened separately and cached in ->private_data.
>
> It might be worth making an exception for such files when accounting in
> nr_file to confirm to
Implement file operations on a regular overlay file. The underlying file
is opened separately and cached in ->private_data.
It might be worth making an exception for such files when accounting in
nr_file to confirm to userspace expectations. We are only adding a small
overhead (248bytes for the
Implement file operations on a regular overlay file. The underlying file
is opened separately and cached in ->private_data.
It might be worth making an exception for such files when accounting in
nr_file to confirm to userspace expectations. We are only adding a small
overhead (248bytes for the
24 matches
Mail list logo
