On Thu, 17 Jan 2008 23:33:54 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9773
>
>Summary: pptp/ppp connection die at high speed on Athlon X2 6000+
>Product: Networking
>Version: 2.5
> KernelVersion: 2.6.23.12
>
On Fri, 7 Dec 2007, Vitaly Bordug wrote:
>
> fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> not connected to the real MDIO bus.
>
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>
> ---
>
> Documentation/powerpc/booting-
On Fri, 7 Dec 2007, Vitaly Bordug wrote:
>
> ...thus use fixed-link to register proper "Fixed PHY"
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
>
applied.
- k
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
On Fri, 7 Dec 2007, Vitaly Bordug wrote:
>
> With that patch fixed.c now fully emulates MDIO bus, thus no need
> to duplicate PHY layer functionality. That, in turn, drastically
> simplifies the code, and drops down line count.
>
> As an additional bonus, now there is no need to register MDIO bus
Herbert Xu wrote:
> On Thu, Jan 17, 2008 at 03:31:14PM +0200, Timo Teräs wrote:
>> I guess the idea was that application should know about the SAs it
>> created. Though a SA dump needs to be done if you want to check
>> for existing entries (created by other processes, or if you are
>> recovering f
In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 11:13:19 +0900 (JST)),
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says:
> Assuming IN_BADCLASS() is still there, we should not reuse the name
> of "ipv6_is_badclass" because the their meanings are different.
Again, ipv4_is_badclass()
My h
In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 02:52:08 +0100 (CET)), Jan
Engelhardt <[EMAIL PROTECTED]> says:
>
> On Jan 18 2008 10:26, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> >> -#define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) ==
> >> 0xf000)
> >> -#define IN_BADCLASS(
In researching the linux implementation of syn cookies I stumbled on a few
points that aren't initially clear to me. I was hoping somehow could elaborate
and shed some light onto what I'm missing.
at net/ipv6/tcp_ipv6.c:1249 within tcp_v6_conn_request()
There is the following comment:
/
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_
Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
>> Andrew Morton <[EMAIL PROTECTED]> wrote:
>> [...]
>>> Can we get this bug fixed please? Today? It has been known about for more
>>> than two months.
>>
>> I just reposted the complete fix; it's #1 of the series of 7.
>
>Bad news. :( 2.6.24-rc7
In article <[EMAIL PROTECTED]> (at Fri, 18 Jan 2008 02:13:52 +0100 (CET)), Jan
Engelhardt <[EMAIL PROTECTED]> says:
> 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
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
On Fri, Jan 18, 2008 at 12:04:06AM +0100, Jan Engelhardt wrote:
>
> On Jan 7 2008 17:10, Vince Fuller wrote:
> >--- net/ipv4/devinet.c.orig 2007-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
On Thu, 17 Jan 2008 16:25:02 -0800
Jay Vosburgh <[EMAIL PROTECTED]> wrote:
> Fix the handling of rtnl and the bonding_rwsem to always be acquired
> in a consistent order (rtnl, then bonding_rwsem).
>
> The existing code sometimes acquired them in this order, and sometimes
> in the opposite order,
Andrew Morton <[EMAIL PROTECTED]> wrote:
[...]
>Can we get this bug fixed please? Today? It has been known about for more
>than two months.
I just reposted the complete fix; it's #1 of the series of 7.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED
Change bond_mii_monitor to not hold any locks when calling rtnl_unlock,
as rtnl_unlock can sleep (when acquring another mutex in netdev_run_todo).
Bug reported by Makito SHIOKAWA <[EMAIL PROTECTED]>, who
included a different patch.
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/
A recent change to add an additional hash policy modified
bond_parse_parm, but it now does not correctly match parameters passed in
via sysfs.
Rewrote bond_parse_parm to handle (a) parameter matches that
are substrings of one another and (b) user input with whitespace (e.g.,
sysfs
Fix the handling of rtnl and the bonding_rwsem to always be acquired
in a consistent order (rtnl, then bonding_rwsem).
The existing code sometimes acquired them in this order, and sometimes
in the opposite order, which opens a window for deadlock between ifenslave
and sysfs.
Signed-off-by: Jay Vo
Fix the functions that store the primary and active slave
options via sysfs to hold the correct locks in the correct order.
The bond_change_active_slave and bond_select_active_slave
functions both require rtnl, bond->lock for read and curr_slave_lock for
write_bh, and no other lock
Add a call to bond_release_all in the bonding netdev event
handler for the master. This releases the slaves for the case of, e.g.,
"echo -bond0 > /sys/class/net/bonding_masters", which otherwise will spin
forever waiting for references to be released.
Signed-off-by: Jay Vosburgh <[EMAIL P
Move an ASSERT_RTNL down to where we should hold only RTNL;
the existing check produces spurious warnings because we hold additional
locks at _bh, tripping a debug warning in spin_lock_mutex().
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_alb.c |5 ++---
alb_fasten_mac_swap (actually rlb_teach_disabled_mac_on_primary)
requries RTNL and no other locks. This could cause dev_set_promiscuity
and/or dev_set_mac_address to be called with improper locking.
Changed callers to hold only RTNL during calls to alb_fasten_mac_swap
or functions
Following are seven patches to fix locking problems,
silence locking-related warnings and resolve one recent regression
in the current 2.6.24-rc.
The first three patches are reposts, the rest are new.
patch 1: fix locking in sysfs primary/active selection
Call cor
Hi Dave,
Here goes an IrDA patch against your latest net-2.6 tree.
This patch fixes some af_irda memory leaks.
It also checks for irias_new_obect() return value.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
net/irda/af_irda.c | 30
On Mon, 14 Jan 2008 15:01:13 -0800
Jay Vosburgh <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> [...]
> >That's bond_lock.
> >
> >This patch (below) addresses what appears to me to be an obvious
> >imbalance in rtnl_lock.
> >
> >I don't care how it's fixed, really. Someone
On Mon, 14 Jan 2008 22:05:28 +0100
supersud501 <[EMAIL PROTECTED]> wrote:
>
>
> Stephen Hemminger wrote:
> > Please test this patch against Linus's current (approx 2.6.24-rc7-git5).
> > Ignore Andrew's premature reversion attempt...
> >
> > This patch disables config mode access after clearing
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
Please pull from branch 'ipg-fixes' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git ipg-fixes
to get the changes below.
Distance from 'master' (d8c89eb3a12f0da96d049bd515c7fa3702e511c5)
-
47cccd7d7
Hi,
I tried 2.6.24-rc8 on my Mac mini Core Duo and noticed that WOL didn't
work anymore, whereas I never had a WOL failure with 2.6.23. The above
patch fixes WOL with 2.6.24-rc8 for me.
Thanks for tracking it down even before I was hit by this regression.
:-)
Regards,
Tino
--
To unsubscribe from
On Thu, Jan 17, 2008 at 03:31:14PM +0200, Timo Teräs wrote:
>
> I guess the idea was that application should know about the SAs it
> created. Though a SA dump needs to be done if you want to check
> for existing entries (created by other processes, or if you are
> recovering from a crash).
That's
On Thu, 2008-01-03 at 17:36 -0600, Nate Case wrote:
> PHY read/write functions can potentially sleep (e.g., a PHY accessed
> via I2C). The following changes were made to account for this:
>
> * Change spin locks to mutex locks
> * Add a BUG_ON() to phy_read() phy_write() to warn against
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
Acked-by: Benjamin He
On Tue, 2008-01-08 at 03:19 -0800, David Brownell wrote:
> > Our
> > module version checks OID_GEN_PHYSICAL_MEDIUM in generic_rndis_bind,
> > with rndis_host bind fails if OID is supported and wireless media
type
> > is returned, with rndis_wext if OID isn't supported or type isn't
> > wireless. S
On Thu, Jan 17, 2008 at 06:04:35PM +0100, Aurélien Charbon wrote:
> Hi Bruce.
>
> Thanks for your comments.
> Here is the patch with some cleanups.
Thanks for the revisions. We need to submit this with a patch comment
that:
- Explains more precisely what this does (fixes export
ibm_emac/ibm_emac_mal.c:mal_poll: Fix MAL_DBG2 invocation
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.c
b/drivers/net/ibm_emac/ibm_emac_mal.c
index dcd8826..1977791 100644
--- a/drivers/net/ibm_emac/ibm_emac_mal.c
+++ b/drivers/net/ibm_emac/ib
Aurélien Charbon wrote:
Thanks for your comments.
Here is the patch with some cleanups.
Hi Aurelien,
Just two nits.
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -400,6 +400,15 @@ static inline int ipv6_addr_v4mapped(const struct in6_addr
*a)
a->s6_addr32[2] == htonl
Hi Bruce.
Thanks for your comments.
Here is the patch with some cleanups.
Regards,
Aurélien
--
Aurelien Charbon
Linux NFSv4 team
Bull SAS
Echirolles - France
http://nfsv4.bullopensource.org/
>From 517
On Thu, 17 Jan 2008 17:57:58 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> I assume that these ancient network drivers were trying to find out if
> an irq is available. eepro.c expecting +EBUSY was doubly wrong.
>
> I'm not sure that can_request_irq() is the right thing, but these drivers
> a
Herbert Xu wrote:
> On Thu, Jan 17, 2008 at 07:42:30AM -0500, jamal wrote:
>> Looking at the pfkey RFC one more time, heres a funny quote:
>> "
>> The dump message is used for debugging
>> purposes only and is not intended for production use.
>> "
>
> In fact it goes much further:
>
>Support
On Thu, 2008-17-01 at 23:50 +1100, Herbert Xu wrote:
> In fact it goes much further:
>
>Support for the dump message MAY be discontinued in future versions
>of PF_KEY. Key management applications MUST NOT depend on this
>message for basic operation.
No doubt PF_KEY being an RFC has
On Thu, Jan 17, 2008 at 07:42:30AM -0500, jamal wrote:
>
> Looking at the pfkey RFC one more time, heres a funny quote:
> "
> The dump message is used for debugging
> purposes only and is not intended for production use.
> "
In fact it goes much further:
Support for the dump message MAY be di
On Thu, 2008-17-01 at 07:54 +0200, Timo Teräs wrote:
> You listen for the events. It is guaranteed that if the dumping code
> does return the entry to be deleted, the deletion notification will
> occur after that dump entry.
Ok, sounds reasonable - as long as there is a known order for
occurances
"Ilpo Järvinen" <[EMAIL PROTECTED]> writes:
>
> Besides, it not always that obvious that gcc is able to determine "the
> constant state", considering e.g., the complexity in the cases with
> tcp_rcv_synsent_state_process, tcp_close_state, tcp_done. In such cases
> uninlining should be done and gcc
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 13:00:09 +0200
>
>> IMHO, it's a lot better then losing >50% of entries and the end
>> of sequence message on big dumps. SPD and SADB are not that
>> volatile; in most of the cases the dump would be as good as an
>
On Thu, 2008-17-01 at 22:11 +1100, Herbert Xu wrote:
> Sure racoon uses pfkey but the question is does it use pfkey dumping?
>
it does when trying to purge phase 2 SAs...
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
Herbert Xu wrote:
> On Thu, Jan 17, 2008 at 07:54:32AM +0200, Timo Teräs wrote:
>>> Racoon doesn't use pfkey dumping as far as I know.
>> ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
>> make it use netlink; it relies heavily all around the code to pfkey
>> structs. It also
Alexey Dobriyan wrote:
On Thu, Jan 17, 2008 at 11:40:42AM +0100, Daniel Lezcano wrote:
Alexey Dobriyan wrote:
commit c064c4811b3e87ff8202f5a966ff4eea0bc54575
Author: Daniel Lezcano <[EMAIL PROTECTED]>
Date: Thu Jan 10 02:56:03 2008 -0800
[NETNS][IPV6]: Make ip6_frags per namespace.
On Thu, Jan 17, 2008 at 02:30:37PM +0900, Makito SHIOKAWA wrote:
>> Maybe I'm wrong, but since this read_lock() is given and taken anyway,
>> it seems this looks a bit better to me (why hold this rtnl longer
>> than needed?):
>> read_unlock(&bond->lock);
>> rtnl_unlock();
On Thu, Jan 17, 2008 at 11:40:42AM +0100, Daniel Lezcano wrote:
> Alexey Dobriyan wrote:
> >>commit c064c4811b3e87ff8202f5a966ff4eea0bc54575
> >>Author: Daniel Lezcano <[EMAIL PROTECTED]>
> >>Date: Thu Jan 10 02:56:03 2008 -0800
> >>
> >>[NETNS][IPV6]: Make ip6_frags per namespace.
> >>
>
Move the ingress qdisc members of struct net_device from the transmit
cache line to the receive cache line to avoid cache line ping-pong.
These members are only used on the receive path.
Signed-off-by: Neil Turton <[EMAIL PROTECTED]>
---
--- net-2.6.25.git-orig/include/linux/netdevice.h 200
On Thu, Jan 17, 2008 at 02:30:36PM +0900, Makito SHIOKAWA wrote:
>> But, since during this change from sysfs cancel_delayed_work_sync()
>> could be probably used, and it's rather efficient with killing
>> rearming works, it seems this check could be unnecessary yet.
> What going to be cancelled in
On Thu, Jan 17, 2008 at 07:54:32AM +0200, Timo Teräs wrote:
>
> > Racoon doesn't use pfkey dumping as far as I know.
>
> ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
> make it use netlink; it relies heavily all around the code to pfkey
> structs. It also runs on BSD so we
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 13:00:09 +0200
> IMHO, it's a lot better then losing >50% of entries and the end
> of sequence message on big dumps. SPD and SADB are not that
> volatile; in most of the cases the dump would be as good as an
> atomic one.
I humbly disagr
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 12:01:17 +0200
>
>> David Miller wrote:
>>> This is an inherent aspect of AF_KEY (and what it was
>>> derived from, BSD routing sockets).
>> Yes, this is the way BSD does it.
>>
>>> It has to provide dumps atomic
Denis V. Lunev wrote:
FIB rule->action should operate in the same namespace as fib_lookup.
This is definitely missed right now.
There are two ways to implement this: pass struct net into another rules
API call (2 levels) or place netns into rule struct directly. The second
approach seems better
Alexey Dobriyan wrote:
commit c064c4811b3e87ff8202f5a966ff4eea0bc54575
Author: Daniel Lezcano <[EMAIL PROTECTED]>
Date: Thu Jan 10 02:56:03 2008 -0800
[NETNS][IPV6]: Make ip6_frags per namespace.
The ip6_frags is moved to the network namespace structure. Because
there can be
Jens-san,
> Hi Ishizaki,
>
> Linas has left the company and is no longer doing kernel related stuff,
> so I suggest, given Jeff is ok with that, that the two of us take over
> spidernet maintainership.
(snip)
> Change maintainership for spidernet.
>
> Signed-off-by: Jens Osterkamp <[EMAIL PROTECT
Save namespace context on the fib rule at the rule creation time and call
routing lookup in the correct namespace.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
Acked-by: Daniel Lezcano <[EMAIL PROTECTED]>
---
include/net/fib_rules.h |1 +
net/core/fib_rules.c|2 ++
net/ipv4/fib_r
The backward link from FIB rules operations to the network namespace will
allow to simplify the API a bit.
Signed-off-by: Denis V. Lunev <[EMAIL PROTECTED]>
Acked-by: Daniel Lezcano <[EMAIL PROTECTED]>
---
include/net/fib_rules.h |1 +
net/decnet/dn_rules.c |1 +
net/ipv4/fib_rules.c
Remove struct net from fib_rules_register(unregister)/notify_change paths
and diet code size a bit.
add/remove: 0/0 grow/shrink: 10/12 up/down: 35/-100 (-65)
function old new delta
notify_rule_change 273 280 +7
trie_show_
FIB rule->action should operate in the same namespace as fib_lookup.
This is definitely missed right now.
There are two ways to implement this: pass struct net into another rules
API call (2 levels) or place netns into rule struct directly. The second
approach seems better as the code will grow le
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 12:01:17 +0200
> David Miller wrote:
> > This is an inherent aspect of AF_KEY (and what it was
> > derived from, BSD routing sockets).
>
> Yes, this is the way BSD does it.
>
> > It has to provide dumps atomically, and if there is no
>
> commit c064c4811b3e87ff8202f5a966ff4eea0bc54575
> Author: Daniel Lezcano <[EMAIL PROTECTED]>
> Date: Thu Jan 10 02:56:03 2008 -0800
>
> [NETNS][IPV6]: Make ip6_frags per namespace.
>
> The ip6_frags is moved to the network namespace structure. Because
> there can be multiple
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 11:38:13 +0200
>
>> The af_key issue is that in big dumps you get only first X
>> entries. The rest of the entries are dropped because the
>> socket receive buffer goes full. You get data corruption:
>> missing ent
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 07:40:07 -0200
> I'll update this machine today to 2.6.24-rc8-git + net-2.6 and try again
> to reproduce.
Thanks for the datapoints and testing.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bo
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 11:38:13 +0200
> The af_key issue is that in big dumps you get only first X
> entries. The rest of the entries are dropped because the
> socket receive buffer goes full. You get data corruption:
> missing entries.
This is an inherent asp
Em Thu, Jan 17, 2008 at 12:00:02AM -0800, David Miller escreveu:
> From: Frans Pop <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 08:51:55 +0100
>
> > On Thursday 17 January 2008, David Miller wrote:
> > > From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> > >
> > > > We spent Wednesday trying to repro
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 11:20:42 +0200
>
>> Where as the pfkey bug fix is non-intrusive and helps all
>> legacy applications still using af_key by _fixing a bug in
>> kernel_.
>
> It's not a bug. You're fixing a speed issue, not a crash
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 11:20:42 +0200
> Where as the pfkey bug fix is non-intrusive and helps all
> legacy applications still using af_key by _fixing a bug in
> kernel_.
It's not a bug. You're fixing a speed issue, not a crash
or a case where AF_KEY is provid
David Miller wrote:
> From: Timo_Teräs <[EMAIL PROTECTED]>
> Date: Thu, 17 Jan 2008 10:11:17 +0200
>
>> I thought my patch would qualify as "life support" bug fix.
>> Currently racoon fails to work if there are too many SPDs or SAs
>> because the kernel cannot handle the dump request properly. And
From: Timo_Teräs <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 10:11:17 +0200
> I thought my patch would qualify as "life support" bug fix.
> Currently racoon fails to work if there are too many SPDs or SAs
> because the kernel cannot handle the dump request properly. And this
> is what my patch fixe
On Thu, 17 Jan 2008 00:30:49 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9767
>
>Summary: missing native u32 classifier for routing policy
>Product: Networking
>Version: 2.5
> KernelVersion: all since 2.2
> P
David Miller wrote:
> Doing anything other than "life support" bug fixes for AF_KEY is
> inappropriate.
Yes. I thought my patch would qualify as "life support" bug fix.
Currently racoon fails to work if there are too many SPDs or SAs
because the kernel cannot handle the dump request properly. And
From: Frans Pop <[EMAIL PROTECTED]>
Date: Thu, 17 Jan 2008 08:51:55 +0100
> On Thursday 17 January 2008, David Miller wrote:
> > From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
> >
> > > We spent Wednesday trying to reproduce (without the patch) these issues
> > > without much luck, and have applied
74 matches
Mail list logo
