On Mon 11-08-14 11:02:05, Matthew Wilcox wrote:
> On Mon, Aug 11, 2014 at 04:35:00PM +0200, Jan Kara wrote:
> > On Mon 11-08-14 10:13:08, Matthew Wilcox wrote:
> > > On Mon, Aug 11, 2014 at 10:51:47AM +0200, Jan Kara wrote:
> > > > So I'm afraid we'll have to find some other way to synchronize
> >
On Mon, Aug 11, 2014 at 04:35:00PM +0200, Jan Kara wrote:
> On Mon 11-08-14 10:13:08, Matthew Wilcox wrote:
> > On Mon, Aug 11, 2014 at 10:51:47AM +0200, Jan Kara wrote:
> > > So I'm afraid we'll have to find some other way to synchronize
> > > page faults and truncate / punch hole in DAX.
> >
> >
On Mon 11-08-14 10:13:08, Matthew Wilcox wrote:
> On Mon, Aug 11, 2014 at 10:51:47AM +0200, Jan Kara wrote:
> > So I'm afraid we'll have to find some other way to synchronize
> > page faults and truncate / punch hole in DAX.
>
> What if we don't? If we hit the race (which is vanishingly unlikely
On Mon, Aug 11, 2014 at 10:51:47AM +0200, Jan Kara wrote:
> So I'm afraid we'll have to find some other way to synchronize
> page faults and truncate / punch hole in DAX.
What if we don't? If we hit the race (which is vanishingly unlikely with
real applications), the consequence is simply that af
On Sat 09-08-14 07:00:00, Matthew Wilcox wrote:
> On Wed, Jul 30, 2014 at 11:52:29AM +0200, Jan Kara wrote:
> > I see the problem now. How about an attached patch? Do you see other
> > lockdep warnings with it?
>
> Hit another one :-( Same inversion between i_mmap_mutex and jbd2_handle:
>
> -
On Wed, Jul 30, 2014 at 11:52:29AM +0200, Jan Kara wrote:
> I see the problem now. How about an attached patch? Do you see other
> lockdep warnings with it?
Hit another one :-( Same inversion between i_mmap_mutex and jbd2_handle:
-> #1 (&mapping->i_mmap_mutex){+.+...}:
[] lock_acquire
On Wed, Jul 30, 2014 at 11:52:29AM +0200, Jan Kara wrote:
> I see the problem now. How about an attached patch? Do you see other
> lockdep warnings with it?
This patch fixes the problem, thanks! Regardless of DAX, I think this
patch should be applied in order to avoid creating a dependency betw
On Tue 29-07-14 17:23:33, Matthew Wilcox wrote:
> On Tue, Jul 29, 2014 at 11:04:57PM +0200, Jan Kara wrote:
> > > Path 1:
> > >
> > > ext4_fallocate ->
> > > ext4_punch_hole ->
> > > ext4_inode_attach_jinode() -> ... ->
> > > lock_map_acquire(&handle->h_lockdep_map);
> > > truncate_pageca
On Tue, Jul 29, 2014 at 11:04:57PM +0200, Jan Kara wrote:
> > Path 1:
> >
> > ext4_fallocate ->
> > ext4_punch_hole ->
> > ext4_inode_attach_jinode() -> ... ->
> > lock_map_acquire(&handle->h_lockdep_map);
> > truncate_pagecache_range() ->
> >unmap_mapping_range() ->
> > mutex_loc
On Tue 29-07-14 08:12:59, Matthew Wilcox wrote:
> On Wed, Apr 09, 2014 at 11:43:31PM +0200, Jan Kara wrote:
> > So there are three places that can fail after we allocate the block:
> > 1) We race with truncate reducing i_size
> > 2) dax_get_pfn() fails
> > 3) vm_insert_mixed() fails
> >
> > I woul
On Wed, Apr 09, 2014 at 11:43:31PM +0200, Jan Kara wrote:
> So there are three places that can fail after we allocate the block:
> 1) We race with truncate reducing i_size
> 2) dax_get_pfn() fails
> 3) vm_insert_mixed() fails
>
> I would guess that 2) can fail only if the HW has problems and leaki
On Wed, 2014-05-21 at 14:35 -0600, Toshi Kani wrote:
> On Sun, 2014-03-23 at 15:08 -0400, Matthew Wilcox wrote:
> :
> > +static int do_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
> > + get_block_t get_block)
> > +{
> :
> > + error = dax_get_pfn(inode, &bh, &pfn
On Sun, 2014-03-23 at 15:08 -0400, Matthew Wilcox wrote:
:
> +static int do_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
> + get_block_t get_block)
> +{
:
> + error = dax_get_pfn(inode, &bh, &pfn);
> + if (error > 0)
> + error = vm_insert_mix
On Sun 13-04-14 07:21:32, Matthew Wilcox wrote:
> On Wed, Apr 09, 2014 at 11:12:03PM +0200, Jan Kara wrote:
> > This would be fine except that unmap_mapping_range() grabs i_mmap_mutex
> > again :-|. But it might be easier to provide a version of that function
> > which assumes i_mmap_mutex is alr
On Wed, Apr 09, 2014 at 11:43:31PM +0200, Jan Kara wrote:
> On Wed 09-04-14 16:51:11, Matthew Wilcox wrote:
> > On Wed, Apr 09, 2014 at 12:27:58PM +0200, Jan Kara wrote:
> > > > + if (unlikely(vmf->pgoff >= size)) {
> > > > + mutex_unlock(&mapping->i_mmap_mutex);
> > > > +
On Wed, Apr 09, 2014 at 11:12:03PM +0200, Jan Kara wrote:
> This would be fine except that unmap_mapping_range() grabs i_mmap_mutex
> again :-|. But it might be easier to provide a version of that function
> which assumes i_mmap_mutex is already locked than what I was suggesting.
*sigh*. I knew
On Wed 09-04-14 16:51:11, Matthew Wilcox wrote:
> On Wed, Apr 09, 2014 at 12:27:58PM +0200, Jan Kara wrote:
> > > + if (unlikely(vmf->pgoff >= size)) {
> > > + mutex_unlock(&mapping->i_mmap_mutex);
> > > + goto sigbus;
> > You need to release the block you've got from the filesyst
On Wed 09-04-14 16:48:06, Matthew Wilcox wrote:
> On Wed, Apr 09, 2014 at 12:05:25AM +0200, Jan Kara wrote:
> > > +
> > > + error = dax_get_pfn(inode, &bh, &pfn);
> > > + if (error > 0)
> > > + error = vm_insert_mixed(vma, vaddr, pfn);
> > When there's a hole (thus page != NULL) and we ar
On Wed, Apr 09, 2014 at 12:27:58PM +0200, Jan Kara wrote:
> > + if (unlikely(vmf->pgoff >= size)) {
> > + mutex_unlock(&mapping->i_mmap_mutex);
> > + goto sigbus;
> You need to release the block you've got from the filesystem in case of
> error here an below.
What's the API
On Wed, Apr 09, 2014 at 12:05:25AM +0200, Jan Kara wrote:
> > + if (!page)
> > + return VM_FAULT_OOM;
> > + size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > + if (vmf->pgoff >= size) {
> Maybe comment here that we have to recheck i_size so that we don't create
> page
One more comment:
On Sun 23-03-14 15:08:33, Matthew Wilcox wrote:
> +static int do_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
> + get_block_t get_block)
> +{
> + struct file *file = vma->vm_file;
> + struct inode *inode = file_inode(file);
> + str
On Sun 23-03-14 15:08:33, Matthew Wilcox wrote:
> Instead of calling aops->get_xip_mem from the fault handler, the
> filesystem passes a get_block_t that is used to find the appropriate
> blocks.
I have some suggestions below...
> Signed-off-by: Matthew Wilcox
> ---
> fs/dax.c | 207
Instead of calling aops->get_xip_mem from the fault handler, the
filesystem passes a get_block_t that is used to find the appropriate
blocks.
Signed-off-by: Matthew Wilcox
---
fs/dax.c | 207 +
fs/ext2/file.c | 35 -
incl
23 matches
Mail list logo
