Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Jan Engelhardt]

On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
>> > --- a/net/netfilter/x_tables.c
>> > +++ b/net/netfilter/x_tables.c
>> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned 
>> > int size)
>> > * than shoot all processes down before realizing there is nothing
>> > * more to reclaim.
>> > */
>> > -  info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
>> > +  info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
>> >if (!info)
>> >return NULL;
>>
>> I am curious, what particular path does not later overwrite the whole zone ?
>
>In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
>can be larger than the size of the structure itself.
>
>Then the data is copied to userspace in copy_entries_to_user() for ipv4
>and v6, and that's where the "bad data"

If the kernel incorrectly copies more bytes than it should, isn't that
a sign that may be going going past the end of the info buffer?
(And thus, zeroing won't truly fix the issue)

And if the kernel copies too few (because it just does not have more
data than userspace is requesting), what remains in the user buffer
is the garbage that originally was there.

Re: [PATCH RFC 0/4] net: add bpfilter

[Jan Engelhardt]

On Monday 2018-02-19 16:32, David Miller wrote:

>From: Harald Welte 
>Date: Mon, 19 Feb 2018 16:23:21 +0100
>
>> Also, as long as legacy ip_tables/x_tables is still in the kernel, you
>> can still run your old userspace against that old implementation in the
>> kernel.
>
>But without offloading, and the various other benefits which I have
>tried to clearly explain to both you and Florian.

Which is actually the business model to get people *off* the old ABI in 
reasonable time. Otherwise, we would have to ask ourselves why we have 
not yet enhanced /dev/raw with mmap and whatnot.

Re: [PATCH net] netfilter: xt_hashlimit: do not allow empty names

[Jan Engelhardt]

On Friday 2018-02-02 12:55, Pablo Neira Ayuso wrote:

>On Fri, Feb 02, 2018 at 12:49:38PM +0100, Pablo Neira Ayuso wrote:
>[...]
>> bool net_valid_name(const char *name, size_t len)
>> {
>> ...
>> }
>
>Am I missing anything in all these tricky string handling? Thanks!

One will have to watch out for calls like

net_valid_name(NLA_DATA(some_ifla_name), IFNAMSIZ)

because quite some nlattrs (IFLA_NAME, IFLA_IFNAME to boot) are NLA_STRINGs
(rather than NLA_NUL_STRINGs) and they are not \0-terminated.

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

[Jan Engelhardt]

On Monday 2018-01-29 17:57, Florian Westphal wrote:
>> > > vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back
>> > > off when the current task is killed") but then became unkillable by 
>> > > commit
>> > > b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is
>> > > killed""). Therefore, we can't handle this problem from MM side.
>> > > Please consider adding some limit from networking side.
>> > 
>> > I don't know what "some limit" would be.  I would prefer if there was
>> > a way to supress OOM Killer in first place so we can just -ENOMEM user.
>> 
>> Just supressing OOM kill is a bad idea. We still leave a way to allocate
>> arbitrary large buffer in kernel.

At the very least, mm could limit that kind of "arbitrary". If the machine has
x GB (swap included) and the admin tries to make the kernel allocate space for
an x GB ruleset, no way is it going to be satisfiable _even with OOM_.

>I think we should try to allocate whatever amount of memory is needed
>for the given xtables ruleset, given that is what admin requested us to do.

Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?

[Jan Engelhardt]

On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>
>One way to fix is to have iptables open the object (using the stored
>xt_bpf_info_v1->path), gaining a new process local fd for the object,
>just after getting the rules from IPT_SO_GET_ENTRIES.
>However we didn't see any other extensions doing something like that in
>iptables.
>
>Another way to solve is to fix the ABI (or have a v2 one), that does NOT
>pass the fd from userspace, only the path of the pinned object.
>Then, 'bpf_mt_check_v1' will open the file from the given path in order
>to get the bpf_prog.

But a path has a similar problem like a file descriptor - it is local to a
certain mount namespace.

To load "large" blobs into the kernel, a pointer to user memory is a possible
option. The downside is that such extra data is not retrievable from the kernel
via the iptables setsockopts anymore - one could work around it with procfs, or
just let it be.

https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_geoip.c
line 64+.

Re: net-next STATUS page

[Jan Engelhardt]

On Thursday 2017-07-13 13:32, Saeed Mahameed wrote:
>>>
 Therefore, in order to avoid any and all confusion I have created this
 web site:

  http://vger.kernel.org/~davem/net-next.html
>
> You will need an image processing algorithm to determine whether it is open or
> close, i have some good neural network algorithms if you are interested :)

That's not going to win any hacker prize.

A much more resource-saving approach is to just strcasestr(s, "closed") 
in the raw text. …at least while the page maintainer remains 
good-hearted.

Re: [PATCH] net: netfilter: Replace explicit NULL comparisons

[Jan Engelhardt]

On Sunday 2017-04-09 05:42, Arushi Singhal wrote:
>On Sun, Apr 9, 2017 at 1:44 AM, Pablo Neira Ayuso <pa...@netfilter.org> wrote:
>  On Sat, Apr 08, 2017 at 08:21:56PM +0200, Jan Engelhardt wrote:
>  > On Saturday 2017-04-08 19:21, Arushi Singhal wrote:
>  >
>  > >Replace explicit NULL comparison with ! operator to simplify code.
>  >
>  > I still wouldn't do this, for the same reason as before. Comparing to
>  > NULL explicitly more or less gave an extra guarantee that the other
>  > operand was also a pointer.
>
>  Arushi, where does it say in the coding style that this is prefered? 
>
>This is reported by checkpatch.pl script.

checkpatch has been controversial at times, like when people took the 80
character limit way too literally. Changing pointer comparisons looks like
another thing that is better left ignored.

Re: [PATCH] net: netfilter: Replace explicit NULL comparisons

[Jan Engelhardt]

On Saturday 2017-04-08 19:21, Arushi Singhal wrote:

>Replace explicit NULL comparison with ! operator to simplify code.

I still wouldn't do this, for the same reason as before. Comparing to 
NULL explicitly more or less gave an extra guarantee that the other 
operand was also a pointer.

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Wednesday 2017-03-29 11:15, SIMRAN SINGHAL wrote:
>>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>>-  if (dest == NULL)
>>+  if (!dest)
>>   return -ENOMEM;
>
>But, according to me we should prefer !var over ( var ==NULL ) according to the
>coding style

Where does it say that?

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Tuesday 2017-03-28 18:23, SIMRAN SINGHAL wrote:
>On Tue, Mar 28, 2017 at 7:24 PM, Jan Engelhardt <jeng...@inai.de> wrote:
>> On Tuesday 2017-03-28 15:13, simran singhal wrote:
>>
>>>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>>>represents failure, !x is commonly used.
>>>
>>>@@ -910,7 +910,7 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct 
>>>ip_vs_dest_user_kern *udest,
>>>   }
>>>
>>>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>>>-  if (dest == NULL)
>>>+  if (!dest)
>>>   return -ENOMEM;
>>
>> This kind of transformation however is not cleanup anymore, it's really
>> bikeshedding and should be avoided. There are pro and cons for both
>> variants, and there is not really an overwhelming number of arguments
>> for either variant to justify the change.
>
>Sorry, but I didn't get what you are trying to convey. And particularly pros 
>and
>cons of both variants.

The ==NULL/!=NULL part sort of ensures that the left side is a pointer, which
is lost when just using the variable and have it implicitly convert to bool.

Re: [PATCH] netfilter: ipset: Use max macro instead of ternary operator

[Jan Engelhardt]

On Tuesday 2017-03-28 15:32, simran singhal wrote:

>This patch replaces ternary operator with macro max as it shorter and
>thus increases code readability.
>
>-  return (ret < 0 ? 0 : ret);
>+  return max(0, ret);

While the two are functionally equivalent, "max" conveys a meaning of 
"upper bound" (think ceil(3)), i.e. a _count of something_, but the 
function still returns a logical "error or bool".

Such a change may be usable in an IOCCC or a codegolf contest,
but it destroys rather than improves readability IMHO.

Re: [PATCH v2] netfilter: Clean up tests if NULL returned on failure

[Jan Engelhardt]

On Tuesday 2017-03-28 15:13, simran singhal wrote:

>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>represents failure, !x is commonly used.
>
>@@ -910,7 +910,7 @@ ip_vs_new_dest(struct ip_vs_service *svc, struct 
>ip_vs_dest_user_kern *udest,
>   }
> 
>   dest = kzalloc(sizeof(struct ip_vs_dest), GFP_KERNEL);
>-  if (dest == NULL)
>+  if (!dest)
>   return -ENOMEM;

This kind of transformation however is not cleanup anymore, it's really 
bikeshedding and should be avoided. There are pro and cons for both 
variants, and there is not really an overwhelming number of arguments 
for either variant to justify the change.

Re: [PATCH] net: Remove unnecessary cast on void pointer

[Jan Engelhardt]

On Tuesday 2017-03-28 14:50, simran singhal wrote:

>The following Coccinelle script was used to detect this:
>@r@
>expression x;
>void* e;
>type T;
>identifier f;
>@@
>(
>  *((T *)e)
>|
>  ((T *)x)[...]
>|
>  ((T*)x)->f
>|
>
>- (T*)
>  e
>)
>
>Signed-off-by: simran singhal 
>---
> net/bridge/netfilter/ebtables.c |  2 +-
> net/ipv4/netfilter/arp_tables.c | 20 
> net/ipv4/netfilter/ip_tables.c  | 20 
> net/ipv6/netfilter/ip6_tables.c | 20 
> net/netfilter/ipset/ip_set_bitmap_gen.h |  4 ++--
> net/netfilter/ipset/ip_set_core.c   |  2 +-
> net/netfilter/nf_conntrack_proto.c  |  2 +-
> net/netfilter/nft_set_hash.c|  2 +-
> net/netfilter/xt_hashlimit.c| 10 +-
> 9 files changed, 35 insertions(+), 47 deletions(-)
>
>diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
>index 79b6991..bdc629e 100644
>--- a/net/bridge/netfilter/ebtables.c
>+++ b/net/bridge/netfilter/ebtables.c
>@@ -1713,7 +1713,7 @@ static int compat_copy_entry_to_user(struct ebt_entry 
>*e, void __user **dstptr,
>   if (*size < sizeof(*ce))
>   return -EINVAL;
> 
>-  ce = (struct ebt_entry __user *)*dstptr;
>+  ce = *dstptr;
>   if (copy_to_user(ce, e, sizeof(*ce)))
>   return -EFAULT;
> 
>diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
>index 6241a81..f046c12 100644
>--- a/net/ipv4/netfilter/arp_tables.c
>+++ b/net/ipv4/netfilter/arp_tables.c
>@@ -310,7 +310,7 @@ static int mark_source_chains(const struct xt_table_info 
>*newinfo,
>   for (hook = 0; hook < NF_ARP_NUMHOOKS; hook++) {
>   unsigned int pos = newinfo->hook_entry[hook];
>   struct arpt_entry *e
>-  = (struct arpt_entry *)(entry0 + pos);
>+  = (entry0 + pos);

At this point you can also drop the now-unnecessary parentheses in all 
the lines you changed.

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Jan Engelhardt]

On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:

>Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>>> Regularly, when a new header is created in include/uapi/, the developer
>>> forgets to add it in the corresponding Kbuild file. This error is usually
>>> detected after the release is out.
>>>
>>> In fact, all headers under uapi directories should be exported, thus it's
>>> useless to have an exhaustive list.
>>>
>>> After this patch, the following files, which were not exported, are now
>>> exported (with make headers_install_all):
>> 
>> ... snip ...
>> 
>>> linux/genwqe/.install
>>> linux/genwqe/..install.cmd
>>> linux/cifs/.install
>>> linux/cifs/..install.cmd
>> 
>> I'm pretty sure these should not be exported!
>> 
>Those files are created in every directory:
>$ find usr/include/ -name '\.\.install.cmd' | wc -l
>71

That still does not mean they should be exported.

Anything but headers (and directories as a skeleton structure) is maximally 
suspicious.

Re: [PATCH v3 2/2] netfilter: Create revision 2 of xt_hashlimit to support higher pps rates

[Jan Engelhardt]

On Thursday 2016-09-22 18:43, Vishwanath Pai wrote:
>+struct hashlimit_cfg2 {
>+  __u32 mode;   /* bitmask of XT_HASHLIMIT_HASH_* */
>+  __u64 avg;/* Average secs between packets * scale */
>+  __u64 burst;  /* Period multiplier for upper limit. */

This would have different sizes between i386 and x86_64,
necessiting additional compat functions. It should be padded
or reordered instead.

>+
>+  /* user specified */
>+  __u32 size; /* how many buckets */
>+  __u32 max;  /* max number of entries */
>+  __u32 gc_interval;  /* gc interval */
>+  __u32 expire;   /* when do entries expire? */
>+
>+  __u8 srcmask, dstmask;
>+};
>+
>+struct xt_hashlimit_mtinfo2 {
>+  char name[NAME_MAX];
>+  struct hashlimit_cfg2 cfg;
>+
>+  /* Used internally by the kernel */
>+  struct xt_hashlimit_htable *hinfo __attribute__((aligned(8)));
>+};

Re: [PATCH 1116/1285] Replace numeric parameter like 0444 with macro

[Jan Engelhardt]

On Tuesday 2016-08-02 14:17, Baole Ni wrote:

>I find that the developers often just specified the numeric value
>when calling a macro which is defined with a parameter for access permission.
>As we know, these numeric value for access permission have had the 
>corresponding macro,
>and that using macro can improve the robustness and readability of the code,
>thus, I suggest replacing the numeric parameter with the macro.
>
> static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
>-module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, 0444);
>+module_param_named(conn_tab_bits, ip_vs_conn_tab_bits, int, S_IRUSR | S_IRGRP 
>| S_IROTH);

We have S_IRUGO for this.

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

[Jan Engelhardt]

On Monday 2016-03-28 21:29, David Miller wrote:
>>> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb,
>>> > >   length--;
>>> > >   continue;
>>> > >   default:
>>> > > +if (length < 2)
>>> > > +return;
>>> > >   opsize = *ptr++;
>>> > >   if (opsize < 2) /* "silly options" */
>>> > >   return;
>
>I'm trying to figure out how this can even matter.
>If we are in the loop, length is at least one.
>That means it is legal to read the opsize byte.

Is that because the skbuff is always padded to a multiple of (at
least) two? Maybe such padding is explicitly foregone when ASAN is in
place. After all, glibc, in userspace, is likely to do padding as
well for malloc, and yet, ASAN catches these cases.

RE: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Jan Engelhardt]

On Monday 2015-11-23 18:35, David Laight wrote:
>From: Florian Westphal
>> Sent: 21 November 2015 16:56
>> > +struct xt_cgroup_info_v1 {
>> > +  charpath[PATH_MAX];
>> > +  __u32   classid;
>> > +
>> > +  /* kernel internal data */
>> > +  void*priv __attribute__((aligned(8)));
>> > +};
>> 
>> Ahem.  Am I reading this right? This struct is > 4k in size?
>> If so -- Ugh.  Does sizeof(path) really have to be PATH_MAX?
>
>I've not looked at the use, but could you put 'char path[];'
>as the last member an require any allocations to be long enough
>to contain the actual path?

Oh, smart :)  Yeah, ebt_among does something like that.
(.matchsize = -1, hint)

Except that the "priv" pointer seems to be ruining the fun here -
kernel vars have to be last, which collides with the requirements
for []-type members.
--
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: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

[Jan Engelhardt]

On Saturday 2015-11-21 19:54, Florian Westphal wrote:
>
>The only other question I have is wheter PATH_MAX might be a possible
>ABI breaker in future.  It would have to be guaranteed that this is the
>same size forever, else you'd get strange errors on rule insertion if
>the sizes of the kernel and userspace version differs.
>
The same goes for IFNAMSIZ. But, so far, nobody changed it in the kernel,
even though there are voices that 15 characters + '\0' were a tight choice.
--
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: [PATCH 1/5] cgroup: record ancestor IDs and reimplement cgroup_is_descendant() using it

[Jan Engelhardt]

