Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: manual merge of the akpm-current tree with the block tree
@ 2021-04-07  9:18 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2021-04-07  9:18 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Christoph Hellwig, Linux Kernel Mailing List,
	Linux Next Mailing List, Matthew Wilcox (Oracle)


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

Hi all,

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

  block/blk-settings.c

between commit:

  9bb33f24abbd ("block: refactor the bounce buffering code")

from the block tree and commit:

  1d4982a2dc66 ("include: remove pagemap.h from blkdev.h")

from the akpm-current 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 block/blk-settings.c
index 9c009090c4b5,976085a44fb8..000000000000
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@@ -7,6 -7,8 +7,7 @@@
  #include <linux/init.h>
  #include <linux/bio.h>
  #include <linux/blkdev.h>
+ #include <linux/pagemap.h>
 -#include <linux/memblock.h>	/* for max_pfn/max_low_pfn */
  #include <linux/gcd.h>
  #include <linux/lcm.h>
  #include <linux/jiffies.h>

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2021-06-02  5:40 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2021-06-02  5:40 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Christoph Hellwig, Linux Kernel Mailing List,
	Linux Next Mailing List, Yue Hu


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

Hi all,

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

  drivers/block/zram/zram_drv.h

between commit:

  a8698707a183 ("block: move bd_mutex to struct gendisk")

from the block tree and commit:

  53dc46e0dbcf ("zram: move backing_dev under macro CONFIG_ZRAM_WRITEBACK")

from the akpm-current 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/block/zram/zram_drv.h
index 74c411911b6e,6e73dc3c2769..000000000000
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@@ -112,9 -112,9 +112,9 @@@ struct zram 
  	/*
  	 * zram is claimed so open request will be failed
  	 */
 -	bool claim; /* Protected by bdev->bd_mutex */
 +	bool claim; /* Protected by disk->open_mutex */
- 	struct file *backing_dev;
  #ifdef CONFIG_ZRAM_WRITEBACK
+ 	struct file *backing_dev;
  	spinlock_t wb_limit_lock;
  	bool wb_limit_enable;
  	u64 bd_wb_limit;

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2021-03-18 17:54 ` Shakeel Butt
@ 2021-03-18 18:19   ` Jens Axboe
  0 siblings, 0 replies; 28+ messages in thread
From: Jens Axboe @ 2021-03-18 18:19 UTC (permalink / raw)
  To: Shakeel Butt, Stephen Rothwell
  Cc: Andrew Morton, Dan Schatzberg, Linux Kernel Mailing List,
	Linux Next Mailing List

