| Message ID | 1564653995-9004-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | fs: xfs: xfs_log: Don't use KM_MAYFAIL at xfs_log_reserve(). | expand |
On Thu, Aug 01, 2019 at 07:06:35PM +0900, Tetsuo Handa wrote: > When the system is close-to-OOM, fsync() may fail due to -ENOMEM because > xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback > operation due to user-triggerable OOM condition. Since we are not using > KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's > use the same flags at xfs_log_reserve(). > > oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null) > CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925 > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 > Call Trace: > dump_stack+0x67/0x95 > warn_alloc+0xa9/0x140 > __alloc_pages_slowpath+0x9a8/0xbce > __alloc_pages_nodemask+0x372/0x3b0 > alloc_slab_page+0x3a/0x8d0 > new_slab+0x330/0x420 > ___slab_alloc.constprop.94+0x879/0xb00 > __slab_alloc.isra.89.constprop.93+0x43/0x6f > kmem_cache_alloc+0x331/0x390 > kmem_zone_alloc+0x9f/0x110 [xfs] > kmem_zone_alloc+0x9f/0x110 [xfs] > xlog_ticket_alloc+0x33/0xd0 [xfs] > xfs_log_reserve+0xb4/0x410 [xfs] > xfs_trans_reserve+0x1d1/0x2b0 [xfs] > xfs_trans_alloc+0xc9/0x250 [xfs] > xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs] > xfs_submit_ioend.isra.28+0xa5/0x180 [xfs] > xfs_vm_writepages+0x76/0xa0 [xfs] > do_writepages+0x17/0x80 > __filemap_fdatawrite_range+0xc1/0xf0 > file_write_and_wait_range+0x53/0xa0 > xfs_file_fsync+0x87/0x290 [xfs] > vfs_fsync_range+0x37/0x80 > do_fsync+0x38/0x60 > __x64_sys_fsync+0xf/0x20 > do_syscall_64+0x4a/0x1c0 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > --- I assume this survived your test scenario? If so, the change looks fine to me. Thanks for the patch. Reviewed-by: Brian Foster <bfoster@redhat.com> > fs/xfs/xfs_log.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c > index 00e9f5c388d3..7fc3c1ad36bc 100644 > --- a/fs/xfs/xfs_log.c > +++ b/fs/xfs/xfs_log.c > @@ -429,10 +429,7 @@ xfs_log_reserve( > > ASSERT(*ticp == NULL); > tic = xlog_ticket_alloc(log, unit_bytes, cnt, client, permanent, > - KM_SLEEP | KM_MAYFAIL); > - if (!tic) > - return -ENOMEM; > - > + KM_SLEEP); > *ticp = tic; > > xlog_grant_push_ail(log, tic->t_cnt ? tic->t_unit_res * tic->t_cnt > -- > 2.16.5 >
On 2019/08/01 19:56, Brian Foster wrote: > I assume this survived your test scenario? Yes. > > If so, the change looks fine to me. Thanks for the patch. > > Reviewed-by: Brian Foster <bfoster@redhat.com>
On Thu, Aug 01, 2019 at 07:06:35PM +0900, Tetsuo Handa wrote: > When the system is close-to-OOM, fsync() may fail due to -ENOMEM because > xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback > operation due to user-triggerable OOM condition. Since we are not using > KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's > use the same flags at xfs_log_reserve(). > > oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null) > CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925 > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 > Call Trace: > dump_stack+0x67/0x95 > warn_alloc+0xa9/0x140 > __alloc_pages_slowpath+0x9a8/0xbce > __alloc_pages_nodemask+0x372/0x3b0 > alloc_slab_page+0x3a/0x8d0 > new_slab+0x330/0x420 > ___slab_alloc.constprop.94+0x879/0xb00 > __slab_alloc.isra.89.constprop.93+0x43/0x6f > kmem_cache_alloc+0x331/0x390 > kmem_zone_alloc+0x9f/0x110 [xfs] > kmem_zone_alloc+0x9f/0x110 [xfs] > xlog_ticket_alloc+0x33/0xd0 [xfs] > xfs_log_reserve+0xb4/0x410 [xfs] > xfs_trans_reserve+0x1d1/0x2b0 [xfs] > xfs_trans_alloc+0xc9/0x250 [xfs] > xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs] > xfs_submit_ioend.isra.28+0xa5/0x180 [xfs] > xfs_vm_writepages+0x76/0xa0 [xfs] > do_writepages+0x17/0x80 > __filemap_fdatawrite_range+0xc1/0xf0 > file_write_and_wait_range+0x53/0xa0 > xfs_file_fsync+0x87/0x290 [xfs] > vfs_fsync_range+0x37/0x80 > do_fsync+0x38/0x60 > __x64_sys_fsync+0xf/0x20 > do_syscall_64+0x4a/0x1c0 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> That's quite an opaque commit log for what started off as a severe email thread of potential leak of information. As such, can you expand on this commit log considerably to explain the situation a bit better? Your initial thread here provided much clearer evidence of the issue. As-is this commit log tells the reader *nothing* about the potential harm in not applying this patch. You had mentioned you identified this issue present on at least 4.18 till 5.3-rc1. So, I'm at least inclined to consider this for stable for at least v4.19. However, what about older kernels? Now that you have identified a fix, were the flag changed in prior commits, is it a regression that perhaps added KM_MAYFAIL at some point? Luis
On Thu, Aug 01, 2019 at 06:50:57PM +0000, Luis Chamberlain wrote: > On Thu, Aug 01, 2019 at 07:06:35PM +0900, Tetsuo Handa wrote: > > When the system is close-to-OOM, fsync() may fail due to -ENOMEM because > > xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback > > operation due to user-triggerable OOM condition. Since we are not using > > KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's > > use the same flags at xfs_log_reserve(). > > > > oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null) > > CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925 > > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 > > Call Trace: > > dump_stack+0x67/0x95 > > warn_alloc+0xa9/0x140 > > __alloc_pages_slowpath+0x9a8/0xbce > > __alloc_pages_nodemask+0x372/0x3b0 > > alloc_slab_page+0x3a/0x8d0 > > new_slab+0x330/0x420 > > ___slab_alloc.constprop.94+0x879/0xb00 > > __slab_alloc.isra.89.constprop.93+0x43/0x6f > > kmem_cache_alloc+0x331/0x390 > > kmem_zone_alloc+0x9f/0x110 [xfs] > > kmem_zone_alloc+0x9f/0x110 [xfs] > > xlog_ticket_alloc+0x33/0xd0 [xfs] > > xfs_log_reserve+0xb4/0x410 [xfs] > > xfs_trans_reserve+0x1d1/0x2b0 [xfs] > > xfs_trans_alloc+0xc9/0x250 [xfs] > > xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs] > > xfs_submit_ioend.isra.28+0xa5/0x180 [xfs] > > xfs_vm_writepages+0x76/0xa0 [xfs] > > do_writepages+0x17/0x80 > > __filemap_fdatawrite_range+0xc1/0xf0 > > file_write_and_wait_range+0x53/0xa0 > > xfs_file_fsync+0x87/0x290 [xfs] > > vfs_fsync_range+0x37/0x80 > > do_fsync+0x38/0x60 > > __x64_sys_fsync+0xf/0x20 > > do_syscall_64+0x4a/0x1c0 > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > > That's quite an opaque commit log for what started off as a severe email > thread of potential leak of information. As such, can you expand on this > commit log considerably to explain the situation a bit better? I'm pretty sure this didn't solve the underlying stale data exposure problem, which might be why you think this is "opaque". It fixes a bug that causes data writeback failure (which was the exposure vector this time) but I think the ultimate fix for the exposure problem are the two patches I linked to quite a ways back in this discussion.... --D https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=bd012b434a56d9fac3cbc33062b8e2cd6e1ad0a0 https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=adcf7c0c87191fd3616813c8ce9790f89a9a8eba > Your > initial thread here provided much clearer evidence of the issue. As-is > this commit log tells the reader *nothing* about the potential harm in > not applying this patch. > > You had mentioned you identified this issue present on at least > 4.18 till 5.3-rc1. So, I'm at least inclined to consider this for > stable for at least v4.19. > > However, what about older kernels? Now that you have identified > a fix, were the flag changed in prior commits, is it a regression > that perhaps added KM_MAYFAIL at some point? > > Luis
On Thu, Aug 01, 2019 at 07:06:35PM +0900, Tetsuo Handa wrote: > When the system is close-to-OOM, fsync() may fail due to -ENOMEM because > xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback > operation due to user-triggerable OOM condition. Since we are not using > KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's > use the same flags at xfs_log_reserve(). > > oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null) > CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925 > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 > Call Trace: > dump_stack+0x67/0x95 > warn_alloc+0xa9/0x140 > __alloc_pages_slowpath+0x9a8/0xbce > __alloc_pages_nodemask+0x372/0x3b0 > alloc_slab_page+0x3a/0x8d0 > new_slab+0x330/0x420 > ___slab_alloc.constprop.94+0x879/0xb00 > __slab_alloc.isra.89.constprop.93+0x43/0x6f > kmem_cache_alloc+0x331/0x390 > kmem_zone_alloc+0x9f/0x110 [xfs] > kmem_zone_alloc+0x9f/0x110 [xfs] > xlog_ticket_alloc+0x33/0xd0 [xfs] > xfs_log_reserve+0xb4/0x410 [xfs] > xfs_trans_reserve+0x1d1/0x2b0 [xfs] > xfs_trans_alloc+0xc9/0x250 [xfs] > xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs] > xfs_submit_ioend.isra.28+0xa5/0x180 [xfs] > xfs_vm_writepages+0x76/0xa0 [xfs] > do_writepages+0x17/0x80 > __filemap_fdatawrite_range+0xc1/0xf0 > file_write_and_wait_range+0x53/0xa0 > xfs_file_fsync+0x87/0x290 [xfs] > vfs_fsync_range+0x37/0x80 > do_fsync+0x38/0x60 > __x64_sys_fsync+0xf/0x20 > do_syscall_64+0x4a/0x1c0 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Looks ok... Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> --D > --- > fs/xfs/xfs_log.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c > index 00e9f5c388d3..7fc3c1ad36bc 100644 > --- a/fs/xfs/xfs_log.c > +++ b/fs/xfs/xfs_log.c > @@ -429,10 +429,7 @@ xfs_log_reserve( > > ASSERT(*ticp == NULL); > tic = xlog_ticket_alloc(log, unit_bytes, cnt, client, permanent, > - KM_SLEEP | KM_MAYFAIL); > - if (!tic) > - return -ENOMEM; > - > + KM_SLEEP); > *ticp = tic; > > xlog_grant_push_ail(log, tic->t_cnt ? tic->t_unit_res * tic->t_cnt > -- > 2.16.5 >
On 2019/08/02 3:50, Luis Chamberlain wrote: > That's quite an opaque commit log for what started off as a severe email > thread of potential leak of information. As such, can you expand on this > commit log considerably to explain the situation a bit better? Your > initial thread here provided much clearer evidence of the issue. As-is > this commit log tells the reader *nothing* about the potential harm in > not applying this patch. > > You had mentioned you identified this issue present on at least > 4.18 till 5.3-rc1. So, I'm at least inclined to consider this for > stable for at least v4.19. > > However, what about older kernels? Now that you have identified > a fix, were the flag changed in prior commits, is it a regression > that perhaps added KM_MAYFAIL at some point? I only checked 4.18+ so that RHEL8 will backport this patch. According to Brian Foster, commit eb01c9cd87 ("[XFS] Remove the xlog_ticket allocator") ( https://git.kernel.org/linus/eb01c9cd87 ) which dates back to April 2008 added KM_MAYFAIL flag for this allocation - buf = (xfs_caddr_t) kmem_zalloc(PAGE_SIZE, KM_SLEEP); + tic = kmem_zone_zalloc(xfs_log_ticket_zone, KM_SLEEP|KM_MAYFAIL); though Dave Chinner thinks that the log ticket rework is irrelevant. Do we need to find which commit made this problem visible?
On Fri, Aug 02, 2019 at 06:13:12AM +0900, Tetsuo Handa wrote: > On 2019/08/02 3:50, Luis Chamberlain wrote: > > That's quite an opaque commit log for what started off as a severe email > > thread of potential leak of information. As such, can you expand on this > > commit log considerably to explain the situation a bit better? Your > > initial thread here provided much clearer evidence of the issue. As-is > > this commit log tells the reader *nothing* about the potential harm in > > not applying this patch. > > > > You had mentioned you identified this issue present on at least > > 4.18 till 5.3-rc1. So, I'm at least inclined to consider this for > > stable for at least v4.19. > > > > However, what about older kernels? Now that you have identified > > a fix, were the flag changed in prior commits, is it a regression > > that perhaps added KM_MAYFAIL at some point? > > I only checked 4.18+ so that RHEL8 will backport this patch. According to > Brian Foster, commit eb01c9cd87 ("[XFS] Remove the xlog_ticket allocator") > ( https://git.kernel.org/linus/eb01c9cd87 ) which dates back to April 2008 > added KM_MAYFAIL flag for this allocation > > - buf = (xfs_caddr_t) kmem_zalloc(PAGE_SIZE, KM_SLEEP); > + tic = kmem_zone_zalloc(xfs_log_ticket_zone, KM_SLEEP|KM_MAYFAIL); > > though Dave Chinner thinks that the log ticket rework is irrelevant. > Do we need to find which commit made this problem visible? No. -Dave.
On Thu, Aug 01, 2019 at 01:46:14PM -0700, Darrick J. Wong wrote: > On Thu, Aug 01, 2019 at 06:50:57PM +0000, Luis Chamberlain wrote: > > On Thu, Aug 01, 2019 at 07:06:35PM +0900, Tetsuo Handa wrote: > > > When the system is close-to-OOM, fsync() may fail due to -ENOMEM because > > > xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback > > > operation due to user-triggerable OOM condition. Since we are not using > > > KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's > > > use the same flags at xfs_log_reserve(). > > > > > > oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null) > > > CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925 > > > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 > > > Call Trace: > > > dump_stack+0x67/0x95 > > > warn_alloc+0xa9/0x140 > > > __alloc_pages_slowpath+0x9a8/0xbce > > > __alloc_pages_nodemask+0x372/0x3b0 > > > alloc_slab_page+0x3a/0x8d0 > > > new_slab+0x330/0x420 > > > ___slab_alloc.constprop.94+0x879/0xb00 > > > __slab_alloc.isra.89.constprop.93+0x43/0x6f > > > kmem_cache_alloc+0x331/0x390 > > > kmem_zone_alloc+0x9f/0x110 [xfs] > > > kmem_zone_alloc+0x9f/0x110 [xfs] > > > xlog_ticket_alloc+0x33/0xd0 [xfs] > > > xfs_log_reserve+0xb4/0x410 [xfs] > > > xfs_trans_reserve+0x1d1/0x2b0 [xfs] > > > xfs_trans_alloc+0xc9/0x250 [xfs] > > > xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs] > > > xfs_submit_ioend.isra.28+0xa5/0x180 [xfs] > > > xfs_vm_writepages+0x76/0xa0 [xfs] > > > do_writepages+0x17/0x80 > > > __filemap_fdatawrite_range+0xc1/0xf0 > > > file_write_and_wait_range+0x53/0xa0 > > > xfs_file_fsync+0x87/0x290 [xfs] > > > vfs_fsync_range+0x37/0x80 > > > do_fsync+0x38/0x60 > > > __x64_sys_fsync+0xf/0x20 > > > do_syscall_64+0x4a/0x1c0 > > > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > > > > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > > > > That's quite an opaque commit log for what started off as a severe email > > thread of potential leak of information. As such, can you expand on this > > commit log considerably to explain the situation a bit better? > > I'm pretty sure this didn't solve the underlying stale data exposure > problem, which might be why you think this is "opaque". It fixes a bug > that causes data writeback failure (which was the exposure vector this > time) but I think the ultimate fix for the exposure problem are the two > patches I linked to quite a ways back in this discussion.... > > --D > > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=bd012b434a56d9fac3cbc33062b8e2cd6e1ad0a0 > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=adcf7c0c87191fd3616813c8ce9790f89a9a8eba Got it, thanks! Even with this, I still think the current commit could say a bit a more about the effects of not having this patch applied. What are the effects of say having the above two patches applied but not the one being submitted now? Luis
On 2019/08/03 7:21, Luis Chamberlain wrote: >> I'm pretty sure this didn't solve the underlying stale data exposure >> problem, which might be why you think this is "opaque". It fixes a bug >> that causes data writeback failure (which was the exposure vector this >> time) but I think the ultimate fix for the exposure problem are the two >> patches I linked to quite a ways back in this discussion.... >> >> --D >> >> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=bd012b434a56d9fac3cbc33062b8e2cd6e1ad0a0 >> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=adcf7c0c87191fd3616813c8ce9790f89a9a8eba > > Got it, thanks! Even with this, I still think the current commit could > say a bit a more about the effects of not having this patch applied. > What are the effects of say having the above two patches applied but not > the one being submitted now? Is this patch going to be applied as-is? Or, someone have a plan to rewrite the changelog?
On Mon, Aug 12, 2019 at 07:57:27PM +0900, Tetsuo Handa wrote: > On 2019/08/03 7:21, Luis Chamberlain wrote: > >> I'm pretty sure this didn't solve the underlying stale data exposure > >> problem, which might be why you think this is "opaque". It fixes a bug > >> that causes data writeback failure (which was the exposure vector this > >> time) but I think the ultimate fix for the exposure problem are the two > >> patches I linked to quite a ways back in this discussion.... > >> > >> --D > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=bd012b434a56d9fac3cbc33062b8e2cd6e1ad0a0 > >> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=adcf7c0c87191fd3616813c8ce9790f89a9a8eba > > > > Got it, thanks! Even with this, I still think the current commit could > > say a bit a more about the effects of not having this patch applied. > > What are the effects of say having the above two patches applied but not > > the one being submitted now? > > Is this patch going to be applied as-is? Or, someone have a plan to > rewrite the changelog? The first one, since the patch eliminates a vector to the writeback race problem but does not iself solve the race. --D
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index 00e9f5c388d3..7fc3c1ad36bc 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -429,10 +429,7 @@ xfs_log_reserve( ASSERT(*ticp == NULL); tic = xlog_ticket_alloc(log, unit_bytes, cnt, client, permanent, - KM_SLEEP | KM_MAYFAIL); - if (!tic) - return -ENOMEM; - + KM_SLEEP); *ticp = tic; xlog_grant_push_ail(log, tic->t_cnt ? tic->t_unit_res * tic->t_cnt
When the system is close-to-OOM, fsync() may fail due to -ENOMEM because xfs_log_reserve() is using KM_MAYFAIL. It is a bad thing to fail writeback operation due to user-triggerable OOM condition. Since we are not using KM_MAYFAIL at xfs_trans_alloc() before calling xfs_log_reserve(), let's use the same flags at xfs_log_reserve(). oom-torture: page allocation failure: order:0, mode:0x46c40(GFP_NOFS|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), nodemask=(null) CPU: 7 PID: 1662 Comm: oom-torture Kdump: loaded Not tainted 5.3.0-rc2+ #925 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 Call Trace: dump_stack+0x67/0x95 warn_alloc+0xa9/0x140 __alloc_pages_slowpath+0x9a8/0xbce __alloc_pages_nodemask+0x372/0x3b0 alloc_slab_page+0x3a/0x8d0 new_slab+0x330/0x420 ___slab_alloc.constprop.94+0x879/0xb00 __slab_alloc.isra.89.constprop.93+0x43/0x6f kmem_cache_alloc+0x331/0x390 kmem_zone_alloc+0x9f/0x110 [xfs] kmem_zone_alloc+0x9f/0x110 [xfs] xlog_ticket_alloc+0x33/0xd0 [xfs] xfs_log_reserve+0xb4/0x410 [xfs] xfs_trans_reserve+0x1d1/0x2b0 [xfs] xfs_trans_alloc+0xc9/0x250 [xfs] xfs_setfilesize_trans_alloc.isra.27+0x44/0xc0 [xfs] xfs_submit_ioend.isra.28+0xa5/0x180 [xfs] xfs_vm_writepages+0x76/0xa0 [xfs] do_writepages+0x17/0x80 __filemap_fdatawrite_range+0xc1/0xf0 file_write_and_wait_range+0x53/0xa0 xfs_file_fsync+0x87/0x290 [xfs] vfs_fsync_range+0x37/0x80 do_fsync+0x38/0x60 __x64_sys_fsync+0xf/0x20 do_syscall_64+0x4a/0x1c0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- fs/xfs/xfs_log.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)