linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: build warnings after merge of the akpm-current tree
@ 2020-10-06 12:05 Stephen Rothwell
  2020-10-06 20:01 ` Peter Xu
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2020-10-06 12:05 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peter Xu, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the akpm-current tree, today's linux-next build (sparc
defconfig) produced this warning:

mm/memory.c: In function 'copy_present_page':
mm/memory.c:800:20: warning: unused variable 'dst_mm' [-Wunused-variable]
  struct mm_struct *dst_mm = dst_vma->vm_mm;
                    ^~~~~~
mm/memory.c: In function 'copy_present_pte':
mm/memory.c:889:20: warning: unused variable 'dst_mm' [-Wunused-variable]
  struct mm_struct *dst_mm = dst_vma->vm_mm;
                    ^~~~~~

Maybe introduced by commit

  7e6cdccef3df ("mm-remove-src-dst-mm-parameter-in-copy_page_range-v2")

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2020-10-06 12:05 linux-next: build warnings after merge of the akpm-current tree Stephen Rothwell
@ 2020-10-06 20:01 ` Peter Xu
  2020-10-06 22:03   ` Stephen Rothwell
  0 siblings, 1 reply; 33+ messages in thread
From: Peter Xu @ 2020-10-06 20:01 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List

On Tue, Oct 06, 2020 at 11:05:16PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (sparc
> defconfig) produced this warning:
> 
> mm/memory.c: In function 'copy_present_page':
> mm/memory.c:800:20: warning: unused variable 'dst_mm' [-Wunused-variable]
>   struct mm_struct *dst_mm = dst_vma->vm_mm;
>                     ^~~~~~
> mm/memory.c: In function 'copy_present_pte':
> mm/memory.c:889:20: warning: unused variable 'dst_mm' [-Wunused-variable]
>   struct mm_struct *dst_mm = dst_vma->vm_mm;
>                     ^~~~~~
> 
> Maybe introduced by commit
> 
>   7e6cdccef3df ("mm-remove-src-dst-mm-parameter-in-copy_page_range-v2")

Yes it is.  The mm pointer is only used by set_pte_at(), while I just noticed
that some of the archs do not use the mm pointer at all, hence this warning.

The required change attached; this is quite special that we only referenced the
mm once in each of the function, so that temp variable can actually be avoided.
Ideally there should be some way to only define the variable on archs that need
this mm pointer (e.g., when set_pte_at() or some similar function is called
multiple times in some function, it should still be helpful to introduce a
local variable to keep dst_vma->vm_mm).  However I don't know a good way to do
this...

Thanks,

------------8<------------
diff --git a/mm/memory.c b/mm/memory.c
index 8ade87e8600a..d9b16136014c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -798,7 +798,6 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
                  pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
                  struct page **prealloc, pte_t pte, struct page *page)
 {
-       struct mm_struct *dst_mm = dst_vma->vm_mm;
        struct mm_struct *src_mm = src_vma->vm_mm;
        struct page *new_page;

@@ -874,7 +873,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
        /* All done, just insert the new page copy in the child */
        pte = mk_pte(new_page, dst_vma->vm_page_prot);
        pte = maybe_mkwrite(pte_mkdirty(pte), dst_vma);
-       set_pte_at(dst_mm, addr, dst_pte, pte);
+       set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
        return 0;
 }

@@ -887,7 +886,6 @@ copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
                 pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
                 struct page **prealloc)
 {
-       struct mm_struct *dst_mm = dst_vma->vm_mm;
        struct mm_struct *src_mm = src_vma->vm_mm;
        unsigned long vm_flags = src_vma->vm_flags;
        pte_t pte = *src_pte;
@@ -932,7 +930,7 @@ copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
        if (!(vm_flags & VM_UFFD_WP))
                pte = pte_clear_uffd_wp(pte);

-       set_pte_at(dst_mm, addr, dst_pte, pte);
+       set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
        return 0;
 }
------------8<------------

-- 
Peter Xu


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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2020-10-06 20:01 ` Peter Xu
@ 2020-10-06 22:03   ` Stephen Rothwell
  0 siblings, 0 replies; 33+ messages in thread
From: Stephen Rothwell @ 2020-10-06 22:03 UTC (permalink / raw)
  To: Peter Xu
  Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Tue, 6 Oct 2020 16:01:38 -0400 Peter Xu <peterx@redhat.com> wrote:
>
> On Tue, Oct 06, 2020 at 11:05:16PM +1100, Stephen Rothwell wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (sparc
> > defconfig) produced this warning:
> > 
> > mm/memory.c: In function 'copy_present_page':
> > mm/memory.c:800:20: warning: unused variable 'dst_mm' [-Wunused-variable]
> >   struct mm_struct *dst_mm = dst_vma->vm_mm;
> >                     ^~~~~~
> > mm/memory.c: In function 'copy_present_pte':
> > mm/memory.c:889:20: warning: unused variable 'dst_mm' [-Wunused-variable]
> >   struct mm_struct *dst_mm = dst_vma->vm_mm;
> >                     ^~~~~~
> > 
> > Maybe introduced by commit
> > 
> >   7e6cdccef3df ("mm-remove-src-dst-mm-parameter-in-copy_page_range-v2")  
> 
> Yes it is.  The mm pointer is only used by set_pte_at(), while I just noticed
> that some of the archs do not use the mm pointer at all, hence this warning.
> 
> The required change attached; this is quite special that we only referenced the
> mm once in each of the function, so that temp variable can actually be avoided.
> Ideally there should be some way to only define the variable on archs that need
> this mm pointer (e.g., when set_pte_at() or some similar function is called
> multiple times in some function, it should still be helpful to introduce a
> local variable to keep dst_vma->vm_mm).  However I don't know a good way to do
> this...
> 
> Thanks,
> 
> ------------8<------------
> diff --git a/mm/memory.c b/mm/memory.c
> index 8ade87e8600a..d9b16136014c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -798,7 +798,6 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
>                   pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
>                   struct page **prealloc, pte_t pte, struct page *page)
>  {
> -       struct mm_struct *dst_mm = dst_vma->vm_mm;
>         struct mm_struct *src_mm = src_vma->vm_mm;
>         struct page *new_page;
> 
> @@ -874,7 +873,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma
>         /* All done, just insert the new page copy in the child */
>         pte = mk_pte(new_page, dst_vma->vm_page_prot);
>         pte = maybe_mkwrite(pte_mkdirty(pte), dst_vma);
> -       set_pte_at(dst_mm, addr, dst_pte, pte);
> +       set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
>         return 0;
>  }
> 
> @@ -887,7 +886,6 @@ copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>                  pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss,
>                  struct page **prealloc)
>  {
> -       struct mm_struct *dst_mm = dst_vma->vm_mm;
>         struct mm_struct *src_mm = src_vma->vm_mm;
>         unsigned long vm_flags = src_vma->vm_flags;
>         pte_t pte = *src_pte;
> @@ -932,7 +930,7 @@ copy_present_pte(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
>         if (!(vm_flags & VM_UFFD_WP))
>                 pte = pte_clear_uffd_wp(pte);
> 
> -       set_pte_at(dst_mm, addr, dst_pte, pte);
> +       set_pte_at(dst_vma->vm_mm, addr, dst_pte, pte);
>         return 0;
>  }

Thanks, I have applied that to linux-next today.

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2022-03-28 23:04   ` Matthew Wilcox
@ 2022-03-29  3:32     ` Hugh Dickins
  0 siblings, 0 replies; 33+ messages in thread
From: Hugh Dickins @ 2022-03-29  3:32 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Hugh Dickins, Stephen Rothwell, Andrew Morton,
	Linux Kernel Mailing List, Linux Next Mailing List, linux-doc,
	linux-mm

On Tue, 29 Mar 2022, Matthew Wilcox wrote:
> On Wed, Feb 09, 2022 at 08:03:26AM -0800, Hugh Dickins wrote:
> > On Wed, 9 Feb 2022, Stephen Rothwell wrote:
> > > include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
> > > include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'
> > 
> > Thank you for including the patches and reporting this, Stephen.
> > Is this a warning you can live with for a week or two?
> > 
> > I've never tried generating htmldocs (I'm tempted just to replace a few
> > "/**"s by "/*"s!), and I'm fairly sure Matthew will have strong feelings
> > about how this new union (or not) will be better foliated - me messing
> > around with doc output here is unlikely to be helpful at this moment.
> 
> I have a substantial question, and then some formatting / appearance
> questions.

I think that substantial question will soon need its own thread,
rather than here in this htmldocs thread.

But while we are here, let's include a link into our previous discussion:
https://lore.kernel.org/linux-mm/3c6097a7-df8c-f39c-36e8-8b5410e76c8a@google.com/

> 
> The first is, what does mlock_count represent for a multi-page folio
> that is partially mlocked?  If you allocate an order-9 page then mmap()
> 13 pages of it and mlockall(), does mlock_count increase by 1, 13 or 512?

You won't like the answer: none of the above; the current answer is 0.

Because before your folio work implementing readahead into compound pages,
we had order-0 pages (mapped by PTEs), and (speaking x86_64 language)
order-9 pages which (typically) get mapped by PMDs.

And Kirill attended to the issue of PTE mappings of huge pages by leaving
them out of the Mlocked accounting, and leaving huge pages mapped that way
on evictable LRUs, so that they could be split under memory pressure.

And I've carried that forward in the mm/munlock series - though I claim
to have simpified and improved it, by leaving PageDoubleMap out of it,
keeping PMD mappings as Mlocked even if there are also PTE mappings.

I think none of us have attended to PageCompound folio mappings changing
the balance of probabilities: they are being left out of the mlocked
accounting just like PTE mappings of THPs are.

If you'd like a number bigger than 0 there, I guess I can add a patch
to, what, not skip PTE mappings of compound pages if !PageSwapBacked?
Although it would be much nicer not to distinguish by PageSwapBacked,
I suspect testing and page reclaim issues require us to make the
distinction, for now at least.

Then the answer to your question would be mlock_count 13
(but Mlocked 2048 kB).

As I said in the linked mail: it doesn't matter at all how you count them
in mlock_count, just so long as they are counted up and down consistently.
Since it's simplest just to count 1 in mlock_count for each PMD or PTE,
I prefer that (as I did with THPs); but if you prefer to count PMDs up
and down by HUGE_PMD_NR, that works too.

mlock_count is just an internal implementation detail.

Mlocked and Unevictable amounts are visible to the user (and to various
tests no doubt) but still just numbers shown; more important is whether
a sparsely mlocked compound page can be split under memory pressure and
its unmlocked portions reclaimed.

I don't know where the folio work stands with splitting (but I think you
have a patch which removes the !PageSwapBacked splitting of huge pages
from vmscan.c - I've a separate mail to send you on that); but it looks
like a lot of huge_memory.c is still HPAGE_PMD_NR-based (I'd say rightly,
because PMD issues are traditional THP's main concern).

If we do move sparsely mlocked folios to the "Unevictable LRU", I'm
not sure how long we can get away with them being invisible to page
reclaim: it will probably need someone (I'm not volunteering) to write
a shrinker for them, along the lines of anon THP's deferred split list,
or shmem THP's unused-beyond-EOF split list.

> 
> Then we have a tradeoff between prettiness of the source code and
> prettiness of the htmldocs.  At one maximum, we can make it look like
> this in the htmldocs:
> 
> struct folio {
>   unsigned long flags;
>   struct list_head lru;
>   unsigned int mlock_count;
>   struct address_space *mapping;
>   pgoff_t index;
>   void *private;
>   atomic_t _mapcount;
>   atomic_t _refcount;
> #ifdef CONFIG_MEMCG;
>   unsigned long memcg_data;
> #endif;
> };
> 
> but at the cost of making the source code look like this:
> 
> struct folio {
>         /* private: don't document the anon union */
>         union {
>                 struct {
>         /* public: */
>                         unsigned long flags;
>         /* private: */
>                         union {
>         /* public: */
>                                 struct list_head lru;
>         /* private: */
>                                 struct {
>                                         void *__filler;
>         /* public: */
>                                         unsigned int mlock_count;
>         /* private: */
>                                 };
>                         };
>         /* public: */
>                         struct address_space *mapping;
> 
> At the other extreme, the htmldocs can look more complicated:
> 
> struct folio {
>   unsigned long flags;
>   union {
>     struct list_head lru;
>     struct {
>       unsigned int mlock_count;
>     };
>   };
>   struct address_space *mapping;
>   pgoff_t index;
>   void *private;
>   atomic_t _mapcount;
>   atomic_t _refcount;
> #ifdef CONFIG_MEMCG;
>   unsigned long memcg_data;
> #endif;
> };
> 
> with the source code changes being merely:
> 
> @@ -227,6 +227,7 @@ struct page {
>   * struct folio - Represents a contiguous set of bytes.
>   * @flags: Identical to the page flags.
>   * @lru: Least Recently Used list; tracks how recently this folio was used.
> + * @mlock_count: Number of times any page in this folio is mlocked.
>   * @mapping: The file this page belongs to, or refers to the anon_vma for
>   *    anonymous memory.
>   * @index: Offset within the file, in units of pages.  For anonymous memory,
> @@ -256,7 +257,9 @@ struct folio {
>                         union {
>                                 struct list_head lru;
>                                 struct {
> +       /* private: */
>                                         void *__filler;
> +       /* public: */
>                                         unsigned int mlock_count;
>                                 };
>                         };
> 
> Various steps in between are possible, such as removing the anonymous
> struct from the documentation, but leaving the union.  We could also
> choose to document __filler, but that seems like a poor choice to me.
> 
> Anyway, that's all arguable and not really too important.  My mild
> preference is for the private/public markers around __filler alone,
> but I'll happily abide by the preferences of others.

Same here: mild preference for this, but defer to others.

> 
> The important part is what mlock_count really means.  We can be
> reasonably verbose here (two or three lines of text, I'd suggest).

mlock_count aims to be the number of page table entries in VM_LOCKED
VMAs for this folio, but may undercount.

That's of course an over-simplification, skirting issues mentioned
above, and that it can only be relied on when PageLRU PageUnevictable;
but let's not get into those here.

But I wrote that "mlock_count aims" sentence above without seeing your
 * @mlock_count: Number of times any page in this folio is mlocked.

Yes, I think I prefer the brevity of what you wrote to mine.

Thanks,
Hugh

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2022-02-09 16:03 ` Hugh Dickins
@ 2022-03-28 23:04   ` Matthew Wilcox
  2022-03-29  3:32     ` Hugh Dickins
  0 siblings, 1 reply; 33+ messages in thread
