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
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
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
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
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
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:
- 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))
>
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
- 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:
>
>
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:
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
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
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
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 +-
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
15 matches
Mail list logo
