Re: linux-next: manual merge of the staging tree with the block tree

[Gao Xiang]

Hi Stephen,

On 2019/5/8 11:44, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 1 May 2019 17:05:28 +1000 Stephen Rothwell  
> wrote:
>>
>> Today's linux-next merge of the staging tree got conflicts in:
>>
>>   drivers/staging/erofs/data.c
>>   drivers/staging/erofs/unzip_vle.c
>>
>> between commit:
>>
>>   2b070cfe582b ("block: remove the i argument to bio_for_each_segment_all")
>>
>> from the block tree and commit:
>>
>>   14a56ec65bab ("staging: erofs: support IO read error injection")
>>
>> from the staging 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 drivers/staging/erofs/data.c
>> index 9f04d7466c55,c64ec76643d4..
>> --- a/drivers/staging/erofs/data.c
>> +++ b/drivers/staging/erofs/data.c
>> @@@ -17,11 -17,18 +17,17 @@@
>>   
>>   static inline void read_endio(struct bio *bio)
>>   {
>> +struct super_block *const sb = bio->bi_private;
>>  -   int i;
>>  struct bio_vec *bvec;
>> -const blk_status_t err = bio->bi_status;
>> +blk_status_t err = bio->bi_status;
>>  struct bvec_iter_all iter_all;
>>   
>> +if (time_to_inject(EROFS_SB(sb), FAULT_READ_IO)) {
>> +erofs_show_injection_info(FAULT_READ_IO);
>> +err = BLK_STS_IOERR;
>> +}
>> + 
>>  -   bio_for_each_segment_all(bvec, bio, i, iter_all) {
>>  +   bio_for_each_segment_all(bvec, bio, iter_all) {
>>  struct page *page = bvec->bv_page;
>>   
>>  /* page is already locked */
>> diff --cc drivers/staging/erofs/unzip_vle.c
>> index 59b9f37d5c00,a2e03c932102..
>> --- a/drivers/staging/erofs/unzip_vle.c
>> +++ b/drivers/staging/erofs/unzip_vle.c
>> @@@ -843,14 -844,13 +844,12 @@@ static void z_erofs_vle_unzip_kickoff(v
>>   
>>   static inline void z_erofs_vle_read_endio(struct bio *bio)
>>   {
>> -const blk_status_t err = bio->bi_status;
>> +struct erofs_sb_info *sbi = NULL;
>> +blk_status_t err = bio->bi_status;
>>  -   unsigned int i;
>>  struct bio_vec *bvec;
>> - #ifdef EROFS_FS_HAS_MANAGED_CACHE
>> -struct address_space *mc = NULL;
>> - #endif
>>  struct bvec_iter_all iter_all;
>>   
>>  -   bio_for_each_segment_all(bvec, bio, i, iter_all) {
>>  +   bio_for_each_segment_all(bvec, bio, iter_all) {
>>  struct page *page = bvec->bv_page;
>>  bool cachemngd = false;
>>   
> 
> This conflict is now between the block tree and Linus' tree.

It seems that the conflict has been resolved in linus' tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b070cfe582b8e99fec6ada57d2e59e194aae202

Thanks,
Gao Xiang


> 

Re: linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi all,

On Wed, 1 May 2019 17:05:28 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/erofs/data.c
>   drivers/staging/erofs/unzip_vle.c
> 
> between commit:
> 
>   2b070cfe582b ("block: remove the i argument to bio_for_each_segment_all")
> 
> from the block tree and commit:
> 
>   14a56ec65bab ("staging: erofs: support IO read error injection")
> 
> from the staging 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 drivers/staging/erofs/data.c
> index 9f04d7466c55,c64ec76643d4..
> --- a/drivers/staging/erofs/data.c
> +++ b/drivers/staging/erofs/data.c
> @@@ -17,11 -17,18 +17,17 @@@
>   
>   static inline void read_endio(struct bio *bio)
>   {
> + struct super_block *const sb = bio->bi_private;
>  -int i;
>   struct bio_vec *bvec;
> - const blk_status_t err = bio->bi_status;
> + blk_status_t err = bio->bi_status;
>   struct bvec_iter_all iter_all;
>   
> + if (time_to_inject(EROFS_SB(sb), FAULT_READ_IO)) {
> + erofs_show_injection_info(FAULT_READ_IO);
> + err = BLK_STS_IOERR;
> + }
> + 
>  -bio_for_each_segment_all(bvec, bio, i, iter_all) {
>  +bio_for_each_segment_all(bvec, bio, iter_all) {
>   struct page *page = bvec->bv_page;
>   
>   /* page is already locked */
> diff --cc drivers/staging/erofs/unzip_vle.c
> index 59b9f37d5c00,a2e03c932102..
> --- a/drivers/staging/erofs/unzip_vle.c
> +++ b/drivers/staging/erofs/unzip_vle.c
> @@@ -843,14 -844,13 +844,12 @@@ static void z_erofs_vle_unzip_kickoff(v
>   
>   static inline void z_erofs_vle_read_endio(struct bio *bio)
>   {
> - const blk_status_t err = bio->bi_status;
> + struct erofs_sb_info *sbi = NULL;
> + blk_status_t err = bio->bi_status;
>  -unsigned int i;
>   struct bio_vec *bvec;
> - #ifdef EROFS_FS_HAS_MANAGED_CACHE
> - struct address_space *mc = NULL;
> - #endif
>   struct bvec_iter_all iter_all;
>   
>  -bio_for_each_segment_all(bvec, bio, i, iter_all) {
>  +bio_for_each_segment_all(bvec, bio, iter_all) {
>   struct page *page = bvec->bv_page;
>   bool cachemngd = false;
>   

This conflict is now between the block tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgp0ac28V7kvJ.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the staging tree with the block tree

[Gao Xiang]

Hi,

On 2019/5/1 ??3:05, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the staging tree got conflicts in:

   drivers/staging/erofs/data.c
   drivers/staging/erofs/unzip_vle.c

between commit:

   2b070cfe582b ("block: remove the i argument to bio_for_each_segment_all")

from the block tree and commit:

   14a56ec65bab ("staging: erofs: support IO read error injection")

from the staging 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.


the patch looks good to me,


Thanks,
Gao Xiang

linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the staging tree got conflicts in:

  drivers/staging/erofs/data.c
  drivers/staging/erofs/unzip_vle.c

between commit:

  2b070cfe582b ("block: remove the i argument to bio_for_each_segment_all")

from the block tree and commit:

  14a56ec65bab ("staging: erofs: support IO read error injection")

from the staging 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 drivers/staging/erofs/data.c
index 9f04d7466c55,c64ec76643d4..
--- a/drivers/staging/erofs/data.c
+++ b/drivers/staging/erofs/data.c
@@@ -17,11 -17,18 +17,17 @@@
  
  static inline void read_endio(struct bio *bio)
  {
+   struct super_block *const sb = bio->bi_private;
 -  int i;
struct bio_vec *bvec;
-   const blk_status_t err = bio->bi_status;
+   blk_status_t err = bio->bi_status;
struct bvec_iter_all iter_all;
  
+   if (time_to_inject(EROFS_SB(sb), FAULT_READ_IO)) {
+   erofs_show_injection_info(FAULT_READ_IO);
+   err = BLK_STS_IOERR;
+   }
+ 
 -  bio_for_each_segment_all(bvec, bio, i, iter_all) {
 +  bio_for_each_segment_all(bvec, bio, iter_all) {
struct page *page = bvec->bv_page;
  
/* page is already locked */
diff --cc drivers/staging/erofs/unzip_vle.c
index 59b9f37d5c00,a2e03c932102..
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@@ -843,14 -844,13 +844,12 @@@ static void z_erofs_vle_unzip_kickoff(v
  
  static inline void z_erofs_vle_read_endio(struct bio *bio)
  {
-   const blk_status_t err = bio->bi_status;
+   struct erofs_sb_info *sbi = NULL;
+   blk_status_t err = bio->bi_status;
 -  unsigned int i;
struct bio_vec *bvec;
- #ifdef EROFS_FS_HAS_MANAGED_CACHE
-   struct address_space *mc = NULL;
- #endif
struct bvec_iter_all iter_all;
  
 -  bio_for_each_segment_all(bvec, bio, i, iter_all) {
 +  bio_for_each_segment_all(bvec, bio, iter_all) {
struct page *page = bvec->bv_page;
bool cachemngd = false;
  


pgp3tihsd3MXM.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi all,

On Tue, 14 Jun 2016 15:07:37 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/lustre/lustre/llite/lloop.c
> 
> between commit:
> 
>   95fe6c1a209e ("block, fs, mm, drivers: use bio set/get op accessors")
> 
> from the block tree and commit:
> 
>   67b1a24e883c ("staging: lustre: llite: remove lloop device")
> 
> from the staging tree.
> 
> I fixed it up (I removed the file) 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.

Since Linus has merged the staging tree, this file will need to be
removed when the block tree is merged into Linus' tree.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi all,

On Tue, 14 Jun 2016 15:07:37 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/lustre/lustre/llite/lloop.c
> 
> between commit:
> 
>   95fe6c1a209e ("block, fs, mm, drivers: use bio set/get op accessors")
> 
> from the block tree and commit:
> 
>   67b1a24e883c ("staging: lustre: llite: remove lloop device")
> 
> from the staging tree.
> 
> I fixed it up (I removed the file) 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.

Since Linus has merged the staging tree, this file will need to be
removed when the block tree is merged into Linus' tree.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/lustre/lustre/llite/lloop.c

between commit:

  95fe6c1a209e ("block, fs, mm, drivers: use bio set/get op accessors")

from the block tree and commit:

  67b1a24e883c ("staging: lustre: llite: remove lloop device")

from the staging tree.

I fixed it up (I removed the file) 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

linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/lustre/lustre/llite/lloop.c

between commit:

  95fe6c1a209e ("block, fs, mm, drivers: use bio set/get op accessors")

from the block tree and commit:

  67b1a24e883c ("staging: lustre: llite: remove lloop device")

from the staging tree.

I fixed it up (I removed the file) 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

Re: linux-next: manual merge of the staging tree with the block tree

[Greg KH]

On Tue, Nov 05, 2013 at 01:49:26AM -0800, Christoph Hellwig wrote:
> On Mon, Nov 04, 2013 at 09:20:10PM -0800, Greg KH wrote:
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > 
> > Looks good to me, thanks.
> 
> The lloop driver should simply be dropped.  It's a duplication of loop
> which had some lustre-specific hacks that are replaced with generic
> improvements already in linux-next.

That's fine with me, I figure it will be deleted eventually by someone
sending me a patch to do so...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the staging tree with the block tree

[Christoph Hellwig]

On Mon, Nov 04, 2013 at 09:20:10PM -0800, Greg KH wrote:
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> 
> Looks good to me, thanks.

The lloop driver should simply be dropped.  It's a duplication of loop
which had some lustre-specific hacks that are replaced with generic
improvements already in linux-next.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the staging tree with the block tree

[Christoph Hellwig]

On Mon, Nov 04, 2013 at 09:20:10PM -0800, Greg KH wrote:
  I fixed it up (see below) and can carry the fix as necessary (no action
  is required).
 
 Looks good to me, thanks.

The lloop driver should simply be dropped.  It's a duplication of loop
which had some lustre-specific hacks that are replaced with generic
improvements already in linux-next.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the staging tree with the block tree

[Greg KH]

On Tue, Nov 05, 2013 at 01:49:26AM -0800, Christoph Hellwig wrote:
 On Mon, Nov 04, 2013 at 09:20:10PM -0800, Greg KH wrote:
   I fixed it up (see below) and can carry the fix as necessary (no action
   is required).
  
  Looks good to me, thanks.
 
 The lloop driver should simply be dropped.  It's a duplication of loop
 which had some lustre-specific hacks that are replaced with generic
 improvements already in linux-next.

That's fine with me, I figure it will be deleted eventually by someone
sending me a patch to do so...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the staging tree with the block tree

[Greg KH]

On Tue, Nov 05, 2013 at 04:09:24PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265
> ("block: Abstract out bvec iterator") from the block tree and commit
> de40d1209898 ("staging: lustre: fix bug with LL_MRF_RETURN in
> loop_make_request") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265
("block: Abstract out bvec iterator") from the block tree and commit
de40d1209898 ("staging: lustre: fix bug with LL_MRF_RETURN in
loop_make_request") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/staging/lustre/lustre/llite/lloop.c
index 3488bb6c44a7,e2421ea61352..
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@@ -368,10 -365,9 +367,9 @@@ static void loop_make_request(struct re
goto err;
}
loop_add_bio(lo, old_bio);
-   LL_MRF_RETURN(0);
+   return;
  err:
 -  cfs_bio_io_error(old_bio, old_bio->bi_size);
 +  cfs_bio_io_error(old_bio, old_bio->bi_iter.bi_size);
-   LL_MRF_RETURN(0);
  }
  
  


pgpdDLQfbmLDS.pgp
Description: PGP signature

linux-next: manual merge of the staging tree with the block tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265
(block: Abstract out bvec iterator) from the block tree and commit
de40d1209898 (staging: lustre: fix bug with LL_MRF_RETURN in
loop_make_request) from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/staging/lustre/lustre/llite/lloop.c
index 3488bb6c44a7,e2421ea61352..
--- a/drivers/staging/lustre/lustre/llite/lloop.c
+++ b/drivers/staging/lustre/lustre/llite/lloop.c
@@@ -368,10 -365,9 +367,9 @@@ static void loop_make_request(struct re
goto err;
}
loop_add_bio(lo, old_bio);
-   LL_MRF_RETURN(0);
+   return;
  err:
 -  cfs_bio_io_error(old_bio, old_bio-bi_size);
 +  cfs_bio_io_error(old_bio, old_bio-bi_iter.bi_size);
-   LL_MRF_RETURN(0);
  }
  
  


pgpdDLQfbmLDS.pgp
Description: PGP signature

Re: linux-next: manual merge of the staging tree with the block tree

[Greg KH]

On Tue, Nov 05, 2013 at 04:09:24PM +1100, Stephen Rothwell wrote:
 Hi Greg,
 
 Today's linux-next merge of the staging tree got a conflict in
 drivers/staging/lustre/lustre/llite/lloop.c between commit ed2d2f9a8265
 (block: Abstract out bvec iterator) from the block tree and commit
 de40d1209898 (staging: lustre: fix bug with LL_MRF_RETURN in
 loop_make_request) from the staging tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

Looks good to me, thanks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/