drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
There's no reason to use bit shift to find the UDP header.
It's not intuitive and it reinvents well-defined functions.
Signed-off-by: Moon Yeounsu <yyyynoom@gmail.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 360ee26557f7..07c4cf84bdf3 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5731,7 +5731,7 @@ static int e1000_transfer_dhcp_info(struct e1000_adapter *adapter,
if (ip->protocol != IPPROTO_UDP)
return 0;
- udp = (struct udphdr *)((u8 *)ip + (ip->ihl << 2));
+ udp = (struct udphdr *)((u8 *)ip + ip_hdrlen(skb));
if (ntohs(udp->dest) != 67)
return 0;
--
2.45.2
Moon Yeounsu <yyyynoom@gmail.com> wrote: > There's no reason to use bit shift to find the UDP header. > It's not intuitive and it reinvents well-defined functions. > > Signed-off-by: Moon Yeounsu <yyyynoom@gmail.com> > --- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c > index 360ee26557f7..07c4cf84bdf3 100644 > --- a/drivers/net/ethernet/intel/e1000e/netdev.c > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c > @@ -5731,7 +5731,7 @@ static int e1000_transfer_dhcp_info(struct e1000_adapter *adapter, > if (ip->protocol != IPPROTO_UDP) > return 0; > > - udp = (struct udphdr *)((u8 *)ip + (ip->ihl << 2)); > + udp = (struct udphdr *)((u8 *)ip + ip_hdrlen(skb)); This helper needs skb_network_header being set up correctly, are you sure thats the case here? ip pointer is fetched via data + 14 right above, so it doesn't look like this would work.
On Thu, Aug 1, 2024 at 11:06 PM Florian Westphal <fw@strlen.de> wrote: > This helper needs skb_network_header being set up correctly, are you > sure thats the case here? ip pointer is fetched via data + 14 right > above, so it doesn't look like this would work. I read it once more carefully, and yes, you are right. Sorry for wasting your time... It is my first patch to the netdev subsystem. So... I was too excited. It's all my fault. Next time, I'll be careful and deliberate. Thank you for reviewing.
© 2016 - 2026 Red Hat, Inc.