On 29/06/15 10:44, Tom Hughes wrote:
On 29/06/15 10:20, Tom Hughes wrote:
On 29/06/15 09:30, Tom Hughes wrote:
On 29/06/15 09:14, Johannes Berg wrote:
On Sat, 2015-06-27 at 16:34 +0100, Tom Hughes wrote:
Interestingly from what I can see this is trying to create a file
for the station at a path something like:
ieee80211/phy0/netdev:XXXX/stations/XXXXXX
indeed.
but in my (currently working) boot under 4.0.4 there is no netdev
directory under phy0 in debugfs... but then maybe that is the problem
as well if the inode pointer was null?
This is pretty strange - if the dentry pointer (sdata
->debugfs.subdir_stations) was NULL or an ERR_PTR(), the code would
return pretty much immediately.
So it looks like that pointer is valid, but it's ->d_inode was NULL?
I'm not really sure how that could happen.
Indeed I'm a bit puzzled...
It looks like hostapd has something to do with it... If I stop hostapd and
remove ath9k and then reprobe it then the netdev dir appears:
gosford [~] % sudo modprobe ath9k
gosford [~] % sudo ls /sys/kernel/debug/ieee80211/phy1
ath9k long_retry_limit reset user_power
fragmentation_threshold netdev:wlp2s0 rts_threshold wep_iv
ht40allow_map power short_retry_limit
hwflags queues statistics
keys rc total_ps_buffered
Then I start hostapd and it vanishes:
...and you also need to have selinux in enforcing mode.
It appears hostapd is trying to do something with debugfs and is
being denied directory search access:
So I think this happens when hostapd switches the interface
to AP mode, which causes the netdev to be torn down and then
recreated, and the debugfs directory along with it.
Except that if the netlink message to change the mode was
sent from a daemon whose selinux context prevents searching
debugfs the recreation somehow fails and leaves an invalid
state that later causes the null pointer deref.
Tom
--
Tom Hughes (tom@xxxxxxxxxx)
http://compton.nu/
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html