On Tuesday 2015-11-17 20:40, Tejun Heo wrote:
>+static inline bool cgroup_is_descendant(struct cgroup *cgrp,
>+  struct cgroup *ancestor)

(const struct group *cgrp, const struct group *ancestor)

>+{
>+  if (cgrp->root != ancestor->root || cgrp->level < ancestor->level)
>+  return false;
>+  return cgrp->ancestor_ids[ancestor->level] == ancestor->id;
>+}
--
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: [PATCH iptables] libxt_cgroup2: add support for cgroup2 path matching

[Jan Engelhardt]

On Tuesday 2015-11-17 20:42, Tejun Heo wrote:
>+static void cgroup2_save(const void *ip, const struct xt_entry_match *match)
>+{
>+  const struct xt_cgroup2_info *info = (void *)match->data;
>+
>+  printf("%s --path %s", info->invert ? " !" : "", info->path);
>+}

Can cgroup path names contain anything fancy, like spaces, backslashes, etc.?
If so, xtables_save_string() will be needed here.

>+static struct xtables_match cgroup2_match = {
>+  .family = NFPROTO_UNSPEC,
>+  .name   = "cgroup2",
>+  .version= XTABLES_VERSION,
>+  .size   = XT_ALIGN(sizeof(struct xt_cgroup2_info)),
>+  .userspacesize  = XT_ALIGN(sizeof(struct xt_cgroup2_info)),

userspacesize must not include xt_cgroup2_info.priv.
Change to offsetof(...), cf. other .c modules which do this.


>+++ b/extensions/libxt_cgroup2.man
>@@ -0,0 +1,24 @@
>+.TP
>+[\fB!\fP] \fB\-\-path\fP \fIpath\fP
>+Match cgroup2 membership.
>+
>+Each socket is associated with the v2 cgroup of the creating process.
>+This matches packets coming from or going to all sockets in the
>+sub-hierarchy of the specified path.  The path should be relative to
>+the root of the cgroup2 hierarchy.  Can be used in the OUTPUT and
>+INPUT chains to assign particular firewall policies for aggregated
>+processes on the system. This allows for more fine-grained firewall
>+policies that only match for a subset of the system's processes.
>+
>+\fBIMPORTANT\fP: when being used in the INPUT chain, the cgroup2
>+matcher is currently only of limited functionality, meaning it
>+will only match on packets that are processed for local sockets
>+through early socket demuxing. Therefore, general usage on the
>+INPUT chain is disadviced unless the implications are well

is disadviced (sic)  -> is not advised
--
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: [PATCH 2/5] kernfs: implement kernfs_walk_and_get()

[Jan Engelhardt]

On Tuesday 2015-11-17 22:20, David Miller wrote:
>> +static char path_buf[PATH_MAX]; /* protected by kernfs_mutex */
>> +int len = strlen(path);
> ...
>> +if (len >= PATH_MAX)
>> +return NULL;
>> +
>> +memcpy(path_buf, path, len + 1);
>
>   static char path_buf[PATH_MAX]; /* protected by kernfs_mutex */
>   int len = strlcpy(path_buf, path, PATH_MAX);
> ...
>   if (len >= PATH_MAX)
>   return NULL;

if (len < 0 || len >= PATH_MAX)

strlcpy returns a size_t, which, when coerced into an int, could lead to
negative numbers. In that sense, "size_t len" probably seems like an even
better bet yet.
--
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: [PATCH 5/5] netfilter: implement xt_cgroup2 match

[Jan Engelhardt]

On Tuesday 2015-11-17 20:40, Tejun Heo wrote:
>@@ -0,0 +1,14 @@
>+#ifndef _XT_CGROUP2_H
>+#define _XT_CGROUP2_H
>+
>+#include 
>+
>+struct xt_cgroup2_info {
>+  charpath[PATH_MAX];
>+  __u8invert;

Should  be included? (For PATH_MAX)

>+  /* kernel internal data */
>+  void*priv;
>+};

void *priv __attribute__((aligned(8)));

>+static bool cgroup2_mt(const struct sk_buff *skb, struct xt_action_param *par)
>+{
>+  const struct xt_cgroup2_info *info = par->matchinfo;
>+  struct cgroup *ancestor = info->priv;

There is no modification planned on the cgroup, so this too can be const struct
cgroup * if-and-when cgroup_is_descendant is made to take const ptrs as well.

>+  if (!skb->sk || !sk_fullsock(skb->sk))
>+  return false;
>+
>+  return cgroup_is_descendant(skb->sk->sk_cgroup, ancestor) ^ 
>info->invert;
>+}

--
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: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type

[Jan Engelhardt]

On Wednesday 2015-09-30 09:24, Daniel Mack wrote:
>
>> Drop?  Makes no sense, else application would not be running in the first
>> place.
>
>Of course you can drop certain packets at this point, depending on other
>details. Say, for instance, you want to match all packets that are
>received by a certain task [...]
>Another use case is accounting. If you want to know how much traffic a
>certain service or application in your system has caused

But the sk info would be available in INPUT already, would it not?
--
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: [ANNOUNCE] libnftnl 1.0.4 release

[Jan Engelhardt]

On Wednesday 2015-09-16 13:50, Pablo Neira Ayuso wrote:
>The Netfilter project proudly presents:
>
>libnftnl 1.0.4

$ git diff libnftnl-1.0.3..libnftnl-1.0.4 src/libnftnl.map
diff --git a/src/libnftnl.map b/src/libnftnl.map
index be7b998..14ec88c 100644
--- a/src/libnftnl.map
+++ b/src/libnftnl.map
@@ -124,10 +123,12 @@ global:
   nft_set_attr_is_set;
   nft_set_attr_set;
   nft_set_attr_set_u32;
+  nft_set_attr_set_u64;
   nft_set_attr_set_str;
   nft_set_attr_get;
   nft_set_attr_get_str;
   nft_set_attr_get_u32;
+  nft_set_attr_get_u64;
   nft_set_nlmsg_build_payload;
   nft_set_nlmsg_parse;
   nft_set_parse;

You broke the ABI. A program that uses nft_set_attr_set_u64 and is
built against libnftnl-1.0.4 is marked to be compatible with the
"LIBNFTNL_1.0" symbol group, but this is incorrect, since the
nft_set_attr_set_u64 symbol did not previously exist.

Existing symbol groups in .map must not be extended. Always start
a new group.
--
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

[PATCH] build: must honor pkg-config flags for libmnl

[Jan Engelhardt]

The build otherwise fails if libmnl does not directly live in a
standard search path.
---
 tipc/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tipc/Makefile b/tipc/Makefile
index 4bda8c5..d4637f8 100644
--- a/tipc/Makefile
+++ b/tipc/Makefile
@@ -5,8 +5,11 @@ TIPCOBJ=bearer.o \
 node.o socket.o \
 tipc.o
 
+include ../Config
+
 TARGETS=tipc
-LDLIBS += -lmnl
+CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
+LDLIBS += $(shell $(PKG_CONFIG) libmnl --libs)
 
 all: $(TARGETS) $(LIBS)
 
-- 
2.4.3

--
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: [PATCH 2/4] netfilter: default CONFIG_NETFILTER_INGRESS to y

[Jan Engelhardt]

On Friday 2015-05-29 01:44, Pablo Neira Ayuso wrote:

Useful to compile-test all options.

--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -3,6 +3,7 @@ menu Core Netfilter Configuration
 
 config NETFILTER_INGRESS
   bool Netfilter ingress support
+  default y
   select NET_INGRESS
   help
 This allows you to classify packets from ingress using the Netfilter

Careful with default y. I seem to remember that someone higher up
(perhaps Linus himself) was against default y for features deemed
not essential (especially hardware drivers), as no driver is any
more important than another. If compile-test is your reason for the
patch, it might fall into the same category.
--
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

lockdep warnings in ipv6

[Jan Engelhardt]

Hi,


when doing IPv6 (ping6, ssh otherhost, etc.), lockdep spews a warning in 
2.6.25-rc2 on the target. CONFIG_..._FRAME_POINTER is off,

CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_FRAME_POINTER is not set

so I am not sure if the stack trace is worth something, is it?

[  449.168320] ===
[  449.168637] [ INFO: possible circular locking dependency detected ]
[  449.168851] 2.6.25-rc2 #67
[  449.168951] ---
[  449.169078] swapper/0 is trying to acquire lock:
[  449.169315]  (tbl-lock){-+-+}, at: [c023d5a3] 
neigh_lookup+0x43/0xb0
[  449.170147] 
[  449.170150] but task is already holding lock:
[  449.170309]  (n-lock){-+-+}, at: [c023f975] 
neigh_timer_handler+0x15/0x2a0
[  449.170512] 
[  449.170514] which lock already depends on the new lock.
[  449.170516] 
[  449.170736] 
[  449.170738] the existing dependency chain (in reverse order) is:
[  449.170926] 
[  449.170927] - #1 (n-lock){-+-+}:
[  449.171188][c0132266] add_lock_to_list+0x46/0xc0
[  449.171509][c0134c48] __lock_acquire+0xb48/0xf90
[  449.171678][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.171849][c01350ef] lock_acquire+0x5f/0x80
[  449.172007][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.172173][c029b239] _write_lock+0x29/0x40
[  449.172342][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.172508][c023dcda] neigh_periodic_timer+0x7a/0x170
[  449.172670][c011dd5f] run_timer_softirq+0x15f/0x1c0
[  449.172984][c023dc60] neigh_periodic_timer+0x0/0x170
[  449.173180][c023dc60] neigh_periodic_timer+0x0/0x170
[  449.173349][c011a182] __do_softirq+0x52/0xb0
[  449.173516][c011a225] do_softirq+0x45/0x50
[  449.173675][c011a665] irq_exit+0x55/0x70
[  449.173831][c0104e83] do_IRQ+0x43/0x90
[  449.173987][c0103214] common_interrupt+0x24/0x40
[  449.174147][c010321e] common_interrupt+0x2e/0x40
[  449.174308][] 0x
[  449.174767] 
[  449.174769] - #0 (tbl-lock){-+-+}:
[  449.174939][c01324f0] print_circular_bug_entry+0x40/0x50
[  449.175108][c0134a71] __lock_acquire+0x971/0xf90
[  449.175268][c013425e] __lock_acquire+0x15e/0xf90
[  449.175468][c0133c16] trace_hardirqs_on+0x66/0x110
[  449.175633][c01350ef] lock_acquire+0x5f/0x80
[  449.175793][c023d5a3] neigh_lookup+0x43/0xb0
[  449.175973][c029b2fe] _read_lock_bh+0x2e/0x40
[  449.176139][c023d5a3] neigh_lookup+0x43/0xb0
[  449.176303][c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821][c8a74a8c] ndisc_dst_alloc+0x13c/0x1a0 [ipv6]
[  449.177821][c8a74950] ndisc_dst_alloc+0x0/0x1a0 [ipv6]
[  449.177821][c8a78575] __ndisc_send+0x95/0x4e0 [ipv6]
[  449.177821][c8a67410] ip6_output+0x0/0xb00 [ipv6]
[  449.177821][c8a79467] ndisc_send_ns+0x67/0xa0 [ipv6]
[  449.177821][c8a6eeb0] ipv6_chk_addr+0xa0/0xb0 [ipv6]
[  449.177821][c8a7a4ef] ndisc_solicit+0x9f/0x1b0 [ipv6]
[  449.177821][c0133af8] mark_held_locks+0x38/0x70
[  449.177821][c029b665] _spin_unlock_irqrestore+0x45/0x60
[  449.177821][c0133c16] trace_hardirqs_on+0x66/0x110
[  449.177821][c023fab5] neigh_timer_handler+0x155/0x2a0
[  449.177821][c011dd5f] run_timer_softirq+0x15f/0x1c0
[  449.177821][c023f960] neigh_timer_handler+0x0/0x2a0
[  449.177821][c023f960] neigh_timer_handler+0x0/0x2a0
[  449.177821][c011a182] __do_softirq+0x52/0xb0
[  449.177821][c011a225] do_softirq+0x45/0x50
[  449.177821][c011a665] irq_exit+0x55/0x70
[  449.177821][c0104e83] do_IRQ+0x43/0x90
[  449.177821][c0103214] common_interrupt+0x24/0x40
[  449.177821][c010321e] common_interrupt+0x2e/0x40
[  449.177821][c0101ace] default_idle+0x5e/0x90
[  449.177821][c0101a70] default_idle+0x0/0x90
[  449.177821][c0101910] cpu_idle+0x30/0x80
[  449.177821][] 0x
[  449.177821] 
[  449.177821] other info that might help us debug this:
[  449.177821] 
[  449.177821] 1 lock held by swapper/0:
[  449.177821]  #0:  (n-lock){-+-+}, at: [c023f975] 
neigh_timer_handler+0x15/0x2a0
[  449.177821] 
[  449.177821] stack backtrace:
[  449.177821] Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #67
[  449.177821]  [c0132d72] print_circular_bug_tail+0x72/0x80
[  449.177821]  [c0134a71] __lock_acquire+0x971/0xf90
[  449.177821]  [c013425e] __lock_acquire+0x15e/0xf90
[  449.177821]  [c0133c16] trace_hardirqs_on+0x66/0x110
[  449.177821]  [c01350ef] lock_acquire+0x5f/0x80
[  449.177821]  [c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821]  [c029b2fe] _read_lock_bh+0x2e/0x40
[  449.177821]  [c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821]  [c023d5a3] neigh_lookup+0x43/0xb0
[  449.177821]  [c8a74a8c] ndisc_dst_alloc+0x13c/0x1a0 [ipv6]
[  449.177821]  [c8a74950] 

Re: [NETFILTER]: Introduce nf_inet_address

[Jan Engelhardt]

On Feb 22 2008 16:44, Patrick McHardy wrote:
 Pablo Neira Ayuso wrote:
 Patrick McHardy wrote:
  Yes, that was a bug in the lastest release. We need to
  release a 1.4.1 version or something like that, but I'm
  not too familiar with the release process, so I haven't
  done this so far.
 
 I can schedule one for this weekend, just send me an ACK.


 That would be great. I think we had another issue in 1.4.0 with
 some header files, but I can't remeber the details.

 Jan, I recall we talked about this some time ago, do you remember?

I dunno, in Xtables 1.5.1 all header problems (minus
the uint32_t all in nf_inet_addr) are resolved I believe.
The thing even compiles without a kernel source now.
--
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: [NETFILTER]: Introduce nf_inet_address

[Jan Engelhardt]

On Feb 19 2008 15:45, Patrick McHardy wrote:
 
 It's in busybox 1.9.1. Just including netinet/in.h seems to be
 sufficient to make it happy again. I wonder if netfilter.h should
 include that for itself?

 That would break iptables compilation, which already includes
 linux/in.h in some files. I guess the best fix for now is to
 include netinet/in.h in busybox and long-term clean this up
 properly.


If linux/netfilter.h includes linux/in.h, userspace compilation
fails (clashing defs, etc.); if linux/netfilter.h includes
netinet/in.h, kernel compilation fails (file not found).

What comes to mind is the ugly hack we had for a few days:

#ifdef __KERNEL__
#   include linux/in.h
#else
#   include netinet/in.h
#endif

and I think we should not impose any inclusion rules on userspace
this way.

Right now, it is solved this way:

kernel .c files explicitly include linux/in.h when loading
linux/netfilter.h,

userspace .c files explicitly includ netinet/in.h when loading
linux/netfilter.h. And that seems to work out.

--
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: [RFC PATCH 3/8] [NET]: uninline dev_alloc_skb, de-bloats a lot

[Jan Engelhardt]

On Feb 20 2008 15:47, Ilpo Järvinen wrote:

-23668  392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb

-static inline struct sk_buff *dev_alloc_skb(unsigned int length)
-{
-  return __dev_alloc_skb(length, GFP_ATOMIC);
-}
+extern struct sk_buff *dev_alloc_skb(unsigned int length);

Striking. How can this even happen? A callsite which calls

dev_alloc_skb(n)

is just equivalent to

__dev_alloc_skb(n, GFP_ATOMIC);

which means there's like 4 (or 8 if it's long) bytes more on the
stack. For a worst case, count in another 8 bytes for push and pop or mov on
the stack. But that still does not add up to 23 kb.
--
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: [RFC PATCH 3/8] [NET]: uninline dev_alloc_skb, de-bloats a lot

