Hi,
Linus has pulled the latest set of patches from the for-next branch of
the linux-gfs2.git tree, so I rebased the tree based on Linus's master.
So the current tree is back to having no unmerged GFS2 patches.
Regards,
Bob Peterson
Red Hat File Systems
Hi Digimer,
On Fri, Sep 04, 2015 at 03:36:09AM -0400, Digimer wrote:
> Hi all,
>
> I hit an issue a little while ago where live-migrating a VM (on the
> same management network normally used for corosync and a few other
> monitoring tasks) ate up all the bandwidth, causing corosync to declare
> Recent commits to kernel/git/torvalds/linux.git have made the following
> functions able to tolerate NULL arguments:
>
> kmem_cache_destroy (commit 3942d29918522)
> mempool_destroy (commit 4e3ca3e033d1)
> dma_pool_destroy (commit 44d7175da6ea)
How do you think about to extend an other SmPL
On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote:
> On Sat, 12 Sep 2015 04:41:33 +
> "Dilger, Andreas" wrote:
>
> > On 2015/09/11, 4:20 AM, "HPDD-discuss on behalf of Jeff Layton"
> >
On 14/09/15 07:19 AM, Dejan Muhamedagic wrote:
> Hi Digimer,
>
> On Fri, Sep 04, 2015 at 03:36:09AM -0400, Digimer wrote:
>> Hi all,
>>
>> I hit an issue a little while ago where live-migrating a VM (on the
>> same management network normally used for corosync and a few other
>> monitoring
Hi,
This patch adds checks to function rindex_read to make sure the
rgrp starting address isn't grossly outside the file system.
It may be in the case of severely corrupt file systems from fsck.
If we added them to the rgrp tree, our calculations will get
screwed up, eventually causing a
Hi,
This patch adds a check to function gfs2_rgrp_free to make sure
rgd->bits is non-zero before attempting to reference it.
This might be NULL because no buffers actually existed because
it was concocted in an attempt to repair damaged rgrps in fsck.
Regards,
Bob Peterson
Red Hat File Systems