From: Matthew Wilcox @ 2022-03-28 23:04 UTC (permalink / raw)
  To: Hugh Dickins
  Cc: Stephen Rothwell, Andrew Morton, Linux Kernel Mailing List,
	Linux Next Mailing List

On Wed, Feb 09, 2022 at 08:03:26AM -0800, Hugh Dickins wrote:
> On Wed, 9 Feb 2022, Stephen Rothwell wrote:
> > include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
> > include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'
> 
> Thank you for including the patches and reporting this, Stephen.
> Is this a warning you can live with for a week or two?
> 
> I've never tried generating htmldocs (I'm tempted just to replace a few
> "/**"s by "/*"s!), and I'm fairly sure Matthew will have strong feelings
> about how this new union (or not) will be better foliated - me messing
> around with doc output here is unlikely to be helpful at this moment.

I have a substantial question, and then some formatting / appearance
questions.

The first is, what does mlock_count represent for a multi-page folio
that is partially mlocked?  If you allocate an order-9 page then mmap()
13 pages of it and mlockall(), does mlock_count increase by 1, 13 or 512?

Then we have a tradeoff between prettiness of the source code and
prettiness of the htmldocs.  At one maximum, we can make it look like
this in the htmldocs:

struct folio {
  unsigned long flags;
  struct list_head lru;
  unsigned int mlock_count;
  struct address_space *mapping;
  pgoff_t index;
  void *private;
  atomic_t _mapcount;
  atomic_t _refcount;
#ifdef CONFIG_MEMCG;
  unsigned long memcg_data;
#endif;
};

but at the cost of making the source code look like this:

