Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
On Tue, Oct 03, 2006 at 03:49:35PM +1000, Herbert Xu wrote:
>
> OK, I think I've got the right bug this time.
Here is the patch for the other bug that I found along the way:
[UDP6]: Fix MSG_PROBE crash
UDP tracks corking status through the pending variable. The
IP layer also tracks it through the socket write queue. It
is possible for the two to get out of sync when MSG_PROBE is
used.
This patch changes UDP to check the write queue to ensure
that the two stay in sync.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -675,6 +675,8 @@ do_append_data:
udp_flush_pending_frames(sk);
else if (!corkreq)
err = udp_push_pending_frames(sk, up);
+ else if (unlikely(skb_queue_empty(&sk->sk_write_queue)))
+ up->pending = 0;
release_sock(sk);
out:
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -770,6 +770,8 @@ do_append_data:
udp_v6_flush_pending_frames(sk);
else if (!corkreq)
err = udp_v6_push_pending_frames(sk, up);
+ else if (unlikely(skb_queue_empty(&sk->sk_write_queue)))
+ up->pending = 0;
if (dst) {
if (connected) {
-
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
Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
On Thu, Sep 28, 2006 at 10:40:18AM +0200, cagri coltekin wrote:
>
> No. Bug is the first after boot:
OK, I think I've got the right bug this time.
[UDP6]: Fix flowi clobbering
The udp6_sendmsg function uses a shared buffer to store the
flow without taking any locks. This leads to races with SMP.
This patch moves the flowi object onto the stack.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
This bug is pretty old so we need the fix for 2.6.18 too.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -546,7 +546,7 @@ static int udpv6_sendmsg(struct kiocb *i
struct in6_addr *daddr, *final_p = NULL, final;
struct ipv6_txoptions *opt = NULL;
struct ip6_flowlabel *flowlabel = NULL;
- struct flowi *fl = &inet->cork.fl;
+ struct flowi fl;
struct dst_entry *dst;
int addr_len = msg->msg_namelen;
int ulen = len;
@@ -626,19 +626,19 @@ do_udp_sendmsg:
}
ulen += sizeof(struct udphdr);
- memset(fl, 0, sizeof(*fl));
+ memset(&fl, 0, sizeof(fl));
if (sin6) {
if (sin6->sin6_port == 0)
return -EINVAL;
- fl->fl_ip_dport = sin6->sin6_port;
+ fl.fl_ip_dport = sin6->sin6_port;
daddr = &sin6->sin6_addr;
if (np->sndflow) {
- fl->fl6_flowlabel =
sin6->sin6_flowinfo&IPV6_FLOWINFO_MASK;
- if (fl->fl6_flowlabel&IPV6_FLOWLABEL_MASK) {
- flowlabel = fl6_sock_lookup(sk,
fl->fl6_flowlabel);
+ fl.fl6_flowlabel =
sin6->sin6_flowinfo&IPV6_FLOWINFO_MASK;
+ if (fl.fl6_flowlabel&IPV6_FLOWLABEL_MASK) {
+ flowlabel = fl6_sock_lookup(sk,
fl.fl6_flowlabel);
if (flowlabel == NULL)
return -EINVAL;
daddr = &flowlabel->dst;
@@ -656,32 +656,32 @@ do_udp_sendmsg:
if (addr_len >= sizeof(struct sockaddr_in6) &&
sin6->sin6_scope_id &&
ipv6_addr_type(daddr)&IPV6_ADDR_LINKLOCAL)
- fl->oif = sin6->sin6_scope_id;
+ fl.oif = sin6->sin6_scope_id;
} else {
if (sk->sk_state != TCP_ESTABLISHED)
return -EDESTADDRREQ;
- fl->fl_ip_dport = inet->dport;
+ fl.fl_ip_dport = inet->dport;
daddr = &np->daddr;
- fl->fl6_flowlabel = np->flow_label;
+ fl.fl6_flowlabel = np->flow_label;
connected = 1;
}
- if (!fl->oif)
- fl->oif = sk->sk_bound_dev_if;
+ if (!fl.oif)
+ fl.oif = sk->sk_bound_dev_if;
if (msg->msg_controllen) {
opt = &opt_space;
memset(opt, 0, sizeof(struct ipv6_txoptions));
opt->tot_len = sizeof(*opt);
- err = datagram_send_ctl(msg, fl, opt, &hlimit, &tclass);
+ err = datagram_send_ctl(msg, &fl, opt, &hlimit, &tclass);
if (err < 0) {
fl6_sock_release(flowlabel);
return err;
}
- if ((fl->fl6_flowlabel&IPV6_FLOWLABEL_MASK) && !flowlabel) {
- flowlabel = fl6_sock_lookup(sk, fl->fl6_flowlabel);
+ if ((fl.fl6_flowlabel&IPV6_FLOWLABEL_MASK) && !flowlabel) {
+ flowlabel = fl6_sock_lookup(sk, fl.fl6_flowlabel);
if (flowlabel == NULL)
return -EINVAL;
}
@@ -695,39 +695,39 @@ do_udp_sendmsg:
opt = fl6_merge_options(&opt_space, flowlabel, opt);
opt = ipv6_fixup_options(&opt_space, opt);
- fl->proto = IPPROTO_UDP;
- ipv6_addr_copy(&fl->fl6_dst, daddr);
- if (ipv6_addr_any(&fl->fl6_src) && !ipv6_addr_any(&np->saddr))
- ipv6_addr_copy(&fl->fl6_src, &np->saddr);
- fl->fl_ip_sport = inet->sport;
+ fl.proto = IPPROTO_UDP;
+ ipv6_addr_copy(&fl.fl6_dst, daddr);
+ if (ipv6_addr_any(&fl.fl6_src) && !ipv6_addr_any(&np->saddr))
+ ipv6_addr_copy(&fl.fl6_src, &np->saddr);
+ fl.fl_ip_sport = inet->sport;
/* merge ip6_build_xmit from ip6_output */
if (opt && opt->srcrt) {
struct rt0_hdr *rt0 = (struct rt0_hdr *) opt->srcrt;
- ipv6_addr_copy(&final, &fl->fl6_dst);
- ipv6_addr_copy(&fl->fl6_dst, rt0->addr);
+ ipv6_addr_copy(&final, &fl.fl6_dst);
+ ipv6_addr_copy(&fl.fl6_dst, rt0->addr);
final_p
[PATCH] bcm43xx-softmac: Fix system hang for x86-64 with >1GB RAM
The bcm43xx-softmac software currently fails when running on x86_64 systems
with more than 1GB RAM and one of the card variants with 30-bit DMA addressing.
This patch uses the address extension bits in the hardware to set the correct
DMA mask for the specific card in use.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
Please apply this to wireless-2.6. It is a fix for a current bug,
and should be sent upstream for inclusion in 2.6.19. The patch has been
circulated on the bcm43xx mailing list for a couple of weeks, and has
fixed every case where there was a problem with more than 1 GB RAM.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
@@ -314,6 +314,23 @@ int bcm43xx_dma_tx(struct bcm43xx_privat
struct ieee80211_txb *txb);
void bcm43xx_dma_rx(struct bcm43xx_dmaring *ring);
+/* Helper function that returns the dma mask for this device. */
+static inline
+u64 bcm43xx_get_supported_dma_mask(struct bcm43xx_private *bcm)
+{
+ int dma64 = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATEHIGH) &
+ BCM43xx_SBTMSTATEHIGH_DMA64BIT;
+ u16 mmio_base = bcm43xx_dmacontroller_base(dma64, 0);
+ u32 mask = BCM43xx_DMA32_TXADDREXT_MASK;
+
+ if (dma64)
+ return DMA_64BIT_MASK;
+ bcm43xx_write32(bcm, mmio_base + BCM43xx_DMA32_TXCTL, mask);
+ if (bcm43xx_read32(bcm, mmio_base + BCM43xx_DMA32_TXCTL) & mask)
+ return DMA_32BIT_MASK;
+ return DMA_30BIT_MASK;
+}
+
#else /* CONFIG_BCM43XX_DMA */
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2925,10 +2925,13 @@ static int bcm43xx_wireless_core_init(st
bcm43xx_write16(bcm, 0x043C, 0x000C);
if (active_wlcore) {
- if (bcm43xx_using_pio(bcm))
+ if (bcm43xx_using_pio(bcm)) {
err = bcm43xx_pio_init(bcm);
- else
+ } else {
err = bcm43xx_dma_init(bcm);
+ if (err == -ENOSYS)
+ err = bcm43xx_pio_init(bcm);
+ }
if (err)
goto err_chip_cleanup;
}
@@ -3994,8 +3997,6 @@ static int bcm43xx_init_private(struct b
struct net_device *net_dev,
struct pci_dev *pci_dev)
{
- int err;
-
bcm43xx_set_status(bcm, BCM43xx_STAT_UNINIT);
bcm->ieee = netdev_priv(net_dev);
bcm->softmac = ieee80211_priv(net_dev);
@@ -4013,22 +4014,8 @@ static int bcm43xx_init_private(struct b
(void (*)(unsigned long))bcm43xx_interrupt_tasklet,
(unsigned long)bcm);
tasklet_disable_nosync(&bcm->isr_tasklet);
- if (modparam_pio) {
+ if (modparam_pio)
bcm->__using_pio = 1;
- } else {
- err = pci_set_dma_mask(pci_dev, DMA_30BIT_MASK);
- err |= pci_set_consistent_dma_mask(pci_dev, DMA_30BIT_MASK);
- if (err) {
-#ifdef CONFIG_BCM43XX_PIO
- printk(KERN_WARNING PFX "DMA not supported. Falling
back to PIO.\n");
- bcm->__using_pio = 1;
-#else
- printk(KERN_ERR PFX "FATAL: DMA not supported and PIO
not configured. "
- "Recompile the driver with PIO
support, please.\n");
- return -ENODEV;
-#endif /* CONFIG_BCM43XX_PIO */
- }
- }
bcm->rts_threshold = BCM43xx_DEFAULT_RTS_THRESHOLD;
/* default to sw encryption for now */
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -705,11 +705,30 @@ int bcm43xx_dma_init(struct bcm43xx_priv
struct bcm43xx_dmaring *ring;
int err = -ENOMEM;
int dma64 = 0;
- u32 sbtmstatehi;
+ u64 mask = bcm43xx_get_supported_dma_mask(bcm);
+ int nobits;
- sbtmstatehi = bcm43xx_read32(bcm, BCM43xx_CIR_SBTMSTATEHIGH);
- if (sbtmstatehi & BCM43xx_SBTMSTATEHIGH_DMA64BIT)
+ if (mask == DMA_64BIT_MASK) {
dma64 = 1;
+ nobits = 64;
+ } else if (mask == DMA_32BIT_MASK)
+ nobits = 32;
+ else
+ nobits = 30;
+ err = pci_set_dma_mask(bcm->pci_dev, mask);
+ err |= pci_set_consistent_dma_mask(bcm->pci_dev, mask);
Re: Please pull bcm43xx-d80211 bugfixes and new features
Michael Buesch wrote: Hi John, Please pull from my tree git pull http://bu3sch.de/git/wireless-dev.git for-linville This will pull various bugfixes and feature improvements. Most noteably it will pull a bugfix for a crash introduced by an earlier patch to d80211 which changed RX status information handling. The new features include support for the new v4 firmware. I also did my homework to get better support for OpenWRT devices in ssb. The list of pulled changesets is: Michael Buesch: ssb: Abstract bus accesses. bcm43xx-d80211: convert to ssb abstract bus access API bcm43xx-d80211: Don't crash if we use v4 firmware. bcm43xx-d80211: Always make fwpostfix option available. bcm43xx-d80211: Firmware revision/patchlevel detection. bcm43xx-d80211: Add support for v4 firmware. bcm43xx-d80211: add SHM constants bcm43xx-d80211: Don't use low level netif and ieee80211_netif_oper functions. bcm43xx-d80211: DMA-mask fixes. bcm43xx-d80211: Remove some BCM947XX ifdefs, Merge branch 'master' of git://kernel.org/.../linville/wireless-dev bcm43xx-d80211: Assign all fields in the RX status report. bcm43xx-d80211: Set channel cookie to prevent ghost packets. bcm43xx-d80211: Prevent crash by setting active wlcore to NULL on wlcore-select failure. The diffstat is: drivers/misc/ssb.c | 431 ++- drivers/net/wireless/d80211/bcm43xx/bcm43xx.h | 143 +++ .../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c | 295 +++- .../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.h | 35 - drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c | 149 ++-- drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.h | 18 drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c | 16 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 820 +--- drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c | 76 +- drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c | 104 +-- drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.h | 12 .../net/wireless/d80211/bcm43xx/bcm43xx_power.c| 125 +--- .../net/wireless/d80211/bcm43xx/bcm43xx_radio.c| 143 ++-- .../net/wireless/d80211/bcm43xx/bcm43xx_radio.h|1 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c | 309 +++- drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.h | 247 +- include/linux/ssb.h| 71 +- 17 files changed, 1681 insertions(+), 1314 deletions(-) Michael, There is something wrong with wireless-dev after I pulled your changes. The logs are: kernel: ssb: Core 0 found: cc 0800, rev 02, vendor 4243 kernel: ssb: Core 1 found: cc 0812, rev 04, vendor 4243 kernel: ssb: Core 2 found: cc 080D, rev 01, vendor 4243 kernel: ssb: Core 3 found: cc 0807, rev 01, vendor 4243 kernel: ssb: Core 4 found: cc 0804, rev 07, vendor 4243 kernel: ssb: Core 5 found: cc 0812, rev 04, vendor 4243 kernel: bcm43xx_d80211: Ignoring additional 802.11 core. kernel: bcm43xx_d80211: Broadcom 4306 WLAN found kernel: ssb: Switching to core 4 kernel: bcm43xx_d80211: PHY connected kernel: ssb: Switching to core 1 kernel: bcm43xx_d80211: Detected PHY: Version: 1, Type 2, Revision 1 kernel: bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2) kernel: bcm43xx_d80211: Radio turned off kernel: bcm43xx_d80211: Radio turned off kernel: wmaster0: Selected rate control algorithm 'simple' kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00 :06:25:40:6f:03) kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: PHY disconnected kernel: bcm43xx_d80211: PHY connected kernel: bcm43xx_d80211: firmware revision FE84, patchlevel 90B4, date 2000-14-248 29:46:18 kernel: ssb: Switching to core 0 kernel: ssb: Switching to core 1 kernel: bcm43xx_d80211: Radio turned on kernel: bcm43xx_d80211: Chip initialized kernel: bcm43xx_d80211: 30-bit DMA initialized kernel: bcm43xx_d80211: TODO: Incomplete code in keymac_write() at drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c:871 . kernel: bcm43xx_d80211: Keys cleared kernel: bcm43xx_d80211: Selected 802.11 core (phytype 2) kernel: wmaster0: Does not support passive scan, disabled kernel: wlan1: starting scan kernel: HW CONFIG: channel=1 freq=2412 phymode=3 kernel: HW CONFIG: channel=2 freq=2417 phymode=3 kernel: bcm43xx_d80211: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR kernel: bcm43xx_d80211: ASSERTION FAILED (0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c:1020:parse_cookie() kernel: bcm43xx_d80211: ASSERTION FAILED (ring && *slot >= 0 && *slot < ring->nr_slots) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c:1023:parse_cookie() kernel: bcm43xx_d80211: FATAL ERROR: BCM43xx_IRQ_XMIT_ERROR kernel: bcm43xx_d80211: ASSERTION FAILED (0) at: drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c:1020:parse_cookie() kernel: bcm43xx_d80211: ASSERTION FAILED (ring && *slot >= 0 && *slot < ring->nr_ slots) at: drivers/ne
[PATCH][XFRM] Fixes for net-2.6
Hello,
I have two patches to fix XFRM. Can you check and apply them?
HEADLINES
-
[XFRM] POLICY: Fix per-direction policy counter after flushing.
[XFRM] STATE: Use destination address for src hash.
DIFFSTAT
net/xfrm/xfrm_hash.h |7 ---
net/xfrm/xfrm_policy.c |4 ++--
net/xfrm/xfrm_state.c | 16 +---
3 files changed, 15 insertions(+), 12 deletions(-)
CHANGESETS
--
commit 90c1f7d3e1019b2885844b03088588268e38cec5
Author: Masahide NAKAMURA <[EMAIL PROTECTED]>
Date: Sun Sep 24 14:46:59 2006 +0900
[XFRM] POLICY: Fix per-direction policy counter after flushing.
Currently when xfrm_policy_flush() is called per-direction
policy counter is cleared. However flusing policy is performed
for each type (i.e. main or sub) then it is not always true
to make the counter zero.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index b6e2e79..048e248 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -787,6 +787,7 @@ void xfrm_policy_flush(u8 type)
continue;
hlist_del(&pol->bydst);
hlist_del(&pol->byidx);
+ xfrm_policy_count[dir]--;
write_unlock_bh(&xfrm_policy_lock);
xfrm_policy_kill(pol);
@@ -804,6 +805,7 @@ void xfrm_policy_flush(u8 type)
continue;
hlist_del(&pol->bydst);
hlist_del(&pol->byidx);
+ xfrm_policy_count[dir]--;
write_unlock_bh(&xfrm_policy_lock);
xfrm_policy_kill(pol);
@@ -812,8 +814,6 @@ void xfrm_policy_flush(u8 type)
goto again2;
}
}
-
- xfrm_policy_count[dir] = 0;
}
atomic_inc(&flow_cache_genid);
write_unlock_bh(&xfrm_policy_lock);
---
commit e517421855d241f0b85a186b25e85d00eafa129f
Author: Masahide NAKAMURA <[EMAIL PROTECTED]>
Date: Sat Sep 23 16:41:34 2006 +0900
[XFRM] STATE: Use destination address for src hash.
Src hash is introduced for Mobile IPv6 route optimization usage.
On current kenrel code it is calculated with source address only.
It results we uses the same hash value for outbound state (when
the node has only one address for Mobile IPv6).
This patch use also destination address as peer information for
src hash to be dispersed.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index 6ac4e4f..d401dc8 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -41,17 +41,18 @@ static inline unsigned int __xfrm_dst_ha
return (h ^ (h >> 16)) & hmask;
}
-static inline unsigned __xfrm_src_hash(xfrm_address_t *saddr,
+static inline unsigned __xfrm_src_hash(xfrm_address_t *daddr,
+ xfrm_address_t *saddr,
unsigned short family,
unsigned int hmask)
{
unsigned int h = family;
switch (family) {
case AF_INET:
- h ^= __xfrm4_addr_hash(saddr);
+ h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
break;
case AF_INET6:
- h ^= __xfrm6_addr_hash(saddr);
+ h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
break;
};
return (h ^ (h >> 16)) & hmask;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index f927b73..39b8bf3 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -63,10 +63,11 @@ static inline unsigned int xfrm_dst_hash
return __xfrm_dst_hash(daddr, saddr, reqid, family, xfrm_state_hmask);
}
-static inline unsigned int xfrm_src_hash(xfrm_address_t *addr,
+static inline unsigned int xfrm_src_hash(xfrm_address_t *daddr,
+xfrm_address_t *saddr,
unsigned short family)
{
- return __xfrm_src_hash(addr, family, xfrm_state_hmask);
+ return __xfrm_src_hash(daddr, saddr, family, xfrm_state_hmask);
}
static inline unsigned int
@@ -92,7 +93,8 @@ static void xfrm_hash_transfer(struct hl
nhashmask);
hlist_add_head(&x->bydst, ndsttable+h);
- h = __xfrm_src_hash(&x->props.saddr, x->props.family,
+ h = __xfrm_src_hash(&x->id.daddr, &x->props.saddr,
+ x->props.family,
nhashmask);
hlist_add_head(&x->bysrc, nsrctable+h);
@@ -458,7 +460,7 @@ static struct xfrm_state *__xfrm_state_l
static struct xfrm_state *__xfrm_state_lookup_byaddr(xfrm_address_t *daddr,
x
[PATCH] hp100: fix conditional compilation mess
The previous hp100 changeset attempted to kill warnings, but was only
tested on !CONFIG_ISA platforms. The correct conditional compilation
setup involves tested CONFIG_ISA rather than just MODULE.
Fixes link on CONFIG_ISA platforms (i386) in current -git.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/net/Space.c |2 +-
drivers/net/hp100.c |8 +---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Space.c b/drivers/net/Space.c
index 9953201..a67f5ef 100644
--- a/drivers/net/Space.c
+++ b/drivers/net/Space.c
@@ -165,7 +165,7 @@ #endif
* look for EISA/PCI/MCA cards in addition to ISA cards).
*/
static struct devprobe2 isa_probes[] __initdata = {
-#ifdef CONFIG_HP100/* ISA, EISA & PCI */
+#if defined(CONFIG_HP100) && defined(CONFIG_ISA) /* ISA, EISA */
{hp100_probe, 0},
#endif
#ifdef CONFIG_3C515
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
index 561db44..ae8ad4f 100644
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -188,7 +188,7 @@ struct hp100_private {
/*
* variables
*/
-#ifndef MODULE
+#ifdef CONFIG_ISA
static const char *hp100_isa_tbl[] = {
"HWPF150", /* HP J2573 rev A */
"HWP1950", /* HP J2573 */
@@ -335,7 +335,7 @@ static __devinit const char *hp100_read_
return str;
}
-#ifndef MODULE
+#ifdef CONFIG_ISA
static __init int hp100_isa_probe1(struct net_device *dev, int ioaddr)
{
const char *sig;
@@ -393,7 +393,9 @@ static int __init hp100_isa_probe(struc
}
return err;
}
+#endif /* CONFIG_ISA */
+#if !defined(MODULE) && defined(CONFIG_ISA)
struct net_device * __init hp100_probe(int unit)
{
struct net_device *dev = alloc_etherdev(sizeof(struct hp100_private));
@@ -423,7 +425,7 @@ #endif
free_netdev(dev);
return ERR_PTR(err);
}
-#endif
+#endif /* !MODULE && CONFIG_ISA */
static int __devinit hp100_probe1(struct net_device *dev, int ioaddr,
u_char bus, struct pci_dev *pci_dev)
-
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
[PATCH 2.6] Fix WE-21 Orinoco overflow issue...
Hi John,
This patch fixes the Orinoco driver overflow issue with
WE-21. This was discussed on the mailing list, the reporter confirmed
that it fixes the issue and Andrew has already added this patch in
tree.
Regards,
Jean
diff -u -p linux/drivers/net/wireless/orinoco.j1.c
linux/drivers/net/wireless/orinoco.c
--- linux/drivers/net/wireless/orinoco.j1.c 2006-10-02 10:15:41.0
-0700
+++ linux/drivers/net/wireless/orinoco.c2006-10-02 10:39:20.0
-0700
@@ -2456,6 +2456,7 @@ void free_orinocodev(struct net_device *
/* Wireless extensions */
//
+/* Return : < 0 -> error code ; >= 0 -> length */
static int orinoco_hw_get_essid(struct orinoco_private *priv, int *active,
char buf[IW_ESSID_MAX_SIZE+1])
{
@@ -2500,9 +2501,9 @@ static int orinoco_hw_get_essid(struct o
len = le16_to_cpu(essidbuf.len);
BUG_ON(len > IW_ESSID_MAX_SIZE);
- memset(buf, 0, IW_ESSID_MAX_SIZE+1);
+ memset(buf, 0, IW_ESSID_MAX_SIZE);
memcpy(buf, p, len);
- buf[len] = '\0';
+ err = len;
fail_unlock:
orinoco_unlock(priv, &flags);
@@ -3026,17 +3027,18 @@ static int orinoco_ioctl_getessid(struct
if (netif_running(dev)) {
err = orinoco_hw_get_essid(priv, &active, essidbuf);
- if (err)
+ if (err < 0)
return err;
+ erq->length = err;
} else {
if (orinoco_lock(priv, &flags) != 0)
return -EBUSY;
- memcpy(essidbuf, priv->desired_essid, IW_ESSID_MAX_SIZE + 1);
+ memcpy(essidbuf, priv->desired_essid, IW_ESSID_MAX_SIZE);
+ erq->length = strlen(priv->desired_essid);
orinoco_unlock(priv, &flags);
}
erq->flags = 1;
- erq->length = strlen(essidbuf);
return 0;
}
@@ -3074,10 +3076,10 @@ static int orinoco_ioctl_getnick(struct
if (orinoco_lock(priv, &flags) != 0)
return -EBUSY;
- memcpy(nickbuf, priv->nick, IW_ESSID_MAX_SIZE+1);
+ memcpy(nickbuf, priv->nick, IW_ESSID_MAX_SIZE);
orinoco_unlock(priv, &flags);
- nrq->length = strlen(nickbuf);
+ nrq->length = strlen(priv->nick);
return 0;
}
-
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
[PATCH 2.6] More WE-21 potential overflows...
Hi,
After the Orinoco issue, I did an audit of other drivers for
the same issue. Three drivers were NULL terminating the ESSID, which
could cause an overflow in WE-21 when the ESSID has maximum size.
Sorry for having overlooked that...
Jean
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
---
diff -u -p linux/drivers/net/wireless/airo.j1.c
linux/drivers/net/wireless/airo.c
--- linux/drivers/net/wireless/airo.j1.c2006-10-02 17:40:43.0
-0700
+++ linux/drivers/net/wireless/airo.c 2006-10-02 17:41:32.0 -0700
@@ -5910,7 +5910,6 @@ static int airo_get_essid(struct net_dev
/* Get the current SSID */
memcpy(extra, status_rid.SSID, status_rid.SSIDlen);
- extra[status_rid.SSIDlen] = '\0';
/* If none, we may want to get the one that was set */
/* Push it out ! */
diff -u -p linux/drivers/net/wireless/atmel.j1.c
linux/drivers/net/wireless/atmel.c
--- linux/drivers/net/wireless/atmel.j1.c 2006-10-02 17:40:51.0
-0700
+++ linux/drivers/net/wireless/atmel.c 2006-10-02 17:41:59.0 -0700
@@ -1678,11 +1678,9 @@ static int atmel_get_essid(struct net_de
/* Get the current SSID */
if (priv->new_SSID_size != 0) {
memcpy(extra, priv->new_SSID, priv->new_SSID_size);
- extra[priv->new_SSID_size] = '\0';
dwrq->length = priv->new_SSID_size;
} else {
memcpy(extra, priv->SSID, priv->SSID_size);
- extra[priv->SSID_size] = '\0';
dwrq->length = priv->SSID_size;
}
diff -u -p linux/drivers/net/wireless/ray_cs.j1.c
linux/drivers/net/wireless/ray_cs.c
--- linux/drivers/net/wireless/ray_cs.j1.c 2006-10-02 17:40:58.0
-0700
+++ linux/drivers/net/wireless/ray_cs.c 2006-10-02 17:42:41.0 -0700
@@ -1198,7 +1198,6 @@ static int ray_get_essid(struct net_devi
/* Get the essid that was set */
memcpy(extra, local->sparm.b5.a_current_ess_id, IW_ESSID_MAX_SIZE);
- extra[IW_ESSID_MAX_SIZE] = '\0';
/* Push it out ! */
dwrq->length = strlen(extra);
-
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
[PATCH] neigh: always use hash_mask under tbl lock
Make sure hash_mask is protected with tbl->lock in all
cases just like the hash_buckets.
Signed-off-by: Julian Anastasov <[EMAIL PROTECTED]>
---
I just noticed this in sources. Let me know if such change
is valid and desired for 2.4 or stable tree. Compiles on 2.6.18 and
2.6.18-git18.
diff -urp v2.6.18-git18/linux/net/core/neighbour.c linux/net/core/neighbour.c
--- v2.6.18-git18/linux/net/core/neighbour.c2006-10-03 01:50:15.0
+0300
+++ linux/net/core/neighbour.c 2006-10-03 01:50:32.0 +0300
@@ -344,12 +344,12 @@ struct neighbour *neigh_lookup(struct ne
{
struct neighbour *n;
int key_len = tbl->key_len;
- u32 hash_val = tbl->hash(pkey, dev) & tbl->hash_mask;
+ u32 hash_val = tbl->hash(pkey, dev);
NEIGH_CACHE_STAT_INC(tbl, lookups);
read_lock_bh(&tbl->lock);
- for (n = tbl->hash_buckets[hash_val]; n; n = n->next) {
+ for (n = tbl->hash_buckets[hash_val & tbl->hash_mask]; n; n = n->next) {
if (dev == n->dev && !memcmp(n->primary_key, pkey, key_len)) {
neigh_hold(n);
NEIGH_CACHE_STAT_INC(tbl, hits);
@@ -364,12 +364,12 @@ struct neighbour *neigh_lookup_nodev(str
{
struct neighbour *n;
int key_len = tbl->key_len;
- u32 hash_val = tbl->hash(pkey, NULL) & tbl->hash_mask;
+ u32 hash_val = tbl->hash(pkey, NULL);
NEIGH_CACHE_STAT_INC(tbl, lookups);
read_lock_bh(&tbl->lock);
- for (n = tbl->hash_buckets[hash_val]; n; n = n->next) {
+ for (n = tbl->hash_buckets[hash_val & tbl->hash_mask]; n; n = n->next) {
if (!memcmp(n->primary_key, pkey, key_len)) {
neigh_hold(n);
NEIGH_CACHE_STAT_INC(tbl, hits);
@@ -1998,12 +1998,12 @@ static int neigh_dump_table(struct neigh
int rc, h, s_h = cb->args[1];
int idx, s_idx = idx = cb->args[2];
+ read_lock_bh(&tbl->lock);
for (h = 0; h <= tbl->hash_mask; h++) {
if (h < s_h)
continue;
if (h > s_h)
s_idx = 0;
- read_lock_bh(&tbl->lock);
for (n = tbl->hash_buckets[h], idx = 0; n; n = n->next, idx++) {
if (idx < s_idx)
continue;
@@ -2016,8 +2016,8 @@ static int neigh_dump_table(struct neigh
goto out;
}
}
- read_unlock_bh(&tbl->lock);
}
+ read_unlock_bh(&tbl->lock);
rc = skb->len;
out:
cb->args[1] = h;
-
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
Re: [PATCH 1/2] remove Momentum Jaguar ATX network driver support
On Mon, Oct 02, 2006 at 11:33:44PM +0900, Yoichi Yuasa wrote: > This patch has removed Momentum / PMC-Sierra Jaguar ATX network driver > support. > It is listed in feature-removal-schedule.txt . NAK. I won't remove the Momentum / Ocelot support for now. Ralf - 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
Re: Network problem with 2.6.18-mm1 ?
On Fri, 2006-09-29 at 17:30 -0600, Eric W. Biederman wrote: > > So it looks like the kernel moved the ioapics. > > The following patch in 2.6.18-mm1 is known to have that effect. > x86_64-mm-insert-ioapics-and-local-apic-into-resource-map > > Can you please try reverting that one patch? > > There is a fix an updated version of that patch I think in -mm2 > but I haven't had a chance to see if it fixes the problem yet. > Bingo !! Reverting this patch fixed my networking problem on 2.6.18-mm2. Thanks, Badari - 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
Re: cubic tcp behaviour
Thanks for posting your measurements on the web Injong. Without getting into the merits or otherwise of the coefficient of variation as a measure of anything users might care about, the individual time history plots of throughput and cwnd look interesting. I wonder if I could flag up some curious behaviour that seems evident in the measurements for the cubic algorithm. In very many of the individual time history plots it looks as if there are sustained periods (extending to 100s of seconds) of substantial unfairness between competing cubic flows with the same round-trip time. See for example: http://netsrv.csc.ncsu.edu/highspeed/convex-ordering/FullSet_old/RTTFAIR/1MB_4HS_0FLF_2RLF_SLF_320MS/600--CUBIC-CUBIC-SIMPLE--400-3-667--1000-155-0-0-1-1-5-500--20-0.6-1000-10-600-64000-150--24/ http://netsrv.csc.ncsu.edu/highspeed/convex-ordering/FullSet_old/RTTFAIR/1MB_4HS_0FLF_2RLF_SLF_320MS/600--CUBIC-CUBIC-SIMPLE--400-3-667--1000-155-0-0-1-1-5-500--20-0.6-1000-10-600-64000-150--17/ Can you comment on this behaviour ? Perhaps I am misinterpreting the data. I think its probably worth pointing out that in all the tests it looks as if the cubic flows are all started at much the same time - is this correct ? If so, the tests do not really probe the responsiveness of cubic and it might well be useful to perform tests where the flows have significantly different start times - it was this sort of experiment (by ourselves a couple of years ago now - blowing my own trumpet, I know, but what the heck :-)) that initially highlighted the convergence issues with scalable-tcp, and the slow convergence of high-speed tcp and bic-tcp. Slow convergence translates into possible sustained unfairness, for example, against new flows starting up. Doug Hamilton Institute www.hamilton.ie [EMAIL PROTECTED] wrote: Send end2end-interest mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://mailman.postel.org/mailman/listinfo/end2end-interest or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of end2end-interest digest..." Today's Topics: 1. Stability of various TCP protocols [CUBIC, BIC, HTCP, HSTCP, STCP] (Injong Rhee) 2. Re: performance of BIC-TCP, High-Speed-TCP, H-TCP etc (Injong Rhee) -- Message: 1 Date: Thu, 28 Sep 2006 12:58:02 -0400 From: "Injong Rhee" <[EMAIL PROTECTED]> Subject: [e2e] Stability of various TCP protocols [CUBIC, BIC, HTCP, HSTCP, STCP] To: <[EMAIL PROTECTED]> Cc: netdev@vger.kernel.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="ks_c_5601-1987" Hi, I'd like to report on a measurement study regarding the stability of various TCP variant protocols. Although we can find quite a bit of work on fairness and convergence of protocols (including some theoretical studies on the topic as well), there is relatively little work on measuring the stability of protocols and its impact on protocol performance and overall health of the networks (e.g., the overall queue fluctions and link utilization). We have measured the degree of rate oscillation and fluctuation of protocols to have some understanding of protocol stability. We would like to share our results with you to get some feedback from the community. We have some theoretical results and also experimental results. Here is the link to the experimental results. You can find links to all of our experimental data that include results from several hundred experiments. http://netsrv.csc.ncsu.edu/convex-ordering/ If you need our report on theoretical results, we can e-mail you the report. Injong Rhee -- next part -- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060928/c42cf65c/attachment-0001.html -- Message: 2 Date: Thu, 28 Sep 2006 12:33:32 -0400 From: "Injong Rhee" <[EMAIL PROTECTED]> Subject: Re: [e2e] performance of BIC-TCP, High-Speed-TCP, H-TCP etc To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Cc: netdev@vger.kernel.org, Douglas Leith <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Sure. I don't mind doing this test. I am currently working with Doug Leith to get to the bottom of this difference. So when we get to the PFLDnet, we should have some more findings on this. But I am up for this challenge. - Original Message - From: "Lachlan Andrew" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Douglas Leith" <[EMAIL PROTECTED]>; ; <[EMAIL PROTECT
[PATCH v3 0/1] One more time ...
Version 3 of the NetLabel support for the secid patchset. This version takes into account comments made by Stephen Smalley. -- paul moore linux security @ hp - 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
[ANNOUNCE] iproute2-2.6.18-061002
This is a much delayed update to the iproute2 command set. It can be downloaded from: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.18-061002.tar.gz Repository: git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git For more info on iproute2 see: http://linux-net.osdl.org/index.php/Iproute2 The version number includes the kernel version to denote what features are supported. The same source should build on older systems, but obviously the newer kernel features won't be available. As much as possible, this package tries to be source compatible across releases. Summary of changes: - converted to git - build fixes for some distributions - bug fix for xfrm monitor - alignment fixes for cris - documentation corrections - many small bug fixes - new tc monitor mode Contributors to this release Jamal Hadi Salim Patrick McHardy Andy Gay Jesper Dangaard Brouer Vince Worthington Git changelog is a bit of a mess, so if I missed your name sorry. - 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
[PATCH v3 1/1] NetLabel: secid reconciliation support
This patch provides the missing NetLabel support to the secid reconciliation
patchset.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
security/selinux/hooks.c| 80 ++---
security/selinux/include/objsec.h |1
security/selinux/include/selinux_netlabel.h | 28 +++
security/selinux/ss/services.c | 106 ++--
4 files changed, 107 insertions(+), 108 deletions(-)
Index: net-2.6/security/selinux/hooks.c
===
--- net-2.6.orig/security/selinux/hooks.c
+++ net-2.6/security/selinux/hooks.c
@@ -3465,6 +3465,10 @@ static int selinux_sock_rcv_skb_compat(s
goto out;
}
+ err = selinux_netlbl_sock_rcv_skb(sock_sid, sock_class, skb, ad);
+ if (err)
+ goto out;
+
err = selinux_xfrm_sock_rcv_skb(sock_sid, skb, ad);
out:
@@ -3501,10 +3505,7 @@ static int selinux_socket_sock_rcv_skb(s
else
err = avc_has_perm(sksec->sid, skb->secmark, SECCLASS_PACKET,
PACKET__RECV, &ad);
- if (err)
- goto out;
- err = selinux_netlbl_sock_rcv_skb(sksec, skb, &ad);
out:
return err;
}
@@ -3527,11 +3528,8 @@ static int selinux_socket_getpeersec_str
peer_sid = ssec->peer_sid;
}
else if (isec->sclass == SECCLASS_TCP_SOCKET) {
- peer_sid = selinux_netlbl_socket_getpeersec_stream(sock);
- if (peer_sid == SECSID_NULL) {
- ssec = sock->sk->sk_security;
- peer_sid = ssec->peer_sid;
- }
+ ssec = sock->sk->sk_security;
+ peer_sid = ssec->peer_sid;
if (peer_sid == SECSID_NULL) {
err = -ENOPROTOOPT;
goto out;
@@ -3573,13 +3571,13 @@ static int selinux_socket_getpeersec_dgr
if (sock && (sock->sk->sk_family == PF_UNIX))
selinux_get_inode_sid(SOCK_INODE(sock), &peer_secid);
else if (skb) {
- peer_secid = selinux_netlbl_socket_getpeersec_dgram(skb);
- if (peer_secid == SECSID_NULL) {
- if (selinux_compat_net)
+ if (selinux_compat_net) {
+ peer_secid = selinux_netlbl_socket_getpeersec_dgram(
+ skb);
+ if (peer_secid == SECSID_NULL)
peer_secid = selinux_socket_getpeer_dgram(skb);
- else
- peer_secid = skb->secmark;
- }
+ } else
+ peer_secid = skb->secmark;
}
if (peer_secid == SECSID_NULL)
@@ -3641,13 +3639,11 @@ static int selinux_inet_conn_request(str
u32 newsid;
u32 peersid;
- newsid = selinux_netlbl_inet_conn_request(skb, sksec->sid);
- if (newsid != SECSID_NULL) {
- req->secid = newsid;
- return 0;
- }
-
if (selinux_compat_net) {
+ err = selinux_netlbl_skb_sid(skb, sksec->sid, &peersid);
+ if (err == 0 && peersid != SECSID_NULL)
+ goto out;
+
err = selinux_xfrm_decode_session(skb, &peersid, 0);
BUG_ON(err);
@@ -3659,6 +3655,7 @@ static int selinux_inet_conn_request(str
} else
peersid = skb->secmark;
+out:
err = security_sid_mls_copy(sksec->sid, peersid, &newsid);
if (err)
return err;
@@ -3700,6 +3697,8 @@ static void selinux_req_classify_flow(co
static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
{
u32 xfrm_sid;
+ u32 nlbl_sid;
+ u32 ext_sid;
int err;
if (selinux_compat_net)
@@ -3717,15 +3716,27 @@ static int selinux_skb_flow_in(struct sk
err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0);
BUG_ON(err);
- err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
- PACKET__FLOW_IN, NULL);
+ err = selinux_netlbl_skb_sid(skb,
+xfrm_sid ? xfrm_sid : skb->secmark,
+&nlbl_sid);
if (err)
goto out;
- if (xfrm_sid)
- skb->secmark = xfrm_sid;
+ if (nlbl_sid)
+ ext_sid = nlbl_sid;
+ else
+ ext_sid = xfrm_sid;
- /* See if NetLabel can flow in thru the current secmark here */
+ err = avc_has_perm(ext_sid,
+ skb->secmark,
+ SECCLASS_PACKET,
+ PACKET__FLOW_IN,
+ NULL);
+ if (err)
+ goto out;
+
+ if (ext_sid)
+ skb->secmark = ext_sid;
out:
return err ? 0 : 1;
@@ -3740,1
Re: [PATCH] Network Events Connector
From: Samir Bellabes <[EMAIL PROTECTED]> Date: Mon, 02 Oct 2006 08:11:06 +0200 > 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 open for the corresponding sport or not, and if > so open the firewall for the application which get the corresponding sport. You can do this with the security layer, netfilter's ULOG, or even the netfilter connection tracking netlink sockets. That's 3 facilities by which you can accomplish this, and if none of them are perfect, add the small modifications you need to one of them to make them usable for your task. It makes no sense to add new facilities just for this. - 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
Re: [PATCH v2 1/1] NetLabel: secid reconciliation support
Stephen Smalley wrote:
> On Mon, 2006-10-02 at 14:06 -0400, [EMAIL PROTECTED] wrote:
>
>>plain text document attachment (netlabel-secid_support)
>>This patch provides the missing NetLabel support to the secid reconciliation
>>patchset.
>>
>>Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
>>---
>> security/selinux/hooks.c| 67 +++--
>> security/selinux/include/objsec.h |1
>> security/selinux/include/selinux_netlabel.h | 28 +++
>> security/selinux/ss/services.c | 106
>> ++--
>> 4 files changed, 98 insertions(+), 104 deletions(-)
>
>
>>@@ -3725,7 +3723,16 @@ static int selinux_skb_flow_in(struct sk
>>+
>>+ err = avc_has_perm(nlbl_sid, skb->secmark, SECCLASS_PACKET,
>>+ PACKET__FLOW_IN, NULL);
>
>
> This means we end up with two flow_in checks each time, even if only one
> or none of the two labeling mechanisms was used, right? Given the
> conclusion on the discussion of what it means to use them together (just
> redundant), this seems to be pointless overhead.
Okay, how about something like this?
static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
{
u32 xfrm_sid;
u32 nlbl_sid;
u32 ext_sid;
int err;
if (selinux_compat_net)
return 1;
/*
* loopback traffic already labeled and
* flow-controlled on outbound. We may
* need to flow-control on the inbound
* as well if there's ever a use-case for it.
*/
if (skb->dev == &loopback_dev)
return 1;
err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0);
BUG_ON(err);
err = selinux_netlbl_skb_sid(skb,
xfrm_sid ? xfrm_sid : skb->secmark,
&nlbl_sid);
if (err)
goto out;
if (nlbl_sid)
ext_sid = nlbl_sid;
else
ext_sid = xfrm_sid;
err = avc_has_perm(ext_sid,
skb->secmark,
SECCLASS_PACKET,
PACKET__FLOW_IN,
NULL);
if (err)
goto out;
if (ext_sid)
skb->secmark = ext_sid;
out:
return err ? 0 : 1;
};
--
paul moore
linux security @ hp
-
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
RE: [PATCH v2 1/1] NetLabel: secid reconciliation support
> > If this selinux_netlbl_skb_sid() call can fail for any > reason other than > > a kernel bug, then this needs to goto out instead of using > BUG_ON. For > > example, if the function can fail due to temporary memory pressure > > leading to a failed allocation, then you want to simply > drop the packet, > > not panic the kernel. > > That's fine - see the discussion Venkat and I had earlier. > I'll change > it to jump to "out". Just to clarify, my comments earlier about BUG_ON were in relation to selinux_xfrm_decode_session which can only fail as a result of a bug or kernel corruption. For "other" errors, a jump out indeed seems proper, like you are already planning to do. - 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
Re: 2.6.18-mm2 - oops in cache_alloc_refill()
On Mon, 02 Oct 2006 10:52:45 PDT, Jean Tourrilhes said: > On Fri, Sep 29, 2006 at 06:20:08PM -0700, Andrew Morton wrote: > > On Fri, 29 Sep 2006 20:01:54 -0400 > > > > > > % grep ioctl /tmp/foo2 | sort -u | more > > > ioctl(13, SIOCGIWESSID, 0xbfbcdb9c) = 0 > > > ioctl(13, SIOCGIWRANGE, 0xbfbcdbdc) = 0 > > > ioctl(13, SIOCGIWRATE, 0xbfbcdbbc) = 0 > > > > Yes. The main thing which those WE-21 patches do is to shorten the size of > > various buffers which are used in wireless ioctls. > > Ok, I've found it. Actually, I feel ashamed, as it is a fairly > classical buffer overflow, we put one extra char in a buffer. Now, I > don't understand why it did not blow up on my box ;-) > New patch. I think it is right, but I would not mind Pavel to > have a look at it. On my box it does not make thing worse. > Valdis : would you mind trying if this patch fix the problem > you are seeing with WE-21 ? If it fixes it, I'll send it to John... Been up and running with we-21 configured in, and gkrellm doing the monitoring that gave it indigestion. It was dying in 1-2 minutes, now been up for 30 mins with no issues pgpGWS0PQ0L7P.pgp Description: PGP signature
Re: [PATCH v2 1/1] NetLabel: secid reconciliation support
Stephen Smalley wrote: > On Mon, 2006-10-02 at 14:06 -0400, [EMAIL PROTECTED] wrote: > >>plain text document attachment (netlabel-secid_support) >>This patch provides the missing NetLabel support to the secid reconciliation >>patchset. >> >>Signed-off-by: Paul Moore <[EMAIL PROTECTED]> >>--- >> security/selinux/hooks.c| 67 +++-- >> security/selinux/include/objsec.h |1 >> security/selinux/include/selinux_netlabel.h | 28 +++ >> security/selinux/ss/services.c | 106 >> ++-- >> 4 files changed, 98 insertions(+), 104 deletions(-) > > >>@@ -3725,7 +3723,16 @@ static int selinux_skb_flow_in(struct sk >> if (xfrm_sid) >> skb->secmark = xfrm_sid; >> >>- /* See if NetLabel can flow in thru the current secmark here */ >>+ err = selinux_netlbl_skb_sid(skb, skb->secmark, &nlbl_sid); >>+ BUG_ON(err); > > > If this selinux_netlbl_skb_sid() call can fail for any reason other than > a kernel bug, then this needs to goto out instead of using BUG_ON. For > example, if the function can fail due to temporary memory pressure > leading to a failed allocation, then you want to simply drop the packet, > not panic the kernel. That's fine - see the discussion Venkat and I had earlier. I'll change it to jump to "out". >>+ >>+ err = avc_has_perm(nlbl_sid, skb->secmark, SECCLASS_PACKET, >>+ PACKET__FLOW_IN, NULL); > > > This means we end up with two flow_in checks each time, even if only one > or none of the two labeling mechanisms was used, right? Given the > conclusion on the discussion of what it means to use them together (just > redundant), this seems to be pointless overhead. I was just trying to match what Venkat had already done. It's easy enough to distinguish when there is not a NetLabel present and skip the second check, but I think we need a second access check for NetLabel when it is present as to skip that check could result in some wierd behaviors if both forms of external labeling are used. Yes, we all agree it's redundant to use both at the same time, but I don't think there is anything preventing users from doing so at the present time. >>@@ -3749,6 +3757,12 @@ static int selinux_skb_flow_out(struct s >> struct sk_security_struct *sksec = skb->sk->sk_security; >> skb->secmark = sksec->sid; >> } >>+ >>+ err = selinux_netlbl_skb_sid(skb, skb->secmark, &nlbl_sid); >>+ BUG_ON(err); > > > Same concern about BUG_ON as above. Also, I'd have expected this to > happen at the same point that selinux_skb_xfrm_sid() is called. > >>+ if (nlbl_sid) >>+ skb->secmark = nlbl_sid; > > > And then I'd expect this to be moved up prior to the if (xfrm_sid) > clause, turning that into an else clause, e.g.: > if (nlbl_sid) > skb->secmark = nlbl_sid; > else if (xfrm_sid) > skb->secmark = xfrm_sid; > else if (skb->sk) ... Easy enough to change. >>@@ -3913,9 +3928,15 @@ static unsigned int selinux_ip_postroute >> skb->sk->sk_security; >> skb->secmark = sksec->sid; >> } >>+ >>+ err = selinux_netlbl_skb_sid(skb, >>+ skb->secmark, >>+ &nlbl_sid); >>+ BUG_ON(err); >>+ >>+ if (nlbl_sid) >>+ skb->secmark = nlbl_sid; > > > Similar comments as above. > >> } >>- err = avc_has_perm(skb->secmark, SECINITSID_UNLABELED, >>-SECCLASS_PACKET, PACKET__FLOW_OUT, &ad); > > > Why do you think you can remove this? I don't, that was a mistake/typo that I missed. Thanks. -- paul moore linux security @ hp - 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
Re: [PATCH v2 1/1] NetLabel: secid reconciliation support
On Mon, 2006-10-02 at 14:06 -0400, [EMAIL PROTECTED] wrote: > plain text document attachment (netlabel-secid_support) > This patch provides the missing NetLabel support to the secid reconciliation > patchset. > > Signed-off-by: Paul Moore <[EMAIL PROTECTED]> > --- > security/selinux/hooks.c| 67 +++-- > security/selinux/include/objsec.h |1 > security/selinux/include/selinux_netlabel.h | 28 +++ > security/selinux/ss/services.c | 106 > ++-- > 4 files changed, 98 insertions(+), 104 deletions(-) > @@ -3725,7 +3723,16 @@ static int selinux_skb_flow_in(struct sk > if (xfrm_sid) > skb->secmark = xfrm_sid; > > - /* See if NetLabel can flow in thru the current secmark here */ > + err = selinux_netlbl_skb_sid(skb, skb->secmark, &nlbl_sid); > + BUG_ON(err); If this selinux_netlbl_skb_sid() call can fail for any reason other than a kernel bug, then this needs to goto out instead of using BUG_ON. For example, if the function can fail due to temporary memory pressure leading to a failed allocation, then you want to simply drop the packet, not panic the kernel. > + > + err = avc_has_perm(nlbl_sid, skb->secmark, SECCLASS_PACKET, > + PACKET__FLOW_IN, NULL); This means we end up with two flow_in checks each time, even if only one or none of the two labeling mechanisms was used, right? Given the conclusion on the discussion of what it means to use them together (just redundant), this seems to be pointless overhead. > @@ -3749,6 +3757,12 @@ static int selinux_skb_flow_out(struct s > struct sk_security_struct *sksec = skb->sk->sk_security; > skb->secmark = sksec->sid; > } > + > + err = selinux_netlbl_skb_sid(skb, skb->secmark, &nlbl_sid); > + BUG_ON(err); Same concern about BUG_ON as above. Also, I'd have expected this to happen at the same point that selinux_skb_xfrm_sid() is called. > + if (nlbl_sid) > + skb->secmark = nlbl_sid; And then I'd expect this to be moved up prior to the if (xfrm_sid) clause, turning that into an else clause, e.g.: if (nlbl_sid) skb->secmark = nlbl_sid; else if (xfrm_sid) skb->secmark = xfrm_sid; else if (skb->sk) ... > @@ -3913,9 +3928,15 @@ static unsigned int selinux_ip_postroute > skb->sk->sk_security; > skb->secmark = sksec->sid; > } > + > + err = selinux_netlbl_skb_sid(skb, > + skb->secmark, > + &nlbl_sid); > + BUG_ON(err); > + > + if (nlbl_sid) > + skb->secmark = nlbl_sid; Similar comments as above. > } > - err = avc_has_perm(skb->secmark, SECINITSID_UNLABELED, > -SECCLASS_PACKET, PACKET__FLOW_OUT, &ad); Why do you think you can remove this? -- Stephen Smalley National Security Agency - 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
RE: [PATCH] Fix for IPsec leakage with SELinux enabled
> > This is indeed the "designed" and expected (for me) behavior. > > This is a security hole. SELinux denies all access by > default, so the > default behavior of this code is to allow all traffic to bypass IPsec. > > You should not need to add a rule to 'allow' increased security. You are right. Currently working on a patch (should be out tonight/tomorrow). > This needs to be handled within SELinux as far as possible, > and errors > will generally need to be propagated back to the callers, as Agreed here as well. I have yet to review your patch in depth, but it definitely makes sense to do what you say here. Thanks. > we don't know > what other LSMs might do, and errors unrelated to access > control can be > returned. > > > - James > -- > James Morris > <[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 http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Fix for IPsec leakage with SELinux enabled
On Mon, 2 Oct 2006, Venkat Yekkirala wrote:
> This is indeed the "designed" and expected (for me) behavior.
This is a security hole. SELinux denies all access by default, so the
default behavior of this code is to allow all traffic to bypass IPsec.
You should not need to add a rule to 'allow' increased security.
> But I am
> beginning to see where this is perhaps NOT in line with the user
> expectation when the users have an IPSec policy rule that does NOT use
> labels.
> currently, EACH flow needing to use this rule MUST
> have SELinux policy "polmatch"ing the flow context (ftpd_t)
> to unlabeled_t (the implied in the absence of an explicit
> context on the IPSec policy rule) or the traffic would flow
> in clear text ("leaks" in user perception).
Plaintext leak is not a user perception, it's an absolute.
> What I propose we do is to do the polmatch check ONLY when
> there's an explicit label associated with the spd rule. Does
> this sound reasonable and correct in the larger SELinux context?
I think so.
> In cases where there's an explicit label on an spd rule like:
>
> spdadd 192.168.4.79 192.168.4.78 any -ctx 1 1
> "system_u:object_r:labeled_ipsec_t:s2-s4"
> -P out ipsec
> esp/transport//require;
>
> spdadd 192.168.4.78 192.168.4.79 any -ctx 1 1
> "system_u:object_r:labeled_ipsec_t:s2-s4"
> -P in ipsec
> esp/transport//require;
>
> then the current behavior (prior to this proposed patch) would be the
> desired behavior, i.e., a polmatch denial in the SELinux module just
> means that the flow isn't expected to undergo IPSec xfrms. IOW, there's
> no need to propagate -EACCES all the way back up. We could still propagate
> errors other than -EACCES if we like.
This needs to be handled within SELinux as far as possible, and errors
will generally need to be propagated back to the callers, as we don't know
what other LSMs might do, and errors unrelated to access control can be
returned.
- James
--
James Morris
<[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 http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] d80211: proper rate control structures freeing
Add a reference counting to the rate control algorithm structure. This
prevents unloading of the rate control module when there still exists a sta
entry which uses that module.
To achieve this some other things need to be done in this patch as well:
- The new rate_control_ref structure is introduced. It replaces the
rate_ctrl and rate_ctrl_priv fields in the ieee80211_local.
- Parameters for most rate control callbacks are changed.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c | 37 +
net/d80211/ieee80211_i.h |3 -
net/d80211/ieee80211_ioctl.c |2 -
net/d80211/ieee80211_rate.c | 54 +-
net/d80211/ieee80211_rate.h | 124 +-
net/d80211/ieee80211_scan.c |2 -
net/d80211/ieee80211_sta.c |6 +-
net/d80211/ieee80211_sysfs.c |5 +-
net/d80211/rc80211_simple.c | 19 --
net/d80211/sta_info.c| 14 +++--
net/d80211/sta_info.h|1
11 files changed, 158 insertions(+), 109 deletions(-)
d0b148eaaa06082e00c9e2a753cf6106d468b5b0
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 8c4a6d6..8d8149e 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -351,7 +351,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021
extra.startidx = 0;
extra.endidx= tx->local->num_curr_rates;
- tx->u.tx.rate = rate_control_get_rate(tx->dev, tx->skb, &extra);
+ tx->u.tx.rate = rate_control_get_rate(tx->local, tx->dev, tx->skb,
+ &extra);
if (unlikely(extra.probe != NULL)) {
tx->u.tx.control->rate_ctrl_probe = 1;
tx->u.tx.probe_last_frag = 1;
@@ -1781,7 +1782,7 @@ #endif /* CONFIG_D80211_VERBOSE_DEBUG */
memset(&extra, 0, sizeof(extra));
extra.endidx = local->num_curr_rates;
- rate = rate_control_get_rate(dev, skb, &extra);
+ rate = rate_control_get_rate(local, dev, skb, &extra);
if (!rate) {
if (net_ratelimit()) {
printk(KERN_DEBUG "%s: ieee80211_beacon_get: no
rate "
@@ -4102,7 +4103,7 @@ void ieee80211_tx_status(struct net_devi
return;
}
} else {
- rate_control_tx_status(dev, skb, status);
+ rate_control_tx_status(local, dev, skb, status);
}
ieee80211_led_tx(local, 0);
@@ -4304,36 +4305,30 @@ static void ieee80211_precalc_modes(stru
static int rate_control_initialize(struct ieee80211_local *local)
{
- struct rate_control_ops *ops;
+ struct rate_control_ref *ref;
- ops = ieee80211_rate_control_ops_get(NULL);
- if (!ops) {
+ ref = rate_control_alloc(NULL, local);
+ if (!ref) {
printk(KERN_WARNING "%s: Failed to select rate control "
"algorithm\n", local->mdev->name);
return -1;
}
- local->rate_ctrl_priv = rate_control_alloc(ops, local);
- if (!local->rate_ctrl_priv) {
- ieee80211_rate_control_ops_put(ops);
- return -1;
- }
- local->rate_ctrl = ops;
+ local->rate_ctrl = ref;
printk(KERN_DEBUG "%s: Selected rate control "
"algorithm '%s'\n", local->mdev->name,
- local->rate_ctrl->name);
+ ref->ops->name);
return 0;
}
static void rate_control_deinitialize(struct ieee80211_local *local)
{
- struct rate_control_ops *ops;
+ struct rate_control_ref *ref;
- rate_control_free(local);
- ops = local->rate_ctrl;
+ ref = local->rate_ctrl;
local->rate_ctrl = NULL;
- ieee80211_rate_control_ops_put(ops);
+ rate_control_put(ref);
}
struct net_device *ieee80211_alloc_hw(size_t priv_data_len,
@@ -4511,8 +4506,7 @@ int ieee80211_register_hw(struct net_dev
"algorithm\n", dev->name);
goto fail_rate;
}
- result = rate_control_add_attrs(local, local->rate_ctrl_priv,
- &local->class_dev.kobj);
+ result = rate_control_add_attrs(local->ref, &local->class_dev.kobj);
if (result < 0) {
printk(KERN_DEBUG "%s: Failed to register sysfs attributes "
"for rate control\n", dev->name);
@@ -4630,8 +4624,8 @@ void ieee80211_unregister_hw(struct net_
ieee80211_rx_bss_list_deinit(dev);
ieee80211_clear_tx_pending(local);
sta_info_stop(local);
- rate_control_remove_attrs(local, local->rate_ctrl_priv,
- &local->class_dev.kobj);
+ rate_control_remove_attrs(local->ref, &local->class_dev.kobj);
+ rate_control_deinitialize(local);
ieee80211_dev_sysfs_del(local);
for (i = 0; i < NUM_IEEE80211_MODES; i++) {
@@ -4662,7 +4656,6 @@ EXPORT_SYMBOL(ieee80
[PATCH 0/8] d80211: rate control modules locking and changing
The following patch series fixes locking issues with rate control modules and adds support for on-the-fly changing of the rate control algorithms. During the work I discovered some bugs which are not exactly related to rate controling; they are included in the series as well. All patches are also available in the 'devel' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git Jiri -- Jiri Benc SUSE Labs - 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
[PATCH 3/8] d80211: rename rate_control.h to ieee80211_rate.h
rate_control.h is not a header for rate_control.c as the name suggests.
Furthermore, we want to introduce ieee80211_rate.c which implements some
things defined in rate_control.h.
This patch renames rate_control.h to ieee80211_rate.h.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |2 -
net/d80211/ieee80211_ioctl.c |2 -
net/d80211/ieee80211_rate.h | 154 ++
net/d80211/ieee80211_scan.c |2 -
net/d80211/ieee80211_sta.c |2 -
net/d80211/ieee80211_sysfs.c |2 -
net/d80211/rate_control.c|2 -
net/d80211/rate_control.h| 154 --
net/d80211/sta_info.c|2 -
9 files changed, 161 insertions(+), 161 deletions(-)
create mode 100644 net/d80211/ieee80211_rate.h
delete mode 100644 net/d80211/rate_control.h
f0ab1336dc23b25ed00a7a26ec0ba0b9a1a96cdf
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index b30bd80..b138eb0 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -25,7 +25,7 @@ #include
#include
#include
#include "ieee80211_i.h"
-#include "rate_control.h"
+#include "ieee80211_rate.h"
#include "wep.h"
#include "wpa.h"
#include "tkip.h"
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 445adad..36759e4 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -23,7 +23,7 @@ #include
#include
#include "ieee80211_i.h"
#include "hostapd_ioctl.h"
-#include "rate_control.h"
+#include "ieee80211_rate.h"
#include "wpa.h"
#include "aes_ccm.h"
diff --git a/net/d80211/ieee80211_rate.h b/net/d80211/ieee80211_rate.h
new file mode 100644
index 000..e1c9e05
--- /dev/null
+++ b/net/d80211/ieee80211_rate.h
@@ -0,0 +1,154 @@
+/*
+ * Copyright 2002-2005, Instant802 Networks, Inc.
+ * Copyright 2005, Devicescape Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef IEEE80211_RATE_H
+#define IEEE80211_RATE_H
+
+#include
+#include
+#include
+#include
+#include "ieee80211_i.h"
+#include "sta_info.h"
+
+#define RATE_CONTROL_NUM_DOWN 20
+#define RATE_CONTROL_NUM_UP 15
+
+
+struct rate_control_extra {
+ /* values from rate_control_get_rate() to the caller: */
+ struct ieee80211_rate *probe; /* probe with this rate, or NULL for no
+ * probing */
+ int startidx, endidx, rateidx;
+ struct ieee80211_rate *nonerp;
+ int nonerp_idx;
+
+ /* parameters from the caller to rate_control_get_rate(): */
+ int mgmt_data; /* this is data frame that is used for management
+ * (e.g., IEEE 802.1X EAPOL) */
+ u16 ethertype;
+};
+
+
+struct rate_control_ops {
+ const char *name;
+ void (*tx_status)(struct net_device *dev, struct sk_buff *skb,
+ struct ieee80211_tx_status *status);
+ struct ieee80211_rate *
+ (*get_rate)(struct net_device *dev, struct sk_buff *skb,
+ struct rate_control_extra *extra);
+ void (*rate_init)(struct ieee80211_local *local, struct sta_info *sta);
+ void (*clear)(void *priv);
+
+ void * (*alloc)(struct ieee80211_local *local);
+ void (*free)(void *priv);
+ void * (*alloc_sta)(void);
+ void (*free_sta)(void *priv);
+
+ int (*add_attrs)(void *priv, struct kobject *kobj);
+ void (*remove_attrs)(void *priv, struct kobject *kobj);
+ int (*add_sta_attrs)(void *priv, struct kobject *kobj);
+ void (*remove_sta_attrs)(void *priv, struct kobject *kobj);
+};
+
+
+int ieee80211_rate_control_register(struct rate_control_ops *ops);
+void ieee80211_rate_control_unregister(struct rate_control_ops *ops);
+
+
+static inline void rate_control_tx_status(struct net_device *dev,
+ struct sk_buff *skb,
+ struct ieee80211_tx_status *status)
+{
+ struct ieee80211_local *local = dev->ieee80211_ptr;
+ local->rate_ctrl->tx_status(dev, skb, status);
+}
+
+
+static inline struct ieee80211_rate *
+rate_control_get_rate(struct net_device *dev, struct sk_buff *skb,
+ struct rate_control_extra *extra)
+{
+ struct ieee80211_local *local = dev->ieee80211_ptr;
+ return local->rate_ctrl->get_rate(dev, skb, extra);
+}
+
+
+static inline void rate_control_rate_init(struct ieee80211_local *local,
+ struct sta_info *sta)
+{
+ local->rate_ctrl->rate_init(local, sta);
+}
+
+
+static inline void rate_control_clear(struct ieee80211_local *local)
+{
+ local->rate_ctrl->clear(local->rate_ctrl_priv);
+}
+
+
+static inline void * rate_control_alloc(struct ieee80211_local *local)
+{
+ return local->rate_ctrl->alloc(local);
+}
+
+
+static inli
[PATCH 7/8] d80211: allow changing of the rate control algorithm
Allow changing of the rate control algorithm.
This has some limitations:
- The rate control algorithm can be set per-wiphy only.
- All of network interfaces of the wiphy have to be down to change the
algorithm.
- All sta entries are flushed when the algorithm is succesfully changed.
- The add_sta ioctl can be called only at a running interface from now.
Changing of the algorithm is possible by writing a new algorithm name into
/sys/class/ieee80211/phyX/rate_ctrl_alg. This will be most likely changed in
the future.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c | 50 +-
net/d80211/ieee80211_i.h |2 ++
net/d80211/ieee80211_ioctl.c |4 +++
net/d80211/ieee80211_sysfs.c | 18 ++-
4 files changed, 57 insertions(+), 17 deletions(-)
7fc923b53c8689378512c6fe51b21e85224f860b
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 8d8149e..ce56fd3 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4303,22 +4303,44 @@ static void ieee80211_precalc_modes(stru
}
}
-static int rate_control_initialize(struct ieee80211_local *local)
+int ieee80211_init_rate_ctrl_alg(struct ieee80211_local *local,
+const char *name)
{
- struct rate_control_ref *ref;
+ struct rate_control_ref *ref, *old;
+ int res;
+
+ ASSERT_RTNL();
+ if (local->open_count || netif_running(local->mdev) ||
+ (local->apdev && netif_running(local->apdev)))
+ return -EBUSY;
- ref = rate_control_alloc(NULL, local);
+ ref = rate_control_alloc(name, local);
if (!ref) {
printk(KERN_WARNING "%s: Failed to select rate control "
"algorithm\n", local->mdev->name);
- return -1;
+ return -ENOENT;
+ }
+ res = rate_control_add_attrs(ref, &local->class_dev.kobj);
+ if (res < 0) {
+ printk(KERN_DEBUG "%s: Failed to register sysfs attributes "
+ "for rate control\n", local->mdev->name);
+ rate_control_put(ref);
+ return res;
}
+
+ old = local->rate_ctrl;
local->rate_ctrl = ref;
+ if (old) {
+ rate_control_remove_attrs(ref, &local->class_dev.kobj);
+ rate_control_put(old);
+ sta_info_flush(local, NULL);
+ }
printk(KERN_DEBUG "%s: Selected rate control "
"algorithm '%s'\n", local->mdev->name,
ref->ops->name);
+
return 0;
}
@@ -4328,6 +4350,7 @@ static void rate_control_deinitialize(st
ref = local->rate_ctrl;
local->rate_ctrl = NULL;
+ rate_control_remove_attrs(ref, &local->class_dev.kobj);
rate_control_put(ref);
}
@@ -4496,28 +4519,24 @@ int ieee80211_register_hw(struct net_dev
goto fail_masterlink;
}
result = ieee80211_sysfs_add_netdevice(dev);
- rtnl_unlock();
- if (result < 0)
+ if (result < 0) {
+ rtnl_unlock();
goto fail_if_sysfs;
+ }
- result = rate_control_initialize(local);
+ result = ieee80211_init_rate_ctrl_alg(local, NULL);
+ rtnl_unlock();
if (result < 0) {
printk(KERN_DEBUG "%s: Failed to initialize rate control "
"algorithm\n", dev->name);
goto fail_rate;
}
- result = rate_control_add_attrs(local->ref, &local->class_dev.kobj);
- if (result < 0) {
- printk(KERN_DEBUG "%s: Failed to register sysfs attributes "
- "for rate control\n", dev->name);
- goto fail_rate_attrs;
- }
result = ieee80211_wep_init(local);
if (result < 0) {
printk(KERN_DEBUG "%s: Failed to initialize wep\n", dev->name);
- goto fail_rate_attrs;
+ goto fail_wep;
}
/* TODO: add rtnl locking around device creation and qdisc install */
@@ -4536,7 +4555,7 @@ int ieee80211_register_hw(struct net_dev
return 0;
-fail_rate_attrs:
+fail_wep:
rate_control_deinitialize(local);
fail_rate:
ieee80211_sysfs_remove_netdevice(dev);
@@ -4624,7 +4643,6 @@ void ieee80211_unregister_hw(struct net_
ieee80211_rx_bss_list_deinit(dev);
ieee80211_clear_tx_pending(local);
sta_info_stop(local);
- rate_control_remove_attrs(local->ref, &local->class_dev.kobj);
rate_control_deinitialize(local);
ieee80211_dev_sysfs_del(local);
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 9c81c48..314235b 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -583,6 +583,8 @@ int ieee80211_if_update_wds(struct net_d
void ieee80211_if_setup(struct net_device *dev);
void ieee80211_if_mgmt_setup(struct net_device *dev);
void ieee80211_if_shutdown(struct
[PATCH 2/8] d80211: del sta timer on interface close
Delete sta timer when the corresponding network interface is brought down.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c | 24
net/d80211/ieee80211_i.h |1 +
net/d80211/ieee80211_iface.c | 12 +++-
net/d80211/ieee80211_sta.c |3 +++
4 files changed, 31 insertions(+), 9 deletions(-)
832beeb503d7c41a6a9f3ea73cf31dee5c9f1eb9
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 036eca1..b30bd80 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -2106,6 +2106,29 @@ static struct net_device_stats *ieee8021
return &(sdata->stats);
}
+void ieee80211_if_shutdown(struct net_device *dev)
+{
+ struct ieee80211_local *local = dev->ieee80211_ptr;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+
+ ASSERT_RTNL();
+ switch (sdata->type) {
+ case IEEE80211_IF_TYPE_STA:
+ case IEEE80211_IF_TYPE_IBSS:
+ sdata->u.sta.state = IEEE80211_DISABLED;
+ del_timer_sync(&sdata->u.sta.timer);
+ if (local->scan_work.data == sdata->dev) {
+ local->sta_scanning = 0;
+ cancel_delayed_work(&local->scan_work);
+ flush_scheduled_work();
+ /* see comment in ieee80211_unregister_hw to
+* understand why this works */
+ local->scan_work.data = NULL;
+ }
+ break;
+ }
+}
+
static inline int identical_mac_addr_allowed(int type1, int type2)
{
return (type1 == IEEE80211_IF_TYPE_MNTR ||
@@ -2306,6 +2329,7 @@ static int ieee80211_stop(struct net_dev
conf.mac_addr = dev->dev_addr;
local->hw->remove_interface(sdata->master, &conf);
}
+ ieee80211_if_shutdown(dev);
ieee80211_start_hard_monitor(local);
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index 425fc9b..6fd208e 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -583,6 +583,7 @@ void ieee80211_tx_set_iswep(struct ieee8
int ieee80211_if_update_wds(struct net_device *dev, u8 *remote_addr);
void ieee80211_if_setup(struct net_device *dev);
void ieee80211_if_mgmt_setup(struct net_device *dev);
+void ieee80211_if_shutdown(struct net_device *dev);
/* ieee80211_ioctl.c */
int ieee80211_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 0a10c86..9a187af 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -242,6 +242,9 @@ #endif
ieee80211_key_free(sdata->keys[i]);
}
+ /* Shouldn't be necessary but won't hurt */
+ ieee80211_if_shutdown(dev);
+
switch (sdata->type) {
case IEEE80211_IF_TYPE_AP: {
/* Remove all virtual interfaces that use this BSS
@@ -286,15 +289,6 @@ #endif /* CONFIG_D80211_VERBOSE_DEBUG */
break;
case IEEE80211_IF_TYPE_STA:
case IEEE80211_IF_TYPE_IBSS:
- del_timer_sync(&sdata->u.sta.timer);
- if (local->scan_work.data == sdata->dev) {
- local->sta_scanning = 0;
- cancel_delayed_work(&local->scan_work);
- flush_scheduled_work();
- /* see comment in ieee80211_unregister_hw to
-* understand why this works */
- local->scan_work.data = NULL;
- }
kfree(sdata->u.sta.extra_ie);
sdata->u.sta.extra_ie = NULL;
kfree(sdata->u.sta.assocreq_ies);
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index dd95ce8..159474f 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1848,6 +1848,9 @@ void ieee80211_sta_timer(unsigned long p
struct ieee80211_if_sta *ifsta;
dev = (struct net_device *) ptr;
+ if (!netif_running(dev))
+ return;
+
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
if (sdata->type != IEEE80211_IF_TYPE_STA &&
sdata->type != IEEE80211_IF_TYPE_IBSS) {
--
1.3.0
-
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
[PATCH 8/8] d80211: rate_control: do not use atomic allocations when not necessary
Allow GFP_KERNEL to be used for allocations of sta entries triggered from
the user space.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211_ioctl.c |2 +-
net/d80211/ieee80211_rate.h |7 ---
net/d80211/ieee80211_sta.c |4 ++--
net/d80211/rc80211_simple.c |4 ++--
net/d80211/sta_info.c|8 +++-
net/d80211/sta_info.h|2 +-
6 files changed, 13 insertions(+), 14 deletions(-)
53c1534ebad3c02a67517ed7339c76140812947e
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index ff6718b..cded685 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -277,7 +277,7 @@ static int ieee80211_ioctl_add_sta(struc
sta = sta_info_get(local, param->sta_addr);
if (!sta) {
- sta = sta_info_add(local, dev, param->sta_addr);
+ sta = sta_info_add(local, dev, param->sta_addr, GFP_KERNEL);
if (!sta)
return -ENOMEM;
}
diff --git a/net/d80211/ieee80211_rate.h b/net/d80211/ieee80211_rate.h
index 60e4879..04c7465 100644
--- a/net/d80211/ieee80211_rate.h
+++ b/net/d80211/ieee80211_rate.h
@@ -52,7 +52,7 @@ struct rate_control_ops {
void *(*alloc)(struct ieee80211_local *local);
void (*free)(void *priv);
- void *(*alloc_sta)(void *priv);
+ void *(*alloc_sta)(void *priv, gfp_t gfp);
void (*free_sta)(void *priv, void *priv_sta);
int (*add_attrs)(void *priv, struct kobject *kobj);
@@ -112,9 +112,10 @@ static inline void rate_control_clear(st
ref->ops->clear(ref->priv);
}
-static inline void *rate_control_alloc_sta(struct rate_control_ref *ref)
+static inline void *rate_control_alloc_sta(struct rate_control_ref *ref,
+ gfp_t gfp)
{
- return ref->ops->alloc_sta(ref->priv);
+ return ref->ops->alloc_sta(ref->priv, gfp);
}
static inline void rate_control_free_sta(struct rate_control_ref *ref,
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index ed6747a..480e9c9 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1158,7 +1158,7 @@ static void ieee80211_rx_mgmt_assoc_resp
/* Add STA entry for the AP */
sta = sta_info_get(local, ifsta->bssid);
if (!sta) {
- sta = sta_info_add(local, dev, ifsta->bssid);
+ sta = sta_info_add(local, dev, ifsta->bssid, GFP_ATOMIC);
if (!sta) {
printk(KERN_DEBUG "%s: failed to add STA entry for the"
" AP\n", dev->name);
@@ -2832,7 +2832,7 @@ struct sta_info * ieee80211_ibss_add_sta
printk(KERN_DEBUG "%s: Adding new IBSS station " MAC_FMT " (dev=%s)\n",
dev->name, MAC_ARG(addr), sta_dev->name);
- sta = sta_info_add(local, dev, addr);
+ sta = sta_info_add(local, dev, addr, GFP_ATOMIC);
if (!sta)
return NULL;
diff --git a/net/d80211/rc80211_simple.c b/net/d80211/rc80211_simple.c
index 055a167..3634d00 100644
--- a/net/d80211/rc80211_simple.c
+++ b/net/d80211/rc80211_simple.c
@@ -305,11 +305,11 @@ static void rate_control_simple_clear(vo
}
-static void * rate_control_simple_alloc_sta(void *priv)
+static void * rate_control_simple_alloc_sta(void *priv, gfp_t gfp)
{
struct sta_rate_control *rctrl;
- rctrl = kzalloc(sizeof(*rctrl), GFP_ATOMIC);
+ rctrl = kzalloc(sizeof(*rctrl), gfp);
return rctrl;
}
diff --git a/net/d80211/sta_info.c b/net/d80211/sta_info.c
index a177d2f..c18365b 100644
--- a/net/d80211/sta_info.c
+++ b/net/d80211/sta_info.c
@@ -130,16 +130,14 @@ void sta_info_release(struct kobject *ko
struct sta_info * sta_info_add(struct ieee80211_local *local,
- struct net_device *dev, u8 *addr)
+ struct net_device *dev, u8 *addr, gfp_t gfp)
{
struct sta_info *sta;
- sta = kmalloc(sizeof(*sta), GFP_ATOMIC);
+ sta = kzalloc(sizeof(*sta), gfp);
if (!sta)
return NULL;
- memset(sta, 0, sizeof(*sta));
-
if (kobject_set_name(&sta->kobj, MAC_FMT, MAC_ARG(addr))) {
kfree(sta);
return NULL;
@@ -148,7 +146,7 @@ struct sta_info * sta_info_add(struct ie
kobject_init(&sta->kobj);
sta->rate_ctrl = rate_control_get(local->rate_ctrl);
- sta->rate_ctrl_priv = rate_control_alloc_sta(sta->rate_ctrl);
+ sta->rate_ctrl_priv = rate_control_alloc_sta(sta->rate_ctrl, gfp);
if (!sta->rate_ctrl_priv) {
rate_control_put(sta->rate_ctrl);
kobject_put(&sta->kobj);
diff --git a/net/d80211/sta_info.h b/net/d80211/sta_info.h
index 9bd7e0d..ed1a104 100644
--- a/net/d80211/sta_info.h
+++ b/net/d80211/sta_info.h
@@ -133,7 +133,7 @@ struct sta_info * sta_info_get(struct ie
int sta_info_min_txrate_get(struct ieee80211_local *local);
void sta_i
d80211: for testing only: really stupid rate control algorithm
This is a rate control algorithm intended for the testing of rate modules
changing. It's name is "lowest". It uses always the lowest rate available.
Usage:
echo -n lowest > /sys/class/ieee80211/phy0/rate_ctrl_alg
---
net/d80211/Makefile |2 -
net/d80211/rc80211_lowest.c | 106 +++
2 files changed, 107 insertions(+), 1 deletions(-)
create mode 100644 net/d80211/rc80211_lowest.c
5b994b344d168fae604c7c4270a651d562d4701d
diff --git a/net/d80211/Makefile b/net/d80211/Makefile
index d5d4d41..d02c2d6 100644
--- a/net/d80211/Makefile
+++ b/net/d80211/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_D80211) += 80211.o rc80211_simple.o
+obj-$(CONFIG_D80211) += 80211.o rc80211_simple.o rc80211_lowest.o
80211-objs-$(CONFIG_D80211_LEDS) += ieee80211_led.o
diff --git a/net/d80211/rc80211_lowest.c b/net/d80211/rc80211_lowest.c
new file mode 100644
index 000..e1b6ccf
--- /dev/null
+++ b/net/d80211/rc80211_lowest.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2002-2005, Instant802 Networks, Inc.
+ * Copyright 2005, Devicescape Software, Inc.
+ * Copyright (c) 2006 Jiri Benc <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "ieee80211_i.h"
+#include "ieee80211_rate.h"
+
+static void rate_control_lowest_tx_status(void *priv, struct net_device *dev,
+ struct sk_buff *skb,
+ struct ieee80211_tx_status *status)
+{
+}
+
+static struct ieee80211_rate *
+rate_control_lowest_get_rate(void *priv, struct net_device *dev,
+struct sk_buff *skb,
+struct rate_control_extra *extra)
+{
+ struct ieee80211_local *local = dev->ieee80211_ptr;
+ int i;
+
+ for (i = 0; i < local->num_curr_rates; i++) {
+ struct ieee80211_rate *rate = &local->curr_rates[i];
+
+ if (rate->flags & IEEE80211_RATE_SUPPORTED)
+ return rate;
+ }
+ return &local->curr_rates[0];
+}
+
+static void rate_control_lowest_rate_init(void *priv, void *priv_sta,
+ struct ieee80211_local *local,
+ struct sta_info *sta)
+{
+ sta->txrate = 0;
+}
+
+static void *rate_control_lowest_alloc(struct ieee80211_local *local)
+{
+ return kzalloc(sizeof(int), GFP_KERNEL);
+}
+
+static void rate_control_lowest_free(void *priv)
+{
+ kfree(priv);
+}
+
+static void rate_control_lowest_clear(void *priv)
+{
+}
+
+static void * rate_control_lowest_alloc_sta(void *priv, gfp_t gfp)
+{
+ return kzalloc(sizeof(int), gfp);
+}
+
+
+static void rate_control_lowest_free_sta(void *priv, void *priv_sta)
+{
+ kfree(priv_sta);
+}
+
+static struct rate_control_ops rate_control_lowest = {
+ .module = THIS_MODULE,
+ .name = "lowest",
+ .tx_status = rate_control_lowest_tx_status,
+ .get_rate = rate_control_lowest_get_rate,
+ .rate_init = rate_control_lowest_rate_init,
+ .clear = rate_control_lowest_clear,
+ .alloc = rate_control_lowest_alloc,
+ .free = rate_control_lowest_free,
+ .alloc_sta = rate_control_lowest_alloc_sta,
+ .free_sta = rate_control_lowest_free_sta,
+};
+
+static int __init rate_control_lowest_init(void)
+{
+ return ieee80211_rate_control_register(&rate_control_lowest);
+}
+
+
+static void __exit rate_control_lowest_exit(void)
+{
+ ieee80211_rate_control_unregister(&rate_control_lowest);
+}
+
+
+module_init(rate_control_lowest_init);
+module_exit(rate_control_lowest_exit);
+
+MODULE_DESCRIPTION("Testing rate control algorithm for ieee80211");
+MODULE_LICENSE("GPL");
--
1.3.0
-
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
[PATCH 4/8] d80211: proper rate_control loading
Fix locking issues with loading of rate_control modules. This still doesn't
allow changing of the modules on the fly.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/Makefile |1
net/d80211/ieee80211.c | 108 ++-
net/d80211/ieee80211_rate.c | 92 +
net/d80211/ieee80211_rate.h |8 ++-
net/d80211/rate_control.c |3 +
5 files changed, 136 insertions(+), 76 deletions(-)
create mode 100644 net/d80211/ieee80211_rate.c
57da83fffc22dc16bc244a4453a09c8a177d881e
diff --git a/net/d80211/Makefile b/net/d80211/Makefile
index 2a2a0c6..27d90e5 100644
--- a/net/d80211/Makefile
+++ b/net/d80211/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_D80211) += 80211.o rate_con
ieee80211_sta.o \
ieee80211_dev.o \
ieee80211_iface.o \
+ ieee80211_rate.o \
ieee80211_sysfs.o \
ieee80211_sysfs_sta.o \
michael.o \
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index b138eb0..8c4a6d6 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -46,16 +46,6 @@ static unsigned char eapol_header[] =
{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00, 0x88, 0x8e };
-struct rate_control_algs {
- struct rate_control_algs *next;
- struct rate_control_ops *ops;
-};
-
-static struct rate_control_algs *ieee80211_rate_ctrl_algs;
-
-static int rate_control_initialize(struct ieee80211_local *local);
-
-
static u8 * ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len);
static int ieee80211_mgmt_start_xmit(struct sk_buff *skb,
@@ -4312,6 +4302,39 @@ static void ieee80211_precalc_modes(stru
}
}
+static int rate_control_initialize(struct ieee80211_local *local)
+{
+ struct rate_control_ops *ops;
+
+ ops = ieee80211_rate_control_ops_get(NULL);
+ if (!ops) {
+ printk(KERN_WARNING "%s: Failed to select rate control "
+ "algorithm\n", local->mdev->name);
+ return -1;
+ }
+ local->rate_ctrl_priv = rate_control_alloc(ops, local);
+ if (!local->rate_ctrl_priv) {
+ ieee80211_rate_control_ops_put(ops);
+ return -1;
+ }
+ local->rate_ctrl = ops;
+
+ printk(KERN_DEBUG "%s: Selected rate control "
+ "algorithm '%s'\n", local->mdev->name,
+ local->rate_ctrl->name);
+
+ return 0;
+}
+
+static void rate_control_deinitialize(struct ieee80211_local *local)
+{
+ struct rate_control_ops *ops;
+
+ rate_control_free(local);
+ ops = local->rate_ctrl;
+ local->rate_ctrl = NULL;
+ ieee80211_rate_control_ops_put(ops);
+}
struct net_device *ieee80211_alloc_hw(size_t priv_data_len,
void (*setup)(struct net_device *))
@@ -4520,7 +4543,7 @@ int ieee80211_register_hw(struct net_dev
return 0;
fail_rate_attrs:
- rate_control_free(local);
+ rate_control_deinitialize(local);
fail_rate:
ieee80211_sysfs_remove_netdevice(dev);
fail_if_sysfs:
@@ -4639,7 +4662,7 @@ EXPORT_SYMBOL(ieee80211_free_hw);
void ieee80211_release_hw(struct ieee80211_local *local)
{
- rate_control_free(local);
+ rate_control_deinitialize(local);
kfree(local);
}
@@ -4742,67 +4765,6 @@ void * ieee80211_dev_stats(struct net_de
}
EXPORT_SYMBOL(ieee80211_dev_stats);
-int ieee80211_rate_control_register(struct rate_control_ops *ops)
-{
- struct rate_control_algs *alg;
-
- alg = kzalloc(sizeof(*alg), GFP_KERNEL);
- if (!alg)
- return -1;
-
- alg->next = ieee80211_rate_ctrl_algs;
- alg->ops = ops;
- ieee80211_rate_ctrl_algs = alg;
-
- return 0;
-}
-EXPORT_SYMBOL(ieee80211_rate_control_register);
-
-void ieee80211_rate_control_unregister(struct rate_control_ops *ops)
-{
- struct rate_control_algs *alg, *prev;
-
- prev = NULL;
- alg = ieee80211_rate_ctrl_algs;
- while (alg) {
- if (alg->ops == ops) {
- if (prev)
- prev->next = alg->next;
- else
- ieee80211_rate_ctrl_algs = alg->next;
- kfree(alg);
- break;
- }
- prev = alg;
- alg = alg->next;
- }
-}
-EXPORT_SYMBOL(ieee80211_rate_control_unregister);
-
-static int rate_control_initialize(struct ieee80211_local *local)
-{
- struct rate_control_algs *algs;
-
- if (!ieee80211_rate_ctrl_algs)
- request_module("ieee80211_rate_control");
-
- for (algs = ieee80211_rate_ctrl_algs; algs; algs = algs->next) {
- local->rate_ctrl = algs->ops;
- local->rate_ctrl_priv = rate_control_alloc(local);
- if (local->rate_ctrl_priv) {
- printk(KERN_DEBUG "%s: Selected rate control "
- "algor
[PATCH 5/8] d80211: rename rate_control.c to rc80211_simple.c
To support changing of the rate control modules on the fly we need
well-defined names of the modules.
Let it be rc80211_*. Rename the only one rate control module
(rate_control.c) into rc80211_simple.c. The module alias for the default
module is changed to rc80211_default.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/Makefile |2
net/d80211/rate_control.c | 395 ---
net/d80211/rc80211_simple.c | 395 +++
3 files changed, 396 insertions(+), 396 deletions(-)
delete mode 100644 net/d80211/rate_control.c
create mode 100644 net/d80211/rc80211_simple.c
f1d25465387bf4b09b505d90daafaff0e276060a
diff --git a/net/d80211/Makefile b/net/d80211/Makefile
index 27d90e5..d5d4d41 100644
--- a/net/d80211/Makefile
+++ b/net/d80211/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_D80211) += 80211.o rate_control.o
+obj-$(CONFIG_D80211) += 80211.o rc80211_simple.o
80211-objs-$(CONFIG_D80211_LEDS) += ieee80211_led.o
diff --git a/net/d80211/rate_control.c b/net/d80211/rate_control.c
deleted file mode 100644
index 6703931..000
--- a/net/d80211/rate_control.c
+++ /dev/null
@@ -1,395 +0,0 @@
-/*
- * Copyright 2002-2005, Instant802 Networks, Inc.
- * Copyright 2005, Devicescape Software, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include "ieee80211_i.h"
-#include "ieee80211_rate.h"
-
-
-/* This is a minimal implementation of TX rate controlling that can be used
- * as the default when no improved mechanisms are available. */
-
-
-#define RATE_CONTROL_EMERG_DEC 2
-#define RATE_CONTROL_INTERVAL (HZ / 20)
-#define RATE_CONTROL_MIN_TX 10
-
-MODULE_ALIAS("rc80211_default");
-
-static void rate_control_rate_inc(struct ieee80211_local *local,
- struct sta_info *sta)
-{
-struct ieee80211_sub_if_data *sdata;
- int i = sta->txrate;
- int maxrate;
-
-sdata = IEEE80211_DEV_TO_SUB_IF(sta->dev);
- if (sdata->bss && sdata->bss->force_unicast_rateidx > -1) {
- /* forced unicast rate - do not change STA rate */
- return;
- }
-
- maxrate = sdata->bss ? sdata->bss->max_ratectrl_rateidx : -1;
-
- if (i > local->num_curr_rates)
- i = local->num_curr_rates - 2;
-
- while (i + 1 < local->num_curr_rates) {
- i++;
- if (sta->supp_rates & BIT(i) &&
- local->curr_rates[i].flags & IEEE80211_RATE_SUPPORTED &&
- (maxrate < 0 || i <= maxrate)) {
- sta->txrate = i;
- break;
- }
- }
-}
-
-
-static void rate_control_rate_dec(struct ieee80211_local *local,
- struct sta_info *sta)
-{
-struct ieee80211_sub_if_data *sdata;
- int i = sta->txrate;
-
-sdata = IEEE80211_DEV_TO_SUB_IF(sta->dev);
- if (sdata->bss && sdata->bss->force_unicast_rateidx > -1) {
- /* forced unicast rate - do not change STA rate */
- return;
- }
-
- if (i > local->num_curr_rates)
- i = local->num_curr_rates;
-
- while (i > 0) {
- i--;
- if (sta->supp_rates & BIT(i) &&
- local->curr_rates[i].flags & IEEE80211_RATE_SUPPORTED) {
- sta->txrate = i;
- break;
- }
- }
-}
-
-
-static struct ieee80211_rate *
-rate_control_lowest_rate(struct ieee80211_local *local)
-{
- int i;
-
- for (i = 0; i < local->num_curr_rates; i++) {
- struct ieee80211_rate *rate = &local->curr_rates[i];
-
- if (rate->flags & IEEE80211_RATE_SUPPORTED
- )
- return rate;
- }
-
- printk(KERN_DEBUG "rate_control_lowest_rate - no supported rates "
- "found\n");
- return &local->curr_rates[0];
-}
-
-
-struct global_rate_control {
- int dummy;
-};
-
-struct sta_rate_control {
-unsigned long last_rate_change;
-u32 tx_num_failures;
-u32 tx_num_xmit;
-
-unsigned long avg_rate_update;
-u32 tx_avg_rate_sum;
-u32 tx_avg_rate_num;
-};
-
-
-static void rate_control_simple_tx_status(struct net_device *dev,
- struct sk_buff *skb,
- struct ieee80211_tx_status *status)
-{
- struct ieee80211_local *local = dev->ieee80211_ptr;
- struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
- struct sta_info *sta;
- struct sta_rate_control *srctrl;
-
-sta = sta_info_get(local, hdr->addr1);
-
- if (!sta)
-return;
[PATCH 1/8] d80211: add missing rtnl_unlock()
Add forgotten rtnl_unlock() in the error path of ieee80211_register_hw.
Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
a0ed5768c0c3b9481dda8b59f6a183e000451acf
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 3efba6a..036eca1 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4449,8 +4449,10 @@ int ieee80211_register_hw(struct net_dev
result = sysfs_create_link(&local->class_dev.kobj,
&dev->class_dev.kobj,
"master");
- if (result < 0)
+ if (result < 0) {
+ rtnl_unlock();
goto fail_masterlink;
+ }
result = ieee80211_sysfs_add_netdevice(dev);
rtnl_unlock();
if (result < 0)
--
1.3.0
-
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
[PATCH v2 1/1] NetLabel: secid reconciliation support
This patch provides the missing NetLabel support to the secid reconciliation
patchset.
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
security/selinux/hooks.c| 67 +++--
security/selinux/include/objsec.h |1
security/selinux/include/selinux_netlabel.h | 28 +++
security/selinux/ss/services.c | 106 ++--
4 files changed, 98 insertions(+), 104 deletions(-)
Index: net-2.6/security/selinux/hooks.c
===
--- net-2.6.orig/security/selinux/hooks.c
+++ net-2.6/security/selinux/hooks.c
@@ -3465,6 +3465,10 @@ static int selinux_sock_rcv_skb_compat(s
goto out;
}
+ err = selinux_netlbl_sock_rcv_skb(sock_sid, sock_class, skb, ad);
+ if (err)
+ goto out;
+
err = selinux_xfrm_sock_rcv_skb(sock_sid, skb, ad);
out:
@@ -3501,10 +3505,7 @@ static int selinux_socket_sock_rcv_skb(s
else
err = avc_has_perm(sksec->sid, skb->secmark, SECCLASS_PACKET,
PACKET__RECV, &ad);
- if (err)
- goto out;
- err = selinux_netlbl_sock_rcv_skb(sksec, skb, &ad);
out:
return err;
}
@@ -3527,11 +3528,8 @@ static int selinux_socket_getpeersec_str
peer_sid = ssec->peer_sid;
}
else if (isec->sclass == SECCLASS_TCP_SOCKET) {
- peer_sid = selinux_netlbl_socket_getpeersec_stream(sock);
- if (peer_sid == SECSID_NULL) {
- ssec = sock->sk->sk_security;
- peer_sid = ssec->peer_sid;
- }
+ ssec = sock->sk->sk_security;
+ peer_sid = ssec->peer_sid;
if (peer_sid == SECSID_NULL) {
err = -ENOPROTOOPT;
goto out;
@@ -3573,13 +3571,13 @@ static int selinux_socket_getpeersec_dgr
if (sock && (sock->sk->sk_family == PF_UNIX))
selinux_get_inode_sid(SOCK_INODE(sock), &peer_secid);
else if (skb) {
- peer_secid = selinux_netlbl_socket_getpeersec_dgram(skb);
- if (peer_secid == SECSID_NULL) {
- if (selinux_compat_net)
+ if (selinux_compat_net) {
+ peer_secid = selinux_netlbl_socket_getpeersec_dgram(
+ skb);
+ if (peer_secid == SECSID_NULL)
peer_secid = selinux_socket_getpeer_dgram(skb);
- else
- peer_secid = skb->secmark;
- }
+ } else
+ peer_secid = skb->secmark;
}
if (peer_secid == SECSID_NULL)
@@ -3641,13 +3639,11 @@ static int selinux_inet_conn_request(str
u32 newsid;
u32 peersid;
- newsid = selinux_netlbl_inet_conn_request(skb, sksec->sid);
- if (newsid != SECSID_NULL) {
- req->secid = newsid;
- return 0;
- }
-
if (selinux_compat_net) {
+ err = selinux_netlbl_skb_sid(skb, sksec->sid, &peersid);
+ if (err == 0 && peersid != SECSID_NULL)
+ goto out;
+
err = selinux_xfrm_decode_session(skb, &peersid, 0);
BUG_ON(err);
@@ -3659,6 +3655,7 @@ static int selinux_inet_conn_request(str
} else
peersid = skb->secmark;
+out:
err = security_sid_mls_copy(sksec->sid, peersid, &newsid);
if (err)
return err;
@@ -3700,6 +3697,7 @@ static void selinux_req_classify_flow(co
static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
{
u32 xfrm_sid;
+ u32 nlbl_sid;
int err;
if (selinux_compat_net)
@@ -3725,7 +3723,16 @@ static int selinux_skb_flow_in(struct sk
if (xfrm_sid)
skb->secmark = xfrm_sid;
- /* See if NetLabel can flow in thru the current secmark here */
+ err = selinux_netlbl_skb_sid(skb, skb->secmark, &nlbl_sid);
+ BUG_ON(err);
+
+ err = avc_has_perm(nlbl_sid, skb->secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (nlbl_sid)
+ skb->secmark = nlbl_sid;
out:
return err ? 0 : 1;
@@ -3740,6 +3747,7 @@ static int selinux_skb_flow_out(struct s
if (!skb->secmark) {
u32 xfrm_sid;
+ u32 nlbl_sid;
selinux_skb_xfrm_sid(skb, &xfrm_sid);
@@ -3749,6 +3757,12 @@ static int selinux_skb_flow_out(struct s
struct sk_security_struct *sksec = skb->sk->sk_security;
skb->secmark = sksec->sid;
}
+
+ err = selinux_netlbl_skb_sid(skb, skb->secmark, &nlbl_sid);
+ BUG_ON(err);
+
+
[PATCH v2 0/1] Respun patch to match the latest secid patchset
This patchset is against the net-2.6 tree from this morning plus the secid patches posted by Venkat yesterday night. Unfortunately the net-2.6 trees from the past few days seem to have problems booting on my test machine, so testing of this patch has been ... well ... "minimal". However, I know there are a lot of deadlines floating around right now so I thought it best to post this ASAP. This patch is basically what I posted last week plus some changes to make use of the secid patches support of the peer_sid field in the sk_security_struct. NetLabel used the field previously but had to special case it's handling since it was the only user for INET sockets, the secid patchset makes this much cleaner. There are most likely additional NetLabel specific cleanups that can be made, but considering my testing problems I thought it best to play it as safe as possibile with this patch. I'll deal with the other cleanups once I can prove them during testing. Please consider this for inclusion in 2.6.19. -- paul moore linux security @ hp - 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
Re: 2.6.18-mm2 - oops in cache_alloc_refill()
On Fri, Sep 29, 2006 at 06:20:08PM -0700, Andrew Morton wrote:
> On Fri, 29 Sep 2006 20:01:54 -0400
> >
> > % grep ioctl /tmp/foo2 | sort -u | more
> > ioctl(13, SIOCGIWESSID, 0xbfbcdb9c) = 0
> > ioctl(13, SIOCGIWRANGE, 0xbfbcdbdc) = 0
> > ioctl(13, SIOCGIWRATE, 0xbfbcdbbc) = 0
>
> Yes. The main thing which those WE-21 patches do is to shorten the size of
> various buffers which are used in wireless ioctls.
Ok, I've found it. Actually, I feel ashamed, as it is a fairly
classical buffer overflow, we put one extra char in a buffer. Now, I
don't understand why it did not blow up on my box ;-)
New patch. I think it is right, but I would not mind Pavel to
have a look at it. On my box it does not make thing worse.
Valdis : would you mind trying if this patch fix the problem
you are seeing with WE-21 ? If it fixes it, I'll send it to John...
Have fun...
Jean
P.S. : I'll audit the other wireless drivers for the same thing.
-
diff -u -p linux/drivers/net/wireless/orinoco.j1.c
linux/drivers/net/wireless/orinoco.c
--- linux/drivers/net/wireless/orinoco.j1.c 2006-10-02 10:15:41.0
-0700
+++ linux/drivers/net/wireless/orinoco.c2006-10-02 10:39:20.0
-0700
@@ -2456,6 +2456,7 @@ void free_orinocodev(struct net_device *
/* Wireless extensions */
//
+/* Return : < 0 -> error code ; >= 0 -> length */
static int orinoco_hw_get_essid(struct orinoco_private *priv, int *active,
char buf[IW_ESSID_MAX_SIZE+1])
{
@@ -2500,9 +2501,9 @@ static int orinoco_hw_get_essid(struct o
len = le16_to_cpu(essidbuf.len);
BUG_ON(len > IW_ESSID_MAX_SIZE);
- memset(buf, 0, IW_ESSID_MAX_SIZE+1);
+ memset(buf, 0, IW_ESSID_MAX_SIZE);
memcpy(buf, p, len);
- buf[len] = '\0';
+ err = len;
fail_unlock:
orinoco_unlock(priv, &flags);
@@ -3026,17 +3027,18 @@ static int orinoco_ioctl_getessid(struct
if (netif_running(dev)) {
err = orinoco_hw_get_essid(priv, &active, essidbuf);
- if (err)
+ if (err < 0)
return err;
+ erq->length = err;
} else {
if (orinoco_lock(priv, &flags) != 0)
return -EBUSY;
- memcpy(essidbuf, priv->desired_essid, IW_ESSID_MAX_SIZE + 1);
+ memcpy(essidbuf, priv->desired_essid, IW_ESSID_MAX_SIZE);
+ erq->length = strlen(priv->desired_essid);
orinoco_unlock(priv, &flags);
}
erq->flags = 1;
- erq->length = strlen(essidbuf);
return 0;
}
@@ -3074,10 +3076,10 @@ static int orinoco_ioctl_getnick(struct
if (orinoco_lock(priv, &flags) != 0)
return -EBUSY;
- memcpy(nickbuf, priv->nick, IW_ESSID_MAX_SIZE+1);
+ memcpy(nickbuf, priv->nick, IW_ESSID_MAX_SIZE);
orinoco_unlock(priv, &flags);
- nrq->length = strlen(nickbuf);
+ nrq->length = strlen(priv->nick);
return 0;
}
-
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
[PATCH] wext
This patch (wext-patch) is a proposal. It adds two new defines for the SIOCSIWMLME to cover all kinds MLMEs (well, except REASSOC) through a ioctl. (it would be nice to have them, so that I can post the hostapd code for the prism54 card!) I didn't update the changelog! but this should be done in a matter of seconds. diffstat wext-patch wireless.h | 2 ++ 1 file changed, 2 insertions(+) Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]> Regards, Chr. Lamparter --- a/include/linux/wireless.h 2006-10-01 03:24:01.0 +0200 +++ b/include/linux/wireless.h 2006-10-01 03:24:38.0 +0200 @@ -546,6 +546,8 @@ /* MLME requests (SIOCSIWMLME / struct iw_mlme) */ #define IW_MLME_DEAUTH 0 #define IW_MLME_DISASSOC 1 +#define IW_MLME_AUTH 2 +#define IW_MLME_ASSOC 3 /* SIOCSIWAUTH/SIOCGIWAUTH struct iw_param flags */ #define IW_AUTH_INDEX 0x0FFF
Re: [PATCH 6/6]: powerpc/cell spidernet refine locking
On Fri, Sep 29, 2006 at 07:47:52PM -0700, Andrew Morton wrote: > On Fri, 29 Sep 2006 18:29:11 -0500 > [EMAIL PROTECTED] (Linas Vepstas) wrote: > > > The transmit side of the spider ethernet driver currently > > places locks around some very large chunks of code. This > > results in a fair amount of lock contention is some cases. > > This patch makes the locks much more fine-grained, protecting > > only the cirtical sections. One lock is used to protect > > three locations: the queue head and tail pointers, and the > > queue low-watermark location. > > You have spider_net_set_low_watermark() walking the tx_chain outside > tx_chain.lock. Are you sure about that? Yes. Its making an approximate count of the queue length, and I figured that if its approximate to begin with, an unlocked version should be just fine. --linas - 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
Re: [PATCH 7/9] secid reconciliation-v04: Enforcement for SELinux
Venkat Yekkirala wrote: >>My immediate concern is not really what selinux_xfrm_decode_session() >>returns, but how to handle it, or rather errors in general, in >>selinux_skb_flow_in(). I'm in the process of creating a patch to add >>the missing NetLabel support to the secid patches and I am >>wondering if >>I should BUG_ON() for an error condition or simply jump to "out". >>Jumping seems a bit cleaner to me, although perhaps harder to >>debug, so >>I was just wondering what the reasoning was behind the use of >>BUG_ON(). > > > It's more a "code integrity" check that I have sought to enforce > via BUG_ON (meaning the function isn't expected to fail under any > circumstances). Whether this is a severe enough error (possible as > a result of a bug in decode_session or a corrupted kernel) that we > should panic the system at that point is probably debatable. In particular > I would be interested to know how similar situations are currently > treated in the kernel. > > My recommendation would be to be consistent with the rest of the code > and do a BUG_ON. That was how I was leaning and for the same reasons, I'll go that route and if we need we can always change it later. > As for other errors, you could jump out like the rest > of the code already does (if that meets your needs that is). -- paul moore linux security @ hp - 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
RE: [PATCH 7/9] secid reconciliation-v04: Enforcement for SELinux
> My immediate concern is not really what selinux_xfrm_decode_session() > returns, but how to handle it, or rather errors in general, in > selinux_skb_flow_in(). I'm in the process of creating a patch to add > the missing NetLabel support to the secid patches and I am > wondering if > I should BUG_ON() for an error condition or simply jump to "out". > Jumping seems a bit cleaner to me, although perhaps harder to > debug, so > I was just wondering what the reasoning was behind the use of > BUG_ON(). It's more a "code integrity" check that I have sought to enforce via BUG_ON (meaning the function isn't expected to fail under any circumstances). Whether this is a severe enough error (possible as a result of a bug in decode_session or a corrupted kernel) that we should panic the system at that point is probably debatable. In particular I would be interested to know how similar situations are currently treated in the kernel. My recommendation would be to be consistent with the rest of the code and do a BUG_ON. As for other errors, you could jump out like the rest of the code already does (if that meets your needs that is). - 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
Re: [PATCH 0/6]: powerpc/cell spidernet ethernet patches
On Mon, Oct 02, 2006 at 06:50:39PM +0200, Arnd Bergmann wrote: > On Monday 02 October 2006 18:27, Linas Vepstas wrote: > > > > > > I'm not sure if I have missed a patch in here, but I > > > don't see anything reintroducing the 'netif_stop_queue' > > > that is missing from the transmit path. > > > > > > Do you have a extra patch for that? > > > > Unfinished. There are several ways in which the current > > spider-net driver doesn't do things the way Greg KH's, etal > > book on device drivers recommends. I was planning on combing > > through these this week. > > Ok, that's good. However, removing the netif_stop_queue > was an obvious oversight that happened during the cleanup > last year. > > Putting that one line back in should be a really safe fix for > the problem of overly high system load we sometimes see. Hmm. I have a patch from 5 weeks ago that seems to insert a bunch of these. I'm not sure why it hadn't been mailed before, I'll test and post as soon as I can. --linas - 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
RE: [PATCH] Fix for IPsec leakage with SELinux enabled
> 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,
> >
> > Given that the resolver fails to find a policy here, I am trying to
> > understand what exactly is blocking it (the first SYNACK) from
> > proceeding without IPSec.
>
> You're right. My explanation there was for the case where
> I'd modified
> the code to propagate the SELinux denial back to
> xfrm_lookup(), and not
> for the original issue (sorry, it's been a long week).
>
> In the original case, all packets originating from a confined
> domain will
> bypass ipsec. During xfrm_lookup, flow_cache_lookup() returns NULL
> policy:
>
> xfrm_lookup()
> {
> ...
>
> if (!policy) {
> /* To accelerate a bit... */
> if ((dst_orig->flags & DST_NOXFRM) ||
> !xfrm_policy_count[XFRM_POLICY_OUT])
> return 0;
>
> policy = flow_cache_lookup(fl, dst_orig->ops->family,
>dir, xfrm_policy_lookup);
> }
>
> if (!policy)
> return 0; <- bad
> ...
> }
>
> The call chain is:
>
> flow_cache_lookup()
> xfrm_policy_lookup()
>xfrm_policy_lookup_bytype()
> xfrm_policy_match() {
>xfrm_selector_match => returns true, then
> security_xfrm_policy_lookup => returns -EACCESS
> }
>
> then
>
> xfrm_policy_match() => returns 0
> xfrm_policy_lookup_bytype => returns 0
> xfrm_policy_lookup() => sets obj to NULL w/ void return
> flow_cache_lookup() => returns NULL
> xfrm_lookup => returns 0
>
> and the packet proceeds without error and with no transform
> applied (i.e.
> leaked as cleartext).
This is indeed the "designed" and expected (for me) behavior. But I am
beginning to see where this is perhaps NOT in line with the user
expectation when the users have an IPSec policy rule that does NOT use
labels.
IOW, if they have their policy like (NO LABELS):
spdadd 192.168.4.79 192.168.4.78 any -P out ipsec
esp/transport//require;
spdadd 192.168.4.78 192.168.4.79 any -P in ipsec
esp/transport//require;
currently, EACH flow needing to use this rule MUST
have SELinux policy "polmatch"ing the flow context (ftpd_t)
to unlabeled_t (the implied in the absence of an explicit
context on the IPSec policy rule) or the traffic would flow
in clear text ("leaks" in user perception).
What I propose we do is to do the polmatch check ONLY when
there's an explicit label associated with the spd rule. Does
this sound reasonable and correct in the larger SELinux context?
In cases where there's an explicit label on an spd rule like:
spdadd 192.168.4.79 192.168.4.78 any -ctx 1 1
"system_u:object_r:labeled_ipsec_t:s2-s4"
-P out ipsec
esp/transport//require;
spdadd 192.168.4.78 192.168.4.79 any -ctx 1 1
"system_u:object_r:labeled_ipsec_t:s2-s4"
-P in ipsec
esp/transport//require;
then the current behavior (prior to this proposed patch) would be the
desired behavior, i.e., a polmatch denial in the SELinux module just
means that the flow isn't expected to undergo IPSec xfrms. IOW, there's
no need to propagate -EACCES all the way back up. We could still propagate
errors other than -EACCES if we like.
>
> The first component of the fix is to propagate errors back up
> to callers
> via the flow cache resolver, and handle them correctly, as
> this is where
> we can experience security module denials.
This will cause problems with the case where we may have multiple
"labeled" spd rules, each of which should be attempted to be polmatched
against before letting the flow out in clear text, as would be expected
by the user as well.
>
> The second component is to then ensure that, on failure,
-EACCES in this case is perceived as a failure since the
designed behavior doesn't seem to be in line with the user
expectation. Otherwise, with the above proposed change to
the design, there won't be a polmatch check in this case and
hence no failure.
It's probably still a good idea to propagate non-EACCES failures
back up the chain though.
> we
> kill the new
> flow cache entry created during lookup, so that it is not
> subsequently
> looked up with a null policy (i.e. allowing future packets to
> leak) and to
> force the security hook to be called again in case the policy
> has changed.
>
> Hope that clarifies.
>
>
> - James
> --
> James Morris
> <[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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6]: powerpc/cell spidernet ethtool -i version number info.
On Sat, Sep 30, 2006 at 12:33:45PM +0200, Arnd Bergmann wrote:
> Am Saturday 30 September 2006 01:21 schrieb Linas Vepstas:
> >
> > static int __init spider_net_init(void)
> > {
> > + printk("spidernet Version %s.\n",VERSION);
> > +
>
> This is missing a printk level and a space character.
Revised patch below.
> More importantly,
> you should not print the presence of the driver to the syslog, but
> the presence of a device driven by it.
Most device drivers seem to print version numbers in the module_init
routines (i.e. right before calling pci_register_driver), rather than
in the probe routines; so this patch follows this convention.
--linas
This patch adds version information as reported by
ethtool -i to the Spidernet driver.
From: James K Lewis <[EMAIL PROTECTED]>
Signed-off-by: James K Lewis <[EMAIL PROTECTED]>
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
drivers/net/spider_net.c |3 +++
drivers/net/spider_net.h |2 ++
drivers/net/spider_net_ethtool.c |2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.18-mm2/drivers/net/spider_net.c
===
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.c 2006-09-29
16:44:17.0 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.c 2006-10-02 12:00:15.0
-0500
@@ -55,6 +55,7 @@ MODULE_AUTHOR("Utz Bacher <[EMAIL PROTECTED]
"<[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Spider Southbridge Gigabit Ethernet driver");
MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION);
static int rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_DEFAULT;
static int tx_descriptors = SPIDER_NET_TX_DESCRIPTORS_DEFAULT;
@@ -2303,6 +2304,8 @@ static struct pci_driver spider_net_driv
*/
static int __init spider_net_init(void)
{
+ printk(KERN_INFO "Spidernet version %s.\n", VERSION);
+
if (rx_descriptors < SPIDER_NET_RX_DESCRIPTORS_MIN) {
rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_MIN;
pr_info("adjusting rx descriptors to %i.\n", rx_descriptors);
Index: linux-2.6.18-mm2/drivers/net/spider_net.h
===
--- linux-2.6.18-mm2.orig/drivers/net/spider_net.h 2006-09-29
16:44:17.0 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net.h 2006-10-02 11:57:32.0
-0500
@@ -24,6 +24,8 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
+#define VERSION "1.1 A"
+
#include "sungem_phy.h"
extern int spider_net_stop(struct net_device *netdev);
Index: linux-2.6.18-mm2/drivers/net/spider_net_ethtool.c
===
--- linux-2.6.18-mm2.orig/drivers/net/spider_net_ethtool.c 2006-09-29
16:33:43.0 -0500
+++ linux-2.6.18-mm2/drivers/net/spider_net_ethtool.c 2006-09-29
16:44:18.0 -0500
@@ -76,7 +76,7 @@ spider_net_ethtool_get_drvinfo(struct ne
/* clear and fill out info */
memset(drvinfo, 0, sizeof(struct ethtool_drvinfo));
strncpy(drvinfo->driver, spider_net_driver_name, 32);
- strncpy(drvinfo->version, "0.1", 32);
+ strncpy(drvinfo->version, VERSION, 32);
strcpy(drvinfo->fw_version, "no information");
strncpy(drvinfo->bus_info, pci_name(card->pdev), 32);
}
-
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
Re: [PATCH 7/9] secid reconciliation-v04: Enforcement for SELinux
Stephen Smalley wrote:
> On Mon, 2006-10-02 at 12:12 -0400, Paul Moore wrote:
>
>>Venkat Yekkirala wrote:
>>
>>>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: Venkat Yekkirala <[EMAIL PROTECTED]>
>>>
>>>{snip}
>>>
>>>+static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
>>>+{
>>>+u32 xfrm_sid;
>>>+int err;
>>>+
>>>+if (selinux_compat_net)
>>>+return 1;
>>>+
>>>+/*
>>>+ * loopback traffic already labeled and
>>>+ * flow-controlled on outbound. We may
>>>+ * need to flow-control on the inbound
>>>+ * as well if there's ever a use-case for it.
>>>+ */
>>>+if (skb->dev == &loopback_dev)
>>>+return 1;
>>>+
>>>+err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0);
>>>+BUG_ON(err);
>>
>>Just a quick question that has been nagging me for awhile - any
>>particular reason why this is a BUG_ON() and not an "if (err) goto out;"?
>
> It appears that selinux_xfrm_decode_session() can only legitimately
> return an error if the last argument (ckall) is non-zero.
> security_skb_classify_flow() was doing the same thing prior to this
> patch series. It would be clearer if there were two separate interfaces
> that internally use the same helper, with one of the functions returning
> void.
My immediate concern is not really what selinux_xfrm_decode_session()
returns, but how to handle it, or rather errors in general, in
selinux_skb_flow_in(). I'm in the process of creating a patch to add
the missing NetLabel support to the secid patches and I am wondering if
I should BUG_ON() for an error condition or simply jump to "out".
Jumping seems a bit cleaner to me, although perhaps harder to debug, so
I was just wondering what the reasoning was behind the use of BUG_ON().
I honestly don't care at this point, it's a rather minor detail, I'd
just like to "do the right thing" with the NetLabel patch.
--
paul moore
linux security @ hp
-
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
Re: [PATCH 0/6]: powerpc/cell spidernet ethernet patches
On Monday 02 October 2006 18:27, Linas Vepstas wrote: > > > > I'm not sure if I have missed a patch in here, but I > > don't see anything reintroducing the 'netif_stop_queue' > > that is missing from the transmit path. > > > > Do you have a extra patch for that? > > Unfinished. There are several ways in which the current > spider-net driver doesn't do things the way Greg KH's, etal > book on device drivers recommends. I was planning on combing > through these this week. Ok, that's good. However, removing the netif_stop_queue was an obvious oversight that happened during the cleanup last year. Putting that one line back in should be a really safe fix for the problem of overly high system load we sometimes see. Arnd <>< - 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
Please pull bcm43xx-d80211 bugfixes and new features
Hi John, Please pull from my tree git pull http://bu3sch.de/git/wireless-dev.git for-linville This will pull various bugfixes and feature improvements. Most noteably it will pull a bugfix for a crash introduced by an earlier patch to d80211 which changed RX status information handling. The new features include support for the new v4 firmware. I also did my homework to get better support for OpenWRT devices in ssb. The list of pulled changesets is: Michael Buesch: ssb: Abstract bus accesses. bcm43xx-d80211: convert to ssb abstract bus access API bcm43xx-d80211: Don't crash if we use v4 firmware. bcm43xx-d80211: Always make fwpostfix option available. bcm43xx-d80211: Firmware revision/patchlevel detection. bcm43xx-d80211: Add support for v4 firmware. bcm43xx-d80211: add SHM constants bcm43xx-d80211: Don't use low level netif and ieee80211_netif_oper functions. bcm43xx-d80211: DMA-mask fixes. bcm43xx-d80211: Remove some BCM947XX ifdefs, Merge branch 'master' of git://kernel.org/.../linville/wireless-dev bcm43xx-d80211: Assign all fields in the RX status report. bcm43xx-d80211: Set channel cookie to prevent ghost packets. bcm43xx-d80211: Prevent crash by setting active wlcore to NULL on wlcore-select failure. The diffstat is: drivers/misc/ssb.c | 431 ++- drivers/net/wireless/d80211/bcm43xx/bcm43xx.h | 143 +++ .../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c | 295 +++- .../net/wireless/d80211/bcm43xx/bcm43xx_debugfs.h | 35 - drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c | 149 ++-- drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.h | 18 drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c | 16 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 820 +--- drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c | 76 +- drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c | 104 +-- drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.h | 12 .../net/wireless/d80211/bcm43xx/bcm43xx_power.c| 125 +--- .../net/wireless/d80211/bcm43xx/bcm43xx_radio.c| 143 ++-- .../net/wireless/d80211/bcm43xx/bcm43xx_radio.h|1 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c | 309 +++- drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.h | 247 +- include/linux/ssb.h| 71 +- 17 files changed, 1681 insertions(+), 1314 deletions(-) -- Greetings Michael. - 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
Re: [PATCH 7/9] secid reconciliation-v04: Enforcement for SELinux
On Mon, 2 Oct 2006, Stephen Smalley wrote: > It appears that selinux_xfrm_decode_session() can only legitimately > return an error if the last argument (ckall) is non-zero. > security_skb_classify_flow() was doing the same thing prior to this > patch series. It would be clearer if there were two separate interfaces > that internally use the same helper, with one of the functions returning > void. Ok, this can be a followup patch request (and not block merging). - James -- James Morris <[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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] secid reconciliation-v04: Add LSM hooks
On Sun, 2006-10-01 at 16:26 -0500, Venkat Yekkirala wrote:
> 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/linux/security.h | 41 -
> security/dummy.c | 13 +++
> 2 files changed, 53 insertions(+), 1 deletion(-)
> @@ -3150,7 +3185,11 @@ static inline int security_xfrm_state_al
> {
> if (!polsec)
> return 0;
> - return security_ops->xfrm_state_alloc_security(x, NULL, polsec, secid);
> + /*
> + * No need to pass polsec along since we want the context to be
> + * taken from secid which is usually from the sock.
> + */
> + return security_ops->xfrm_state_alloc_security(x, NULL, NULL, secid);
> }
As a follow-up patch, you could then drop polsec from the hook interface
in security_ops (but not the static inline function interface), and from
the underlying selinux functions. That would simplify
selinux_xfrm_sec_ctx_alloc() a bit and make the logic clearer.
--
Stephen Smalley
National Security Agency
-
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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> > Can you look in /var/log/audit/audit.log ? (especially grep for
> > 'association' )
>
> Indeed.
>
> type=AVC msg=audit(1159804556.391:21): avc: denied { polmatch } for
> pid=2213 comm="racoon" scontext=root:system_r:unconfined_t:s0-s0:c0.c255
> tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
Ok, that's it.
> But then it is quite strange why FC5 2.6.17-1.2187_FC5smp works,
> are there some bindings to the kernel version?
> (my knowledge about selinux changes related to xfrm are somewhere
> between zero and void).
The SELinux policy is loosely bound to the kernel version. Generally, if
you run development kernels, you need development SELinux policy.
> > What version of SELinux policy are you using?
> >
> > i.e. $ rpm -q selinux-policy-targeted
>
> selinux-policy-targeted-2.3.7-2.fc5
Yep, that's ancient.
> I run it every day in cron and there are no updates at
>
> http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/i386/
>
> behind my version.
You can get recent policy packages via the devel repo, which I'd suggest
if you're using development (or DIY) kernels.
--
James Morris
<[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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] secid reconciliation-v04: Enforcement for SELinux
On Mon, 2006-10-02 at 12:12 -0400, Paul Moore wrote:
> Venkat Yekkirala wrote:
> > 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: Venkat Yekkirala <[EMAIL PROTECTED]>
> >
> > {snip}
> >
> > +static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
> > +{
> > + u32 xfrm_sid;
> > + int err;
> > +
> > + if (selinux_compat_net)
> > + return 1;
> > +
> > + /*
> > +* loopback traffic already labeled and
> > +* flow-controlled on outbound. We may
> > +* need to flow-control on the inbound
> > +* as well if there's ever a use-case for it.
> > +*/
> > + if (skb->dev == &loopback_dev)
> > + return 1;
> > +
> > + err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0);
> > + BUG_ON(err);
>
> Just a quick question that has been nagging me for awhile - any
> particular reason why this is a BUG_ON() and not an "if (err) goto out;"?
It appears that selinux_xfrm_decode_session() can only legitimately
return an error if the last argument (ckall) is non-zero.
security_skb_classify_flow() was doing the same thing prior to this
patch series. It would be clearer if there were two separate interfaces
that internally use the same helper, with one of the functions returning
void.
> > + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> > + PACKET__FLOW_IN, NULL);
> > + if (err)
> > + goto out;
> > +
> > + if (xfrm_sid)
> > + skb->secmark = xfrm_sid;
> > +
> > + /* See if NetLabel can flow in thru the current secmark here */
> > +
> > +out:
> > + return err ? 0 : 1;
> > +};
>
--
Stephen Smalley
National Security Agency
-
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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Mon, Oct 02, 2006 at 12:13:45PM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
>
> > On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris ([EMAIL PROTECTED])
> > wrote:
> > > Updated version of the patch, which return directly after a flow cache
> > > lookup error in xfrm_lookup rather than returing via the cleanup path
> > > (which was causing a spurious dst_release).
> > >
> > > This works for me, although I never saw the oops with the old patch.
> > >
> > > Evgeniy, let me know if this fixes the oops you're seeing.
> >
> > With enabled selinux in enforcing mode I can not even get messages to
> > racoon, i.e. tcpdump sees first message of the daemon, but racoon log
> > (with a lot of -d) is not changed.
> > With permissive mode everything works fine.
>
> I think this could be your security policy denying access (which is a
> strong suspicion, becuase you hit the problem easily and it requires a
> policy denial).
>
> Can you look in /var/log/audit/audit.log ? (especially grep for
> 'association' )
Indeed.
type=AVC msg=audit(1159804556.391:21): avc: denied { polmatch } for
pid=2213 comm="racoon" scontext=root:system_r:unconfined_t:s0-s0:c0.c255
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
But then it is quite strange why FC5 2.6.17-1.2187_FC5smp works,
are there some bindings to the kernel version?
(my knowledge about selinux changes related to xfrm are somewhere
between zero and void).
> What version of SELinux policy are you using?
>
> i.e. $ rpm -q selinux-policy-targeted
selinux-policy-targeted-2.3.7-2.fc5
> If it's not very recent, like 2.3.16-9 or better, you may need to run a
> yum update.
I run it every day in cron and there are no updates at
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/i386/
behind my version.
>
> - James
> --
> James Morris
> <[EMAIL PROTECTED]>
--
Evgeniy Polyakov
-
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
Re: [PATCH 0/6]: powerpc/cell spidernet ethernet patches
On Sat, Sep 30, 2006 at 12:40:00PM +0200, Arnd Bergmann wrote: > Am Saturday 30 September 2006 01:05 schrieb Linas Vepstas: > > > > Although these patches improve things, I am not > > satisfied with how this driver behaves, and so > > plan to do additional work next week. > > > > I'm not sure if I have missed a patch in here, but I > don't see anything reintroducing the 'netif_stop_queue' > that is missing from the transmit path. > > Do you have a extra patch for that? Unfinished. There are several ways in which the current spider-net driver doesn't do things the way Greg KH's, etal book on device drivers recommends. I was planning on combing through these this week. --linas - 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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote: > On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris ([EMAIL PROTECTED]) > wrote: > > Updated version of the patch, which return directly after a flow cache > > lookup error in xfrm_lookup rather than returing via the cleanup path > > (which was causing a spurious dst_release). > > > > This works for me, although I never saw the oops with the old patch. > > > > Evgeniy, let me know if this fixes the oops you're seeing. > > With enabled selinux in enforcing mode I can not even get messages to > racoon, i.e. tcpdump sees first message of the daemon, but racoon log > (with a lot of -d) is not changed. > With permissive mode everything works fine. I think this could be your security policy denying access (which is a strong suspicion, becuase you hit the problem easily and it requires a policy denial). Can you look in /var/log/audit/audit.log ? (especially grep for 'association' ) What version of SELinux policy are you using? i.e. $ rpm -q selinux-policy-targeted If it's not very recent, like 2.3.16-9 or better, you may need to run a yum update. - James -- James Morris <[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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] secid reconciliation-v04: Enforcement for SELinux
Venkat Yekkirala wrote:
> 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: Venkat Yekkirala <[EMAIL PROTECTED]>
>
> {snip}
>
> +static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
> +{
> + u32 xfrm_sid;
> + int err;
> +
> + if (selinux_compat_net)
> + return 1;
> +
> + /*
> + * loopback traffic already labeled and
> + * flow-controlled on outbound. We may
> + * need to flow-control on the inbound
> + * as well if there's ever a use-case for it.
> + */
> + if (skb->dev == &loopback_dev)
> + return 1;
> +
> + err = selinux_xfrm_decode_session(skb, &xfrm_sid, 0);
> + BUG_ON(err);
Just a quick question that has been nagging me for awhile - any
particular reason why this is a BUG_ON() and not an "if (err) goto out;"?
> + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> + PACKET__FLOW_IN, NULL);
> + if (err)
> + goto out;
> +
> + if (xfrm_sid)
> + skb->secmark = xfrm_sid;
> +
> + /* See if NetLabel can flow in thru the current secmark here */
> +
> +out:
> + return err ? 0 : 1;
> +};
--
paul moore
linux security @ hp
-
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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris ([EMAIL PROTECTED]) wrote: > Updated version of the patch, which return directly after a flow cache > lookup error in xfrm_lookup rather than returing via the cleanup path > (which was causing a spurious dst_release). > > This works for me, although I never saw the oops with the old patch. > > Evgeniy, let me know if this fixes the oops you're seeing. With enabled selinux in enforcing mode I can not even get messages to racoon, i.e. tcpdump sees first message of the daemon, but racoon log (with a lot of -d) is not changed. With permissive mode everything works fine. It is possible that it is 2.6.18 only problem though, I will try previous kernels. -- Evgeniy Polyakov - 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
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
> (whitespace damaged; more for comment than for application).
>
> > -if ((u32)skb->data & 3) {
> > +if ((unsigned long)skb->data & 3) {
>
> I suppose it quietens a compiler warning. Doesn't actually fix a bug
> though.
Right but it does no harm casting it to either so its worth cleaning up.
-
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
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
On Mon, Oct 02, 2006 at 04:12:35PM +0100, Alan Cox wrote:
> @@ -1423,14 +1418,15 @@
> printk(KERN_ERR DEV_LABEL "can't allocate DLEs\n");
> goto err_out;
> }
> - iadev->rx_dle_q.start = (struct dle*)dle_addr;
> + iadev->rx_dle_q.start = (struct dle *)dle_addr;
> iadev->rx_dle_q.read = iadev->rx_dle_q.start;
> iadev->rx_dle_q.write = iadev->rx_dle_q.start;
> - iadev->rx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
> dle)*DLE_ENTRIES);
> + iadev->rx_dle_q.end = (struct dle*)((unsigned
> long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
> /* the end of the dle q points to the entry after the last
> DLE that can be used. */
dle_addr is a bit strange. How about:
+++ b/drivers/atm/iphase.c
@@ -1404,7 +1404,7 @@ static int rx_init(struct atm_dev *dev)
IADEV *iadev;
struct rx_buf_desc __iomem *buf_desc_ptr;
unsigned long rx_pkt_start = 0;
- void *dle_addr;
+ struct dle *dle_addr;
struct abr_vc_table *abr_vc_table;
u16 *vc_table;
u16 *reass_table;
@@ -1423,10 +1423,10 @@ static int rx_init(struct atm_dev *dev)
printk(KERN_ERR DEV_LABEL "can't allocate DLEs\n");
goto err_out;
}
- iadev->rx_dle_q.start = (struct dle*)dle_addr;
+ iadev->rx_dle_q.start = dle_addr;
iadev->rx_dle_q.read = iadev->rx_dle_q.start;
iadev->rx_dle_q.write = iadev->rx_dle_q.start;
- iadev->rx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct dle)*DLE
_ENTRIES);
+ iadev->rx_dle_q.end = dle_addr + DLE_ENTRIES;
/* the end of the dle q points to the entry after the last
DLE that can be used. */
@@ -1884,7 +1884,7 @@ static int tx_init(struct atm_dev *dev)
IADEV *iadev;
struct tx_buf_desc *buf_desc_ptr;
unsigned int tx_pkt_start;
- void *dle_addr;
+ struct dle *dle_addr;
int i;
u_short tcq_st_adr;
u_short *tcq_start;
@@ -1908,10 +1908,10 @@ static int tx_init(struct atm_dev *dev)
printk(KERN_ERR DEV_LABEL "can't allocate DLEs\n");
goto err_out;
}
- iadev->tx_dle_q.start = (struct dle*)dle_addr;
+ iadev->tx_dle_q.start = dle_addr;
iadev->tx_dle_q.read = iadev->tx_dle_q.start;
iadev->tx_dle_q.write = iadev->tx_dle_q.start;
- iadev->tx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct dle)*DLE
_ENTRIES);
+ iadev->tx_dle_q.end = dle_addr + DLE_ENTRIES;
/* write the upper 20 bits of the start address to tx list address regis
ter */
writel(iadev->tx_dle_dma & 0xf000,
(whitespace damaged; more for comment than for application).
> -if ((u32)skb->data & 3) {
> +if ((unsigned long)skb->data & 3) {
I suppose it quietens a compiler warning. Doesn't actually fix a bug
though.
-
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
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
Ar Llu, 2006-10-02 am 09:52 -0400, ysgrifennodd chas williams -
CONTRACTOR:
> some of the drivers in atm are already marked with !64BIT and some
> need to be marked. this might be more complete for drivers/atm/Kconfig:
This should fix Iphase for one. Some of the others look a lot harder
however
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Binary files linux.vanilla-2.6.18-mm2/drivers/atm/fore200e_mkfirm and
linux-2.6.18-mm2/drivers/atm/fore200e_mkfirm differ
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.18-mm2/drivers/atm/iphase.c
linux-2.6.18-mm2/drivers/atm/iphase.c
--- linux.vanilla-2.6.18-mm2/drivers/atm/iphase.c 2006-09-20
04:42:06.0 +0100
+++ linux-2.6.18-mm2/drivers/atm/iphase.c 2006-10-02 15:28:51.678220488
+0100
@@ -93,10 +93,6 @@
MODULE_LICENSE("GPL");
-#if BITS_PER_LONG != 32
-# error FIXME: this driver only works on 32-bit platforms
-#endif
-
/ IA_LIB **/
static void ia_init_rtn_q (IARTN_Q *que)
@@ -1408,7 +1404,6 @@
struct abr_vc_table *abr_vc_table;
u16 *vc_table;
u16 *reass_table;
-u16 *ptr16;
int i,j, vcsize_sel;
u_short freeq_st_adr;
u_short *freeq_start;
@@ -1423,14 +1418,15 @@
printk(KERN_ERR DEV_LABEL "can't allocate DLEs\n");
goto err_out;
}
- iadev->rx_dle_q.start = (struct dle*)dle_addr;
+ iadev->rx_dle_q.start = (struct dle *)dle_addr;
iadev->rx_dle_q.read = iadev->rx_dle_q.start;
iadev->rx_dle_q.write = iadev->rx_dle_q.start;
- iadev->rx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
dle)*DLE_ENTRIES);
+ iadev->rx_dle_q.end = (struct dle*)((unsigned
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* the end of the dle q points to the entry after the last
DLE that can be used. */
/* write the upper 20 bits of the start address to rx list address
register */
+ /* We know this is 32bit bus addressed so the following is safe */
writel(iadev->rx_dle_dma & 0xf000,
iadev->dma + IPHASE5575_RX_LIST_ADDR);
IF_INIT(printk("Tx Dle list addr: 0x%08x value: 0x%0x\n",
@@ -1584,11 +1580,12 @@
Set Packet Aging Interval count register to overflow in about 4 us
*/
writew(0xF6F8, iadev->reass_reg+PKT_TM_CNT );
-ptr16 = (u16*)j;
-i = ((u32)ptr16 >> 6) & 0xff;
- ptr16 += j - 1;
- i |=(((u32)ptr16 << 2) & 0xff00);
+
+i = (j >> 6) & 0xFF;
+j += 2 * (j - 1);
+i |= ((j << 2) & 0xFF00);
writew(i, iadev->reass_reg+TMOUT_RANGE);
+
/* initiate the desc_tble */
for(i=0; inum_tx_desc;i++)
iadev->desc_tbl[i].timestamp = 0;
@@ -1911,7 +1908,7 @@
iadev->tx_dle_q.start = (struct dle*)dle_addr;
iadev->tx_dle_q.read = iadev->tx_dle_q.start;
iadev->tx_dle_q.write = iadev->tx_dle_q.start;
- iadev->tx_dle_q.end = (struct dle*)((u32)dle_addr+sizeof(struct
dle)*DLE_ENTRIES);
+ iadev->tx_dle_q.end = (struct dle*)((unsigned
long)dle_addr+sizeof(struct dle)*DLE_ENTRIES);
/* write the upper 20 bits of the start address to tx list address
register */
writel(iadev->tx_dle_dma & 0xf000,
@@ -2913,7 +2910,7 @@
dev_kfree_skb_any(skb);
return 0;
}
-if ((u32)skb->data & 3) {
+if ((unsigned long)skb->data & 3) {
printk("Misaligned SKB\n");
if (vcc->pop)
vcc->pop(vcc, skb);
-
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
Re: rewriting skb->truesize... good or bad idea
Hi David Thanks for the answer. David Miller wrote: > From: Vlad Yasevich <[EMAIL PROTECTED]> > Date: Fri, 29 Sep 2006 14:16:57 -0400 > >> I've attached the patch, in case people want to look at the code. >> >> However, we question if this is a good idea or if this is going to break >> things... > > Modification of skb->truesize is very dangerous and is only legal > in a very limited set of circumstances. > > The core problem is that if any other reference exists to the skb > you could corrupt existing socket accounting by changing skb->truesize. Yes, that's what I've found in the code. > > Let's say that the packet went into a network tap like tcpdump and > the packet has been charged to an AF_PACKET socket via skb->truesize. > If you modify skb->truesize then when the AF_PACKET socket releases > it's reference it will subtract the wrong amount of skb->truesize > from the socket receive buffer. Thankfully, this does not appear to be a problem in this particular case. The clones that would have their truesize changed, only exist in SCTP. The packet has already gone through all verifications and we just queue the clones to the socket. The original packet skb remains unchanged. SCTP calls kfree_skb on it once all the cloning is done. > > If, on the other hand, you know you have exclusive access to the > skb and there are no other references, setting skb->truesize can > be OK. However setting it to sizeof(struct sk_buff) doesn't make > sense since there is at least: > > sizeof(struct sk_buff) + sizeof(struct skb_shared_info) > > memory assosciated with any SKB whatsoever in the kernel. That is, > even for a "zero length" skb->data buffer, we still always allocate > the skb_shared_info area which must be accounted for. Well, since we are dealing with clones of the original skb, I didn't think that we need to include skb_shared_info. I thought that was accounted for in the original skb? The clones, that SCTP creates, point at a subset of data... something like this: clone 1 --+ clone 2 --+ || || vv +--- | proto hdrs | sctp data chunk 1 | data chunk 2 +--- ^ | | +--- orig_skb->head Right now, for every clone we use the generic socket accounting code that uses skb->truesize. The alternative to changing truesize is to write an SCTP version of socket accounting. This is what we did back in 2.6.10 days and we tried get away from that. If you have another idea of how we could do this, I'd appreciate it. > > BTW, I think the whole chunking mechanism in the SCTP code is the > largest source of problems and maintainability issues in that stack. > Any time I want to make major modifications to SKBs to make them > smaller or whatever, the most difficult piece of code to adjust is > this code. > I think you've already removed all the dependencies between chunking and SKBs. All we have now are some pointers to skb. This work actually made the protocol a lot more stable. Thanks -vlad - 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
[PATCH 1/2] remove Momentum Jaguar ATX network driver support
This patch has removed Momentum / PMC-Sierra Jaguar ATX network driver support. It is listed in feature-removal-schedule.txt . Yoichi Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]> diff -pruN -X generic/Documentation/dontdiff generic-orig/drivers/net/Kconfig generic/drivers/net/Kconfig --- generic-orig/drivers/net/Kconfig2006-10-01 14:16:22.148805500 +0900 +++ generic/drivers/net/Kconfig 2006-10-01 14:25:10.785843250 +0900 @@ -2292,7 +2292,7 @@ config UGETH_HAS_GIGA config MV643XX_ETH tristate "MV-643XX Ethernet support" - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MOMENCO_OCELOT_3 || (PPC_MULTIPLATFORM && PPC32) + depends on MOMENCO_OCELOT_C || MV64360 || MOMENCO_OCELOT_3 || (PPC_MULTIPLATFORM && PPC32) select MII help This driver supports the gigabit Ethernet on the Marvell MV643XX - 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
[PATCH 2/2] remove Momentum Ocelot 3 andOcelot C network driver support
This patch has removed Momentum Ocelot 3 and Ocelot C network driver support. It is listed in feature-removal-schedule.txt . Yoichi Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]> diff -pruN -X generic/Documentation/dontdiff generic-orig/drivers/net/Kconfig generic/drivers/net/Kconfig --- generic-orig/drivers/net/Kconfig2006-10-01 14:27:17.837783500 +0900 +++ generic/drivers/net/Kconfig 2006-10-01 14:27:22.662085000 +0900 @@ -2292,7 +2292,7 @@ config UGETH_HAS_GIGA config MV643XX_ETH tristate "MV-643XX Ethernet support" - depends on MOMENCO_OCELOT_C || MV64360 || MOMENCO_OCELOT_3 || (PPC_MULTIPLATFORM && PPC32) + depends on MV64360 || (PPC_MULTIPLATFORM && PPC32) select MII help This driver supports the gigabit Ethernet on the Marvell MV643XX - 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
[PATCH] Fix for IPsec leakage with SELinux enabled - V.02
Updated version of the patch, which return directly after a flow cache
lookup error in xfrm_lookup rather than returing via the cleanup path
(which was causing a spurious dst_release).
This works for me, although I never saw the oops with the old patch.
Evgeniy, let me know if this fixes the oops you're seeing.
Signed-off-by: James Morris <[EMAIL PROTECTED]>
---
diff -purN -X dontdiff net-2.6.o/include/net/flow.h net-2.6.w/include/net/flow.h
--- net-2.6.o/include/net/flow.h2006-09-29 11:33:58.0 -0400
+++ net-2.6.w/include/net/flow.h2006-09-30 23:50:32.0 -0400
@@ -97,7 +97,7 @@ struct flowi {
#define FLOW_DIR_FWD 2
struct sock;
-typedef void (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
+typedef int (*flow_resolve_t)(struct flowi *key, u16 family, u8 dir,
void **objp, atomic_t **obj_refp);
extern void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
diff -purN -X dontdiff net-2.6.o/net/core/flow.c net-2.6.w/net/core/flow.c
--- net-2.6.o/net/core/flow.c 2006-09-29 11:33:59.0 -0400
+++ net-2.6.w/net/core/flow.c 2006-10-01 01:07:24.0 -0400
@@ -85,6 +85,14 @@ static void flow_cache_new_hashrnd(unsig
add_timer(&flow_hash_rnd_timer);
}
+static void flow_entry_kill(int cpu, struct flow_cache_entry *fle)
+{
+ if (fle->object)
+ atomic_dec(fle->object_ref);
+ kmem_cache_free(flow_cachep, fle);
+ flow_count(cpu)--;
+}
+
static void __flow_cache_shrink(int cpu, int shrink_to)
{
struct flow_cache_entry *fle, **flp;
@@ -100,10 +108,7 @@ static void __flow_cache_shrink(int cpu,
}
while ((fle = *flp) != NULL) {
*flp = fle->next;
- if (fle->object)
- atomic_dec(fle->object_ref);
- kmem_cache_free(flow_cachep, fle);
- flow_count(cpu)--;
+ flow_entry_kill(cpu, fle);
}
}
}
@@ -220,24 +225,33 @@ void *flow_cache_lookup(struct flowi *ke
nocache:
{
+ int err;
void *obj;
atomic_t *obj_ref;
- resolver(key, family, dir, &obj, &obj_ref);
+ err = resolver(key, family, dir, &obj, &obj_ref);
if (fle) {
- fle->genid = atomic_read(&flow_cache_genid);
-
- if (fle->object)
- atomic_dec(fle->object_ref);
-
- fle->object = obj;
- fle->object_ref = obj_ref;
- if (obj)
- atomic_inc(fle->object_ref);
+ if (err) {
+ /* Force security policy check on next lookup */
+ *head = fle->next;
+ flow_entry_kill(cpu, fle);
+ } else {
+ fle->genid = atomic_read(&flow_cache_genid);
+
+ if (fle->object)
+ atomic_dec(fle->object_ref);
+
+ fle->object = obj;
+ fle->object_ref = obj_ref;
+ if (obj)
+ atomic_inc(fle->object_ref);
+ }
}
local_bh_enable();
+ if (err)
+ obj = ERR_PTR(err);
return obj;
}
}
diff -purN -X dontdiff net-2.6.o/net/xfrm/xfrm_policy.c
net-2.6.w/net/xfrm/xfrm_policy.c
--- net-2.6.o/net/xfrm/xfrm_policy.c2006-09-29 11:34:00.0 -0400
+++ net-2.6.w/net/xfrm/xfrm_policy.c2006-10-02 10:02:18.0 -0400
@@ -880,30 +880,32 @@ out:
}
EXPORT_SYMBOL(xfrm_policy_walk);
-/* Find policy to apply to this flow. */
-
+/*
+ * Find policy to apply to this flow.
+ *
+ * Returns 0 if policy found, else an -errno.
+ */
static int xfrm_policy_match(struct xfrm_policy *pol, struct flowi *fl,
u8 type, u16 family, int dir)
{
struct xfrm_selector *sel = &pol->selector;
- int match;
+ int match, ret = -ESRCH;
if (pol->family != family ||
pol->type != type)
- return 0;
+ return ret;
match = xfrm_selector_match(sel, fl, family);
- if (match) {
- if (!security_xfrm_policy_lookup(pol, fl->secid, dir))
- return 1;
- }
+ if (match)
+ ret = security_xfrm_policy_lookup(pol, fl->secid, dir);
- return 0;
+ return ret;
}
static struct xfrm_policy *xfrm_policy_lookup_bytype(u8 type, struct flowi *fl,
u16 family, u8 dir)
{
+ int err
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
Hello, Jeff Garzik wrote: Andi Kleen wrote: Jeff Garzik <[EMAIL PROTECTED]> writes: 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. When I had this problem in the past I just used && !64BIT. How is this new option different? Same reason why we have CONFIG_BROKEN_ON_SMP separate from CONFIG_SMP. AFAIK I2O got fixed too. Do you have any evidence that it is really broken on 64bit? i2o_config did not. Just read the code, it's obvious... Although the documentation does say it need fixes, it really doesn't. It is broken if used with 64-bit DMA addresses, but it does work on 64-bit systems. Best regards, Markus Lidel -- Markus Lidel (Senior IT Consultant) Shadow Connect GmbH Carl-Reisch-Weg 12 D-86381 Krumbach Germany Phone: +49 82 82/99 51-0 Fax:+49 82 82/99 51-11 E-Mail: [EMAIL PROTECTED] URL:http://www.shadowconnect.com - 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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote: > Probably reference counter is inside freed object... I think I know what it is (xfrm_lookup needs to just return on flow cache lookup failure, not goto error and free the dst). Patch forthcoming. - James -- James Morris <[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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
Ar Llu, 2006-10-02 am 00:55 -0400, ysgrifennodd Jeff Garzik: > 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. NAK. This contains lots of stuff whcih isn't broken in the first place. (Eg Megaraid works with 32bit config tools not 64bit ones and is otherwise fine, ISDN is just bogus warnings now swatted) - 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
Re: [PATCH] genetlink custom attribute type
On Mon, 2006-10-02 at 15:49 +0200, Thomas Graf wrote: > That's not a bad idea, although it seems cleaner to just allow defining > a callback function which gets called foreach unknown attribute. Hm, that'd work too, but it'd force me to leave these 'unknown attributes' at the end of the attribute space, no? Otherwise, something with .len=0,.type=0 is sort of valid as well, not? > As for > generic netlink, this callback could be defined on a per command basis > in struct genl_ops. I'd have to look at it more closely again, I removed the custom stuff and it's not immediately important to me at this time. johannes - 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
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
In message <[EMAIL PROTECTED]>,Jeff Garzik writes: >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, because the 32BIT marker was due to bugs >rather than fundamentals. some of the drivers in atm are already marked with !64BIT and some need to be marked. this might be more complete for drivers/atm/Kconfig: diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig index cfa5af8..f4e0978 100644 --- a/drivers/atm/Kconfig +++ b/drivers/atm/Kconfig @@ -139,7 +139,7 @@ config ATM_ENI_BURST_RX_2W config ATM_FIRESTREAM tristate "Fujitsu FireStream (FS50/FS155) " - depends on PCI && ATM + depends on PCI && ATM && BROKEN_ON_64BIT help Driver for the Fujitsu FireStream 155 (MB86697) and FireStream 50 (MB86695) ATM PCI chips. @@ -149,7 +149,7 @@ config ATM_FIRESTREAM config ATM_ZATM tristate "ZeitNet ZN1221/ZN1225" - depends on PCI && ATM + depends on PCI && ATM && BROKEN_ON_64BIT help Driver for the ZeitNet ZN1221 (MMF) and ZN1225 (UTP-5) 155 Mbps ATM adapters. @@ -173,7 +173,7 @@ # bool ' Enable extended debugging # fi config ATM_NICSTAR tristate "IDT 77201 (NICStAR) (ForeRunnerLE)" - depends on PCI && ATM && !64BIT + depends on PCI && ATM && BROKEN_ON_64BIT help The NICStAR chipset family is used in a large number of ATM NICs for 25 and for 155 Mbps, including IDT cards and the Fore ForeRunnerLE @@ -241,7 +241,7 @@ config ATM_IDT77252_USE_SUNI config ATM_AMBASSADOR tristate "Madge Ambassador (Collage PCI 155 Server)" - depends on PCI && ATM + depends on PCI && ATM && BROKEN_ON_64BIT help This is a driver for ATMizer based ATM card produced by Madge Networks Ltd. Say Y (or M to compile as a module named ambassador) @@ -265,7 +265,7 @@ config ATM_AMBASSADOR_DEBUG config ATM_HORIZON tristate "Madge Horizon [Ultra] (Collage PCI 25 and Collage PCI 155 Client)" - depends on PCI && ATM + depends on PCI && ATM && BROKEN_ON_64BIT help This is a driver for the Horizon chipset ATM adapter cards once produced by Madge Networks Ltd. Say Y (or M to compile as a module @@ -289,7 +289,7 @@ config ATM_HORIZON_DEBUG config ATM_IA tristate "Interphase ATM PCI x575/x525/x531" - depends on PCI && ATM && !64BIT + depends on PCI && ATM && BROKEN_ON_64BIT ---help--- This is a driver for the Interphase (i)ChipSAR adapter cards which include a variety of variants in term of the size of the - 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
Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
02 Eki 2006 Pts 13:24 tarihinde, Jarek Poplawski şunları yazmıştı:
> On 30-09-2006 21:23, Ismail Donmez wrote:
> > Hi,
> >
> > With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
> > changed behaviour so it returns false when the node is empty as expected.
>
> ...
>
> > - if (!RB_EMPTY_NODE(rb)) {
> > + if (RB_EMPTY_NODE(rb)) {
>
> Maybe you have some kind of agreement with Jens Axboe but I
> can't understand current way of kernel cooperation:
> he changes some global behavior to the opposite and fixes
> his code in three places but can't fix it in the fourth place
> where it's used? Isn't it both trivial and automatic kind
> of patch?
I don't know if Jens will going to fix other occurrences but the sch_htb.c fix
was recent and Jens' commit got my attention hence the patch.
Regards,
ismail
-
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
Re: [PATCH] genetlink custom attribute type
* Johannes Berg <[EMAIL PROTECTED]> 2006-09-27 14:18
> On Tue, 2006-09-26 at 11:44 +0200, Thomas Graf wrote:
>
> > Thinking it over I'm still not completely happy with this. A
> > small subset of all the validation tasks is simply too complex
> > to be put into the policy. The validation of your type value
> > array is such a case, address fields with variable length based
> > on their family is another. I think it's just not worth to
> > blow up struct nla_policy by 12 bytes per entry just to save
> > some code.
>
> Oh, I just had another idea... Feel free to ignore me if you think that
> having this done in some generic way isn't worth it though. As I said,
> it doesn't really make a difference to me in the end :)
>
>
> Currently, we always pass a "struct nla_policy *policy" into things,
> which really is an array. We could instead pass in a new
>
> struct nla_validation {
> int (*custom_validate)(struct nlattr *nla);
> struct nla_policy *policy;
> };
>
> and call custom_validate() whenever we encounter something in the policy
> that has type NLA_CUSTOM_VALIDATE. Downsides of this approach are that
> it requires changing all current users, and introduces 16 bytes constant
> overhead on 64-bit platforms, the size of nla_validation.
Sorry for the delay.
That's not a bad idea, although it seems cleaner to just allow defining
a callback function which gets called foreach unknown attribute. As for
generic netlink, this callback could be defined on a per command basis
in struct genl_ops.
-
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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled
On Mon, Oct 02, 2006 at 09:31:36AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> What kind of traffic was running over the system? What is the IPsec and
> SELinux configuration?
I had login through ssh, started racoon and setup keys.
SElinu is configured by default in FC5 system with enforcing mode.
I switched off to different window and after some time, not immediately,
remote system stopped to answer.
There were no heavy traffic definitely.
It looks like some timeout expired and someone tried to do xfrm_lookup.
> Can you run gdb on vmlinux, find the start of xfrm_lookup then list what's
> at the EIP offset?
>
> (gdb) p xfrm_lookup
> $1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)}
> 0xc02cc7e2
> (gdb) l *(0xc02cc7e2 + 0x043d)
(gdb) p xfrm_lookup
$1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)} 0xc0301326
(gdb) l *(0xc0301326+0x043d)
0xc0301763 is in xfrm_lookup (include/asm/atomic.h:126).
121 */
122 static __inline__ int atomic_dec_and_test(atomic_t *v)
123 {
124 unsigned char c;
125
126 __asm__ __volatile__(
127 LOCK_PREFIX "decl %0; sete %1"
128 :"+m" (v->counter), "=qm" (c)
129 : : "memory");
130 return c != 0;
Probably reference counter is inside freed object...
> --
> James Morris
> <[EMAIL PROTECTED]>
--
Evgeniy Polyakov
-
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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> > Evgeniy, please let me know if this fixes your problem.
>
> With that patch applied I got kernel panic after some time.
> Unfortunately I have not installed serial console, so the most
> interesting bits of the stack dump are not visible.
> Here is the last ones which are on the screen:
> ip_rcv
> ip_rcv_finish
> packet_rcv_spkt
> ip_rcv
> netif_receive_skb
> sys_accept
> skge_poll
>
> and some other uninteresting stuff like hrtimer, softirq and the like...
>
> EIP is at xfrm_lookup+0x43d/0x470
>
> Notice packet socket handler in the trace, may be it can help - I ran
> system with tcpdump started.
What kind of traffic was running over the system? What is the IPsec and
SELinux configuration?
Can you run gdb on vmlinux, find the start of xfrm_lookup then list what's
at the EIP offset?
(gdb) p xfrm_lookup
$1 = {int (struct dst_entry **, struct flowi *, struct sock *, int)}
0xc02cc7e2
(gdb) l *(0xc02cc7e2 + 0x043d)
--
James Morris
<[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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Network Events Connector
On Mon, Oct 02, 2006 at 02:57:55PM +0200, Samir Bellabes ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 02, 2006 at 08:11:06AM +0200, Samir Bellabes ([EMAIL > > PROTECTED]) wrote: > >> > >> 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 open for the corresponding sport or not, and if > >> so open the firewall for the application which get the corresponding sport. > >> > >> For people behind a firewall (non-running in the user box) we can have a > >> authentification between the user box, which have set the port to state > >> TCP_LISTEN for example, and the firewall, in a such way that the > >> firewall's router will forward incoming packet for this port to the user > >> box. > >> > >> It will avoid adding specific rules to the user's firewall-script, and > >> let the firewall be more interactive for users. > >> > >> Signed-off-by: Samir Bellabes <[EMAIL PROTECTED]> > > > > Interesting... Mybe it even prints the name of the application which is > > trying to change port state? > > Yes, of course, the name of the application is a part of the 'trusted > system'. But i think we can look for the application which gets the > inode corresponding to the sock in userspace, using the /proc/ > files. > Whithout this, we have to lookup all the process in kernel, in order to > find the one which old the sock. It's time consumming, even if the kind > of event involved (listening/close port) doesn't occur so often. > But if you think the kernel can do that, it's not a problem, i have code > to do that. It is much better to do it in userspace - look into /proc/$pid/. I recall I saw such feature in Windows :) 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). > In fact the '$PATH/apps' is the complete info we need. With it, > we can ask the user, and we can check with the 'distro' tools (urpmi, > apt-get, smart) if the '$PATH/apps' really belongs to the distro and > should be trust. > > I'm working also in a option on this, in order to avoid some 'false > positive', because some ports don't need to be 'open' in the firewall, > using conntrack. > As a example, you can take ftp's client, which will own a listening port > when it will received data from server, but the ip/nf_conntrack_ftp will > do the jobs for us, in order to let the data coming in. > This current patch will send the information that the ftp's client is > listening on a port (and a userspace tool will ask the user about what > to do with this) but the ip_conntrack as already did the job. > > > I have couple of comments about structures you use, otherwise it looks > > good, although I do not know if it is ok or not ok to include it into > > mainline tree. > > From one point of view it is small and interesting piece of code, from other > > point it is not clear if such functionality is needed... > > ok. > > > Btw, you could also create netlink/connector based firewall rules > > update, I think people with hundreds of rules in one table will bless > > you after that. > > This is the real goal, using ipset - http://ipset.netfilter.org/ > With this we can easily create a uniq rule for iptables, and then > add/remove port from the 'set' involve. It is not the same as create and update existing rules. I think hipac project uses feature of fast rules update. It is quite major break for existing iptables, but it should be eventually done... -- Evgeniy Polyakov - 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
Re: [PATCH] Network Events Connector
Evgeniy Polyakov <[EMAIL PROTECTED]> writes:
> On Mon, Oct 02, 2006 at 08:11:06AM +0200, Samir Bellabes ([EMAIL PROTECTED])
> wrote:
>>
>> 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 open for the corresponding sport or not, and if
>> so open the firewall for the application which get the corresponding sport.
>>
>> For people behind a firewall (non-running in the user box) we can have a
>> authentification between the user box, which have set the port to state
>> TCP_LISTEN for example, and the firewall, in a such way that the
>> firewall's router will forward incoming packet for this port to the user
>> box.
>>
>> It will avoid adding specific rules to the user's firewall-script, and
>> let the firewall be more interactive for users.
>>
>> Signed-off-by: Samir Bellabes <[EMAIL PROTECTED]>
>
> Interesting... Mybe it even prints the name of the application which is
> trying to change port state?
Yes, of course, the name of the application is a part of the 'trusted
system'. But i think we can look for the application which gets the
inode corresponding to the sock in userspace, using the /proc/
files.
Whithout this, we have to lookup all the process in kernel, in order to
find the one which old the sock. It's time consumming, even if the kind
of event involved (listening/close port) doesn't occur so often.
But if you think the kernel can do that, it's not a problem, i have code
to do that.
In fact the '$PATH/apps' is the complete info we need. With it,
we can ask the user, and we can check with the 'distro' tools (urpmi,
apt-get, smart) if the '$PATH/apps' really belongs to the distro and
should be trust.
I'm working also in a option on this, in order to avoid some 'false
positive', because some ports don't need to be 'open' in the firewall,
using conntrack.
As a example, you can take ftp's client, which will own a listening port
when it will received data from server, but the ip/nf_conntrack_ftp will
do the jobs for us, in order to let the data coming in.
This current patch will send the information that the ftp's client is
listening on a port (and a userspace tool will ask the user about what
to do with this) but the ip_conntrack as already did the job.
> I have couple of comments about structures you use, otherwise it looks
> good, although I do not know if it is ok or not ok to include it into
> mainline tree.
> From one point of view it is small and interesting piece of code, from other
> point it is not clear if such functionality is needed...
ok.
> Btw, you could also create netlink/connector based firewall rules
> update, I think people with hundreds of rules in one table will bless
> you after that.
This is the real goal, using ipset - http://ipset.netfilter.org/
With this we can easily create a uniq rule for iptables, and then
add/remove port from the 'set' involve.
>> +#ifndef CN_NET_H
>> +#define CN_NET_H
>> +
>> +#include
>> +#include
>> +
>> +/*
>> + * Userspace sends this enum to register with the kernel that it is
>> listening
>> + * for events on the connector.
>> + */
>> +enum cn_net_status {
>> +CN_NET_LISTEN = 1,
>> +CN_NET_IGNORE = 2
>> +};
>> +
>> +struct net_event {
>> +enum event {
>> +NET_EVENT_NONE = 0x,
>> +NET_EVENT_TCP_LISTEN= 0x0001,
>> +NET_EVENT_TCP_CLOSE = 0x0002,
>> +NET_EVENT_UDP_BIND = 0x0004,
>> +NET_EVENT_UDP_CLOSE = 0x0008,
>> +NET_EVENT_DCCP_LISTEN = 0x0010,
>> +NET_EVENT_DCCP_CLOSE= 0x0020,
>> +NET_EVENT_MAX = 0x8000
>> +} event;
>> +struct timespec timestamp;
>
> Doesn't this monster have different size in 64 and 32 bit
> environments?
I see.
>> +union {
>> +struct {
>> +__u32 err;
>> +} ack;
>> +
>> +struct {
>> +unsigned int family;
>> +union {
>> +struct in6_addr ipv6;
>> +unsigned long ipv4;
>
> Please no longs in code which is supposed to be used simultaneously in
> 32 and 64 bit environments.
Of course.
Thanks for you comments, i will send a new patch later today.
regars.
-
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
Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On Mon, Oct 02, 2006 at 01:15:55PM +0200, Jarek Poplawski wrote: ... > instead of: > > + if (RB_EMPTY_NODE(rb)) should be: + if (RB_EMPTY_NODE(node)) Jarek P. - 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
Re: [PATCH] Fix for IPsec leakage with SELinux enabled
On Sun, Oct 01, 2006 at 02:27:13AM -0400, James Morris ([EMAIL PROTECTED]) wrote: > 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 > indicates that the packet can pass freely). This also forces any future > lookups for the same flow to consult the security module (e.g. SELinux) > for current security policy (rather than, say, caching the error on the > flow cache entry). > > I've done quite a bit of testing and not seen any problems, although the > patch could certainly do with further review. > > Evgeniy, please let me know if this fixes your problem. With that patch applied I got kernel panic after some time. Unfortunately I have not installed serial console, so the most interesting bits of the stack dump are not visible. Here is the last ones which are on the screen: ip_rcv ip_rcv_finish packet_rcv_spkt ip_rcv netif_receive_skb sys_accept skge_poll and some other uninteresting stuff like hrtimer, softirq and the like... EIP is at xfrm_lookup+0x43d/0x470 Notice packet socket handler in the trace, may be it can help - I ran system with tcpdump started. -- Evgeniy Polyakov - 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
[PATCH] fix bcm43xx-d80211 for inode diet
This patch propagates the inode diet changes to bcm43xx-d80211.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
This patch is required for compiling bcm43xx-d80211 after pulling the
inode diet changes that went into Linus's tree into wireless-dev, since
bcm43xx-d80211 is not in mainline it wasn't fixed up along with the
changes.
I've compiled this but couldn't test because the kernel currently
doesn't boot on my powerbook, it hangs very early.
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
2006-10-01 11:30:18.040555764 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
2006-10-01 11:50:01.780555764 +0200
@@ -54,7 +54,7 @@ static ssize_t write_file_dummy(struct f
static int open_file_generic(struct inode *inode, struct file *file)
{
- file->private_data = inode->u.generic_ip;
+ file->private_data = inode->i_private;
return 0;
}
-
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
Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On Mon, Oct 02, 2006 at 12:24:47PM +0200, Jarek Poplawski wrote:
> On 30-09-2006 21:23, Ismail Donmez wrote:
> > Hi,
> >
> > With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
> > changed behaviour so it returns false when the node is empty as expected.
> ...
> > - if (!RB_EMPTY_NODE(rb)) {
> > + if (RB_EMPTY_NODE(rb)) {
>
> Maybe you have some kind of agreement with Jens Axboe but I
> can't understand current way of kernel cooperation:
> he changes some global behavior to the opposite and fixes
> his code in three places but can't fix it in the fourth place
...
But I see it's not so bad and net_sched isn't the last!
It looks deadline-iosched.c and one place in as-iosched.c
(~ 466 line) where probably also forgotten.
Another question - is there any change planned?
If not why in rbtree.c is:
+ if (rb_parent(node) == node)
instead of:
+ if (RB_EMPTY_NODE(rb))
Jarek P.
-
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
Re: [PATCH 5/5] Solve host error problem in low performance embedded system when continune down and up.
On Mon, Oct 02, 2006 at 02:26:36PM -0400, Jesse Huang wrote:
> 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(-)
>
> c06c70e20a85facd640528ca66e0b579fc3ee745
> diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
> index 14b4933..b4a6010 100755
> --- a/drivers/net/sundance.c
> +++ b/drivers/net/sundance.c
> @@ -1643,6 +1643,14 @@ static int netdev_close(struct net_devic
> struct sk_buff *skb;
> int i;
>
> + /* Wait and kill tasklet */
> + tasklet_kill(&np->rx_tasklet);
> + tasklet_kill(&np->tx_tasklet);
> + np->cur_tx = 0;
> + np->dirty_tx = 0;
> + np->cur_task = 0;
> + np->last_tx = 0;
> +
> netif_stop_queue(dev);
>
> if (netif_msg_ifdown(np)) {
> @@ -1663,9 +1671,20 @@ static int netdev_close(struct net_devic
> /* Stop the chip's Tx and Rx processes. */
> iowrite16(TxDisable | RxDisable | StatsDisable, ioaddr + MACCtrl1);
>
> - /* Wait and kill tasklet */
> - tasklet_kill(&np->rx_tasklet);
> - tasklet_kill(&np->tx_tasklet);
> + for (i = 2000; i > 0; i--) {
> + if ((ioread32(ioaddr + DMACtrl) &0xC000) == 0)
^^^
Missing white space?
> + break;
> + mdelay(1);
> + }
> +
> + iowrite16(GlobalReset | DMAReset | FIFOReset | NetworkReset, ioaddr
> +ASICCtrl + 2);
^
Same here..
> +
> + for (i = 2000; i > 0; i--)
> + {
> + if ((ioread16(ioaddr + ASICCtrl +2) &ResetBusy) == 0)
^^
.. and here
> + break;
> + mdelay(1);
> + }
>
Regards,
Frederik
-
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
Re: [PATCH] Revert [NET_SCHED]: HTB: fix incorrect use of RB_EMPTY_NODE
On 30-09-2006 21:23, Ismail Donmez wrote:
> Hi,
>
> With commit 10fd48f2376db52f08bf0420d2c4f580e39269e1 [1] , RB_EMPTY_NODE
> changed behaviour so it returns false when the node is empty as expected.
...
> - if (!RB_EMPTY_NODE(rb)) {
> + if (RB_EMPTY_NODE(rb)) {
Maybe you have some kind of agreement with Jens Axboe but I
can't understand current way of kernel cooperation:
he changes some global behavior to the opposite and fixes
his code in three places but can't fix it in the fourth place
where it's used? Isn't it both trivial and automatic kind
of patch?
Second question is this title alarming enough?:
"[PATCH] rbtree: fixed reversed RB_EMPTY_NODE and rb_next/prev"
Maybe:
[PATCH] rbtree: reversed RB_EMPTY_NODE and fixed rb_next/prev
but shouldn't there be some special [XYZ!] keyword used for
such severe situations?
Jarek P.
-
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
Re: [PATCH 5/5] Solve host error problem in low performance embedded system when continune down and up.
In some low performance embedded CPU, if continued to ifconfig up and down driver. It will cause host error. Driver need to make sure all counter is clear to zero, and hardware actually stop. - Original Message - From: "Andrew Morton" <[EMAIL PROTECTED]> To: "Jesse Huang" <[EMAIL PROTECTED]> Cc: ; ; <[EMAIL PROTECTED]> Sent: Monday, October 02, 2006 2:51 PM Subject: Re: [PATCH 5/5] Solve host error problem in low performance embedded system when continune down and up. 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, thanks. - 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
Re: [PATCH 2/5] Fix TX Pause bug (reset_tx, intr_handler)
When TxUnderrun happen, driver will re-enable tx. But during this enable process, TxUnderrun maybe happen again. So driver need to make sure Tx was actually enabled. - Original Message - From: "Andrew Morton" <[EMAIL PROTECTED]> To: "Jesse Huang" <[EMAIL PROTECTED]> Cc: ; ; <[EMAIL PROTECTED]> Sent: Monday, October 02, 2006 2:53 PM Subject: Re: [PATCH 2/5] Fix TX Pause bug (reset_tx, intr_handler) 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
Andi Kleen wrote: Jeff Garzik <[EMAIL PROTECTED]> writes: 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. When I had this problem in the past I just used && !64BIT. How is this new option different? Same reason why we have CONFIG_BROKEN_ON_SMP separate from CONFIG_SMP. AFAIK I2O got fixed too. Do you have any evidence that it is really broken on 64bit? i2o_config did not. Just read the code, it's obvious... Jeff - 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
Re: [PATCH] Introduce BROKEN_ON_64BIT facility
Jeff Garzik <[EMAIL PROTECTED]> writes: > 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. When I had this problem in the past I just used && !64BIT. How is this new option different? > config ISDN_CAPI_CAPI20 > tristate "CAPI2.0 /dev/capi support" > - depends on ISDN_CAPI > + depends on ISDN_CAPI && BROKEN_ON_64BIT > help > This option will provide the CAPI 2.0 interface to userspace > applications via /dev/capi20. Applications should use the > @@ -44,7 +44,7 @@ config ISDN_CAPI_CAPIFS > > config ISDN_CAPI_CAPIDRV > tristate "CAPI2.0 capidrv interface support" > - depends on ISDN_CAPI && ISDN_I4L > + depends on ISDN_CAPI && ISDN_I4L && BROKEN_ON_64BIT As discussed earlier ISDN is actually ok. > diff --git a/drivers/message/i2o/Kconfig b/drivers/message/i2o/Kconfig > index 6443392..0e135ce 100644 > --- a/drivers/message/i2o/Kconfig > +++ b/drivers/message/i2o/Kconfig > @@ -56,7 +56,7 @@ config I2O_EXT_ADAPTEC_DMA64 > > config I2O_CONFIG > tristate "I2O Configuration support" > - depends on I2O > + depends on I2O && BROKEN_ON_64BIT > ---help--- > Say Y for support of the configuration interface for the I2O adapters. AFAIK I2O got fixed too. Do you have any evidence that it is really broken on 64bit? -Andi - 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
Re: [RFC] cfg80211 and nl80211
James, Good points. Just a few comments. > The EEPROM contents typically represent the configuration and operating > parameters which have been tested and certified to be operational. > > These would represent the only settings which a user can operate with > and still be covered by existing certifications. Also, the EEPROM could potentially contain limitations of the device itself, a device manufactured for channels 1-11 might not even operate correctly in channel 14, I guess. > The kernel should enforce the parameters as specified by the > hardware/driver. In the event that a driver does not advertise a set of > capabilities, the kernel should select the minimal "safe set", which > would be a subset of the 2.4Ghz spectrum and likely exclude all of 5.2Ghz. Right. Note that for bcm43xx for example, we know that these devices have been certified all over the world and hence the EEPROM information is effectively useless because it just tells us for which region this particular device was manufactured, the vendor actually programs this info and not Broadcom. Hence, in the driver, we'd probably announce some rather liberal set of parameters. Maybe there's a need for two different sets of parameters here: one that the hardware can potentially be used at (usually known to the driver), and one that it was certified for (the eeprom country info for a given device)? > With hardware that restricts operation to the capabilities it was tested > and calibrated for, this will likely result in a broken user experience > -- if they try and use a device on channel 13 and the device restricts > operation to channels 1 - 11, tuning operations will fail. Yes, makes sense to enforce this all the way through to userspace and refuse broadening of the limitations from what the driver announced. This does, however, mean that we cannot just have one global set of parameters because different hardware might behave differently, if I use a card manufactured for the somewhere else and it restricts operating to the eeprom limitations, then that means that I can potentially not make use of the full permitted spectrum for where I am, and hence will not want this card to restrict other cards in the system that may be certified for that broader spectrum. On the other hand, since the other card is not certified for the broader spectrum there should not be a way to force it to operate there since it may misbehave. The conclusion, it seems, is to have two different sets of limitations: (a) a global set of regulatory limitations that is completely controlled by external information (802.11d anouncements, user specified operating country, ...) and set by the userspace daemon that analyses all these things and (b) a device specific set of limitations initialised by the driver to the ranges supported by the card (what the card was certified for etc) Both (a) and (b) are initialised to some sort of (to be determined) 'safe set', (b) then given by the driver for each wiphy, and (a) by the userspace daemon. Then, when a given card operates, the kernel makes sure that operation is limited to adhere to both sets of limitations. Of course there needs to be some userspace interface to query both (a) and (b). This makes sure that - devices always only operate in the ranges they were certified with - operations is additionally limited to what the current locale permits - 802.11d is possible within those ranges that the devices allow Does that sound sane? johannes - 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
Re: [PATCH] Network Events Connector
On Mon, Oct 02, 2006 at 08:11:06AM +0200, Samir Bellabes ([EMAIL PROTECTED])
wrote:
>
> 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 open for the corresponding sport or not, and if
> so open the firewall for the application which get the corresponding sport.
>
> For people behind a firewall (non-running in the user box) we can have a
> authentification between the user box, which have set the port to state
> TCP_LISTEN for example, and the firewall, in a such way that the
> firewall's router will forward incoming packet for this port to the user
> box.
>
> It will avoid adding specific rules to the user's firewall-script, and
> let the firewall be more interactive for users.
>
> Signed-off-by: Samir Bellabes <[EMAIL PROTECTED]>
Interesting... Mybe it even prints the name of the application which is
trying to change port state?
I have couple of comments about structures you use, otherwise it looks
good, although I do not know if it is ok or not ok to include it into
mainline tree.
>From one point of view it is small and interesting piece of code, from other
point it is not clear if such functionality is needed...
Btw, you could also create netlink/connector based firewall rules
update, I think people with hundreds of rules in one table will bless
you after that.
> +#ifndef CN_NET_H
> +#define CN_NET_H
> +
> +#include
> +#include
> +
> +/*
> + * Userspace sends this enum to register with the kernel that it is listening
> + * for events on the connector.
> + */
> +enum cn_net_status {
> + CN_NET_LISTEN = 1,
> + CN_NET_IGNORE = 2
> +};
> +
> +struct net_event {
> + enum event {
> + NET_EVENT_NONE = 0x,
> + NET_EVENT_TCP_LISTEN= 0x0001,
> + NET_EVENT_TCP_CLOSE = 0x0002,
> + NET_EVENT_UDP_BIND = 0x0004,
> + NET_EVENT_UDP_CLOSE = 0x0008,
> + NET_EVENT_DCCP_LISTEN = 0x0010,
> + NET_EVENT_DCCP_CLOSE= 0x0020,
> + NET_EVENT_MAX = 0x8000
> + } event;
> + struct timespec timestamp;
Doesn't this monster have different size in 64 and 32 bit environments?
> + union {
> + struct {
> + __u32 err;
> + } ack;
> +
> + struct {
> + unsigned int family;
> + union {
> + struct in6_addr ipv6;
> + unsigned long ipv4;
Please no longs in code which is supposed to be used simultaneously in
32 and 64 bit environments.
> + } saddr;
> + unsigned int sport;
> + } data;
> + } net_event_data;
> +};
--
Evgeniy Polyakov
-
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
Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh
Sorry, I had typed wrong word. It is because patent issue. Thnaks. - Original Message - From: "Roland Dreier" <[EMAIL PROTECTED]> To: "Andrew Morton" <[EMAIL PROTECTED]> Cc: "Jesse Huang" <[EMAIL PROTECTED]>; ; ; <[EMAIL PROTECTED]> Sent: Monday, October 02, 2006 3:00 PM Subject: Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh > > 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.. Actually I think this patch needs to be handled delicately -- because based on earlier emails from Jesse (http://www.mail-archive.com/netdev@vger.kernel.org/msg22254.html), I am pretty sure that "pattern" is a typo for "patent". So I guess the question is what exactly the patent covers and what the implications of having the current kernel code are. - R. - 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
Re: [PATCH 1/5] remove TxStartThresh and RxEarlyThresh
> > 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.. Actually I think this patch needs to be handled delicately -- because based on earlier emails from Jesse (http://www.mail-archive.com/netdev@vger.kernel.org/msg22254.html), I am pretty sure that "pattern" is a typo for "patent". So I guess the question is what exactly the patent covers and what the implications of having the current kernel code are. - R. - 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
