Re: [PATCH v5 3/5] writeback: fix build problems of "writeback: support retrieving per group debug writeback stats of bdi"

[Kemeng Shi <shikemeng@huaweicloud.com>]

Hi Johannes,
on 4/24/2024 9:27 PM, Johannes Weiner wrote:
> Hi Kemeng,
> 
> On Tue, Apr 23, 2024 at 11:46:41AM +0800, Kemeng Shi wrote:
>> Fix two build problems:
>> 1. implicit declaration of function 'cgroup_ino'.
> 
> I just ran into this as well, with defconfig on mm-everything:
Sorry for this.
> 
> /home/hannes/src/linux/linux/mm/backing-dev.c: In function 'wb_stats_show':
> /home/hannes/src/linux/linux/mm/backing-dev.c:175:33: error: 'struct bdi_writeback' has no member named 'memcg_css'
>   175 |                    cgroup_ino(wb->memcg_css->cgroup),
>       |                                 ^~
> make[3]: *** [/home/hannes/src/linux/linux/scripts/Makefile.build:244: mm/backing-dev.o] Error 1
> 
>> ---
>>  mm/backing-dev.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/backing-dev.c b/mm/backing-dev.c
>> index 6ecd11bdce6e..e61bbb1bd622 100644
>> --- a/mm/backing-dev.c
>> +++ b/mm/backing-dev.c
>> @@ -172,7 +172,11 @@ static void wb_stats_show(struct seq_file *m, struct bdi_writeback *wb,
>>  		   "b_more_io:         %10lu\n"
>>  		   "b_dirty_time:      %10lu\n"
>>  		   "state:             %10lx\n\n",
>> +#ifdef CONFIG_CGROUP_WRITEBACK
>>  		   cgroup_ino(wb->memcg_css->cgroup),
>> +#else
>> +		   1ul,
>> +#endif
>>  		   K(stats->nr_writeback),
>>  		   K(stats->nr_reclaimable),
>>  		   K(stats->wb_thresh),
>> @@ -192,7 +196,6 @@ static int cgwb_debug_stats_show(struct seq_file *m, void *v)
>>  	unsigned long background_thresh;
>>  	unsigned long dirty_thresh;
>>  	struct bdi_writeback *wb;
>> -	struct wb_stats stats;
>>  
>>  	global_dirty_limits(&background_thresh, &dirty_thresh);
> 
> The fix looks right to me, but it needs to be folded into the previous
> patch. No patch should knowingly introduce an issue that is fixed
> later on. This will break bisection.
As I'm not sure if previous patch is already applied to tree, so I
make this fix a individual patch and mentioned in cover letter that
this could be folded if previous patch is not in tree or this could
be applied individually to fix the introduced issue. As Androw told
me that little fixups would be preferred instead of entire resend in
current stage, I guess a new series with this patch foled should not
be necessary. If a new series is still needed, please let me konw.
I would like to it.

Thanks.