lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230823044409.GF11286@frogsfrogsfrogs>
Date:   Tue, 22 Aug 2023 21:44:09 -0700
From:   "Darrick J. Wong" <djwong@...nel.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Christian Brauner <brauner@...nel.org>,
        David Chinner <david@...morbit.com>,
        Christoph Hellwig <hch@....de>, linux-xfs@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the xfs
 tree

On Wed, Aug 23, 2023 at 09:38:52AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
> 
>   fs/xfs/xfs_super.c
> 
> between commit:
> 
>   a76dba3b248c ("xfs: create scaffolding for creating debugfs entries")
> 
> from the xfs tree and commit:
> 
>   35a93b148b03 ("xfs: close the external block devices in xfs_mount_free")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc fs/xfs/xfs_super.c
> index 09638e8fb4ee,c79eac048456..000000000000
> --- a/fs/xfs/xfs_super.c
> +++ b/fs/xfs/xfs_super.c
> @@@ -760,7 -772,17 +774,18 @@@ static voi
>   xfs_mount_free(
>   	struct xfs_mount	*mp)
>   {
> + 	/*
> + 	 * Free the buftargs here because blkdev_put needs to be called outside
> + 	 * of sb->s_umount, which is held around the call to ->put_super.
> + 	 */
> + 	if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp)
> + 		xfs_free_buftarg(mp->m_logdev_targp);
> + 	if (mp->m_rtdev_targp)
> + 		xfs_free_buftarg(mp->m_rtdev_targp);
> + 	if (mp->m_ddev_targp)
> + 		xfs_free_buftarg(mp->m_ddev_targp);
> + 
>  +	debugfs_remove(mp->m_debugfs);
>   	kfree(mp->m_rtname);
>   	kfree(mp->m_logname);
>   	kmem_free(mp);
> @@@ -1538,18 -1537,11 +1556,18 @@@ xfs_fs_fill_super
>   
>   	error = xfs_open_devices(mp);
>   	if (error)
> - 		goto out_free_names;
> + 		return error;
>   
>  +	if (xfs_debugfs) {
>  +		mp->m_debugfs = xfs_debugfs_mkdir(mp->m_super->s_id,
>  +						  xfs_debugfs);
>  +	} else {
>  +		mp->m_debugfs = NULL;
>  +	}
>  +

Yep, this looks correct.

--D

>   	error = xfs_init_mount_workqueues(mp);
>   	if (error)
> - 		goto out_close_devices;
> + 		goto out_shutdown_devices;
>   
>   	error = xfs_init_percpu_counters(mp);
>   	if (error)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