Re: linux-next: manual merge of the kspp tree with the file-locks tree
Hi Jeff, On Mon, 03 Jul 2017 06:27:27 -0400 Jeff Layton wrote: > > I think this is fairly trivial conflict -- Kees is adding the > __randomize_layout attribute here, and I'm just adding a field to each > of these structs. Yep, nothing too tricky here. > The main catch is that both of these branches have a fair number of > preparatory patches before the above changes occur, so pulling one into > the other is not trivial. > > Would it be best to just send the PRs to Linus and have him fix this up > in the final merge? Absolutely the right thing to do. The reminder is mainly so you can just mention the conflict to Linus. -- Cheers, Stephen Rothwell
Re: linux-next: manual merge of the kspp tree with the file-locks tree
On Mon, 2017-07-03 at 11:48 +1000, Stephen Rothwell wrote: > 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 > 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.. > > --- 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_headprivate_list; /* ditto */ > > void*private_data; /* ditto */ > > + errseq_twb_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_headf_tfile_llink; > > #endif /* #ifdef CONFIG_EPOLL */ > > struct address_space*f_mapping; > > + errseq_tf_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; > > Thanks. I think this is fairly trivial conflict -- Kees is adding the __randomize_layout attribute here, and I'm just adding a field to each of these structs. The main catch is that both of these branches have a fair number of preparatory patches before the above changes occur, so pulling one into the other is not trivial. Would it be best to just send the PRs to Linus and have him fix this up in the final merge? -- Jeff Layton
Re: linux-next: manual merge of the kspp tree with the file-locks tree
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 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.. > --- 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_headprivate_list; /* ditto */ > void*private_data; /* ditto */ > +errseq_twb_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_headf_tfile_llink; > #endif /* #ifdef CONFIG_EPOLL */ > struct address_space*f_mapping; > +errseq_tf_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
linux-next: manual merge of the kspp tree with the file-locks tree
Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: include/linux/fs.h between commit: 1844a66c1c89 ("fs: new infrastructure for writeback error handling and reporting") from the file-locks tree and commit: 3abc2b3fcf5c ("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 000cf03ec441,8f28143486c4.. --- a/include/linux/fs.h +++ b/include/linux/fs.h @@@ -293,8 -275,7 +293,8 @@@ struct kiocb void (*ki_complete)(struct kiocb *iocb, long ret, long ret2); void*private; int ki_flags; + enum rw_hintki_hint; - }; + } __randomize_layout; static inline bool is_sync_kiocb(struct kiocb *kiocb) { @@@ -401,8 -392,7 +401,8 @@@ struct address_space gfp_t gfp_mask; /* implicit gfp mask for allocations */ struct list_headprivate_list; /* ditto */ void*private_data; /* ditto */ + errseq_twb_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 @@@ -880,9 -868,8 +880,10 @@@ struct file struct list_headf_tfile_llink; #endif /* #ifdef CONFIG_EPOLL */ struct address_space*f_mapping; + errseq_tf_wb_err; /* data writeback error tracking */ + errseq_tf_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;
linux-next: manual merge of the kspp tree with the file-locks tree
Hi Kees, 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.. --- 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_headprivate_list; /* ditto */ void*private_data; /* ditto */ + errseq_twb_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_headf_tfile_llink; #endif /* #ifdef CONFIG_EPOLL */ struct address_space*f_mapping; + errseq_tf_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;