Hi all,
With the merge window opening, just a reminder that this conflict still
exists.
On Wed, 21 Jun 2017 16:32:11 +1000 Stephen Rothwell <s...@canb.auug.org.au>
wrote:
>
> Today's linux-next merge of the kspp tree got a conflict in:
>
> include/linux/fs.h
>
> between commits:
>
> 7356fd927059 ("fs: new infrastructure for writeback error handling and
> reporting")
> c7fe314be636 ("fs: add f_md_wb_err field to struct file for tracking
> metadata errors")
>
> from the file-locks tree and commit:
>
> 1a12979f61e4 ("randstruct: Mark various structs for randomization")
>
> from the kspp 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 include/linux/fs.h
> index 39e4603cd17a,8f28143486c4..000000000000
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@@ -397,8 -392,7 +397,8 @@@ struct address_space
> gfp_t gfp_mask; /* implicit gfp mask for
> allocations */
> struct list_head private_list; /* ditto */
> void *private_data; /* ditto */
> + errseq_t wb_err;
> - } __attribute__((aligned(sizeof(long))));
> + } __attribute__((aligned(sizeof(long)))) __randomize_layout;
> /*
> * On most architectures that alignment is already the case; but
> * must be enforced here for CRIS, to let the least significant bit
> @@@ -875,8 -868,8 +875,9 @@@ struct file
> struct list_head f_tfile_llink;
> #endif /* #ifdef CONFIG_EPOLL */
> struct address_space *f_mapping;
> + errseq_t f_md_wb_err; /* metadata wb error tracking */
> - } __attribute__((aligned(4))); /* lest something weird decides that 2
> is OK */
> + } __randomize_layout
> + __attribute__((aligned(4))); /* lest something weird decides that 2
> is OK */
>
> struct file_handle {
> __u32 handle_bytes;
--
Cheers,
Stephen Rothwell
