On Mon, 02 Oct 2006 14:26:00 -0400
Jesse Huang <[EMAIL PROTECTED]> wrote:
> Correct initial and close hardware step.
Please provide a description of what was wrong with it, and how this
patch fixes it, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a me
On Mon, 02 Oct 2006 14:24:36 -0400
Jesse Huang <[EMAIL PROTECTED]> wrote:
> Fix TX Pause bug (reset_tx, intr_handler)
Please describe this bug more completely.How does this patch solve it?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
On Mon, 02 Oct 2006 14:26:36 -0400
Jesse Huang <[EMAIL PROTECTED]> wrote:
> Solve host error problem in low performance embedded system when continune
> down and up.
I don't understand that. Please describe the actual problem which is being
solved,
as well as the means by which it was solved,
On Mon, 02 Oct 2006 14:23:51 -0400
Jesse Huang <[EMAIL PROTECTED]> wrote:
> For pattern issue need to remove TxStartThresh and RxEarlyThresh.
Please describe this issue more completely.
What are the implications of simply removing this feature? Presumably that
code was there for a reason..
-
To
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
Solve host error problem in low performance embedded system when continune down
and up.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
Fix TX Pause bug (reset_tx, intr_handler)
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
e146d4c423de9c2e9d55fbf9c6b3abbee14ce9ac
diff --git
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
Correct initial and close hardware step.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
1bbb3f6231fa1f52a9f61e299f22610d357f6041
diff --git a/drivers/
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
For pattern issue need to remove TxStartThresh and RxEarlyThresh.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
3751714e0fc36905c87a230172d9561c29321
This patch adds a connector which reports networking's events to
userspace. It's sending events when a sock has its sk_state changed to :
- LISTEN or CLOSE for DCCP and TCP
- BIND or CLOSE for UDP.
With this notification, a userspace tool can ask the user if he want to
let the local firewall
Add a broken-on-64bit option, similar to the existing broken-on-smp
config option. This is just the first pass, marking the obvious
candidates.
Several driver have been marked as dependent on CONFIG_32BIT in the
past, when they should really be dependent on this new
CONFIG_BROKEN_ON_64BIT option
On Sun, 1 Oct 2006, Venkat Yekkirala wrote:
> > The way I was seeing the problem was when connecting via IPsec to a
> > confined service on an SELinux box (vsftpd), which did not have the
> > appropriate SELinux policy permissions to send packets via IPsec.
> >
> > The first SYNACK would be blo
> >>In the case above I am concerned about the situation where the
> >>skb->secmark == 0 and there is a IPv4 option (i.e. it is NetLabel
> >>labeled) on the packet.
>
> It's unfortunate that you cut out the code in your reply.
It's even more unfortunate that you should say this. The proper
thing
Invoke the skb_flow_out LSM hook for outbound
traffic for secid reconciliation and flow control.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
net/netfilter/xt_CONNSECMARK.c | 72 ---
net/netfilter/xt_SECMARK.c | 45 ++-
2 files change
This beings secmark into the picture when classifying flows
using an skb.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/linux/security.h | 10 --
include/linux/skbuff.h | 20
2 files changed, 20 insertions(+), 10 deletions(-)
--- net-2.6.sid/i
This labels the skb(s) for locally generated IPv6 traffic. This will
be used in pertinent flow control checks on the outbound later in the
LSM hook.
NOTE: Forwarded traffic is already labeled with the reconciled
secmark on the inbound.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
incl
This tracks the peer's secid at connection establishment time
for clients, for later retrieval using SO_PEERSEC.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/linux/security.h | 14 ++
net/ipv4/tcp_input.c |2 ++
security/dummy.c |6 ++
secu
This defines SELinux enforcement of the 2 new LSM hooks as well
as related changes elsewhere in the SELinux code.
This also now keeps track of the peersid thru the establishment
of a connection on the server (tracking peersid on the client
is covered later in this patch set).
Signed-off-by: Venka
This patchset helps with leveraging secmark in defining fine-grained security
check points with support for a. a default place holder domain defined using
secmark for each of the check points and b. flow control and reconciliation
of domains entering/leaving the system.
The reconciliation steps fo
This labels the skb(s) for locally generated IPv4 traffic. This will
be used in pertinent flow control checks on the outbound later in the
LSM hook.
This is not as pretty as it is for IPv6, but what to do?
Note that skb(s) that derive the secmark from the originating socket
do so in the outbound h
Invoke the skb_flow_in LSM hook for inbound
traffic for secid reconciliation and flow control.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/net/xfrm.h | 45 +--
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/include/net
Add skb_policy_check and skb_netfilter_check hooks to LSM to enable
reconciliation of the various security identifiers as well as enforce
flow control on inbound (PREROUTING/INPUT) and outbound
(OUTPUT/FORWARD/POSTROUTING)
traffic.
Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]>
---
include/
This patchset is relative to davem's net-2.6.git
The following are the changes included in this patchset since the previous post:
- Create IPSec SAs to be acquired with the creating sock's context as opposed
to that of the matching SPD rule, resulting in a simpler SPD as well as
policy.
- Set
> The way I was seeing the problem was when connecting via IPsec to a
> confined service on an SELinux box (vsftpd), which did not have the
> appropriate SELinux policy permissions to send packets via IPsec.
>
> The first SYNACK would be blocked,
Given that the resolver fails to find a policy h
In message <[EMAIL PROTECTED]>,Jeff Garzik writes:
>1) not safe on 64-bit
firestream is not the only driver that's likely 32-bit safe only.
zatm, nicstar, horizon and ambassdor all use virt_to_bus().
>2) variable 'tmc0' is indeed potentially used uninit'd, in particular if
>make_rate() returns a
The following gcc warning indicates a bug:
drivers/net/wan/pc300_drv.c: In function ‘cpc_open’:
drivers/net/wan/pc300_drv.c:2870: warning: ‘br’ may be used uninitialized in
this function
clock_rate_calc() is not checked for a negative return value.
-
To unsubscribe from this list: send the lin
gcc spits out this warning:
net/tipc/link.c: In function ‘link_retransmit_failure’:
net/tipc/link.c:1669: warning: cast from pointer to integer of different
size
More than a little bit ugly, storing integers in void*, but at least the
code is correct, unlike some of the more crufty Linux kernel
You also need to mark firestream as 32-bit only, in Kconfig...
(or fix it)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
chas williams - CONTRACTOR wrote:
> still generates a warning from gcc though.
The warning is bogus in this case, though -- the only way for "*pcr" to
be unset is when alloc_shaper() returns non-zero
> + *pcr = 0;
You're right, 0 is better than ATM_MAX_PCR here.
-Mitch
-
To unsubscr
In message <[EMAIL PROTECTED]>,Mitchell Blank Jr writes:
>The fix is for alloc_shaper() should really do "*pcr = ATM_MAX_PCR" in
>the "if (ubr)" stanza. Chas, want to submit that in the next batch
>of patches?
i dont think you can do that. pcr gets assigned to .min_pcr and .min_pcr
= ATM_MAX_PCR
please consider for 2.6.18 -- thanks!
[ATM]: [zatm] always *pcr in alloc_shaper()
Signed-off-by: Chas Williams <[EMAIL PROTECTED]>
---
commit ae0e261f74750f57c963349f5c09c8057d5eee32
tree 5e9358ef3fd7d00e3be7a1862afa62a6852c8cb6
parent d7b1207f84d681df2e46c6f22ca153eb7f0944cb
author chas william
please consider for 2.6.19 -- thanks!
[ATM]: [ambassador] Change the return type to reflect reality
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Chas Williams <[EMAIL PROTECTED]>
---
commit d7b1207f84d681df2e46c6f22ca153eb7f0944cb
tree 9204a7e7f6812bd683a0079a9a9177ec400fadbd
pa
please consider for 2.6.19 -- thanks!
[ATM]: kmalloc to kzalloc patches for drivers/atm
Signed-off-by: Om Narasimhan <[EMAIL PROTECTED]>
Signed-off-by: Chas Williams <[EMAIL PROTECTED]>
---
commit 339d365266211690a446773e3eb9d864637a71bb
tree d48530e7ba716797687d2831f0f5148cda4a999a
parent f6936
In message <[EMAIL PROTECTED]>,Jeff Garzik writes:
>If alloc_shaper() argument 'unlimited' is true, then pcr is never
>assigned a value. However, the caller of alloc_shaper() always tests
>the pcr value, regardless of whether or not 'unlimited' is true.
when unlimited is true, this means ubr.
Jeff Garzik wrote:
> 1) not safe on 64-bit
Almost certainly correct. Probably never will be -- IIRC this SAR was
mainly used in embedded apps. I don't know if any commercially-available
PCI cards were ever made with it. I could be wrong though, it's been awhile
since I was up on the ATM industr
(cc:'s trimmed again)
Jeff Garzik wrote:
> drivers/atm/ambassador.c: In function ?amb_open?:
> drivers/atm/ambassador.c:1049: warning: ?tx_rate_bits? may be used
> uninitialized in this function
>
> The variable is accessed before the make_rate() error code is checked,
Or rather, the make_rate
This driver does some dodgy stuff, reading a 32-bit value directly from
the hardware, calling bus_to_virt() on it, and then pretending that will
work just fine on 64-bit.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig
index cfa5af8..8903ecf
(trimmed cc:'s since, IMO, isn't really all that general interest)
Jeff Garzik wrote:
> drivers/atm/zatm.c: In function ?zatm_open?:
> drivers/atm/zatm.c:919: warning: ?pcr? may be used uninitialized in this
> function
Yeah, looks like a bug. Not very high-impact because:
1. it only results i
The gcc warning "may be used uninitialized" is correct here, as well:
drivers/atm/firestream.c: In function ‘top_off_fp’:
drivers/atm/firestream.c:1501: warning: cast to pointer from integer of
different size
drivers/atm/firestream.c: In function ‘fs_open’:
drivers/atm/firestream.c:870: warning
Rick Jones wrote:
> 2) develop some style
>>> of register description definition type of text file, maybe XML, maybe
>>> INI style or something stored in /etc/ethtool as .conf or
>>> something like that. This way, ethtool doesn't have to be
>>> changed/updated/patched/likely-bug-added for every si
The following warning appears to be real:
drivers/atm/ambassador.c: In function ‘amb_open’:
drivers/atm/ambassador.c:1049: warning: ‘tx_rate_bits’ may be used
uninitialized in this function
The variable is accessed before the make_rate() error code is checked,
thus accessing an uninit'd value
While auditing a 'may be used uninitialized' warning, I found a minor
bug: make_rate() has the standard error code convention -- zero for
success, negative errno on error -- but its return type is defined as
unsigned.
Change the return type to reflect reality.
Signed-off-by: Jeff Garzik <[EMAIL
Unlike 98% of the warnings of this type, this gcc warning does indeed
seem to indicate a bug:
drivers/atm/zatm.c: In function ‘zatm_open’:
drivers/atm/zatm.c:919: warning: ‘pcr’ may be used uninitialized in this
function
If alloc_shaper() argument 'unlimited' is true, then pcr is never
assig
42 matches
Mail list logo