struct folio {
        /* private: don't document the anon union */
        union {
                struct {
        /* public: */
                        unsigned long flags;
        /* private: */
                        union {
        /* public: */
                                struct list_head lru;
        /* private: */
                                struct {
                                        void *__filler;
        /* public: */
                                        unsigned int mlock_count;
        /* private: */
                                };
                        };
        /* public: */
                        struct address_space *mapping;

At the other extreme, the htmldocs can look more complicated:

struct folio {
  unsigned long flags;
  union {
    struct list_head lru;
    struct {
      unsigned int mlock_count;
    };
  };
  struct address_space *mapping;
  pgoff_t index;
  void *private;
  atomic_t _mapcount;
  atomic_t _refcount;
#ifdef CONFIG_MEMCG;
  unsigned long memcg_data;
#endif;
};

with the source code changes being merely:

@@ -227,6 +227,7 @@ struct page {
  * struct folio - Represents a contiguous set of bytes.
  * @flags: Identical to the page flags.
  * @lru: Least Recently Used list; tracks how recently this folio was used.
+ * @mlock_count: Number of times any page in this folio is mlocked.
  * @mapping: The file this page belongs to, or refers to the anon_vma for
  *    anonymous memory.
  * @index: Offset within the file, in units of pages.  For anonymous memory,
@@ -256,7 +257,9 @@ struct folio {
                        union {
                                struct list_head lru;
                                struct {
+       /* private: */
                                        void *__filler;
+       /* public: */
                                        unsigned int mlock_count;
                                };
                        };

Various steps in between are possible, such as removing the anonymous
struct from the documentation, but leaving the union.  We could also
choose to document __filler, but that seems like a poor choice to me.

Anyway, that's all arguable and not really too important.  My mild
preference is for the private/public markers around __filler alone,
but I'll happily abide by the preferences of others.

The important part is what mlock_count really means.  We can be
reasonably verbose here (two or three lines of text, I'd suggest).

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2022-03-28 19:54   ` Hugh Dickins
@ 2022-03-28 22:10     ` Matthew Wilcox
  0 siblings, 0 replies; 33+ messages in thread
From: Matthew Wilcox @ 2022-03-28 22:10 UTC (permalink / raw)
  To: Hugh Dickins
  Cc: Stephen Rothwell, Andrew Morton, Vlastimil Babka, linux-kernel,
	linux-next, linux-mm

On Mon, Mar 28, 2022 at 12:54:14PM -0700, Hugh Dickins wrote:
> On Thu, 24 Mar 2022, Stephen Rothwell wrote:
> 
> > Hi all,
> > 
> > On Wed, 9 Feb 2022 17:02:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 
> > > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > > produced these warnings:
> > > 
> > > include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
> > > include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'
> > > 
> > > Introduced by commit
> > > 
> > >   60a5c5ab0ba7 ("mm/munlock: maintain page->mlock_count while unevictable")
> > 
> > I am still getting these warnings.  That commit is now
> > 
> >   07ca76067308 ("mm/munlock: maintain page->mlock_count while unevictable")
> > 
> > in Linus' tree :-(
> 
> Sorry about that Stephen: back in Feb I expected Matthew to have strong
> feelings about it, and it wouldn't have been helpful for me to mess it
> around at that time.
> 
> But I'll reply to this now with my suggested patch: which Matthew may
> not like (he may consider it a retrograde step), but unless he NAKs it
> and comes up with something we all like better, it should do for now.

Sorry!  I didn't see these emails back in February, or I would have
fixed it up.  I'm doing a build now, but it's a very slow process
(and seems to have become single-threaded since the last time I ran it?)
so it will be a little while before I can produce a patch.

> I did try to 'make htmldocs' for the first time, but was put off by all
> the new packages I was asked to install - not a good use of time.  And
> I'm so ignorant that I do not even know if "/* public: */" is a helpful
> comment or a special annotation.

Fortunately the documentation is actually documented:
Documentation/doc-guide/kernel-doc.rst
''Structure, union, and enumeration documentation''

There are still many, many warnings when building the documentation, so
don't feel particularly bad about this.  I've tried to make it more
obvious to non-doc-specialists by making W=1 emit warnings, but that
only happens for .c files, not for .h files.  As you say, the amount
of tooling that needs to be installed to make htmldocs is intimidating.

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2022-03-24  7:27 ` Stephen Rothwell
@ 2022-03-28 19:54   ` Hugh Dickins
  2022-03-28 22:10     ` Matthew Wilcox
  0 siblings, 1 reply; 33+ messages in thread
From: Hugh Dickins @ 2022-03-28 19:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Hugh Dickins, Andrew Morton, Matthew Wilcox, Vlastimil Babka,
	linux-kernel, linux-next, linux-mm

On Thu, 24 Mar 2022, Stephen Rothwell wrote:

> Hi all,
> 
> On Wed, 9 Feb 2022 17:02:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > 
> > After merging the akpm-current tree, today's linux-next build (htmldocs)
> > produced these warnings:
> > 
> > include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
> > include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'
> > 
> > Introduced by commit
> > 
> >   60a5c5ab0ba7 ("mm/munlock: maintain page->mlock_count while unevictable")
> 
> I am still getting these warnings.  That commit is now
> 
>   07ca76067308 ("mm/munlock: maintain page->mlock_count while unevictable")
> 
> in Linus' tree :-(

Sorry about that Stephen: back in Feb I expected Matthew to have strong
feelings about it, and it wouldn't have been helpful for me to mess it
around at that time.

But I'll reply to this now with my suggested patch: which Matthew may
not like (he may consider it a retrograde step), but unless he NAKs it
and comes up with something we all like better, it should do for now.

I did try to 'make htmldocs' for the first time, but was put off by all
the new packages I was asked to install - not a good use of time.  And
I'm so ignorant that I do not even know if "/* public: */" is a helpful
comment or a special annotation.

Patch follows...
Hugh

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2022-02-09  6:02 Stephen Rothwell
  2022-02-09 16:03 ` Hugh Dickins
@ 2022-03-24  7:27 ` Stephen Rothwell
  2022-03-28 19:54   ` Hugh Dickins
  1 sibling, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2022-03-24  7:27 UTC (permalink / raw)
  To: Hugh Dickins
  Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

On Wed, 9 Feb 2022 17:02:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced these warnings:
> 
> include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
> include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'
> 
> Introduced by commit
> 
>   60a5c5ab0ba7 ("mm/munlock: maintain page->mlock_count while unevictable")

I am still getting these warnings.  That commit is now

  07ca76067308 ("mm/munlock: maintain page->mlock_count while unevictable")

in Linus' tree :-(

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2022-02-09  6:02 Stephen Rothwell
@ 2022-02-09 16:03 ` Hugh Dickins
  2022-03-28 23:04   ` Matthew Wilcox
  2022-03-24  7:27 ` Stephen Rothwell
  1 sibling, 1 reply; 33+ messages in thread
From: Hugh Dickins @ 2022-02-09 16:03 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Hugh Dickins, Matthew Wilcox,
	Linux Kernel Mailing List, Linux Next Mailing List

On Wed, 9 Feb 2022, Stephen Rothwell wrote:

> Hi all,
> 
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced these warnings:
> 
> include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
> include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'
> 
> Introduced by commit
> 
>   60a5c5ab0ba7 ("mm/munlock: maintain page->mlock_count while unevictable")

Thank you for including the patches and reporting this, Stephen.
Is this a warning you can live with for a week or two?

I've never tried generating htmldocs (I'm tempted just to replace a few
"/**"s by "/*"s!), and I'm fairly sure Matthew will have strong feelings
about how this new union (or not) will be better foliated - me messing
around with doc output here is unlikely to be helpful at this moment.

Hugh

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2022-02-09  6:02 Stephen Rothwell
  2022-02-09 16:03 ` Hugh Dickins
  2022-03-24  7:27 ` Stephen Rothwell
  0 siblings, 2 replies; 33+ messages in thread
From: Stephen Rothwell @ 2022-02-09  6:02 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Hugh Dickins, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced these warnings:

include/linux/mm_types.h:272: warning: Function parameter or member '__filler' not described in 'folio'
include/linux/mm_types.h:272: warning: Function parameter or member 'mlock_count' not described in 'folio'

Introduced by commit

  60a5c5ab0ba7 ("mm/munlock: maintain page->mlock_count while unevictable")

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2021-10-11  7:31 Stephen Rothwell
@ 2021-10-11 17:46 ` Kees Cook
  0 siblings, 0 replies; 33+ messages in thread
From: Kees Cook @ 2021-10-11 17:46 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Daniel Micay, Matthew Wilcox, Joe Perches,
	Linux Kernel Mailing List, Linux Next Mailing List

On Mon, Oct 11, 2021 at 06:31:45PM +1100, Stephen Rothwell wrote:
> After merging the akpm-current tree, today's linux-next build (htmldocs)
> produced these warnings:
> 
> include/linux/slab.h:577: warning: Function parameter or member '1' not described in '__alloc_size'
> include/linux/slab.h:577: warning: expecting prototype for kmalloc(). Prototype was for __alloc_size() instead

Yay kerndoc. Thanks for catching this, and I realize Matthew Wilcox
predicted this earlier:
https://lore.kernel.org/lkml/3a0c55a3fabc57ce9771c93499ef19327f3b8621.camel@perches.com/

I will get a fix sent.

-Kees

> include/linux/slab.h:623: warning: Function parameter or member '1' not described in '__alloc_size'
> include/linux/slab.h:623: warning: Function parameter or member '2' not described in '__alloc_size'
> include/linux/slab.h:623: warning: expecting prototype for kmalloc_array(). Prototype was for __alloc_size() instead
> include/linux/slab.h:644: warning: Function parameter or member '2' not described in '__alloc_size'
> include/linux/slab.h:644: warning: Function parameter or member '3' not described in '__alloc_size'
> include/linux/slab.h:644: warning: expecting prototype for krealloc_array(). Prototype was for __alloc_size() instead
> include/linux/slab.h:660: warning: Function parameter or member '1' not described in '__alloc_size'
> include/linux/slab.h:660: warning: Function parameter or member '2' not described in '__alloc_size'
> include/linux/slab.h:660: warning: expecting prototype for kcalloc(). Prototype was for __alloc_size() instead
> include/linux/slab.h:723: warning: Function parameter or member '1' not described in '__alloc_size'
> include/linux/slab.h:723: warning: expecting prototype for kzalloc(). Prototype was for __alloc_size() instead
> include/linux/slab.h:734: warning: Function parameter or member '1' not described in '__alloc_size'
> include/linux/slab.h:734: warning: expecting prototype for kzalloc_node(). Prototype was for __alloc_size() instead
> include/linux/slab.h:1: warning: no structured comments found
> 
> Introduced by commit
> 
>   04ba82afbbf3 ("slab: add __alloc_size attributes for better bounds checking")
> 
> -- 
> Cheers,
> Stephen Rothwell



-- 
Kees Cook

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2021-10-11  7:31 Stephen Rothwell
  2021-10-11 17:46 ` Kees Cook
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2021-10-11  7:31 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Daniel Micay, Kees Cook, Linux Kernel Mailing List,
	Linux Next Mailing List

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

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced these warnings:

include/linux/slab.h:577: warning: Function parameter or member '1' not described in '__alloc_size'
include/linux/slab.h:577: warning: expecting prototype for kmalloc(). Prototype was for __alloc_size() instead
include/linux/slab.h:623: warning: Function parameter or member '1' not described in '__alloc_size'
include/linux/slab.h:623: warning: Function parameter or member '2' not described in '__alloc_size'
include/linux/slab.h:623: warning: expecting prototype for kmalloc_array(). Prototype was for __alloc_size() instead
include/linux/slab.h:644: warning: Function parameter or member '2' not described in '__alloc_size'
include/linux/slab.h:644: warning: Function parameter or member '3' not described in '__alloc_size'
include/linux/slab.h:644: warning: expecting prototype for krealloc_array(). Prototype was for __alloc_size() instead
include/linux/slab.h:660: warning: Function parameter or member '1' not described in '__alloc_size'
include/linux/slab.h:660: warning: Function parameter or member '2' not described in '__alloc_size'
include/linux/slab.h:660: warning: expecting prototype for kcalloc(). Prototype was for __alloc_size() instead
include/linux/slab.h:723: warning: Function parameter or member '1' not described in '__alloc_size'
include/linux/slab.h:723: warning: expecting prototype for kzalloc(). Prototype was for __alloc_size() instead
include/linux/slab.h:734: warning: Function parameter or member '1' not described in '__alloc_size'
include/linux/slab.h:734: warning: expecting prototype for kzalloc_node(). Prototype was for __alloc_size() instead
include/linux/slab.h:1: warning: no structured comments found

Introduced by commit

  04ba82afbbf3 ("slab: add __alloc_size attributes for better bounds checking")

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2021-06-15 10:50 Stephen Rothwell
  0 siblings, 0 replies; 33+ messages in thread
From: Stephen Rothwell @ 2021-06-15 10:50 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Andy Shevchenko, Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

After merging the akpm-current tree, today's linux-next build (htmldocs)
produced these warnings:

include/linux/kernel.h:1: warning: 'kstrtol' not found
include/linux/kernel.h:1: warning: 'kstrtoul' not found

Introduced by commit

  af137d888395 ("kernel.h: split out kstrtox() and simple_strtox() to a separate header")

They are referenced in Documentation/core-api/kernel-api.rst.

-- 
Cheers,
Stephen Rothwell

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

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2020-01-06  6:14 Stephen Rothwell
  0 siblings, 0 replies; 33+ messages in thread
From: Stephen Rothwell @ 2020-01-06  6:14 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Akinobu Mita

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

Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

In file included from include/linux/device.h:15,
                 from include/linux/pci.h:37,
                 from drivers/net/wireless/intel/iwlegacy/4965.c:14:
drivers/net/wireless/intel/iwlegacy/4965.c: In function 'il4965_hw_get_temperature':
drivers/net/wireless/intel/iwlegacy/common.h:2928:32: warning: format '%d' expects argument of type 'int', but argument 6 has type 'long int' [-Wformat=]
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |                                ^~~~~~~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
   19 | #define dev_fmt(fmt) fmt
      |                      ^~~
drivers/net/wireless/intel/iwlegacy/common.h:2928:3: note: in expansion of macro 'dev_err'
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |   ^~~~~~~
drivers/net/wireless/intel/iwlegacy/common.h:3027:26: note: in expansion of macro 'IL_DBG'
 3027 | #define D_TEMP(f, a...)  IL_DBG(IL_DL_TEMP, f, ## a)
      |                          ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1614:2: note: in expansion of macro 'D_TEMP'
 1614 |  D_TEMP("Calibrated temperature: %dK, %dC\n", temperature,
      |  ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1614:40: note: format string is defined here
 1614 |  D_TEMP("Calibrated temperature: %dK, %dC\n", temperature,
      |                                       ~^
      |                                        |
      |                                        int
      |                                       %ld
In file included from include/linux/device.h:15,
                 from include/linux/pci.h:37,
                 from drivers/net/wireless/intel/iwlegacy/4965.c:14:
drivers/net/wireless/intel/iwlegacy/4965.c: In function 'il4965_temperature_calib':
drivers/net/wireless/intel/iwlegacy/common.h:2928:32: warning: format '%d' expects argument of type 'int', but argument 5 has type 'long int' [-Wformat=]
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |                                ^~~~~~~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
   19 | #define dev_fmt(fmt) fmt
      |                      ^~~
drivers/net/wireless/intel/iwlegacy/common.h:2928:3: note: in expansion of macro 'dev_err'
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |   ^~~~~~~
drivers/net/wireless/intel/iwlegacy/common.h:3027:26: note: in expansion of macro 'IL_DBG'
 3027 | #define D_TEMP(f, a...)  IL_DBG(IL_DL_TEMP, f, ## a)
      |                          ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1674:4: note: in expansion of macro 'D_TEMP'
 1674 |    D_TEMP("Temperature changed " "from %dC to %dC\n",
      |    ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1674:41: note: format string is defined here
 1674 |    D_TEMP("Temperature changed " "from %dC to %dC\n",
      |                                        ~^
      |                                         |
      |                                         int
      |                                        %ld
In file included from include/linux/device.h:15,
                 from include/linux/pci.h:37,
                 from drivers/net/wireless/intel/iwlegacy/4965.c:14:
drivers/net/wireless/intel/iwlegacy/common.h:2928:32: warning: format '%d' expects argument of type 'int', but argument 6 has type 'long int' [-Wformat=]
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |                                ^~~~~~~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
   19 | #define dev_fmt(fmt) fmt
      |                      ^~~
drivers/net/wireless/intel/iwlegacy/common.h:2928:3: note: in expansion of macro 'dev_err'
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |   ^~~~~~~
drivers/net/wireless/intel/iwlegacy/common.h:3027:26: note: in expansion of macro 'IL_DBG'
 3027 | #define D_TEMP(f, a...)  IL_DBG(IL_DL_TEMP, f, ## a)
      |                          ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1674:4: note: in expansion of macro 'D_TEMP'
 1674 |    D_TEMP("Temperature changed " "from %dC to %dC\n",
      |    ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1674:48: note: format string is defined here
 1674 |    D_TEMP("Temperature changed " "from %dC to %dC\n",
      |                                               ~^
      |                                                |
      |                                                int
      |                                               %ld
In file included from include/linux/device.h:15,
                 from include/linux/pci.h:37,
                 from drivers/net/wireless/intel/iwlegacy/4965.c:14:
drivers/net/wireless/intel/iwlegacy/common.h:2928:32: warning: format '%d' expects argument of type 'int', but argument 5 has type 'long int' [-Wformat=]
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |                                ^~~~~~~~
include/linux/dev_printk.h:19:22: note: in definition of macro 'dev_fmt'
   19 | #define dev_fmt(fmt) fmt
      |                      ^~~
drivers/net/wireless/intel/iwlegacy/common.h:2928:3: note: in expansion of macro 'dev_err'
 2928 |   dev_err(&il->hw->wiphy->dev, "%c %s " fmt,  \
      |   ^~~~~~~
drivers/net/wireless/intel/iwlegacy/common.h:3027:26: note: in expansion of macro 'IL_DBG'
 3027 | #define D_TEMP(f, a...)  IL_DBG(IL_DL_TEMP, f, ## a)
      |                          ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1678:4: note: in expansion of macro 'D_TEMP'
 1678 |    D_TEMP("Temperature " "initialized to %dC\n",
      |    ^~~~~~
drivers/net/wireless/intel/iwlegacy/4965.c:1678:43: note: format string is defined here
 1678 |    D_TEMP("Temperature " "initialized to %dC\n",
      |                                          ~^
      |                                           |
      |                                           int
      |                                          %ld

Presumably introduced by commit

  7a24660b5c25 ("iwlegacy: use <linux/units.h> helpers")

-- 
Cheers,
Stephen Rothwell

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2017-08-25 21:23   ` Andrew Morton
@ 2017-08-26  1:23     ` Changwei Ge
  0 siblings, 0 replies; 33+ messages in thread
From: Changwei Ge @ 2017-08-26  1:23 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Mark Fasheh

Hi Andrew,


On 2017/8/26 5:24, Andrew Morton wrote:
> On Thu, 24 Aug 2017 08:15:30 +0000 Changwei Ge <ge.changwei@h3c.com> wrote:
>
>> Hi Andrew,
>>
>> On 2017/8/24 15:42, Stephen Rothwell wrote:
>>> Hi Andrew, After merging the akpm-current tree, today's linux-next
>>> build (x86_64 allmodconfig) produced these warnings:
>>> fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_free_dead_locks':
>>> fs/ocfs2/dlm/dlmrecovery.c:2306:6: warning: unused variable 'i'
>>> [-Wunused-variable] int i; ^ fs/ocfs2/dlm/dlmrecovery.c:2305:20:
>>> warning: unused variable 'queue' [-Wunused-variable] struct list_head
>>> *queue = NULL; ^ 
>> My patch never defines these two variables, it's strange that they are
>> defined within the patch you collected.
>> Could you please help to check if this patch comes from mail '[PATCH]
>> ocfs2: re-queue AST or BAST if sending is failed to improve the
>> reliability' sent on 7, August.
> Yes, I'm not at all sure how those lines got there.
>
> Problem is, the patch you sent was wordwrapped and had its tabs
> replaced with spaces.  So I had to do quite a lot of work on it to make
> it usable.  Evidently I somehow added those lines in the process.
>
> Please carefully check that
>
> http://www.ozlabs.org/~akpm/mmotm/broken-out/ocfs2-re-queue-ast-or-bast-if-sending-is-failed-to-improve-the-reliability.patch
>
> plus
>
> --- a/fs/ocfs2/dlm/dlmrecovery.c~ocfs2-re-queue-ast-or-bast-if-sending-is-failed-to-improve-the-reliability-fix
> +++ a/fs/ocfs2/dlm/dlmrecovery.c
> @@ -2302,8 +2302,6 @@ static void dlm_free_dead_locks(struct d
>  	struct dlm_lock *lock, *next;
>  	unsigned int freed = 0;
>  	int reserved_tmp = 0;
> -	struct list_head *queue = NULL;
> -	int i;
>  
>  	/* this node is the lockres master:
>  	 * 1) remove any stale locks for the dead node
>
> produce the correct result.
>
> And please appropriately configure your email client for next time!
Sorry for the trouble my patch made, I will check my email client
configuration.

Thanks,
Changwei
>

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2017-08-24  8:15 ` Changwei Ge
@ 2017-08-25 21:23   ` Andrew Morton
  2017-08-26  1:23     ` Changwei Ge
  0 siblings, 1 reply; 33+ messages in thread
From: Andrew Morton @ 2017-08-25 21:23 UTC (permalink / raw)
  To: Changwei Ge
  Cc: Stephen Rothwell, Linux-Next Mailing List,
	Linux Kernel Mailing List, Mark Fasheh

On Thu, 24 Aug 2017 08:15:30 +0000 Changwei Ge <ge.changwei@h3c.com> wrote:

> Hi Andrew,
> 
> On 2017/8/24 15:42, Stephen Rothwell wrote:
> > Hi Andrew, After merging the akpm-current tree, today's linux-next
> > build (x86_64 allmodconfig) produced these warnings:
> > fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_free_dead_locks':
> > fs/ocfs2/dlm/dlmrecovery.c:2306:6: warning: unused variable 'i'
> > [-Wunused-variable] int i; ^ fs/ocfs2/dlm/dlmrecovery.c:2305:20:
> > warning: unused variable 'queue' [-Wunused-variable] struct list_head
> > *queue = NULL; ^ 
> My patch never defines these two variables, it's strange that they are
> defined within the patch you collected.
> Could you please help to check if this patch comes from mail '[PATCH]
> ocfs2: re-queue AST or BAST if sending is failed to improve the
> reliability' sent on 7, August.

Yes, I'm not at all sure how those lines got there.

Problem is, the patch you sent was wordwrapped and had its tabs
replaced with spaces.  So I had to do quite a lot of work on it to make
it usable.  Evidently I somehow added those lines in the process.

Please carefully check that

http://www.ozlabs.org/~akpm/mmotm/broken-out/ocfs2-re-queue-ast-or-bast-if-sending-is-failed-to-improve-the-reliability.patch

plus

--- a/fs/ocfs2/dlm/dlmrecovery.c~ocfs2-re-queue-ast-or-bast-if-sending-is-failed-to-improve-the-reliability-fix
+++ a/fs/ocfs2/dlm/dlmrecovery.c
@@ -2302,8 +2302,6 @@ static void dlm_free_dead_locks(struct d
 	struct dlm_lock *lock, *next;
 	unsigned int freed = 0;
 	int reserved_tmp = 0;
-	struct list_head *queue = NULL;
-	int i;
 
 	/* this node is the lockres master:
 	 * 1) remove any stale locks for the dead node

produce the correct result.

And please appropriately configure your email client for next time!

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2017-08-24  7:41 Stephen Rothwell
@ 2017-08-24  8:15 ` Changwei Ge
  2017-08-25 21:23   ` Andrew Morton
  0 siblings, 1 reply; 33+ messages in thread
From: Changwei Ge @ 2017-08-24  8:15 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Mark Fasheh

Hi Andrew,

On 2017/8/24 15:42, Stephen Rothwell wrote:
> Hi Andrew, After merging the akpm-current tree, today's linux-next
> build (x86_64 allmodconfig) produced these warnings:
> fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_free_dead_locks':
> fs/ocfs2/dlm/dlmrecovery.c:2306:6: warning: unused variable 'i'
> [-Wunused-variable] int i; ^ fs/ocfs2/dlm/dlmrecovery.c:2305:20:
> warning: unused variable 'queue' [-Wunused-variable] struct list_head
> *queue = NULL; ^ 
My patch never defines these two variables, it's strange that they are
defined within the patch you collected.
Could you please help to check if this patch comes from mail '[PATCH]
ocfs2: re-queue AST or BAST if sending is failed to improve the
reliability' sent on 7, August.

Thanks,
Changwei
> Caused by commit
>
>   d09f2c6cf3b8 ("ocfs2: re-queue AST or BAST if sending is failed to improve the reliability")
>

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2017-08-24  7:41 Stephen Rothwell
  2017-08-24  8:15 ` Changwei Ge
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2017-08-24  7:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Changwei Ge,
	Mark Fasheh

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

fs/ocfs2/dlm/dlmrecovery.c: In function 'dlm_free_dead_locks':
fs/ocfs2/dlm/dlmrecovery.c:2306:6: warning: unused variable 'i' [-Wunused-variable]
  int i;
      ^
fs/ocfs2/dlm/dlmrecovery.c:2305:20: warning: unused variable 'queue' [-Wunused-variable]
  struct list_head *queue = NULL;
                    ^

Caused by commit

  d09f2c6cf3b8 ("ocfs2: re-queue AST or BAST if sending is failed to improve the reliability")

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2017-03-20 12:30   ` Jan Glauber
@ 2017-03-20 17:06     ` Challa, Mahipal
  0 siblings, 0 replies; 33+ messages in thread
From: Challa, Mahipal @ 2017-03-20 17:06 UTC (permalink / raw)
  To: Jan Glauber, Dmitry Vyukov
  Cc: Stephen Rothwell, Andrew Morton, Herbert Xu, linux-next, LKML



From: Jan Glauber
Sent: Monday, March 20, 2017 6:00 PM
To: Dmitry Vyukov
Cc: Stephen Rothwell; Andrew Morton; Herbert Xu; linux-next@vger.kernel.org; LKML; Challa, Mahipal
Subject: Re: linux-next: build warnings after merge of the akpm-current tree
    
On Mon, Mar 20, 2017 at 10:05:54AM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 20, 2017 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> >
> > drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats':
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat=]
> >     seq_printf(s, "        ZIP Device %d Stats\n"
> >                   ^
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 11 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 12 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 13 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 14 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 15 has type 'long long int' [-Wformat=]
> >
> > Introduced by commit
> >
> >   09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
> >
> > from the crypto tree interacting with commit
> >
> >   3f4ca3d25e1a ("asm-generic, x86: wrap atomic operations")
> >
> > from the akpm-current tree.
> >
> > This latter commit changed atomic64read() from "long" to "long long"
> > on x86_64.
> 
> Hi,
> 
> Previously atomic operations returned different types on 32/64 bits. I
> think that was pretty unfortunate and could actually lead to lots of
> such warnings (as there were no single format specifier that one could
> use portably), and was difficult to wrap. So I used "unsigned long
> long" for all operations.
> I actually suspect that the new zip_main.c code would cause a similar
> warning on 32 bits even without my change, because atomic ops already
> returned unsigned long long there.

>The driver depends on 64BIT (HW is 64 bit only).

>> So I think we need to fix zip_main.c.

>I'm not entirely sure, all drivers that are available for x86_64 and
>arm64 and use atomic64_read will show such warnings.

>One possible solution would be to disable COMPILE_TEST for the zip
>driver, but that would just hide the issue.

We found a decent solution to this issue and sent the patch to Herbert.
Solution:
Changing the format specifiers to %llu and adding a cast to u64 solves the
problem on all the architectures.

Thanks,
Mahipal


     

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2017-03-20  9:05 ` Dmitry Vyukov
@ 2017-03-20 12:30   ` Jan Glauber
  2017-03-20 17:06     ` Challa, Mahipal
  0 siblings, 1 reply; 33+ messages in thread
From: Jan Glauber @ 2017-03-20 12:30 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: Stephen Rothwell, Andrew Morton, Herbert Xu, linux-next, LKML,
	Mahipal Challa

On Mon, Mar 20, 2017 at 10:05:54AM +0100, Dmitry Vyukov wrote:
> On Mon, Mar 20, 2017 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> >
> > drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats':
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat=]
> >     seq_printf(s, "        ZIP Device %d Stats\n"
> >                   ^
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 11 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 12 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 13 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 14 has type 'long long int' [-Wformat=]
> > drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 15 has type 'long long int' [-Wformat=]
> >
> > Introduced by commit
> >
> >   09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
> >
> > from the crypto tree interacting with commit
> >
> >   3f4ca3d25e1a ("asm-generic, x86: wrap atomic operations")
> >
> > from the akpm-current tree.
> >
> > This latter commit changed atomic64read() from "long" to "long long"
> > on x86_64.
> 
> Hi,
> 
> Previously atomic operations returned different types on 32/64 bits. I
> think that was pretty unfortunate and could actually lead to lots of
> such warnings (as there were no single format specifier that one could
> use portably), and was difficult to wrap. So I used "unsigned long
> long" for all operations.
> I actually suspect that the new zip_main.c code would cause a similar
> warning on 32 bits even without my change, because atomic ops already
> returned unsigned long long there.

The driver depends on 64BIT (HW is 64 bit only).

> So I think we need to fix zip_main.c.

I'm not entirely sure, all drivers that are available for x86_64 and
arm64 and use atomic64_read will show such warnings.

One possible solution would be to disable COMPILE_TEST for the zip
driver, but that would just hide the issue.

--Jan

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2017-03-20  5:22 Stephen Rothwell
@ 2017-03-20  9:05 ` Dmitry Vyukov
  2017-03-20 12:30   ` Jan Glauber
  0 siblings, 1 reply; 33+ messages in thread
From: Dmitry Vyukov @ 2017-03-20  9:05 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Andrew Morton, Herbert Xu, linux-next, LKML, Mahipal Challa, Jan Glauber

On Mon, Mar 20, 2017 at 6:22 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats':
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat=]
>     seq_printf(s, "        ZIP Device %d Stats\n"
>                   ^
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 11 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 12 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 13 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 14 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 15 has type 'long long int' [-Wformat=]
>
> Introduced by commit
>
>   09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
>
> from the crypto tree interacting with commit
>
>   3f4ca3d25e1a ("asm-generic, x86: wrap atomic operations")
>
> from the akpm-current tree.
>
> This latter commit changed atomic64read() from "long" to "long long"
> on x86_64.

Hi,

Previously atomic operations returned different types on 32/64 bits. I
think that was pretty unfortunate and could actually lead to lots of
such warnings (as there were no single format specifier that one could
use portably), and was difficult to wrap. So I used "unsigned long
long" for all operations.
I actually suspect that the new zip_main.c code would cause a similar
warning on 32 bits even without my change, because atomic ops already
returned unsigned long long there.
So I think we need to fix zip_main.c.

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2017-03-20  5:22 Stephen Rothwell
  2017-03-20  9:05 ` Dmitry Vyukov
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2017-03-20  5:22 UTC (permalink / raw)
  To: Andrew Morton, Herbert Xu
  Cc: linux-next, linux-kernel, Mahipal Challa, Jan Glauber, Dmitry Vyukov

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats':
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat=]
    seq_printf(s, "        ZIP Device %d Stats\n"
                  ^
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 11 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 12 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 13 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 14 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 15 has type 'long long int' [-Wformat=]

Introduced by commit

  09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")

from the crypto tree interacting with commit

  3f4ca3d25e1a ("asm-generic, x86: wrap atomic operations")

from the akpm-current tree.

This latter commit changed atomic64read() from "long" to "long long"
on x86_64.

-- 
Cheers,
Stephen Rothwell

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2015-01-27  8:12 Stephen Rothwell
@ 2015-01-27  8:27 ` Vladimir Davydov
  0 siblings, 0 replies; 33+ messages in thread
From: Vladimir Davydov @ 2015-01-27  8:27 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Hi,

On Tue, Jan 27, 2015 at 07:12:43PM +1100, Stephen Rothwell wrote:
> In file included from mm/slab_common.c:26:0:
> mm/slab_common.c: In function 'kmem_cache_destroy':
> mm/slab.h:259:30: warning: right-hand operand of comma expression has no effect [-Wunused-value]
>   for (iter = NULL, tmp = NULL, (root); 0; )
>                               ^

It's already been fixed, please see

https://lkml.org/lkml/2015/1/24/39

Thanks,
Vladimir

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2015-01-27  8:12 Stephen Rothwell
  2015-01-27  8:27 ` Vladimir Davydov
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2015-01-27  8:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Vladimir Davydov

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

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:

In file included from mm/slab_common.c:26:0:
mm/slab_common.c: In function 'kmem_cache_destroy':
mm/slab.h:259:30: warning: right-hand operand of comma expression has no effect [-Wunused-value]
  for (iter = NULL, tmp = NULL, (root); 0; )
                              ^
mm/slab_common.c:620:2: note: in expansion of macro 'for_each_memcg_cache_safe'
  for_each_memcg_cache_safe(c, c2, s) {
  ^
mm/slab_common.c: In function 'memcg_accumulate_slabinfo':
mm/slab.h:257:18: warning: right-hand operand of comma expression has no effect [-Wunused-value]
  for (iter = NULL, (root); 0; )
                  ^
mm/slab_common.c:959:2: note: in expansion of macro 'for_each_memcg_cache'
  for_each_memcg_cache(c, s) {
  ^
In file included from mm/slub.c:19:0:
mm/slub.c: In function '__kmem_cache_alias':
mm/slab.h:257:18: warning: right-hand operand of comma expression has no effect [-Wunused-value]
  for (iter = NULL, (root); 0; )
                  ^
mm/slub.c:3652:3: note: in expansion of macro 'for_each_memcg_cache'
   for_each_memcg_cache(c, s) {
   ^

Introduced by commit 3019931a000b ("slab: link memcg caches of the same
kind into a list").

-- 
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] 33+ messages in thread

* Re: linux-next: build warnings after merge of the akpm-current tree
  2014-10-03 18:21 ` Andrew Morton
@ 2014-10-03 19:28   ` Michal Nazarewicz
  0 siblings, 0 replies; 33+ messages in thread
From: Michal Nazarewicz @ 2014-10-03 19:28 UTC (permalink / raw)
  To: Andrew Morton, Stephen Rothwell, Marek Szyprowski
  Cc: linux-next, linux-kernel, Arnd Bergmann, Grant Likely,
	Laura Abbott, Josh Cartwright, Joonsoo Kim, Kyungmin Park

On Fri, Oct 03 2014, Andrew Morton wrote:
> On Fri, 3 Oct 2014 17:30:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Andrew,
>> 
>> After merging the akpm-current tree, today's linux-next build (arm
>> multi_v7_defconfig) produced these warnings:
>> 
>> drivers/base/dma-contiguous.c:244:2: warning: initialization from incompatible pointer type
>>   .device_init = rmem_cma_device_init,
>>   ^
>> drivers/base/dma-contiguous.c:244:2: warning: (near initialization for 'rmem_cma_ops.device_init')
>> drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type
>>   .device_init = rmem_dma_device_init,
>>   ^
>> 
>> Introduced by commit e92f6296f3a2 ("drivers: dma-coherent: add
>> initialization from device tree").  This init routine is supposed to
>> return void ...
>
> I'm a bit reluctant to just go in and change rmem_cma_device_init().
>
> Why does it test for rmem->priv==NULL?  Can that really happen?  Why? 
> Is it a legitimate state?

I don't think so, since:

static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
	[…]
	rmem->ops = &rmem_cma_ops;
	rmem->priv = cma;
	[…]
}

The following should fix the warning:

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 6c42289..a9a88b6 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -223,14 +223,9 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
 #undef pr_fmt
 #define pr_fmt(fmt) fmt
 
-static int rmem_cma_device_init(struct reserved_mem *rmem, struct device *dev)
+static void rmem_cma_device_init(struct reserved_mem *rmem, struct device *dev)
 {
-	struct cma *cma = rmem->priv;
-
-	if (!cma)
-		return -ENODEV;
-
-	dev_set_cma_area(dev, cma);
+	dev_set_cma_area(dev, rmem->priv);
 	return 0;
 }

Even if rmem->priv is NULL, the call will simply clear device's
cma_area, but at this point it should be NULL anyway.
 
> And why does dev_set_cma_area() test for dev==NULL?  Can that really
> happen?  Is it legitimate?  Is all this stuff just papering over other
> bugs?

I believe since a2547380393ac82c659b40182b0da8d05a8365f3 dev no longer
can be NULL.  It should be safe to apply this:

diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index 569bbd0..ff9804e 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -71,8 +71,7 @@ static inline struct cma *dev_get_cma_area(struct device *dev)
 
 static inline void dev_set_cma_area(struct device *dev, struct cma *cma)
 {
-	if (dev)
-		dev->cma_area = cma;
+	dev->cma_area = cma;
 }
 
 static inline void dma_contiguous_set_default(struct cma *cma)

>
> The whole thing could do with a bit of an audit and cleanup, I suspect.
> Get the states and initialization sequences and error checking all
> sorted out, then get rid of all these tests for NULL.
>

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2014-10-03  7:30 Stephen Rothwell
@ 2014-10-03 18:21 ` Andrew Morton
  2014-10-03 19:28   ` Michal Nazarewicz
  0 siblings, 1 reply; 33+ messages in thread
From: Andrew Morton @ 2014-10-03 18:21 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Marek Szyprowski, Arnd Bergmann,
	Michal Nazarewicz, Grant Likely, Laura Abbott, Josh Cartwright,
	Joonsoo Kim, Kyungmin Park

On Fri, 3 Oct 2014 17:30:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
> 
> drivers/base/dma-contiguous.c:244:2: warning: initialization from incompatible pointer type
>   .device_init = rmem_cma_device_init,
>   ^
> drivers/base/dma-contiguous.c:244:2: warning: (near initialization for 'rmem_cma_ops.device_init')
> drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type
>   .device_init = rmem_dma_device_init,
>   ^
> 
> Introduced by commit e92f6296f3a2 ("drivers: dma-coherent: add
> initialization from device tree").  This init routine is supposed to
> return void ...

I'm a bit reluctant to just go in and change rmem_cma_device_init().

Why does it test for rmem->priv==NULL?  Can that really happen?  Why? 
Is it a legitimate state?

And why does dev_set_cma_area() test for dev==NULL?  Can that really
happen?  Is it legitimate?  Is all this stuff just papering over other
bugs?

The whole thing could do with a bit of an audit and cleanup, I suspect.
Get the states and initialization sequences and error checking all
sorted out, then get rid of all these tests for NULL.


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

* linux-next: build warnings after merge of the akpm-current tree
@ 2014-10-03  7:30 Stephen Rothwell
  2014-10-03 18:21 ` Andrew Morton
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2014-10-03  7:30 UTC (permalink / raw)
  To: Andrew Morton
  Cc: linux-next, linux-kernel, Marek Szyprowski, Arnd Bergmann,
	Michal Nazarewicz, Grant Likely, Laura Abbott, Josh Cartwright,
	Joonsoo Kim, Kyungmin Park

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

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:

drivers/base/dma-contiguous.c:244:2: warning: initialization from incompatible pointer type
  .device_init = rmem_cma_device_init,
  ^
drivers/base/dma-contiguous.c:244:2: warning: (near initialization for 'rmem_cma_ops.device_init')
drivers/base/dma-coherent.c:303:2: warning: initialization from incompatible pointer type
  .device_init = rmem_dma_device_init,
  ^

Introduced by commit e92f6296f3a2 ("drivers: dma-coherent: add
initialization from device tree").  This init routine is supposed to
return void ...

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

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

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2014-09-23  8:18 Stephen Rothwell
  0 siblings, 0 replies; 33+ messages in thread
From: Stephen Rothwell @ 2014-09-23  8:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Pavel Machek

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

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
allyesconfig) produced these warnings:

drivers/rtc/rtc-bq32k.c: In function 'trickle_charger_of_init':
drivers/rtc/rtc-bq32k.c:155:7: warning: assignment makes pointer from integer without a cast
   reg = 0x05;
       ^
drivers/rtc/rtc-bq32k.c:165:7: warning: assignment makes pointer from integer without a cast
   reg = 0x25;
       ^
drivers/rtc/rtc-bq32k.c:177:6: warning: assignment makes pointer from integer without a cast
  reg = 0x20;
      ^

Introduced by commit 7bb72683b170 ("rtc: bq32000: add trickle charger
option, with device tree binding").

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

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2014-08-26  7:22 Stephen Rothwell
@ 2014-08-26 10:19 ` Xishi Qiu
  0 siblings, 0 replies; 33+ messages in thread
From: Xishi Qiu @ 2014-08-26 10:19 UTC (permalink / raw)
  To: Stephen Rothwell, Tang Chen; +Cc: Andrew Morton, linux-next, linux-kernel

On 2014/8/26 15:22, Stephen Rothwell wrote:

> Hi Andrew,
> 
> After merging the akpm-current tree, today's linux-next build (arm
> defconfig) produced these warnings:
> 
> In file included from /scratch/sfr/next/include/asm-generic/bug.h:13:0,
>                  from /scratch/sfr/next/arch/arm/include/asm/bug.h:61,
>                  from /scratch/sfr/next/include/linux/bug.h:4,
>                  from /scratch/sfr/next/include/linux/thread_info.h:11,
>                  from /scratch/sfr/next/include/asm-generic/preempt.h:4,
>                  from arch/arm/include/generated/asm/preempt.h:1,
>                  from /scratch/sfr/next/include/linux/preempt.h:18,
>                  from /scratch/sfr/next/include/linux/spinlock.h:50,
>                  from /scratch/sfr/next/include/linux/mmzone.h:7,
>                  from /scratch/sfr/next/include/linux/gfp.h:5,
>                  from /scratch/sfr/next/include/linux/slab.h:14,
>                  from /scratch/sfr/next/mm/nobootmem.c:13:
> /scratch/sfr/next/mm/nobootmem.c: In function 'free_low_memory_core_early':
> /scratch/sfr/next/include/linux/kernel.h:29:20: warning: large integer implicitly truncated to unsigned type [-Woverflow]
>  #define ULLONG_MAX (~0ULL)
>                     ^
> /scratch/sfr/next/mm/nobootmem.c:122:28: note: in expansion of macro 'ULLONG_MAX'
>   memblock_clear_hotplug(0, ULLONG_MAX);
>                             ^
> 
> Introduced by commit 6e162b4c49f7 ("mem-hotplug: let memblock skip the
> hotpluggable memory regions in __next_mem_range()").  The second
> argument to memblock_clear_hotplug() is a phys_addr_t, which varies in
> size between architectures/platforms.
> 

/arch/x86/mm/numa.c
numa_init()
	...
	WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
	...
This function has the same problem too, right?

#define ULLONG_MAX	(~0ULL)  -> always 64 bit, right?

#ifdef CONFIG_PHYS_ADDR_T_64BIT -> phys_addr_t is 32 or 64 bit
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif

Thanks,
Xishi Qiu


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

* linux-next: build warnings after merge of the akpm-current tree
@ 2014-08-26  7:22 Stephen Rothwell
  2014-08-26 10:19 ` Xishi Qiu
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2014-08-26  7:22 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Xishi Qiu

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

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
defconfig) produced these warnings:

In file included from /scratch/sfr/next/include/asm-generic/bug.h:13:0,
                 from /scratch/sfr/next/arch/arm/include/asm/bug.h:61,
                 from /scratch/sfr/next/include/linux/bug.h:4,
                 from /scratch/sfr/next/include/linux/thread_info.h:11,
                 from /scratch/sfr/next/include/asm-generic/preempt.h:4,
                 from arch/arm/include/generated/asm/preempt.h:1,
                 from /scratch/sfr/next/include/linux/preempt.h:18,
                 from /scratch/sfr/next/include/linux/spinlock.h:50,
                 from /scratch/sfr/next/include/linux/mmzone.h:7,
                 from /scratch/sfr/next/include/linux/gfp.h:5,
                 from /scratch/sfr/next/include/linux/slab.h:14,
                 from /scratch/sfr/next/mm/nobootmem.c:13:
/scratch/sfr/next/mm/nobootmem.c: In function 'free_low_memory_core_early':
/scratch/sfr/next/include/linux/kernel.h:29:20: warning: large integer implicitly truncated to unsigned type [-Woverflow]
 #define ULLONG_MAX (~0ULL)
                    ^
/scratch/sfr/next/mm/nobootmem.c:122:28: note: in expansion of macro 'ULLONG_MAX'
  memblock_clear_hotplug(0, ULLONG_MAX);
                            ^

Introduced by commit 6e162b4c49f7 ("mem-hotplug: let memblock skip the
hotpluggable memory regions in __next_mem_range()").  The second
argument to memblock_clear_hotplug() is a phys_addr_t, which varies in
size between architectures/platforms.

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

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

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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2013-08-29 11:24 ` Maxim Patlasov
@ 2013-08-29 19:42   ` Andrew Morton
  0 siblings, 0 replies; 33+ messages in thread
From: Andrew Morton @ 2013-08-29 19:42 UTC (permalink / raw)
  To: Maxim Patlasov; +Cc: Stephen Rothwell, linux-next, linux-kernel

On Thu, 29 Aug 2013 15:24:46 +0400 Maxim Patlasov <mpatlasov@parallels.com> wrote:

> Hi Stephen,
> 
> 08/29/2013 01:47 PM, Stephen Rothwell __________:
> > Hi Andrew,
> >
> > After merging the akpm tree, today's linux-next build (sparc64 defconfig
> > and others) produced these warnings:
> >
> > mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited':
> > mm/page-writeback.c:1450:13: warning: 'bdi_thresh' may be used uninitialized in this function [-Wuninitialized]
> > mm/page-writeback.c:1372:16: note: 'bdi_thresh' was declared here
> > mm/page-writeback.c:1226:16: warning: 'bdi_dirty' may be used uninitialized in this function [-Wuninitialized]
> > mm/page-writeback.c:1369:16: note: 'bdi_dirty' was declared here
> >
> > Possibly introduced by commit 34c547af1e23 ("mm/page-writeback.c: add
> > strictlimit feature"), but I am not sure anything can be done about them.
> >
> 
> This looks as gcc glitch. So far as I didn't observe the warnings, the 
> version of gcc does matter. May be moving the definitions of the two 
> variables into for(;;){...} would help. Could you please give it a try?

Shuffling the definitions around won't help.  To fix this we'll need to
add more code and I hate adding runtime overhead to address
compile-time issues.  So...

--- a/mm/page-writeback.c~a
+++ a/mm/page-writeback.c
@@ -1366,10 +1366,8 @@ static void balance_dirty_pages(struct a
 {
 	unsigned long nr_reclaimable;	/* = file_dirty + unstable_nfs */
 	unsigned long nr_dirty;  /* = file_dirty + writeback + unstable_nfs */
-	unsigned long bdi_dirty;
 	unsigned long background_thresh;
 	unsigned long dirty_thresh;
-	unsigned long bdi_thresh;
 	long period;
 	long pause;
 	long max_pause;
@@ -1385,8 +1383,10 @@ static void balance_dirty_pages(struct a
 
 	for (;;) {
 		unsigned long now = jiffies;
-		unsigned long dirty;
+		unsigned long uninitialized_var(bdi_thresh);
 		unsigned long thresh;
+		unsigned long uninitialized_var(bdi_dirty);
+		unsigned long dirty;
 		unsigned long bg_thresh;
 
 		/*
_



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

* Re: linux-next: build warnings after merge of the akpm-current tree
  2013-08-29  9:47 Stephen Rothwell
@ 2013-08-29 11:24 ` Maxim Patlasov
  2013-08-29 19:42   ` Andrew Morton
  0 siblings, 1 reply; 33+ messages in thread
From: Maxim Patlasov @ 2013-08-29 11:24 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel

Hi Stephen,

08/29/2013 01:47 PM, Stephen Rothwell пишет:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (sparc64 defconfig
> and others) produced these warnings:
>
> mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited':
> mm/page-writeback.c:1450:13: warning: 'bdi_thresh' may be used uninitialized in this function [-Wuninitialized]
> mm/page-writeback.c:1372:16: note: 'bdi_thresh' was declared here
> mm/page-writeback.c:1226:16: warning: 'bdi_dirty' may be used uninitialized in this function [-Wuninitialized]
> mm/page-writeback.c:1369:16: note: 'bdi_dirty' was declared here
>
> Possibly introduced by commit 34c547af1e23 ("mm/page-writeback.c: add
> strictlimit feature"), but I am not sure anything can be done about them.
>

This looks as gcc glitch. So far as I didn't observe the warnings, the 
version of gcc does matter. May be moving the definitions of the two 
variables into for(;;){...} would help. Could you please give it a try?

Thanks,
Maxim

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

* linux-next: build warnings after merge of the akpm-current tree
@ 2013-08-29  9:47 Stephen Rothwell
  2013-08-29 11:24 ` Maxim Patlasov
  0 siblings, 1 reply; 33+ messages in thread
From: Stephen Rothwell @ 2013-08-29  9:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-next, linux-kernel, Maxim Patlasov

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

Hi Andrew,

After merging the akpm tree, today's linux-next build (sparc64 defconfig
and others) produced these warnings:

mm/page-writeback.c: In function 'balance_dirty_pages_ratelimited':
mm/page-writeback.c:1450:13: warning: 'bdi_thresh' may be used uninitialized in this function [-Wuninitialized]
mm/page-writeback.c:1372:16: note: 'bdi_thresh' was declared here
mm/page-writeback.c:1226:16: warning: 'bdi_dirty' may be used uninitialized in this function [-Wuninitialized]
mm/page-writeback.c:1369:16: note: 'bdi_dirty' was declared here

Possibly introduced by commit 34c547af1e23 ("mm/page-writeback.c: add
strictlimit feature"), but I am not sure anything can be done about them.

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

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

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

end of thread, other threads:[~2022-03-29  3:32 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-06 12:05 linux-next: build warnings after merge of the akpm-current tree Stephen Rothwell
2020-10-06 20:01 ` Peter Xu
2020-10-06 22:03   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2022-02-09  6:02 Stephen Rothwell
2022-02-09 16:03 ` Hugh Dickins
2022-03-28 23:04   ` Matthew Wilcox
2022-03-29  3:32     ` Hugh Dickins
2022-03-24  7:27 ` Stephen Rothwell
2022-03-28 19:54   ` Hugh Dickins
2022-03-28 22:10     ` Matthew Wilcox
2021-10-11  7:31 Stephen Rothwell
2021-10-11 17:46 ` Kees Cook
2021-06-15 10:50 Stephen Rothwell
2020-01-06  6:14 Stephen Rothwell
2017-08-24  7:41 Stephen Rothwell
2017-08-24  8:15 ` Changwei Ge
2017-08-25 21:23   ` Andrew Morton
2017-08-26  1:23     ` Changwei Ge
2017-03-20  5:22 Stephen Rothwell
2017-03-20  9:05 ` Dmitry Vyukov
2017-03-20 12:30   ` Jan Glauber
2017-03-20 17:06     ` Challa, Mahipal
2015-01-27  8:12 Stephen Rothwell
2015-01-27  8:27 ` Vladimir Davydov
2014-10-03  7:30 Stephen Rothwell
2014-10-03 18:21 ` Andrew Morton
2014-10-03 19:28   ` Michal Nazarewicz
2014-09-23  8:18 Stephen Rothwell
2014-08-26  7:22 Stephen Rothwell
2014-08-26 10:19 ` Xishi Qiu
2013-08-29  9:47 Stephen Rothwell
2013-08-29 11:24 ` Maxim Patlasov
2013-08-29 19:42   ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).