On Sunday 01 October 2006 04:52, Herbert Xu wrote:
On Sat, Sep 30, 2006 at 10:23:46PM +0300, Ismail Donmez wrote:
With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
changed behaviour so it returns false when the node is empty as expected.
Hence Herbert's fix for
This time with correct description too, *sigh*
With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
changed behaviour so it returns true when the node is empty as expected.
Hence Patrick McHardy's fix for sched_htb.c should be reverted.
[1]
Please review this patch carefully. It addresses a couple of issues.
When a security module is loaded (in this case, SELinux), the
security_xfrm_policy_lookup() hook can return an access denied permission
(or other error). We were not handling that correctly, and in fact
inverting the return
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
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
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
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 drivername.conf or
something like that. This way, ethtool doesn't have to be
changed/updated/patched/likely-bug-added for every
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:
(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 in
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
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.
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
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
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 williams
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 has a
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 unsubscribe
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
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
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
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 an
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 here,
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]
---
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:
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
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
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
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(-)
---
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]
---
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
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 to do is to
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 blocked,
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
32 matches
Mail list logo
