linux-kernel - Re: [PATCH v2 0/6] Improve visibility of writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2695c070-6490-172a-e735-521f6412aa74@huaweicloud.com>
Date: Thu, 28 Mar 2024 16:23:56 +0800
From: Kemeng Shi <shikemeng@...weicloud.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: willy@...radead.org, jack@...e.cz, bfoster@...hat.com, tj@...nel.org,
 dsterba@...e.com, mjguzik@...il.com, dhowells@...hat.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 0/6] Improve visibility of writeback



on 3/28/2024 9:59 AM, Kemeng Shi wrote:
> 
> on 3/28/2024 1:40 AM, Andrew Morton wrote:
>> On Wed, 27 Mar 2024 23:57:45 +0800 Kemeng Shi <shikemeng@...weicloud.com> wrote:
>>
>>> This series tries to improve visilibity of writeback.
>>
>> Well...  why?  Is anyone usefully using the existing instrumentation? 
>> What is to be gained by expanding it further?  What is the case for
>> adding this code?
>>
>> I don't recall hearing of anyone using the existing debug
>> instrumentation so perhaps we should remove it!
> Hi Andrew, this was discussed in [1]. In short, I use the
> debug files to test change in submit patchset [1]. The
> wb_monitor.py is suggested by Tejun in [2] to improve
> visibility of writeback.
> I use the debug files to test change in [1]. The wb_monitor.py is suggested by Tejun
> in [2] to improve visibility of writeback.
>>
>> Also, I hit a build error and a pile of warnings with an arm
>> allnoconfig build.
With arm allnoconfig build on uptodated mm-unstable branch, I don't
hit any build error but only some warnings as following:
..
mm/page-writeback.c: In function ‘cgwb_calc_thresh’:
mm/page-writeback.c:906:13: warning: ‘writeback’ is used uninitialized in this function [-Wuninitialized]
  906 |  mdtc.dirty += writeback;
      |  ~~~~~~~~~~~^~~~~~~~~~~~
In file included from ./include/linux/kernel.h:28,
                 from mm/page-writeback.c:15:
/include/linux/minmax.h:46:54: warning: ‘filepages’ is used uninitialized in this function [-Wuninitialized]
   46 | #define __cmp(op, x, y) ((x) __cmp_op_##op (y) ? (x) : (y))
      |                                                      ^
mm/page-writeback.c:898:16: note: ‘filepages’ was declared here
  898 |  unsigned long filepages, headroom, writeback;
      |                ^~~~~~~~~
In file included from ./include/linux/kernel.h:28,
                 from mm/page-writeback.c:15:
/include/linux/minmax.h:46:54: warning: ‘headroom’ is used uninitialized in this function [-Wuninitialized]
   46 | #define __cmp(op, x, y) ((x) __cmp_op_##op (y) ? (x) : (y))
      |                                                      ^
mm/page-writeback.c:898:27: note: ‘headroom’ was declared here
  898 |  unsigned long filepages, headroom, writeback;
      |                           ^~~~~~~~
..

The only reason I can think of is that I also apply patchset [1]
for build. I mentioned patchset [1] in cover letter but I forgot
to notify the dependency to the patchset.
If this is the reason to blame for buidl error, I will send a new
set based on mm-unstable in next version.

Thanks,
Kemeng

[1] https://lore.kernel.org/lkml/20240123183332.876854-1-shikemeng@huaweicloud.com/T/#mc6455784a63d0f8aa1a2f5aff325abcdf9336b76
>>
> Sorry for this, I only tested on x86. I will look into this and
> fix the build problem in next version.
> 
> [1] https://lore.kernel.org/lkml/44e3b910-8b52-5583-f8a9-37105bf5e5b6@huaweicloud.com/
> [2] https://lore.kernel.org/lkml/a747dc7d-f24a-08bd-d969-d3fb35e151b7@huaweicloud.com/
> [3] https://lore.kernel.org/lkml/ZcUsOb_fyvYr-zZ-@slm.duckdns.org/
>