On 3/18/21 11:54 AM, Shakeel Butt wrote:
> On Wed, Mar 17, 2021 at 11:17 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> Today's linux-next merge of the akpm-current tree got a conflict in:
>>
>>   mm/memcontrol.c
>>
>> between commit:
>>
>>   06d69d4c8669 ("mm: Charge active memcg when no mm is set")
>>
>> from the block tree and commit:
>>
>>   674788258a66 ("memcg: charge before adding to swapcache on swapin")
>>
>> from the akpm-current tree.
>>
>> I fixed it up (I think - 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 mm/memcontrol.c
>> index f05501669e29,668d1d7c2645..000000000000
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@@ -6691,65 -6549,73 +6550,80 @@@ out
>>    * @gfp_mask: reclaim mode
>>    *
>>    * Try to charge @page to the memcg that @mm belongs to, reclaiming
>>  - * pages according to @gfp_mask if necessary.
>>  + * pages according to @gfp_mask if necessary. if @mm is NULL, try to
>>  + * charge to the active memcg.
>>    *
>> +  * Do not use this for pages allocated for swapin.
>> +  *
>>    * Returns 0 on success. Otherwise, an error code is returned.
>>    */
>>   int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask)
>>   {
>> -       unsigned int nr_pages = thp_nr_pages(page);
>> -       struct mem_cgroup *memcg = NULL;
>> -       int ret = 0;
>> +       struct mem_cgroup *memcg;
>> +       int ret;
>>
>>         if (mem_cgroup_disabled())
>> -               goto out;
>> +               return 0;
>>
>> -       if (PageSwapCache(page)) {
>> -               swp_entry_t ent = { .val = page_private(page), };
>> -               unsigned short id;
>>  -      memcg = get_mem_cgroup_from_mm(mm);
>> ++      if (!mm) {
>> ++              memcg = get_mem_cgroup_from_current();
>> ++              if (!memcg)
>> ++                      memcg = get_mem_cgroup_from_mm(current->mm);
>> ++      } else {
>> ++              memcg = get_mem_cgroup_from_mm(mm);
>> ++      }
>> +       ret = __mem_cgroup_charge(page, memcg, gfp_mask);
>> +       css_put(&memcg->css);
> 
> Things are more complicated than this. First we need a similar change
> in mem_cgroup_swapin_charge_page() but I am thinking of making
> get_mem_cgroup_from_mm() more general and not make any changes in
> these two functions.
> 
> Is it possible to get Dan's patch series in mm tree? More specifically
> the above two patches in the same tree then one of us can make their
> patch rebase over the other (I am fine with doing this myself).

Yes, I think we should do that, and since he's going to be respinning
the series anyway, I'll drop it right now and then let's take it through
Andrew to avoid unnecessary complications that way.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2021-03-18  6:17 Stephen Rothwell
@ 2021-03-18 17:54 ` Shakeel Butt
  2021-03-18 18:19   ` Jens Axboe
  0 siblings, 1 reply; 28+ messages in thread
From: Shakeel Butt @ 2021-03-18 17:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jens Axboe, Dan Schatzberg,
	Linux Kernel Mailing List, Linux Next Mailing List

On Wed, Mar 17, 2021 at 11:17 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   mm/memcontrol.c
>
> between commit:
>
>   06d69d4c8669 ("mm: Charge active memcg when no mm is set")
>
> from the block tree and commit:
>
>   674788258a66 ("memcg: charge before adding to swapcache on swapin")
>
> from the akpm-current tree.
>
> I fixed it up (I think - 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 mm/memcontrol.c
> index f05501669e29,668d1d7c2645..000000000000
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@@ -6691,65 -6549,73 +6550,80 @@@ out
>    * @gfp_mask: reclaim mode
>    *
>    * Try to charge @page to the memcg that @mm belongs to, reclaiming
>  - * pages according to @gfp_mask if necessary.
>  + * pages according to @gfp_mask if necessary. if @mm is NULL, try to
>  + * charge to the active memcg.
>    *
> +  * Do not use this for pages allocated for swapin.
> +  *
>    * Returns 0 on success. Otherwise, an error code is returned.
>    */
>   int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask)
>   {
> -       unsigned int nr_pages = thp_nr_pages(page);
> -       struct mem_cgroup *memcg = NULL;
> -       int ret = 0;
> +       struct mem_cgroup *memcg;
> +       int ret;
>
>         if (mem_cgroup_disabled())
> -               goto out;
> +               return 0;
>
> -       if (PageSwapCache(page)) {
> -               swp_entry_t ent = { .val = page_private(page), };
> -               unsigned short id;
>  -      memcg = get_mem_cgroup_from_mm(mm);
> ++      if (!mm) {
> ++              memcg = get_mem_cgroup_from_current();
> ++              if (!memcg)
> ++                      memcg = get_mem_cgroup_from_mm(current->mm);
> ++      } else {
> ++              memcg = get_mem_cgroup_from_mm(mm);
> ++      }
> +       ret = __mem_cgroup_charge(page, memcg, gfp_mask);
> +       css_put(&memcg->css);

Things are more complicated than this. First we need a similar change
in mem_cgroup_swapin_charge_page() but I am thinking of making
get_mem_cgroup_from_mm() more general and not make any changes in
these two functions.

Is it possible to get Dan's patch series in mm tree? More specifically
the above two patches in the same tree then one of us can make their
patch rebase over the other (I am fine with doing this myself).

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2021-03-18  6:17 Stephen Rothwell
  2021-03-18 17:54 ` Shakeel Butt
  0 siblings, 1 reply; 28+ messages in thread
From: Stephen Rothwell @ 2021-03-18  6:17 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Dan Schatzberg, Linux Kernel Mailing List,
	Linux Next Mailing List, Shakeel Butt


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

Hi all,

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

  mm/memcontrol.c

between commit:

  06d69d4c8669 ("mm: Charge active memcg when no mm is set")

from the block tree and commit:

  674788258a66 ("memcg: charge before adding to swapcache on swapin")

from the akpm-current tree.

I fixed it up (I think - 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 mm/memcontrol.c
index f05501669e29,668d1d7c2645..000000000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -6691,65 -6549,73 +6550,80 @@@ out
   * @gfp_mask: reclaim mode
   *
   * Try to charge @page to the memcg that @mm belongs to, reclaiming
 - * pages according to @gfp_mask if necessary.
 + * pages according to @gfp_mask if necessary. if @mm is NULL, try to
 + * charge to the active memcg.
   *
+  * Do not use this for pages allocated for swapin.
+  *
   * Returns 0 on success. Otherwise, an error code is returned.
   */
  int mem_cgroup_charge(struct page *page, struct mm_struct *mm, gfp_t gfp_mask)
  {
- 	unsigned int nr_pages = thp_nr_pages(page);
- 	struct mem_cgroup *memcg = NULL;
- 	int ret = 0;
+ 	struct mem_cgroup *memcg;
+ 	int ret;
  
  	if (mem_cgroup_disabled())
- 		goto out;
+ 		return 0;
  
- 	if (PageSwapCache(page)) {
- 		swp_entry_t ent = { .val = page_private(page), };
- 		unsigned short id;
 -	memcg = get_mem_cgroup_from_mm(mm);
++	if (!mm) {
++		memcg = get_mem_cgroup_from_current();
++		if (!memcg)
++			memcg = get_mem_cgroup_from_mm(current->mm);
++	} else {
++		memcg = get_mem_cgroup_from_mm(mm);
++	}
+ 	ret = __mem_cgroup_charge(page, memcg, gfp_mask);
+ 	css_put(&memcg->css);
  
- 		/*
- 		 * Every swap fault against a single page tries to charge the
- 		 * page, bail as early as possible.  shmem_unuse() encounters
- 		 * already charged pages, too.  page and memcg binding is
- 		 * protected by the page lock, which serializes swap cache
- 		 * removal, which in turn serializes uncharging.
- 		 */
- 		VM_BUG_ON_PAGE(!PageLocked(page), page);
- 		if (page_memcg(compound_head(page)))
- 			goto out;
+ 	return ret;
+ }
  
- 		id = lookup_swap_cgroup_id(ent);
- 		rcu_read_lock();
- 		memcg = mem_cgroup_from_id(id);
- 		if (memcg && !css_tryget_online(&memcg->css))
- 			memcg = NULL;
- 		rcu_read_unlock();
- 	}
+ /**
+  * mem_cgroup_swapin_charge_page - charge a newly allocated page for swapin
+  * @page: page to charge
+  * @mm: mm context of the victim
+  * @gfp: reclaim mode
+  * @entry: swap entry for which the page is allocated
+  *
+  * This function charges a page allocated for swapin. Please call this before
+  * adding the page to the swapcache.
+  *
+  * Returns 0 on success. Otherwise, an error code is returned.
+  */
+ int mem_cgroup_swapin_charge_page(struct page *page, struct mm_struct *mm,
+ 				  gfp_t gfp, swp_entry_t entry)
+ {
+ 	struct mem_cgroup *memcg;
+ 	unsigned short id;
+ 	int ret;
  
- 	if (!memcg) {
- 		if (!mm) {
- 			memcg = get_mem_cgroup_from_current();
- 			if (!memcg)
- 				memcg = get_mem_cgroup_from_mm(current->mm);
- 		} else {
- 			memcg = get_mem_cgroup_from_mm(mm);
- 		}
- 	}
+ 	if (mem_cgroup_disabled())
+ 		return 0;
  
- 	ret = try_charge(memcg, gfp_mask, nr_pages);
- 	if (ret)
- 		goto out_put;
+ 	id = lookup_swap_cgroup_id(entry);
+ 	rcu_read_lock();
+ 	memcg = mem_cgroup_from_id(id);
+ 	if (!memcg || !css_tryget_online(&memcg->css))
+ 		memcg = get_mem_cgroup_from_mm(mm);
+ 	rcu_read_unlock();
  
- 	css_get(&memcg->css);
- 	commit_charge(page, memcg);
+ 	ret = __mem_cgroup_charge(page, memcg, gfp);
  
- 	local_irq_disable();
- 	mem_cgroup_charge_statistics(memcg, page, nr_pages);
- 	memcg_check_events(memcg, page);
- 	local_irq_enable();
+ 	css_put(&memcg->css);
+ 	return ret;
+ }
  
+ /*
+  * mem_cgroup_swapin_uncharge_swap - uncharge swap slot
+  * @entry: swap entry for which the page is charged
+  *
+  * Call this function after successfully adding the charged page to swapcache.
+  *
+  * Note: This function assumes the page for which swap slot is being uncharged
+  * is order 0 page.
+  */
+ void mem_cgroup_swapin_uncharge_swap(swp_entry_t entry)
+ {
  	/*
  	 * Cgroup1's unified memory+swap counter has been charged with the
  	 * new swapcache page, finish the transfer by uncharging the swap

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2020-11-17  5:05 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2020-11-17  5:05 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Kent Overstreet, Linux Kernel Mailing List, Linux Next Mailing List


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

Hi all,

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

  mm/filemap.c

between commit:

  0abed7c69b95 ("mm: never attempt async page lock if we've transferred data already")

from the block tree and commit:

  b5c7e73f6bd3 ("mm/filemap/c: break generic_file_buffered_read up into multiple functions")

from the akpm-current tree.

I just used the latter version for today, if more is needed, please let
me know.

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

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2020-10-15  6:27 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2020-10-15  6:27 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: David Howells, Linux Kernel Mailing List,
	Linux Next Mailing List, Matthew Wilcox (Oracle)


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

Hi all,

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

  mm/readahead.c

between commit:

  fd0ec96ec35d ("readahead: use limited read-ahead to satisfy read")

from the block tree and commits:

  16681dc9dd92 ("mm/readahead: pass readahead_control to force_page_cache_ra")
  f65bd470e7ed ("mm/readahead: add page_cache_sync_ra and page_cache_async_ra")

from the akpm-current 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 mm/readahead.c
index e5975f4e0ee5,c6ffb76827da..000000000000
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@@ -548,42 -545,23 +545,29 @@@ readit
  		}
  	}
  
- 	ra_submit(ra, mapping, filp);
+ 	ractl->_index = ra->start;
+ 	do_page_cache_ra(ractl, ra->size, ra->async_size);
  }
  
- /**
-  * page_cache_sync_readahead - generic file readahead
-  * @mapping: address_space which holds the pagecache and I/O vectors
-  * @ra: file_ra_state which holds the readahead state
-  * @filp: passed on to ->readpage() and ->readpages()
-  * @index: Index of first page to be read.
-  * @req_count: Total number of pages being read by the caller.
-  *
-  * page_cache_sync_readahead() should be called when a cache miss happened:
-  * it will submit the read.  The readahead logic may decide to piggyback more
-  * pages onto the read request if access patterns suggest it will improve
-  * performance.
-  */
- void page_cache_sync_readahead(struct address_space *mapping,
- 			       struct file_ra_state *ra, struct file *filp,
- 			       pgoff_t index, unsigned long req_count)
+ void page_cache_sync_ra(struct readahead_control *ractl,
+ 		struct file_ra_state *ra, unsigned long req_count)
  {
- 	bool do_forced_ra = filp && (filp->f_mode & FMODE_RANDOM);
 -	/* no read-ahead */
 -	if (!ra->ra_pages)
 -		return;
++	bool do_forced_ra = ractl->file && (ractl->file->f_mode & FMODE_RANDOM);
  
 -	if (blk_cgroup_congested())
 -		return;
 +	/*
 +	 * Even if read-ahead is disabled, start this request as read-ahead.
 +	 * This makes regular read-ahead disabled use the same path as normal
 +	 * reads, instead of having to punt to ->readpage() manually. We limit
 +	 * ourselves to 1 page for this case, to avoid causing problems if
 +	 * we're congested or tight on memory.
 +	 */
 +	if (!ra->ra_pages || blk_cgroup_congested()) {
 +		req_count = 1;
 +		do_forced_ra = true;
 +	}
  
 -	/* be dumb */
 -	if (ractl->file && (ractl->file->f_mode & FMODE_RANDOM)) {
 +	if (do_forced_ra) {
- 		force_page_cache_readahead(mapping, filp, index, req_count);
+ 		force_page_cache_ra(ractl, ra, req_count);
  		return;
  	}
  

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2020-09-25  9:57 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2020-09-25  9:57 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Matthew Wilcox (Oracle),
	Christoph Hellwig, Linux Next Mailing List,
	Linux Kernel Mailing List


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

Hi all,

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

  mm/page-writeback.c

between commit:

  1cb039f3dc16 ("bdi: replace BDI_CAP_STABLE_WRITES with a queue and a sb flag")

from the block tree and commit:

  7a3714df632a ("mm/page-writeback: support tail pages in wait_for_stable_page")

from the akpm-current 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 mm/page-writeback.c
index 358d6f28c627,dac075e451d3..000000000000
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@@ -2849,7 -2849,8 +2849,8 @@@ EXPORT_SYMBOL_GPL(wait_on_page_writebac
   */
  void wait_for_stable_page(struct page *page)
  {
+ 	page = thp_head(page);
 -	if (bdi_cap_stable_pages_required(inode_to_bdi(page->mapping->host)))
 +	if (page->mapping->host->i_sb->s_iflags & SB_I_STABLE_WRITES)
  		wait_on_page_writeback(page);
  }
  EXPORT_SYMBOL_GPL(wait_for_stable_page);

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2019-05-03  9:10 Stephen Rothwell
@ 2019-05-03 12:35 ` Amir Goldstein
  0 siblings, 0 replies; 28+ messages in thread
From: Amir Goldstein @ 2019-05-03 12:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jens Axboe, Linux Next Mailing List,
	Linux Kernel Mailing List

On Fri, May 3, 2019 at 5:10 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>   fs/sync.c
>
> between commit:
>
>   22f96b3808c1 ("fs: add sync_file_range() helper")
>
> from the block tree and commit:
>
>   9a8d18789a18 ("fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback")
>
> from the akpm-current 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.
>

Fix looks technically correct, but it would have been better if the fat
comment moved to the fat helper and then replace
s/sys_sync_file_range/ksys_sync_file_range with
s/sys_sync_file_range/sync_file_range

It is probably best if either maintainer took both patches through his tree
and if move and update the comment from "sys_sync_file_range" be done
as part of the helper function patch.

Thanks,
Amir.

> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/sync.c
> index 01e82170545a,9e8cd90e890f..000000000000
> --- a/fs/sync.c
> +++ b/fs/sync.c
> @@@ -292,10 -348,16 +292,16 @@@ int sync_file_range(struct file *file,
>         }
>
>         if (flags & SYNC_FILE_RANGE_WRITE) {
> +               int sync_mode = WB_SYNC_NONE;
> +
> +               if ((flags & SYNC_FILE_RANGE_WRITE_AND_WAIT) ==
> +                            SYNC_FILE_RANGE_WRITE_AND_WAIT)
> +                       sync_mode = WB_SYNC_ALL;
> +
>                 ret = __filemap_fdatawrite_range(mapping, offset, endbyte,
> -                                                WB_SYNC_NONE);
> +                                                sync_mode);
>                 if (ret < 0)
>  -                      goto out_put;
>  +                      goto out;
>         }
>
>         if (flags & SYNC_FILE_RANGE_WAIT_AFTER)
> @@@ -305,68 -369,6 +311,71 @@@ out
>         return ret;
>   }
>
>  +/*
> -  * sys_sync_file_range() permits finely controlled syncing over a segment of
> ++ * ksys_sync_file_range() permits finely controlled syncing over a segment of
>  + * a file in the range offset .. (offset+nbytes-1) inclusive.  If nbytes is
> -  * zero then sys_sync_file_range() will operate from offset out to EOF.
> ++ * zero then ksys_sync_file_range() will operate from offset out to EOF.
>  + *
>  + * The flag bits are:
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE: wait upon writeout of all pages in the range
>  + * before performing the write.
>  + *
>  + * SYNC_FILE_RANGE_WRITE: initiate writeout of all those dirty pages in the
>  + * range which are not presently under writeback. Note that this may block for
>  + * significant periods due to exhaustion of disk request structures.
>  + *
>  + * SYNC_FILE_RANGE_WAIT_AFTER: wait upon writeout of all pages in the range
>  + * after performing the write.
>  + *
>  + * Useful combinations of the flag bits are:
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE: ensures that all pages
> -  * in the range which were dirty on entry to sys_sync_file_range() are placed
> ++ * in the range which were dirty on entry to ksys_sync_file_range() are placed
>  + * under writeout.  This is a start-write-for-data-integrity operation.
>  + *
>  + * SYNC_FILE_RANGE_WRITE: start writeout of all dirty pages in the range which
>  + * are not presently under writeout.  This is an asynchronous flush-to-disk
>  + * operation.  Not suitable for data integrity operations.
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE (or SYNC_FILE_RANGE_WAIT_AFTER): wait for
>  + * completion of writeout of all pages in the range.  This will be used after an
>  + * earlier SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE operation to wait
>  + * for that operation to complete and to return the result.
>  + *
> -  * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER:
> ++ * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER
> ++ * (a.k.a. SYNC_FILE_RANGE_WRITE_AND_WAIT):
>  + * a traditional sync() operation.  This is a write-for-data-integrity operation
>  + * which will ensure that all pages in the range which were dirty on entry to
> -  * sys_sync_file_range() are committed to disk.
> ++ * ksys_sync_file_range() are committed to disk.  It should be noted that disk
> ++ * caches are not flushed by this call, so there are no guarantees here that the
> ++ * data will be available on disk after a crash.
>  + *
>  + *
>  + * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
>  + * I/O errors or ENOSPC conditions and will return those to the caller, after
>  + * clearing the EIO and ENOSPC flags in the address_space.
>  + *
>  + * It should be noted that none of these operations write out the file's
>  + * metadata.  So unless the application is strictly performing overwrites of
>  + * already-instantiated disk blocks, there are no guarantees here that the data
>  + * will be available after a crash.
>  + */
>  +int ksys_sync_file_range(int fd, loff_t offset, loff_t nbytes,
>  +                       unsigned int flags)
>  +{
>  +      int ret;
>  +      struct fd f;
>  +
>  +      ret = -EBADF;
>  +      f = fdget(fd);
>  +      if (f.file)
>  +              ret = sync_file_range(f.file, offset, nbytes, flags);
>  +
>  +      fdput(f);
>  +      return ret;
>  +}
>  +
>   SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, loff_t, nbytes,
>                                 unsigned int, flags)
>   {

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2019-05-03  9:10 Stephen Rothwell
  2019-05-03 12:35 ` Amir Goldstein
  0 siblings, 1 reply; 28+ messages in thread
From: Stephen Rothwell @ 2019-05-03  9:10 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Amir Goldstein


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

Hi all,

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

  fs/sync.c

between commit:

  22f96b3808c1 ("fs: add sync_file_range() helper")

from the block tree and commit:

  9a8d18789a18 ("fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback")

from the akpm-current 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/sync.c
index 01e82170545a,9e8cd90e890f..000000000000
--- a/fs/sync.c
+++ b/fs/sync.c
@@@ -292,10 -348,16 +292,16 @@@ int sync_file_range(struct file *file, 
  	}
  
  	if (flags & SYNC_FILE_RANGE_WRITE) {
+ 		int sync_mode = WB_SYNC_NONE;
+ 
+ 		if ((flags & SYNC_FILE_RANGE_WRITE_AND_WAIT) ==
+ 			     SYNC_FILE_RANGE_WRITE_AND_WAIT)
+ 			sync_mode = WB_SYNC_ALL;
+ 
  		ret = __filemap_fdatawrite_range(mapping, offset, endbyte,
- 						 WB_SYNC_NONE);
+ 						 sync_mode);
  		if (ret < 0)
 -			goto out_put;
 +			goto out;
  	}
  
  	if (flags & SYNC_FILE_RANGE_WAIT_AFTER)
@@@ -305,68 -369,6 +311,71 @@@ out
  	return ret;
  }
  
 +/*
-  * sys_sync_file_range() permits finely controlled syncing over a segment of
++ * ksys_sync_file_range() permits finely controlled syncing over a segment of
 + * a file in the range offset .. (offset+nbytes-1) inclusive.  If nbytes is
-  * zero then sys_sync_file_range() will operate from offset out to EOF.
++ * zero then ksys_sync_file_range() will operate from offset out to EOF.
 + *
 + * The flag bits are:
 + *
 + * SYNC_FILE_RANGE_WAIT_BEFORE: wait upon writeout of all pages in the range
 + * before performing the write.
 + *
 + * SYNC_FILE_RANGE_WRITE: initiate writeout of all those dirty pages in the
 + * range which are not presently under writeback. Note that this may block for
 + * significant periods due to exhaustion of disk request structures.
 + *
 + * SYNC_FILE_RANGE_WAIT_AFTER: wait upon writeout of all pages in the range
 + * after performing the write.
 + *
 + * Useful combinations of the flag bits are:
 + *
 + * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE: ensures that all pages
-  * in the range which were dirty on entry to sys_sync_file_range() are placed
++ * in the range which were dirty on entry to ksys_sync_file_range() are placed
 + * under writeout.  This is a start-write-for-data-integrity operation.
 + *
 + * SYNC_FILE_RANGE_WRITE: start writeout of all dirty pages in the range which
 + * are not presently under writeout.  This is an asynchronous flush-to-disk
 + * operation.  Not suitable for data integrity operations.
 + *
 + * SYNC_FILE_RANGE_WAIT_BEFORE (or SYNC_FILE_RANGE_WAIT_AFTER): wait for
 + * completion of writeout of all pages in the range.  This will be used after an
 + * earlier SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE operation to wait
 + * for that operation to complete and to return the result.
 + *
-  * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER:
++ * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER
++ * (a.k.a. SYNC_FILE_RANGE_WRITE_AND_WAIT):
 + * a traditional sync() operation.  This is a write-for-data-integrity operation
 + * which will ensure that all pages in the range which were dirty on entry to
-  * sys_sync_file_range() are committed to disk.
++ * ksys_sync_file_range() are committed to disk.  It should be noted that disk
++ * caches are not flushed by this call, so there are no guarantees here that the
++ * data will be available on disk after a crash.
 + *
 + *
 + * SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
 + * I/O errors or ENOSPC conditions and will return those to the caller, after
 + * clearing the EIO and ENOSPC flags in the address_space.
 + *
 + * It should be noted that none of these operations write out the file's
 + * metadata.  So unless the application is strictly performing overwrites of
 + * already-instantiated disk blocks, there are no guarantees here that the data
 + * will be available after a crash.
 + */
 +int ksys_sync_file_range(int fd, loff_t offset, loff_t nbytes,
 +			 unsigned int flags)
 +{
 +	int ret;
 +	struct fd f;
 +
 +	ret = -EBADF;
 +	f = fdget(fd);
 +	if (f.file)
 +		ret = sync_file_range(f.file, offset, nbytes, flags);
 +
 +	fdput(f);
 +	return ret;
 +}
 +
  SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, loff_t, nbytes,
  				unsigned int, flags)
  {

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2018-10-02  7:21 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2018-10-02  7:21 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josef Bacik,
	Johannes Weiner


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

Hi Andrew,

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

  block/blk-iolatency.c

between commit:

  1fa2840e56f9 ("blk-iolatency: use a percentile approache for ssd's")

from the block tree and commit:

  07360251b445 ("sched-loadavg-consolidate-load_int-load_frac-calc_load-fix")
  1ccc64569a48 ("sched-loadavg-consolidate-load_int-load_frac-calc_load-fix-fix")

from the akpm-current 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 block/blk-iolatency.c
index 35c48d7b8f78,8793f1344e11..000000000000
--- a/block/blk-iolatency.c
+++ b/block/blk-iolatency.c
@@@ -186,80 -172,6 +186,81 @@@ static inline struct blkcg_gq *lat_to_b
  	return pd_to_blkg(&iolat->pd);
  }
  
 +static inline void latency_stat_init(struct iolatency_grp *iolat,
 +				     struct latency_stat *stat)
 +{
 +	if (iolat->ssd) {
 +		stat->ps.total = 0;
 +		stat->ps.missed = 0;
 +	} else
 +		blk_rq_stat_init(&stat->rqs);
 +}
 +
 +static inline void latency_stat_sum(struct iolatency_grp *iolat,
 +				    struct latency_stat *sum,
 +				    struct latency_stat *stat)
 +{
 +	if (iolat->ssd) {
 +		sum->ps.total += stat->ps.total;
 +		sum->ps.missed += stat->ps.missed;
 +	} else
 +		blk_rq_stat_sum(&sum->rqs, &stat->rqs);
 +}
 +
 +static inline void latency_stat_record_time(struct iolatency_grp *iolat,
 +					    u64 req_time)
 +{
 +	struct latency_stat *stat = get_cpu_ptr(iolat->stats);
 +	if (iolat->ssd) {
 +		if (req_time >= iolat->min_lat_nsec)
 +			stat->ps.missed++;
 +		stat->ps.total++;
 +	} else
 +		blk_rq_stat_add(&stat->rqs, req_time);
 +	put_cpu_ptr(stat);
 +}
 +
 +static inline bool latency_sum_ok(struct iolatency_grp *iolat,
 +				  struct latency_stat *stat)
 +{
 +	if (iolat->ssd) {
 +		u64 thresh = div64_u64(stat->ps.total, 10);
 +		thresh = max(thresh, 1ULL);
 +		return stat->ps.missed < thresh;
 +	}
 +	return stat->rqs.mean <= iolat->min_lat_nsec;
 +}
 +
 +static inline u64 latency_stat_samples(struct iolatency_grp *iolat,
 +				       struct latency_stat *stat)
 +{
 +	if (iolat->ssd)
 +		return stat->ps.total;
 +	return stat->rqs.nr_samples;
 +}
 +
 +static inline void iolat_update_total_lat_avg(struct iolatency_grp *iolat,
 +					      struct latency_stat *stat)
 +{
 +	int exp_idx;
 +
 +	if (iolat->ssd)
 +		return;
 +
 +	/*
- 	 * CALC_LOAD takes in a number stored in fixed point representation.
++	 * calc_load takes in a number stored in fixed point representation.
 +	 * Because we are using this for IO time in ns, the values stored
 +	 * are significantly larger than the FIXED_1 denominator (2048).
 +	 * Therefore, rounding errors in the calculation are negligible and
 +	 * can be ignored.
 +	 */
 +	exp_idx = min_t(int, BLKIOLATENCY_NR_EXP_FACTORS - 1,
 +			div64_u64(iolat->cur_win_nsec,
 +				  BLKIOLATENCY_EXP_BUCKET_SIZE));
- 	CALC_LOAD(iolat->lat_avg, iolatency_exp_factors[exp_idx], stat->rqs.mean);
++	iolat->lat_avg = calc_load(iolat->lat_avg,
++				   iolatency_exp_factors[exp_idx], stat->rqs.mean);
 +}
 +
  static inline bool iolatency_may_queue(struct iolatency_grp *iolat,
  				       wait_queue_entry_t *wait,
  				       bool first_block)

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2018-08-13  7:51 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2018-08-13  7:51 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Coly Li


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

Hi all,

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

  drivers/md/bcache/Kconfig
  drivers/md/bcache/util.h

between commits:

  bc81b47e828a ("bcache: prefer 'help' in Kconfig")
  fc2d5988b597 ("bcache: add identifier names to arguments of function definitions")

from the block tree and commit:

  fbb43f40e27b ("bcache: use routines from lib/crc64.c for CRC64 calculation")

from the akpm-current tree.

I fixed it up (see below, and the latter removed some fo the lines changed
by fc2d5988b597) 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/md/bcache/Kconfig
index 817b9fba50db,af247298409a..000000000000
--- a/drivers/md/bcache/Kconfig
+++ b/drivers/md/bcache/Kconfig
@@@ -1,7 -1,8 +1,8 @@@
  
  config BCACHE
  	tristate "Block device as cache"
+ 	select CRC64
 -	---help---
 +	help
  	Allows a block device to be used as cache for other devices; uses
  	a btree for indexing and the layout is optimized for SSDs.
  
diff --cc drivers/md/bcache/util.h
index 4e0ed19e32d3,a1579e28049f..000000000000
--- a/drivers/md/bcache/util.h
+++ b/drivers/md/bcache/util.h
@@@ -543,11 -543,26 +544,27 @@@ dup:									
  #define RB_PREV(ptr, member)						\
  	container_of_or_null(rb_prev(&(ptr)->member), typeof(*ptr), member)
  
+ static inline uint64_t bch_crc64(const void *p, size_t len)
+ {
+ 	uint64_t crc = 0xffffffffffffffffULL;
+ 
+ 	crc = crc64_be(crc, p, len);
+ 	return crc ^ 0xffffffffffffffffULL;
+ }
+ 
+ static inline uint64_t bch_crc64_update(uint64_t crc,
+ 					const void *p,
+ 					size_t len)
+ {
+ 	crc = crc64_be(crc, p, len);
+ 	return crc;
+ }
+ 
  /* Does linear interpolation between powers of two */
 -static inline unsigned fract_exp_two(unsigned x, unsigned fract_bits)
 +static inline unsigned int fract_exp_two(unsigned int x,
 +					 unsigned int fract_bits)
  {
 -	unsigned fract = x & ~(~0 << fract_bits);
 +	unsigned int fract = x & ~(~0 << fract_bits);
  
  	x >>= fract_bits;
  	x   = 1 << x;

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2018-08-02  8:31 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2018-08-02  8:31 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Josef Bacik,
	Shakeel Butt


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

Hi all,

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

  kernel/fork.c

between commit:

  2c323017e381 ("blk-cgroup: clear the throttle queue on fork")

from the block tree and commit:

  f3ed47469a7b ("fs: fsnotify: account fsnotify metadata to kmemcg")

from the akpm-current 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 kernel/fork.c
index f54c49573139,3913dd898bd4..000000000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -867,11 -867,9 +868,14 @@@ static struct task_struct *dup_task_str
  	tsk->fail_nth = 0;
  #endif
  
 +#ifdef CONFIG_BLK_CGROUP
 +	tsk->throttle_queue = NULL;
 +	tsk->use_memdelay = 0;
 +#endif
 +
+ #ifdef CONFIG_MEMCG
+ 	tsk->active_memcg = NULL;
+ #endif
  	return tsk;
  
  free_stack:

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2018-03-19  6:36 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2018-03-19  6:36 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
	Bart Van Assche, Sergey Senozhatsky


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

Hi Andrew,

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

  drivers/block/zram/zram_drv.h

between commit:

  233bde21aa43 ("block: Move SECTOR_SIZE and SECTOR_SHIFT definitions into <linux/blkdev.h>")

from the block tree and commit:

  5d95e0f3a22b ("zram: drop max_zpage_size and use zs_huge_class_size()")

from the akpm-current 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/block/zram/zram_drv.h
index 1e9bf65c0bfb,d71c8000a964..000000000000
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@@ -21,22 -21,7 +21,6 @@@
  
  #include "zcomp.h"
  
- /*-- Configurable parameters */
- 
- /*
-  * Pages that compress to size greater than this are stored
-  * uncompressed in memory.
-  */
- static const size_t max_zpage_size = PAGE_SIZE / 4 * 3;
- 
- /*
-  * NOTE: max_zpage_size must be less than or equal to:
-  *   ZS_MAX_ALLOC_SIZE. Otherwise, zs_malloc() would
-  * always return failure.
-  */
- 
- /*-- End of configurable params */
- 
 -#define SECTOR_SHIFT		9
  #define SECTORS_PER_PAGE_SHIFT	(PAGE_SHIFT - SECTOR_SHIFT)
  #define SECTORS_PER_PAGE	(1 << SECTORS_PER_PAGE_SHIFT)
  #define ZRAM_LOGICAL_BLOCK_SHIFT 12

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2016-07-13  6:14 Stephen Rothwell
@ 2016-07-13 16:31 ` Jens Axboe
  0 siblings, 0 replies; 28+ messages in thread
From: Jens Axboe @ 2016-07-13 16:31 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: linux-next, linux-kernel, NeilBrown, Keith Busch

On 07/12/2016 11:14 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
>    drivers/nvme/host/core.c
>
> between commit:
>
>    f80ec966c19b ("nvme: Limit command retries")
>
> from the block tree and commit:
>
>    8cc07e463b0c ("NVMe: don't allocate unused nvme_major")
>
> from the akpm-current 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.

Usually I'm not that picky with trivial stuff going through other trees, 
but with the amount of churn we have in NVMe, it really should go 
through the block tree.

-- 
Jens Axboe

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2016-07-13  6:14 Stephen Rothwell
  2016-07-13 16:31 ` Jens Axboe
  0 siblings, 1 reply; 28+ messages in thread
From: Stephen Rothwell @ 2016-07-13  6:14 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: linux-next, linux-kernel, NeilBrown, Keith Busch

Hi Andrew,

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

  drivers/nvme/host/core.c

between commit:

  f80ec966c19b ("nvme: Limit command retries")

from the block tree and commit:

  8cc07e463b0c ("NVMe: don't allocate unused nvme_major")

from the akpm-current 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/nvme/host/core.c
index 86a0c661e74c,3dc259e7bf2a..000000000000
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@@ -48,14 -47,6 +48,11 @@@ unsigned char shutdown_timeout = 5
  module_param(shutdown_timeout, byte, 0644);
  MODULE_PARM_DESC(shutdown_timeout, "timeout in seconds for controller shutdown");
  
 +unsigned int nvme_max_retries = 5;
 +module_param_named(max_retries, nvme_max_retries, uint, 0644);
 +MODULE_PARM_DESC(max_retries, "max number of retries a command may have");
 +EXPORT_SYMBOL_GPL(nvme_max_retries);
 +
- static int nvme_major;
- module_param(nvme_major, int, 0);
- 
  static int nvme_char_major;
  module_param(nvme_char_major, int, 0);
  

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2015-12-07 19:44 ` Andrew Morton
@ 2015-12-07 20:24   ` Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2015-12-07 20:24 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig

Hi Andrew,

On Mon, 7 Dec 2015 11:44:31 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 7 Dec 2015 19:12:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > --- a/fs/block_dev.c
> > +++ b/fs/block_dev.c
> > @@@ -432,7 -432,7 +432,7 @@@ int bdev_write_page(struct block_devic
> >   
> >   	if (!ops->rw_page || bdev_get_integrity(bdev))
> >   		return -EOPNOTSUPP;
> > - 	result = blk_queue_enter(bdev->bd_queue, false);
> >  -	result = blk_queue_enter(bdev->bd_queue, GFP_NOIO);
> > ++	result = blk_queue_enter(bdev->bd_queue, true);
> >   	if (result)  
> 
> We want nowait==false here.

OK, I will fix that up today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2015-12-07  8:12 Stephen Rothwell
@ 2015-12-07 19:44 ` Andrew Morton
  2015-12-07 20:24   ` Stephen Rothwell
  0 siblings, 1 reply; 28+ messages in thread
From: Andrew Morton @ 2015-12-07 19:44 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Jens Axboe, linux-next, linux-kernel, Christoph Hellwig

On Mon, 7 Dec 2015 19:12:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@@ -432,7 -432,7 +432,7 @@@ int bdev_write_page(struct block_devic
>   
>   	if (!ops->rw_page || bdev_get_integrity(bdev))
>   		return -EOPNOTSUPP;
> - 	result = blk_queue_enter(bdev->bd_queue, false);
>  -	result = blk_queue_enter(bdev->bd_queue, GFP_NOIO);
> ++	result = blk_queue_enter(bdev->bd_queue, true);
>   	if (result)

We want nowait==false here.

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2015-12-07  8:12 Stephen Rothwell
  2015-12-07 19:44 ` Andrew Morton
  0 siblings, 1 reply; 28+ messages in thread
From: Stephen Rothwell @ 2015-12-07  8:12 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig

Hi Andrew,

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

  fs/block_dev.c

between commit:

  6f3b0e8bcf3c ("blk-mq: add a flags parameter to blk_mq_alloc_request")

from the block tree and commit:

  f39b774555f0 ("fs/block_dev.c:bdev_write_page(): use blk_queue_enter(..., GFP_NOIO)")

from the akpm-current tree.

I fixed it up (see below, though I am not sure it is the correct fix?) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/block_dev.c
index aa1a45985889,c27362de0039..000000000000
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@@ -432,7 -432,7 +432,7 @@@ int bdev_write_page(struct block_devic
  
  	if (!ops->rw_page || bdev_get_integrity(bdev))
  		return -EOPNOTSUPP;
- 	result = blk_queue_enter(bdev->bd_queue, false);
 -	result = blk_queue_enter(bdev->bd_queue, GFP_NOIO);
++	result = blk_queue_enter(bdev->bd_queue, true);
  	if (result)
  		return result;
  

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2015-11-01 18:38 ` Mel Gorman
@ 2015-11-01 21:51   ` Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2015-11-01 21:51 UTC (permalink / raw)
  To: Mel Gorman
  Cc: Andrew Morton, Jens Axboe, linux-next, linux-kernel, Dan Williams

Hi Mel,

On Sun, 1 Nov 2015 18:38:53 +0000 Mel Gorman <mgorman@techsingularity.net> wrote:
>
> On Mon, Nov 02, 2015 at 02:51:25AM +1100, Stephen Rothwell wrote:
> > 
> > @@ -2038,7 +2038,7 @@ void generic_make_request(struct bio *bio)
> >  	do {
> >  		struct request_queue *q = bdev_get_queue(bio->bi_bdev);
> >  
> > -		if (likely(blk_queue_enter(q, __GFP_WAIT) == 0)) {
> > +		if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
> >  
> >  			q->make_request_fn(q, bio);
> 
> ___GFP_DIRECT_RECLAIM is more appropriate than __GFP_RECLAIM in the
> second hunk.

OK, I have done that for today, thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2015-11-01 15:51 Stephen Rothwell
  2015-11-01 16:04 ` kbuild test robot
  2015-11-01 16:05 ` kbuild test robot
@ 2015-11-01 18:38 ` Mel Gorman
  2015-11-01 21:51   ` Stephen Rothwell
  2 siblings, 1 reply; 28+ messages in thread
From: Mel Gorman @ 2015-11-01 18:38 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Jens Axboe, linux-next, linux-kernel, Dan Williams

On Mon, Nov 02, 2015 at 02:51:25AM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   block/blk-mq.c
> 
> between commit:
> 
>   3ef28e83ab15 ("block: generic request_queue reference counting")
> 
> from the block tree and commit:
> 
>   7cc8e61bde7a ("mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd")
>   415a13cc1c3c ("mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM")
> 
> from the akpm-current tree.
> 
> I fixed it up (the code updated in the latter was moved by the former,
> so I applied the following merge fix patch) and can carry the fix as
> necessary (no action is required).
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 2 Nov 2015 02:49:02 +1100
> Subject: [PATCH] block: fixes for __GPF_WAIT changes
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  block/blk-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 9e32f0868e36..6f2c263f478b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -638,7 +638,7 @@ int blk_queue_enter(struct request_queue *q, gfp_t gfp)
>  		if (percpu_ref_tryget_live(&q->q_usage_counter))
>  			return 0;
>  
> -		if (!(gfp & __GFP_WAIT))
> +		if (!gfpflags_allow_blocking(gfp))
>  			return -EBUSY;
>  
>  		ret = wait_event_interruptible(q->mq_freeze_wq,
> @@ -2038,7 +2038,7 @@ void generic_make_request(struct bio *bio)
>  	do {
>  		struct request_queue *q = bdev_get_queue(bio->bi_bdev);
>  
> -		if (likely(blk_queue_enter(q, __GFP_WAIT) == 0)) {
> +		if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
>  
>  			q->make_request_fn(q, bio);
>  

Hi Stephen,

___GFP_DIRECT_RECLAIM is more appropriate than __GFP_RECLAIM in the
second hunk.

Thanks.

-- 
Mel Gorman
SUSE Labs

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2015-11-01 15:51 Stephen Rothwell
  2015-11-01 16:04 ` kbuild test robot
@ 2015-11-01 16:05 ` kbuild test robot
  2015-11-01 18:38 ` Mel Gorman
  2 siblings, 0 replies; 28+ messages in thread
From: kbuild test robot @ 2015-11-01 16:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: kbuild-all, Andrew Morton, Jens Axboe, linux-next, linux-kernel,
	Mel Gorman, Dan Williams


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

Hi Stephen,

[auto build test ERROR on block/for-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base]

url:    https://github.com/0day-ci/linux/commits/Stephen-Rothwell/linux-next-manual-merge-of-the-akpm-current-tree-with-the-block-tree/20151101-235406
config: x86_64-randconfig-x019-201544 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   block/blk-core.c: In function 'blk_queue_enter':
>> block/blk-core.c:641:8: error: implicit declaration of function 'gfpflags_allow_blocking' [-Werror=implicit-function-declaration]
      if (!gfpflags_allow_blocking(gfp))
           ^
   In file included from include/linux/linkage.h:4:0,
                    from include/linux/kernel.h:6,
                    from block/blk-core.c:14:
   block/blk-core.c: In function 'generic_make_request':
>> block/blk-core.c:2041:33: error: '__GFP_RECLAIM' undeclared (first use in this function)
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
                                    ^
   include/linux/compiler.h:165:40: note: in definition of macro 'likely'
    # define likely(x) __builtin_expect(!!(x), 1)
                                           ^
   block/blk-core.c:2041:33: note: each undeclared identifier is reported only once for each function it appears in
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
                                    ^
   include/linux/compiler.h:165:40: note: in definition of macro 'likely'
    # define likely(x) __builtin_expect(!!(x), 1)
                                           ^
   cc1: some warnings being treated as errors

vim +/gfpflags_allow_blocking +641 block/blk-core.c

   635		while (true) {
   636			int ret;
   637	
   638			if (percpu_ref_tryget_live(&q->q_usage_counter))
   639				return 0;
   640	
 > 641			if (!gfpflags_allow_blocking(gfp))
   642				return -EBUSY;
   643	
   644			ret = wait_event_interruptible(q->mq_freeze_wq,

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 25667 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: linux-next: manual merge of the akpm-current tree with the block tree
  2015-11-01 15:51 Stephen Rothwell
@ 2015-11-01 16:04 ` kbuild test robot
  2015-11-01 16:05 ` kbuild test robot
  2015-11-01 18:38 ` Mel Gorman
  2 siblings, 0 replies; 28+ messages in thread
From: kbuild test robot @ 2015-11-01 16:04 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: kbuild-all, Andrew Morton, Jens Axboe, linux-next, linux-kernel,
	Mel Gorman, Dan Williams


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

Hi Stephen,

[auto build test WARNING on block/for-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base]

url:    https://github.com/0day-ci/linux/commits/Stephen-Rothwell/linux-next-manual-merge-of-the-akpm-current-tree-with-the-block-tree/20151101-235406
config: x86_64-randconfig-x018-201544 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/linkage.h:4:0,
                    from include/linux/kernel.h:6,
                    from block/blk-core.c:14:
   block/blk-core.c: In function 'blk_queue_enter':
   block/blk-core.c:641:8: error: implicit declaration of function 'gfpflags_allow_blocking' [-Werror=implicit-function-declaration]
      if (!gfpflags_allow_blocking(gfp))
           ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
     if (__builtin_constant_p((cond)) ? !!(cond) :   \
                               ^
>> block/blk-core.c:641:3: note: in expansion of macro 'if'
      if (!gfpflags_allow_blocking(gfp))
      ^
   block/blk-core.c: In function 'generic_make_request':
   block/blk-core.c:2041:33: error: '__GFP_RECLAIM' undeclared (first use in this function)
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
                                    ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
     if (__builtin_constant_p((cond)) ? !!(cond) :   \
                               ^
   block/blk-core.c:2041:3: note: in expansion of macro 'if'
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
      ^
>> block/blk-core.c:2041:7: note: in expansion of macro 'likely'
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
          ^
   block/blk-core.c:2041:33: note: each undeclared identifier is reported only once for each function it appears in
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
                                    ^
   include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
     if (__builtin_constant_p((cond)) ? !!(cond) :   \
                               ^
   block/blk-core.c:2041:3: note: in expansion of macro 'if'
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
      ^
>> block/blk-core.c:2041:7: note: in expansion of macro 'likely'
      if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
          ^
   cc1: some warnings being treated as errors

vim +/if +641 block/blk-core.c

   625	}
   626	
   627	struct request_queue *blk_alloc_queue(gfp_t gfp_mask)
   628	{
   629		return blk_alloc_queue_node(gfp_mask, NUMA_NO_NODE);
   630	}
   631	EXPORT_SYMBOL(blk_alloc_queue);
   632	
   633	int blk_queue_enter(struct request_queue *q, gfp_t gfp)
   634	{
   635		while (true) {
   636			int ret;
   637	
   638			if (percpu_ref_tryget_live(&q->q_usage_counter))
   639				return 0;
   640	
 > 641			if (!gfpflags_allow_blocking(gfp))
   642				return -EBUSY;
   643	
   644			ret = wait_event_interruptible(q->mq_freeze_wq,
   645					!atomic_read(&q->mq_freeze_depth) ||
   646					blk_queue_dying(q));
   647			if (blk_queue_dying(q))
   648				return -ENODEV;
   649			if (ret)

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 24338 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2015-11-01 15:51 Stephen Rothwell
  2015-11-01 16:04 ` kbuild test robot
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Stephen Rothwell @ 2015-11-01 15:51 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: linux-next, linux-kernel, Mel Gorman, Dan Williams

Hi Andrew,

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

  block/blk-mq.c

between commit:

  3ef28e83ab15 ("block: generic request_queue reference counting")

from the block tree and commit:

  7cc8e61bde7a ("mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd")
  415a13cc1c3c ("mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM")

from the akpm-current tree.

I fixed it up (the code updated in the latter was moved by the former,
so I applied the following merge fix patch) and can carry the fix as
necessary (no action is required).

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 2 Nov 2015 02:49:02 +1100
Subject: [PATCH] block: fixes for __GPF_WAIT changes

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 block/blk-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 9e32f0868e36..6f2c263f478b 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -638,7 +638,7 @@ int blk_queue_enter(struct request_queue *q, gfp_t gfp)
 		if (percpu_ref_tryget_live(&q->q_usage_counter))
 			return 0;
 
-		if (!(gfp & __GFP_WAIT))
+		if (!gfpflags_allow_blocking(gfp))
 			return -EBUSY;
 
 		ret = wait_event_interruptible(q->mq_freeze_wq,
@@ -2038,7 +2038,7 @@ void generic_make_request(struct bio *bio)
 	do {
 		struct request_queue *q = bdev_get_queue(bio->bi_bdev);
 
-		if (likely(blk_queue_enter(q, __GFP_WAIT) == 0)) {
+		if (likely(blk_queue_enter(q, __GFP_RECLAIM) == 0)) {
 
 			q->make_request_fn(q, bio);
 
-- 
2.6.1

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2015-01-21  7:14 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2015-01-21  7:14 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: linux-next, linux-kernel, Christoph Hellwig, Konstantin Khebnikov


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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got conflicts in
mm/filemap.c and mm/truncate.c between commit de1414a654e6 ("fs: export
inode_to_bdi and use it in favor of mapping->backing_dev_info") from
the  tree and commit d475bc581640 ("page_writeback: cleanup mess around
cancel_dirty_page()") from the akpm-current tree.

I fixed it up (the latter removed the code modified by the former) and
can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2014-07-02  6:06 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2014-07-02  6:06 UTC (permalink / raw)
  To: Andrew Morton, Jens Axboe
  Cc: linux-next, linux-kernel, Maurizio Lombardi, Ming Lei


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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
block/bio.c between commit 254c4407cb84 ("bio: modify __bio_add_page()
to accept pages that don't start a new segment") from the block tree
and commit b5e51c564fb2 ("bio: modify __bio_add_page() to accept pages
that don't start a new segment") from the akpm-current tree.

I fixed it up (I used the version from the block tree) and can carry the
fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2013-11-05  6:29 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2013-11-05  6:29 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Tetsuo Handa, Kent Overstreet, Jens Axboe


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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
mm/bounce.c between commit 5d1f127c3e0c ("block: Convert
bio_for_each_segment() to bvec_iter") from the block tree and commit
df5494a36263 ("kthread: make kthread_create() killable") from the
akpm-current 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 mm/bounce.c
index d5873f21567d,c9f0a4339a7d..000000000000
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@@ -198,14 -201,11 +198,12 @@@ static void __blk_queue_bounce(struct r
  {
  	struct bio *bio;
  	int rw = bio_data_dir(*bio_orig);
 -	struct bio_vec *to, *from;
 +	struct bio_vec *to, from;
 +	struct bvec_iter iter;
  	unsigned i;
  
- 	if (force)
- 		goto bounce;
 -	bio_for_each_segment(from, *bio_orig, i)
 -		if (page_to_pfn(from->bv_page) > queue_bounce_pfn(q))
 +	bio_for_each_segment(from, *bio_orig, iter)
 +		if (page_to_pfn(from.bv_page) > queue_bounce_pfn(q))
  			goto bounce;
  
  	return;

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* linux-next: manual merge of the akpm-current tree with the block tree
@ 2013-11-05  6:25 Stephen Rothwell
  0 siblings, 0 replies; 28+ messages in thread
From: Stephen Rothwell @ 2013-11-05  6:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Kent Overstreet, Jens Axboe


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

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
fs/bio-integrity.c between commits ed2d2f9a8265 ("block: Abstract out
bvec iterator") and 5d1f127c3e0c ("block: Convert bio_for_each_segment()
to bvec_iter") from the block tree and commit 6952c5b3b2b7
("fs/bio-integrity.c: remove duplicated code") from the akpm-current tree.

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

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/bio-integrity.c
index 31f2d5af7b24,8a78830133ab..000000000000
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@@ -304,26 -295,37 +300,38 @@@ static int bio_integrity_generate_verif
  {
  	struct blk_integrity *bi = bdev_get_integrity(bio->bi_bdev);
  	struct blk_integrity_exchg bix;
 -	struct bio_vec *bv;
 +	struct bio_vec bv;
 +	struct bvec_iter iter;
- 	sector_t sector = bio->bi_iter.bi_sector;
- 	unsigned int sectors, total;
+ 	sector_t sector;
 -	unsigned int i, sectors, total, ret;
++	unsigned int sectors, total, ret;
  	void *prot_buf = bio->bi_integrity->bip_buf;
  
- 	total = 0;
+ 	if (operate)
 -		sector = bio->bi_sector;
++		sector = bio->bi_iter.bi_sector;
+ 	else
 -		sector = bio->bi_integrity->bip_sector;
++		sector = bio->bi_integrity->bip_iter.bi_sector;
+ 
+ 	ret = total = 0;
  	bix.disk_name = bio->bi_bdev->bd_disk->disk_name;
  	bix.sector_size = bi->sector_size;
  
 -	bio_for_each_segment(bv, bio, i) {
 -		void *kaddr = kmap_atomic(bv->bv_page);
 -		bix.data_buf = kaddr + bv->bv_offset;
 -		bix.data_size = bv->bv_len;
 +	bio_for_each_segment(bv, bio, iter) {
 +		void *kaddr = kmap_atomic(bv.bv_page);
 +		bix.data_buf = kaddr + bv.bv_offset;
 +		bix.data_size = bv.bv_len;
  		bix.prot_buf = prot_buf;
  		bix.sector = sector;
- 
- 		bi->generate_fn(&bix);
+ 		if (operate) {
+ 			bi->generate_fn(&bix);
+ 		} else {
+ 			ret = bi->verify_fn(&bix);
+ 			if (ret) {
+ 				kunmap_atomic(kaddr);
+ 				return ret;
+ 			}
+ 		}
  
 -		sectors = bv->bv_len / bi->sector_size;
 +		sectors = bv.bv_len / bi->sector_size;
  		sector += sectors;
  		prot_buf += sectors * bi->tuple_size;
  		total += sectors * bi->tuple_size;

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, back to index

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-07  9:18 linux-next: manual merge of the akpm-current tree with the block tree Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2021-06-02  5:40 Stephen Rothwell
2021-03-18  6:17 Stephen Rothwell
2021-03-18 17:54 ` Shakeel Butt
2021-03-18 18:19   ` Jens Axboe
2020-11-17  5:05 Stephen Rothwell
2020-10-15  6:27 Stephen Rothwell
2020-09-25  9:57 Stephen Rothwell
2019-05-03  9:10 Stephen Rothwell
2019-05-03 12:35 ` Amir Goldstein
2018-10-02  7:21 Stephen Rothwell
2018-08-13  7:51 Stephen Rothwell
2018-08-02  8:31 Stephen Rothwell
2018-03-19  6:36 Stephen Rothwell
2016-07-13  6:14 Stephen Rothwell
2016-07-13 16:31 ` Jens Axboe
2015-12-07  8:12 Stephen Rothwell
2015-12-07 19:44 ` Andrew Morton
2015-12-07 20:24   ` Stephen Rothwell
2015-11-01 15:51 Stephen Rothwell
2015-11-01 16:04 ` kbuild test robot
2015-11-01 16:05 ` kbuild test robot
2015-11-01 18:38 ` Mel Gorman
2015-11-01 21:51   ` Stephen Rothwell
2015-01-21  7:14 Stephen Rothwell
2014-07-02  6:06 Stephen Rothwell
2013-11-05  6:29 Stephen Rothwell
2013-11-05  6:25 Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git