netdev - RE: [PATCH V2 net] core: Don't attempt to load the "" driver.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1748EC90@AcuExch.aculab.com>
Date:	Wed, 10 Sep 2014 08:50:50 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'David Miller' <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH V2 net] core: Don't attempt to load the "" driver.

From: David Miller
> From: David Laight <David.Laight@...LAB.COM>
> Date: Mon, 8 Sep 2014 13:23:33 +0000
> 
> > This whole 'try to load the module' path should be predicated on
> > 'interface not found'.
> 
> And that's the first thing dev_load() does, it tries to look up the
> device by name, and only does the module load attempt if that fails.

OK, I'd not looked back at the code before making that comment.

> Nobody cares if the module load itself actually fails, dev_load()
> returns void after all.

The actual code path is typically:
	dev_load(net, ifr.ifr_name);
	rtnl_lock()
	ret = dev_xxx(net, &ifr, cmd);
	rtnl_unlock()

where the first thing dev_xxx() does is to call __dev_get_by_name()
(or the equivalent dev_get_by_name_rcu()) again.
So the code 'sort of' cares whether the module loaded.

I actually wonder when the module load is useful - must be useful sometimes,
otherwise it wouldn't have been added.

I thought ifr.ifr_name was likely to be (say) "eth2" - but the module
won't be called that.
Looks like some hack to get something like the 'bond' driver loaded,
but even then surely ifr.ifr_name would be "bond0" not "bond".

I've had a quick look with 'git blame', but dev_ioctl.c was split from
somewhere and doesn't contain the history.

	David.

--
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