On Wed Sep 14 2022, Zulkifli, Muhammad Husaini wrote: > Hi Vinicius, > > Thanks for the review. Replied inline > >> -----Original Message----- >> From: Gomes, Vinicius >> Sent: Thursday, 15 September, 2022 3:04 AM >> To: Zulkifli, Muhammad Husaini ; >> intel-wired-lan@osuosl.org >> Cc: Zulkifli, Muhammad Husaini >> Subject: Re: [Intel-wired-lan] [PATCH v1] igc: Fix kernel NULL pointer >> dereference >> >> Hi Husaini, >> >> Muhammad Husaini Zulkifli writes: >> >> > This patch fix the null pointer dereference when dereference the >> > pointer that is expected to be valid but is NULL, typically will cause >> > kernel crash as below: >> > >> >> This part of the message only repeats that you found NULL dereference >> related crash, which is already clear from the splat below. >> >> Can you give more details about how you manage to crash? What is schedule >> that you tried to use, that kind of thing. Perhaps the problem is somewhere >> else and we are only hiding the problem. > > With below schedule, if you are not try to dereferencing the pointer, we cannot catch this. > Might be compiler already handle it. This is a guard to ensure that "prev" pointer always valid > Address before using it. It will always NULL if you have 1 GCL schedule entry. Hm. Yes, prev is NULL for the first schedule entry. Nevertheless, it shouldn't be referenced, as `queue_uses[i] > 1' cannot be true for the first entry unless I'm missing something. > > Example schedule: > > tc qdisc replace dev ${INTERFACE} handle 100 parent root taprio num_tc 3 \ > map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \ > queues 1@0 1@1 2@2 \ > base-time ${BASETIME} \ > sched-entry S 0x01 300000 > flags 0x02 Well, with this schedule I cannot reproduce the issue. What kernel version are you testing? Mainline? Thanks, Kurt