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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

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 Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/lustre/lustre/llite/lloop.c
index 3488bb6c44a7,e2421ea61352..000000000000
--- 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);
  }
  
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

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.

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...

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 <sfr@canb.auug.org.au> 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..000000000000
>> --- 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..000000000000
>> --- 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]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

Hi all,

On Wed, 1 May 2019 17:05:28 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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..000000000000
> --- 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..000000000000
> --- 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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]

[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

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..000000000000
--- 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..000000000000
--- 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;
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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 <sfr@canb.auug.org.au> 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

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

[Greg KH]

On Tue, Oct 04, 2011 at 05:14:15PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/zram/zram_drv.c between commit 5a7bbad27a41 ("block:
> remove support for bio remapping from ->make_request") from the block
> tree and commit 0900beae178a ("staging: zram: fix zram locking") from the
> staging tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary.

That looks correct to me, thanks for doing this.

greg k-h

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/zram/zram_drv.c between commit 5a7bbad27a41 ("block:
remove support for bio remapping from ->make_request") from the block
tree and commit 0900beae178a ("staging: zram: fix zram locking") from the
staging tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/zram/zram_drv.c
index 02589ca,b9926ee..0000000
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@@ -572,9 -573,18 +573,17 @@@ static void zram_make_request(struct re
  	}
  
  	__zram_make_request(zram, bio, bio_data_dir(bio));
+ 	up_read(&zram->init_lock);
+ 
 -	return 0;
++	return;
+ 
+ error_unlock:
+ 	up_read(&zram->init_lock);
+ error:
+ 	bio_io_error(bio);
 -	return 0;
  }
  
- void zram_reset_device(struct zram *zram)
+ void __zram_reset_device(struct zram *zram)
  {
  	size_t index;
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]