netdev - Re: [net-next PATCH 2] net: ethernet driver: Fujitsu OGMA

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 20 Jun 2014 15:10:08 +0800
From:	Andy Green <andy.green@...aro.org>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev <netdev@...r.kernel.org>,
	Francois Romieu <romieu@...zoreil.com>,
	Patch Tracking <patches@...aro.org>
Subject: Re: [net-next PATCH 2] net: ethernet driver: Fujitsu OGMA

On 11 June 2014 01:28, Stephen Hemminger <stephen@...workplumber.org> wrote:
> On Tue, 10 Jun 2014 09:08:03 +0800
> Andy Green <andy.green@...aro.org> wrote:
>
>> +static int ogma_netdev_change_mtu(struct net_device *net_device, int new_mtu)
>> +{
>> +     struct ogma_ndev *ndev = netdev_priv(net_device);
>> +
>> +     if (!ndev->priv->param.use_jumbo_pkt_flag)
>> +             return eth_change_mtu(net_device, new_mtu);
>> +
>> +     if ((new_mtu < 68) || (new_mtu > 9000))
>> +             return -EINVAL;
>> +
>> +     net_device->mtu = new_mtu;
>> +
>> +     return 0;
>> +}
>> +
>
> I don't think this works. rx_pkt_buf_len is only set at probe time.
>
> Don't you need to:
>  1. Stop device if running
>  2. Free existing receive buffers
>  3. change rx_pkt_buf_len
>  4. Refill restart receiver.
>
> Most devices setup receive ring in open (not probe)
> to handle this. It also avoid grabbing memory if device is unused.

Sorry for the late response... I have just sent v4 implementing all
the comments except perhaps this one.

I understand the issue you mention.  I have indeed now moved the rx
buffer alloc / free into the network_device open / close.

But it wasn't clear to me from your comment that if we do that, that
the networking stack itself will take care about close and reopen the
network device on mtu change.

If that's the case I guess I can use eth_change_mtu now, but is that
what you meant by "Most devices setup receive ring in open (not probe)
 to handle this"?

-Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html