* Re: possible kernel oops from user MSS
From: Li Yewang @ 2010-11-23 2:48 UTC (permalink / raw)
To: David Miller; +Cc: mzhang, netdev
In-Reply-To: <20101112.152607.193708973.davem@davemloft.net>
At 2010-11-13 7:26, David Miller wrote:
> From: Min Zhang<mzhang@mvista.com>
> Date: Fri, 12 Nov 2010 14:59:58 -0800
>
>> Regarding commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 ("tcp:
>> Increase TCP_MAXSEG socket option minimum"). What is the reason
>> TCP_MAXSEG minimum be 64? Isn't the exact be 40 which is
>> TCPOLEN_MD5SIG_ALIGNED(20) + TCPOLEN_TSTAMP_ALIGNED(12) + 8?
>>
>> Or is it better to use TCP_MIN_MSS from tcp.h:
>>
>> /* Minimal accepted MSS. It is (60+60+8) - (20+20). */
>> #define TCP_MIN_MSS 88U
>
> I suppose TCP_MIN_MSS would be better to use, I'll make that
> change, thanks.
David, do you have plan to fix this bug using TCP_MIN_MSS?
^ permalink raw reply
* Re: possible kernel oops from user MSS
From: David Miller @ 2010-11-23 2:59 UTC (permalink / raw)
To: lyw; +Cc: mzhang, netdev
In-Reply-To: <4CEB2B8E.3090904@cn.fujitsu.com>
From: Li Yewang <lyw@cn.fujitsu.com>
Date: Tue, 23 Nov 2010 10:48:46 +0800
>
>
> At 2010-11-13 7:26, David Miller wrote:
>> From: Min Zhang<mzhang@mvista.com>
>> Date: Fri, 12 Nov 2010 14:59:58 -0800
>>
>>> Regarding commit 7a1abd08d52fdeddb3e9a5a33f2f15cc6a5674d2 ("tcp:
>>> Increase TCP_MAXSEG socket option minimum"). What is the reason
>>> TCP_MAXSEG minimum be 64? Isn't the exact be 40 which is
>>> TCPOLEN_MD5SIG_ALIGNED(20) + TCPOLEN_TSTAMP_ALIGNED(12) + 8?
>>>
>>> Or is it better to use TCP_MIN_MSS from tcp.h:
>>>
>>> /* Minimal accepted MSS. It is (60+60+8) - (20+20). */
>>> #define TCP_MIN_MSS 88U
>>
>> I suppose TCP_MIN_MSS would be better to use, I'll make that
>> change, thanks.
>
> David, do you have plan to fix this bug using TCP_MIN_MSS?
I will, it's deep in my backlog and pretty low priority right now.
^ permalink raw reply
* RE: ixgbe dump
From: Skidmore, Donald C @ 2010-11-23 3:31 UTC (permalink / raw)
To: Yinghai Lu, Kirsher, Jeffrey T; +Cc: Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <AANLkTi=Esp=y2ci=RrCeXYVaxnbrJY3NXpaBgPOBqc7p@mail.gmail.com>
Hi Yinghai,
I was hoping we could have had this patch pushed upstream sooner, but we have quite a few in our internal queue right now.
If this doesn't solve your issue please let me know.
Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>
After freeing the rings we were not zeroing out the ring count values.
This patch now clears these counts correctly.
Reported-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index fbad4d8..eee0b29 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -4771,6 +4771,9 @@ void ixgbe_clear_interrupt_scheme(struct ixgbe_adapter *adapter)
adapter->rx_ring[i] = NULL;
}
+ adapter->num_tx_queues = 0;
+ adapter->num_rx_queues = 0;
+
ixgbe_free_q_vectors(adapter);
ixgbe_reset_interrupt_capability(adapter);
}
>-----Original Message-----
>From: yhlu.kernel@gmail.com [mailto:yhlu.kernel@gmail.com] On Behalf Of
>Yinghai Lu
>Sent: Monday, November 22, 2010 3:28 PM
>To: Kirsher, Jeffrey T
>Cc: Skidmore, Donald C; Brandeburg, Jesse; David Miller; NetDev
>Subject: Re: ixgbe dump
>
>On Mon, Nov 22, 2010 at 3:22 PM, Jeff Kirsher
><jeffrey.t.kirsher@intel.com> wrote:
>>
>> It is not posted yet. Don got the patch to our testers and they are
>> doing a quick validation on the patch before I post it to netdev.
>>
>> I can send you the patch, so that you can assist in letting us know if
>> it resolves the issue.
>
>sure. please send that to me.
>
>Thanks
^ permalink raw reply related
* [PATCH 1/3] decnet: Move to staging
From: Ben Hutchings @ 2010-11-23 3:51 UTC (permalink / raw)
To: David Miller, Greg Kroah-Hartman; +Cc: netdev, devel, Debian kernel maintainers
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.
The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the
only changes appear to be adjustments for net API changes and fixes
for bugs found by inspection.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/Kconfig | 2 ++
net/Kconfig | 2 --
net/decnet/Kconfig | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 5eafdf4..dd94cb2 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -175,5 +175,7 @@ source "drivers/staging/intel_sst/Kconfig"
source "drivers/staging/speakup/Kconfig"
+source "net/decnet/Kconfig"
+
endif # !STAGING_EXCLUDE_BUILD
endif # STAGING
diff --git a/net/Kconfig b/net/Kconfig
index 55fd82e..9e4fc29 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -186,7 +186,6 @@ config BRIDGE_NETFILTER
source "net/netfilter/Kconfig"
source "net/ipv4/netfilter/Kconfig"
source "net/ipv6/netfilter/Kconfig"
-source "net/decnet/netfilter/Kconfig"
source "net/bridge/netfilter/Kconfig"
endif
@@ -201,7 +200,6 @@ source "net/802/Kconfig"
source "net/bridge/Kconfig"
source "net/dsa/Kconfig"
source "net/8021q/Kconfig"
-source "net/decnet/Kconfig"
source "net/llc/Kconfig"
source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
diff --git a/net/decnet/Kconfig b/net/decnet/Kconfig
index 7914fd6..9d17166 100644
--- a/net/decnet/Kconfig
+++ b/net/decnet/Kconfig
@@ -41,3 +41,6 @@ config DECNET_ROUTER
See <file:Documentation/networking/decnet.txt> for more information.
+if NETFILTER
+source "net/decnet/netfilter/Kconfig"
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] econet: Move to staging
From: Ben Hutchings @ 2010-11-23 3:52 UTC (permalink / raw)
To: David Miller, Greg Kroah-Hartman; +Cc: netdev, devel, Debian kernel maintainers
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.
The econet protocol (PF_ECONET) is unmaintained. There appear to be
no published applications for it, and it has never progressed beyond
'experimental' status.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/staging/Kconfig | 2 ++
net/Kconfig | 1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index dd94cb2..a9dd984 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -177,5 +177,7 @@ source "drivers/staging/speakup/Kconfig"
source "net/decnet/Kconfig"
+source "net/econet/Kconfig"
+
endif # !STAGING_EXCLUDE_BUILD
endif # STAGING
diff --git a/net/Kconfig b/net/Kconfig
index 9e4fc29..059c9f1 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -205,7 +205,6 @@ source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
source "net/x25/Kconfig"
source "net/lapb/Kconfig"
-source "net/econet/Kconfig"
source "net/wanrouter/Kconfig"
source "net/phonet/Kconfig"
source "net/ieee802154/Kconfig"
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] x25: Move to staging
From: Ben Hutchings @ 2010-11-23 3:55 UTC (permalink / raw)
To: Andrew Hendry, David Miller, Greg Kroah-Hartman
Cc: netdev, devel, Debian kernel maintainers, linux-x25
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.
The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to
be no published applications for it, and it has never progressed
beyond 'experimental' status.
This protocol generally should not be enabled by distributions, since
the cost of a security flaw affecting all installed systems presumably
outweighs the benefit to the few (if any) legitimate users.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
I'm somewhat less sure about this one; maybe it's improving? But there
is little enough sign of any usefulness after 10 years.
There are several X25 dependencies that presumably should be moved too.
Ben.
drivers/staging/Kconfig | 2 ++
net/Kconfig | 1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index a9dd984..1347242 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -179,5 +179,7 @@ source "net/decnet/Kconfig"
source "net/econet/Kconfig"
+source "net/x25/Kconfig"
+
endif # !STAGING_EXCLUDE_BUILD
endif # STAGING
diff --git a/net/Kconfig b/net/Kconfig
index 059c9f1..1d396ba 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -203,7 +203,6 @@ source "net/8021q/Kconfig"
source "net/llc/Kconfig"
source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
-source "net/x25/Kconfig"
source "net/lapb/Kconfig"
source "net/wanrouter/Kconfig"
source "net/phonet/Kconfig"
--
1.7.2.3
^ permalink raw reply related
* Re: ixgbe dump
From: Yinghai Lu @ 2010-11-23 4:15 UTC (permalink / raw)
To: Skidmore, Donald C
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <29F4ED941D916B48B88B4D2A4F3D1B9C01CC08FBCF@orsmsx509.amr.corp.intel.com>
On Mon, Nov 22, 2010 at 7:31 PM, Skidmore, Donald C
<donald.c.skidmore@intel.com> wrote:
>
> Hi Yinghai,
>
> I was hoping we could have had this patch pushed upstream sooner, but we have quite a few in our internal queue right now.
>
> If this doesn't solve your issue please let me know.
>
> Thanks,
> -Don Skidmore <donald.c.skidmore@intel.com>
>
>
>
>
> After freeing the rings we were not zeroing out the ring count values.
> This patch now clears these counts correctly.
>
> Reported-by: Yinghai Lu <yinghai@kernel.org>
> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> ---
>
> drivers/net/ixgbe/ixgbe_main.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index fbad4d8..eee0b29 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -4771,6 +4771,9 @@ void ixgbe_clear_interrupt_scheme(struct ixgbe_adapter *adapter)
> adapter->rx_ring[i] = NULL;
> }
>
> + adapter->num_tx_queues = 0;
> + adapter->num_rx_queues = 0;
> +
> ixgbe_free_q_vectors(adapter);
> ixgbe_reset_interrupt_capability(adapter);
> }
OK, that fix the problem.
Thanks
Yinghai
^ permalink raw reply
* RE: ixgbe dump
From: Skidmore, Donald C @ 2010-11-23 4:18 UTC (permalink / raw)
To: Yinghai Lu; +Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, David Miller, NetDev
In-Reply-To: <AANLkTi=ceFYmLuqYhWxyoQ2A3Wev6Dw7V2U+sc-D8d9_@mail.gmail.com>
>-----Original Message-----
>From: yhlu.kernel@gmail.com [mailto:yhlu.kernel@gmail.com] On Behalf Of
>Yinghai Lu
>Sent: Monday, November 22, 2010 8:16 PM
>To: Skidmore, Donald C
>Cc: Kirsher, Jeffrey T; Brandeburg, Jesse; David Miller; NetDev
>Subject: Re: ixgbe dump
>
>On Mon, Nov 22, 2010 at 7:31 PM, Skidmore, Donald C
><donald.c.skidmore@intel.com> wrote:
>>
>> Hi Yinghai,
>>
>> I was hoping we could have had this patch pushed upstream sooner, but we
>have quite a few in our internal queue right now.
>>
>> If this doesn't solve your issue please let me know.
>>
>> Thanks,
>> -Don Skidmore <donald.c.skidmore@intel.com>
>>
>>
>>
>>
>> After freeing the rings we were not zeroing out the ring count values.
>> This patch now clears these counts correctly.
>>
>> Reported-by: Yinghai Lu <yinghai@kernel.org>
>> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
>> ---
>>
>> drivers/net/ixgbe/ixgbe_main.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/ixgbe/ixgbe_main.c
>b/drivers/net/ixgbe/ixgbe_main.c
>> index fbad4d8..eee0b29 100644
>> --- a/drivers/net/ixgbe/ixgbe_main.c
>> +++ b/drivers/net/ixgbe/ixgbe_main.c
>> @@ -4771,6 +4771,9 @@ void ixgbe_clear_interrupt_scheme(struct
>ixgbe_adapter *adapter)
>> adapter->rx_ring[i] = NULL;
>> }
>>
>> + adapter->num_tx_queues = 0;
>> + adapter->num_rx_queues = 0;
>> +
>> ixgbe_free_q_vectors(adapter);
>> ixgbe_reset_interrupt_capability(adapter);
>> }
>
>OK, that fix the problem.
>
>Thanks
>
>Yinghai
That great to hear. Hopefully we will be able to get the patch submitted soon.
Thanks,
-Don
^ permalink raw reply
* Re: [PATCH 1/3] decnet: Move to staging
From: Stephen Hemminger @ 2010-11-23 4:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers
In-Reply-To: <1290484313.6770.1328.camel@localhost>
On Tue, 23 Nov 2010 03:51:53 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:
> Recent review has revealed several bugs in obscure protocol
> implementations that can be exploited by local users for denial of
> service or privilege escalation.
>
> The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the
> only changes appear to be adjustments for net API changes and fixes
> for bugs found by inspection.
>
> This protocol generally should not be enabled by distributions, since
> the cost of a security flaw affecting all installed systems presumably
> outweighs the benefit to the few (if any) legitimate users.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
NAK there are still users and stuff does get fixed.
If you don't like it then disable it from config.
--
^ permalink raw reply
* Re: [PATCH 3/3] x25: Move to staging
From: Stephen Hemminger @ 2010-11-23 4:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: Andrew Hendry, David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers, linux-x25
In-Reply-To: <1290484528.6770.1336.camel@localhost>
On Tue, 23 Nov 2010 03:55:28 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:
> Recent review has revealed several bugs in obscure protocol
> implementations that can be exploited by local users for denial of
> service or privilege escalation.
>
> The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to
> be no published applications for it, and it has never progressed
> beyond 'experimental' status.
>
> This protocol generally should not be enabled by distributions, since
> the cost of a security flaw affecting all installed systems presumably
> outweighs the benefit to the few (if any) legitimate users.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> I'm somewhat less sure about this one; maybe it's improving? But there
> is little enough sign of any usefulness after 10 years.
>
> There are several X25 dependencies that presumably should be moved too.
No. If you don't like it then don't enable it.
^ permalink raw reply
* Re: [PATCH 2/3] econet: Move to staging
From: Stephen Hemminger @ 2010-11-23 4:32 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers
In-Reply-To: <1290484348.6770.1329.camel@localhost>
On Tue, 23 Nov 2010 03:52:28 +0000
Ben Hutchings <ben@decadent.org.uk> wrote:
> Recent review has revealed several bugs in obscure protocol
> implementations that can be exploited by local users for denial of
> service or privilege escalation.
>
> The econet protocol (PF_ECONET) is unmaintained. There appear to be
> no published applications for it, and it has never progressed beyond
> 'experimental' status.
>
> This protocol generally should not be enabled by distributions, since
> the cost of a security flaw affecting all installed systems presumably
> outweighs the benefit to the few (if any) legitimate users.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This I agree with. Probably the Arcnet devices as well.
Most distro's don't enable it anyway.
^ permalink raw reply
* Re: [PATCH 3/3] x25: Move to staging
From: Andrew Hendry @ 2010-11-23 5:05 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Hutchings, David Miller, Greg Kroah-Hartman, netdev, devel,
Debian kernel maintainers, linux-x25
In-Reply-To: <20101122203155.27534f3b@nehalam>
There are users of linux X.25 for production environments, please don't..
It works well enough, there have been some X.25 over TCP bits of code
floating around the Internet and mailing lists.
There is an x25 loopback device on sourceforge using tuntap which I
have been using to test slowly removing the bkls.
Regards,
Andrew.
On Tue, Nov 23, 2010 at 3:31 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Tue, 23 Nov 2010 03:55:28 +0000
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
>> Recent review has revealed several bugs in obscure protocol
>> implementations that can be exploited by local users for denial of
>> service or privilege escalation.
>>
>> The x25 protocol (PF_X25) receives only 'odd fixes'. There appear to
>> be no published applications for it, and it has never progressed
>> beyond 'experimental' status.
>>
>> This protocol generally should not be enabled by distributions, since
>> the cost of a security flaw affecting all installed systems presumably
>> outweighs the benefit to the few (if any) legitimate users.
>>
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>> ---
>> I'm somewhat less sure about this one; maybe it's improving? But there
>> is little enough sign of any usefulness after 10 years.
>>
>> There are several X25 dependencies that presumably should be moved too.
>
> No. If you don't like it then don't enable it.
>
^ permalink raw reply
* Re: [PATCH 1/3] decnet: Move to staging
From: David Miller @ 2010-11-23 5:19 UTC (permalink / raw)
To: shemminger; +Cc: ben, gregkh, netdev, devel, debian-kernel
In-Reply-To: <20101122203131.7cbd604b@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 22 Nov 2010 20:31:31 -0800
> On Tue, 23 Nov 2010 03:51:53 +0000
> Ben Hutchings <ben@decadent.org.uk> wrote:
>
>> Recent review has revealed several bugs in obscure protocol
>> implementations that can be exploited by local users for denial of
>> service or privilege escalation.
>>
>> The decnet protocol (PF_DECnet) is unmaintained. Since 2.6.12-rc2 the
>> only changes appear to be adjustments for net API changes and fixes
>> for bugs found by inspection.
>>
>> This protocol generally should not be enabled by distributions, since
>> the cost of a security flaw affecting all installed systems presumably
>> outweighs the benefit to the few (if any) legitimate users.
>>
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>
> NAK there are still users and stuff does get fixed.
> If you don't like it then disable it from config.
Seriously, I can't even remember a bonifides security flaw in decnet
being found recently and in fact the decnet stack is very well written
code.
^ permalink raw reply
* [PATCH net-next] sctp: kill unused macro definition
From: Shan Wei @ 2010-11-23 9:00 UTC (permalink / raw)
To: Vlad Yasevich, David Miller; +Cc: linux-sctp, Network-Maillist
These macros have been existed for several years since v2.6.12-rc2.
But they never be used. So remove them now.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
include/net/sctp/constants.h | 14 --------------
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index 6390884..c70d8cc 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -61,7 +61,6 @@ enum { SCTP_DEFAULT_INSTREAMS = SCTP_MAX_STREAM };
* symbols. CIDs are dense through SCTP_CID_BASE_MAX.
*/
#define SCTP_CID_BASE_MAX SCTP_CID_SHUTDOWN_COMPLETE
-#define SCTP_CID_MAX SCTP_CID_ASCONF_ACK
#define SCTP_NUM_BASE_CHUNK_TYPES (SCTP_CID_BASE_MAX + 1)
@@ -86,9 +85,6 @@ typedef enum {
} sctp_event_t;
-#define SCTP_EVENT_T_MAX SCTP_EVENT_T_PRIMITIVE
-#define SCTP_EVENT_T_NUM (SCTP_EVENT_T_MAX + 1)
-
/* As a convenience for the state machine, we append SCTP_EVENT_* and
* SCTP_ULP_* to the list of possible chunks.
*/
@@ -162,9 +158,6 @@ SCTP_SUBTYPE_CONSTRUCTOR(PRIMITIVE, sctp_event_primitive_t, primitive)
- (unsigned long)(c->chunk_hdr)\
- sizeof(sctp_data_chunk_t)))
-#define SCTP_MAX_ERROR_CAUSE SCTP_ERROR_NONEXIST_IP
-#define SCTP_NUM_ERROR_CAUSE 10
-
/* Internal error codes */
typedef enum {
@@ -266,7 +259,6 @@ enum { SCTP_ARBITRARY_COOKIE_ECHO_LEN = 200 };
#define SCTP_TSN_MAP_INITIAL BITS_PER_LONG
#define SCTP_TSN_MAP_INCREMENT SCTP_TSN_MAP_INITIAL
#define SCTP_TSN_MAP_SIZE 4096
-#define SCTP_TSN_MAX_GAP 65535
/* We will not record more than this many duplicate TSNs between two
* SACKs. The minimum PMTU is 576. Remove all the headers and there
@@ -301,9 +293,6 @@ enum { SCTP_MAX_GABS = 16 };
#define SCTP_CLOCK_GRANULARITY 1 /* 1 jiffy */
-#define SCTP_DEF_MAX_INIT 6
-#define SCTP_DEF_MAX_SEND 10
-
#define SCTP_DEFAULT_COOKIE_LIFE (60 * 1000) /* 60 seconds */
#define SCTP_DEFAULT_MINWINDOW 1500 /* default minimum rwnd size */
@@ -317,9 +306,6 @@ enum { SCTP_MAX_GABS = 16 };
*/
#define SCTP_DEFAULT_MINSEGMENT 512 /* MTU size ... if no mtu disc */
#define SCTP_HOW_MANY_SECRETS 2 /* How many secrets I keep */
-#define SCTP_HOW_LONG_COOKIE_LIVE 3600 /* How many seconds the current
- * secret will live?
- */
#define SCTP_SECRET_SIZE 32 /* Number of octets in a 256 bits. */
#define SCTP_SIGNATURE_SIZE 20 /* size of a SLA-1 signature */
--
1.6.3.3
^ permalink raw reply related
* Draft manpage for recvmmsg
From: Andi Kleen @ 2010-11-23 10:15 UTC (permalink / raw)
To: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
acme-H+wXaHxf7aLQT0dZR+AlfA
Here's a draft manpage for recvmmsg(2), which is one
of the last undocumented syscalls currently.
Please review and comment.
-Andi
.TH RECVMMSG 2 2010-11-23 "Linux" "Linux Programmer's Manual"
.SH NAME
recvmmsg \- receive multiple messages on a socket
.SH SYNOPSIS
.BI "#include <sys/socket.h>"
.br
.BI "int recvmmsg(int " fd ", struct mmsghdr *" mmsghdr \
", unsigned int " vlen ","
.br
.BI " unsigned int " flags ", struct timespec *" timeout ");"
.SH DESCRIPTION
The
.B recvmmsg
system call receives multiple messages in a socket.
It acts similar to
.B recvmsg(2),
but allows to batch multiple receive operations into a single syscall.
In addition it support an explicit timeout.
.B fd
is the file descriptor of the socket to receive data from.
.B mmsghdr
is a pointer to an array with length
.B vlen
of
.I mmsghdr
structures.
.I struct mmsg
is defined in
.I sys/socket.h
as:
.in +4n
.nf
struct mmsghdr {
struct msghdr msg_hdr; /* Message header */
unsigned int msg_len; /* Number of received bytes for header */
};
.fi
.in
.PP
.B msg_hdr
is a struct
.I msghdr
as described in
.I recvmsg(2).
.B msg_len
is the number of bytes returned for the message in the entry.
This field has the same value as the return value of a single
.I recvmsg(2)
on the header.
.B flags
contains flags ored together. The flags are the same
as documented for
.I recvmsg(2).
The additional
.B MSG_WAITFORONE
turns one
.I MSG_DONTWAIT
after the first message has been received.
.B timeout
points to a
.I struct timespec
(see
.I clock_gettime(2)
)
defining a timeout for receiving, or
.I NULL
for no timeout. When the timeout expires
.I recvmmsg
returns.
.SH RETURN VALUE
.I recvmmsg
returns the number of messages received in
.I mmsghdr
or
-1
when an error occurs. The
.I msg_len
members of
.I mmsghdr
are updated for each received message,
in addition to other fields in the msg_hdr for each message,
as described in
.I recvmsg(2).
.SH SEE ALSO
.B recvmsg(2),
.B sendmsg(2),
.B socket(7),
.B socket(2),
.B clock_gettime(2)
.SH VERSIONS
The
.I recvmmsg
syscall was added with kernel 2.6.32.
Support in glibc was added with 2.6.12.
On earlier glibcs the function can be called
manually using
.I syscall(2).
--
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH NEXT] qlcnic: avoid using reset_devices as it may become obsolete.
From: Amit Kumar Salecha @ 2010-11-23 11:25 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Rajesh Borundia
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
In kdump environment do not depend upon reset_devices parameter
to reset the pci function as this parameter may become obsolete.
Instead use an adapter specific mechanism to determine if the pci
function needs to be reset.
Per function refcount is maintained in driver, which is set in probe
and reset in remove handler of adapter. If the probe detects the count
as non zero then reset the function.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic.h | 1 +
drivers/net/qlcnic/qlcnic_ctx.c | 4 +++-
drivers/net/qlcnic/qlcnic_hdr.h | 2 +-
drivers/net/qlcnic/qlcnic_main.c | 5 +++++
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic.h b/drivers/net/qlcnic/qlcnic.h
index 56f54ff..9513a83 100644
--- a/drivers/net/qlcnic/qlcnic.h
+++ b/drivers/net/qlcnic/qlcnic.h
@@ -923,6 +923,7 @@ struct qlcnic_ipaddr {
#define QLCNIC_MACSPOOF 0x200
#define QLCNIC_MAC_OVERRIDE_DISABLED 0x400
#define QLCNIC_PROMISC_DISABLED 0x800
+#define QLCNIC_NEED_FLR 0x1000
#define QLCNIC_IS_MSI_FAMILY(adapter) \
((adapter)->flags & (QLCNIC_MSI_ENABLED | QLCNIC_MSIX_ENABLED))
diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
index 3ad1f3e..29cbc2a 100644
--- a/drivers/net/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/qlcnic/qlcnic_ctx.c
@@ -480,8 +480,10 @@ int qlcnic_fw_create_ctx(struct qlcnic_adapter *adapter)
{
int err;
- if (reset_devices)
+ if (adapter->flags & QLCNIC_NEED_FLR) {
pci_reset_function(adapter->pdev);
+ adapter->flags &= ~QLCNIC_NEED_FLR;
+ }
err = qlcnic_fw_cmd_create_rx_ctx(adapter);
if (err)
diff --git a/drivers/net/qlcnic/qlcnic_hdr.h b/drivers/net/qlcnic/qlcnic_hdr.h
index 4290b80..566e0e8 100644
--- a/drivers/net/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/qlcnic/qlcnic_hdr.h
@@ -722,7 +722,7 @@ enum {
#define QLCNIC_DEV_NPAR_OPER 1 /* NPAR Operational */
#define QLCNIC_DEV_NPAR_OPER_TIMEO 30 /* Operational time out */
-#define QLC_DEV_CHECK_ACTIVE(VAL, FN) ((VAL) &= (1 << (FN * 4)))
+#define QLC_DEV_CHECK_ACTIVE(VAL, FN) ((VAL) & (1 << (FN * 4)))
#define QLC_DEV_SET_REF_CNT(VAL, FN) ((VAL) |= (1 << (FN * 4)))
#define QLC_DEV_CLR_REF_CNT(VAL, FN) ((VAL) &= ~(1 << (FN * 4)))
#define QLC_DEV_SET_RST_RDY(VAL, FN) ((VAL) |= (1 << (FN * 4)))
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index a3dcd04..899df5a 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -1485,6 +1485,7 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
uint8_t revision_id;
uint8_t pci_using_dac;
char brd_name[QLCNIC_MAX_BOARD_NAME_LEN];
+ u32 val;
err = pci_enable_device(pdev);
if (err)
@@ -1546,6 +1547,10 @@ qlcnic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (err)
goto err_out_iounmap;
+ val = QLCRD32(adapter, QLCNIC_CRB_DRV_ACTIVE);
+ if (QLC_DEV_CHECK_ACTIVE(val, adapter->portnum))
+ adapter->flags |= QLCNIC_NEED_FLR;
+
err = adapter->nic_ops->start_firmware(adapter);
if (err) {
dev_err(&pdev->dev, "Loading fw failed.Please Reboot\n");
--
1.7.3.2
^ permalink raw reply related
* Re: Draft manpage for recvmmsg
From: Arnaldo Carvalho de Melo @ 2010-11-23 12:36 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101123101551.GA20431-u0/ZJuX+froe6aEkudXLsA@public.gmane.org>
Em Tue, Nov 23, 2010 at 11:15:51AM +0100, Andi Kleen escreveu:
>
> Here's a draft manpage for recvmmsg(2), which is one
> of the last undocumented syscalls currently.
> Please review and comment.
Looks ok, thanks for writing it.
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* net-2.6 [Patch 1/1][BUG-FIX] dccp: advancing the Ack window
From: Gerrit Renker @ 2010-11-23 12:36 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
Dave,
please can you consider the following bug fix (applies on both net-2.6 and
net-next-2.6). I have no other dccp patches this week -- the second one that
follows is for the test tree only and is meant for RFC.
Best regards
Gerrit
(also on git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp'])
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Patch / Fix <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp: fix error in updating the GAR
This fixes a bug in updating the Greatest Acknowledgment number Received (GAR):
the current implementation does not track the greatest received value -
lower values in the range AWL..AWH (RFC 4340, 7.5.1) erase higher ones.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -241,7 +241,8 @@ static int dccp_check_seqno(struct sock
dccp_update_gsr(sk, seqno);
if (dh->dccph_type != DCCP_PKT_SYNC &&
- (ackno != DCCP_PKT_WITHOUT_ACK_SEQ))
+ ackno != DCCP_PKT_WITHOUT_ACK_SEQ &&
+ after48(ackno, dp->dccps_gar))
dp->dccps_gar = ackno;
} else {
unsigned long now = jiffies;
^ permalink raw reply
* dccp-test-tree [RFC][Patch 1/1] dccp: requesting comments re updating ARP/neighbour table state
From: Gerrit Renker @ 2010-11-23 12:44 UTC (permalink / raw)
To: dccp, netdev
In-Reply-To: <20101123123656.GB3915@gerrit.erg.abdn.ac.uk>
I noted that DCCP apparently does not update the neighbour tables in the same
way as TCP (or UDP with MSG_CONFIRM).
This patch adds the missing calls to dst_update(). I would appreciate review
and comments in case I missed something.
DCCP does not have the equivalent of tcp_init_metrics()/tcp_update_metrics().
It seems that this functionality would be more in the CCIDs than in the main
DCCP module (for instance, CCID-3 does not understand ssthresh/cwnd and uses
a different RTT sampling algorithm).
This patch is meant for RFC, not currently for submission. It is in the DCCP
test tree, on
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree 'dccp']
>>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
dccp: indicate forward progress of connection to lower layer
This patch implements three cases of indicating forward progress:
1. Peer acknowledging receipt of connection initiation.
This corresponds to the cases where tcp_init_metrics() is called:
* receiving Syn-Ack in response to Syn (tcp_rcv_synsent_state_process),
* receiving Ack to finish the handshake (TCP_SYN_RECV -> TCP_ESTABLISHED);
which in DCCP corresponds to
* receiving Response after Request (dccp_rcv_request_sent_state_process),
* moving from RESPOND/PARTOPEN to OPEN when receiving an Ack/DataAck
(RESPOND) or non-Sync/Reset (PARTOPEN).
The latter does no extra rebuild_header() as in tcp_rcv_state_process(),
since in DCCP an active (client) socket can not become a passive one later,
and since dccp_v{4,6}_request_recv_sock() already talk to the routing
system.
2. Peer advancing GAR (greatest acknowledgment number received).
This is comparable to making forward progress in tcp_ack().
3. Peer acknowledging request to terminate the connection.
This corresponds to TCP teardown -
* receiving Ack-of-Fin in FIN_WAIT1/LAST_ACK (tcp_rcv_state_process),
* entering TIME_WAIT (tcp_time_wait),
and is realized in DCCP when receiving
* a Reset packet with code "Closed" (in response to DCCP-Close),
* a Close packet after sending a CloseReq,
* a Close packet after sending a Close (simultaneous close).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -71,6 +71,7 @@ static int dccp_rcv_close(struct sock *s
/* fall through */
case DCCP_REQUESTING:
case DCCP_ACTIVE_CLOSEREQ:
+ dst_confirm(__sk_dst_get(sk));
dccp_send_reset(sk, DCCP_RESET_CODE_CLOSED);
dccp_done(sk);
break;
@@ -155,6 +156,8 @@ static void dccp_rcv_reset(struct sock *
/* Queue the equivalent of TCP fin so that dccp_recvmsg exits the loop */
dccp_fin(sk, skb);
+ if (dccp_hdr_reset(skb)->dccph_reset_code == DCCP_RESET_CODE_CLOSED)
+ dst_confirm(__sk_dst_get(sk));
if (err && !sock_flag(sk, SOCK_DEAD))
sk_wake_async(sk, SOCK_WAKE_IO, POLL_ERR);
dccp_time_wait(sk, DCCP_TIME_WAIT, 0);
@@ -242,8 +245,10 @@ static int dccp_check_seqno(struct sock
if (dh->dccph_type != DCCP_PKT_SYNC &&
ackno != DCCP_PKT_WITHOUT_ACK_SEQ &&
- after48(ackno, dp->dccps_gar))
+ after48(ackno, dp->dccps_gar)) {
+ dst_confirm(__sk_dst_get(sk));
dp->dccps_gar = ackno;
+ }
} else {
unsigned long now = jiffies;
/*
@@ -475,6 +480,8 @@ static int dccp_rcv_request_sent_state_p
/* Make sure socket is routed, for correct metrics. */
icsk->icsk_af_ops->rebuild_header(sk);
+ dst_confirm(__sk_dst_get(sk));
+
if (!sock_flag(sk, SOCK_DEAD)) {
sk->sk_state_change(sk);
sk_wake_async(sk, SOCK_WAKE_IO, POLL_OUT);
@@ -556,6 +563,8 @@ static int dccp_rcv_respond_partopen_sta
dp->dccps_syn_rtt = dccp_sample_rtt(sk, 10 * delta);
}
+ dst_confirm(__sk_dst_get(sk));
+
dp->dccps_osr = DCCP_SKB_CB(skb)->dccpd_seq;
dccp_set_state(sk, DCCP_OPEN);
^ permalink raw reply
* Patch for man unix(7)
From: Tetsuo Handa @ 2010-11-23 12:59 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201010262115.FEH09326.OMFJHSVOFLQFOt-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
From f388eedbdc0b099bb9f36ab007f9370432abb300 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
Date: Tue, 23 Nov 2010 21:34:25 +0900
Subject: [PATCH] unix.7: Fix description of "pathname" sockets
Since unix_mkname() in net/unix/af_unix.c does
((char *)sunaddr)[len] = 0;
rather than
((char *)sunaddr)[len - 1] = 0;
, sunaddr->sun_path may not be terminated with a null byte if
len == sizeof(*sunaddr).
Therefore, the caller of getsockname(), getpeername(), accept() must not assume
that sunaddr->sun_path contains a null-terminated pathname even if the returned
addrlen is greater than sizeof(sa_family_t) and sun_path[0] != '\0'.
Signed-off-by: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
---
man7/unix.7 | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/man7/unix.7 b/man7/unix.7
index b53328b..7b0b47c 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -80,10 +80,23 @@ When the address of the socket is returned by
and
.BR accept (2),
its length is
-.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1" ,
+.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1".
+Note that this length can be one byte larger than
+.IR "sizeof(struct sockaddr_un)"
+because
+.BR bind (2)
+accepts
+.IR sun_path
+which is not terminated with a null byte ('\\0').
+Therefore, you must not use string manipulation functions (e.g. strlen(),
+printf("%s")) against
+.IR sun_path
+because
+.BR getsockname (2),
+.BR getpeername (2),
and
-.I sun_path
-contains the null-terminated pathname.
+.BR accept (2)
+may not have stored a null-terminated string.
.IP *
.IR unnamed :
A stream socket that has not been bound to a pathname using
--
1.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] netxen: avoid using reset_devices as it may become obsolete
From: Amit Kumar Salecha @ 2010-11-23 13:08 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Rajesh Borundia
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
In kdump environment do not depend on reset_devices
parameter to reset the device as the parameter may become obsolete.
Instead use an adapter specific mechanism to determine if the device
needs a reset.
Driver maintains a count of number of pci functions probed
and decrements the count when remove handler of that pci function
is called. If the first probe, probe of function 0,
detects the count as non zero then reset the device.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_main.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index e1d30d7..ceeaac9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1277,6 +1277,7 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
int i = 0, err;
int pci_func_id = PCI_FUNC(pdev->devfn);
uint8_t revision_id;
+ u32 val;
if (pdev->revision >= NX_P3_A0 && pdev->revision <= NX_P3_B1) {
pr_warning("%s: chip revisions between 0x%x-0x%x "
@@ -1352,8 +1353,9 @@ netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
break;
}
- if (reset_devices) {
- if (adapter->portnum == 0) {
+ if (adapter->portnum == 0) {
+ val = NXRD32(adapter, NX_CRB_DEV_REF_COUNT);
+ if (val != 0xffffffff && val != 0) {
NXWR32(adapter, NX_CRB_DEV_REF_COUNT, 0);
adapter->need_fw_reset = 1;
}
--
1.7.3.2
^ permalink raw reply related
* ucc_geth: transmit queue timeout at half-duplex mode
From: Schmitz, Andreas @ 2010-11-23 13:29 UTC (permalink / raw)
To: leoli@freescale.com; +Cc: netdev@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
[-- Attachment #1.1: Type: text/plain, Size: 1227 bytes --]
Hi all,
on my MPC8321E with linux-2.6.36 I get this netdev watchdog warning "NETDEV WATCHDOG: eth0 (of:ucc_geth): transmit queue 0 timed out" if the link mode is half-duplex.
The warning is caused, because all Tx BDs are full and packet transmission is stopped with netif_stop_queue() in ucc_geth_start_xmit().
You can reproduce the bug in the following way:
- Connect to a switch, that supports only 10baseT, or set the mode manually with "mii-diag -F 10baseT".
- Open a telnet session to the target. Generate higher traffic with executing maybe "cat /proc/interrupts" many times.
- After some tries the ethernet connection will be down, then again after approx. 30s seconds the netdev watchdog will dump the warning.
It is unclear to me why the TxBDs get full. Due to missing "Tx buffer sent" interrupts, it seems that the QE stops the transmission.
I found some issue in the errata: "QE_ENET20: UEC may stop transmitting after late collision". But UCCE[TXE] is never set in this case.
Thank you for your help in advance and best regards,
Andreas Schmitz
Software Engineer
_______________________________________
RIEDEL
Communications GmbH & Co. KG
Uellendahler Str. 353
42109 Wuppertal
Germany
[-- Attachment #1.2: Type: text/html, Size: 2213 bytes --]
[-- Attachment #2: ucc_geth_half_duplex_netdev_watchdog.txt --]
[-- Type: text/plain, Size: 13531 bytes --]
PHY: mdio@e0102320:01 - Link is Up - 10/Half
NETDEV WATCHDOG: eth0 (of:ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:258
Modules linked in: gpio
NIP: c01887c0 LR: c01887c0 CTR: c012b8d4
REGS: c3ffbe30 TRAP: 0700 Not tainted (2.6.36)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 44022084 XER: 20000000
TASK = c07f6410[0] 'swapper' THREAD: c080e000
GPR00: c01887c0 c3ffbee0 c07f6410 00000046 00001848 ffffffff c012c2b0 2074696d
GPR08: 00001808 c3ffa000 c0817eb8 00000004 00000000 1007d144 03fff000 c07f94e4
GPR16: 00200200 c020dcd4 00000000 00000001 c0837fc0 c08381ec c083826c c08382ec
GPR24: c083836c 00000002 ffffffff 00000000 c3ffa03c c2607fa0 00000000 c2583000
NIP [c01887c0] dev_watchdog+0x198/0x28c
LR [c01887c0] dev_watchdog+0x198/0x28c
Call Trace:
[c3ffbee0] [c01887c0] dev_watchdog+0x198/0x28c (unreliable)
[c3ffbf50] [c003c9b0] run_timer_softirq+0x1b0/0x250
[c3ffbfb0] [c0036d18] __do_softirq+0xa8/0x124
[c3ffbff0] [c000e5dc] call_do_softirq+0x14/0x24
[c080fe70] [c0005e38] do_softirq+0x6c/0x8c
[c080fe90] [c00367b4] irq_exit+0x3c/0x54
[c080fea0] [c0005fec] do_IRQ+0x128/0x144
[c080fec0] [c000f2ac] ret_from_except+0x0/0x14
--- Exception: 501 at cpu_idle+0x94/0xe4
LR = cpu_idle+0x94/0xe4
[c080ff80] [c00090c4] cpu_idle+0xe0/0xe4 (unreliable)
[c080ffa0] [c0003e50] rest_init+0xa8/0xd8
[c080ffc0] [c023e80c] start_kernel+0x2b8/0x2cc
[c080fff0] [00003438] 0x3438
Instruction dump:
2f800000 40be003c 38810008 7fe3fb78 38a00040 4bfeb799 7fc6f378 7fe4fb78
7c651b78 3c60c022 386316b0 4804f631 <0fe00000> 38000001 3d20c085 9809aa6c
---[ end trace 0cbe1c7362251e03 ]---
UCC2 Fast registers:
Base address: 0xc91c6200
gumr : addr=0xc91c6200, val=0x0000003c
upsmr : addr=0xc91c6204, val=0x02002000
utodr : addr=0xc91c6208, val=0x0000
udsr : addr=0xc91c620c, val=0x7e7e
ucce : addr=0xc91c6210, val=0x00000000
uccm : addr=0xc91c6214, val=0x5fff00ff
uccs : addr=0xc91c6218, val=0x00
urfb : addr=0xc91c6220, val=0x00001780
urfs : addr=0xc91c6224, val=0x0200
urfet : addr=0xc91c6228, val=0x0100
urfset: addr=0xc91c622a, val=0x0180
utfb : addr=0xc91c622c, val=0x00001580
utfs : addr=0xc91c6230, val=0x0200
utfet : addr=0xc91c6234, val=0x0100
utftt : addr=0xc91c6238, val=0x0200
utpt : addr=0xc91c623c, val=0x0100
urtry : addr=0xc91c6240, val=0x00000000
guemr : addr=0xc91c6290, val=0x13
UCC3 Geth registers:
Base address: 0xc91ca200
maccfg1 : addr - 0xc91ca300, val - 0x0000003f
maccfg2 : addr - 0xc91ca304, val - 0x00007124
ipgifg : addr - 0xc91ca308, val - 0x40605060
hafdup : addr - 0xc91ca30c, val - 0x00a1f037
ifctl : addr - 0xc91ca338, val - 0x01000000
ifstat : addr - 0xc91ca33c, val - 0x00000008
macstnaddr1: addr - 0xc91ca340, val - 0x4708007c
macstnaddr2: addr - 0xc91ca344, val - 0x19000000
uempr : addr - 0xc91ca350, val - 0x00000000
utbipar : addr - 0xc91ca354, val - 0x00000020
uescr : addr - 0xc91ca358, val - 0x0804
tx64 : addr - 0xc91ca380, val - 0x00000005
tx127 : addr - 0xc91ca384, val - 0x00000046
tx255 : addr - 0xc91ca388, val - 0x00000121
rx64 : addr - 0xc91ca38c, val - 0x00000002
rx127 : addr - 0xc91ca390, val - 0x00000078
rx255 : addr - 0xc91ca394, val - 0x00000139
txok : addr - 0xc91ca398, val - 0x0001294f
txcf : addr - 0xc91ca39c, val - 0x0000
tmca : addr - 0xc91ca3a0, val - 0x00000000
tbca : addr - 0xc91ca3a4, val - 0x00000002
rxfok : addr - 0xc91ca3a8, val - 0x000001a8
rxbok : addr - 0xc91ca3ac, val - 0x0001563d
rbyt : addr - 0xc91ca3b0, val - 0x0001843b
rmca : addr - 0xc91ca3b4, val - 0x00000000
rbca : addr - 0xc91ca3b8, val - 0x00000004
scar : addr - 0xc91ca3bc, val - 0x00000000
scam : addr - 0xc91ca3c0, val - 0xfffe0000
Thread data TXs:
Base address: 0xfdefbb00
Thread data TX[0]:
Base address: 0xfdefbb00
0xfdefbb00: 18000000 188000ca 18000000 18800044
0xfdefbb10: 18000000 1880005e 0260e130 18800044
0xfdefbb20: 02000318 202490c5 00181204 0c00800e
0xfdefbb30: 69fdf7fe b6a7fa9f eddffeaf bb7fff77
0xfdefbb40: 800016e0 b2000080 0260e138 02179876
0xfdefbb50: 80001580 b0000080 0260e138 021798f6
0xfdefbb60: 80001608 b0000080
Thread data RX:
Base address: 0xfdefbd00
Thread data RX[0]:
Base address: 0xfdefbd00
0xfdefbd00: 00000000 08c01055 00000000 02003000
0xfdefbd10: 00000000 08c01055 00000000 02003000
0xfdefbd20: 00001f00 00000005
TX global param:
Base address: 0xfdefba00
temoder : addr - 0xfdefba00, val - 0x0110
sqptr : addr - 0xfdefba38, val - 0x000019a0
schedulerbasepointer: addr - 0xfdefba3c, val - 0x00000000
txrmonbaseptr: addr - 0xfdefba40, val - 0x00001a80
tstate : addr - 0xfdefba44, val - 0x30000000
iphoffset[0] : addr - 0xfdefba48, val - 0x00
iphoffset[1] : addr - 0xfdefba49, val - 0x00
iphoffset[2] : addr - 0xfdefba4a, val - 0x00
iphoffset[3] : addr - 0xfdefba4b, val - 0x00
iphoffset[4] : addr - 0xfdefba4c, val - 0x00
iphoffset[5] : addr - 0xfdefba4d, val - 0x00
iphoffset[6] : addr - 0xfdefba4e, val - 0x00
iphoffset[7] : addr - 0xfdefba4f, val - 0x00
vtagtable[0] : addr - 0xfdefba50, val - 0x00000000
vtagtable[1] : addr - 0xfdefba54, val - 0x00000000
vtagtable[2] : addr - 0xfdefba58, val - 0x00000000
vtagtable[3] : addr - 0xfdefba5c, val - 0x00000000
vtagtable[4] : addr - 0xfdefba60, val - 0x00000000
vtagtable[5] : addr - 0xfdefba64, val - 0x00000000
vtagtable[6] : addr - 0xfdefba68, val - 0x00000000
vtagtable[7] : addr - 0xfdefba6c, val - 0x00000000
tqptr : addr - 0xfdefba70, val - 0x00001b00
RX global param:
Base address: 0xfdefbc00
remoder : addr - 0xfdefbc00, val - 0x00001000
rqptr : addr - 0xfdefbc04, val - 0x00001d00
typeorlen : addr - 0xfdefbc20, val - 0x0c00
rxgstpack : addr - 0xfdefbc23, val - 0x00
rxrmonbaseptr : addr - 0xfdefbc24, val - 0x00001e00
intcoalescingptr: addr - 0xfdefbc30, val - 0x00001ac0
rstate : addr - 0xfdefbc36, val - 0x30
mrblr : addr - 0xfdefbc46, val - 0x0600
rbdqptr : addr - 0xfdefbc48, val - 0x00001e60
mflr : addr - 0xfdefbc4c, val - 0x05ee
minflr : addr - 0xfdefbc4e, val - 0x0040
maxd1 : addr - 0xfdefbc50, val - 0x05f0
maxd2 : addr - 0xfdefbc52, val - 0x05f0
ecamptr : addr - 0xfdefbc54, val - 0x00000000
l2qt : addr - 0xfdefbc58, val - 0x00000000
l3qt[0] : addr - 0xfdefbc5c, val - 0x00000000
l3qt[1] : addr - 0xfdefbc60, val - 0x00000000
l3qt[2] : addr - 0xfdefbc64, val - 0x00000000
l3qt[3] : addr - 0xfdefbc68, val - 0x00000000
l3qt[4] : addr - 0xfdefbc6c, val - 0x00000000
l3qt[5] : addr - 0xfdefbc70, val - 0x00000000
l3qt[6] : addr - 0xfdefbc74, val - 0x00000000
l3qt[7] : addr - 0xfdefbc78, val - 0x00000000
vlantype : addr - 0xfdefbc7c, val - 0x8100
vlantci : addr - 0xfdefbc7e, val - 0x0000
addressfiltering[0]: addr - 0xfdefbc80, val - 0x00
addressfiltering[1]: addr - 0xfdefbc81, val - 0x00
addressfiltering[2]: addr - 0xfdefbc82, val - 0x00
addressfiltering[3]: addr - 0xfdefbc83, val - 0x00
addressfiltering[4]: addr - 0xfdefbc84, val - 0x00
addressfiltering[5]: addr - 0xfdefbc85, val - 0x00
addressfiltering[6]: addr - 0xfdefbc86, val - 0x00
addressfiltering[7]: addr - 0xfdefbc87, val - 0x00
addressfiltering[8]: addr - 0xfdefbc88, val - 0x00
addressfiltering[9]: addr - 0xfdefbc89, val - 0x00
addressfiltering[10]: addr - 0xfdefbc8a, val - 0x00
addressfiltering[11]: addr - 0xfdefbc8b, val - 0x01
addressfiltering[12]: addr - 0xfdefbc8c, val - 0x00
addressfiltering[13]: addr - 0xfdefbc8d, val - 0x00
addressfiltering[14]: addr - 0xfdefbc8e, val - 0x00
addressfiltering[15]: addr - 0xfdefbc8f, val - 0x00
addressfiltering[16]: addr - 0xfdefbc90, val - 0x00
addressfiltering[17]: addr - 0xfdefbc91, val - 0x00
addressfiltering[18]: addr - 0xfdefbc92, val - 0x01
addressfiltering[19]: addr - 0xfdefbc93, val - 0x00
addressfiltering[20]: addr - 0xfdefbc94, val - 0x00
addressfiltering[21]: addr - 0xfdefbc95, val - 0x5e
addressfiltering[22]: addr - 0xfdefbc96, val - 0x00
addressfiltering[23]: addr - 0xfdefbc97, val - 0x01
addressfiltering[24]: addr - 0xfdefbc98, val - 0x00
addressfiltering[25]: addr - 0xfdefbc99, val - 0x00
addressfiltering[26]: addr - 0xfdefbc9a, val - 0xff
addressfiltering[27]: addr - 0xfdefbc9b, val - 0xff
addressfiltering[28]: addr - 0xfdefbc9c, val - 0xff
addressfiltering[29]: addr - 0xfdefbc9d, val - 0xff
addressfiltering[30]: addr - 0xfdefbc9e, val - 0xff
addressfiltering[31]: addr - 0xfdefbc9f, val - 0xff
addressfiltering[32]: addr - 0xfdefbca0, val - 0x00
addressfiltering[33]: addr - 0xfdefbca1, val - 0x00
addressfiltering[34]: addr - 0xfdefbca2, val - 0xff
addressfiltering[35]: addr - 0xfdefbca3, val - 0xff
addressfiltering[36]: addr - 0xfdefbca4, val - 0xff
addressfiltering[37]: addr - 0xfdefbca5, val - 0xff
addressfiltering[38]: addr - 0xfdefbca6, val - 0xff
addressfiltering[39]: addr - 0xfdefbca7, val - 0xff
addressfiltering[40]: addr - 0xfdefbca8, val - 0x00
addressfiltering[41]: addr - 0xfdefbca9, val - 0x00
addressfiltering[42]: addr - 0xfdefbcaa, val - 0xff
addressfiltering[43]: addr - 0xfdefbcab, val - 0xff
addressfiltering[44]: addr - 0xfdefbcac, val - 0xff
addressfiltering[45]: addr - 0xfdefbcad, val - 0xff
addressfiltering[46]: addr - 0xfdefbcae, val - 0xff
addressfiltering[47]: addr - 0xfdefbcaf, val - 0xff
addressfiltering[48]: addr - 0xfdefbcb0, val - 0x00
addressfiltering[49]: addr - 0xfdefbcb1, val - 0x00
addressfiltering[50]: addr - 0xfdefbcb2, val - 0xff
addressfiltering[51]: addr - 0xfdefbcb3, val - 0xff
addressfiltering[52]: addr - 0xfdefbcb4, val - 0xff
addressfiltering[53]: addr - 0xfdefbcb5, val - 0xff
addressfiltering[54]: addr - 0xfdefbcb6, val - 0xff
addressfiltering[55]: addr - 0xfdefbcb7, val - 0xff
addressfiltering[56]: addr - 0xfdefbcb8, val - 0x81
addressfiltering[57]: addr - 0xfdefbcb9, val - 0x00
addressfiltering[58]: addr - 0xfdefbcba, val - 0x00
addressfiltering[59]: addr - 0xfdefbcbb, val - 0x00
addressfiltering[60]: addr - 0xfdefbcbc, val - 0x00
addressfiltering[61]: addr - 0xfdefbcbd, val - 0x00
addressfiltering[62]: addr - 0xfdefbcbe, val - 0x00
addressfiltering[63]: addr - 0xfdefbcbf, val - 0x00
exfGlobalParam : addr - 0xfdefbcc0, val - 0x00000000
Send Q memory registers:
Base address: 0xfdefb9a0
SQQD[0]:
Base address: 0xfdefb9a0
0xfdefb9a0: 0260e0c0 000019c0 0260e0c0 0260e128
0xfdefb9b0: b73b3fff 0260e128 0260e0c0 0260e138
0xfdefb9c0: 180000cb 02158076 18000213 02175876
0xfdefb9d0: 18000044 02158076 1800005e 02203876
TX FW statistics pram:
Base address: 0xfdefba80
0xfdefba80: 00000000 00000000 00000000 00000000
0xfdefba90: 00000000 00000033 0000015b 00000000
0xfdefbaa0: 00000015 0000000c 00000002 00000000
RX FW statistics pram:
Base address: 0xfdefbe00
0xfdefbe00: 00000032 00000000 00000000 00000000
0xfdefbe10: 00000000 00000001 00000000 00000000
0xfdefbe20: 00000000 00000000 00000000 00000000
0xfdefbe30: 00000000 0000000c 00000013 00000007
0xfdefbe40: 00000000 00000000 00000000 00000000
0xfdefbe50: 00000000 00000000 00000000
RX IRQ coalescing tables:
Base address: 0xfdefbac0
RX IRQ coalescing table entry[0]:
Base address: 0xfdefbac0
interruptcoalescingmaxvalue: addr - 0xfdefbac0, val - 0x00000001
interruptcoalescingcounter : addr - 0xfdefbac4, val - 0x00000001
RX BD QS tables:
Base address: 0xfdefbe60
RX BD QS table[0]:
Base address: 0xfdefbe60
bdbaseptr : addr - 0xfdefbe60, val - 0x00001e70
bdptr : addr - 0xfdefbe64, val - 0x00001e70
externalbdbaseptr: addr - 0xfdefbe68, val - 0x0260e180
externalbdptr : addr - 0xfdefbe6c, val - 0x0260e1c0
ucode RX Prefetched BDs:
Base address: 0xfdefbe70
0xfdefbe70: 90000000 0215b040 90000000 02157040
0xfdefbe80: 90000000 0220d040 90000000 02179040
Init enet param shadow:
Base address: 0xc209ccc0
0xc209ccc0: 0630ff00 04000000 11001c03 04000003
0xc209ccd0: 05001f03 00000000 00000000 00000000
0xc209cce0: 00000000 00000000 00000000 00000000
0xc209ccf0: 00000000 00000000 00001a03 0c001ec3
0xc209cd00: 00000000 00000000 00000000 00000000
0xc209cd10: 00000000 00000000 00000000 00
Init enet entry 0:
Base address: 0xfdefbec0
0xfdefbec0: 40001a00 86001b70 80000000 0000000c
0xfdefbed0: a4e3ff7f e27eff3f df196bd9 33fffc2f
0xfdefbee0: 10904802 00000020 06001b60 06001b60
0xfdefbef0: 67bdf7ed 1aebfcba 35fbeddb ff799df6
Init enet entry 1:
Base address: 0xfdefbf00
0xfdefbf00: 00001c00 00000000 80201000 30000001
0xfdefbf10: 8ebffdbf df001ec0 020031fe 08c01055
0xfdefbf20: 1cc00056 0215b840 05f00000 00001e60
0xfdefbf30: 021588c0 00bf2d7e 00000000 ebc77fc7
0xfdefbf40: 00060402 00016482 ca1c80c6 9810e8c3
0xfdefbf50: a7e195b7 0260e1b8 00000005 00000005
0xfdefbf60: 00001000 81000000 8f040182 30069982
0xfdefbf70: affc77bf f1e3eeff 00000580 00000056
TX BDs[0]
0xc260e0c0: 980001b4 02083876 980001b4 0215a076
0xc260e0d0: 980001b4 02159076 98000042 0216a25e
0xc260e0e0: 9800004e 02079452 9800004e 0216aa52
0xc260e0f0: 980001b4 02158076 9800004e 0216ac52
0xc260e100: 9800004e 0216a052 980001b4 0260c076
0xc260e110: 9800004e 02625e52 980001b4 02161876
0xc260e120: 9800004e 02625052 980001b4 02161076
0xc260e130: 98000044 02175876 b80001b4 02179876
RX BDs[0]
0xc260e180: 90000000 02154840 90000000 0220d840
0xc260e190: 90000000 02158840 90000000 02154040
0xc260e1a0: 90000000 02159840 90000000 02175040
0xc260e1b0: 90000000 02203840 90000000 0215b840
0xc260e1c0: 90000000 0215b040 90000000 02157040
0xc260e1d0: 90000000 0220d040 90000000 02179040
0xc260e1e0: 90000000 02083040 90000000 0215a840
0xc260e1f0: 90000000 02157840 b0000000 0260c840
PHY: mdio@e0102320:01 - Link is Up - 10/Half
[-- Attachment #3: Type: text/plain, Size: 150 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH v3 02/22] bitops: rename generic little-endian bitops functions
From: Akinobu Mita @ 2010-11-23 13:38 UTC (permalink / raw)
To: linux-kernel, linux-arch, Andrew Morton
Cc: rds-devel, kvm, Marcelo Tosatti, Akinobu Mita, Andy Grover,
linux-m68k, netdev, Andreas Schwab, Avi Kivity, Greg Ungerer,
Geert Uytterhoeven, linuxppc-dev, David S. Miller, Paul Mackerras
In-Reply-To: <1290519504-3958-1-git-send-email-akinobu.mita@gmail.com>
As a preparation for providing little-endian bitops for all architectures,
This removes generic_ prefix from little-endian bitops function names
in asm-generic/bitops/le.h.
s/generic_find_next_le_bit/find_next_le_bit/
s/generic_find_next_zero_le_bit/find_next_zero_le_bit/
s/generic_find_first_zero_le_bit/find_first_zero_le_bit/
s/generic___test_and_set_le_bit/__test_and_set_le_bit/
s/generic___test_and_clear_le_bit/__test_and_clear_le_bit/
s/generic_test_le_bit/test_le_bit/
s/generic___set_le_bit/__set_le_bit/
s/generic___clear_le_bit/__clear_le_bit/
s/generic_test_and_set_le_bit/test_and_set_le_bit/
s/generic_test_and_clear_le_bit/test_and_clear_le_bit/
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andy Grover <andy.grover@oracle.com>
Cc: rds-devel@oss.oracle.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org
---
No change from previous submission
arch/avr32/kernel/avr32_ksyms.c | 4 ++--
arch/avr32/lib/findbit.S | 4 ++--
arch/m68k/include/asm/bitops_mm.h | 8 ++++----
arch/m68k/include/asm/bitops_no.h | 2 +-
arch/powerpc/include/asm/bitops.h | 11 ++++++-----
include/asm-generic/bitops/ext2-non-atomic.h | 12 ++++++------
include/asm-generic/bitops/le.h | 26 +++++++++++++-------------
include/asm-generic/bitops/minix-le.h | 10 +++++-----
lib/find_next_bit.c | 9 ++++-----
net/rds/cong.c | 6 +++---
virt/kvm/kvm_main.c | 2 +-
11 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/arch/avr32/kernel/avr32_ksyms.c b/arch/avr32/kernel/avr32_ksyms.c
index 11e310c..c63b943 100644
--- a/arch/avr32/kernel/avr32_ksyms.c
+++ b/arch/avr32/kernel/avr32_ksyms.c
@@ -58,8 +58,8 @@ EXPORT_SYMBOL(find_first_zero_bit);
EXPORT_SYMBOL(find_next_zero_bit);
EXPORT_SYMBOL(find_first_bit);
EXPORT_SYMBOL(find_next_bit);
-EXPORT_SYMBOL(generic_find_next_le_bit);
-EXPORT_SYMBOL(generic_find_next_zero_le_bit);
+EXPORT_SYMBOL(find_next_le_bit);
+EXPORT_SYMBOL(find_next_zero_le_bit);
/* I/O primitives (lib/io-*.S) */
EXPORT_SYMBOL(__raw_readsb);
diff --git a/arch/avr32/lib/findbit.S b/arch/avr32/lib/findbit.S
index 997b33b..6880d85 100644
--- a/arch/avr32/lib/findbit.S
+++ b/arch/avr32/lib/findbit.S
@@ -123,7 +123,7 @@ ENTRY(find_next_bit)
brgt 1b
retal r11
-ENTRY(generic_find_next_le_bit)
+ENTRY(find_next_le_bit)
lsr r8, r10, 5
sub r9, r11, r10
retle r11
@@ -153,7 +153,7 @@ ENTRY(generic_find_next_le_bit)
brgt 1b
retal r11
-ENTRY(generic_find_next_zero_le_bit)
+ENTRY(find_next_zero_le_bit)
lsr r8, r10, 5
sub r9, r11, r10
retle r11
diff --git a/arch/m68k/include/asm/bitops_mm.h b/arch/m68k/include/asm/bitops_mm.h
index b4ecdaa..f1010ab 100644
--- a/arch/m68k/include/asm/bitops_mm.h
+++ b/arch/m68k/include/asm/bitops_mm.h
@@ -366,9 +366,9 @@ static inline int minix_test_bit(int nr, const void *vaddr)
#define ext2_clear_bit(nr, addr) __test_and_clear_bit((nr) ^ 24, (unsigned long *)(addr))
#define ext2_clear_bit_atomic(lock, nr, addr) test_and_clear_bit((nr) ^ 24, (unsigned long *)(addr))
#define ext2_find_next_zero_bit(addr, size, offset) \
- generic_find_next_zero_le_bit((unsigned long *)addr, size, offset)
+ find_next_zero_le_bit((unsigned long *)addr, size, offset)
#define ext2_find_next_bit(addr, size, offset) \
- generic_find_next_le_bit((unsigned long *)addr, size, offset)
+ find_next_le_bit((unsigned long *)addr, size, offset)
static inline int ext2_test_bit(int nr, const void *vaddr)
{
@@ -398,7 +398,7 @@ static inline int ext2_find_first_zero_bit(const void *vaddr, unsigned size)
return (p - addr) * 32 + res;
}
-static inline unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
+static inline unsigned long find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset)
{
const unsigned long *p = addr + (offset >> 5);
@@ -440,7 +440,7 @@ static inline int ext2_find_first_bit(const void *vaddr, unsigned size)
return (p - addr) * 32 + res;
}
-static inline unsigned long generic_find_next_le_bit(const unsigned long *addr,
+static inline unsigned long find_next_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset)
{
const unsigned long *p = addr + (offset >> 5);
diff --git a/arch/m68k/include/asm/bitops_no.h b/arch/m68k/include/asm/bitops_no.h
index 9d3cbe5..292e1ce 100644
--- a/arch/m68k/include/asm/bitops_no.h
+++ b/arch/m68k/include/asm/bitops_no.h
@@ -325,7 +325,7 @@ found_middle:
}
#define ext2_find_next_bit(addr, size, off) \
- generic_find_next_le_bit((unsigned long *)(addr), (size), (off))
+ find_next_le_bit((unsigned long *)(addr), (size), (off))
#include <asm-generic/bitops/minix.h>
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index 30964ae..b4f3f84 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -294,11 +294,12 @@ static __inline__ int test_le_bit(unsigned long nr,
#define __test_and_clear_le_bit(nr, addr) \
__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define find_first_zero_le_bit(addr, size) generic_find_next_zero_le_bit((addr), (size), 0)
-unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
+#define find_first_zero_le_bit(addr, size) \
+ find_next_zero_le_bit((addr), (size), 0)
+unsigned long find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
-unsigned long generic_find_next_le_bit(const unsigned long *addr,
+unsigned long find_next_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
/* Bitmap functions for the ext2 filesystem */
@@ -317,10 +318,10 @@ unsigned long generic_find_next_le_bit(const unsigned long *addr,
#define ext2_find_first_zero_bit(addr, size) \
find_first_zero_le_bit((unsigned long*)addr, size)
#define ext2_find_next_zero_bit(addr, size, off) \
- generic_find_next_zero_le_bit((unsigned long*)addr, size, off)
+ find_next_zero_le_bit((unsigned long *)addr, size, off)
#define ext2_find_next_bit(addr, size, off) \
- generic_find_next_le_bit((unsigned long *)addr, size, off)
+ find_next_le_bit((unsigned long *)addr, size, off)
/* Bitmap functions for the minix filesystem. */
#define minix_test_and_set_bit(nr,addr) \
diff --git a/include/asm-generic/bitops/ext2-non-atomic.h b/include/asm-generic/bitops/ext2-non-atomic.h
index 63cf822..9c7bb9a 100644
--- a/include/asm-generic/bitops/ext2-non-atomic.h
+++ b/include/asm-generic/bitops/ext2-non-atomic.h
@@ -4,17 +4,17 @@
#include <asm-generic/bitops/le.h>
#define ext2_set_bit(nr,addr) \
- generic___test_and_set_le_bit((nr),(unsigned long *)(addr))
+ __test_and_set_le_bit((nr), (unsigned long *)(addr))
#define ext2_clear_bit(nr,addr) \
- generic___test_and_clear_le_bit((nr),(unsigned long *)(addr))
+ __test_and_clear_le_bit((nr), (unsigned long *)(addr))
#define ext2_test_bit(nr,addr) \
- generic_test_le_bit((nr),(unsigned long *)(addr))
+ test_le_bit((nr), (unsigned long *)(addr))
#define ext2_find_first_zero_bit(addr, size) \
- generic_find_first_zero_le_bit((unsigned long *)(addr), (size))
+ find_first_zero_le_bit((unsigned long *)(addr), (size))
#define ext2_find_next_zero_bit(addr, size, off) \
- generic_find_next_zero_le_bit((unsigned long *)(addr), (size), (off))
+ find_next_zero_le_bit((unsigned long *)(addr), (size), (off))
#define ext2_find_next_bit(addr, size, off) \
- generic_find_next_le_bit((unsigned long *)(addr), (size), (off))
+ find_next_le_bit((unsigned long *)(addr), (size), (off))
#endif /* _ASM_GENERIC_BITOPS_EXT2_NON_ATOMIC_H_ */
diff --git a/include/asm-generic/bitops/le.h b/include/asm-generic/bitops/le.h
index db2be81..6ad46ce 100644
--- a/include/asm-generic/bitops/le.h
+++ b/include/asm-generic/bitops/le.h
@@ -8,42 +8,42 @@
#define BITOP_LE_SWIZZLE 0
-#define generic_find_next_zero_le_bit(addr, size, offset) \
+#define find_next_zero_le_bit(addr, size, offset) \
find_next_zero_bit(addr, size, offset)
-#define generic_find_next_le_bit(addr, size, offset) \
+#define find_next_le_bit(addr, size, offset) \
find_next_bit(addr, size, offset)
#elif defined(__BIG_ENDIAN)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) & ~0x7)
-extern unsigned long generic_find_next_zero_le_bit(const unsigned long *addr,
+extern unsigned long find_next_zero_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
-extern unsigned long generic_find_next_le_bit(const unsigned long *addr,
+extern unsigned long find_next_le_bit(const unsigned long *addr,
unsigned long size, unsigned long offset);
#else
#error "Please fix <asm/byteorder.h>"
#endif
-#define generic_test_le_bit(nr, addr) \
+#define test_le_bit(nr, addr) \
test_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___set_le_bit(nr, addr) \
+#define __set_le_bit(nr, addr) \
__set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___clear_le_bit(nr, addr) \
+#define __clear_le_bit(nr, addr) \
__clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic_test_and_set_le_bit(nr, addr) \
+#define test_and_set_le_bit(nr, addr) \
test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic_test_and_clear_le_bit(nr, addr) \
+#define test_and_clear_le_bit(nr, addr) \
test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___test_and_set_le_bit(nr, addr) \
+#define __test_and_set_le_bit(nr, addr) \
__test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic___test_and_clear_le_bit(nr, addr) \
+#define __test_and_clear_le_bit(nr, addr) \
__test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (addr))
-#define generic_find_first_zero_le_bit(addr, size) \
- generic_find_next_zero_le_bit((addr), (size), 0)
+#define find_first_zero_le_bit(addr, size) \
+ find_next_zero_le_bit((addr), (size), 0)
#endif /* _ASM_GENERIC_BITOPS_LE_H_ */
diff --git a/include/asm-generic/bitops/minix-le.h b/include/asm-generic/bitops/minix-le.h
index 4a981c1..ed0ae09 100644
--- a/include/asm-generic/bitops/minix-le.h
+++ b/include/asm-generic/bitops/minix-le.h
@@ -4,14 +4,14 @@
#include <asm-generic/bitops/le.h>
#define minix_test_and_set_bit(nr,addr) \
- generic___test_and_set_le_bit((nr),(unsigned long *)(addr))
+ __test_and_set_le_bit((nr), (unsigned long *)(addr))
#define minix_set_bit(nr,addr) \
- generic___set_le_bit((nr),(unsigned long *)(addr))
+ __set_le_bit((nr), (unsigned long *)(addr))
#define minix_test_and_clear_bit(nr,addr) \
- generic___test_and_clear_le_bit((nr),(unsigned long *)(addr))
+ __test_and_clear_le_bit((nr), (unsigned long *)(addr))
#define minix_test_bit(nr,addr) \
- generic_test_le_bit((nr),(unsigned long *)(addr))
+ test_le_bit((nr), (unsigned long *)(addr))
#define minix_find_first_zero_bit(addr,size) \
- generic_find_first_zero_le_bit((unsigned long *)(addr),(size))
+ find_first_zero_le_bit((unsigned long *)(addr), (size))
#endif /* _ASM_GENERIC_BITOPS_MINIX_LE_H_ */
diff --git a/lib/find_next_bit.c b/lib/find_next_bit.c
index 24c59de..eb8934b 100644
--- a/lib/find_next_bit.c
+++ b/lib/find_next_bit.c
@@ -185,7 +185,7 @@ static inline unsigned long ext2_swab(const unsigned long y)
#endif
}
-unsigned long generic_find_next_zero_le_bit(const unsigned long *addr, unsigned
+unsigned long find_next_zero_le_bit(const unsigned long *addr, unsigned
long size, unsigned long offset)
{
const unsigned long *p = addr + BITOP_WORD(offset);
@@ -226,10 +226,9 @@ found_middle:
found_middle_swap:
return result + ffz(ext2_swab(tmp));
}
+EXPORT_SYMBOL(find_next_zero_le_bit);
-EXPORT_SYMBOL(generic_find_next_zero_le_bit);
-
-unsigned long generic_find_next_le_bit(const unsigned long *addr, unsigned
+unsigned long find_next_le_bit(const unsigned long *addr, unsigned
long size, unsigned long offset)
{
const unsigned long *p = addr + BITOP_WORD(offset);
@@ -271,5 +270,5 @@ found_middle:
found_middle_swap:
return result + __ffs(ext2_swab(tmp));
}
-EXPORT_SYMBOL(generic_find_next_le_bit);
+EXPORT_SYMBOL(find_next_le_bit);
#endif /* __BIG_ENDIAN */
diff --git a/net/rds/cong.c b/net/rds/cong.c
index 75ea686..90ca44f 100644
--- a/net/rds/cong.c
+++ b/net/rds/cong.c
@@ -285,7 +285,7 @@ void rds_cong_set_bit(struct rds_cong_map *map, __be16 port)
i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
- generic___set_le_bit(off, (void *)map->m_page_addrs[i]);
+ __set_le_bit(off, (void *)map->m_page_addrs[i]);
}
void rds_cong_clear_bit(struct rds_cong_map *map, __be16 port)
@@ -299,7 +299,7 @@ void rds_cong_clear_bit(struct rds_cong_map *map, __be16 port)
i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
- generic___clear_le_bit(off, (void *)map->m_page_addrs[i]);
+ __clear_le_bit(off, (void *)map->m_page_addrs[i]);
}
static int rds_cong_test_bit(struct rds_cong_map *map, __be16 port)
@@ -310,7 +310,7 @@ static int rds_cong_test_bit(struct rds_cong_map *map, __be16 port)
i = be16_to_cpu(port) / RDS_CONG_MAP_PAGE_BITS;
off = be16_to_cpu(port) % RDS_CONG_MAP_PAGE_BITS;
- return generic_test_le_bit(off, (void *)map->m_page_addrs[i]);
+ return test_le_bit(off, (void *)map->m_page_addrs[i]);
}
void rds_cong_add_socket(struct rds_sock *rs)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5225052..da16155 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -1252,7 +1252,7 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
if (memslot && memslot->dirty_bitmap) {
unsigned long rel_gfn = gfn - memslot->base_gfn;
- generic___set_le_bit(rel_gfn, memslot->dirty_bitmap);
+ __set_le_bit(rel_gfn, memslot->dirty_bitmap);
}
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH v3 08/22] rds: stop including asm-generic/bitops/le.h
From: Akinobu Mita @ 2010-11-23 13:38 UTC (permalink / raw)
To: linux-kernel, linux-arch, Andrew Morton
Cc: Akinobu Mita, Andy Grover, rds-devel, David S. Miller, netdev
In-Reply-To: <1290519504-3958-1-git-send-email-akinobu.mita@gmail.com>
No need to include asm-generic/bitops/le.h as all architectures
provide little-endian bit operations now.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Andy Grover <andy.grover@oracle.com>
Cc: rds-devel@oss.oracle.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
No change from previous submission
net/rds/cong.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/rds/cong.c b/net/rds/cong.c
index 90ca44f..fa578d3 100644
--- a/net/rds/cong.c
+++ b/net/rds/cong.c
@@ -34,8 +34,6 @@
#include <linux/types.h>
#include <linux/rbtree.h>
-#include <asm-generic/bitops/le.h>
-
#include "rds.h"
/*
--
1.7.3.2
^ permalink raw reply related
* addrconf: refcnt with IPV6_PRIVACY enabled
From: Sergey Senozhatsky @ 2010-11-23 13:40 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, linux-kernel, Pekka Savola (ipv6), Hideaki YOSHIFUJI
Hello,
I've sent a patch http://lkml.org/lkml/2010/11/21/124
"[PATCH] ipv6: fix inet6_dev refcnt with IPV6_PRIVACY enabled" related
to wrong in6_dev refcnt value when IPV6_PRIVACY enabled.
I've took a second look, and question arised -
Is it actually necessary to in6_dev_hold/in6_dev_put in ipv6_regen_rndid?
In ipv6_regen_rndid we call in6_dev_hold only when mod_timer == 0,
and always in6_dev_put.
I've removed check for < 0 and goto from __ipv6_regen_rndid call, since it
always return 0.
Please, kindly review V2.
---
net/ipv6/addrconf.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2fc35b3..8187d14 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -425,7 +425,6 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
dev->name);
ndev->cnf.use_tempaddr = -1;
} else {
- in6_dev_hold(ndev);
ipv6_regen_rndid((unsigned long) ndev);
}
#endif
@@ -1653,8 +1652,7 @@ static void ipv6_regen_rndid(unsigned long data)
if (idev->dead)
goto out;
- if (__ipv6_regen_rndid(idev) < 0)
- goto out;
+ __ipv6_regen_rndid(idev);
expires = jiffies +
idev->cnf.temp_prefered_lft * HZ -
@@ -1667,13 +1665,11 @@ static void ipv6_regen_rndid(unsigned long data)
goto out;
}
- if (!mod_timer(&idev->regen_timer, expires))
- in6_dev_hold(idev);
-
+ mod_timer(&idev->regen_timer, expires);
+
out:
write_unlock_bh(&idev->lock);
rcu_read_unlock_bh();
- in6_dev_put(idev);
}
static int __ipv6_try_regen_rndid(struct inet6_dev *idev, struct in6_addr *tmpaddr) {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox