In article [EMAIL PROTECTED] (at Thu, 5 Oct 2006 15:35:31 +1000), Herbert Xu
[EMAIL PROTECTED] says:
Are there any non-multicast interfaces that require addrconf?
In other words, what does the following patch break :)
Why do you want to do this? Xen issue?
As Alexey mentioned before,
On Thu, 5 Oct 2006, Herbert Xu wrote:
Are there any non-multicast interfaces that require addrconf?
In other words, what does the following patch break :)
Point-to-point (or NOARP) interfaces such as tunnels. I'm not sure
what are the right flags to check..
--
Pekka Savola
On Thu, Oct 05, 2006 at 03:06:34PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
Why do you want to do this? Xen issue?
Yes it's to disable addrconf on the Xen bridge interface.
As Alexey mentioned before, addrconf should work even for !MULTICAST
BROADCAST. This is true for POINTOPOINT
Pekka Savola [EMAIL PROTECTED] wrote:
On Thu, 5 Oct 2006, Herbert Xu wrote:
Are there any non-multicast interfaces that require addrconf?
In other words, what does the following patch break :)
Point-to-point (or NOARP) interfaces such as tunnels. I'm not sure
what are the right flags to
On Wed, 2006-10-04 at 13:57 -0400, Dan Williams wrote:
Are we talking about config changes when some other process pushes a new
config to the card, or when something happens over the air, like new
association or deauth?
Well, both actually :) Yeah, we should have different groups for that.
On Wed, 2006-10-04 at 14:45 -0700, Jouni Malinen wrote:
SIOCSIWMLME was designed to allow additional MLME commands to be added.
IMHO, a potential replacement in the future should not prevent us from
extending WEXT at this point and stop all changes in something that is
currently available.
On Wed, Oct 04, 2006 at 10:57:32AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
On 10/3/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
http://tservice.net.ru/~s0mbre/archive/kevent/evtest.c
These are simple programs which by
On Wed, Oct 04, 2006 at 10:20:44AM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
It is completely possible to do what you describe without special
syscall parameters.
First of all, I don't see how this is efficiently possible. The mask
might change from call
This patch will break multicast forwarding using the pim6 daemon.
This daemon creates an interface called pim6reg which is not MULTICAST
enabled but needs to be configred by addrconf to get ff00::/8 and
fe80::/64 routes. This is required since the route lookup process has
been enforced to
On Thu, Oct 05, 2006 at 03:10:02AM +0200, Samir Bellabes ([EMAIL PROTECTED])
wrote:
You can also extend your module to be more generic and send all (or just
requested in config) state changes for all protocols (or those checked
in config).
Ok, so the next step now is to target all state
applied to #upstream-fixes
-
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
applied 1-5 to #upstream-fixes
-
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
applied to #upstream-fixes
-
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
Maciej W. Rozycki wrote:
Hello,
[...]
Please consider.
Maciej
Please don't include this in the patch description. It must be
hand-edited out, before applying with git-applymbox. All comments
should be placed AFTER the --- separator, which terminates the patch
description.
Applied
Jay Vosburgh wrote:
From: Karsten Keil [EMAIL PROTECTED]
In bond_alb_monitor the bond-curr_slave_lock write lock is taken
and then dev_set_promiscuity maybe called which can take some time,
depending on the network HW. If a network IRQ for this card come in
the softirq handler maybe try to
Jeff Garzik wrote:
Maciej W. Rozycki wrote:
Hello,
[...]
Please consider.
Maciej
Please don't include this in the patch description. It must be
hand-edited out, before applying with git-applymbox. All comments
should be placed AFTER the --- separator, which terminates the patch
Bill Helfinstine wrote:
The b44 driver has a bug where if there are more than
B44_MCAST_TABLE_SIZE groups in the dev-mc_list, it will only listen to
the first B44_MCAST_TABLE_SIZE that it sees.
This patch makes the driver go into RXCONFIG_ALLMULTI mode if there are
more than
ACK, but patch doesn't apply to 2.6.18
-
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
On Wed, 04 Oct 2006 18:51:40 +0200, Jan Kiszka wrote:
Ok, I'm not promising success and I'm going to duck immediately if
someone else feels like working on it, but I could try to patch in this
direction.
Your patches are welcomed!
Now there just remains my precautious question if there are
On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote:
Well another point of concern for me is the TSF handling, those handlers are
called
from interrupt context as well, and also deliver problems for the USB drivers
in case
of adhoc mode.
Where is a problem with tsf handlers? get_tsf is
On Thursday 05 October 2006 10:57, Evgeniy Polyakov wrote:
Well, it is possible to create /sys/proc entry for that, and even now
userspace can grow mapping ring until it is forbiden by kernel, which
means limit is reached.
No need for yet another /sys/proc entry.
Right now, I (for example)
which patch is to be applied first?
You failed to include an order, as described by
http://linux.yyz.us/patch-format.html and Documentation/SubmittingPatches.
Also, stuff like hi Jeff and Thanks, Jan-Bernd must be hand-edited
out before patch application. All comments not intended to be
On Thursday 05 October 2006 12:55, Evgeniy Polyakov wrote:
On Thu, Oct 05, 2006 at 12:45:03PM +0200, Eric Dumazet ([EMAIL PROTECTED])
What is missing or not obvious is : If events are skipped because of
overflows, What happens ? Connections stuck forever ? Hope that
everything will
On Thu, Oct 05, 2006 at 02:09:31PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Thursday 05 October 2006 12:55, Evgeniy Polyakov wrote:
On Thu, Oct 05, 2006 at 12:45:03PM +0200, Eric Dumazet ([EMAIL PROTECTED])
What is missing or not obvious is : If events are skipped because of
On Wed, Oct 04, 2006 at 01:57:38PM -0400, Dan Williams wrote:
* None
- Crypto: None
- 802.11 Auth: Open System
* Static WEP
- Keys: up to 4 group keys
- Crypto: WEP-40, WEP-104, WEP-152, WEP-256
- 802.11 Auth: Open System or Shared Key
- Key Mgmt/Auth: none
*
Jay Vosburgh wrote:
Or Gerlitz [EMAIL PROTECTED] wrote:
My understanding is that changing ifenslave and the bonding kernel code to
allow for enslaving while master is not up is enough, so actually no
change is needed to the sysconfig tools, correct?
Incorrect. The /sbin/ifup included
On Thursday 05 October 2006 13:29, Jiri Benc wrote:
On Wed, 04 Oct 2006 18:51:40 +0200, Jan Kiszka wrote:
Ok, I'm not promising success and I'm going to duck immediately if
someone else feels like working on it, but I could try to patch in this
direction.
Your patches are welcomed!
On Thursday 05 October 2006 13:37, Jiri Benc wrote:
On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote:
Well another point of concern for me is the TSF handling, those handlers
are called
from interrupt context as well, and also deliver problems for the USB
drivers in case
of
On Thu, 5 Oct 2006 17:00:31 +0200, Ivo van Doorn wrote:
Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID
7a:b9:60:8a:84:39
Sep 13 12:27:34 wz4a kernel: BUG: scheduling while atomic:
swapper/0x0100/0
Sep 13 12:27:34 wz4a kernel:
Ivo van Doorn wrote:
On Thursday 05 October 2006 13:37, Jiri Benc wrote:
On Wed, 4 Oct 2006 19:22:38 +0200, Ivo van Doorn wrote:
Well another point of concern for me is the TSF handling, those handlers
are called
from interrupt context as well, and also deliver problems for the USB
drivers
Hi,
This does not happen in rt2500usb driver, since no TSF handling is possible
due to a lack of TSF registers in the device.
This path would be fixed by my conversion patch of sta.timer into
sta.work that I sent you yesterday privately. Unfortunately, I don't
have a copy at hand ATM.
On Thursday 05 October 2006 17:13, Jiri Benc wrote:
On Thu, 5 Oct 2006 17:00:31 +0200, Ivo van Doorn wrote:
Basically it comes down to this:
Sep 13 12:27:34 wz4a kernel: wlan0: Creating new IBSS network, BSSID
7a:b9:60:8a:84:39
Sep 13 12:27:34 wz4a kernel: BUG: scheduling while
On Thursday 05 October 2006 17:39, Jiri Benc wrote:
On Thu, 5 Oct 2006 17:32:39 +0200, Ivo van Doorn wrote:
Well I currently have no time to check it, but can
config_interface handler still be called from interrupt context or has this
also been fixed?
Will be fixed by the sta_timer
On Thu, 5 Oct 2006 17:32:39 +0200, Ivo van Doorn wrote:
Well I currently have no time to check it, but can
config_interface handler still be called from interrupt context or has this
also been fixed?
Will be fixed by the sta_timer conversion as well.
Jiri
--
Jiri Benc
SUSE Labs
-
To
On Thursday 05 October 2006 12:21, Evgeniy Polyakov wrote:
On Thu, Oct 05, 2006 at 11:56:24AM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Thursday 05 October 2006 10:57, Evgeniy Polyakov wrote:
Well, it is possible to create /sys/proc entry for that, and even now
userspace can
On Thu, Oct 05, 2006 at 04:01:19PM +0200, Hans Henrik Happe ([EMAIL PROTECTED])
wrote:
And what happens when there are 3 empty at the beginning and \we need to
put there 4 ready events?
Couldn't there be 3 areas in the mmap buffer:
- Unused: entries that the kernel can alloc from.
-
Evgeniy Polyakov wrote:
And you can add/remove signal events using existing kevent api between
calls.
That's far more expensive than using a mask under control of the program.
And creating special cases for usual events is bad.
There is unified way to deal with events in kevent -
On Wed, 2006-10-04 at 18:08 -0700, Martin Bligh wrote:
Andi Kleen wrote:
I think most likely it would crash on 2.6.18. Keith mannthey had reported
a different crash on 2.6.18-rc4-mm2 when this patch was introduced first
time. Following is the link to the thread.
Then maybe trying
On Wed, 2006-10-04 at 16:02 -0500, Steve Fox wrote:
On Wed, 2006-10-04 at 09:57 -0700, Andrew Morton wrote:
You might well find this bisection lands you on origin.patch. ie: a
mainline bug. I note that David merged a few more xfrm fixes this morning.
So to confirm that, first test
On Thu, 2006-10-05 at 09:53 -0500, Steve Fox wrote:
On Wed, 2006-10-04 at 18:08 -0700, Martin Bligh wrote:
Andi Kleen wrote:
I think most likely it would crash on 2.6.18. Keith mannthey had reported
a different crash on 2.6.18-rc4-mm2 when this patch was introduced first
time. Following
On Thu, 2006-10-05 at 08:12 -0700, Badari Pulavarty wrote:
Can you post the latest panic stack again (with CONFIG_DEBUG_KERNEL) ?
CONFIG_DEBUG_KERNEL should be on
Last time I couldn't match your instruction dump to any code segment
in the routine. And also, can you post your .config file. I
Is there a reason why the tunnel driver for IPv6-in-IPv4 is currently
compiled into the ipv6 module? This driver is only needed in gateways
between different IPv6 networks. On all other hosts with ipv6 enabled it
is not required. To have this driver in a seperate module will save
memory on those
This eHEA patch covers required changes related to Anton Blanchard's new hvcall
interface.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 4a85aca..0b51a8c 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++
On Thu, Oct 05, 2006 at 11:49:38AM -0400, James Morris wrote:
On Thu, 5 Oct 2006, Joerg Roedel wrote:
Is there a reason why the tunnel driver for IPv6-in-IPv4 is currently
compiled into the ipv6 module? This driver is only needed in gateways
between different IPv6 networks. On all other
This is an update including the following changes:
1. Some help text for Kconfig.
2. Removal of unused module options.
3. Phylib support and the resulting removal of generic bits for handling
the PHY.
4. Proper reserving of device resources and using ioremap()ped handles
to access MAC
On Wed, Oct 04, 2006 at 01:57:38PM -0400, Dan Williams wrote:
On Wed, 2006-10-04 at 16:19 +0200, Johannes Berg wrote:
On Wed, 2006-10-04 at 09:41 +0200, Johannes Berg wrote:
Should cfg80211 do the chore of keeping track of the whole scan results?
On the other hand, that doesn't seem to be
Hi John,
Based on the feedback, I formally request you to back out all
of WE-21 from 2.6.19. Rationale : it's probably too early. You can
keep it for a later date if you wish.
Regards,
Jean
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
From: Randy Dunlap [EMAIL PROTECTED]
Fix kernel-doc warning in include/net/sock.h:
Warning(/var/linsrc/linux-2619-rc1-pv//include/net/sock.h:894): No description
found for parameter 'rcu'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
include/net/sock.h |3 +--
1 files changed, 1
Olivier Crameri wrote:
Same thing but with the patch this time.
Since the VLAN device's features may also change in the handler,
shouldn't we check and generate a feature-change
event for the VLAN device(s) as well?
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc
This is a set of changes to remove unneeded type definitions that only
make code less obvious. It applies to all enum and struct types as
well as to potentially unsafe use of them within sizeof().
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
This applies on top of 4/6. Please
The pointer obtained by kmalloc() is treated with ALIGN() before passing
it to kfree(). This may or may not cause problems depending on the
minimum alignment enforced by kmalloc() and is ugly anyway. This change
records the original pointer returned by kmalloc() so that kfree() may
safely
On Thu, Oct 05, 2006 at 09:13:53AM -0400, Stuffed Crust wrote:
(Leave out the RSNIE, AuthType and KeyMgmt stuff; while they're
used in the actual key negotiation/derivation, they're separate
problems and have no bearing on the crypto layer. From the driver's
perspective the RSNIE is
On Wed, Oct 04, 2006 23:43 you wrote:
On Wed, Oct 04, 2006 at 04:12:26PM +0200, [EMAIL PROTECTED] wrote:
the AP code never worked. And the hostapd-ioctl interface was designed
for prism2/2.5/3 cards, but not for fullmac prism54.
What do you mean by never working? I have seen fullmac Prism54
Add support for dumping the registers in the deprecated
sk98lin driver. This is allows for easier comparison with
settings in new skge driver.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- linux-2.6.orig/drivers/net/sk98lin/skethtool.c
+++ linux-2.6/drivers/net/sk98lin/skethtool.c
@@
Add MII ioctl support to the deprecated sk98lin driver.
This allows comparison with skge driver's PHY settings.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- linux-2.6.orig/drivers/net/sk98lin/skge.c
+++ linux-2.6/drivers/net/sk98lin/skge.c
@@ -113,6 +113,7 @@
#include
I applied a combined patch to fix all the headers to iproute2 (for the future
2.6.19 based release).
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Or Gerlitz [EMAIL PROTECTED] wrote:
Jay Vosburgh wrote:
[...]
Yes. Part of the difficulty is that the changes to the
initscripts and sysconfig packages won't be compatible with versions of
bonding prior to the bonding kernel changes (because older versions of
bonding will refuse to add
Adding VIOC device driver, support files: Documenation, makefiles etc.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/Documentation/networking/vioc.txt
linux-2.6.17.vioc/Documentation/networking/vioc.txt
--- linux-2.6.17/Documentation/networking/vioc.txt 1969-12-31
Adding VIOC device driver. Ethtool interface.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_ethtool.c
linux-2.6.17.vioc/drivers/net/vioc/vioc_ethtool.c
--- linux-2.6.17/drivers/net/vioc/vioc_ethtool.c1969-12-31
16:00:00.0 -0800
Adding VIOC device driver. Interrupt handler.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_irq.c
linux-2.6.17.vioc/drivers/net/vioc/vioc_irq.c
--- linux-2.6.17/drivers/net/vioc/vioc_irq.c1969-12-31 16:00:00.0
-0800
+++
Adding VIOC device driver. VIOC hardware APIs.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_api.c
linux-2.6.17.vioc/drivers/net/vioc/vioc_api.c
--- linux-2.6.17/drivers/net/vioc/vioc_api.c1969-12-31 16:00:00.0
-0800
+++
Adding VIOC device driver. Device driver initialization/termination.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_vnic.h
linux-2.6.17.vioc/drivers/net/vioc/vioc_vnic.h
--- linux-2.6.17/drivers/net/vioc/vioc_vnic.h 1969-12-31 16:00:00.0
Adding VIOC device driver. Out-of-band provisioning protocol support code.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/f7/spp.h
linux-2.6.17.vioc/drivers/net/vioc/f7/spp.h
--- linux-2.6.17/drivers/net/vioc/f7/spp.h 1969-12-31 16:00:00.0
The following patch series introduces the VIOC Device Driver, that
provides a network device inerface
to the internal fabric interconnected network used on servers designed and
built by Fabric 7 Systems.
--
Misha Tomushev
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
Adding VIOC device driver. Packet receive code.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_receive.c
linux-2.6.17.vioc/drivers/net/vioc/vioc_receive.c
--- linux-2.6.17/drivers/net/vioc/vioc_receive.c1969-12-31
16:00:00.0 -0800
Adding VIOC device driver. Packet transmit code.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_transmit.c
linux-2.6.17.vioc/drivers/net/vioc/vioc_transmit.c
--- linux-2.6.17/drivers/net/vioc/vioc_transmit.c 1969-12-31
16:00:00.0
Adding VIOC device driver. Device driver provisioning settings.
Signed-off-by: Misha Tomushev [EMAIL PROTECTED]
diff -uprN linux-2.6.17/drivers/net/vioc/vioc_provision.c
linux-2.6.17.vioc/drivers/net/vioc/vioc_provision.c
--- linux-2.6.17/drivers/net/vioc/vioc_provision.c 1969-12-31
On Thu, 5 Oct 2006, Joerg Roedel wrote:
Is there a reason why the tunnel driver for IPv6-in-IPv4 is currently
compiled into the ipv6 module? This driver is only needed in gateways
between different IPv6 networks. On all other hosts with ipv6 enabled it
is not required. To have this driver in
In article [EMAIL PROTECTED] (at Thu, 5 Oct 2006 11:49:38 -0400 (EDT)), James
Morris [EMAIL PROTECTED] says:
On Thu, 5 Oct 2006, Joerg Roedel wrote:
Is there a reason why the tunnel driver for IPv6-in-IPv4 is currently
compiled into the ipv6 module? This driver is only needed in gateways
On Thu, 2006-10-05 at 17:40 +0200, Andi Kleen wrote:
Please don't snip the Code: line. It is fairly important.
Sorry about that. The remote console I was using appears to overwrite
some text after I force the reboot. Here's a clean one.
global
Unable to handle kernel NULL
On Thursday 05 October 2006 19:57, Steve Fox wrote:
On Thu, 2006-10-05 at 17:40 +0200, Andi Kleen wrote:
Please don't snip the Code: line. It is fairly important.
Sorry about that. The remote console I was using appears to overwrite
some text after I force the reboot. Here's a clean one.
On Thu, 2006-10-05 at 20:27 +0200, Andi Kleen wrote:
I guess we need to track when it gets corrupted. Can you send the full
boot log with this patch applied?
Here she blows!
root (hd0,0)
Filesystem type is reiserfs, partition type 0x83
kernel /boot/vmlinuz-autobench root=/dev/sda1 vga=791
On Thu, Oct 05, 2006 at 08:27:02PM +0200, Andi Kleen wrote:
On Thursday 05 October 2006 19:57, Steve Fox wrote:
On Thu, 2006-10-05 at 17:40 +0200, Andi Kleen wrote:
Please don't snip the Code: line. It is fairly important.
Sorry about that. The remote console I was using appears to
On Thursday 05 October 2006 20:51, Steve Fox wrote:
On Thu, 2006-10-05 at 20:27 +0200, Andi Kleen wrote:
I guess we need to track when it gets corrupted. Can you send the full
boot log with this patch applied?
Here she blows!
Can you please try it again with this patch to narrow it down
On Thursday 05 October 2006 20:52, Vivek Goyal wrote:
On Thu, Oct 05, 2006 at 08:27:02PM +0200, Andi Kleen wrote:
On Thursday 05 October 2006 19:57, Steve Fox wrote:
On Thu, 2006-10-05 at 17:40 +0200, Andi Kleen wrote:
Please don't snip the Code: line. It is fairly important.
Hi John,
I updated the for-linville branch of my tree with one important
bugfix and a small cleanup.
In case you didn't pull, yet, this will pull all changes of my previous
pull request plus the following two.
bcm43xx-d80211: Wait for the firmware to respond, before we read revision codes.
On Thu, 2006-10-05 at 21:08 +0200, Andi Kleen wrote:
Mel might want to take a look (and perhaps
also cut down a little on the ugly printks ...)
I tested a patch from Mel which backs out the arch independent zone
sizing and got the same results (to my inexperienced eye). I've sent him
the boot
This version takes into account David Miller's comments
regarding treatment of security layer errors in the case
of socket policies. Specifically, these errors will be
treated like how these kind of errors are treated for
the main/sub policies, which is to return a full lookup
failure.
This treats the security errors encountered in the case of
socket policy matching, the same as how these are treated in
the case of main/sub policies, which is to return a full lookup
failure.
Signed-off-by: Venkat Yekkirala [EMAIL PROTECTED]
---
net/xfrm/xfrm_policy.c | 26
Currently when an IPSec policy rule doesn't specify a security
context, it is assumed to be unlabeled by SELinux, and so
the IPSec policy rule fails to match to a flow that it would
otherwise match to, unless one has explicitly added an SELinux
policy rule allowing the flow to polmatch to the
From: James Morris [EMAIL PROTECTED]
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
On Thu, 14 Sep 2006 10:29:30 +0200 Jarek Poplawski wrote:
On Thu, Sep 14, 2006 at 10:25:32AM +0200, Jarek Poplawski wrote:
...
Attachments are discouraged, but some corporate mail systems
provide no other way to send patches.
I thought they didn't read this but now I understand for
On Thu, 5 Oct 2006, Venkat Yekkirala wrote:
- if (xfrm_policy_match(pol, fl, type, family, dir)) {
+ err = xfrm_policy_match(pol, fl, type, family, dir);
+ if (err) {
+ if (err == -ESRCH)
+ continue;
+
From: James Morris [EMAIL PROTECTED]
Date: Thu, 5 Oct 2006 16:58:31 -0400 (EDT)
On Tue, 3 Oct 2006, David Miller wrote:
The socket policy behavior deserves some scrutiny. I say this because
if a matching socket policy is avoided due to security layer error,
this could potentially make
From: Venkat Yekkirala [EMAIL PROTECTED]
Date: Thu, 05 Oct 2006 15:42:13 -0500
This version takes into account David Miller's comments
regarding treatment of security layer errors in the case
of socket policies. Specifically, these errors will be
treated like how these kind of errors are
On Tue, 3 Oct 2006, David Miller wrote:
The socket policy behavior deserves some scrutiny. I say this because
if a matching socket policy is avoided due to security layer error,
this could potentially make key manager problems very hard to
diagnose.
In this case, AVC denial messages would
On Thu, Oct 05, 2006 at 09:31:13AM -0700, Jean Tourrilhes wrote:
Based on the feedback, I formally request you to back out all
of WE-21 from 2.6.19. Rationale : it's probably too early. You can
keep it for a later date if you wish.
Jean,
What about a patch like the one below? It tries
From: James Morris [EMAIL PROTECTED]
Date: Thu, 5 Oct 2006 16:54:38 -0400 (EDT)
#ifdef CONFIG_XFRM_SUB_POLICY
pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_SUB, fl, family, dir);
- if (pol)
+ if (IS_ERR(pol)) {
+ err = PTR_ERR(pol);
+ pol = NULL;
+
This version takes into account David Miller's comments
regarding treatment of security layer errors in the case
of socket policies. Specifically, these errors will be
treated like how these kind of errors are treated for
the main/sub policies, which is to return a full lookup
failure.
This version takes into account David Miller's comments
regarding treatment of security layer errors in the case
of socket policies. Specifically, these errors will be
treated like how these kind of errors are treated for
the main/sub policies, which is to return a full lookup
Hello, Linux Kernel:
For a project I will work on for mobile, I am looking
into the IP stacks on Linux.
I have a few questions to bother you:
1. is socket.c the file handling the socket
interface?
2. which function is for opening a socket?
It looks like sock_map_fd() is the one for
- if (xfrm_policy_match(pol, fl, type, family, dir)) {
+ err = xfrm_policy_match(pol, fl, type, family, dir);
+ if (err) {
+ if (err == -ESRCH)
+ continue;
+ else {
+
On Thu, Oct 05, 2006 at 04:49:54PM -0400, John W. Linville wrote:
On Thu, Oct 05, 2006 at 09:31:13AM -0700, Jean Tourrilhes wrote:
Based on the feedback, I formally request you to back out all
of WE-21 from 2.6.19. Rationale : it's probably too early. You can
keep it for a later date
From: James Morris [EMAIL PROTECTED]
Date: Thu, 5 Oct 2006 16:54:38 -0400 (EDT)
#ifdef CONFIG_XFRM_SUB_POLICY
pol = xfrm_policy_lookup_bytype(XFRM_POLICY_TYPE_SUB,
fl, family, dir);
- if (pol)
+ if (IS_ERR(pol)) {
+ err = PTR_ERR(pol);
+ pol = NULL;
+
From: Venkat Yekkirala [EMAIL PROTECTED]
Date: Thu, 5 Oct 2006 17:07:59 -0400
My apologies. The second one is also numbered 1, but has the
following distinct subject line:
[PATCH 1/3] Fix for IPsec leakage with SELinux enabled - V.03: Fix xfrm code
I definitely deleted one of them, since I
From: Venkat Yekkirala [EMAIL PROTECTED]
Date: Thu, 5 Oct 2006 17:27:03 -0400
May be James can help me understand this; when exactly would a sub-policy
be noticed here? What does put the whole thing together mean?
The code in xfrm_lookup() which does a flow cache lookup,
and then if it finds
On Thu, Oct 05, 2006 at 04:49:54PM -0400, John W. Linville wrote:
What about a patch like the one below? It tries to detect WE-20
ESSID/NICKN accesses and adjust them to WE-21 style. What am
I missing?
diff --git a/net/core/wireless.c b/net/core/wireless.c
+ else if
On Thu, Oct 05, 2006 at 03:12:46PM -0700, Jean Tourrilhes wrote:
+ if((cmd == SIOCSIWESSID) ||
+(cmd == SIOCSIWNICKN)) {
+ if(extra[iwr-u.data.length - 1] == '\0') {
Can't iwr-u.data.length be zero here (with WE-21)? Maybe
On Thu, Oct 05, 2006 at 04:49:54PM -0400, John W. Linville wrote:
On Thu, Oct 05, 2006 at 09:31:13AM -0700, Jean Tourrilhes wrote:
Based on the feedback, I formally request you to back out all
of WE-21 from 2.6.19. Rationale : it's probably too early. You can
keep it for a later date
On Thu, Oct 05, 2006 at 03:15:50PM -0700, Jouni Malinen wrote:
On Thu, Oct 05, 2006 at 03:12:46PM -0700, Jean Tourrilhes wrote:
+ if((cmd == SIOCSIWESSID) ||
+ (cmd == SIOCSIWNICKN)) {
+ if(extra[iwr-u.data.length - 1] ==
1 - 100 of 127 matches
Mail list logo
