Bug 206695

Created attachment 287689 [details]
dmesg (kernel 5.6-rc3, PowerMac G5 11,2)

Created attachment 287691 [details]
kernel .config (kernel 5.6-rc3, PowerMac G5 11,2)

Can you try this patch?

diff --git a/drivers/macintosh/windfarm_pm112.c b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..a16f43a1def9 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -125,7 +125,7 @@ static int create_cpu_loop(int cpu)
 {
 	int chip = cpu / 2;
 	int core = cpu & 1;
-	struct smu_sdbp_header *hdr;
+	struct smu_sdbp_header *hdr, *hdr2;
 	struct smu_sdbp_cpupiddata *piddata;
 	struct wf_cpu_pid_param pid;
 	struct wf_control *main_fan = cpu_fans[0];
@@ -141,9 +141,9 @@ static int create_cpu_loop(int cpu)
 	piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
 
 	/* Get FVT params to get Tmax; if not found, assume default */
-	hdr = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
-	if (hdr) {
-		struct smu_sdbp_fvt *fvt = (struct smu_sdbp_fvt *)&hdr[1];
+	hdr2 = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
+	if (hdr2) {
+		struct smu_sdbp_fvt *fvt = (struct smu_sdbp_fvt *)&hdr2[1];
 		tmax = fvt->maxtemp << 16;
 	} else
 		tmax = 95 << 16;	/* default to 95 degrees C */
@@ -174,6 +174,10 @@ static int create_cpu_loop(int cpu)
 		pid.min = fmin;
 
 	wf_cpu_pid_init(&cpu_pid[cpu], &pid);
+
+	kfree(hdr);
+	kfree(hdr2);
+
 	return 0;
 }

(In reply to mpe from comment #3)
> Can you try this patch?

Applied your patch on top of 5.6-rc4 + https://patchwork.ozlabs.org/patch/1248350/ and let the G5 do a few hours compiling.

Only getting those nice memleaks from bug #206203 but no windfarm_pm112 memleak any longer. So your patch works well it seems. Thanks!

bugzilla-daemon@bugzilla.kernel.org writes:
> https://bugzilla.kernel.org/show_bug.cgi?id=206695
>
> --- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
> (In reply to mpe from comment #3)
>> Can you try this patch?
>
> Applied your patch on top of 5.6-rc4 +
> https://patchwork.ozlabs.org/patch/1248350/ and let the G5 do a few hours
> compiling.
>
> Only getting those nice memleaks from bug #206203 but no windfarm_pm112
> memleak
> any longer. So your patch works well it seems. Thanks!

Thanks.

Can you try this one instead, it changes the order of operations to make
the code flow a bit nicer.

cheers

diff --git a/drivers/macintosh/windfarm_pm112.c b/drivers/macintosh/windfarm_pm112.c
index 4150301a89a5..e8377ce0a95a 100644
--- a/drivers/macintosh/windfarm_pm112.c
+++ b/drivers/macintosh/windfarm_pm112.c
@@ -132,14 +132,6 @@ static int create_cpu_loop(int cpu)
 	s32 tmax;
 	int fmin;
 
-	/* Get PID params from the appropriate SAT */
-	hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL);
-	if (hdr == NULL) {
-		printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n");
-		return -EINVAL;
-	}
-	piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
-
 	/* Get FVT params to get Tmax; if not found, assume default */
 	hdr = smu_sat_get_sdb_partition(chip, 0xC4 + core, NULL);
 	if (hdr) {
@@ -152,6 +144,16 @@ static int create_cpu_loop(int cpu)
 	if (tmax < cpu_all_tmax)
 		cpu_all_tmax = tmax;
 
+	kfree(hdr);
+
+	/* Get PID params from the appropriate SAT */
+	hdr = smu_sat_get_sdb_partition(chip, 0xC8 + core, NULL);
+	if (hdr == NULL) {
+		printk(KERN_WARNING"windfarm: can't get CPU PID fan config\n");
+		return -EINVAL;
+	}
+	piddata = (struct smu_sdbp_cpupiddata *)&hdr[1];
+
 	/*
 	 * Darwin has a minimum fan speed of 1000 rpm for the 4-way and
 	 * 515 for the 2-way.  That appears to be overkill, so for now,
@@ -174,6 +176,9 @@ static int create_cpu_loop(int cpu)
 		pid.min = fmin;
 
 	wf_cpu_pid_init(&cpu_pid[cpu], &pid);
+
+	kfree(hdr);
+
 	return 0;
 }

(In reply to mpe from comment #5)
> Can you try this one instead, it changes the order of operations to make
> the code flow a bit nicer.
2nd patch works equally well.

Patch posted:

https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200423060038.3308530-1-mpe@ellerman.id.au/

123456789+123456789+123456789+123456789+123456789+123456789+123456789+
I will apply the patch and try with Linux 5.7-rc2 and post any results
seen.

Also this does close off : https://bugzilla.kernel.org/show_bug.cgi?id=199471

I see Wolfram Sang has commented there. OKay ... good stuff.

Dennis Clarke

I see this has not gone upstream to 5.7-rc3 and thus I am applying
it manually and building now.  

Shall report on the kmem leak shortly. I hope. 

Dennis