[Jan Engelhardt]

On Feb 20 2008 17:27, Patrick McHardy wrote:
 Striking. How can this even happen? A callsite which calls
 
  dev_alloc_skb(n)
 
 is just equivalent to
 
  __dev_alloc_skb(n, GFP_ATOMIC);
 
 which means there's like 4 (or 8 if it's long) bytes more on the
 stack. For a worst case, count in another 8 bytes for push and pop or mov on
 the stack. But that still does not add up to 23 kb.

 __dev_alloc_skb() is also an inline function which performs
 some extra work. Which raises the question - if dev_alloc_skb()
 is uninlined, shouldn't __dev_alloc_skb() be uninline as well?

I'd like to see the results when {__dev_alloc_skb is externed
and dev_alloc_skb remains inlined}.
--
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

Netfilter fixes to 2.6.24-git

[Jan Engelhardt]

Hi to everyone,


I have been unable to reach the netfilter and net maintainers the past 
week regarding inclusion of patches, but most importantly a group of 
fixes at [0]-[3]. I am kind of at a loss here but to turn up the volume 
and write to more people on how to proceed.

thanks,
Jan

[0] http://marc.info/?l=netfilter-develm=120230633916142w=2 (Overview)
[1] http://marc.info/?l=netfilter-develm=120230634016145w=2
[2] http://marc.info/?l=netfilter-develm=120230634216156w=2
[3] http://marc.info/?l=netfilter-develm=120230634616162w=2
--
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: [PATCH] Add IPv6 support to TCP SYN cookies

[Jan Engelhardt]

On Feb 5 2008 16:55, Andi Kleen wrote:
On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote:
 Add IPv6 support to TCP SYN cookies.  This is written and tested against
 2.6.24, and applies cleanly to linus' current HEAD (d2fc0b).  Unfortunately
 linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against
 that.  I see no reason why it would be affected though.  Comments/suggestions
 are welcome.

Syncookies are discouraged these days. They disable too many 
valuable TCP features (window scaling, SACK) and even without them 
the kernel is usually strong enough to defend against syn floods
and systems have much more memory than they used to be.

So I don't think it makes much sense to add more code to it, sorry.

Distributions should then probably deactivate it by default.
SUSE 10.3 for example still has it enabled on default installs.
--
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: [1/2] POHMELFS - network filesystem with local coherent cache.

[Jan Engelhardt]

On Jan 31 2008 22:17, Evgeniy Polyakov wrote:

POHMELFS stands for Parallel Optimized Host Message Exchange
Layered File System. It allows to mount remote servers to local
directory via network. This filesystem supports local caching
and writeback flushing.
POHMELFS is a brick in a future distributed filesystem.

A brick is usually something that is in the way -
Or you also say the user has bricked his machine
when it's quite unusable :)
Hope you did not mean /that/.

This set includes two patches:
 * network filesystem with write-through cache (slow, but works with
   remote userspace server)
 * hack to show how local cache works and how faster it is compared
   to async NFS (see below). hack disables writeback flush and
   performs local allocation of the objects only.

Now, some vaporware aka food for thoughts and your brains.

A small benchmark of the local cached mode (above hack):

$ time tar -xf /home/zbr/threading.tar

   POHMELFSNFS v3 (async)
real0m0.043s   0m1.679s

Which is damn 40 times!

Needs a bigger data set to compare. But what is much more
important: does it use a single port for networing, or some
firewall-unfriendly-by-default multiple dynamic-port-allocation
like NFS?

Next task is to think about how to generically solve the problem with
syncing local changes with remote server, when remote server maintains inodes 
with
completely different numbers.
This, among others, will allow offline work with automatic syncing after 
reconnect.

What will happen when both nodes change an inode in disconnected state?
Which inode wins out?

This is not intended for inclusion, CRFS by Zach Brown is a bit ahead of 
POHMELFS,
but it is not generic enough (because of above problem), works only with BTRFS,
and was closed by Oracle so far :)

btrfs is all we need :p


Where's the parallelism that is advertised by the POH in pohmelfs?
--
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: [PATCH] [SIS190] Constify data marked as __devinitdata

[Jan Engelhardt]

On Jan 30 2008 11:53, Jonas Bonn wrote:

This fixes build error as gcc complains about a section type conflict
due to the const __devinitdata in sis190_get_mac_addr_from_apc().

-static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
+static const struct pci_device_id sis190_pci_tbl[] __devinitdata = {
   { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
   { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
   { 0, },

Eh? Did you mean to

-static const u16 __devinitdata ids[] = { 0x0965, 0x0966, 0x0968 };
+static u16 __devinitdata ids[] = { 0x0965, 0x0966, 0x0968 };

instead? Because AFAIK, const *and* __sectionmarker does not mix.
--
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: [PATCH] [SIS190] Constify data marked as __devinitdata

[Jan Engelhardt]

On Jan 30 2008 12:25, Sam Ravnborg wrote:

We have just introduced __initconst, __cpuinitconst, __meminitconst
for const data.
So the patch is wrong.

Oh joy, more tags. Is it actually possible to combine const
with __devinitconst now?

static const uint16_t foo[] __devinitconst = { ... };
--
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: Udev coldplugging loads 8139too driver instead of 8139cp

[Jan Engelhardt]

On Jan 29 2008 18:34, Jon Masters wrote:
On Tue, 2008-01-29 at 03:46 +0300, Michael Tokarev wrote:

 Udev in fact loads both - 8139cp and 8139too.  The difference is the ORDER
 in which it loads them - if for cp-handled hardware it first loads too,
 too will complain as above and will NOT claim the device.  The same is
 true for the opposite.
[...]
 In short: NotABug, or ComplainToRealtec (but that's wy too late and
 will not help anyway) ;)

Nah. It's a bug insomuch as we don't handle multiple matching aliases
very well, and it's becoming more common, so we probably should :)

Why not combine 8139cp.c and 8139too.c?
--
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

[PATCH] [AF_X25]: constify function pointer tables

[Jan Engelhardt]

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
 net/x25/x25_proc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/x25/x25_proc.c b/net/x25/x25_proc.c
index 7d55e50..3faec8e 100644
--- a/net/x25/x25_proc.c
+++ b/net/x25/x25_proc.c
@@ -287,7 +287,7 @@ static const struct file_operations x25_seq_route_fops = {
.release= seq_release,
 };
 
-static struct file_operations x25_seq_forward_fops = {
+static const struct file_operations x25_seq_forward_fops = {
.owner  = THIS_MODULE,
.open   = x25_seq_forward_open,
.read   = seq_read,
-- 
1.5.3.4

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

[PATCH] [AF_RXRPC]: constify function pointer tables

[Jan Engelhardt]

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
 net/rxrpc/ar-call.c |2 +-
 net/rxrpc/ar-internal.h |6 +++---
 net/rxrpc/ar-proc.c |6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/rxrpc/ar-call.c b/net/rxrpc/ar-call.c
index 3c04b00..d923124 100644
--- a/net/rxrpc/ar-call.c
+++ b/net/rxrpc/ar-call.c
@@ -15,7 +15,7 @@
 #include net/af_rxrpc.h
 #include ar-internal.h
 
-const char *rxrpc_call_states[] = {
+const char *const rxrpc_call_states[] = {
[RXRPC_CALL_CLIENT_SEND_REQUEST]= ClSndReq,
[RXRPC_CALL_CLIENT_AWAIT_REPLY] = ClAwtRpl,
[RXRPC_CALL_CLIENT_RECV_REPLY]  = ClRcvRpl,
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 58aaf89..1aaa2e8 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -565,9 +565,9 @@ extern void __exit rxrpc_destroy_all_peers(void);
 /*
  * ar-proc.c
  */
-extern const char *rxrpc_call_states[];
-extern struct file_operations rxrpc_call_seq_fops;
-extern struct file_operations rxrpc_connection_seq_fops;
+extern const char *const rxrpc_call_states[];
+extern const struct file_operations rxrpc_call_seq_fops;
+extern const struct file_operations rxrpc_connection_seq_fops;
 
 /*
  * ar-recvmsg.c
diff --git a/net/rxrpc/ar-proc.c b/net/rxrpc/ar-proc.c
index 2e83ce3..83eda24 100644
--- a/net/rxrpc/ar-proc.c
+++ b/net/rxrpc/ar-proc.c
@@ -14,7 +14,7 @@
 #include net/af_rxrpc.h
 #include ar-internal.h
 
-static const char *rxrpc_conn_states[] = {
+static const char *const rxrpc_conn_states[] = {
[RXRPC_CONN_UNUSED] = Unused  ,
[RXRPC_CONN_CLIENT] = Client  ,
[RXRPC_CONN_SERVER_UNSECURED]   = SvUnsec ,
@@ -98,7 +98,7 @@ static int rxrpc_call_seq_open(struct inode *inode, struct 
file *file)
return seq_open(file, rxrpc_call_seq_ops);
 }
 
-struct file_operations rxrpc_call_seq_fops = {
+const struct file_operations rxrpc_call_seq_fops = {
.owner  = THIS_MODULE,
.open   = rxrpc_call_seq_open,
.read   = seq_read,
@@ -183,7 +183,7 @@ static int rxrpc_connection_seq_open(struct inode *inode, 
struct file *file)
return seq_open(file, rxrpc_connection_seq_ops);
 }
 
-struct file_operations rxrpc_connection_seq_fops = {
+const struct file_operations rxrpc_connection_seq_fops = {
.owner  = THIS_MODULE,
.open   = rxrpc_connection_seq_open,
.read   = seq_read,
-- 
1.5.3.4

--
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: [PATCH] IPv4: Enable use of 240/4 address space

[Jan Engelhardt]

On Jan 18 2008 11:13, YOSHIFUJI Hideaki / 吉藤英明 wrote:
 -static inline bool ipv4_is_badclass(__be32 addr)
 +static inline bool ipv4_is_broadcast(__be32 addr)
  {

I'm just afraid that people might think ipv4_is_broadcast
is for testing subnet broadcast address.

255.255.255.255 is limited broadcast address
(vs subnet broadcast address, which can be forwarded by routers).



From 84bccef295aa9754ee662191e32ba1d64edce2ba Mon Sep 17 00:00:00 2001
From: Jan Engelhardt [EMAIL PROTECTED]
Date: Fri, 18 Jan 2008 02:10:44 +0100
Subject: [PATCH] IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the
240.0.0.0/4 (aka class-E) address space as propsed in the internet
draft draft-fuller-240space-00.txt.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
 include/linux/in.h  |5 +++--
 include/net/addrconf.h  |2 +-
 net/core/pktgen.c   |2 +-
 net/ipv4/fib_frontend.c |2 +-
 net/ipv4/route.c|   12 ++--
 5 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/linux/in.h b/include/linux/in.h
index 27d8a5a..70c6df8 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -262,9 +262,10 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
return (addr  htonl(0xff00)) == htonl(0xe000);
 }
 
-static inline bool ipv4_is_badclass(__be32 addr)
+static inline bool ipv4_is_lbcast(__be32 addr)
 {
-   return (addr  htonl(0xf000)) == htonl(0xf000);
+   /* limited broadcast */
+   return addr == INADDR_BROADCAST;
 }
 
 static inline bool ipv4_is_zeronet(__be32 addr)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 8b1509b..496503c 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -262,7 +262,7 @@ static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
  ipv4_is_private_172(addr) || ipv4_is_test_192(addr) ||
  ipv4_is_anycast_6to4(addr) || ipv4_is_private_192(addr) ||
  ipv4_is_test_198(addr) || ipv4_is_multicast(addr) ||
- ipv4_is_badclass(addr)) ? 0x00 : 0x02;
+ ipv4_is_lbcast(addr)) ? 0x00 : 0x02;
eui[1] = 0;
eui[2] = 0x5E;
eui[3] = 0xFE;
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index d18fdb1..eebccdb 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2266,7 +2266,7 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
 
while (ipv4_is_loopback(s) ||
   ipv4_is_multicast(s) ||
-  ipv4_is_badclass(s) ||
+  ipv4_is_lbcast(s) ||
   ipv4_is_zeronet(s) ||
   ipv4_is_local_multicast(s)) {
t = random32() % (imx - imn) + 
imn;
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8ddcd3f..995b453 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -176,7 +176,7 @@ static inline unsigned __inet_dev_addr_type(struct net *net,
unsigned ret = RTN_BROADCAST;
struct fib_table *local_table;
 
-   if (ipv4_is_zeronet(addr) || ipv4_is_badclass(addr))
+   if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
return RTN_BROADCAST;
if (ipv4_is_multicast(addr))
return RTN_MULTICAST;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1e59c0d..1e484f7 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1154,7 +1154,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 
new_gw,
return;
 
if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
-   || ipv4_is_multicast(new_gw) || ipv4_is_badclass(new_gw)
+   || ipv4_is_multicast(new_gw) || ipv4_is_lbcast(new_gw)
|| ipv4_is_zeronet(new_gw))
goto reject_redirect;
 
@@ -1634,7 +1634,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 
daddr, __be32 saddr,
if (in_dev == NULL)
return -EINVAL;
 
-   if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+   if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
ipv4_is_loopback(saddr) || skb-protocol != htons(ETH_P_IP))
goto e_inval;
 
@@ -1891,7 +1891,7 @@ static int ip_route_input_slow(struct sk_buff *skb, 
__be32 daddr, __be32 saddr,
   by fib_lookup.
 */
 
-   if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+   if (ipv4_is_multicast(saddr) || ipv4_is_lbcast(saddr) ||
ipv4_is_loopback(saddr))
goto martian_source;
 
@@ -1904,7 +1904,7 @@ static int ip_route_input_slow(struct sk_buff *skb, 
__be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(saddr))
goto martian_source;
 
-   if (ipv4_is_badclass(daddr

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

[Jan Engelhardt]

On Jan 7 2008 17:10, Vince Fuller wrote:
--- net/ipv4/devinet.c.orig2007-04-12 10:16:23.0 -0700
+++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800
@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3
   rc = 16;
   else if (IN_CLASSC(haddr))
   rc = 24;
+  else if (IN_CLASSE(haddr))
+  rc = 24;
   }
 
   return rc;

Any particular reason why 24?
--
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

[PATCH] IPv4: Enable use of 240/4 address space

[Jan Engelhardt]

On Jan 7 2008 17:10, Vince Fuller wrote:

This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka class-E) address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.


Below is a patch against davem/net-2.6.25. It might look very spartan, 
but that is actually all that is needed on a sane system. No class E 
macros or so needed.

Only the ipv4_is_badclass() might need renaming if you think it really 
needs a name change. Or maybe a comment. Comments please :)

===
ancestor 7651a1f7ebe567f9088283f6354a5634b5dccb8e
commit 44762168d7cbefc4f8753a79d99a761cbd9875d9
Author: Jan Engelhardt [EMAIL PROTECTED]
Date:   Fri Jan 18 02:10:44 2008 +0100

IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the
240.0.0.0/4 (aka class-E) address space as propsed in the internet
draft draft-fuller-240space-00.txt.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

diff --git a/include/linux/in.h b/include/linux/in.h
index 27d8a5a..b01bf75 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -216,9 +216,6 @@ struct sockaddr_in {
 #defineIN_MULTICAST(a) IN_CLASSD(a)
 #define IN_MULTICAST_NET   0xF000
 
-#defineIN_EXPERIMENTAL(a)  long int) (a))  0xf000) == 
0xf000)
-#defineIN_BADCLASS(a)  IN_EXPERIMENTAL((a))
-
 /* Address to accept any incoming messages. */
 #defineINADDR_ANY  ((unsigned long int) 0x)
 
@@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
 
 static inline bool ipv4_is_badclass(__be32 addr)
 {
-   return (addr  htonl(0xf000)) == htonl(0xf000);
+   return addr == 0x;
 }
 
 static inline bool ipv4_is_zeronet(__be32 addr)
--
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: [PATCH] IPv4: Enable use of 240/4 address space

[Jan Engelhardt]

On Jan 18 2008 10:26, YOSHIFUJI Hideaki / 吉藤英明 wrote:
 -#define IN_EXPERIMENTAL(a)  long int) (a))  0xf000) == 
 0xf000)
 -#define IN_BADCLASS(a)  IN_EXPERIMENTAL((a))

No, please keep these macros.

 @@ -264,7 +261,7 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
  
  static inline bool ipv4_is_badclass(__be32 addr)
  {
 -return (addr  htonl(0xf000)) == htonl(0xf000);
 +return addr == 0x;
  }
  

To (un)align the IN_BADCLASS macro and ipv6_is_badclass() definition,

Unalign? IPv6? Limited broadcast?

you should change the name anyway, e.g., ipv6_is_limited_broadcast()
or some something alike.

===
Author: Jan Engelhardt [EMAIL PROTECTED]
Date:   Fri Jan 18 02:51:34 2008 +0100

IPv4: enable use of 240/4 address space

This short patch modifies the IPv4 networking to enable use of the
240.0.0.0/4 (aka class-E) address space as propsed in the internet
draft draft-fuller-240space-00.txt.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

diff --git a/include/linux/in.h b/include/linux/in.h
index 27d8a5a..4887768 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -262,9 +262,9 @@ static inline bool ipv4_is_local_multicast(__be32 addr)
return (addr  htonl(0xff00)) == htonl(0xe000);
 }
 
-static inline bool ipv4_is_badclass(__be32 addr)
+static inline bool ipv4_is_broadcast(__be32 addr)
 {
-   return (addr  htonl(0xf000)) == htonl(0xf000);
+   return addr == 0x;
 }
 
 static inline bool ipv4_is_zeronet(__be32 addr)
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 8b1509b..f5bd33b 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -262,7 +262,7 @@ static inline int ipv6_isatap_eui64(u8 *eui, __be32 addr)
  ipv4_is_private_172(addr) || ipv4_is_test_192(addr) ||
  ipv4_is_anycast_6to4(addr) || ipv4_is_private_192(addr) ||
  ipv4_is_test_198(addr) || ipv4_is_multicast(addr) ||
- ipv4_is_badclass(addr)) ? 0x00 : 0x02;
+ ipv4_is_broadcast(addr)) ? 0x00 : 0x02;
eui[1] = 0;
eui[2] = 0x5E;
eui[3] = 0xFE;
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index d18fdb1..9d6e7af 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2266,7 +2266,7 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
 
while (ipv4_is_loopback(s) ||
   ipv4_is_multicast(s) ||
-  ipv4_is_badclass(s) ||
+  ipv4_is_broadcast(s) ||
   ipv4_is_zeronet(s) ||
   ipv4_is_local_multicast(s)) {
t = random32() % (imx - imn) + 
imn;
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8ddcd3f..367e097 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -176,7 +176,7 @@ static inline unsigned __inet_dev_addr_type(struct net *net,
unsigned ret = RTN_BROADCAST;
struct fib_table *local_table;
 
-   if (ipv4_is_zeronet(addr) || ipv4_is_badclass(addr))
+   if (ipv4_is_zeronet(addr) || ipv4_is_broadcast(addr))
return RTN_BROADCAST;
if (ipv4_is_multicast(addr))
return RTN_MULTICAST;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 1e59c0d..9f0ea73 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1154,7 +1154,7 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 
new_gw,
return;
 
if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
-   || ipv4_is_multicast(new_gw) || ipv4_is_badclass(new_gw)
+   || ipv4_is_multicast(new_gw) || ipv4_is_broadcast(new_gw)
|| ipv4_is_zeronet(new_gw))
goto reject_redirect;
 
@@ -1634,7 +1634,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 
daddr, __be32 saddr,
if (in_dev == NULL)
return -EINVAL;
 
-   if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+   if (ipv4_is_multicast(saddr) || ipv4_is_broadcast(saddr) ||
ipv4_is_loopback(saddr) || skb-protocol != htons(ETH_P_IP))
goto e_inval;
 
@@ -1891,7 +1891,7 @@ static int ip_route_input_slow(struct sk_buff *skb, 
__be32 daddr, __be32 saddr,
   by fib_lookup.
 */
 
-   if (ipv4_is_multicast(saddr) || ipv4_is_badclass(saddr) ||
+   if (ipv4_is_multicast(saddr) || ipv4_is_broadcast(saddr) ||
ipv4_is_loopback(saddr))
goto martian_source;
 
@@ -1904,7 +1904,7 @@ static int ip_route_input_slow(struct sk_buff *skb, 
__be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(saddr))
goto martian_source;
 
-   if (ipv4_is_badclass(daddr) || ipv4_is_zeronet(daddr

Re: [PATCH 001/001] ipv4: enable use of 240/4 address space

[Jan Engelhardt]

On Jan 11 2008 17:49, David Miller wrote:
From: Vince Fuller [EMAIL PROTECTED]
Date: Fri, 11 Jan 2008 09:29:15 -0800

 I leave it up to you, the developers, to decide if you want to use these
 patches.

Vince, please just ignore these turkeys who are dismissing
your patch and respin it against current sources as I asked
of you.

I'll apply it, immediately, because it is the only correct
course of action.


I strongly agree. Linux should set standards, or at least help them
become one.
--
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: sparc oops in ip_fast_csum

[Jan Engelhardt]

On Jan 6 2008 11:22, Herbert Xu wrote:
@@ -271,6 +271,7 @@ static int raw_send_hdrinc(struct sock *sk, void *from, 
size_t length,
   int hh_len;
   struct iphdr *iph;
   struct sk_buff *skb;
+  unsigned int iphlen;
   int err;
 
   if (length  rt-u.dst.dev-mtu) {
@@ -304,7 +305,8 @@ static int raw_send_hdrinc(struct sock *sk, void *from, 
size_t length,
   goto error_fault;
 
   /* We don't modify invalid header */
-  if (length = sizeof(*iph)  iph-ihl * 4U = length) {
+  iphlen = iph-ihl * 4;
+  if (iphlen = sizeof(*iph)  iphlen = length) {

Humm, this could use ip_hdrlen(skb) :-)
--
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: After many hours all outbound connections get stuck in SYN_SENT

[Jan Engelhardt]

On Dec 20 2007 23:05, Ilpo Järvinen wrote:
 
 Given the fact that I've had this problem for so long, over a variety
 of networking hardware vendors and colo-facilities, this really sounds
 good to me.  It will be challenging for me to justify a kernel core
 dump, but a simple patch to dump the Sack data would be do-able.

If your symptoms really are: SYNs leaving (if they show up in tcpdump, for 
sure they've left TCP code already) and SYN-ACK not showing up even in 
something as early as in tcpdump (for sure TCP side code didn't execute at 
that point yet), there's very little change that Linux' TCP code has some 
bug in it, only things that do something in such scenario are the SYN 
generation and retransmitting SYNs (and those are trivially verifiable 
from tcpdump).

Take a machine, put two interfaces in it, configure as bridge (br0
over eth0 and eth1 without any assigned ip addresses), put it between
end node and the cisco. tcpdump there, which should give an unbiased
view wrt. endnode/cisco. Then perhaps, also configure such a network
listening bridge on the other side of the cisco, e.g. on the link to
the internet and watch that. Compare the two tcpdumpds and see if
sack got trashed.
--
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: After many hours all outbound connections get stuck in SYN_SENT

[Jan Engelhardt]

On Dec 19 2007 12:43, James Nichols wrote:
On 12/19/07, Eric Dumazet [EMAIL PROTECTED] wrote:
 James Nichols a écrit :
  So you see outgoing SYN packets, but no SYN replies coming from the remote
  peer ?  (you mention ACKS, but the first packet received from the remote
   peer should be a SYN+ACK),
 
  Right, I meant to say SYN+ACK.  I don't see them coming back.

 So... Really unlikely a linux problem, but ...

I don't know how you can be so sure.  Turning tcp_sack off instantly
resovles the problem and all connections are succesful.  I can't
imagine even the most far-fetched scenario where a router or every
single remote endpoints would suddenly stop causing the problem just
by removing a single TCP option.

The router could be sooo crappy that it drops all packets from
TCP streams that have SACK enabled and the client has opened
200+ SACK connections previously... something like that?

--
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: After many hours all outbound connections get stuck in SYN_SENT

[Jan Engelhardt]

On Dec 18 2007 21:37, Eric Dumazet wrote:

 If turning off tcp_sack makes the problem go away, why dont you
 turn it off all the time ?

That would just be workaround. I welcome the efforts to track this;
not all users have the time to do so.
Disabling tcp_sack also disabled it kernel-wide, which, well... for
2.6.25 there is a TCPOPTSTRIP netfilter target slated with which
SACK could be stripped only for a given host list or processes from
a UID.
--
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: [PATCH net-2.6.25 1/8] Create ipv4_is_type(__be32 addr) functions

[Jan Engelhardt]

On Dec 13 2007 15:38, Joe Perches wrote:

Change IPV4 specific macros LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET
macros to inline functions ipv4_is_type(__be32 addr)

Adds type safety and arguably some readability.

Changes since last submission:

Removed ipv4_addr_octets function
Used hex constants
Converted recently added rfc3330 macros

Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
+static inline bool ipv4_is_loopback(__be32 addr)
+{
+  return (addr  htonl(0xff00)) == htonl(0x7f00);
+}
+

Can we use __constant_htonl()?

+static inline bool ipv4_is_private_10(__be32 addr)
+{
+  return (addr  htonl(0xff00)) == htonl(0x0a00);
+}

What are these functions needed for, even? There does not seem to be
any code (at least in davem's net-2.6.25:net/ipv4/, where I dared to grep)
that uses them.
--
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: [PATCH net-2.6.25 1/8] Create ipv4_is_type(__be32 addr) functions

[Jan Engelhardt]

On Dec 17 2007 14:43, David Miller wrote:
 On Dec 13 2007 15:38, Joe Perches wrote:
 +static inline bool ipv4_is_private_10(__be32 addr)
 +{
 +   return (addr  htonl(0xff00)) == htonl(0x0a00);
 +}
 
 What are these functions needed for, even? There does not seem to be
 any code (at least in davem's net-2.6.25:net/ipv4/, where I dared to grep)
 that uses them.

You really need to grep the whole tree, never ever decrease the scope
of directories to search if you want to see if an interface is used.

Hah you got me there :)

It's used by some ipv6 address translation code as well as some
bits in SCTP:

include/net/addrconf.h:eui[0] = (ipv4_is_zeronet(addr) || 
ipv4_is_private_10(addr) ||
net/sctp/protocol.c:   } else if (ipv4_is_private_10(addr-v4.sin_addr.s_addr) 
||

So lazy...

I just discovered git-grep...
--
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: [PATCHv6 iptables]Interface group match

[Jan Engelhardt]

On Nov 29 2007 17:27, Patrick McHardy wrote:

 The syntax name/0xmask is simply too strange for me.

 Then how about name/name with masks also defined in rt_ifgroup?
 The same question applies for marks of course.

I would find that confusing, which is why the new xt_TOS only
allows names when no /mask or a mask of /allbits is used.

There is no standard API like getservbyname()...
  
   The code of iproute2 should be copied. If Patrick says it is ok,  I'll
   write this part.
 
  Of course. Please put the tab part somewhere common, I always
  wanted to have named firewall marks shared with ip and tc
  and I believe Balazs wanted that too :)
 
 Ok. Yes, he wants :)

So, we are going to see a librtnl?
-
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: netconsole=y and rtl8139=m

[Jan Engelhardt]

On Nov 20 2007 02:57, Mike Frysinger wrote:
On Nov 20, 2007 2:17 AM, Jan Engelhardt [EMAIL PROTECTED] wrote:
 I get this during boot:

 [   40.821740] netconsole: eth1 doesn't exist, aborting.

 Given that CONFIG_NETCONSOLE=y and CONFIG_8139TOO=m, I can imagine.
 Is there a way to get this working without making 8139TOO=y or
 NETCONSOLE=m?

i guess that depends on what your expectations are.  what do you think
would qualify as a fix ?  that netconsoles could get added/removed
dynamically based on network drivers being loaded/unloaded instead of
netconsole being set up just once at netconsole init time ?

If I can get that bonus, yes :)

Also, does netconsole cope with interface renames?


thanks,
jan
-
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: [PATCHv6 0/3] Interface group patches

[Jan Engelhardt]

On Nov 20 2007 14:14, Laszlo Attila Toth wrote:

This is the 6th version of our interface group patches.

The interface group value can be used to manage different interfaces
at the same time such as in netfilter/iptables.

I take it you could not use...?
iptables -i iif1 -j dosomething
iptables -i iif2 -j dosomething

The netfilter patch
is ready but future plan is the same for ip/tc commands (except
the ifgroup value change which happens via ip link set command).

How can it be useful in conjunction with tc?

-
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

netconsole=y and rtl8139=m

[Jan Engelhardt]

Hi,



I get this during boot:

[   40.821740] netconsole: eth1 doesn't exist, aborting.

Given that CONFIG_NETCONSOLE=y and CONFIG_8139TOO=m, I can imagine.
Is there a way to get this working without making 8139TOO=y or 
NETCONSOLE=m?



thanks,
Jan
-
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: [PATCH 2/2] netdrvr/ibmlana: move away from legacy MCA API

[Jan Engelhardt]

On Oct 29 2007 15:33, Jeff Garzik wrote:
 
+#if 0 /* info available elsewhere, but this is kept for reference */

It is available in the git history, yes, is it still needed for reference?

+static short ibmlana_adapter_ids[] __initdata = {
+  IBM_LANA_ID,
+  0x
+};
+
+static char *ibmlana_adapter_names[] __initdata = {
+  IBM LAN Adapter/A,
+  NULL
+};

Can this be const?

-
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: drivers/net/sunhme.c patch

[Jan Engelhardt]

On Oct 29 2007 15:10, David Miller wrote:
 On Oct 29 2007 08:54, Tom Southerland wrote:
 
  This patch provides a unique mac address for all interfaces
  for the Sun QFE card (non-sparc).  It takes the base mac from
  the first interface and increments the mac address for the
  other interfaces.
 
 Where is the difference to a SPARC QFE? PCI is PCI after all, is not it?

To answer the question, yes it is just a normal PCI device, they put 4
HME chips behind a PCI bridge.  However, the OpenFirmware on the cards
usually creates device node properties for these PCI devices for the
local ethernet addresses.  That's what he's trying to duplicate here.

The question was more like: if I put in a QFE (that was acquired together
with a SUN E250) into x86, would I get duplicate MACs? (Would be strange -
I would have supposed the OF on the card is independent.)

-
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: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 20 2007 00:47, [EMAIL PROTECTED] wrote:
 Sure, the idea was to mark the filter table obsolete as to make people start 
 using the mangle table to do their filtering for new setups.  The filter 
 table would then still be available for legacy/special setups.  But this 
 would only be possible if we at least ported the REJECT target to mangle.

That's *half* the battle.  The other half is explaining why I should move
from a perfectly functional setup that uses the filter table.  What gains
do I get from doing so?  What isn't working that I don't know about? etc?

In other words - why do I want to move from filter to mangle?

Packet processing time.
Compare previous:
packet goes through mangle, then is dropped in filter
Compare afterwards:
packet is already dropped in mangle

= less code to run through
-
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: [PATCH 2/2] Interface group match - netfilter part

[Jan Engelhardt]

On Oct 16 2007 10:30, Patrick McHardy wrote:

 +static int match(const struct sk_buff *skb,

Potential symbol clash, name it ifgroup_match() for example.

 +  const struct net_device *in,
 +  const struct net_device *out,
 +  const struct xt_match *match,
 +  const void *matchinfo,
 +  int offset,
 +  unsigned int protoff,
 +  int *hotdrop)

2.6.23 = bool ifgroup_match(... bool *hotdrop)

 +static struct xt_match ifgroup_match = {
 +.name   = ifgroup,
 +.match  = match,
 +.matchsize  = sizeof(struct xt_ifgroup_info),
 +.family = AF_INET,
 +.me = THIS_MODULE,
 +};
 +
 +static struct xt_match ifgroup6_match = {
 +.name   = ifgroup,
 +.match  = match,
 +.matchsize  = sizeof(struct xt_ifgroup_info),
 +.family = AF_INET6,
 +.me = THIS_MODULE,
 +};

 __read_mostly

And actually, an array,

static struct xt_match ifgroup_match[] __read_mostly = {
...
}

-
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: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 12 2007 16:30, Al Boldi wrote:
Jan Engelhardt wrote:
 On Oct 12 2007 00:31, Al Boldi wrote:
 With the existence of the mangle table, how useful is the filter table?

 A similar discussion was back in March 2007.
 http://marc.info/?l=netfilter-develm=117394977210823w=2
 http://marc.info/?l=netfilter-develm=117400063907706w=2

 in the end, my proposal was something like
 http://jengelh.hopto.org/GFX0/nf_proposal2.svg

Any chance you could publish this as something readable like text/html?

Like, image/png?
http://jengelh.hopto.org/GFX0/nf_proposal2.png
-
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: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 12 2007 15:48, Patrick McHardy wrote:

The netlink based iptables successor I'm currently working on allows to
dynamically create tables with user-specified priorities and built-in
chains. The only built-in tables will be those that need extra
processing (mangle/nat). So it should be possible to set up tables
basically any way you desire.

Will ebtables move a bit closer to iptables?

-
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: [RFD] iptables: mangle table obsoletes filter table

[Jan Engelhardt]

On Oct 12 2007 00:31, Al Boldi wrote:

With the existence of the mangle table, how useful is the filter table?

A similar discussion was back in March 2007.
http://marc.info/?l=netfilter-develm=117394977210823w=2
http://marc.info/?l=netfilter-develm=117400063907706w=2

in the end, my proposal was something like
http://jengelh.hopto.org/GFX0/nf_proposal2.svg
-
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: [PATCH] Move the definition of pr_err() into kernel.h

[Jan Engelhardt]

On Sep 12 2007 12:59, Stephen Hemminger wrote:
 Other pr_*() macros are already defined in kernel.h, but pr_err() was defined
 multiple times in several other places
 
 Signed-off-by: Emil Medve [EMAIL PROTECTED]

pr_error seems better than pr_err

Please add the full set:
   pr_alert
   pr_critical
pr_error
pr_warn
pr_notice

I repeat to be totally against this.

(1) You are trying to add pr_*(fmt, arg) as a lazy shorthand for 
printk(KERN_* fmt, arg...) and

(2) do not seem to notice that pr_debug() changes its behavior 
depending on -DDEBUG, which pr_alert() etc. do not, so there
is IMHO no point (that includes the already existing pr_info()).
Why not just obsolete printk() altogether then?

-
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: [PATCH v3] Make the pr_*() family of macros in kernel.h complete

[Jan Engelhardt]

On Sep 12 2007 11:39, Emil Medve wrote:

Other/Some pr_*() macros are already defined in kernel.h, but pr_err() was 
defined
multiple times in several other places

Note http://lkml.org/lkml/2007/8/4/30 .
-
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: [PATCH] ipconfig.c: De-clutter IP configuration report

[Jan Engelhardt]

On Sep 10 2007 13:09, Maciej W. Rozycki wrote:
 The new code builds fine; no semantic changes.

 Please apply,

  Maciej

patch-mips-2.6.23-rc5-20070904-ipconfig-printk-2
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/net/ipv4/ipconfig.c 
linux-mips-2.6.23-rc5-20070904/net/ipv4/ipconfig.c
--- linux-mips-2.6.23-rc5-20070904.macro/net/ipv4/ipconfig.c   2007-09-04 
04:56:22.0 +
+++ linux-mips-2.6.23-rc5-20070904/net/ipv4/ipconfig.c 2007-09-10 
11:53:19.0 +
@@ -1364,17 +1364,17 @@ static int __init ip_auto_config(void)
   /*
* Clue in the operator.
*/
-  printk(IP-Config: Complete:);
-  printk(\n  device=%s, ic_dev-name);
-  printk(, addr=%u.%u.%u.%u, NIPQUAD(ic_myaddr));
-  printk(, mask=%u.%u.%u.%u, NIPQUAD(ic_netmask));
-  printk(, gw=%u.%u.%u.%u, NIPQUAD(ic_gateway));
-  printk(,\n host=%s, domain=%s, nis-domain=%s,
- utsname()-nodename, ic_domain, utsname()-domainname);
-  printk(,\n bootserver=%u.%u.%u.%u, NIPQUAD(ic_servaddr));
-  printk(, rootserver=%u.%u.%u.%u, NIPQUAD(root_server_addr));
-  printk(, rootpath=%s, root_server_path);
-  printk(\n);
+  pr_info(IP-Config: Complete:\n);
+  pr_info(  device=%s, addr=%u.%u.%u.%u, 
+  mask=%u.%u.%u.%u, gw=%u.%u.%u.%u,\n,
+  ic_dev-name, NIPQUAD(ic_myaddr),
+  NIPQUAD(ic_netmask), NIPQUAD(ic_gateway));
+  pr_info(  host=%s, domain=%s, nis-domain=%s,\n,
+  utsname()-nodename, ic_domain, utsname()-domainname);
+  pr_info(  bootserver=%u.%u.%u.%u, 
+  rootserver=%u.%u.%u.%u, rootpath=%s\n,
+  NIPQUAD(ic_servaddr),
+  NIPQUAD(root_server_addr), root_server_path);
 #endif /* !SILENT */
 
   return 0;

It should really be done in userspace. And ripped from the kernel.



Jan
-- 
-
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: Fwd: That whole Linux stealing our code thing

[Jan Engelhardt]

On Sep 1 2007 18:36, Theo de Raadt wrote:

When companies have taken our wireless device drivers, many many of
them have given changes and fixes back.  Some maybe didn't, but that
is OK.

For companies it's ok, but for linux people it is not?

(1) You do not know how much of the modifications companies did
are actually returned

(2) You do not know whether the ath5k linux part authors will
give back at a later point (much like companies)

-
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: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

[Jan Engelhardt]

On Aug 31 2007 14:06, Jeff Garzik wrote:
 something like BROKEN, though, has *nothing* to do with maturity.  a
 feature can be any of those maturity levels, and simultaneously be
 BROKEN.  i consider BROKEN to be what i call a status, and different
 status levels might be the default of normal, or KIND_OF_FLAKY or
 TOTALLY_BORKED -- that's where BROKEN would fit in.

 BROKEN is definitely a maturity level.  A more accurate description would be
 BITROTTING perhaps.  The code in question has passed through bleeding -
 experimental - stable, and come out the other side.

Software is quite unlike the art of medicine. There, you would go from
'stable' to 'broken', then someone 'experiments' with you, and if
it's a bad day, you bleed out. :)


Jan
-- 
-
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: Distributed storage. Mirroring to any number of devices.

[Jan Engelhardt]

On Aug 14 2007 20:29, Evgeniy Polyakov wrote:

I'm pleased to announce second release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a node to
form tree-like storages.

I'll be quick: what is it good for, are there any users, and what could
it have to do with DRBD and all the other distribution storage talk
that has come up lately (namely NBD w/Raid1)?


Jan
-- 
-
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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])

[Jan Engelhardt]

On Aug 12 2007 13:35, Al Boldi wrote:
Lars Ellenberg wrote:
 meanwhile, please, anyone interessted,
 the drbd paper for LinuxConf Eu 2007 is finalized.
 http://www.drbd.org/fileadmin/drbd/publications/
 drbd8.linux-conf.eu.2007.pdf

 but it does give a good overview about what DRBD actually is,
 what exact problems it tries to solve,
 and what developments to expect in the near future.

 so you can make up your mind about
  Do we need it?, and
  Why DRBD? Why not NBD + MD-RAID?

I may have made a mistake when asking for how it compares to NBD+MD.
Let me retry: what's the functional difference between
GFS2 on a DRBD .vs. GFS2 on a DAS SAN?

Now, shared remote block access should theoretically be handled, as does 
DRBD, by a block layer driver, but realistically it may be more appropriate 
to let it be handled by the combining end user, like OCFS or GFS.


Jan
-- 
-
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: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])

[Jan Engelhardt]

On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:

 now, I am not an expert on either option, but three are a couple things that I
 would question about the DRDB+MD option

 1. when the remote machine is down, how does MD deal with it for reads and
 writes?

I suppose it kicks the drive and you'd have to re-add it by hand unless done by
a cronjob.

 2. MD over local drive will alternate reads between mirrors (or so I've been
 told), doing so over the network is wrong.

Certainly. In which case you set write_mostly (or even write_only, not sure
of its name) on the raid component that is nbd.

 3. when writing, will MD wait for the network I/O to get the data saved on the
 backup before returning from the syscall? or can it sync the data out lazily

Can't answer this one - ask Neil :)




Jan
-- 
-
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: TCP SACK issue, hung connection, tcpdump included

[Jan Engelhardt]

On Jul 29 2007 08:45, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
 CLIENT = Linux 2.6.20.1-smp [Customer build]
 SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4 
 (Nahant Update 5)]
 
 The problems start around time index 09:21:39.860302 when the CLIENT issues 
 a TCP packet with SACK option set (seemingly for a data segment which has 
 already been seen) from that point on the connection hangs.

Where was the capture taken ? on CLIENT or on SERVER (I suspect client from
the timers) ? A possible, but very unlikely reason would be an MTU limitation
somewhere, because the segment which never gets correctly ACKed is also the
largest one in this trace.[...]

I had something similar (and most strangely enough, it only seemed to happen
when the source and/or destination address was outside a given subnet). It
boiled down to that some switch acted really strange and God knows why. A
tcpdump on *both* sides (server+client) each showed that the *other* peer sent
a FIN/RST. Well in the end I settled with setting sys.net.ipv4.tcp_sack=0,
no idea if the broken switch got replaced in the meantime.
Well, just letting you know that it is not limited to computers.


Jan
-- 
-
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: [PATCH] CONFIG_NET=n - lots of link time errors

[Jan Engelhardt]

On Jul 21 2007 19:12, David Miller wrote:
 Enabling drivers from Devices  Networking (in menuconfig), for 
 example SLIP and/or PLIP, throws link time errors when CONFIG_NET itself 
 is =n. Have CONFIG_NETDEVICES depend on CONFIG_NET.
 
 Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

This is the second time I've seen this change in the past few
days, and people seem to hit it quite readily with randconfig.

It seems reasonable and I'll apply it, thanks Jan.

While randconfig is nice and good, this error actually came by manually
tuning the .config for a specific goal (namely: make a small kernel for an
ancient i386 without modifying any code). Turning off CONFIG_NET
was then just an idea away, because I knew that TCP was quite big.


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

[PATCH] CONFIG_NET=n - lots of link time errors

[Jan Engelhardt]

Hi,


enable everything from Drivers  Networking, but deselect CONFIG_NET. 
This throws a ton of linking errors (when using CONFIG_MODULES=n), and 
probably unresolved symbols (MODULES=m). Happens in current -git, but I 
believe it dates much farther back, because this is imo just a simple 
Kconfig issue. I think we need to hand out a big 'if NET'-endif block in 
drivers/net/Kconfig. The full error log is like 120 K in size, and I 
doubt it would make sense to post it, given instructions above. I'll 
attach my (i386) .config for anyone to see it for themselves, and a 
patch proposal right below. Is it ok to add 'depends on NET' on 
NETDEVICES, or are there some network devices that can live without 
CONFIG_NET?

Thanks,
Jan
===

Enabling drivers from Devices  Networking (in menuconfig), for 
example SLIP and/or PLIP, throws link time errors when CONFIG_NET itself 
is =n. Have CONFIG_NETDEVICES depend on CONFIG_NET.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

---
 drivers/net/Kconfig |1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.23/drivers/net/Kconfig
===
--- linux-2.6.23.orig/drivers/net/Kconfig
+++ linux-2.6.23/drivers/net/Kconfig
@@ -5,6 +5,7 @@
 
 menuconfig NETDEVICES
default y if UML
+   depends on NET
bool Network device support
---help---
  You can say N here if you don't intend to connect your Linux box to

net.config
Description: application/config

Re: Scaling Max IP address limitation

[Jan Engelhardt]

On Jun 25 2007 11:47, Robert Iakobashvili wrote:

 I am getting after initial successes some errors:
 rtnl_talk(): RTNETLINK answers: Cannot allocate memory
 and
 #ip addr | wc-l is 8194.

I'd be surprised if it was 4096 on x86 and 8192 on x86_64...


Jan
-- 
-
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: Scaling Max IP address limitation

[Jan Engelhardt]

On Jun 25 2007 12:41, Robert Iakobashvili wrote:
  I am getting after initial successes some errors:
  rtnl_talk(): RTNETLINK answers: Cannot allocate memory
  and
  #ip addr | wc-l is 8194.

 I'd be surprised if it was 4096 on x86 and 8192 on x86_64...

 Missed to mention: the CPU is Pentium-4.

That's like saying you've got a SPARC. Or a MIPS. Or a PPC.
(I can't infer from your answer whether that is running 32 or 64-bit
kernel, because there are P4s with and without 64-bit extensions.)


Jan
-- 
-
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: Scaling Max IP address limitation

[Jan Engelhardt]

On Jun 24 2007 15:08, Kyle Moffett wrote:

 Do you really need that many IP addresses?  When somebody finally gets
 around to implementing REDIRECT support for ip6tables then you could
 just redirect them all to the same port on the local system.

The way I see it, it's: if someone gets around to implement *IPv6 NAT*
(which, if its designers were asked, is contrary to the idea of ipv6).

 Unrelated wishful thinking
 I keep having hopeful dreams that one day netfilter will grow support for
 cross-protocol NAT (IE: NAT a TCPv4 connection over TCPv6 to the IPv6-only
 local web server, or vice versa).  It would seem that would require a merged
 xtables program.

 Having routing table operations, IPsec transformations, etc just be
 another step in the firewall rules would also be useful.  It would be
 handy to be able to -j ROUTE, then -j IPSEC, then -j ROUTE again,
 to re-route the now-encapsulated IPsec packets to their proper
 destination.

Absolutely...

 That would also eliminate the sort-of-hacky problems with
 destination network interface in the bridging code:

Where's the hack? iptables operates on what it sees, and it sees br0.
The physdev match is justified IMO.

 -j BRIDGE might be
 another step in the process, and conceivably you could have independent
 bridge MAC tables too.

Whether a packet goes out a bridge (was that the intention of -j BRIDGE?)
is determined by the routing table, which, in most cases, is just a matter
of destination address.

 You'd probably also want -j BRIDGE_TEST and
 -j ROUTE_TEST to compute the output network interface without actually
 modifying the addresses.

 That would also appear to get rid of the need for all tables other than
 filter and all predefined chains other than INPUT and OUTPUT.  Default
 rules would be these:
 nettables -A INPUT -j CONNTRACK
 nettables -A INPUT -j LOCALMATCH
 nettables -A INPUT --for-this-host -j ACCEPT
 nettables -A INPUT -j OUTPUT

I'd prefer if Linux outputted its packets by default :)

 nettables -A OUTPUT -j ROUTE
 nettables -A OUTPUT -j TRANSMIT

pkttables it is!

But this idea may have its benefit: by not restricting rules to certain
positions like currently, throughput could be achieved. Evil packets
f.e. could be dropped really early. (Well, you could also drop them early
_today_, but a DROP in the mangle table will everyone make their eyes roll
:-)



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

DCCP: 2.6.22-rc5-git8 compile warning

[Jan Engelhardt]

git tree a06381fec77bf88ec6c5eb6324457cb04e9ffd69 (last commit ID) 
gives:

/ws/linux-2.6.22/net/dccp/ipv4.c:589: warning: initialization from 
incompatible
/ws/linux-2.6.22/net/dccp/ipv6.c:387: warning: initialization from 
incompatible
[pointer type - `less` cut it off from the 80 col screen]

Offending lines, ipv4.c:
.send_ack   = dccp_reqsk_send_ack,

ipv6.c:
.send_ack   = dccp_reqsk_send_ack,

These could be fixed :)


Jan
-- 
-
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: DCCP: 2.6.22-rc5-git8 compile warning

[Jan Engelhardt]

git tree a06381fec77bf88ec6c5eb6324457cb04e9ffd69 (last commit ID) 
gives:

/ws/linux-2.6.22/net/dccp/ipv4.c:589: warning: initialization from 
incompatible
/ws/linux-2.6.22/net/dccp/ipv6.c:387: warning: initialization from 
incompatible

Extra patches with quilt caused that. Sorry for the noise.


Jan
-- 
-
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: Scaling Max IP address limitation

[Jan Engelhardt]

On Jun 24 2007 13:44, [EMAIL PROTECTED] wrote:
 On Jun 24 2007 15:08, Kyle Moffett wrote:
 
  Do you really need that many IP addresses?  When somebody finally gets
  around to implementing REDIRECT support for ip6tables then you could
  just redirect them all to the same port on the local system.

 The way I see it, it's: if someone gets around to implement *IPv6 NAT*
 (which, if its designers were asked, is contrary to the idea of ipv6).

 true, but back in the real world it's sometimes desriable to hid _chich_
 specific machine somethign comes from. so I expect that implementation of NAT
 is going tohappen at some point before it's widely deployed.

Client-transparent SOCKS5 proxy. It already exists today! ;-)
(Not as performant as an in-kernel NAT, though.)


Jan
-- 
-
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: [PATCH] fix race in AF_UNIX

[Jan Engelhardt]

On Jun 18 2007 12:47, Alan Cox wrote:

 Do you want me to send the patch to Andrew instead?  His attitude
 towards bugfixes is rather better ;)

And it'll get NAKked and binned. DaveM is (as happens sometimes ;)) right
to insist on the code being clean and efficient.

Or see RFC 1925 number 7a. :)


Jan
-- 
-
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: [PATCH] merge dst_discard in out into one, this decrements the vmlinux image by 21 bytes under i386 arch.

[Jan Engelhardt]

On May 28 2007 10:41, rae l wrote:

 diff --git a/net/core/dst.c b/net/core/dst.c
 index 764bccb..daa0439 100644
 --- a/net/core/dst.c
 +++ b/net/core/dst.c
 @@ -111,17 +111,14 @@ out:
  spin_unlock(dst_lock);
 }

 -static int dst_discard_in(struct sk_buff *skb)
 +static int dst_discard(struct sk_buff *skb)
 {
 kfree_skb(skb);
 return 0;
 }

 -static int dst_discard_out(struct sk_buff *skb)
 -{
 -   kfree_skb(skb);
 -   return 0;
 -}
 +#define dst_discard_in dst_discard
 +#define dst_discard_outdst_discard

Uhm, just replace every invocation of dst_discard_in/_out() directly
by dst_discard ... don't add macros for that.



 void * dst_alloc(struct dst_ops * ops)
 {



Jan
-- 
-
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: [patch 4/8] Use menuconfig objects: SCTP

[Jan Engelhardt]

On May 11 2007 10:12, Vlad Yasevich wrote:
Brian Haley wrote:
 [EMAIL PROTECTED] wrote:
 diff -puN net/sctp/Kconfig~use-menuconfig-objects-sctp net/sctp/Kconfig
 --- a/net/sctp/Kconfig~use-menuconfig-objects-sctp
 +++ a/net/sctp/Kconfig
 @@ -2,11 +2,9 @@
  # SCTP configuration
  #
  
 -menu SCTP Configuration (EXPERIMENTAL)
 -depends on INET  EXPERIMENTAL
 -
 -config IP_SCTP
 +menuconfig IP_SCTP
  tristate The SCTP Protocol (EXPERIMENTAL)
 +depends on NET  EXPERIMENTAL
  depends on IPV6 || IPV6=n
  select CRYPTO if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5
  select CRYPTO_HMAC if SCTP_HMAC_SHA1 || SCTP_HMAC_MD5
 
 This just changed INET  EXPERIMENTAL to NET  EXPERIMENTAL, don't
 know if that was intended.

Thanks Brian.   This is a bug.  This should use INET.

Nobody's perfect :p


Jan
-- 
-
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: [patch 08/13] Use menuconfig objects II - netdev (general+100mbit)

[Jan Engelhardt]

On May 11 2007 16:57, Jeff Garzik wrote:
 
 CONFIG_NETDEVICES, CONFIG_NET_ETHERNET:
 Change Kconfig objects from menu, config into menuconfig so
 that the user can disable the whole feature without having to
 enter the menu first.
 
 CONFIG_SMC9194:
 Move it so that it appears correctly in menuconfig.
 
 Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
 Cc: Jeff Garzik [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]
 ---
 
 drivers/net/Kconfig |  167 --
 drivers/net/arm/Kconfig |   12 +-
 drivers/net/fec_8xx/Kconfig |2 drivers/net/fs_enet/Kconfig |2
 drivers/net/tulip/Kconfig   |   27 ++---
 5 files changed, 102 insertions(+), 108 deletions(-)

 ACK, but failed to apply

Name the tree that I should rebase it on. (Did not seem like basing
everything on -mm always works out.)

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

[PATCH 20/36] Use menuconfig objects II - netdev (general+100mbit)

[Jan Engelhardt]

CONFIG_NETDEVICES, CONFIG_NET_ETHERNET:
Change Kconfig objects from menu, config into menuconfig so
that the user can disable the whole feature without having to
enter the menu first.

CONFIG_SMC9194:
Move it so that it appears correctly in menuconfig.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

---
 drivers/net/Kconfig |  167 +---
 drivers/net/arm/Kconfig |   12 +--
 drivers/net/fec_8xx/Kconfig |2 
 drivers/net/fs_enet/Kconfig |2 
 drivers/net/tulip/Kconfig   |   27 +++
 5 files changed, 102 insertions(+), 108 deletions(-)

--- linux-2.6.21-mm_20070428.orig/drivers/net/Kconfig
+++ linux-2.6.21-mm_20070428/drivers/net/Kconfig
@@ -3,10 +3,7 @@
 # Network device configuration
 #
 
-menu Network device support
-   depends on NET
-
-config NETDEVICES
+menuconfig NETDEVICES
default y if UML
bool Network device support
---help---
@@ -151,11 +148,9 @@ source drivers/net/phy/Kconfig
 #  Ethernet
 #
 
-menu Ethernet (10 or 100Mbit)
-   depends on !UML
-
-config NET_ETHERNET
+menuconfig NET_ETHERNET
bool Ethernet (10 or 100Mbit)
+   depends on !UML
---help---
  Ethernet (also called IEEE 802.3 or ISO 8802-2) is the most common
  type of Local Area Network (LAN) in universities and companies.
@@ -180,9 +175,10 @@ config NET_ETHERNET
  kernel: saying N will just cause the configurator to skip all
  the questions about Ethernet network cards. If unsure, say N.
 
+if NET_ETHERNET
+
 config MII
tristate Generic Media Independent Interface device support
-   depends on NET_ETHERNET
help
  Most ethernet controllers have MII transceiver either as an external
  or internal device.  It is safe to say Y or M here even if your
@@ -190,7 +186,7 @@ config MII
 
 config MACB
tristate Atmel MACB support
-   depends on NET_ETHERNET  (AVR32 || ARCH_AT91SAM9260 || 
ARCH_AT91SAM9263)
+   depends on AVR32 || ARCH_AT91SAM9260 || ARCH_AT91SAM9263
select MII
help
  The Atmel MACB ethernet interface is found on many AT32 and AT91
@@ -203,7 +199,7 @@ source drivers/net/arm/Kconfig
 
 config MACE
tristate MACE (Power Mac ethernet) support
-   depends on NET_ETHERNET  PPC_PMAC  PPC32
+   depends on PPC_PMAC  PPC32
select CRC32
help
  Power Macintoshes and clones with Ethernet built-in on the
@@ -226,7 +222,7 @@ config MACE_AAUI_PORT
 
 config BMAC
tristate BMAC (G3 ethernet) support
-   depends on NET_ETHERNET  PPC_PMAC  PPC32
+   depends on PPC_PMAC  PPC32
select CRC32
help
  Say Y for support of BMAC Ethernet interfaces. These are used on G3
@@ -237,7 +233,7 @@ config BMAC
 
 config ARIADNE
tristate Ariadne support
-   depends on NET_ETHERNET  ZORRO
+   depends on ZORRO
help
  If you have a Village Tronic Ariadne Ethernet adapter, say Y.
  Otherwise, say N.
@@ -247,7 +243,7 @@ config ARIADNE
 
 config A2065
tristate A2065 support
-   depends on NET_ETHERNET  ZORRO
+   depends on ZORRO
select CRC32
help
  If you have a Commodore A2065 Ethernet adapter, say Y. Otherwise,
@@ -258,7 +254,7 @@ config A2065
 
 config HYDRA
tristate Hydra support
-   depends on NET_ETHERNET  ZORRO
+   depends on ZORRO
select CRC32
help
  If you have a Hydra Ethernet adapter, say Y. Otherwise, say N.
@@ -268,7 +264,7 @@ config HYDRA
 
 config ZORRO8390
tristate Zorro NS8390-based Ethernet support
-   depends on NET_ETHERNET  ZORRO
+   depends on ZORRO
select CRC32
help
  This driver is for Zorro Ethernet cards using an NS8390-compatible
@@ -281,7 +277,7 @@ config ZORRO8390
 
 config APNE
tristate PCMCIA NE2000 support
-   depends on NET_ETHERNET  AMIGA_PCMCIA
+   depends on AMIGA_PCMCIA
select CRC32
help
  If you have a PCMCIA NE2000 compatible adapter, say Y.  Otherwise,
@@ -292,7 +288,7 @@ config APNE
 
 config APOLLO_ELPLUS
tristate Apollo 3c505 support
-   depends on NET_ETHERNET  APOLLO
+   depends on APOLLO
help
  Say Y or M here if your Apollo has a 3Com 3c505 ISA Ethernet card.
  If you don't have one made for Apollos, you can use one from a PC,
@@ -301,7 +297,7 @@ config APOLLO_ELPLUS
 
 config MAC8390
bool Macintosh NS 8390 based ethernet cards
-   depends on NET_ETHERNET  MAC
+   depends on MAC
select CRC32
help
  If you want to include a driver to support Nubus or LC-PDS
@@ -311,7 +307,7 @@ config MAC8390
 
 config MAC89x0
tristate Macintosh CS89x0 based ethernet cards
-   depends on NET_ETHERNET  MAC  BROKEN
+   depends on MAC  BROKEN
---help---
  Support for CS89x0 chipset based Ethernet cards.  If you have a
  Nubus or LC-PDS

[PATCH 21/36] Use menuconfig objects II - netdev/atm

[Jan Engelhardt]

Make a menuconfig out of the Kconfig objects menu, ..., endmenu,
so that the user can disable all the options in that menu at once
instead of having to disable each option separately.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

---
 drivers/atm/Kconfig |   32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

--- linux-2.6.21-mm_20070428.orig/drivers/atm/Kconfig
+++ linux-2.6.21-mm_20070428/drivers/atm/Kconfig
@@ -2,19 +2,22 @@
 # ATM device configuration
 #
 
-menu ATM drivers
+menuconfig ATM_DRIVERS
+   bool ATM drivers
depends on NETDEVICES  ATM
+   default y
+
+if ATM_DRIVERS
 
 config ATM_DUMMY
tristate Dummy ATM driver
-   depends on ATM
help
  Dummy ATM driver. Useful for proxy signalling, testing,
  and development.  If unsure, say N.
 
 config ATM_TCP
tristate ATM over TCP
-   depends on INET  ATM
+   depends on INET
help
  ATM over TCP driver. Useful mainly for development and for
  experiments. If unsure, say N.
@@ -30,7 +33,7 @@ config ATM_LANAI
 
 config ATM_ENI
tristate Efficient Networks ENI155P
-   depends on PCI  ATM
+   depends on PCI
---help---
  Driver for the Efficient Networks ENI155p series and SMC ATM
  Power155 155 Mbps ATM adapters. Both, the versions with 512KB and
@@ -139,7 +142,7 @@ config ATM_ENI_BURST_RX_2W
 
 config ATM_FIRESTREAM
tristate Fujitsu FireStream (FS50/FS155) 
-   depends on PCI  ATM
+   depends on PCI
help
  Driver for the Fujitsu FireStream 155 (MB86697) and
  FireStream 50 (MB86695) ATM PCI chips.
@@ -149,7 +152,7 @@ config ATM_FIRESTREAM
 
 config ATM_ZATM
tristate ZeitNet ZN1221/ZN1225
-   depends on PCI  ATM
+   depends on PCI
help
  Driver for the ZeitNet ZN1221 (MMF) and ZN1225 (UTP-5) 155 Mbps ATM
  adapters.
@@ -169,7 +172,7 @@ config ATM_ZATM_DEBUG
 
 config ATM_NICSTAR
tristate IDT 77201 (NICStAR) (ForeRunnerLE)
-   depends on PCI  ATM  !64BIT
+   depends on PCI  !64BIT
help
  The NICStAR chipset family is used in a large number of ATM NICs for
  25 and for 155 Mbps, including IDT cards and the Fore ForeRunnerLE
@@ -202,7 +205,7 @@ config ATM_NICSTAR_USE_IDT77105
 
 config ATM_IDT77252
tristate IDT 77252 (NICStAR II)
-   depends on PCI  ATM
+   depends on PCI
help
  Driver for the IDT 77252 ATM PCI chips.
 
@@ -237,7 +240,7 @@ config ATM_IDT77252_USE_SUNI
 
 config ATM_AMBASSADOR
tristate Madge Ambassador (Collage PCI 155 Server)
-   depends on PCI  ATM
+   depends on PCI
select BITREVERSE
help
  This is a driver for ATMizer based ATM card produced by Madge
@@ -262,7 +265,7 @@ config ATM_AMBASSADOR_DEBUG
 
 config ATM_HORIZON
tristate Madge Horizon [Ultra] (Collage PCI 25 and Collage PCI 155 
Client)
-   depends on PCI  ATM
+   depends on PCI
help
  This is a driver for the Horizon chipset ATM adapter cards once
  produced by Madge Networks Ltd. Say Y (or M to compile as a module
@@ -286,7 +289,7 @@ config ATM_HORIZON_DEBUG
 
 config ATM_IA
tristate Interphase ATM PCI x575/x525/x531
-   depends on PCI  ATM  !64BIT
+   depends on PCI  !64BIT
---help---
  This is a driver for the Interphase (i)ChipSAR adapter cards
  which include a variety of variants in term of the size of the
@@ -319,7 +322,7 @@ config ATM_IA_DEBUG
 
 config ATM_FORE200E_MAYBE
tristate FORE Systems 200E-series
-   depends on (PCI || SBUS)  ATM
+   depends on PCI || SBUS
---help---
  This is a driver for the FORE Systems 200E-series ATM adapter
  cards. It simultaneously supports PCA-200E and SBA-200E models
@@ -436,7 +439,7 @@ config ATM_FORE200E
 
 config ATM_HE
tristate ForeRunner HE Series
-   depends on PCI  ATM
+   depends on PCI
help
  This is a driver for the Marconi ForeRunner HE-series ATM adapter
  cards. It simultaneously supports the 155 and 622 versions.
@@ -448,5 +451,4 @@ config ATM_HE_USE_SUNI
  Support for the S/UNI-Ultra and S/UNI-622 found in the ForeRunner
  HE cards.  This driver provides carrier detection some statistics.
 
-endmenu
-
+endif # ATM
-
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

[PATCH 23/36] Use menuconfig objects II - netdev/wan

[Jan Engelhardt]

Change Kconfig objects from menu, config into menuconfig so
that the user can disable the whole feature without having to
enter the menu first.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

---
 drivers/net/wan/Kconfig |   34 +++---
 1 file changed, 15 insertions(+), 19 deletions(-)

--- linux-2.6.21-mm_20070428.orig/drivers/net/wan/Kconfig
+++ linux-2.6.21-mm_20070428/drivers/net/wan/Kconfig
@@ -2,10 +2,7 @@
 # wan devices configuration
 #
 
-menu Wan interfaces
-   depends on NETDEVICES
-
-config WAN
+menuconfig WAN
bool Wan interfaces support
---help---
  Wide Area Networks (WANs), such as X.25, Frame Relay and leased
@@ -23,10 +20,12 @@ config WAN
 
  If unsure, say N.
 
+if WAN
+
 # There is no way to detect a comtrol sv11 - force it modular for now.
 config HOSTESS_SV11
tristate Comtrol Hostess SV-11 support
-   depends on WAN  ISA  m  ISA_DMA_API  INET
+   depends on ISA  m  ISA_DMA_API  INET
help
  Driver for Comtrol Hostess SV-11 network card which
  operates on low speed synchronous serial links at up to
@@ -38,7 +37,7 @@ config HOSTESS_SV11
 # The COSA/SRP driver has not been tested as non-modular yet.
 config COSA
tristate COSA/SRP sync serial boards support
-   depends on WAN  ISA  m  ISA_DMA_API
+   depends on ISA  m  ISA_DMA_API
---help---
  Driver for COSA and SRP synchronous serial boards.
 
@@ -62,7 +61,7 @@ config COSA
 #
 config LANMEDIA
tristate LanMedia Corp. SSI/V.35, T1/E1, HSSI, T3 boards
-   depends on WAN  PCI
+   depends on PCI
---help---
  Driver for the following Lan Media family of serial boards:
 
@@ -89,7 +88,7 @@ config LANMEDIA
 # There is no way to detect a Sealevel board. Force it modular
 config SEALEVEL_4021
tristate Sealevel Systems 4021 support
-   depends on WAN  ISA  m  ISA_DMA_API  INET
+   depends on ISA  m  ISA_DMA_API  INET
help
  This is a driver for the Sealevel Systems ACB 56 serial I/O adapter.
 
@@ -99,7 +98,6 @@ config SEALEVEL_4021
 # Generic HDLC
 config HDLC
tristate Generic HDLC layer
-   depends on WAN
help
  Say Y to this option if your Linux box contains a WAN (Wide Area
  Network) card supported by this driver and you are planning to
@@ -167,7 +165,7 @@ config HDLC_X25
  If unsure, say N.
 
 comment X.25/LAPB support is disabled
-   depends on WAN  HDLC  (LAPB!=m || HDLC!=m)  LAPB!=y
+   depends on HDLC  (LAPB!=m || HDLC!=m)  LAPB!=y
 
 config PCI200SYN
tristate Goramo PCI200SYN support
@@ -230,10 +228,10 @@ config PC300_MLPPP
  Multilink PPP over the PC300 synchronous communication boards.
 
 comment Cyclades-PC300 MLPPP support is disabled.
-   depends on WAN  HDLC  PC300  (PPP=n || !PPP_MULTILINK || 
PPP_SYNC_TTY=n || !HDLC_PPP)
+   depends on HDLC  PC300  (PPP=n || !PPP_MULTILINK || PPP_SYNC_TTY=n 
|| !HDLC_PPP)
 
 comment Refer to the file README.mlppp, provided by PC300 package.
-   depends on WAN  HDLC  PC300  (PPP=n || !PPP_MULTILINK || 
PPP_SYNC_TTY=n || !HDLC_PPP)
+   depends on HDLC  PC300  (PPP=n || !PPP_MULTILINK || PPP_SYNC_TTY=n 
|| !HDLC_PPP)
 
 config PC300TOO
tristate Cyclades PC300 RSV/X21 alternative support
@@ -338,7 +336,6 @@ config DSCC4_PCI_RST
 
 config DLCI
tristate Frame Relay DLCI support
-   depends on WAN
---help---
  Support for the Frame Relay protocol.
 
@@ -385,7 +382,7 @@ config SDLA
 # Wan router core.
 config WAN_ROUTER_DRIVERS
tristate WAN router drivers
-   depends on WAN  WAN_ROUTER
+   depends on WAN_ROUTER
---help---
  Connect LAN to WAN via Linux box.
 
@@ -440,7 +437,7 @@ config CYCLOMX_X25
 # X.25 network drivers
 config LAPBETHER
tristate LAPB over Ethernet driver (EXPERIMENTAL)
-   depends on WAN  LAPB  X25
+   depends on LAPB  X25
---help---
  Driver for a pseudo device (typically called /dev/lapb0) which allows
  you to open an LAPB point-to-point connection to some other computer
@@ -456,7 +453,7 @@ config LAPBETHER
 
 config X25_ASY
tristate X.25 async driver (EXPERIMENTAL)
-   depends on WAN  LAPB  X25
+   depends on LAPB  X25
---help---
  Send and receive X.25 frames over regular asynchronous serial
  lines such as telephone lines equipped with ordinary modems.
@@ -471,7 +468,7 @@ config X25_ASY
 
 config SBNI
tristate Granch SBNI12 Leased Line adapter support
-   depends on WAN  X86
+   depends on X86
---help---
  Driver for ISA SBNI12-xx cards which are low cost alternatives to
  leased line modems.
@@ -497,5 +494,4 @@ config SBNI_MULTILINE
 
  If unsure, say N.
 
-endmenu
-
+endif # WAN
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo

[PATCH 22/36] Use menuconfig objects II - netdev/pcmcia

[Jan Engelhardt]

Change Kconfig objects from menu, config into menuconfig so
that the user can disable the whole feature without having to
enter the menu first.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

---
 drivers/net/pcmcia/Kconfig |   23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

--- linux-2.6.21-mm_20070428.orig/drivers/net/pcmcia/Kconfig
+++ linux-2.6.21-mm_20070428/drivers/net/pcmcia/Kconfig
@@ -2,11 +2,9 @@
 # PCMCIA Network device configuration
 #
 
-menu PCMCIA network device support
-   depends on NETDEVICES  PCMCIA!=n
-
-config NET_PCMCIA
+menuconfig NET_PCMCIA
bool PCMCIA network device support
+   depends on PCMCIA
---help---
  Say Y if you would like to include support for any PCMCIA or CardBus
  network adapters, then say Y to the driver for your particular card
@@ -21,9 +19,10 @@ config NET_PCMCIA
 
  If unsure, say N.
 
+if NET_PCMCIA
+
 config PCMCIA_3C589
tristate 3Com 3c589 PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
help
  Say Y here if you intend to attach a 3Com 3c589 or compatible PCMCIA
  (PC-card) Ethernet card to your computer.
@@ -33,7 +32,6 @@ config PCMCIA_3C589
 
 config PCMCIA_3C574
tristate 3Com 3c574 PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
help
  Say Y here if you intend to attach a 3Com 3c574 or compatible PCMCIA
  (PC-card) Fast Ethernet card to your computer.
@@ -43,7 +41,6 @@ config PCMCIA_3C574
 
 config PCMCIA_FMVJ18X
tristate Fujitsu FMV-J18x PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
select CRC32
help
  Say Y here if you intend to attach a Fujitsu FMV-J18x or compatible
@@ -54,7 +51,6 @@ config PCMCIA_FMVJ18X
 
 config PCMCIA_PCNET
tristate NE2000 compatible PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
select CRC32
help
  Say Y here if you intend to attach an NE2000 compatible PCMCIA
@@ -65,7 +61,6 @@ config PCMCIA_PCNET
 
 config PCMCIA_NMCLAN
tristate New Media PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
help
  Say Y here if you intend to attach a New Media Ethernet or LiveWire
  PCMCIA (PC-card) Ethernet card to your computer.
@@ -75,7 +70,6 @@ config PCMCIA_NMCLAN
 
 config PCMCIA_SMC91C92
tristate SMC 91Cxx PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
select CRC32
select MII
help
@@ -87,7 +81,6 @@ config PCMCIA_SMC91C92
 
 config PCMCIA_XIRC2PS
tristate Xircom 16-bit PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
help
  Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card)
  Ethernet or Fast Ethernet card to your computer.
@@ -97,7 +90,6 @@ config PCMCIA_XIRC2PS
 
 config PCMCIA_AXNET
tristate Asix AX88190 PCMCIA support
-   depends on NET_PCMCIA  PCMCIA
---help---
  Say Y here if you intend to attach an Asix AX88190-based PCMCIA
  (PC-card) Fast Ethernet card to your computer.  These cards are
@@ -109,7 +101,7 @@ config PCMCIA_AXNET
 
 config ARCNET_COM20020_CS
tristate COM20020 ARCnet PCMCIA support
-   depends on NET_PCMCIA  ARCNET_COM20020  PCMCIA
+   depends on ARCNET_COM20020
help
  Say Y here if you intend to attach this type of ARCnet PCMCIA card
  to your computer.
@@ -119,7 +111,7 @@ config ARCNET_COM20020_CS
 
 config PCMCIA_IBMTR
tristate IBM PCMCIA tokenring adapter support
-   depends on NET_PCMCIA  IBMTR!=y  TR  PCMCIA  !64BIT
+   depends on IBMTR!=y  TR  !64BIT
help
  Say Y here if you intend to attach this type of Token Ring PCMCIA
  card to your computer. You then also need to say Y to Token Ring
@@ -128,5 +120,4 @@ config PCMCIA_IBMTR
  To compile this driver as a module, choose M here: the module will be
  called ibmtr_cs.
 
-endmenu
-
+endif # NET_PCMCIA
-
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: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

[Jan Engelhardt]

On Apr 25 2007 10:45, Waskiewicz Jr, Peter P wrote:
 
 BTW, is there any reason this is being cced to lkml?

Since this change affects how tc interacts with the qdisc layer, I cced
lkml.

Fine with me, at least I get to know that tc could break :)



Jan
-- 
-
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: [PATCH 20/30] Use menuconfig objects - ARCNET

[Jan Engelhardt]

On Apr 11 2007 10:30, Esben Nielsen wrote:
 On Tue, 10 Apr 2007, Jan Engelhardt wrote:
 
 (Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)

 ArcNet is old. Almost nobody is using it anymore. I used it at my
 former job, since we used it as control network. A lot of companies
 still does quitely, but not in combination with Linux.

So send some removal patches :)

 
 -menu ARCnet devices
 +menuconfig ARCNET
 depends on NETDEVICES  (ISA || PCI)

 Why does it depend on ISA || PCI ?

No idea. I just left it as is.

 People tend to forget the PCMCIA driver.

Somewhat somewhat. 32-bit PCMCIA (CONFIG_CARDBUS) depends on PCI,
so with (ISA || PCI) you have probably everything minus
{sbus, mca, 16 bit pcmcia, other exotic parts}.

 And in principle you could enable the ArcNet framework
 without using any of the drivers in the kernel tree.


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

[PATCH 17/30] Use menuconfig objects - IPVS

[Jan Engelhardt]

Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

Index: linux-2.6.21-rc5/net/ipv4/ipvs/Kconfig
===
--- linux-2.6.21-rc5.orig/net/ipv4/ipvs/Kconfig
+++ linux-2.6.21-rc5/net/ipv4/ipvs/Kconfig
@@ -1,10 +1,7 @@
 #
 # IP Virtual Server configuration
 #
-menu   IP: Virtual Server Configuration
-   depends on NETFILTER
-
-config IP_VS
+menuconfig IP_VS
tristate IP virtual server support (EXPERIMENTAL)
depends on NETFILTER
---help---
@@ -25,9 +22,10 @@ config   IP_VS
  If you want to compile it in kernel, say Y. To compile it as a
  module, choose M here. If unsure, say N.
 
+if IP_VS
+
 config IP_VS_DEBUG
bool IP virtual server debugging
-   depends on IP_VS
---help---
  Say Y here if you want to get additional messages useful in
  debugging the IP virtual server code. You can change the debug
@@ -35,7 +33,6 @@ configIP_VS_DEBUG
 
 config IP_VS_TAB_BITS
int IPVS connection table size (the Nth power of 2)
-   depends on IP_VS 
default 12 
---help---
  The IPVS connection hash table uses the chaining scheme to handle
@@ -61,42 +58,35 @@ config  IP_VS_TAB_BITS
  needed for your box.
 
 comment IPVS transport protocol load balancing support
-depends on IP_VS
 
 config IP_VS_PROTO_TCP
bool TCP load balancing support
-   depends on IP_VS
---help---
  This option enables support for load balancing TCP transport
  protocol. Say Y if unsure.
 
 config IP_VS_PROTO_UDP
bool UDP load balancing support
-   depends on IP_VS
---help---
  This option enables support for load balancing UDP transport
  protocol. Say Y if unsure.
 
 config IP_VS_PROTO_ESP
bool ESP load balancing support
-   depends on IP_VS
---help---
  This option enables support for load balancing ESP (Encapsulation
  Security Payload) transport protocol. Say Y if unsure.
 
 config IP_VS_PROTO_AH
bool AH load balancing support
-   depends on IP_VS
---help---
  This option enables support for load balancing AH (Authentication
  Header) transport protocol. Say Y if unsure.
 
 comment IPVS scheduler
-depends on IP_VS
 
 config IP_VS_RR
tristate round-robin scheduling
-   depends on IP_VS
---help---
  The robin-robin scheduling algorithm simply directs network
  connections to different real servers in a round-robin manner.
@@ -106,7 +96,6 @@ config   IP_VS_RR
  
 config IP_VS_WRR
 tristate weighted round-robin scheduling 
-   depends on IP_VS
---help---
  The weighted robin-robin scheduling algorithm directs network
  connections to different real servers based on server weights
@@ -120,7 +109,6 @@ config  IP_VS_WRR
 
 config IP_VS_LC
 tristate least-connection scheduling
-depends on IP_VS
---help---
  The least-connection scheduling algorithm directs network
  connections to the server with the least number of active 
@@ -131,7 +119,6 @@ config  IP_VS_LC
 
 config IP_VS_WLC
 tristate weighted least-connection scheduling
-depends on IP_VS
---help---
  The weighted least-connection scheduling algorithm directs network
  connections to the server with the least active connections
@@ -142,7 +129,6 @@ config  IP_VS_WLC
 
 config IP_VS_LBLC
tristate locality-based least-connection scheduling
-depends on IP_VS
---help---
  The locality-based least-connection scheduling algorithm is for
  destination IP load balancing. It is usually used in cache cluster.
@@ -157,7 +143,6 @@ config  IP_VS_LBLC
 
 config  IP_VS_LBLCR
tristate locality-based least-connection with replication scheduling
-depends on IP_VS
---help---
  The locality-based least-connection with replication scheduling
  algorithm is also for destination IP load balancing. It is 
@@ -176,7 +161,6 @@ config  IP_VS_LBLCR
 
 config IP_VS_DH
tristate destination hashing scheduling
-depends on IP_VS
---help---
  The destination hashing scheduling algorithm assigns network
  connections to the servers through looking up a statically assigned
@@ -187,7 +171,6 @@ config  IP_VS_DH
 
 config IP_VS_SH
tristate source hashing scheduling
-depends on IP_VS
---help---
  The source hashing scheduling algorithm assigns network
  connections to the servers through looking up a statically assigned
@@ -198,7 +181,6 @@ config  IP_VS_SH
 
 config IP_VS_SED
tristate shortest expected delay scheduling
-depends

[PATCH 20/30] Use menuconfig objects - ARCNET

[Jan Engelhardt]

(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)

Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

Index: linux-2.6.21-rc5/drivers/net/arcnet/Kconfig
===
--- linux-2.6.21-rc5.orig/drivers/net/arcnet/Kconfig
+++ linux-2.6.21-rc5/drivers/net/arcnet/Kconfig
@@ -2,10 +2,8 @@
 # Arcnet configuration
 #
 
-menu ARCnet devices
+menuconfig ARCNET
depends on NETDEVICES  (ISA || PCI)
-
-config ARCNET
tristate ARCnet support
---help---
  If you have a network card of this type, say Y and check out the
@@ -25,9 +23,10 @@ config ARCNET
  file:Documentation/networking/net-modules.txt.  The module will
  be called arcnet.
 
+if ARCNET
+
 config ARCNET_1201
tristate Enable standard ARCNet packet format (RFC 1201)
-   depends on ARCNET
help
  This allows you to use RFC1201 with your ARCnet card via the virtual
  arc0 device.  You need to say Y here to communicate with
@@ -38,7 +37,6 @@ config ARCNET_1201
 
 config ARCNET_1051
tristate Enable old ARCNet packet format (RFC 1051)
-   depends on ARCNET
---help---
  This allows you to use RFC1051 with your ARCnet card via the virtual
  arc0s device. You only need arc0s if you want to talk to ARCnet
@@ -53,7 +51,6 @@ config ARCNET_1051
 
 config ARCNET_RAW
tristate Enable raw mode packet interface
-   depends on ARCNET
help
  ARCnet raw mode packet encapsulation, no soft headers.  Unlikely
  to work unless talking to a copy of the same Linux arcnet driver,
@@ -61,7 +58,6 @@ config ARCNET_RAW
 
 config ARCNET_CAP
tristate Enable CAP mode packet interface
-   depends on ARCNET
help
  ARCnet cap mode packet encapsulation. Used to get the hardware
   acknowledge back to userspace. After the initial protocol byte every
@@ -80,7 +76,6 @@ config ARCNET_CAP
 
 config ARCNET_COM90xx
tristate ARCnet COM90xx (normal) chipset driver
-   depends on ARCNET
help
  This is the chipset driver for the standard COM90xx cards. If you
  have always used the old ARCnet driver without knowing what type of
@@ -92,7 +87,6 @@ config ARCNET_COM90xx
 
 config ARCNET_COM90xxIO
tristate ARCnet COM90xx (IO mapped) chipset driver
-   depends on ARCNET
---help---
  This is the chipset driver for the COM90xx cards, using them in
  IO-mapped mode instead of memory-mapped mode. This is slower than
@@ -105,7 +99,6 @@ config ARCNET_COM90xxIO
 
 config ARCNET_RIM_I
tristate ARCnet COM90xx (RIM I) chipset driver
-   depends on ARCNET
---help---
  This is yet another chipset driver for the COM90xx cards, but this
  time only using memory-mapped mode, and no IO ports at all. This
@@ -118,7 +111,6 @@ config ARCNET_RIM_I
 
 config ARCNET_COM20020
tristate ARCnet COM20020 chipset driver
-   depends on ARCNET
help
  This is the driver for the new COM20020 chipset. It supports such
  things as promiscuous mode, so packet sniffing is possible, and
@@ -136,5 +128,4 @@ config ARCNET_COM20020_PCI
tristate Support for COM20020 on PCI
depends on ARCNET_COM20020  PCI
 
-endmenu
-
+endif # ARCNET
#EOF
-
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

[PATCH 21/30] Use menuconfig objects - PHY

[Jan Engelhardt]

(No MAINTAINERS entry. MODULE_AUTHOR lines exist, but without addresses.)

Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

Index: linux-2.6.21-rc5/drivers/net/phy/Kconfig
===
--- linux-2.6.21-rc5.orig/drivers/net/phy/Kconfig
+++ linux-2.6.21-rc5/drivers/net/phy/Kconfig
@@ -2,9 +2,7 @@
 # PHY Layer Configuration
 #
 
-menu PHY device support
-
-config PHYLIB
+menuconfig PHYLIB
tristate PHY Device support and infrastructure
depends on NET_ETHERNET  (BROKEN || !S390)
help
@@ -12,59 +10,52 @@ config PHYLIB
  devices.  This option provides infrastructure for
  managing PHY devices.
 
+if PHYLIB
+
 comment MII PHY device drivers
-   depends on PHYLIB
 
 config MARVELL_PHY
tristate Drivers for Marvell PHYs
-   depends on PHYLIB
---help---
  Currently has a driver for the 88E1011S

 config DAVICOM_PHY
tristate Drivers for Davicom PHYs
-   depends on PHYLIB
---help---
  Currently supports dm9161e and dm9131
 
 config QSEMI_PHY
tristate Drivers for Quality Semiconductor PHYs
-   depends on PHYLIB
---help---
  Currently supports the qs6612
 
 config LXT_PHY
tristate Drivers for the Intel LXT PHYs
-   depends on PHYLIB
---help---
  Currently supports the lxt970, lxt971
 
 config CICADA_PHY
tristate Drivers for the Cicada PHYs
-   depends on PHYLIB
---help---
  Currently supports the cis8204
+
 config VITESSE_PHY
 tristate Drivers for the Vitesse PHYs
-depends on PHYLIB
 ---help---
   Currently supports the vsc8244
 
 config SMSC_PHY
tristate Drivers for SMSC PHYs
-   depends on PHYLIB
---help---
  Currently supports the LAN83C185 PHY
 
 config BROADCOM_PHY
tristate Drivers for Broadcom PHYs
-   depends on PHYLIB
---help---
  Currently supports the BCM5411, BCM5421 and BCM5461 PHYs.
 
 config FIXED_PHY
tristate Drivers for PHY emulation on fixed speed/link
-   depends on PHYLIB
---help---
  Adds the driver to PHY layer to cover the boards that do not have any 
PHY bound,
  but with the ability to manipulate the speed/link in software. The 
relevant MII
@@ -79,5 +70,4 @@ config FIXED_MII_100_FDX
bool Emulation for 100M Fdx fixed PHY behavior
depends on FIXED_PHY
 
-endmenu
-
+endif # PHYLIB
#EOF
-
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

[PATCH 22/30] Use menuconfig objects - toeknring

[Jan Engelhardt]

Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.

Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]

Index: linux-2.6.21-rc5/drivers/net/tokenring/Kconfig
===
--- linux-2.6.21-rc5.orig/drivers/net/tokenring/Kconfig
+++ linux-2.6.21-rc5/drivers/net/tokenring/Kconfig
@@ -2,12 +2,10 @@
 # Token Ring driver configuration
 #
 
-menu Token Ring devices
-   depends on NETDEVICES  !UML
-
 # So far, we only have PCI, ISA, and MCA token ring devices
-config TR
+menuconfig TR
bool Token Ring driver support
+   depends on NETDEVICES  !UML
depends on (PCI || ISA || MCA || CCW)
select LLC
help
@@ -20,9 +18,11 @@ config TR
  from http://www.tldp.org/docs.html#howto. Most people can
  say N here.
 
+if TR
+
 config IBMTR
tristate IBM Tropic chipset based adapter support
-   depends on TR  (ISA || MCA)
+   depends on ISA || MCA
---help---
  This is support for all IBM Token Ring cards that don't use DMA. If
  you have such a beast, say Y and read the Token-Ring mini-HOWTO,
@@ -36,7 +36,7 @@ config IBMTR
 
 config IBMOL
tristate IBM Olympic chipset PCI adapter support
-   depends on TR  PCI
+   depends on PCI
---help---
  This is support for all non-Lanstreamer IBM PCI Token Ring Cards.
  Specifically this is all IBM PCI, PCI Wake On Lan, PCI II, PCI II
@@ -54,7 +54,7 @@ config IBMOL
 
 config IBMLS
tristate IBM Lanstreamer chipset PCI adapter support
-   depends on TR  PCI  !64BIT
+   depends on PCI  !64BIT
help
  This is support for IBM Lanstreamer PCI Token Ring Cards.
 
@@ -66,7 +66,7 @@ config IBMLS
 
 config 3C359
tristate 3Com 3C359 Token Link Velocity XL adapter support
-   depends on TR  PCI
+   depends on PCI
---help---
  This is support for the 3Com PCI Velocity XL cards, specifically
  the 3Com 3C359, please note this is not for the 3C339 cards, you
@@ -84,7 +84,7 @@ config 3C359
 
 config TMS380TR
tristate Generic TMS380 Token Ring ISA/PCI adapter support
-   depends on TR  (PCI || ISA  ISA_DMA_API || MCA)
+   depends on PCI || ISA  ISA_DMA_API || MCA
select FW_LOADER
---help---
  This driver provides generic support for token ring adapters
@@ -108,7 +108,7 @@ config TMS380TR
 
 config TMSPCI
tristate Generic TMS380 PCI support
-   depends on TR  TMS380TR  PCI
+   depends on TMS380TR  PCI
---help---
  This tms380 module supports generic TMS380-based PCI cards.
 
@@ -123,7 +123,7 @@ config TMSPCI
 
 config SKISA
tristate SysKonnect TR4/16 ISA support
-   depends on TR  TMS380TR  ISA
+   depends on TMS380TR  ISA
help
  This tms380 module supports SysKonnect TR4/16 ISA cards.
 
@@ -135,7 +135,7 @@ config SKISA
 
 config PROTEON
tristate Proteon ISA support
-   depends on TR  TMS380TR  ISA
+   depends on TMS380TR  ISA
help
  This tms380 module supports Proteon ISA cards.
 
@@ -148,7 +148,7 @@ config PROTEON
 
 config ABYSS
tristate Madge Smart 16/4 PCI Mk2 support
-   depends on TR  TMS380TR  PCI
+   depends on TMS380TR  PCI
help
  This tms380 module supports the Madge Smart 16/4 PCI Mk2
  cards (51-02).
@@ -158,7 +158,7 @@ config ABYSS
 
 config MADGEMC
tristate Madge Smart 16/4 Ringnode MicroChannel
-   depends on TR  TMS380TR  MCA
+   depends on TMS380TR  MCA
help
  This tms380 module supports the Madge Smart 16/4 MC16 and MC32
  MicroChannel adapters.
@@ -168,7 +168,7 @@ config MADGEMC
 
 config SMCTR
tristate SMC ISA/MCA adapter support
-   depends on TR  (ISA || MCA_LEGACY)  (BROKEN || !64BIT)
+   depends on (ISA || MCA_LEGACY)  (BROKEN || !64BIT)
---help---
  This is support for the ISA and MCA SMC Token Ring cards,
  specifically SMC TokenCard Elite (8115T) and SMC TokenCard Elite/A
@@ -182,5 +182,4 @@ config SMCTR
  To compile this driver as a module, choose M here: the module will be
  called smctr.
 
-endmenu
-
+endif # TR
#EOF
-
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: [PATCH 2/2] NET: Multiqueue network device support implementation.

[Jan Engelhardt]

Hi,


On Apr 9 2007 14:28, Peter P Waskiewicz Jr wrote:
@@ -3345,6 +3358,7 @@ void free_netdev(struct net_device *dev)
 {
 #ifdef CONFIG_SYSFS
   /*  Compatibility with error handling in drivers */
+  kfree((char *)dev-egress_subqueue);
   if (dev-reg_state == NETREG_UNINITIALIZED) {
   kfree((char *)dev - dev-padded);
   return;
@@ -3356,6 +3370,7 @@ void free_netdev(struct net_device *dev)
   /* will free via device release */
   put_device(dev-dev);
 #else
+  kfree((char *)dev-egress_subqueue);
   kfree((char *)dev - dev-padded);
 #endif
 }

Ahem. Explain that cast.



Jan
-- 
-
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: [RFC] div64_64 support

[Jan Engelhardt]

On Feb 23 2007 17:05, Stephen Hemminger wrote:

Since there already two users of full 64 bit division in the kernel,
and other places maybe hiding out as well. Add a full 64/64 bit divide.

Yes this expensive, but there are places where it is necessary.
It is not clear if doing the scaling buys any advantage on 64 bit platforms,
so for them a full divide is done.

---
 include/asm-arm/div64.h  |2 ++
 include/asm-generic/div64.h  |8 
 include/asm-m68k/div64.h |2 ++
 include/asm-mips/div64.h |8 
 include/asm-um/div64.h   |1 +
 include/asm-xtensa/div64.h   |1 +
 lib/div64.c  |   22 ++
 net/ipv4/tcp_cubic.c |   22 --
 net/netfilter/xt_connbytes.c |   16 
 9 files changed, 44 insertions(+), 38 deletions(-)

Actually, there is udivdi3 support in the kernel

./arch/arm26/lib/udivdi3.c
./arch/sh/lib/udivdi3.c
./arch/sparc/lib/udivdi3.S

should not this be consolidated too?




Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
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: [RFC] div64_64 support

[Jan Engelhardt]

On Feb 26 2007 13:28, Stephen Hemminger wrote:
 
 ./arch/arm26/lib/udivdi3.c
 ./arch/sh/lib/udivdi3.c
 ./arch/sparc/lib/udivdi3.S
 
 should not this be consolidated too?

Hmm. Those are the GCC internal versions, that are picked up but
doing divide in place. Do we want to allow general 64 bit in kernel to
be easily used? It could cause sloppy slow code, but it would look
cleaner.

Then our reviewers should catch it, and if not, the janitors will
(/me winks at R.P.J.Day and trivial@).

@@ -134,7 +112,7 @@
*/
   do {
   x1 = x;
-  x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3;
+  x = (2 * x + (u32) (a / x*x)) / 3;

Eye see a bug.

Previously there was div64_64(a, x*x) which is equivalent to
(a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is
equivalent to a*x/x (in the domain of real numbers). Furthermore,
a/x*x is a-(a%x), which does not even remotely match a/(x^2).

Please keep the math intact, thank you ;-)



Jan
-- 
-
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: [RFC] div64_64 support

[Jan Engelhardt]

On Feb 26 2007 15:44, Stephen Hemminger wrote:
 -   x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3;
 +   x = (2 * x + (u32) (a / x*x)) / 3;
 
 Previously there was div64_64(a, x*x) which is equivalent to
 (a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is
 equivalent to a*x/x (in the domain of real numbers). Furthermore,
 a/x*x is a-(a%x), which does not even remotely match a/(x^2).
 
Been there, done that, don't want to repeat it...

I am sorry I don't quite follow.


Jan
-- 
-
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: [RFC] div64_64 support

[Jan Engelhardt]

On Feb 26 2007 16:07, Stephen Hemminger wrote:
 On Feb 26 2007 15:44, Stephen Hemminger wrote:
  -x = (2 * x + (uint32_t) div64_64(a, x*x)) / 3;
  +x = (2 * x + (u32) (a / x*x)) / 3;
  
  Previously there was div64_64(a, x*x) which is equivalent to
  (a)/(x*x), or just: a/(x^2). But now you do a/x*x, which is
  equivalent to a*x/x (in the domain of real numbers). Furthermore,
  a/x*x is a-(a%x), which does not even remotely match a/(x^2).
  
 Been there, done that, don't want to repeat it...
 
 I am sorry I don't quite follow.

Once before a missed paren's caused a TCP congestion window bug that
took 6 months before it was found...

Hah, just as I expected.

|On Tue, 27 Feb 2007 00:02:50 +0100 (MET), Jan Engelhardt wrote:
|Then our reviewers should catch it, and if not, the janitors will.


Jan
-- 
-
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: [PATCH]ip_auto_config bug in 2.6.20-rc6

[Jan Engelhardt]

On Feb 2 2007 14:09, Joakim Tjernlund wrote:
On Thu, 2007-02-01 at 12:26 +0100, Joakim Tjernlund wrote:
 The following commandline:
  root=/dev/mtdblock6 rw rootfstype=jffs2 
 ip=192.168.1.10:::255.255.255.0:localhost.localdomain:eth1:off 
 console=ttyS0,115200
 makes ip_auto_config fall back to DHCP and complain IP-Config: Incomplete 
 network configuration information.
 depending on if CONFIG_IP_PNP_DHCP is set or not.
 
 The only way I can make ip_auto_config accept my IP config is to add an 
 entry for the server IP:
 ip=192.168.1.10:192.168.1.15::255.255.255.0:localhost.localdomain:eth1:off
 
 I think this is a bug since I am not using a NFS root FS.

I just wonder why IP_PNP has not been obsoleted and removed from the 
tree yet, given that initramfs is the advertised way to do so such 
things.


Jan
-- 
-
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: owner-Match in 2.6.20-rc5 (fwd)

[Jan Engelhardt]

  The report below was posted on the netfilter user list. Isn't there any 
  ill side effect by reverting the change?
 
 Performance regression :-(
 
 This optimization saves a whole handful of heavy atomic operations in
 the packet transmit path of TCP.
 
 As I understand it, the owner-Match is not in the upstream tree, and
 it's the only thing that cares, so I see no reason to cater for it.
 
 For me, it's there.
 -rw-r--r-- 1 jengelh users 2247 Jan 25 21:37
 /erk/kernel/linux-2.6.20-rc6/net/ipv4/netfilter/ipt_owner.c

Ok, I'll see what I can do about this :-)


People really depend on this. Much more than than pid/comm/smpunsafe stuff.
For example, a web server [cgi enabled, etc.] which also runs squid,
to force all webtraffic through it:

-A OUTPUT -p tcp --dport 80 -m owner ! --uid-owner
  squid -j REDIRECT --to-ports 3128


-`J'
-- 
-
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