From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Fri, 24 Jan 2020 08:45:57 -0500 (EST) Subject: [Cluster-devel] [GFS2 v8 PATCH 16/22] gfs2: new slab for transactions In-Reply-To: References: <20191209153700.700208-1-rpeterso@redhat.com> <20191209153700.700208-17-rpeterso@redhat.com> Message-ID: <1920225263.4672289.1579873557442.JavaMail.zimbra@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- Original Message ----- > On Mon, Dec 9, 2019 at 4:38 PM Bob Peterson wrote: > > This patch adds a new slab for gfs2 transactions. That allows us to > > have an initialization function and protect against some errors. > > The added checks in gfs2_trans_free actually have nothing to do with Hi, I agree that a lot of these extra checks are unnecessary, especially with the amount of testing this patch has had. My main concern was that some transactions are often moved from the caller to a global pointer queued off the superblock, sdp. Bear in mind I also used this patch as part of a larger effort to try to locate use-after-free slab corruption problems people were seeing in the kernel. These checks proved those problems were not caused by GFS2 transactions being used after they were freed, so we can probably remove them. Before the patch, new transactions were allocated with kzalloc, which meant the storage was guaranteed to be initialized to all zeroes. Now that we're using a slab, I wanted to similarly guarantee there weren't any leftover values left in the slab objects. Also bear in mind this really has nothing to do with the recovery and journal replay problems, so this patch could be pushed separately, and I think it would be a good idea. I'll clean this up a bit and send a replacement outside the patch set. Regards, Bob Peterson Red Hat File Systems