* Re: [PATCH] TC: bug fixes to the "sample" clause
From: Russell Stuart @ 2006-03-14 0:31 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, hadi, lartc
In-Reply-To: <20060313135048.27b09fba@localhost.localdomain>
On Mon, 2006-03-13 at 13:50 -0800, Stephen Hemminger wrote:
> On Tue, 14 Mar 2006 07:43:57 +1000
> Russell Stuart <russell-lartc@stuart.id.au> wrote:
>
> > On Mon, 2006-03-13 at 10:04 -0800, Stephen Hemminger wrote:
> > > The memset fix is in current CVS. I just wasn't going to take the
> > > patch that looked at utsname to decide what hash to use.
> >
> > Stephen, could you describe your objections to it please?
> >
>
> Because it means that the API for netlink isn't being used properly.
Do you mean the binary API between the kernel and the
applications has been broken; this is bad as it
transgresses some unwritten law; and the patch is
bad because it hides this problem rather than addressing
it?
Does the fact that the binary API changed during a
major kernel release (between 2.4 and 2.6) give us some
wriggle room here?
Anyway, jokes aside, the situation we have now is the
current "tc" doesn't work with the current kernel. This
situation can't be allowed to continue, I presume. Ergo,
here is a list of things we could do to fix this. All
you (plural) have to do is choose one, or some
combination:
1. Change the hashing algorithm back to the 2.4 way.
(IMHO, the 2.4 algorithm was better.) Disadvantage:
anybody who had a u32 filter that hashed on more
than one non-zero byte will have their u32 filters
suddenly break. However, since how the hashing
algorithm was never documented beyond "HOWTO's"
that showed how to hash on one byte, and every
example of hashing I have seen has been a copy &
paste of said HOWTO's, my guess is there are stuff
all people who will be effected. Another disadvantage:
people who are using older 2.6 kernels (eg me on
my production machines) won't have the problem fixed.
2. Change the hashing algorithm in "tc" to match the
current kernel. Disadvantage: "tc" will no longer
work with 2.4 kernels.
3. Change the hashing algorithm in "tc" to match the
current kernel, and change the 2.4 kernel's hashing
algorithm to match the 2.6 kernel. This is Jamal's
proposed solution. Disadvantage: 2.4 is a "stable"
kernel, produced when we made a real effort to
distinguish between between stable and development
kernels. This change would break API compatibility
in a stable series. Yuk!
4. Make "tc" look at the kernel version, and choose
the appropriate hashing function. This was my
solution, and everybody seems to hate it bar me
:(. Disadvantages: None, other than it hides a
violation of an "unwritten law".
5. A combination of 1 & 4. Change the hashing in 2.6
algorithm back to what it was in 2.4, and hide the
change by making "tc" check the kernel version and
choose the matching hash. Disadvantages: None,
other than now we have wilfully broken the unwritten
law twice.
My personal preference is to have a "tc" in CVS that
works with _all_ kernel versions. Yes - the netlink
interface has been broken. But is was done, and now
can't be undone. No matter why we do, there will
forever more be kernel versions with incompatible
netlink interfaces. We can't fix it. We just have
to limit the damage.
^ permalink raw reply
* [Patch 8/9] generic netlink utility functions
From: Shailabh Nagar @ 2006-03-14 0:55 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: Jamal
In-Reply-To: <1142296834.5858.3.camel@elinux04.optonline.net>
genetlink-utils.patch
Two utilities for simplifying usage of NETLINK_GENERIC
interface.
Signed-off-by: Balbir Singh <balbir@in.ibm.com>
Signed-off-by: Shailabh Nagar <nagar@watson.ibm.com>
include/net/genetlink.h | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+)
Index: linux-2.6.16-rc5/include/net/genetlink.h
===================================================================
--- linux-2.6.16-rc5.orig/include/net/genetlink.h 2006-03-11 07:41:32.000000000 -0500
+++ linux-2.6.16-rc5/include/net/genetlink.h 2006-03-11 07:41:41.000000000 -0500
@@ -150,4 +150,24 @@ static inline int genlmsg_unicast(struct
return nlmsg_unicast(genl_sock, skb, pid);
}
+/**
+ * gennlmsg_data - head of message payload
+ * @gnlh: genetlink messsage header
+ */
+static inline void *genlmsg_data(const struct genlmsghdr *gnlh)
+{
+ return ((unsigned char *) gnlh + GENL_HDRLEN);
+}
+
+/**
+ * genlmsg_len - length of message payload
+ * @gnlh: genetlink message header
+ */
+static inline int genlmsg_len(const struct genlmsghdr *gnlh)
+{
+ struct nlmsghdr *nlh = (struct nlmsghdr *)((unsigned char *)gnlh -
+ NLMSG_HDRLEN);
+ return (nlh->nlmsg_len - GENL_HDRLEN - NLMSG_HDRLEN);
+}
+
#endif /* __NET_GENERIC_NETLINK_H */
^ permalink raw reply
* [Patch 9/9] Generic netlink interface for delay accounting
From: Shailabh Nagar @ 2006-03-14 0:56 UTC (permalink / raw)
To: linux-kernel; +Cc: Jamal, netdev
In-Reply-To: <1142296834.5858.3.camel@elinux04.optonline.net>
delayacct-genetlink.patch
Create a generic netlink interface (NETLINK_GENERIC family),
called "taskstats", for getting delay and cpu statistics of
tasks and thread groups during their lifetime and when they exit.
Comments addressed (all in response to Jamal)
- Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
- Use multicast only for events generated due to task exit, not for
replies to commands
- Align taskstats and taskstats_reply structures to 64 bit aligned.
- Use dynamic ID generation for genetlink family
More changes expected. Following comments will go into a
Documentation file:
When a task is alive, userspace can get its stats by sending a
command containing its pid. Sending a tgid returns the sum of stats
of the tasks belonging to that tgid (where such a sum makes sense).
Together, the command interface allows stats for a large number of
tasks to be collected more efficiently than would be possible
through /proc or any per-pid interface.
The netlink interface also sends the stats for each task to userspace
when the task is exiting. This permits fine-grain accounting for
short-lived tasks, which is important if userspace is doing its own
aggregation of statistics based on some grouping of tasks
(e.g. CSA jobs, ELSA banks or CKRM classes).
If the exiting task belongs to a thread group (with more members than itself)
, the latters delay stats are also sent out on the task's exit. This allows
userspace to get accurate data at a per-tgid level while the tid's of a tgid
are exiting one by one.
The interface has been deliberately kept distinct from the delay
accounting code since it is potentially usable by other kernel components
that need to export per-pid/tgid data. The format of data returned to
userspace is versioned and the command interface easily extensible to
facilitate reuse.
If reuse is not deemed useful enough, the naming, placement of functions
and config options will be modified to make this an interface for delay
accounting alone.
Signed-off-by: Shailabh Nagar <nagar@watson.ibm.com>
Signed-off-by: Balbir Singh <balbir@in.ibm.com>
include/linux/taskstats.h | 128 ++++++++++++++++++++++++
init/Kconfig | 16 ++-
kernel/taskstats.c | 244 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 385 insertions(+), 3 deletions(-)
Index: linux-2.6.16-rc5/include/linux/taskstats.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.16-rc5/include/linux/taskstats.h 2006-03-13 19:01:35.000000000 -0500
@@ -0,0 +1,128 @@
+/* taskstats.h - exporting per-task statistics
+ *
+ * Copyright (C) Shailabh Nagar, IBM Corp. 2006
+ * (C) Balbir Singh, IBM Corp. 2006
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2.1 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it would be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+#ifndef _LINUX_TASKSTATS_H
+#define _LINUX_TASKSTATS_H
+
+/* Format for per-task data returned to userland when
+ * - a task exits
+ * - listener requests stats for a task
+ *
+ * The struct is versioned. Newer versions should only add fields to
+ * the bottom of the struct to maintain backward compatibility.
+ *
+ * To create the next version, bump up the taskstats_version variable
+ * and delineate the start of newly added fields with a comment indicating
+ * the version number.
+ */
+
+#define TASKSTATS_VERSION 1
+
+struct taskstats {
+ /* Maintain 64-bit alignment while extending */
+
+ /* Version 1 */
+#define TASKSTATS_NOPID -1
+ __s64 pid;
+ __s64 tgid;
+
+ /* XXX_count is number of delay values recorded.
+ * XXX_total is corresponding cumulative delay in nanoseconds
+ */
+
+#define TASKSTATS_NOCPUSTATS 1
+ __u64 cpu_count;
+ __u64 cpu_delay_total; /* wait, while runnable, for cpu */
+ __u64 blkio_count;
+ __u64 blkio_delay_total; /* sync,block io completion wait*/
+ __u64 swapin_count;
+ __u64 swapin_delay_total; /* swapin page fault wait*/
+
+ __u64 cpu_run_total; /* cpu running time
+ * no count available/provided */
+};
+
+
+#define TASKSTATS_LISTEN_GROUP 0x1
+
+/*
+ * Commands sent from userspace
+ * Not versioned. New commands should only be inserted at the enum's end
+ */
+
+enum {
+ TASKSTATS_CMD_UNSPEC, /* Reserved */
+ TASKSTATS_CMD_NONE, /* Not a valid cmd to send
+ * Marks data sent on task/tgid exit */
+ TASKSTATS_CMD_LISTEN, /* Start listening */
+ TASKSTATS_CMD_IGNORE, /* Stop listening */
+ TASKSTATS_CMD_PID, /* Send stats for a pid */
+ TASKSTATS_CMD_TGID, /* Send stats for a tgid */
+};
+
+/* Parameters for commands
+ * New parameters should only be inserted at the struct's end
+ */
+
+struct taskstats_cmd_param {
+ /* Maintain 64-bit alignment while extending */
+ union {
+ __s64 pid;
+ __s64 tgid;
+ } id;
+};
+
+enum outtype {
+ TASKSTATS_REPLY_NONE = 1, /* Control cmd response */
+ TASKSTATS_REPLY_PID, /* per-pid data cmd response*/
+ TASKSTATS_REPLY_TGID, /* per-tgid data cmd response*/
+ TASKSTATS_REPLY_EXIT_PID, /* Exiting task's stats */
+ TASKSTATS_REPLY_EXIT_TGID, /* Exiting tgid's stats
+ * (sent on each tid's exit) */
+};
+
+/*
+ * Reply sent from kernel
+ * Version number affects size/format of struct taskstats only
+ */
+
+struct taskstats_reply {
+ /* Maintain 64-bit alignment while extending */
+ __u16 outtype; /* Must be one of enum outtype */
+ __u16 version;
+ __u32 err;
+ struct taskstats stats; /* Invalid if err != 0 */
+};
+
+/* NETLINK_GENERIC related info */
+
+#define TASKSTATS_GENL_NAME "TASKSTATS"
+#define TASKSTATS_GENL_VERSION 0x1
+
+#define TASKSTATS_HDRLEN (NLMSG_SPACE(GENL_HDRLEN))
+#define TASKSTATS_BODYLEN (sizeof(struct taskstats_reply))
+
+#ifdef __KERNEL__
+
+#include <linux/sched.h>
+
+#ifdef CONFIG_TASKSTATS
+extern void taskstats_exit_pid(struct task_struct *);
+#else
+static inline void taskstats_exit_pid(struct task_struct *tsk)
+{}
+#endif
+
+#endif /* __KERNEL__ */
+#endif /* _LINUX_TASKSTATS_H */
Index: linux-2.6.16-rc5/kernel/taskstats.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.16-rc5/kernel/taskstats.c 2006-03-13 19:01:35.000000000 -0500
@@ -0,0 +1,244 @@
+/*
+ * taskstats.c - Export per-task statistics to userland
+ *
+ * Copyright (C) Shailabh Nagar, IBM Corp. 2006
+ * (C) Balbir Singh, IBM Corp. 2006
+ *
+ * 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.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/taskstats.h>
+#include <linux/delayacct.h>
+#include <net/genetlink.h>
+#include <asm/atomic.h>
+
+const int taskstats_version = TASKSTATS_VERSION;
+static DEFINE_PER_CPU(__u32, taskstats_seqnum) = { 0 };
+static int family_registered = 0;
+
+
+static struct genl_family family = {
+ .id = GENL_ID_GENERATE,
+ .name = TASKSTATS_GENL_NAME,
+ .version = TASKSTATS_GENL_VERSION,
+ .hdrsize = 0,
+ .maxattr = 0,
+};
+
+/* Taskstat specific functions */
+static int prepare_reply(struct genl_info *info, u8 cmd,
+ struct sk_buff **skbp, struct taskstats_reply **replyp)
+{
+ struct sk_buff *skb;
+ struct taskstats_reply *reply;
+
+ skb = nlmsg_new(TASKSTATS_HDRLEN + TASKSTATS_BODYLEN);
+ if (!skb)
+ return -ENOMEM;
+
+ if (!info) {
+ int seq = get_cpu_var(taskstats_seqnum)++;
+ put_cpu_var(taskstats_seqnum);
+
+ reply = genlmsg_put(skb, 0, seq,
+ family.id, 0, NLM_F_REQUEST,
+ cmd, family.version);
+ } else
+ reply = genlmsg_put(skb, info->snd_pid, info->snd_seq,
+ family.id, 0, info->nlhdr->nlmsg_flags,
+ info->genlhdr->cmd, family.version);
+ if (reply == NULL) {
+ nlmsg_free(skb);
+ return -EINVAL;
+ }
+ skb_put(skb, TASKSTATS_BODYLEN);
+
+ memset(reply, 0, sizeof(*reply));
+ reply->version = taskstats_version;
+ reply->err = 0;
+
+ *skbp = skb;
+ *replyp = reply;
+ return 0;
+}
+
+static int send_reply(struct sk_buff *skb, int replytype, pid_t pid, int event)
+{
+ struct genlmsghdr *genlhdr = nlmsg_data((struct nlmsghdr *)skb->data);
+ struct taskstats_reply *reply;
+ int rc;
+
+ reply = (struct taskstats_reply *)genlmsg_data(genlhdr);
+ reply->outtype = replytype;
+
+ rc = genlmsg_end(skb, reply);
+ if (rc < 0) {
+ nlmsg_free(skb);
+ return rc;
+ }
+
+ if (event)
+ return genlmsg_multicast(skb, pid, TASKSTATS_LISTEN_GROUP);
+ else
+ return genlmsg_unicast(skb, pid);
+}
+
+static inline void fill_pid(struct taskstats_reply *reply, pid_t pid,
+ struct task_struct *pidtsk)
+{
+ int rc;
+ struct task_struct *tsk = pidtsk;
+
+ if (!pidtsk) {
+ read_lock(&tasklist_lock);
+ tsk = find_task_by_pid(pid);
+ if (!tsk) {
+ read_unlock(&tasklist_lock);
+ reply->err = EINVAL;
+ return;
+ }
+ get_task_struct(tsk);
+ read_unlock(&tasklist_lock);
+ } else
+ get_task_struct(tsk);
+
+ rc = delayacct_add_tsk(reply, tsk);
+ if (!rc) {
+ reply->stats.pid = (s64)tsk->pid;
+ reply->stats.tgid = (s64)tsk->tgid;
+ } else
+ reply->err = (rc < 0) ? -rc : rc ;
+
+ put_task_struct(tsk);
+}
+
+static int taskstats_send_pid(struct sk_buff *skb, struct genl_info *info)
+{
+ int rc;
+ struct sk_buff *rep_skb;
+ struct taskstats_reply *reply;
+ struct taskstats_cmd_param *param= info->userhdr;
+
+ rc = prepare_reply(info, info->genlhdr->cmd, &rep_skb, &reply);
+ if (rc)
+ return rc;
+ fill_pid(reply, param->id.pid, NULL);
+ return send_reply(rep_skb, TASKSTATS_REPLY_PID, info->snd_pid, 0);
+}
+
+static inline void fill_tgid(struct taskstats_reply *reply, pid_t tgid,
+ struct task_struct *tgidtsk)
+{
+ int rc;
+ struct task_struct *tsk, *first;
+
+ first = tgidtsk;
+ read_lock(&tasklist_lock);
+ if (!first) {
+ first = find_task_by_pid(tgid);
+ if (!first) {
+ read_unlock(&tasklist_lock);
+ reply->err = EINVAL;
+ return;
+ }
+ }
+ tsk = first;
+ do {
+ rc = delayacct_add_tsk(reply, tsk);
+ if (rc)
+ break;
+ } while_each_thread(first, tsk);
+ read_unlock(&tasklist_lock);
+
+ if (!rc) {
+ reply->stats.pid = (s64)TASKSTATS_NOPID;
+ reply->stats.tgid = (s64)tgid;
+ } else
+ reply->err = (rc < 0) ? -rc : rc ;
+}
+
+static int taskstats_send_tgid(struct sk_buff *skb, struct genl_info *info)
+{
+ int rc;
+ struct sk_buff *rep_skb;
+ struct taskstats_reply *reply;
+ struct taskstats_cmd_param *param= info->userhdr;
+
+ rc = prepare_reply(info, info->genlhdr->cmd, &rep_skb, &reply);
+ if (rc)
+ return rc;
+ fill_tgid(reply, param->id.tgid, NULL);
+ return send_reply(rep_skb, TASKSTATS_REPLY_TGID, info->snd_pid, 0);
+}
+
+/* Send pid data out on exit */
+void taskstats_exit_pid(struct task_struct *tsk)
+{
+ int rc;
+ struct sk_buff *rep_skb;
+ struct taskstats_reply *reply;
+
+ /*
+ * tasks can start to exit very early. Ensure that the family
+ * is registered before notifications are sent out
+ */
+ if (!family_registered)
+ return;
+
+ rc = prepare_reply(NULL, TASKSTATS_CMD_NONE, &rep_skb, &reply);
+ if (rc)
+ return;
+ fill_pid(reply, tsk->pid, tsk);
+ rc = send_reply(rep_skb, TASKSTATS_REPLY_EXIT_PID, 0, 1);
+
+ if (rc || thread_group_empty(tsk))
+ return;
+
+ /* Send tgid data too */
+ rc = prepare_reply(NULL, TASKSTATS_CMD_NONE, &rep_skb, &reply);
+ if (rc)
+ return;
+ fill_tgid(reply, tsk->tgid, tsk);
+ send_reply(rep_skb, TASKSTATS_REPLY_EXIT_TGID, 0, 1);
+}
+
+static struct genl_ops pid_ops = {
+ .cmd = TASKSTATS_CMD_PID,
+ .doit = taskstats_send_pid,
+};
+
+static struct genl_ops tgid_ops = {
+ .cmd = TASKSTATS_CMD_TGID,
+ .doit = taskstats_send_tgid,
+};
+
+static int __init taskstats_init(void)
+{
+ if (genl_register_family(&family))
+ return -EFAULT;
+ family_registered = 1;
+
+ if (genl_register_ops(&family, &pid_ops))
+ goto err;
+ if (genl_register_ops(&family, &tgid_ops))
+ goto err;
+
+ return 0;
+err:
+ genl_unregister_family(&family);
+ family_registered = 0;
+ return -EFAULT;
+}
+
+late_initcall(taskstats_init);
+
Index: linux-2.6.16-rc5/init/Kconfig
===================================================================
--- linux-2.6.16-rc5.orig/init/Kconfig 2006-03-13 18:51:30.000000000 -0500
+++ linux-2.6.16-rc5/init/Kconfig 2006-03-13 19:04:52.000000000 -0500
@@ -158,11 +158,21 @@ config TASK_DELAY_ACCT
in pages. Such statistics can help in setting a task's priorities
relative to other tasks for cpu, io, rss limits etc.
- Unlike BSD process accounting, this information is available
- continuously during the lifetime of a task.
-
Say N if unsure.
+config TASKSTATS
+ bool "Export task/process statistics through netlink (EXPERIMENTAL)"
+ depends on TASK_DELAY_ACCT
+ default y
+ help
+ Export selected statistics for tasks/processes through the
+ generic netlink interface. Unlike BSD process accounting, the
+ statistics are available during the lifetime of tasks/processes as
+ responses to commands. Like BSD accounting, they are sent to user
+ space on task exit.
+
+ Say Y if unsure.
+
config SYSCTL
bool "Sysctl support"
---help---
^ permalink raw reply
* Re: [PATCH] scm: fold __scm_send() into scm_send()
From: Andrew Morton @ 2006-03-14 1:31 UTC (permalink / raw)
To: Ingo Oeser; +Cc: davem, linux-kernel, netdev
In-Reply-To: <200603132105.32794.ioe-lkml@rameria.de>
Ingo Oeser <ioe-lkml@rameria.de> wrote:
>
> -int scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *scm)
> -{
> - struct task_struct *p = current;
> - scm->creds = (struct ucred) {
> - .uid = p->uid,
> - .gid = p->gid,
> - .pid = p->tgid
> - };
> - scm->fp = NULL;
> - scm->sid = security_sk_sid(sock->sk, NULL, 0);
> - scm->seq = 0;
> - if (msg->msg_controllen <= 0)
> - return 0;
> - return __scm_send(sock, msg, scm);
> -}
It's worth noting that scm_send() will call security_sk_sid() even if
(msg->msg_controllen <= 0).
If that test is likely to be true with any frequency then perhaps we can
optimise things...
^ permalink raw reply
* Re: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
From: Herbert Xu @ 2006-03-14 2:25 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jkmaline, hostap, netdev, linux-kernel
In-Reply-To: <20060313222841.GQ13973@stusta.de>
Adrian Bunk <bunk@stusta.de> wrote:
>
> + if (pci_enable_device(pdev))
> + return -EIO;
> +
> hw_priv = kmalloc(sizeof(*hw_priv), GFP_KERNEL);
> if (hw_priv == NULL)
> return -ENOMEM;
> memset(hw_priv, 0, sizeof(*hw_priv));
>
> - if (pci_enable_device(pdev))
> - return -EIO;
> -
You've just turned it into a leak of a different kind.
Why not jump to the error exit instead?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [Patch 9/9] Generic netlink interface for delay accounting
From: jamal @ 2006-03-14 2:29 UTC (permalink / raw)
To: nagar; +Cc: linux-kernel, netdev
In-Reply-To: <1142297791.5858.31.camel@elinux04.optonline.net>
On Mon, 2006-13-03 at 19:56 -0500, Shailabh Nagar wrote:
> delayacct-genetlink.patch
>
> Create a generic netlink interface (NETLINK_GENERIC family),
> called "taskstats", for getting delay and cpu statistics of
> tasks and thread groups during their lifetime and when they exit.
>
> Comments addressed (all in response to Jamal)
>
Note, you are still not following the standard scheme of doing things.
Example: using command = GET and the message carrying the TGID to note
which TGID is of interest. Instead you have command = TGID.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] TC: bug fixes to the "sample" clause
From: Russell Stuart @ 2006-03-14 2:29 UTC (permalink / raw)
To: hadi; +Cc: netdev, lartc
In-Reply-To: <1142082696.5184.53.camel@jzny2>
On Sat, 2006-03-11 at 08:11 -0500, jamal wrote:
> On Fri, 2006-10-02 at 12:33 +1000, Russell Stuart wrote:
> > This patch adds a "divisor" option to tc's "sample"
> > clause:
>
> While this looks right - can we have more test data with tc filter ls
> both before and after your fix? Specify divisor of 256 and 16 for
> example. Show that for the 256 it is the same as before and for 16 it
> does the right thing.
With patch, divisor 256:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb
tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 ht 801: divisor 256
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x01 0xff divisor 256 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x0f 0xff divisor 256 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x10 0xff divisor 256 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0xef 0xff divisor 256 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0xf0 0xff divisor 256 match u32 0 0
tc -s filter show dev eth0
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 256
filter parent 1: protocol ip pref 1 u32 fh 801:1:800 order 2048 key ht 801 bkt 1 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:f:800 order 2048 key ht 801 bkt f flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:10:800 order 2048 key ht 801 bkt 10 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:ef:800 order 2048 key ht 801 bkt ef flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:f0:800 order 2048 key ht 801 bkt f0 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
Without patch, divisor 256:
tc qdisc add dev eth0 root handle 1: htb
tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 ht 801: divisor 256
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x01 0xff match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x0f 0xff match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x10 0xff match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0xef 0xff match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0xf0 0xff match u32 0 0
tc -s filter show dev eth0
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 256
filter parent 1: protocol ip pref 1 u32 fh 801:1:800 order 2048 key ht 801 bkt 1 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:f:800 order 2048 key ht 801 bkt f flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:10:800 order 2048 key ht 801 bkt 10 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:ef:800 order 2048 key ht 801 bkt ef flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:f0:800 order 2048 key ht 801 bkt f0 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
With patch, divisor 16:
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb
tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 ht 801: divisor 16
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x01 0xff divisor 16 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x0f 0xff divisor 16 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0x10 0xff divisor 16 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0xef 0xff divisor 16 match u32 0 0
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 801: classid 1:0 sample u8 0xf0 0xff divisor 16 match u32 0 0
tc -s filter show dev eth0
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 16
filter parent 1: protocol ip pref 1 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801::801 order 2049 key ht 801 bkt 0 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:1:800 order 2048 key ht 801 bkt 1 flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:f:800 order 2048 key ht 801 bkt f flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 801:f:801 order 2049 key ht 801 bkt f flowid 1:
match 00000000/00000000 at 0
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
^ permalink raw reply
* Re: [Patch 9/9] Generic netlink interface for delay accounting
From: Matt Helsley @ 2006-03-14 2:33 UTC (permalink / raw)
To: Shailabh Nagar; +Cc: linux-kernel, Jamal, netdev
In-Reply-To: <1142297791.5858.31.camel@elinux04.optonline.net>
On Mon, 2006-03-13 at 19:56 -0500, Shailabh Nagar wrote:
<snip>
> Comments addressed (all in response to Jamal)
>
> - Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
The enums for these are still in the patch. See below.
<snip>
> +/*
> + * Commands sent from userspace
> + * Not versioned. New commands should only be inserted at the enum's end
> + */
> +
> +enum {
> + TASKSTATS_CMD_UNSPEC, /* Reserved */
> + TASKSTATS_CMD_NONE, /* Not a valid cmd to send
> + * Marks data sent on task/tgid exit */
> + TASKSTATS_CMD_LISTEN, /* Start listening */
> + TASKSTATS_CMD_IGNORE, /* Stop listening */
>From the description I thought you had eliminated these.
> + TASKSTATS_CMD_PID, /* Send stats for a pid */
> + TASKSTATS_CMD_TGID, /* Send stats for a tgid */
> +};
Jamal, was your Mon, 13 Mar 2006 21:29:09 -0500 reply:
> Note, you are still not following the standard scheme of doing things.
> Example: using command = GET and the message carrying the TGID to note
> which TGID is of interest. Instead you have command = TGID.
>
> cheers,
> jamal
meant to suggest that TASKSTATS_CMD_(P|TG)ID should be renamed to
TASKSTATS_CMD_GET_(P|TG)ID ? Is that sufficient? Or am I
misunderstanding?
<snip>
Cheers,
-Matt Helsley
^ permalink raw reply
* Re: [PATCH] TC: bug fixes to the "sample" clause
From: Russell Stuart @ 2006-03-14 2:45 UTC (permalink / raw)
To: hadi; +Cc: netdev, lartc
In-Reply-To: <1142092598.5184.93.camel@jzny2>
On Sat, 2006-03-11 at 10:56 -0500, jamal wrote:
> Right - take a look at the use of hashkey with varying divisors to see
> where the 2.4 folding breaks[1]. Note you should be able to use hashkey
> instead of sample and it would work fine.
<snip>
> [1] Essentially, if you teach u32 in 2.4 to spread rules over different
> buckets it will not do so evenly. Off top of my head i remember that the
> best you could ever do is have bucket selection in increments of 4 (so
> bucket 0, 4, 8,..) with certain divisor sizes - mostly works with 256;
> to work properly you need it to be (0,1,2,3,..).
> implies --> When it does work, it is detrimental to lookup speed when
> you hit thousands of rules because some buckets get overloaded and
> others are totaly unused and when it doesnt work, it results in
> classifier misses for rules you inserted.
Hmm. I can't see how this could be so. Can you give
specific examples.
The only time I can think of where the 2.4 XOR hash would
be worse is where there is a correlation between the bits
in different bytes. I can't think of a real life example
of where that would be so. In every other case it will
be as good as, but typically better than, the 2.6
algorithm.
^ permalink raw reply
* Re: [Patch 9/9] Generic netlink interface for delay accounting
From: jamal @ 2006-03-14 2:48 UTC (permalink / raw)
To: Matt Helsley; +Cc: Shailabh Nagar, linux-kernel, netdev
In-Reply-To: <1142303607.24621.63.camel@stark>
On Mon, 2006-13-03 at 18:33 -0800, Matt Helsley wrote:
> On Mon, 2006-03-13 at 19:56 -0500, Shailabh Nagar wrote:
> Jamal, was your Mon, 13 Mar 2006 21:29:09 -0500 reply:
> > Note, you are still not following the standard scheme of doing things.
> > Example: using command = GET and the message carrying the TGID to note
> > which TGID is of interest. Instead you have command = TGID.
> >
> meant to suggest that TASKSTATS_CMD_(P|TG)ID should be renamed to
> TASKSTATS_CMD_GET_(P|TG)ID ? Is that sufficient? Or am I
> misunderstanding?
>
I had a long description in an earlier email feedback; but the summary
of it is the GET command is generic like TASKSTATS_CMD_GET; the message
itself carries TLVs of what needs to be gotten which are
either PID and/or TGID etc. Anyways, theres a long spill of what i am
saying in that earlier email. Perhaps the current patch is a transition
towards that?
cheers,
jamal
^ permalink raw reply
* Re: [2.6 patch] drivers/net/wireless/ipw2200.c: fix an array overun
From: Zhu Yi @ 2006-03-14 3:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jketreno, netdev, linville, linux-kernel
In-Reply-To: <20060311034258.GJ21864@stusta.de>
On Sat, 2006-03-11 at 04:42 +0100, Adrian Bunk wrote:
> This patch fixes a big array overun found by the Coverity checker.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.16-rc5-mm3-full/drivers/net/wireless/ipw2200.c.old 2006-03-11 02:41:23.000000000 +0100
> +++ linux-2.6.16-rc5-mm3-full/drivers/net/wireless/ipw2200.c 2006-03-11 02:42:04.000000000 +0100
> @@ -9956,9 +9956,8 @@ static int ipw_ethtool_set_eeprom(struct
> return -EINVAL;
> mutex_lock(&p->mutex);
> memcpy(&p->eeprom[eeprom->offset], bytes, eeprom->len);
> - for (i = IPW_EEPROM_DATA;
> - i < IPW_EEPROM_DATA + IPW_EEPROM_IMAGE_SIZE; i++)
> - ipw_write8(p, i, p->eeprom[i]);
> + for (i = 0; i < IPW_EEPROM_IMAGE_SIZE; i++)
> + ipw_write8(p, i + IPW_EEPROM_DATA, p->eeprom[i]);
> mutex_unlock(&p->mutex);
> return 0;
> }
Acked-by: Zhu Yi <yi.zhu@intel.com>
Thanks,
-yi
^ permalink raw reply
* Re: [Patch 9/9] Generic netlink interface for delay accounting
From: Shailabh Nagar @ 2006-03-14 4:18 UTC (permalink / raw)
To: hadi; +Cc: Matt Helsley, linux-kernel, netdev
In-Reply-To: <1142304506.5219.34.camel@jzny2>
jamal wrote:
>On Mon, 2006-13-03 at 18:33 -0800, Matt Helsley wrote:
>
>
>>On Mon, 2006-03-13 at 19:56 -0500, Shailabh Nagar wrote:
>>
>>
>
>
>
>>Jamal, was your Mon, 13 Mar 2006 21:29:09 -0500 reply:
>>
>>
>>>Note, you are still not following the standard scheme of doing things.
>>>Example: using command = GET and the message carrying the TGID to note
>>>which TGID is of interest. Instead you have command = TGID.
>>>
>>>
>>>
>
>
>
>>meant to suggest that TASKSTATS_CMD_(P|TG)ID should be renamed to
>>TASKSTATS_CMD_GET_(P|TG)ID ? Is that sufficient? Or am I
>>misunderstanding?
>>
>>
>>
>
>I had a long description in an earlier email feedback; but the summary
>of it is the GET command is generic like TASKSTATS_CMD_GET; the message
>itself carries TLVs of what needs to be gotten which are
>either PID and/or TGID etc. Anyways, theres a long spill of what i am
>saying in that earlier email. Perhaps the current patch is a transition
>towards that?
>
>
Yes, the comments you'd made in the previous mail have not been
incorporated and this is still the older version of the patch.
We'd been avoiding TLV usage so far :-)
>cheers,
>jamal
>
>
>
^ permalink raw reply
* Re: [Patch 9/9] Generic netlink interface for delay accounting
From: Shailabh Nagar @ 2006-03-14 4:29 UTC (permalink / raw)
To: Matt Helsley; +Cc: linux-kernel, Jamal, netdev
In-Reply-To: <1142303607.24621.63.camel@stark>
Matt Helsley wrote:
>On Mon, 2006-03-13 at 19:56 -0500, Shailabh Nagar wrote:
><snip>
>
>
>
>>Comments addressed (all in response to Jamal)
>>
>>- Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
>>
>>
>
>The enums for these are still in the patch. See below.
>
><snip>
>
>
>
>>+/*
>>+ * Commands sent from userspace
>>+ * Not versioned. New commands should only be inserted at the enum's end
>>+ */
>>+
>>+enum {
>>+ TASKSTATS_CMD_UNSPEC, /* Reserved */
>>+ TASKSTATS_CMD_NONE, /* Not a valid cmd to send
>>+ * Marks data sent on task/tgid exit */
>>+ TASKSTATS_CMD_LISTEN, /* Start listening */
>>+ TASKSTATS_CMD_IGNORE, /* Stop listening */
>>
>>
>
>>From the description I thought you had eliminated these.
>
>
Yup, typo. the commands aren't registered but the enums hang on.
Will fix.
--Shailabh
^ permalink raw reply
* Re: Router stops routing after changing MAC Address
From: Bart Samwel @ 2006-03-14 11:40 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: Greg Scott, Rick Jones, Chuck Ebbert, linux-kernel, netdev,
Alan Cox, Simon Mackinlay
In-Reply-To: <Pine.LNX.4.61.0603131730100.5785@chaos.analogic.com>
linux-os (Dick Johnson) wrote:
> On Mon, 13 Mar 2006, Greg Scott wrote:
> Bzzzzst... Not! There are not any MAC addresses associated with any
> of the intercity links, usually not even in WANs! MAC is for
> Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses.
Bzzzzt. According to WikiPedia:
http://en.wikipedia.org/wiki/MAC_address
MAC addresses are used for:
- Token ring
- 802.11 wireless networks
- Bluetooth
- FDDI
- ATM (switched virtual connections only, as part of an NSAP address)
- SCSI and Fibre Channel (as part of a World Wide Name)
FDDI = fiber, ATM = ATM.
--Bart
^ permalink raw reply
* Re: Router stops routing after changing MAC Address
From: Simon Mackinlay @ 2006-03-14 12:12 UTC (permalink / raw)
To: Bart Samwel, linux-os (Dick Johnson)
Cc: Greg Scott, Rick Jones, Chuck Ebbert, linux-kernel, netdev,
Alan Cox, Simon Mackinlay
> Bzzzzt. According to WikiPedia:
>
> http://en.wikipedia.org/wiki/MAC_address
>
> MAC addresses are used for:
>
> - Token ring
> - 802.11 wireless networks
> - Bluetooth
> - FDDI
> - ATM (switched virtual connections only, as part of an NSAP address)
> - SCSI and Fibre Channel (as part of a World Wide Name)
>
> FDDI = fiber, ATM = ATM.
http://developer.intel.com/design/network/products/optical/framers/ixf18104.htm
It works too.
Cheers,
Simon
--
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/
^ permalink raw reply
* Re: Router stops routing after changing MAC Address
From: linux-os (Dick Johnson) @ 2006-03-14 12:52 UTC (permalink / raw)
To: Bart Samwel
Cc: Greg Scott, Rick Jones, Chuck Ebbert, linux-kernel, netdev,
Alan Cox, Simon Mackinlay
In-Reply-To: <4416ABB1.8020802@samwel.tk>
On Tue, 14 Mar 2006, Bart Samwel wrote:
> linux-os (Dick Johnson) wrote:
>> On Mon, 13 Mar 2006, Greg Scott wrote:
>> Bzzzzst... Not! There are not any MAC addresses associated with any
>> of the intercity links, usually not even in WANs! MAC is for
>> Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses.
>
> Bzzzzt. According to WikiPedia:
>
> http://en.wikipedia.org/wiki/MAC_address
>
> MAC addresses are used for:
>
> - Token ring
> - 802.11 wireless networks
> - Bluetooth
> - FDDI
> - ATM (switched virtual connections only, as part of an NSAP address)
> - SCSI and Fibre Channel (as part of a World Wide Name)
>
> FDDI = fiber, ATM = ATM.
>
> --Bart
>
A name is NOT. I can call my mail route number RFD#2 a MAC
address. Also token-ring is a form of Ethernet as are all
known wireless networks unless they use light. Even cable
modems use Ethernet, with FDM on the cable side and baseband
on the customer side. Calling SCSI MAC is absurd. All of the
above, except the ethernets are forms of point-to-point
communications links. IP (over/under or through) these
links uses a source and destination IP and any hardware
addressing scheme is incidental.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: Router stops routing after changing MAC Address
From: Bjørn Mork @ 2006-03-14 14:16 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In-Reply-To: <Pine.LNX.4.61.0603131513380.5373@chaos.analogic.com>
"linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:
> Actually, it doesn't make any difference. Changing the IEEE station
> (physical) address is not an allowed procedure even though hooks are
> available in many drivers to do this.
Of course it is. It's even required to support some obsolete
networking protocols. You could start with
Documentation/networking/decnet.txt if you don't want to STFW
Bjørn
--
I mean, you're always totally wrong.
^ permalink raw reply
* Re: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
From: Michael Buesch @ 2006-03-14 14:30 UTC (permalink / raw)
To: Adrian Bunk; +Cc: jkmaline, hostap, netdev, linux-kernel
In-Reply-To: <20060313222841.GQ13973@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Monday 13 March 2006 23:28, you wrote:
> This patch fixes two memotry leaks spotted by the Coverity checker.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> drivers/net/wireless/hostap/hostap_pci.c | 6 +++---
> drivers/net/wireless/hostap/hostap_plx.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> --- linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_pci.c.old 2006-03-13 22:34:30.000000000 +0100
> +++ linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_pci.c 2006-03-13 22:37:57.000000000 +0100
> @@ -301,14 +301,14 @@ static int prism2_pci_probe(struct pci_d
> struct hostap_interface *iface;
> struct hostap_pci_priv *hw_priv;
>
> + if (pci_enable_device(pdev))
> + return -EIO;
> +
> hw_priv = kmalloc(sizeof(*hw_priv), GFP_KERNEL);
> if (hw_priv == NULL)
+ pci_disable_device(pdev);
> return -ENOMEM;
> memset(hw_priv, 0, sizeof(*hw_priv));
>
> - if (pci_enable_device(pdev))
> - return -EIO;
> -
> phymem = pci_resource_start(pdev, 0);
>
> if (!request_mem_region(phymem, pci_resource_len(pdev, 0), "Prism2")) {
> --- linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_plx.c.old 2006-03-13 22:39:40.000000000 +0100
> +++ linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_plx.c 2006-03-13 22:40:09.000000000 +0100
> @@ -446,14 +446,14 @@ static int prism2_plx_probe(struct pci_d
> int tmd7160;
> struct hostap_plx_priv *hw_priv;
>
> + if (pci_enable_device(pdev))
> + return -EIO;
> +
> hw_priv = kmalloc(sizeof(*hw_priv), GFP_KERNEL);
> if (hw_priv == NULL)
Seems like pci_disable_device should be done here, too.
> return -ENOMEM;
> memset(hw_priv, 0, sizeof(*hw_priv));
>
> - if (pci_enable_device(pdev))
> - return -EIO;
> -
> /* National Datacomm NCP130 based on TMD7160, not PLX9052. */
> tmd7160 = (pdev->vendor == 0x15e8) && (pdev->device == 0x0131);
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: Router stops routing after changing MAC Address
From: Greg Scott @ 2006-03-14 15:30 UTC (permalink / raw)
To: linux-os (Dick Johnson), Bart Samwel
Cc: Rick Jones, Chuck Ebbert, linux-kernel, netdev, Alan Cox,
Simon Mackinlay
Yet I have real-world examples I've seen with my own eyes where MAC
Address problems have messed up bridged networks. I posted some of
those here yesterday. Good old Ethernet MAC Addresses can and do play a
real role in these wide area networks.
Don't believe me? Try it yourself. Find a LAN connected to the
Internet via bridged DSL or cablemodem with a real firewall in place.
Swap the firewall and wait...and wait...and wait some more for ARP
caches to clear on the other end.
When nothing changes but the passage of time and traffic starts to flow
again - and the Internet service is bridged not routed - give me another
explanation besides ARP caches.
- Greg
-----Original Message-----
From: linux-os (Dick Johnson) [mailto:linux-os@analogic.com]
Sent: Tuesday, March 14, 2006 6:53 AM
To: Bart Samwel
Cc: Greg Scott; Rick Jones; Chuck Ebbert; linux-kernel;
netdev@vger.kernel.org; Alan Cox; Simon Mackinlay
Subject: Re: Router stops routing after changing MAC Address
On Tue, 14 Mar 2006, Bart Samwel wrote:
> linux-os (Dick Johnson) wrote:
>> On Mon, 13 Mar 2006, Greg Scott wrote:
>> Bzzzzst... Not! There are not any MAC addresses associated with any
>> of the intercity links, usually not even in WANs! MAC is for
>> Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC
addresses.
>
> Bzzzzt. According to WikiPedia:
>
> http://en.wikipedia.org/wiki/MAC_address
>
> MAC addresses are used for:
>
> - Token ring
> - 802.11 wireless networks
> - Bluetooth
> - FDDI
> - ATM (switched virtual connections only, as part of an NSAP address)
> - SCSI and Fibre Channel (as part of a World Wide Name)
>
> FDDI = fiber, ATM = ATM.
>
> --Bart
>
A name is NOT. I can call my mail route number RFD#2 a MAC address.
Also token-ring is a form of Ethernet as are all known wireless networks
unless they use light. Even cable modems use Ethernet, with FDM on the
cable side and baseband on the customer side. Calling SCSI MAC is
absurd. All of the above, except the ethernets are forms of
point-to-point communications links. IP (over/under or through) these
links uses a source and destination IP and any hardware addressing
scheme is incidental.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of
this information by persons or entities other than the intended
recipient is prohibited. If you are not the intended recipient, please
notify Analogic Corporation immediately - by replying to this message or
by sending an email to DeliveryErrors@analogic.com - and destroy all
copies of this information, including any attachments, without reading
or disclosing them.
Thank you.
^ permalink raw reply
* Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
From: Pavel Machek @ 2006-03-14 22:13 UTC (permalink / raw)
To: Chris Leech; +Cc: linux-kernel, netdev
In-Reply-To: <20060311022919.3950.43835.stgit@gitlost.site>
Hi!
> --- /dev/null
> +++ b/drivers/dma/dmaengine.c
> @@ -0,0 +1,360 @@
> +/*****************************************************************************
> +Copyright(c) 2004 - 2006 Intel Corporation. All rights reserved.
> +
> +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., 59
> +Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> +
> +The full GNU General Public License is included in this distribution in the
> +file called LICENSE.
> +*****************************************************************************/
Could you use
/*
*
*/
comment style, and describe in one or two lines what the source does
in the header?
Pavel
--
209:using System.IO;
^ permalink raw reply
* Re: Router stops routing after changing MAC Address
From: Valdis.Kletnieks @ 2006-03-14 23:57 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: Greg Scott, Rick Jones, Chuck Ebbert, linux-kernel, netdev,
Bart Samwel, Alan Cox, Simon Mackinlay
In-Reply-To: <Pine.LNX.4.61.0603131730100.5785@chaos.analogic.com>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
On Mon, 13 Mar 2006 17:35:50 EST, "linux-os (Dick Johnson)" said:
> Bzzzzst... Not! There are not any MAC addresses associated with any
> of the intercity links, usually not even in WANs! MAC is for
> Ethernet! Once you go to fiber, ATM, T-N, etc., there are no
> MAC addresses.
This will come as a big surprise to those places running Gig-E and 10G-E
links into a fiber for long-haul cross-country connectivity.....
[-- Attachment #2: Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [-mm patch] make drivers/net/tg3.c:tg3_request_irq()
From: David S. Miller @ 2006-03-15 1:04 UTC (permalink / raw)
To: bunk; +Cc: akpm, linux-kernel, netdev, jgarzik
In-Reply-To: <20060313212602.GL13973@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Mon, 13 Mar 2006 22:26:02 +0100
> This patch makes the needlessly global function tg3_request_irq()
> static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [2.6 patch] net/decnet/dn_route.c: fix inconsequent NULL checking
From: David S. Miller @ 2006-03-15 1:06 UTC (permalink / raw)
To: bunk; +Cc: patrick, linux-decnet-user, netdev, linux-kernel
In-Reply-To: <20060310230233.GB21864@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Sat, 11 Mar 2006 00:02:33 +0100
> The Coverity checker noted this inconsequent NULL checking in
> dnrt_drop().
>
> Since all callers ensure that NULL isn't passed, we can simply remove
> the check.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
From: Jouni Malinen @ 2006-03-15 3:16 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, hostap, linux-kernel
In-Reply-To: <20060313222841.GQ13973@stusta.de>
On Mon, Mar 13, 2006 at 11:28:41PM +0100, Adrian Bunk wrote:
> This patch fixes two memotry leaks spotted by the Coverity checker.
Thanks. I'll make a bit different patch to resolve this and related PCI
"leaks" in one change. I'm going through the Coverity reports for Host
AP driver, so I'll include other fixes in a patch set, too.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
From: Adrian Bunk @ 2006-03-15 16:14 UTC (permalink / raw)
To: hostap, netdev, linux-kernel; +Cc: Herbert Xu
In-Reply-To: <20060315031625.GE9384@jm.kir.nu>
On Tue, Mar 14, 2006 at 07:16:25PM -0800, Jouni Malinen wrote:
> On Mon, Mar 13, 2006 at 11:28:41PM +0100, Adrian Bunk wrote:
> > This patch fixes two memotry leaks spotted by the Coverity checker.
>
> Thanks. I'll make a bit different patch to resolve this and related PCI
> "leaks" in one change. I'm going through the Coverity reports for Host
> AP driver, so I'll include other fixes in a patch set, too.
Thanks (I assume you've seem Herbert's comment why my patch was wrong).
> Jouni Malinen PGP id EFC895FA
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
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