Herbert Xu | 1 Oct 03:52 2006
Picon
Picon

Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE

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 sched_htb.c should be reverted.

I've fixed sched_htb.c? That's news to me :)

I fully agree with your patch though.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

akpm | 1 Oct 05:43 2006

[patch 1/2] bluetooth: guard bt_proto with rwlock

From: Masatake YAMATO <jet <at> gyve.org>

I found that bt_proto manipulated in bt_sock_register is not guarded
from race condition.

Look at net/bluetooth/af_bluetooth.c:

    static struct net_proto_family *bt_proto[BT_MAX_PROTO];

    int bt_sock_register(int proto, struct net_proto_family *ops)
    {
	    if (proto < 0 || proto >= BT_MAX_PROTO)
		    return -EINVAL;

	    if (bt_proto[proto])
		    return -EEXIST;

	    bt_proto[proto] = ops;
	    return 0;
    }

Here bt_proto[proto] is set.

In other hand,

    static int bt_sock_create(struct socket *sock, int proto)
    {
	    int err = 0;

	    if (proto < 0 || proto >= BT_MAX_PROTO)
(Continue reading)

akpm | 1 Oct 05:43 2006

[patch 2/2] bluetooth: use GFP_ATOMIC in *_sock_create's sk_alloc

From: Frederik Deweerdt <deweerdt <at> free.fr>

I think that the bluetooth-guard-bt_proto-with-rwlock.patch introduced the following
BUG:
[   43.232000] BUG: sleeping function called from invalid context at mm/slab.c:2903
[   43.232000] in_atomic():1, irqs_disabled():0
[   43.232000]  [<c0104114>] show_trace_log_lvl+0x197/0x1ba
[   43.232000]  [<c010415e>] show_trace+0x27/0x29
[   43.232000]  [<c010426e>] dump_stack+0x26/0x28
[   43.232000]  [<c011ad1c>] __might_sleep+0xa2/0xaa
[   43.232000]  [<c0173085>] __kmalloc+0x9c/0xb3
[   43.232000]  [<c02f9295>] sk_alloc+0x1bc/0x1de
[   43.232000]  [<c036d689>] hci_sock_create+0x42/0x8a
[   43.236000]  [<c0366f40>] bt_sock_create+0xb5/0x154
[   43.236000]  [<c02f69dc>] __sock_create+0x131/0x356
[   43.236000]  [<c02f6c2f>] sock_create+0x2e/0x30
[   43.236000]  [<c02f6c88>] sys_socket+0x27/0x53
[   43.240000]  [<c02f7db5>] sys_socketcall+0xa9/0x277
[   43.240000]  [<c0103131>] sysenter_past_esp+0x56/0x8d
[   43.240000]  [<b7f38410>] 0xb7f38410

This patch makes sk_alloc GFP_ATOMIC, because we are holding the bt_proto_rwlock, for
the following functions:
- bnep_sock_create
- cmtp_sock_create
- hci_sock_create
- hidp_sock_create
- l2cap_sock_create
- rfcomm_sock_create
- sco_sock_create
(Continue reading)

Jeff Garzik | 1 Oct 05:48 2006

netdev-2.6.git frozen

Similar to David's recent announcement, netdev-2.6.git is now closed to 
new features.

Though really, [my fault] I should have posted this as soon as the merge 
window opened.  The stuff that goes into each new release, when the 
merge window opens, should be stuff that has already been through a 
round of testing in -mm.

The updates presented in netdev -- e100, e1000, ixgb and sky2 -- will go 
upstream tomorrow.  Everything else will be fixed.

And the message for the future is:  don't wait until the merge window 
opens, to submit your test.  Doing so means it doesn't get the normal 
amount of testing and review, and is thus discouraged.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Garzik | 1 Oct 05:52 2006

Re: netdev-2.6.git frozen

Jeff Garzik wrote:
> Similar to David's recent announcement, netdev-2.6.git is now closed to 
> new features.
> 
> Though really, [my fault] I should have posted this as soon as the merge 
> window opened.  The stuff that goes into each new release, when the 
> merge window opens, should be stuff that has already been through a 
> round of testing in -mm.
> 
> The updates presented in netdev -- e100, e1000, ixgb and sky2 -- will go 
> upstream tomorrow.  Everything else will be fixed.

s/fixed/fixes/

I wish "everything" was fixed, after tomorrow :)

