Re: [Cluster-devel] [PATCH 2/2] gfs2: Fix lru_count going negative

2019-01-31 Thread Andreas Gruenbacher
Ross, On Thu, 31 Jan 2019 at 11:56, Ross Lagerwall wrote: > > Under certain conditions, lru_count may drop below zero resulting in > a large amount of log spam like this: > > vmscan: shrink_slab: gfs2_dump_glock+0x3b0/0x630 [gfs2] \ > negative objects to delete nr=-1 > > This happens as

Re: [Cluster-devel] [PATCH] gfs2: Revert "Fix loop in gfs2_rbm_find"

2019-01-31 Thread Linus Torvalds
On Wed, Jan 30, 2019 at 12:30 PM Andreas Gruenbacher wrote: > > This reverts commit 2d29f6b96d8f80322ed2dd895bca590491c38d34. > > It turns out that the fix can lead to a ~20 percent performance regression > in initial writes to the page cache according to iozone. Let's revert this > for now to

Re: [Cluster-devel] [PATCH] gfs2: Revert "Fix loop in gfs2_rbm_find"

2019-01-31 Thread Andreas Gruenbacher
On Thu, 31 Jan 2019 at 19:41, Linus Torvalds wrote: > On Wed, Jan 30, 2019 at 12:30 PM Andreas Gruenbacher > wrote: > > > > This reverts commit 2d29f6b96d8f80322ed2dd895bca590491c38d34. > > > > It turns out that the fix can lead to a ~20 percent performance regression > > in initial writes to

Re: [Cluster-devel] [PATCH] gfs2: Revert "Fix loop in gfs2_rbm_find"

2019-01-31 Thread Linus Torvalds
On Thu, Jan 31, 2019 at 11:12 AM Andreas Gruenbacher wrote: > > That patch just hasn't seen enough testing to make me comfortable > sending it yet. Ok, I'll just apply the revert. Thanks, Linus

[Cluster-devel] [PATCH 0/2] GFS2 counting fixes

2019-01-31 Thread Ross Lagerwall
Here are a couple of fixes for GFS2 (ref-)counting going wrong. Ross Lagerwall (2): gfs2: Fix occasional glock use-after-free gfs2: Fix lru_count going negative fs/gfs2/aops.c| 3 +-- fs/gfs2/glock.c | 16 +--- fs/gfs2/lops.c| 2 +- fs/gfs2/meta_io.c | 2 +-

[Cluster-devel] [PATCH 1/2] gfs2: Fix occasional glock use-after-free

2019-01-31 Thread Ross Lagerwall
Each gfs2_bufdata stores a reference to a glock but the reference count isn't incremented. This causes an occasional use-after-free of the glock. Fix by taking a reference on the glock during allocation and dropping it when freeing. Found by KASAN: BUG: KASAN: use-after-free in

Re: [Cluster-devel] [PATCH 2/2] gfs2: Fix lru_count going negative

2019-01-31 Thread Steven Whitehouse
Hi, On 31/01/2019 10:55, Ross Lagerwall wrote: Under certain conditions, lru_count may drop below zero resulting in a large amount of log spam like this: vmscan: shrink_slab: gfs2_dump_glock+0x3b0/0x630 [gfs2] \ negative objects to delete nr=-1 This happens as follows: 1) A glock is

Re: [Cluster-devel] [PATCH 1/2] gfs2: Fix occasional glock use-after-free

2019-01-31 Thread Steven Whitehouse
Hi, On 31/01/2019 10:55, Ross Lagerwall wrote: Each gfs2_bufdata stores a reference to a glock but the reference count isn't incremented. This causes an occasional use-after-free of the glock. Fix by taking a reference on the glock during allocation and dropping it when freeing. Another good

[Cluster-devel] [PATCH 2/2] gfs2: Fix lru_count going negative

2019-01-31 Thread Ross Lagerwall
Under certain conditions, lru_count may drop below zero resulting in a large amount of log spam like this: vmscan: shrink_slab: gfs2_dump_glock+0x3b0/0x630 [gfs2] \ negative objects to delete nr=-1 This happens as follows: 1) A glock is moved from lru_list to the dispose list and lru_count

Re: [Cluster-devel] [PATCH 2/2] gfs2: Fix lru_count going negative

2019-01-31 Thread Bob Peterson
Hi Ross, Comments below. Sorry if this is a bit incoherent; it's early and I'm not properly caffeinated yet. - Original Message - > Under certain conditions, lru_count may drop below zero resulting in > a large amount of log spam like this: > > vmscan: shrink_slab:

Re: [Cluster-devel] [PATCH 1/2] gfs2: Fix occasional glock use-after-free

2019-01-31 Thread Bob Peterson
- Original Message - > Each gfs2_bufdata stores a reference to a glock but the reference count > isn't incremented. This causes an occasional use-after-free of the > glock. Fix by taking a reference on the glock during allocation and > dropping it when freeing. > > Found by KASAN: > >

[Cluster-devel] [PATCH] gfs2: Fix loop in gfs2_rbm_find (2)

2019-01-31 Thread Andreas Gruenbacher
This is an updated version of the patch previously posted on January 24. Changes since then: - The previous version didn't take filesystems with a single bitmap block per filesystem into account, and could still loop endlessly in that case. - When starting a scan at the beginning of a

Re: [Cluster-devel] [PATCH 2/2] gfs2: Fix lru_count going negative

2019-01-31 Thread Bob Peterson
- Original Message - > > + > > + if (!test_bit(GLF_LRU, >gl_flags)) { > > + set_bit(GLF_LRU, >gl_flags); > > atomic_inc(_count); > > + } > > The above may be simplified to something like: > + if (!test_and_set_bit(GLF_LRU, >gl_flags)) >

Re: [Cluster-devel] [PATCH 1/2] gfs2: Fix occasional glock use-after-free

2019-01-31 Thread Andreas Gruenbacher
Hi Ross, On Thu, 31 Jan 2019 at 11:56, Ross Lagerwall wrote: > Each gfs2_bufdata stores a reference to a glock but the reference count > isn't incremented. This causes an occasional use-after-free of the > glock. Fix by taking a reference on the glock during allocation and > dropping it when

Re: [Cluster-devel] [PATCH 2/2] gfs2: Fix lru_count going negative

2019-01-31 Thread Ross Lagerwall
On 1/31/19 2:36 PM, Bob Peterson wrote: Hi Ross, Comments below. Sorry if this is a bit incoherent; it's early and I'm not properly caffeinated yet. - Original Message - Under certain conditions, lru_count may drop below zero resulting in a large amount of log spam like this: vmscan: