[PATCH net v2 RESEND] net: ena: set admin device pointer before queue allocations

[PATCH net v2 RESEND] net: ena: set admin device pointer before queue allocations

[Avi Weiss]

From: Wajeeh Atrash <atrwajee@amazon.com>

On the first probe, ena_com_admin_init() allocates the completion
contexts and admin SQ/CQ buffers before setting admin_queue->ena_dev.
Their allocation failure paths log through this pointer, which is
still NULL. A failed allocation therefore dereferences NULL instead
of returning -ENOMEM.

Set admin_queue->ena_dev before the first allocation so the helpers
can log errors and return -ENOMEM normally.

This issue has already been fixed in Amazon's standalone ENA driver
(commit 7d1dc4341d4f).

Fixes: da580ca8de2c ("net: ena: add device distinct log prefix to files")
Signed-off-by: Wajeeh Atrash <atrwajee@amazon.com>
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
---
 drivers/net/ethernet/amazon/ena/ena_com.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index 297fb36ab8c16..9b14cddf4432e 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -1992,6 +1992,7 @@ int ena_com_admin_init(struct ena_com_dev *ena_dev,
 
 	admin_queue->q_depth = ENA_ADMIN_QUEUE_DEPTH;
 
+	admin_queue->ena_dev = ena_dev;
 	admin_queue->q_dmadev = ena_dev->dmadev;
 	admin_queue->polling = false;
 	admin_queue->curr_cmd_id = 0;
@@ -2045,7 +2046,6 @@ int ena_com_admin_init(struct ena_com_dev *ena_dev,
 	if (ret)
 		goto error;
 
-	admin_queue->ena_dev = ena_dev;
 	admin_queue->running_state = true;
 
 	return 0;
-- 
2.43.0

Re: [PATCH net v2 RESEND] net: ena: set admin device pointer before queue allocations

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by LLM and not proven at runtime). If it was triggered
   please include the symptoms, like the stack trace or kernel messages.

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account.

*IMPORTANT*: If you do repost (for other reasons) - please include
the relevant info in the cover letter or commit messages.
-- 
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.