Re: bpfilter causes a leftover kernel process
Hi, Quick follow-up on this: - first off, Arch devs have updated their kernel config so the next kernel will not have bpfilter enabled anymore, thus avoiding any issue. - having said that, I've found a neasy way to reproduce it in an Arch VM, in case you're interested : Boot the latest Arch ISO[1] which now contains a kernel 4.18.5 and do a very basic installation, pretty much just: # pacstrap /mnt base # genfstab -U /mnt >> /mnt/etc/fstab And of course install your boot loader of choice. Then boot the brand new system, log in and make sure the helper is actually started, i.e. `modprobe bpfilter` -- Now halt. You'll see in the end that systemd complains that it can't unmount /oldroot (EBUSY), aka the root fs; and that's because of the bpfilter helper, which wasn't killed because it's seen as a kernel thread due to its empty command line and therefore not signaled. Cheers, [1] https://www.archlinux.org/download/
Re: bpfilter causes a leftover kernel process
On Tue, 28 Aug 2018 22:35:38 -0700
Alexei Starovoitov wrote:
> > Yeah, I have a similar thing happening on shutdown, except that
> > we're talking about a kernel thread here, so that process is
> > ignored by the mentionned killing spree as a result, thus leaving
> > that process running.
>
> it's not a kernel thread and sounds like there is a bug in your pid 1
> that is worth fixing.
Well, it sure does look like one. By which I mean that looking at
its /proc/$PID entry, one can see that it has an empty command line and
kthreadd as parent (ppid 2), which usually are only true for kernel
threads (unless I'm mistaken).
The tool I'm using to send the signals on shutdown does indeed not use
kill(-1,sig) but instead scans /proc and determines whether or not to
signal a process (thus allowing to ignore a few specific processes to
be killed later on).
Kernel threads are obviously to be skipped, and to identify them it
uses the classic method of checking whether or not it has an empty
command line. As I said, this bpfilter helper does and that's why it is
considered a kernel thread & thus not killed.
This is also what other tools do, like ps or top, which is indeed why
they also show it as a kernel thread ("[none]").
So is this way of doing this wrong? And if so, what would be a better
way to identify kernel threads?
Out of curiosity I also had a look at how systemd does things, and it
looks to me like it does the exact same thing[1], also identifying
kernel threads by their empty command line. So I would think that a
similar issue could be observed under systemd as well.
Thanks.
[1]
https://github.com/systemd/systemd/blob/master/src/core/killall.c#L44
Re: bpfilter causes a leftover kernel process
On Mon, 27 Aug 2018 20:35:02 -0700 Alexei Starovoitov wrote: > I'm also running Arch Linux in my VM, but I'm not able to reproduce > umount issue. I'm guessing it's somehow related to non-static build > and libc.so being busy with old systemd. Oh, I mentioned it in a previous draft of my original mail but it seems it got lost in rewrites, I don't actually use systemd. Not that it should matter here though. > Typical shutdown should have done: > [ 73.498022] shutdown[1]: Sending SIGTERM to remaining processes... > [ 73.505501] shutdown[1]: Sending SIGKILL to remaining processes... > [ 73.512783] shutdown[1]: Unmounting file systems. > And at the time of umount / no processes are alive other than systemd. Yeah, I have a similar thing happening on shutdown, except that we're talking about a kernel thread here, so that process is ignored by the mentionned killing spree as a result, thus leaving that process running. >From a shell opened after the umounting fails I can see that only my pid1 & the opened shell are running, except of course that this bpfilter process is there, as a kernel thread "[none]" Manually killing it at that point works, i.e. allows the umounting to succeed and a proper shutdown to complete.
Re: bpfilter causes a leftover kernel process
Small addentum: Of course I failed to realize this bpfilter helper is also mentioned in the kernel log: kern.info: [8.997711] bpfilter: Loaded bpfilter_umh pid 920 It also seems to be absolutely required when CONFIG_BPFILTER is enabled, that is I tried blacklisting the module bpfilter, but then other things (e.g. iptables-restore) just fail to work. So the process is required, never ends and prevents umouting the rootfs on shutdown. Unless I'm missing something, there's definitely a bug there? Thanks,
bpfilter causes a leftover kernel process
Hi, (Please cc me as I'm not subscribed to the list, thanks.) I'm running an Arch Linux x86_64 system, and recently updated to a 3.18 kernel, which led me to encounter what I believe to be a kernel bug related to the bpfilter framework. What happens is that upon boot, there's a "leftover kernel process" running (shown as "[none]" in ps), which doesn't seem to do anything (anymore) but does have references/fds open to the root fs, and so when trying to shutdown the system umounting the root fs fails (EBUSY) because of it, leading to expected issues. Simply killing that process allows umounting the root fs fine and "resolves" all issues. This process/behavior wasn't there with any previous kernel, and is there with all tried kernels from 4.18.0 to 4.18.4, without any other change to the system -- although this is due to CONFIG_BPFILTER=y in the kernel config. Indeed I managed to compile a kernel 4.18.4 myself using the Arch Linux config[1] with a single change of unsetting CONFIG_BPFILTER, and with the resulting kernel I don't have this "leftover kernel process" anymore, everything is back to normal. Now, about this process, here's a few outputs to try and describe what it is: rafus# pgrep none 920 rafus# cd /proc/920 rafus# readlink exe / (deleted) rafus# ls -l fd total 0 lr-x-- 1 root root 64 Aug 26 17:17 0 -> 'pipe:[13366]' l-wx-- 1 root root 64 Aug 26 17:17 1 -> 'pipe:[13367]' lrwx-- 1 root root 64 Aug 26 17:17 2 -> /dev/console rafus# cat status Name: none Umask: 0022 State: S (sleeping) Tgid: 920 Ngid: 0 Pid:920 PPid: 2 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 64 Groups: NStgid: 920 NSpid: 920 NSpgid: 0 NSsid: 0 VmPeak: 2296 kB VmSize: 2296 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 748 kB VmRSS: 748 kB RssAnon: 60 kB RssFile: 684 kB RssShmem: 4 kB VmData: 176 kB VmStk: 132 kB VmExe: 8 kB VmLib: 1452 kB VmPTE:44 kB VmSwap:0 kB HugetlbPages: 0 kB CoreDumping:0 Threads:1 SigQ: 0/7861 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: 003f CapEff: 003f CapBnd: 003f CapAmb: NoNewPrivs: 0 Seccomp:0 Speculation_Store_Bypass: vulnerable Cpus_allowed: 1 Cpus_allowed_list: 0 Mems_allowed: 0001 Mems_allowed_list: 0 voluntary_ctxt_switches:65 nonvoluntary_ctxt_switches: 1 rafus# cat stack [<0>] pipe_wait+0x6c/0xb0 [<0>] pipe_read+0x20a/0x2d0 [<0>] __vfs_read+0x13a/0x180 [<0>] vfs_read+0x8a/0x130 [<0>] ksys_read+0x4f/0xb0 [<0>] do_syscall_64+0x5b/0x170 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [<0>] 0x rafus# file -L exe exe: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=b247cedd3f8daaea3eee38477aa641d84b77f0ba, not stripped rafus# stat -L exe File: exe Size: 16832 Blocks: 40 IO Block: 4096 regular file Device: 1h/1d Inode: 13361 Links: 0 Access: (0777/-rwxrwxrwx) Uid: (0/root) Gid: (0/root) Access: 2018-08-26 17:17:37.334261924 +0200 Modify: 2018-08-26 17:14:27.787595262 +0200 Change: 2018-08-26 17:14:27.787595262 +0200 Birth: - rafus# sha1sum exe 723d59584abe5e1e9917f0ec41d7e9120514afe7 exe rafus# strings exe|grep bpf Started bpfilter I'm not actually sure what the process is, I'm guessing some kind of helper is spawned at some point during boot, and for some reason it never ends. Although I can reproduce it (it happens on every boot with a kernel 4.18 and CONFIG_BPFILTER=y), I'm unfortunately not sure what is actually needed to be done in order to trigger it. I don't use bpfilter myself/directly, as said this happens with the exact same system as with previous kernels, but I obviously have some network configuration (done using iptables/iproute2) set up during boot. Let me know if you need more information or need me to test things, and I'll do my best. Thank you. [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux
[PATCH] docs: networking: fix minor typos in various documentation files
This patch fixes some typos/misspelling errors in the
Documentation/networking files.
Signed-off-by: Olivier Gayot
---
Documentation/networking/6lowpan.txt | 4 ++--
Documentation/networking/gtp.txt | 4 ++--
Documentation/networking/ila.txt | 2 +-
Documentation/networking/ip-sysctl.txt | 2 +-
Documentation/networking/ipsec.txt | 4 ++--
Documentation/networking/ipvlan.txt | 4 ++--
Documentation/networking/kcm.txt | 10 +-
Documentation/networking/nf_conntrack-sysctl.txt | 2 +-
8 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/networking/6lowpan.txt
b/Documentation/networking/6lowpan.txt
index a7dc7e939c7a..2e5a939d7e6f 100644
--- a/Documentation/networking/6lowpan.txt
+++ b/Documentation/networking/6lowpan.txt
@@ -24,10 +24,10 @@ enum lowpan_lltypes.
Example to evaluate the private usually you can do:
-static inline sturct lowpan_priv_foobar *
+static inline struct lowpan_priv_foobar *
lowpan_foobar_priv(struct net_device *dev)
{
- return (sturct lowpan_priv_foobar *)lowpan_priv(dev)->priv;
+ return (struct lowpan_priv_foobar *)lowpan_priv(dev)->priv;
}
switch (dev->type) {
diff --git a/Documentation/networking/gtp.txt b/Documentation/networking/gtp.txt
index 0d9c18f05ec6..6966bbec1ecb 100644
--- a/Documentation/networking/gtp.txt
+++ b/Documentation/networking/gtp.txt
@@ -67,7 +67,7 @@ Don't be confused by terminology: The GTP User Plane goes
through
kernel accelerated path, while the GTP Control Plane goes to
Userspace :)
-The official homepge of the module is at
+The official homepage of the module is at
https://osmocom.org/projects/linux-kernel-gtp-u/wiki
== Userspace Programs with Linux Kernel GTP-U support ==
@@ -120,7 +120,7 @@ If yo have questions regarding how to use the Kernel GTP
module from
your own software, or want to contribute to the code, please use the
osmocom-net-grps mailing list for related discussion. The list can be
reached at osmocom-net-g...@lists.osmocom.org and the mailman
-interface for managign your subscription is at
+interface for managing your subscription is at
https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs
== Issue Tracker ==
diff --git a/Documentation/networking/ila.txt b/Documentation/networking/ila.txt
index 78df879abd26..a17dac9dc915 100644
--- a/Documentation/networking/ila.txt
+++ b/Documentation/networking/ila.txt
@@ -121,7 +121,7 @@ three options to deal with this:
- checksum neutral mapping
When an address is translated the difference can be offset
- elsewhere in a part of the packet that is covered by the
+ elsewhere in a part of the packet that is covered by
the checksum. The low order sixteen bits of the identifier
are used. This method is preferred since it doesn't require
parsing a packet beyond the IP header and in most cases the
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index 35ffaa281b26..92a91a025757 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -26,7 +26,7 @@ ip_no_pmtu_disc - INTEGER
discarded. Outgoing frames are handled the same as in mode 1,
implicitly setting IP_PMTUDISC_DONT on every created socket.
- Mode 3 is a hardend pmtu discover mode. The kernel will only
+ Mode 3 is a hardened pmtu discover mode. The kernel will only
accept fragmentation-needed errors if the underlying protocol
can verify them besides a plain socket lookup. Current
protocols for which pmtu events will be honored are TCP, SCTP
diff --git a/Documentation/networking/ipsec.txt
b/Documentation/networking/ipsec.txt
index 8dbc08b7e431..ba794b7e51be 100644
--- a/Documentation/networking/ipsec.txt
+++ b/Documentation/networking/ipsec.txt
@@ -25,8 +25,8 @@ Quote from RFC3173:
is implementation dependent.
Current IPComp implementation is indeed by the book, while as in practice
-when sending non-compressed packet to the peer(whether or not packet len
-is smaller than the threshold or the compressed len is large than original
+when sending non-compressed packet to the peer (whether or not packet len
+is smaller than the threshold or the compressed len is larger than original
packet len), the packet is dropped when checking the policy as this packet
matches the selector but not coming from any XFRM layer, i.e., with no
security path. Such naked packet will not eventually make it to upper layer.
diff --git a/Documentation/networking/ipvlan.txt
b/Documentation/networking/ipvlan.txt
index 812ef003e0a8..27a38e50c287 100644
--- a/Documentation/networking/ipvlan.txt
+++ b/Documentation/networking/ipvlan.txt
@@ -73,11 +73,11 @@ mode to make conn-tracking work.
This is the default option. To configure the IP
[PATCH] docs: ip-sysctl.txt: fix name of some ipv6 variables
The name of the following proc/sysctl entries were incorrectly documented: /proc/sys/net/ipv6/conf//max_dst_opts_number /proc/sys/net/ipv6/conf//max_hbt_opts_number /proc/sys/net/ipv6/conf//max_dst_opts_length /proc/sys/net/ipv6/conf//max_hbt_length Their name was set to the name of the symbol in the .data field of the control table instead of their .proc name. Signed-off-by: Olivier Gayot <olivier.ga...@sigexec.com> --- Documentation/networking/ip-sysctl.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 5dc1a040a2f1..b583a73cf95f 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1390,26 +1390,26 @@ mld_qrv - INTEGER Default: 2 (as specified by RFC3810 9.1) Minimum: 1 (as specified by RFC6636 4.5) -max_dst_opts_cnt - INTEGER +max_dst_opts_number - INTEGER Maximum number of non-padding TLVs allowed in a Destination options extension header. If this value is less than zero then unknown options are disallowed and the number of known TLVs allowed is the absolute value of this number. Default: 8 -max_hbh_opts_cnt - INTEGER +max_hbh_opts_number - INTEGER Maximum number of non-padding TLVs allowed in a Hop-by-Hop options extension header. If this value is less than zero then unknown options are disallowed and the number of known TLVs allowed is the absolute value of this number. Default: 8 -max dst_opts_len - INTEGER +max_dst_opts_length - INTEGER Maximum length allowed for a Destination options extension header. Default: INT_MAX (unlimited) -max hbh_opts_len - INTEGER +max_hbh_length - INTEGER Maximum length allowed for a Hop-by-Hop options extension header. Default: INT_MAX (unlimited) -- 2.17.0
Re: Bug w/ (policy) routing
On Mon, 2 Jan 2017 09:48:12 -0700 David Ahern <d...@cumulusnetworks.com> wrote: > On 1/1/17 12:52 PM, Olivier Brunel wrote: > > Indeed, if I first delete the rule for lookup local and recreate it > > w/ higher prio than my "lookup 50", then no more issue. > > After the unshare or when creating a new network namespace, bringing > the lo device up will create the local table and the rest of the > commands will work properly. ie., instead of moving the local rule > you can run: Indeed, and that's a much better solution for me, since I bring lo up anyways, I might as well do it first. Thank you. > unshare -n bash > > ip li set lo up > ip rule add table 50 prio 50 > ip link add test type veth peer name test2 > ... > > - > > Alex: > > The order of commands is influencing whether the unmerge succeeds or > not which is wrong. I took a quick look and I don't see a simple > solution to this. Effectively: > > Adding a rule before bringing up any interface does not unmerge the > tables: $ unshare -n bash > $ ip rule add table 50 prio 50 > $ ip li set lo up > > In fib_unmerge(), fib_new_table(net, RT_TABLE_LOCAL) returns null. > > > Where the reverse order works: > $ unshare -n bash > $ ip li set lo up > $ ip rule add table 50 prio 50 > > David
Re: Bug w/ (policy) routing
On Sat, 31 Dec 2016 13:15:44 -0700 David Ahern <d...@cumulusnetworks.com> wrote: > On 12/30/16 4:00 PM, Olivier Brunel wrote: > > Hi, > > > > (Please cc me as I'm not subscribed to the list, thanks.) > > > > I'm trying to set things up using some policy routing, and having > > some weird issues I can't really explain. It looks to me like there > > might be a bug somewhere... > > > > This is done under Arch Linux 64bits, iproute2 4.9.0 (`ip -V` says > > ip utility, iproute2-ss161212), kernel 4.8.13 > > > > Basically here's what I could reduce it to: > > - create a new network namespace, create a pair of veth devices: > > one in there, one sent back to the original namespace > > - I'm giving them IPs 10.4.0.1 (original namespace) & 10.4.0.2 (new > > namespace) > > - in that new namespace, I'm trying to add a route to 10.4.0.1, but > > inside a new table. I also want a default route via 10.4.0.1 on > > the table main. It seems to work, only not really... > > > > It's not very easy to describe so hopefully this will make things > > clearer: > > > > $ sudo unshare -n sh > > The main and local fib tables start merged into a single fib_table > instance. > > > sh-4.4# ip rule add table 50 prio 50 > > sh-4.4# ip link add test type veth peer name test2 > > sh-4.4# ip addr add 10.4.0.2 dev test > > sh-4.4# ip link set dev test up > > sh-4.4# ip link set netns 1 dev test2 > > # back in original namespace, we add 10.4.0.1 to test2 and bring it > > up > > > > sh-4.4# ip route add 10.4.0.1 dev test table 50 > > sh-4.4# ip route add default via 10.4.0.1 dev test > > sh-4.4# ip route flush cache > > sh-4.4# ip rule > > 0: from all lookup local > > 50: from all lookup 50 > > 32766: from all lookup main > > 32767: from all lookup default > > sh-4.4# ip route show table 50 > > 10.4.0.1 dev test scope link > > sh-4.4# ip route get 10.4.0.1 > > 10.4.0.1 via 10.4.0.1 dev test table local src 10.4.0.2 > > cache > > # !?? why isn't table 50 used as, I believe, it should. And why > > The default rule set has the local table at priority 0 so all lookups > hit that table first: > > # ip ru ls > 0:from all lookup local > 32766:from all lookup main > 32767:from all lookup default > > For some reason it hits a match doing the lookup in the merged > local/main fib_table for this ip route get. > > > does adding a rule "fixes" it : > > > > sh-4.4# ip rule add prio 5 > > Adding this rule causes the local and main tables to be split into > actual separate fib tables. Doing so causes the lookup in the local > table to fail, so the lookup continues to the next rule -- which is > your prio 50 table 50 rule. > > I did not look into why the earlier rule addition did not cause the > unmerge to happen -- it should have. Thanks, (I feel like) I understand what's happening now. > > sh-4.4# ip route get 10.4.0.1 > > 10.4.0.1 dev test table 50 src 10.4.0.2 > > cache > > # deleting the new rule makes no difference. It could even have been > > done right after adding it. It's like it just triggered something > > (reload, cache flushed, ...) > > As seen I did flush cached routes as mentionned in the man page, I > > don't know of anything else that would need done to "refresh" > > things? > > > > Any ideas as to why this is happening? Should this work as I expect > > it, or is there anything I'm doing wrong? > > For your purposes now this should fix the problem for you: > > ip ru del from all lookup local > ip ru add prio 32765 from all lookup local Indeed, if I first delete the rule for lookup local and recreate it w/ higher prio than my "lookup 50", then no more issue. Thanks a lot!
Bug w/ (policy) routing
Hi, (Please cc me as I'm not subscribed to the list, thanks.) I'm trying to set things up using some policy routing, and having some weird issues I can't really explain. It looks to me like there might be a bug somewhere... This is done under Arch Linux 64bits, iproute2 4.9.0 (`ip -V` says ip utility, iproute2-ss161212), kernel 4.8.13 Basically here's what I could reduce it to: - create a new network namespace, create a pair of veth devices: one in there, one sent back to the original namespace - I'm giving them IPs 10.4.0.1 (original namespace) & 10.4.0.2 (new namespace) - in that new namespace, I'm trying to add a route to 10.4.0.1, but inside a new table. I also want a default route via 10.4.0.1 on the table main. It seems to work, only not really... It's not very easy to describe so hopefully this will make things clearer: $ sudo unshare -n sh sh-4.4# ip rule add table 50 prio 50 sh-4.4# ip link add test type veth peer name test2 sh-4.4# ip addr add 10.4.0.2 dev test sh-4.4# ip link set dev test up sh-4.4# ip link set netns 1 dev test2 # back in original namespace, we add 10.4.0.1 to test2 and bring it up sh-4.4# ip route add 10.4.0.1 dev test table 50 sh-4.4# ip route add default via 10.4.0.1 dev test sh-4.4# ip route flush cache sh-4.4# ip rule 0: from all lookup local 50: from all lookup 50 32766: from all lookup main 32767: from all lookup default sh-4.4# ip route show table 50 10.4.0.1 dev test scope link sh-4.4# ip route get 10.4.0.1 10.4.0.1 via 10.4.0.1 dev test table local src 10.4.0.2 cache # !?? why isn't table 50 used as, I believe, it should. And why does adding a rule "fixes" it : sh-4.4# ip rule add prio 5 sh-4.4# ip route get 10.4.0.1 10.4.0.1 dev test table 50 src 10.4.0.2 cache # deleting the new rule makes no difference. It could even have been done right after adding it. It's like it just triggered something (reload, cache flushed, ...) As seen I did flush cached routes as mentionned in the man page, I don't know of anything else that would need done to "refresh" things? Any ideas as to why this is happening? Should this work as I expect it, or is there anything I'm doing wrong? Thanks,
Re: [PATCH] hso: fix refcnt leak in recent patch.
On Tue, Apr 14, 2015 at 11:03:03AM +1000, NeilBrown wrote:
On Tue, 14 Apr 2015 09:36:34 +1000 NeilBrown ne...@suse.de wrote:
Prior to
commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
hso: fix crash when device disappears while serial port is open
hso_serial_open would always kref_get(serial-parent-ref) before
returning zero.
Since that commit, it only calls kref_get when returning 0 if
serial-port.count was zero.
This results in calls to
kref_put(serial-parent-ref, hso_serial_ref_free);
after hso_serial_ref_free has been called, which dereferences a freed
pointer.
This patch adds the missing kref_get().
Fixes: commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
Cc: sta...@vger.kernel.org (v4.0)
Cc: Olivier Sobrie oliv...@sobrie.be
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 75befc1bd816..6848fc903340 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1299,6 +1299,7 @@ static int hso_serial_open(struct tty_struct *tty,
struct file *filp)
}
} else {
D1(Port was already open);
+ kref_get(serial-parent-ref);
}
usb_autopm_put_interface(serial-parent-interface);
Sorry - that was wrong.
I'm getting crashes which strongly suggest the kref_put is being called extra
times, but I misunderstood the code and was hasty.
Maybe this instead?
I tested the patch and it looks fine :-)
Thank you,
Olivier
Thanks,
NeilBrown
From: NeilBrown n...@brown.name
Date: Tue, 14 Apr 2015 09:33:03 +1000
Subject: [PATCH] hso: fix refcnt leak in recent patch.
Prior to
commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
hso: fix crash when device disappears while serial port is open
a kref_get on serial-parent-ref would be taken on each open,
and it would be kref_put on each close.
Now the kref_put happens when the tty_struct is finally put (via
the 'cleanup') providing tty-driver_data has been set.
So the kref_get must be called exact once when tty-driver_data is
set.
With the current code, if the first open fails the kref_get() is never
called, but the kref_put() is called, leaving to a crash.
So change the kref_get call to happen exactly when -driver_data is
changed from NULL to non-NULL.
Fixes: commit 29bd3bc1194c624ce863cab2a7da9bc1f0c3b47b
Cc: sta...@vger.kernel.org (v4.0)
Cc: Olivier Sobrie oliv...@sobrie.be
Tested-by: Olivier Sobrie oliv...@sobrie.be
Signed-off-by: NeilBrown n...@brown.name
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 75befc1bd816..17fd3820263a 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -1278,6 +1278,8 @@ static int hso_serial_open(struct tty_struct *tty,
struct file *filp)
D1(Opening %d, serial-minor);
/* setup */
+ if (tty-driver_data == NULL)
+ kref_get(serial-parent-ref);
tty-driver_data = serial;
tty_port_tty_set(serial-port, tty);
@@ -1294,8 +1296,6 @@ static int hso_serial_open(struct tty_struct *tty,
struct file *filp)
if (result) {
hso_stop_serial_device(serial-parent);
serial-port.count--;
- } else {
- kref_get(serial-parent-ref);
}
} else {
D1(Port was already open);
--
Olivier
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: Totally unrelated indeed so why are spouting crap? If the kohab list has a problem take it up with them but keep ALSA out of it. alsa-devel has only ever moderated out spam -- nothing else. That is incorrect. Hopefully it is the case now though, since my experience of the subject was years ago. OG. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: [1] What kind of latency would be allowed? Would an implementation be allowed to power up the phy say once per minute or once per 5 minutes to see if there is link? The implementation could do this progressively; first poll every X seconds, then after an hour, every minute etc. I suspect that the hard maximum latency is the time needed by the user to start the network himself, be it opening a root xterm and doing the appropriate invocation or pulling up and clicking where appropriate in a GUI. That's probably around 5 seconds. Over that, and they won't even notice there is an autodetection running. But still, 5 seconds is probably too much too, because it's going to look like it's unreliable. The user has to see something happen within half-a-second or so, otherwise he's going to start doing it by hand. The see part is distribution/desktop-dependant and not the kernel problem, but the top chrono happens when the rj45 is plugged in. OG. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote: 5 seconds is unfair and unrealistic though. The *hardware* negotiation before link is seen can easily take upto 45 seconds already. That's a network topology/hardware issue (spanning tree fun) that software or even the hardware in your PC can do nothing about. It's about ergonomics, not technical capabilities or fairness. this means that the power up time needs to be at least 45 seconds, if it's then down 5 seconds inbetween... that's not real power savings. Then that means you can't have usable autodetection and power savings at the same time. That's a pefectly acceptable answer, you just have to give the choice between the two to the user. From the kernel p.o.v, it just means that you probably need 3 modes: 1- active and exchanging packets 2- inactive but waiting for plugging and able to tell something is going on fast (like 0.5s fast) 3- powered off and they probably already exist (UP+addr/procmisc. set, UP and DOWN). And if the second mode can't be lower power than the first, that's just life. An hypothetical mode 4 identical to 2 without the fast part is just not worth bothering with. OG. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Offloading features in VLAN interfaces
Hi, after running some experiments, we realised that using VLAN support in Linux caused some overhead. It turned out to be that the offloading features of our NIC (tso, sg, checksum offloading) were not beeing used. After digging a little bit in the code, we realised that the VLAN code did not set the features parameter of the net_device structure for the virtual interface. Attached is a patch with a suggested solution to this problem. Please let us know if this is an acceptable patch. Thanks, Olivier Crameri, HP Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Offloading features in VLAN interfaces
Same thing but with the patch this time. Sorry about that, Olivier Crameri On 9/29/06, Olivier Crameri [EMAIL PROTECTED] wrote: Hi, after running some experiments, we realised that using VLAN support in Linux caused some overhead. It turned out to be that the offloading features of our NIC (tso, sg, checksum offloading) were not beeing used. After digging a little bit in the code, we realised that the VLAN code did not set the features parameter of the net_device structure for the virtual interface. Attached is a patch with a suggested solution to this problem. Please let us know if this is an acceptable patch. Thanks, Olivier Crameri, HP Labs vlan.patch Description: Binary data
Re: [PATCH 1/5] new pcmcia IDs for hostap - ASUS WL-110
Jean Tourrilhes [EMAIL PROTECTED] writes: The overall architecture of hotplug/udev module loading is broken as it does not allow user override. I have explained in details the problem to the concerned people, but it seems that they don't really care. The standard answer is blacklist the orinoco module. Let's not even mention libusual. You can also have a local alias overriding in a /etc/modprobe.d/ file, for example: alias pcmcia:m02AAc0002f*fn*pfn*pa*pb*pc*pd* hostap_cs modprobe will use this alias only, since it doesn't look in module.alias if the alias is resolved before. This allows to override the driver for a specific card, without blacklisting a driver still usable with a whole number of cards. Regards -- Olivier Blin - Mandriva - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dscape ieee80211: enabling/disabling the radio
2006/5/10, Michael Wu [EMAIL PROTECTED]: On Tuesday 09 May 2006 18:01, Ivo van Doorn wrote: A user on the forums Olivier Cornu (added to the CC list) has done some investigation into the scanning behaviour of the dscape stack. Basicly the dscape stack is performing active scanning while the device is down, but during the active scan it is sending packets out, or at least attempting to do so. Besides the question if active scanning is preferred over passive scanning while interface is down, active scanning fails because the packets that should be send are being send through the regular xmit routines of the interface. (IFF_UP is not set for the interface) This means that besides enabling the radio which should be done in the driver, the stack should either bring up the interface when doing an active scan, or resort to passive scanning while interface is down. If you can passive scan while the interface is down, I don't think it's really down. In adm8211, nothing can be sent or received when the interface is down. The radio is always off when the interface is down. Taking the interface up just for a scan and then taking it back down doesn't sound too good either. I think scans should be prohibited while the interface is down, since leaving the interface on isn't gonna do anything bad unless you put in the info to associate. -Michael Wu What do you mean exactly by device is down, but not really down? I thought a network device was called down when the IFF_UP flag of its net_device struct was set to 0 (thus not appearing in ifconfig, among other things). Is there any other alternative understanding of it being down i'm not aware of? I confirm scanning actively with the device down is possible using another NIC/driver. Thus I guess it's normal behaviour. I still have to figure out how to do it using the dscape 802.11 stack (if it's actually possible)... Olivier Cornu - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless: recap of current issues (stack)
Jean Tourrilhes [EMAIL PROTECTED] writes: Please consider this page about drakroam and net_applet as well: http://qa.mandriva.com/twiki/bin/view/Main/EasyWifi NetApplet was already on my page, but thanks to you I've checked it and it's now 404. Well, assuming your netapplet is the same/continuation of the netapplet from Robert Love Joe Shaw, and not something totally different using the same name. I'll update that. Nope, it's not the same project. Our net_applet was born only a bit earlier, though it didn't support wireless at this time. Thanks -- Olivier Blin - Mandriva - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
