* Re: Refactor Netlink connector?
From: Evgeniy Polyakov @ 2006-05-30 19:09 UTC (permalink / raw)
To: James Morris; +Cc: netdev, David S. Miller, tgraf, Stephen Smalley
In-Reply-To: <Pine.LNX.4.64.0605301453360.28036@d.namei>
On Tue, May 30, 2006 at 02:58:11PM -0400, James Morris (jmorris@namei.org) wrote:
> > Apache still can setup routes using ioctl or execve("ip route add/route
> > add");
>
> Depends on the policy. You can specify which types of files/sockets
> apache can perform ioctl on, and whether it can execve 'ip', and if so,
> which security context that runs in, and then whether that security
> context can add routes.
With applications like phpmmyadmin apache must be allowed to perform such
operations no matter hacked it is or not...
> Security in SELinux is not based on the name of the application, it's
> based on the security label bound to the binary being executed.
I know how selinux works.
I see your point, selinux is supposed to control each datflow even if it
sometimes is not that good idea.
> > Anyway you can easily add lsm hook into both sending/receiving pathes in
> > connector code, it fully controls the traffic before it reached socket
> > queue or user's callback.
>
> There are already LSM hooks which allow this, it's a matter of not wanting
> to have to parse arbitrarily implemented Netlink protocols to determine
> what the messages are.
I mean you can control messages based on cn_mcg->id structure, since
cn_msg is a header for all connector messages.
> - James
> --
> James Morris
> <jmorris@namei.org>
--
Evgeniy Polyakov
^ permalink raw reply
* Re: Refactor Netlink connector?
From: James Morris @ 2006-05-30 18:58 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, David S. Miller, tgraf, Stephen Smalley
In-Reply-To: <20060530180300.GA10293@2ka.mipt.ru>
On Tue, 30 May 2006, Evgeniy Polyakov wrote:
> On Tue, May 30, 2006 at 10:18:32AM -0400, James Morris (jmorris@namei.org) wrote:
> > > And, btw, what is the purpose of controlling netlink messages?
> > > Does it prevent malicious userspace application to receive events from
> > > malicious kernel module?
> >
> > It provides control over which types of applications can send and receive
> > different types of Netlink messages. e.g. you can specify that Apache can
> > read the routing table but not write to it.
>
> Apache still can setup routes using ioctl or execve("ip route add/route
> add");
Depends on the policy. You can specify which types of files/sockets
apache can perform ioctl on, and whether it can execve 'ip', and if so,
which security context that runs in, and then whether that security
context can add routes.
Security in SELinux is not based on the name of the application, it's
based on the security label bound to the binary being executed.
> Anyway you can easily add lsm hook into both sending/receiving pathes in
> connector code, it fully controls the traffic before it reached socket
> queue or user's callback.
There are already LSM hooks which allow this, it's a matter of not wanting
to have to parse arbitrarily implemented Netlink protocols to determine
what the messages are.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: 2.6.17-rc5-mm1
From: Michal Piotrowski @ 2006-05-30 18:51 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: netdev, linux-kernel, Andrew Morton, mingo
In-Reply-To: <1149005329.3636.78.camel@laptopd505.fenrus.org>
Hi Arjan,
On 30/05/06, Arjan van de Ven <arjan@linux.intel.com> wrote:
> On Tue, 2006-05-30 at 17:59 +0200, Michal Piotrowski wrote:
> > Hi,
> >
> > On 30/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
> > >
> > >
> >
> > It looks like a network stack problem.
> >
> > May 30 17:50:34 ltg01-fedora init: Switching to runlevel: 6
> > May 30 17:50:35 ltg01-fedora avahi-daemon[1878]: Got SIGTERM, quitting.
> > May 30 17:50:35 ltg01-fedora avahi-daemon[1878]: Leaving mDNS
> > multicast group on interface eth0.IPv4 with address 192.168.0.
> > 14.
> > May 30 17:50:35 ltg01-fedora kernel:
> > May 30 17:50:35 ltg01-fedora kernel: ======================================
> > May 30 17:50:35 ltg01-fedora kernel: [ BUG: bad unlock ordering detected! ]
> > May 30 17:50:35 ltg01-fedora kernel: --------------------------------------
> > May 30 17:50:35 ltg01-fedora kernel: avahi-daemon/1878 is trying to
>
> does this fix it for you?
Yes, thanks.
> Mark out of order unlocking in igmp.c as such
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply
* Re: avahi error: IP_ADD_MEMBERSHIP failed: No buffer space available
From: Stefan Rompf @ 2006-05-30 18:34 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <447C89F3.5040909@candelatech.com>
Am Dienstag 30 Mai 2006 20:07 schrieb Ben Greear:
> May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on
> inter face eth2#18.IPv4 with address 172.1.2.20.
> May 30 11:01:37 x64-1u avahi-daemon[2022]: IP_ADD_MEMBERSHIP failed: No
> buffer s pace available
there is a configurable limit of system wide multicast memberships. As you're
the guy who creates gazillions of VLAN interfaces, you will surely hit it.
Check /proc/sys/net/ipv4/igmp_max_memberships. (This is also relevant for
people running OSPF over many VLANs).
Stefan
^ permalink raw reply
* Re: skge driver oops
From: Stephen Hemminger @ 2006-05-30 18:25 UTC (permalink / raw)
To: Beschorner Daniel
Cc: 'Krzysztof Oledzki', netdev, 'david@mantara.com'
In-Reply-To: <BB1F4EFD574E9F409035BDA71C9612500241B7@exchange.i-bn>
On Mon, 29 May 2006 19:54:01 +0200
Beschorner Daniel <Daniel.Beschorner@facton.com> wrote:
> Hi Stephen,
>
> the patch doesn't help.
> As soon as the card is receiving lots of data, the box crashes after some
> seconds.
> Testing these patches is very tricky for me, as it is a production system at
> a remote location crashing on every test.
>
> It's a D-Link card, ID 4C00 (530T), SysKonnect's driver is working fine.
I assume you sk98lin version downloaded from their web site.
^ permalink raw reply
* Re: Refactor Netlink connector?
From: Evgeniy Polyakov @ 2006-05-30 18:03 UTC (permalink / raw)
To: James Morris; +Cc: netdev, David S. Miller, tgraf, Stephen Smalley
In-Reply-To: <Pine.LNX.4.64.0605301015090.25929@d.namei>
On Tue, May 30, 2006 at 10:18:32AM -0400, James Morris (jmorris@namei.org) wrote:
> > And, btw, what is the purpose of controlling netlink messages?
> > Does it prevent malicious userspace application to receive events from
> > malicious kernel module?
>
> It provides control over which types of applications can send and receive
> different types of Netlink messages. e.g. you can specify that Apache can
> read the routing table but not write to it.
Apache still can setup routes using ioctl or execve("ip route add/route
add");
Anyway you can easily add lsm hook into both sending/receiving pathes in
connector code, it fully controls the traffic before it reached socket
queue or user's callback.
> - James
> --
> James Morris
> <jmorris@namei.org>
--
Evgeniy Polyakov
^ permalink raw reply
* avahi error: IP_ADD_MEMBERSHIP failed: No buffer space available
From: Ben Greear @ 2006-05-30 18:07 UTC (permalink / raw)
To: NetDev
This is an FC5 64-bit system with 1GB RAM and dual-core Opteron.
When I create a bunch of virtual interfaces, I see this in
/var/log/messages. The kernel is 2.6.16.16 plus my hacks.
At first look, it doesn't appear I actually need the avahi tool, so
I'm just going to disable it. But, I thought someone might
want to be aware of the problem...
May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on inter
face eth2#16.IPv4 with address 172.1.2.18.
May 30 11:01:37 x64-1u avahi-daemon[2022]: Registering new address record for 17
2.1.2.18 on eth2#16.
May 30 11:01:37 x64-1u avahi-daemon[2022]: New relevant interface eth2#17.IPv4 f
or mDNS.
May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on inter
face eth2#17.IPv4 with address 172.1.2.19.
May 30 11:01:37 x64-1u avahi-daemon[2022]: IP_ADD_MEMBERSHIP failed: No buffer s
pace available
May 30 11:01:37 x64-1u avahi-daemon[2022]: Registering new address record for 17
2.1.2.19 on eth2#17.
May 30 11:01:37 x64-1u avahi-daemon[2022]: New relevant interface eth2#18.IPv4 f
or mDNS.
May 30 11:01:37 x64-1u avahi-daemon[2022]: Joining mDNS multicast group on inter
face eth2#18.IPv4 with address 172.1.2.20.
May 30 11:01:37 x64-1u avahi-daemon[2022]: IP_ADD_MEMBERSHIP failed: No buffer s
pace available
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] tcp probe connection tracing
From: Stephen Hemminger @ 2006-05-30 17:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Since there seems to be lots of interest in TCP congestion control, here
is a cleaned up version of my TCP congestion tracker. I will put in the
TCP git tree for 2.6.18
----
This adds a new module for tracking TCP state variables non-intrusively
using kprobes. It has a simple /proc interface that outputs one line
for each packet received. A sample usage is to collect congestion
window and ssthresh over time graphs.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
---
net/Kconfig | 15 ++++
net/ipv4/Makefile | 1
net/ipv4/tcp_probe.c | 179 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 195 insertions(+), 0 deletions(-)
create mode 100644 net/ipv4/tcp_probe.c
f62dd92bdf3b6be5904c1ba347fa21f0f2deccda
diff --git a/net/Kconfig b/net/Kconfig
index 4193cdc..ff0db80 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -215,6 +215,21 @@ config NET_PKTGEN
To compile this code as a module, choose M here: the
module will be called pktgen.
+config NET_TCPPROBE
+ tristate "TCP connection probing"
+ depends on INET && EXPERIMENTAL && PROC_FS && KPROBES
+ ---help---
+ This module allows for capturing the changes to TCP connection
+ state in response to incoming patckets. It is used for debugging
+ TCP congestion avoidance modules. If you don't understand
+ what was just said, you don't need it: say N.
+
+ Documentation on how to use the packet generator can be found
+ at http://linux-net.osdl.org/index.php/TcpProbe
+
+ To compile this code as a module, choose M here: the
+ module will be called tcp_probe.
+
endmenu
endmenu
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index 65ab5ba..ac7eb0e 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IP_VS) += ipvs/
obj-$(CONFIG_INET_DIAG) += inet_diag.o
obj-$(CONFIG_IP_ROUTE_MULTIPATH_CACHED) += multipath.o
obj-$(CONFIG_INET_TCP_DIAG) += tcp_diag.o
+obj-$(CONFIG_NET_TCPPROBE) += tcp_probe.o
obj-$(CONFIG_TCP_CONG_BIC) += tcp_bic.o
obj-$(CONFIG_TCP_CONG_CUBIC) += tcp_cubic.o
obj-$(CONFIG_TCP_CONG_WESTWOOD) += tcp_westwood.o
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
new file mode 100644
index 0000000..0bb8c5b
--- /dev/null
+++ b/net/ipv4/tcp_probe.c
@@ -0,0 +1,179 @@
+/*
+ * tcpprobe - Observe the TCP flow with kprobes.
+ *
+ * The idea for this came from Werner Almesberger's umlsim
+ * Copyright (C) 2004, Stephen Hemminger <shemminger@osdl.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/socket.h>
+#include <linux/tcp.h>
+#include <linux/proc_fs.h>
+#include <linux/module.h>
+#include <linux/kfifo.h>
+#include <linux/vmalloc.h>
+
+#include <net/tcp.h>
+
+MODULE_AUTHOR("Stephen Hemminger <shemminger@osdl.org>");
+MODULE_DESCRIPTION("TCP cwnd snooper");
+MODULE_LICENSE("GPL");
+
+static int port = 0;
+MODULE_PARM_DESC(port, "Port to match (0=all)");
+module_param(port, int, 0);
+
+static int bufsize = 64*1024;
+MODULE_PARM_DESC(bufsize, "Log buffer size (default 64k)");
+module_param(bufsize, int, 0);
+
+static const char procname[] = "tcpprobe";
+
+struct {
+ struct kfifo *fifo;
+ spinlock_t lock;
+ wait_queue_head_t wait;
+ struct timeval tstart;
+} tcpw;
+
+static void printl(const char *fmt, ...)
+{
+ va_list args;
+ int len;
+ struct timeval now;
+ char tbuf[256];
+
+ va_start(args, fmt);
+ do_gettimeofday(&now);
+
+ now.tv_sec -= tcpw.tstart.tv_sec;
+ now.tv_usec -= tcpw.tstart.tv_usec;
+ if (now.tv_usec < 0) {
+ --now.tv_sec;
+ now.tv_usec += 1000000;
+ }
+
+ len = sprintf(tbuf, "%lu.%06lu ", now.tv_sec, now.tv_usec);
+ len += vscnprintf(tbuf+len, sizeof(tbuf)-len, fmt, args);
+ va_end(args);
+
+ kfifo_put(tcpw.fifo, tbuf, len);
+ wake_up(&tcpw.wait);
+}
+
+static int jtcp_sendmsg(struct kiocb *iocb, struct sock *sk,
+ struct msghdr *msg, size_t size)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ const struct inet_sock *inet = inet_sk(sk);
+
+ if (port == 0 || ntohs(inet->dport) == port ||
+ ntohs(inet->sport) == port) {
+ printl("%d.%d.%d.%d:%u %d.%d.%d.%d:%u %d %#x %#x %u %u %u\n",
+ NIPQUAD(inet->saddr), ntohs(inet->sport),
+ NIPQUAD(inet->daddr), ntohs(inet->dport),
+ size, tp->snd_nxt, tp->snd_una,
+ tp->snd_cwnd, tcp_current_ssthresh(sk),
+ tp->snd_wnd);
+ }
+
+ jprobe_return();
+ return 0;
+}
+
+static struct jprobe tcp_send_probe = {
+ .kp = { .addr = (kprobe_opcode_t *) &tcp_sendmsg, },
+ .entry = (kprobe_opcode_t *) &jtcp_sendmsg,
+};
+
+
+static int tcpprobe_open(struct inode * inode, struct file * file)
+{
+ kfifo_reset(tcpw.fifo);
+ do_gettimeofday(&tcpw.tstart);
+ return 0;
+}
+
+static ssize_t tcpprobe_read(struct file *file, char __user *buf,
+ size_t len, loff_t *ppos)
+{
+ int error = 0, cnt;
+ unsigned char *tbuf;
+
+ if (!buf || len < 0)
+ return -EINVAL;
+
+ if (len == 0)
+ return 0;
+
+ tbuf = vmalloc(len);
+ if (!tbuf)
+ return -ENOMEM;
+
+ error = wait_event_interruptible(tcpw.wait,
+ __kfifo_len(tcpw.fifo) != 0);
+ if (error)
+ return error;
+
+ cnt = kfifo_get(tcpw.fifo, tbuf, len);
+ error = copy_to_user(buf, tbuf, cnt);
+
+ vfree(tbuf);
+
+ return error ? error : cnt;
+}
+
+static struct file_operations tcpprobe_fops = {
+ .owner = THIS_MODULE,
+ .open = tcpprobe_open,
+ .read = tcpprobe_read,
+};
+
+static __init int tcpprobe_init(void)
+{
+ int ret = -ENOMEM;
+
+ init_waitqueue_head(&tcpw.wait);
+ spin_lock_init(&tcpw.lock);
+ tcpw.fifo = kfifo_alloc(bufsize, GFP_KERNEL, &tcpw.lock);
+
+ if (!proc_net_fops_create(procname, S_IRUSR, &tcpprobe_fops))
+ goto err0;
+
+ ret = register_jprobe(&tcp_send_probe);
+ if (ret)
+ goto err1;
+
+ pr_info("TCP watch registered (port=%d)\n", port);
+ return 0;
+ err1:
+ proc_net_remove(procname);
+ err0:
+ kfifo_free(tcpw.fifo);
+ return ret;
+}
+module_init(tcpprobe_init);
+
+static __exit void tcpprobe_exit(void)
+{
+ kfifo_free(tcpw.fifo);
+ proc_net_remove(procname);
+ unregister_jprobe(&tcp_send_probe);
+
+}
+module_exit(tcpprobe_exit);
--
1.3.3
^ permalink raw reply related
* [PATCH] Changes to ieee80211.h for user space regulatory daemon
From: Larry Finger @ 2006-05-30 16:55 UTC (permalink / raw)
To: netdev, John Linville
Attached are two small patches for include/net/ieee80211.h to prepare for later submission of code
to implement a user-space daemon that supplies 802.11 regulatory information.
The first change adds a bit indicating that 802.11h rules are to be applied to a channel. As
discussed earlier in this list, a single bit is unlikely to be sufficient; however, at this time I
have been unable to find any regulations implementing differences between 802.11a and 802.11h other
than DFS, radar detection and passive scanning. A single bit is thus sufficient to convey to the
driver that these rules should be obeyed.
The second change adds comments to the freq and max_power fields of struct ieee80211_channel to
indicate the units that are used.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
index 293e920..6a2f60c 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -968,6 +968,7 @@ #define IEEE80211_52GHZ_CHANNELS (IEEE80
enum {
IEEE80211_CH_PASSIVE_ONLY = (1 << 0),
+ IEEE80211_CH_80211H_RULES = (1 << 1),
IEEE80211_CH_B_ONLY = (1 << 2),
IEEE80211_CH_NO_IBSS = (1 << 3),
IEEE80211_CH_UNIFORM_SPREADING = (1 << 4),
@@ -976,10 +977,10 @@ enum {
};
struct ieee80211_channel {
- u32 freq;
+ u32 freq; /* in MHz */
u8 channel;
u8 flags;
- u8 max_power;
+ u8 max_power; /* in dBm */
};
struct ieee80211_geo {
^ permalink raw reply related
* Re: zd1201 & ipw2200 problems
From: Greg KH @ 2006-05-30 16:24 UTC (permalink / raw)
To: Pavel Machek; +Cc: Netdev list, Jirka Lenost Benc, kernel list
In-Reply-To: <20060530144742.GC27794@elf.ucw.cz>
On Tue, May 30, 2006 at 04:47:42PM +0200, Pavel Machek wrote:
> Hi!
>
> > > I see some strange problems with zd1201. (Ccing greg, he seen
> > > something similar).
> >
> > Which zd1201 driver are you using?
>
> In-tree one, 2.6.17-rc4 (and around). Ouch and I've "solved" the
> zaurus problme in the meantime -- it was hw one.
Oops, sorry, I was thinking of the zd1211 driver, which is still not in
the kernel tree and there are a few different versions floating around.
Glad it's working for you now.
greg k-h
^ permalink raw reply
* Re: [patch, -rc5-mm1] lock validator: remove softirq.c WARN_ON
From: Alexey Kuznetsov @ 2006-05-30 16:15 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Ingo Molnar, Jiri Slaby, Andrew Morton, linux-kernel, jgarzik,
netdev, alan
In-Reply-To: <1149005130.3636.75.camel@laptopd505.fenrus.org>
Hello!
> > static void netlink_table_grab(void)
> > {
> > write_lock_bh(&nl_table_lock);
>
> well it could be this one as well...
Indeed.
But it still looks as something very strange.
There are some GFP_KERNEL allocations on the way to this function.
^ permalink raw reply
* Re: 2.6.17-rc5-mm1
From: Arjan van de Ven @ 2006-05-30 16:08 UTC (permalink / raw)
To: Michal Piotrowski; +Cc: netdev, linux-kernel, Andrew Morton, mingo
In-Reply-To: <6bffcb0e0605300859x5c8f83f5w635fd25f0100fca@mail.gmail.com>
On Tue, 2006-05-30 at 17:59 +0200, Michal Piotrowski wrote:
> Hi,
>
> On 30/05/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
> >
> >
>
> It looks like a network stack problem.
>
> May 30 17:50:34 ltg01-fedora init: Switching to runlevel: 6
> May 30 17:50:35 ltg01-fedora avahi-daemon[1878]: Got SIGTERM, quitting.
> May 30 17:50:35 ltg01-fedora avahi-daemon[1878]: Leaving mDNS
> multicast group on interface eth0.IPv4 with address 192.168.0.
> 14.
> May 30 17:50:35 ltg01-fedora kernel:
> May 30 17:50:35 ltg01-fedora kernel: ======================================
> May 30 17:50:35 ltg01-fedora kernel: [ BUG: bad unlock ordering detected! ]
> May 30 17:50:35 ltg01-fedora kernel: --------------------------------------
> May 30 17:50:35 ltg01-fedora kernel: avahi-daemon/1878 is trying to
does this fix it for you?
Mark out of order unlocking in igmp.c as such
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
net/ipv4/igmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc5-mm1-lockdep/net/ipv4/igmp.c
===================================================================
--- linux-2.6.17-rc5-mm1-lockdep.orig/net/ipv4/igmp.c
+++ linux-2.6.17-rc5-mm1-lockdep/net/ipv4/igmp.c
@@ -1472,7 +1472,7 @@ static int ip_mc_del_src(struct in_devic
return -ESRCH;
}
spin_lock_bh(&pmc->lock);
- read_unlock(&in_dev->mc_list_lock);
+ read_unlock_non_nested(&in_dev->mc_list_lock);
#ifdef CONFIG_IP_MULTICAST
sf_markstate(pmc);
#endif
^ permalink raw reply
* Re: [patch, -rc5-mm1] lock validator: remove softirq.c WARN_ON
From: Arjan van de Ven @ 2006-05-30 16:05 UTC (permalink / raw)
To: Alexey Kuznetsov
Cc: Ingo Molnar, Jiri Slaby, Andrew Morton, linux-kernel, jgarzik,
netdev, alan
In-Reply-To: <20060530160024.GA8987@ms2.inr.ac.ru>
On Tue, 2006-05-30 at 20:00 +0400, Alexey Kuznetsov wrote:
> Hello!
>
> > ok, that WARN_ON is over-eager. Fix is below:
>
> Nevertheless, I cannot figure out what's happening here.
>
> This local_bh_disable() is called right after schedule().
> No way irqs can be disabled there. What is wrong?
>
>
> static void netlink_table_grab(void)
> {
> write_lock_bh(&nl_table_lock);
well it could be this one as well...
>
> if (atomic_read(&nl_table_users)) {
^ permalink raw reply
* Re: [patch, -rc5-mm1] lock validator: remove softirq.c WARN_ON
From: Alexey Kuznetsov @ 2006-05-30 16:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jiri Slaby, Andrew Morton, linux-kernel, jgarzik, netdev, alan
In-Reply-To: <20060530115545.GA7025@elte.hu>
Hello!
> ok, that WARN_ON is over-eager. Fix is below:
Nevertheless, I cannot figure out what's happening here.
This local_bh_disable() is called right after schedule().
No way irqs can be disabled there. What is wrong?
static void netlink_table_grab(void)
{
write_lock_bh(&nl_table_lock);
if (atomic_read(&nl_table_users)) {
DECLARE_WAITQUEUE(wait, current);
add_wait_queue_exclusive(&nl_table_wait, &wait);
for(;;) {
set_current_state(TASK_UNINTERRUPTIBLE);
if (atomic_read(&nl_table_users) == 0)
break;
write_unlock_bh(&nl_table_lock);
schedule();
write_lock_bh(&nl_table_lock);
}
__set_current_state(TASK_RUNNING);
remove_wait_queue(&nl_table_wait, &wait);
}
}
Alexey
^ permalink raw reply
* Re: 2.6.17-rc5-mm1
From: Michal Piotrowski @ 2006-05-30 15:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev
In-Reply-To: <20060530022925.8a67b613.akpm@osdl.org>
Hi,
On 30/05/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
>
>
It looks like a network stack problem.
May 30 17:50:34 ltg01-fedora init: Switching to runlevel: 6
May 30 17:50:35 ltg01-fedora avahi-daemon[1878]: Got SIGTERM, quitting.
May 30 17:50:35 ltg01-fedora avahi-daemon[1878]: Leaving mDNS
multicast group on interface eth0.IPv4 with address 192.168.0.
14.
May 30 17:50:35 ltg01-fedora kernel:
May 30 17:50:35 ltg01-fedora kernel: ======================================
May 30 17:50:35 ltg01-fedora kernel: [ BUG: bad unlock ordering detected! ]
May 30 17:50:35 ltg01-fedora kernel: --------------------------------------
May 30 17:50:35 ltg01-fedora kernel: avahi-daemon/1878 is trying to
release lock (&in_dev->mc_list_lock) at:
May 30 17:50:35 ltg01-fedora kernel: [<c02e693b>] ip_mc_del_src+0x5e/0xd5
May 30 17:50:35 ltg01-fedora kernel: but the next lock to release is:
May 30 17:50:35 ltg01-fedora kernel: (&im->lock){-...}, at:
[<c02e6934>] ip_mc_del_src+0x57/0xd5
May 30 17:50:35 ltg01-fedora kernel:
May 30 17:50:35 ltg01-fedora kernel: other info that might help us debug this:
May 30 17:50:35 ltg01-fedora kernel: 2 locks held by avahi-daemon/1878:
May 30 17:50:35 ltg01-fedora kernel: #0: (rtnl_mutex){--..}, at:
[<c02f0b0f>] mutex_lock+0x1c/0x1f
May 30 17:50:35 ltg01-fedora kernel: #1:
(&in_dev->mc_list_lock){-.-?}, at: [<c02e6905>]
ip_mc_del_src+0x28/0xd5
May 30 17:50:35 ltg01-fedora kernel:
May 30 17:50:35 ltg01-fedora kernel: stack backtrace:
May 30 17:50:35 ltg01-fedora kernel: [<c0103e52>] show_trace_log_lvl+0x4b/0xf4
May 30 17:50:35 ltg01-fedora kernel: [<c01044b3>] show_trace+0xd/0x10
May 30 17:50:35 ltg01-fedora kernel: [<c010457b>] dump_stack+0x19/0x1b
May 30 17:50:35 ltg01-fedora kernel: [<c0139bfa>] lockdep_release+0x18b/0x350
May 30 17:50:35 ltg01-fedora kernel: [<c02f2640>] _read_unlock+0x16/0x4d
May 30 17:50:35 ltg01-fedora kernel: [<c02e693b>] ip_mc_del_src+0x5e/0xd5
May 30 17:50:35 ltg01-fedora kernel: [<c02e69de>] ip_mc_leave_src+0x2c/0x6c
May 30 17:50:35 ltg01-fedora kernel: [<c02e6c5b>] ip_mc_leave_group+0x3d/0x97
May 30 17:50:35 ltg01-fedora kernel: [<c02c8a68>] ip_setsockopt+0x4d0/0x9a6
May 30 17:50:35 ltg01-fedora kernel: [<c02def6d>] udp_setsockopt+0x1f/0x9c
May 30 17:50:35 ltg01-fedora kernel: [<c02a7006>]
sock_common_setsockopt+0x13/0x18
May 30 17:50:35 ltg01-fedora kernel: [<c02a5956>] sys_setsockopt+0x73/0xa4
May 30 17:50:35 ltg01-fedora kernel: [<c02a6c53>] sys_socketcall+0x148/0x186
May 30 17:50:35 ltg01-fedora kernel: [<c02f2ad5>] sysenter_past_esp+0x56/0x8d
Here is config
http://www.stardust.webpages.pl/files/mm/2.6.17-rc5-mm1/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply
* Re: zd1201 failure on sharp zaurus explained
From: Pavel Machek @ 2006-05-30 14:49 UTC (permalink / raw)
To: Oliver Neukum
Cc: rpurdie, lenz, kernel list, Russell King, Netdev list,
Jirka Lenost Benc, pe1rxq
In-Reply-To: <200605301611.02984.oliver@neukum.org>
On Út 30-05-06 16:11:02, Oliver Neukum wrote:
> Am Dienstag, 30. Mai 2006 15:20 schrieb Pavel Machek:
> > 2) usb problem, probably. Should not usb core detect that card
> > requires too much juice and refuse to power it up?
>
> Does your hub correctly report whether it is plugged in?
No idea; how do I tell?
But zaurus tries to power the wlan card even if it is directly plugged
in. wlan card there comunicates with the computer but not with the
wireless part...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: zd1201 & ipw2200 problems
From: Pavel Machek @ 2006-05-30 14:47 UTC (permalink / raw)
To: Greg KH; +Cc: Netdev list, Jirka Lenost Benc, kernel list
In-Reply-To: <20060530144120.GA15350@kroah.com>
Hi!
> > I see some strange problems with zd1201. (Ccing greg, he seen
> > something similar).
>
> Which zd1201 driver are you using?
In-tree one, 2.6.17-rc4 (and around). Ouch and I've "solved" the
zaurus problme in the meantime -- it was hw one.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: zd1201 & ipw2200 problems
From: Greg KH @ 2006-05-30 14:41 UTC (permalink / raw)
To: Pavel Machek; +Cc: Netdev list, Jirka Lenost Benc, kernel list
In-Reply-To: <20060530111712.GA32054@elf.ucw.cz>
On Tue, May 30, 2006 at 01:17:12PM +0200, Pavel Machek wrote:
> Hi!
>
> I see some strange problems with zd1201. (Ccing greg, he seen
> something similar).
Which zd1201 driver are you using?
thanks,
greg k-h
^ permalink raw reply
* Re: Refactor Netlink connector?
From: James Morris @ 2006-05-30 14:22 UTC (permalink / raw)
To: jamal; +Cc: David Miller, sds, tgraf, netdev, johnpol
In-Reply-To: <1148904686.27078.20.camel@jzny2>
On Mon, 29 May 2006, jamal wrote:
> If SELinux should provide ways to add "filters" more dynamically at its
> hooks - instead of having people go and look for that table and update
> it then it would simplify things and we may be able to easily have
> netlink users to register such filters at startup; infact we may be able
> to hide this from the users in genetlink.
> One could argue that if SELinux is capable of adding such filters at its
> hooks, then the problem could be moved to user space policy perhaps?
This is similar to what the secmark stuff does, allows selection and
labeling to be done via iptables, so the SELinux kernel stuff then just
needs to look at the labels.
In this case, I'm not sure it's worthwhile adding a filtering layer to
Netlink, probably simpler just to have the different Netlink protocols
define whether each command is one of 'read', 'write' and 'readpriv' (the
latter is pretty rare), so nothing has to be scanned on the fly at all.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: Refactor Netlink connector?
From: James Morris @ 2006-05-30 14:18 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, David S. Miller, tgraf, Stephen Smalley
In-Reply-To: <20060528153321.GB31822@2ka.mipt.ru>
On Sun, 28 May 2006, Evgeniy Polyakov wrote:
> Does SELinux have security handlers for each type of possible ioctls
> over the world? Each ioctl number is like each netlink type of message,
> but instead there is only one check per ioctl syscall as long as lsm
> hook for socket's send/recv syscall.
> It could be interesting and quite challenging to force all ioctl users
> to have the same structure under each ioctl number so SELinux could
> control for example disk geometry or time and date requests...
It has a generic control for ioctls, but also does some special handling
for some ioctls.
> And, btw, what is the purpose of controlling netlink messages?
> Does it prevent malicious userspace application to receive events from
> malicious kernel module?
It provides control over which types of applications can send and receive
different types of Netlink messages. e.g. you can specify that Apache can
read the routing table but not write to it.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: zd1201 failure on sharp zaurus explained
From: Oliver Neukum @ 2006-05-30 14:11 UTC (permalink / raw)
To: Pavel Machek
Cc: rpurdie, lenz, kernel list, Russell King, Netdev list,
Jirka Lenost Benc, pe1rxq
In-Reply-To: <20060530132054.GA9780@elf.ucw.cz>
Am Dienstag, 30. Mai 2006 15:20 schrieb Pavel Machek:
> 2) usb problem, probably. Should not usb core detect that card
> requires too much juice and refuse to power it up?
Does your hub correctly report whether it is plugged in?
Regards
Oliver
^ permalink raw reply
* zd1201 failure on sharp zaurus explained
From: Pavel Machek @ 2006-05-30 13:20 UTC (permalink / raw)
To: rpurdie, lenz, kernel list, Russell King, Netdev list,
Jirka Lenost Benc, pe1rxq
Hi!
Now I found out what went wrong with zd1201 on sharp zaurus (spitz)...
Card is detected and seems to work okay, except that you don't get any
results from iwlist eth1 scan, and card generally does not do anything
involving radio.
And now I have an explanation, too:
If you plug card directly to zaurus, above is what happens.
If you plug it into the hub, hub flashes the lights and shuts down, as
if not enough power is available from the zaurus.
...which is probably the case, because if I connect external 6V power
supply to the hub, it all starts to work.
So... it is
1) hw problem: spitz power supply is not strong enough to drive zd1201
2) usb problem, probably. Should not usb core detect that card
requires too much juice and refuse to power it up?
...and the morale is, always put hub between device and the host so
that you can see the flashy leds :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: drivers/connector/cn_queue.c:130: warning: value computed is not used
From: Evgeniy Polyakov @ 2006-05-30 11:48 UTC (permalink / raw)
To: Andreas Schwab; +Cc: netdev
In-Reply-To: <jeac8zg311.fsf@sykes.suse.de>
On Tue, May 30, 2006 at 01:34:02PM +0200, Andreas Schwab (schwab@suse.de) wrote:
> There is no point in testing the atomic value if the result is thrown
> away.
It was created to put implicit smp barrier, but it is not needed there.
Your patch is correct, thank you.
> Signed-off-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
> index 9f2f00d..05f8ce2 100644
> --- a/drivers/connector/cn_queue.c
> +++ b/drivers/connector/cn_queue.c
> @@ -127,7 +127,7 @@ void cn_queue_del_callback(struct cn_que
>
> if (found) {
> cn_queue_free_callback(cbq);
> - atomic_dec_and_test(&dev->refcnt);
> + atomic_dec(&dev->refcnt);
> }
> }
>
>
> Andreas.
--
Evgeniy Polyakov
^ permalink raw reply
* [patch, -rc5-mm1] lock validator: remove softirq.c WARN_ON
From: Ingo Molnar @ 2006-05-30 11:55 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, jgarzik, netdev, kuznet, alan
In-Reply-To: <447C261E.1090202@gmail.com>
* Jiri Slaby <jirislaby@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm1/
>
> BUG: warning at /l/latest/xxx/kernel/softirq.c:86/local_bh_disable()
ok, that WARN_ON is over-eager. Fix is below:
--------------
Subject: lock validator: remove softirq.c WARN_ON
From: Ingo Molnar <mingo@elte.hu>
there is nothing wrong with calling local_bh_disable() in irqs-off
section (as long as the local_bh_enable isnt done with irqs-off),
so remove this over-eager WARN_ON().
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
kernel/softirq.c | 1 -
1 file changed, 1 deletion(-)
Index: linux/kernel/softirq.c
===================================================================
--- linux.orig/kernel/softirq.c
+++ linux/kernel/softirq.c
@@ -83,7 +83,6 @@ static void __local_bh_disable(unsigned
void local_bh_disable(void)
{
- WARN_ON_ONCE(irqs_disabled());
__local_bh_disable((unsigned long)__builtin_return_address(0));
}
^ permalink raw reply
* drivers/connector/cn_queue.c:130: warning: value computed is not used
From: Andreas Schwab @ 2006-05-30 11:34 UTC (permalink / raw)
To: netdev
There is no point in testing the atomic value if the result is thrown
away.
Signed-off-by: Andreas Schwab <schwab@suse.de>
diff --git a/drivers/connector/cn_queue.c b/drivers/connector/cn_queue.c
index 9f2f00d..05f8ce2 100644
--- a/drivers/connector/cn_queue.c
+++ b/drivers/connector/cn_queue.c
@@ -127,7 +127,7 @@ void cn_queue_del_callback(struct cn_que
if (found) {
cn_queue_free_callback(cbq);
- atomic_dec_and_test(&dev->refcnt);
+ atomic_dec(&dev->refcnt);
}
}
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox