On Monday 2020-10-12 19:04, Stephen Hemminger wrote:
>
>> +static struct color_code {
>> +const char match[8], *code;
>> +int len;
>> +} color_codes[C_MAX] = {
>> +{"iface="}, {"lladdr="}, {"v4addr="}, {"v6addr="}, {"operup="},
>> +{"operdn="}, {"clear=", "0", 1},
>> };
>
>Also i
Implement fine-grained control over color codes for iproute, very
similar to the GCC_COLORS environment variable.
Signed-off-by: Jan Engelhardt
---
lib/color.c | 125 +-
man/man8/ip.8 | 25 --
2 files changed, 83 insertions(+), 67
Implement fine-grained control over color codes for iproute, very
similar to the GCC_COLORS environment variable.
Signed-off-by: Jan Engelhardt
---
lib/color.c | 127 --
man/man8/ip.8 | 25 --
2 files changed, 81 insertions(+), 71
-off-by: Jan Engelhardt
---
ip/ipnetns.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 46cc235b..e7a45653 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -78,6 +78,8 @@ static int ipnetns_have_nsid(void)
if (have_rtnl_getnsid
On Thursday 2020-09-24 18:11, Stephen Hemminger wrote:
>> >
>> >MFLAGS is a way to pass flags from original make into the sub-make.
>>
>> MAKEFLAGS and MFLAGS are already exported by make (${MAKE} is magic
>> methinks), so they need no explicit passing. You can check this by
>> adding somethin
On Tuesday 2020-09-22 02:22, Stephen Hemminger wrote:
>Jan Engelhardt wrote:
>
>> `ip addr` when run under qemu-user-riscv64, fails. This likely is
>> due to qemu-5.1 not doing translation of RTM_GETNSID calls.
>>
>> 2: host0@if5: mtu 1500 qdisc noqueue state
On Tuesday 2020-09-22 02:19, Stephen Hemminger wrote:
>> I observe:
>>
>> » make -j8 CCOPTS=-ggdb3
>> lib
>> make[1]: warning: -j8 forced in submake: resetting jobserver mode.
>> make[1]: Nothing to be done for 'all'.
>> ip
>> make[1]: warning: -j8 forced in submake
Treat the situation similar to an absence of procfs.
Signed-off-by: Jan Engelhardt
---
ip/ipnetns.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 46cc235b..8fab51cd 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -85,8 +85,9 @@ static
I observe:
» make -j8 CCOPTS=-ggdb3
lib
make[1]: warning: -j8 forced in submake: resetting jobserver mode.
make[1]: Nothing to be done for 'all'.
ip
make[1]: warning: -j8 forced in submake: resetting jobserver mode.
CC ipntable.o
M
On Wednesday 2020-07-29 10:04, David Laight wrote:
>From: Christoph Hellwig
>> Sent: 28 July 2020 17:39
>>
>> While the kernel in general is not strict aliasing safe we can trivially
>> do that in sockptr_is_null without affecting code generation, so always
>> check the actually assigned union
On Thursday 2020-07-23 08:08, Christoph Hellwig wrote:
>+typedef struct {
>+ union {
>+ void*kernel;
>+ void __user *user;
>+ };
>+ boolis_kernel : 1;
>+} sockptr_t;
>+
>+static inline bool sockptr_is_null(sockptr_t sockptr)
>+{
On Monday 2020-06-15 01:34, Alexander A. Klimov wrote:
>>
>> A header file rename is no problem. We even have dummy headers
> Hmm.. if I understand all of you correctly, David, Stefano, Pablo and Al say
> like no, not a good idea, but only you, Jan, say like should be no problem.
>
> Jan, do you
On Friday 2020-06-19 09:46, Christoph Hellwig wrote:
>On Fri, Jun 19, 2020 at 12:06:45AM +0300, Alexey Dobriyan wrote:
>> Rename
>> struct notifier_block *this
>> to
>> struct notifier_block *nb
>>
>> "nb" is arguably a better name for notifier block.
>
>But not enough better to cause t
On Sunday 2020-06-14 22:19, David Howells wrote:
>Alexander A. Klimov wrote:
>
>> *Is it a good idea to rename files in include/uapi/ ?*
>
>Very likely not. If programs out there are going to be built on a
>case-sensitive filesystem (which happens all the time), they're going to break
>if you r
Signed-off-by: Jan Engelhardt
---
4th time is the charm?!
extensions/libip6t_REJECT.man | 20
extensions/libipt_REJECT.man | 20
2 files changed, 40 insertions(+)
diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man
index
Signed-off-by: Jan Engelhardt
---
Spello fix near "indiscriminately".
extensions/libip6t_REJECT.man | 20
extensions/libipt_REJECT.man | 20
2 files changed, 40 insertions(+)
diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_
Signed-off-by: Jan Engelhardt
---
Simplify the trigger case by dropping mentions of P_3.
New -A commands as proposed.
extensions/libip6t_REJECT.man | 20
extensions/libipt_REJECT.man | 20
2 files changed, 40 insertions(+)
diff --git a/extensions
Signed-off-by: Jan Engelhardt
---
Maciej's explanation on how INVALID+REJECT can lead to problems looks
convincing. I hereby present new manpage wording in the form of "if A, then B"
to better build the argument of avoiding REJECT. So the issue is not caused by
an _incoming_
On Saturday 2020-05-09 07:22, Maciej Żenczykowski wrote:
>diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man
>index 0030a51f..b6474811 100644
>--- a/extensions/libip6t_REJECT.man
>+++ b/extensions/libip6t_REJECT.man
>@@ -30,3 +30,18 @@ TCP RST packet to be sent back. This
On Wednesday 2020-05-06 08:50, Huang Qijun wrote:
>When compiling netfilter, there will be an error
>"No rule to make target 'net/netfilter/xt_TCPMSS.o'",
>because the xt_TCPMSS.c in the makefile is uppercase,
>and the file name of the source file (xt_tcpmss.c) is lowercase.
>-obj-$(CONFIG_NETFIL
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
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, a
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 watc
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 i
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 do
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 ha
On Sunday 2017-04-09 05:42, Arushi Singhal wrote:
>On Sun, Apr 9, 2017 at 1:44 AM, Pablo Neira Ayuso 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 ex
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.
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
>c
On Tuesday 2017-03-28 18:23, SIMRAN SINGHAL wrote:
>On Tue, Mar 28, 2017 at 7:24 PM, Jan Engelhardt wrote:
>> On Tuesday 2017-03-28 15:13, simran singhal wrote:
>>
>>>Some functions like kmalloc/kzalloc return NULL on failure. When NULL
>>>repres
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
"upp
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 = kza
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/netfi
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
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 si
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
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;
>>> > >
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__((a
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 an
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 con
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)
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 < anc
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
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
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/lib
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 @@ TIPCO
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
>
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] =
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
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 cas
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 lengt
On Feb 19 2008 15:45, Patrick McHardy wrote:
>>
>> It's in busybox 1.9.1. Just including 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 gu
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
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 th
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 di
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 = { ... };
--
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
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
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 @@
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..d
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c |2 +-
drivers/net/hamradio/bpqether.c |2 +-
drivers/net/hamradio/scc.c |2 +-
drivers/net/hamradio/yam.c |2 +-
drivers/net/ibm
t 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 +0
n)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 20
f6354a5634b5dccb8e
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")
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
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
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)
On Dec 31 2007 18:43, Patrick Mau wrote:
>
>May I ask something that might be obvious for most of the
>development community:
>
>Modules have to be loaded in seperate pages, right ?
That seems to be the case, judging from /proc/modules always ending in 000,
meaning each module is aligned at 0x100
On Dec 31 2007 16:19, Bodo Eggert wrote:
>Adrian Bunk wrote:
>>
>> The only advantage I see is that the kernel image you have to flash
>> can be made smaller - with the disadvantage that the running kernel
>> is bigger by more than 10%.
>>
>> If you don't believe me, try it yourself:
>> Build a
On Dec 29 2007 02:09, Adrian Bunk wrote:
>On Sat, Dec 29, 2007 at 12:45:12AM +0100, Jan Engelhardt wrote:
>> Turn CONFIG_FC, CONFIG_FDDI, CONFIG_HIPPI and CONFIG_TR into tristate
>> so they can be built as modules. This will allow CONFIG_LLC to be
>> built as a module too,
266008 380928 3451976 34ac48 vmlinux.previous
2794603 265620 380928 3441151 3481ff vmlinux
$ l vmlinux.previous vmlinux
-rwxr-xr-x 1 jengelh users 5154214 Dec 29 00:02 vmlinux.previous
-rwxr-xr-x 1 jengelh users 5135974 Dec 29 00:39 vmlinux
Signed-off-by: Jan Engelhardt <[EMAIL PROTEC
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 du
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 sh
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, wh
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
>>
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_(__be32 addr)
>
>Adds type safety and arguably some readability.
>
>Changes since last submission:
>
>Removed ipv4_addr_octets function
>U
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
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 dosomethi
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_81
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 "
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
>> > ot
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 c
On Oct 28 2007 10:34, Russell King wrote:
>On Sat, Oct 27, 2007 at 03:40:04PM -0700, Joe Perches wrote:
>> and forward declarations of
>>
>> struct proc_dir_entry;
>> struct file_operations;
>>
>> As a general rule, I think it better to use includes
>> than use naked forward declarations.
>
>If
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
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 *
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
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
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-devel&m=117394977210823&w=2
http://marc.info/?l=netfilter-devel&m=117400063907706&w=2
in the end, my proposa
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
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 mess
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-2007
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
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
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: w
On Aug 12 2007 20:21, [EMAIL PROTECTED] wrote:
>
> per the message below MD (or DM) would need to be modified to work
> reasonably well with one of the disk components being over an
> unreliable link (like a network link)
Does not dm-multipath do something like that?
> are the MD/DM maintainers
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
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 ac
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
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.
>>
>
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
==
1 - 100 of 149 matches
Mail list logo
