On Wed, 12 Jul 2023 at 09:39, Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> wrote: > > > > On 7/11/2023 10:57 AM, Chunyan Zhang wrote: > > On Mon, 10 Jul 2023 at 17:57, Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> wrote: > >> > >> > >> > >> On 7/10/2023 4:03 PM, Chunyan Zhang wrote: > >>> The global pointer 'sprd_port' maybe not zero when sprd_probe returns > >>> fail, that is a risk for sprd_port to be accessed afterward, and will > >>> lead unexpected errors. > >>> > >>> For example: > >>> > >>> There're two UART ports, UART1 is used for console and configured in kernel > >>> command line, i.e. "console="; > >>> > >>> The UART1 probe fail and the memory allocated to sprd_port[1] was released, > >>> but sprd_port[1] was not set to NULL; > >> > >> IMO, we should just set sprd_port[1] to be NULL, which seems simpler? > > > > This patch just does like this indeed, in the label of 'clean_port'. > > Adding a local variable instead of using global pointer (sprd_port[]) > > to store the virtual address allocated for sprd_port can avoid > > overmany goto labels. > > > >> > >>> > >>> In UART2 probe, the same virtual address was allocated to sprd_port[2], > >>> and UART2 probe process finally will go into sprd_console_setup() to > >>> register UART1 as console since it is configured as preferred console > >>> (filled to console_cmdline[]), but the console parameters (sprd_port[1]) > >>> actually belongs to UART2. > >> > >> I'm confusing why the console parameters belongs to UART2? Since the > >> console_cmdline[] will specify the serial index, that belongs to UART1. > > > > The same virtual address stored in sprd_port[1] was reallocated to > > sprd_port[2] after the UART1 probe returned failure. > > > > After more thinking, I understood your case. :) > > But I see a nit in this patch, you added a 'clean_port' label to clear > the resource for the fail-probe-port instead of sprd_remove(), however > sprd_remove() will call sprd_rx_free_buf() to free the DMA buffer > originally. I know the 2nd patch will add it back, but patch 1 is not > git-bisect safe, right? Actually it doesn't make git-bisect unsafe, the driver can work with a memory leak issue which has been there and fixed in another patch. But I can add back sprd_remove() to keep the unrelated code logic the same. Thanks for the review, Chunyan > > So I think you should also add sprd_rx_free_buf() under the 'clean_port' > label in patch 1, then patch 2 moves the sprd_rx_free_buf() to the > correct place. >