> And the message for the future is:  don't wait until the merge window 
> opens, to submit your test.  Doing so means it doesn't get the normal 

s/test/code/

Apparently I need my morning Pepsi.

> amount of testing and review, and is thus discouraged.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Ismail Donmez | 1 Oct 08:14 2006
Picon

Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE

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 sched_htb.c should be reverted.
>
> I've fixed sched_htb.c? That's news to me :)
>
> I fully agree with your patch though.

Oh it was Patrick McHardy <kaber <at> trash.net>, sorry. Patch again with a 
Signed-off line too this time.

Hi,

With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] ,  RB_EMPTY_NODE 
changed behaviour so it returns false when the node is empty as expected. 
Hence Patrick McHardy's fix for sched_htb.c should be reverted.

[1] 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=10fd48f2376db52f08bf0420d2c4f580e39269e1;hp=9817064b68fef7e4580c6df1ea597e106b9ff88b

Signed-off-by: Ismail Donmez <ismail <at> pardus.org.tr>

Regards,
ismail
Attachment (rb.diff): text/x-diff, 454 bytes
Ismail Donmez | 1 Oct 08:17 2006
Picon

[PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE

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] 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=10fd48f2376db52f08bf0420d2c4f580e39269e1;hp=9817064b68fef7e4580c6df1ea597e106b9ff88b

Signed-off-by: Ismail Donmez <ismail <at> pardus.org.tr>
Attachment (rb.diff): text/x-diff, 454 bytes
James Morris | 1 Oct 08:27 2006

[PATCH] Fix for IPsec leakage with SELinux enabled

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 logic and propagating a false "ok" back up to 
xfrm_lookup(), which then allowed packets to pass as if they were not 
associated with an xfrm policy.

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, because of an uncached lookup via 
flow_cache_lookup(), which would fail to resolve an xfrm policy because 
the SELinux policy is checked at that point via the resolver.

However, retransmitted SYNACKs would then find a cached flow entry when 
calling into flow_cache_lookup() with a null xfrm policy, which is 
interpreted by xfrm_lookup() as the packet not having any associated 
policy and similarly to the first case, allowing it to pass without 
transformation.

The solution presented here is to first ensure that errno values are 
correctly propagated all the way back up through the various call chains 
from security_xfrm_policy_lookup(), and handled correctly.

Then, flow_cache_lookup() is modified, so that if the policy resolver 
fails (typically a permission denied via the security module), the flow 
cache entry is killed rather than having a null policy assigned (which 
(Continue reading)

Jeff Garzik | 1 Oct 15:24 2006

ATM bug found

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 
assigned a value.  However, the caller of alloc_shaper() always tests 
the pcr value, regardless of whether or not 'unlimited' is true.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Garzik | 1 Oct 15:33 2006

[PATCH] atm/ambassador: fix return code bug


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 <jeff <at> garzik.org>

diff --git a/drivers/atm/ambassador.c b/drivers/atm/ambassador.c
index 4521a24..da599e6 100644
--- a/drivers/atm/ambassador.c
+++ b/drivers/atm/ambassador.c
 <at>  <at>  -915,8 +915,8  <at>  <at>  #endif

 /********** make rate (not quite as much fun as Horizon) **********/

-static unsigned int make_rate (unsigned int rate, rounding r,
-			       u16 * bits, unsigned int * actual) {
+static int make_rate (unsigned int rate, rounding r,
+		      u16 * bits, unsigned int * actual) {
   unsigned char exp = -1; // hush gcc
   unsigned int man = -1;  // hush gcc

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)


Gmane