* Re: [PATCH net-next 2/2] VXLAN: Use tunnel_ip_select_ident() for tunnel IP-Identification.
From: David Miller @ 2013-02-25 20:48 UTC (permalink / raw)
To: pshelar; +Cc: netdev, edumazet, jesse, stephen
In-Reply-To: <1361554240-1678-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Fri, 22 Feb 2013 09:30:40 -0800
> tunnel_ip_select_ident() is more efficient when generating ip-header
> id given inner packet is of ipv4 type.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2 v2] IP_GRE: Fix IP-Identification.
From: David Miller @ 2013-02-25 20:48 UTC (permalink / raw)
To: pshelar; +Cc: netdev, edumazet, jesse, stephen
In-Reply-To: <1361554230-1645-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Fri, 22 Feb 2013 09:30:30 -0800
> GRE-GSO generates ip fragments with id 0,2,3,4... for every
> GSO packet, which is not correct. Following patch fixes it
> by setting ip-header id unique id of fragments are allowed.
> As Eric Dumazet suggested it is optimized by using inner ip-header
> whenever inner packet is ipv4.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] Revert "ip_gre: propogate target device GSO capability to the tunnel device"
From: David Miller @ 2013-02-25 20:48 UTC (permalink / raw)
To: dmitry; +Cc: pshelar, netdev
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F1C01B72C@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Mon, 25 Feb 2013 11:38:36 +0000
>> -----Original Message-----
>> From: Pravin B Shelar [mailto:pshelar@nicira.com]
>> Sent: Monday, February 25, 2013 8:05 AM
>> To: davem@davemloft.net
>> Cc: netdev@vger.kernel.org; Dmitry Kravkov; Pravin B Shelar
>> Subject: [PATCH net-next 2/2] Revert "ip_gre: propogate target device GSO capability to the tunnel device"
>>
>> This reverts commit eb6b9a8cad65e820b145547844b108117cece3a0.
>>
>> Above commit limits GSO capability of gre device to just TSO, but
>> software GRE-GSO is capable of handling all GSO capabilities.
>>
>> This patch also fixes following panic which reverted commit introduced:-
...
>> CC: Dmitry Kravkov <dmitry@broadcom.com>
>> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
...
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] IP_GRE: Fix GRE_CSUM case.
From: David Miller @ 2013-02-25 20:48 UTC (permalink / raw)
To: dmitry; +Cc: pshelar, netdev
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F1C01B740@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Mon, 25 Feb 2013 11:40:06 +0000
>> -----Original Message-----
>> From: Pravin B Shelar [mailto:pshelar@nicira.com]
>> Sent: Monday, February 25, 2013 8:05 AM
>> To: davem@davemloft.net
>> Cc: netdev@vger.kernel.org; Dmitry Kravkov; Pravin B Shelar
>> Subject: [PATCH net-next 1/2] IP_GRE: Fix GRE_CSUM case.
>>
>> commit "ip_gre: allow CSUM capable devices to handle packets"
>> aa0e51cdda005cd37e2, broke GRE_CSUM case.
>> GRE_CSUM needs checksum computed for inner packet. Therefore
>> csum-calculation can not be offloaded if tunnel device requires
>> GRE_CSUM. Following patch fixes it by computing inner packet checksum
>> for GRE_CSUM type, for all other type of GRE devices csum is offloaded.
>>
>> CC: Dmitry Kravkov <dmitry@broadcom.com>
>> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
...
> Tested the series on two different devices
>
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
>
Applied.
^ permalink raw reply
* Re: [PATCH] b43: Fix lockdep splat on module unload
From: David Miller @ 2013-02-25 20:48 UTC (permalink / raw)
To: Larry.Finger; +Cc: linville, linux-wireless, netdev, stable
In-Reply-To: <1361808564-22684-1-git-send-email-Larry.Finger@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon, 25 Feb 2013 10:09:24 -0600
> On unload, b43 produces a lockdep warning that can be summarized in the
> following way:
>
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.8.0-wl+ #117 Not tainted
> -------------------------------------------------------
> modprobe/5557 is trying to acquire lock:
> ((&wl->firmware_load)){+.+.+.}, at: [<ffffffff81062160>] flush_work+0x0/0x2a0
>
> but task is already holding lock:
> (rtnl_mutex){+.+.+.}, at: [<ffffffff813bd7d2>] rtnl_lock+0x12/0x20
>
> which lock already depends on the new lock.
> [ INFO: possible circular locking dependency detected ]
> ======================================================
>
> The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html.
> To summarize, commit 6b6fa58 added a 'cancel_work_sync(&wl->firmware_load)'
> call in the wrong place.
>
> The fix is to move the cancel_work_sync() call to b43_bcma_remove() and
> b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in
> diagnosing the log output.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Applied.
^ permalink raw reply
* Re: [PATCH][FIX] bgmac: fix indexing of 2nd level loops
From: David Miller @ 2013-02-25 20:47 UTC (permalink / raw)
To: zajec5; +Cc: netdev, tvb
In-Reply-To: <1361816546-10171-1-git-send-email-zajec5@gmail.com>
From: Rafał Miłecki <zajec5@gmail.com>
Date: Mon, 25 Feb 2013 19:22:26 +0100
> We were using the same variable for iterating two nested loops.
>
> Reported-by: Tijs Van Buggenhout <tvb@able.be>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless 2013-02-25
From: David Miller @ 2013-02-25 20:46 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130225201748.GC6455@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 25 Feb 2013 15:17:49 -0500
> This is a batch of fixes intended for the 3.9 stream...
>
> Avinash Patil gives us a mwifiex fix to prevent a system freeze when
> that driver is unloaded.
>
> Daniel Drake brings a patch to avoid dropping the carrier flag across a
> suspend. This prevents improper packet drops.
>
> Wei Yongjun delivers a brcmfmac for a lock leak on an error path.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* pull request: wireless 2013-02-25
From: John W. Linville @ 2013-02-25 20:17 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
This is a batch of fixes intended for the 3.9 stream...
Avinash Patil gives us a mwifiex fix to prevent a system freeze when
that driver is unloaded.
Daniel Drake brings a patch to avoid dropping the carrier flag across a
suspend. This prevents improper packet drops.
Wei Yongjun delivers a brcmfmac for a lock leak on an error path.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit ea5cdccc46d392b73d941c723630d37094e8e8ea:
net/pasemi: Fix missing coding style (2013-02-24 21:22:47 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 6d6436fbcbc43febe2481d3488f3bb5271ec2eb0:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-02-25 14:50:31 -0500)
----------------------------------------------------------------
Avinash Patil (1):
mwifiex: fix system freeze while reloading driver
Daniel Drake (1):
mwifiex: don't drop carrier flag over suspend
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Wei Yongjun (1):
brcmfmac: fix missing unlock on error in brcmf_notify_vif_event()
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 4 +++-
drivers/net/wireless/mwifiex/pcie.c | 21 ++-------------------
drivers/net/wireless/mwifiex/sdio.c | 9 ---------
3 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index cecc3ef..2af9c0f 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -4615,8 +4615,10 @@ static s32 brcmf_notify_vif_event(struct brcmf_if *ifp,
switch (ifevent->action) {
case BRCMF_E_IF_ADD:
/* waiting process may have timed out */
- if (!cfg->vif_event.vif)
+ if (!cfg->vif_event.vif) {
+ mutex_unlock(&event->vif_event_lock);
return -EBADF;
+ }
ifp->vif = vif;
vif->ifp = ifp;
diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
index 4b54bcf..35c7972 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -171,7 +171,7 @@ static int mwifiex_pcie_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct mwifiex_adapter *adapter;
struct pcie_service_card *card;
- int hs_actived, i;
+ int hs_actived;
if (pdev) {
card = (struct pcie_service_card *) pci_get_drvdata(pdev);
@@ -191,9 +191,6 @@ static int mwifiex_pcie_suspend(struct pci_dev *pdev, pm_message_t state)
/* Indicate device suspended */
adapter->is_suspended = true;
- for (i = 0; i < adapter->priv_num; i++)
- netif_carrier_off(adapter->priv[i]->netdev);
-
return 0;
}
@@ -209,7 +206,6 @@ static int mwifiex_pcie_resume(struct pci_dev *pdev)
{
struct mwifiex_adapter *adapter;
struct pcie_service_card *card;
- int i;
if (pdev) {
card = (struct pcie_service_card *) pci_get_drvdata(pdev);
@@ -231,10 +227,6 @@ static int mwifiex_pcie_resume(struct pci_dev *pdev)
adapter->is_suspended = false;
- for (i = 0; i < adapter->priv_num; i++)
- if (adapter->priv[i]->media_connected)
- netif_carrier_on(adapter->priv[i]->netdev);
-
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
MWIFIEX_ASYNC_CMD);
@@ -916,17 +908,8 @@ static int mwifiex_pcie_delete_sleep_cookie_buf(struct mwifiex_adapter *adapter)
static int mwifiex_clean_pcie_ring_buf(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
- const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
- u32 rdptr;
-
- /* Read the TX ring read pointer set by firmware */
- if (mwifiex_read_reg(adapter, reg->tx_rdptr, &rdptr)) {
- dev_err(adapter->dev,
- "Flush TXBD: failed to read reg->tx_rdptr\n");
- return -1;
- }
- if (!mwifiex_pcie_txbd_empty(card, rdptr)) {
+ if (!mwifiex_pcie_txbd_empty(card, card->txbd_rdptr)) {
card->txbd_flush = 1;
/* write pointer already set at last send
* send dnld-rdy intr again, wait for completion.
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index e63f646..363ba31 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -161,7 +161,6 @@ static int mwifiex_sdio_suspend(struct device *dev)
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
mmc_pm_flag_t pm_flag = 0;
- int i;
int ret = 0;
if (func) {
@@ -198,9 +197,6 @@ static int mwifiex_sdio_suspend(struct device *dev)
/* Indicate device suspended */
adapter->is_suspended = true;
- for (i = 0; i < adapter->priv_num; i++)
- netif_carrier_off(adapter->priv[i]->netdev);
-
return ret;
}
@@ -220,7 +216,6 @@ static int mwifiex_sdio_resume(struct device *dev)
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
mmc_pm_flag_t pm_flag = 0;
- int i;
if (func) {
pm_flag = sdio_get_host_pm_caps(func);
@@ -243,10 +238,6 @@ static int mwifiex_sdio_resume(struct device *dev)
adapter->is_suspended = false;
- for (i = 0; i < adapter->priv_num; i++)
- if (adapter->priv[i]->media_connected)
- netif_carrier_on(adapter->priv[i]->netdev);
-
/* Disable Host Sleep */
mwifiex_cancel_hs(mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA),
MWIFIEX_ASYNC_CMD);
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated)
From: rebelyouth hacklab @ 2013-02-25 20:23 UTC (permalink / raw)
To: netdev
Hi,
I'm writing again for the same issue about :
Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast
Ethernet (rev b0) 1.0.0.7 md5 /sha1 corrupted using NFS and samba
My solution in this past 7 months was one : don't use the chip (I also
deactivate the chip from the BIOS)
A friend of mine let me borrowed a pci-x with a Realtek RTL8168C/8111C.
The card worked in any condition, no problem with nfs or samba.
Unfortunately my friend need back the card for a project and I
activated back the Atheros card...and the problem is still there
I'm using at the moment a Debian sid with kernel 3.7.9 and a Chackra
2012 with kernel 3.7.6 and I see the atl1e is the same 1.0.0.7-NAPI :
modinfo atl1e
filename:
/lib/modules/3.7.9-amd64/kernel/drivers/net/ethernet/atheros/atl1e/atl1e.ko
version: 1.0.0.7-NAPI
license: GPL
description: Atheros 1000M Ethernet Network Driver
author: Atheros Corporation, <xiong.huang@atheros.com>, Jie
Yang <jie.yang@atheros.com>
srcversion: 440FEE0BD620C8D71C0B74A
alias: pci:v00001969d00001066sv*sd*bc*sc*i*
alias: pci:v00001969d00001026sv*sd*bc*sc*i*
depends:
intree: Y
vermagic: 3.7.9-amd64 SMP preempt mod_unload modversions
parm: tx_desc_cnt:Transmit description count (array of int)
parm: rx_mem_size:memory size of rx buffer(KB) (array of int)
parm: media_type:MediaType Select (array of int)
parm: int_mod_timer:Interrupt Moderator Timer (array of int)
I know the simple solution will be to buy a card with a different chip
(like the Realtek RTL8168C/8111C) but I would like to help the
community with this issue.
The problem : files bigger of 1Gb are corrupted (and file 400mb + I
get a corruption in the 75% of the cases)
I don't receive any oops on the kernel or any dmesg error on the
client side but the server receive a lot of errors in RX:
RX packets:78125369 errors:58741 dropped:0 overruns:58741 frame:0
This are the test I did:
I test the connection with another cable CAT 6e, tried another router,
a switch and direct connection, also tried to connect another adapter
to the server
to see if the chipset on the server (Ethernet controller: NVIDIA
Corporation MCP79 Ethernet (rev b1) ) was the one who send corrupt
data or have a conflict with the atheros, but this, from my test,
wasn't the case
Software test:
I'm using Nfs 4 with this setting on the server:
/media 192.168.0.0/24(rw,fsid=0,no_subtree_check,sync)
/media/disk 192.168.0.0/24(rw,nohide,insecure,no_subtree_check,sync)
(tried async but doesn't fix the issue)
on the client : 192.168.0.1:/ /nfs nfs4
defaults,users,_netdev 0 0 (tried rsize=32768,wsize=32768, async
without success)
I tried too copy large zero files (400mb, 1gb, 4gb,8gb ,16gb) and the
sha1/md5 are ok
if I try a iso or vdi or a video bigger on these above that the
corruption occurs all the time,
same issue if I use samba.
I tried big DVD isos and separate files zip an rar and there
areperfect in Windows, Freebsd and Mac OS X (samba,ftp,nfs) the
ipconfig
on the server showing is all ok
Temp solution :
1) disable TSO with ethtool -K eth0 tso off working at 80% for some reason
2) set the fstab on the nfs to use proto=udp working but samba files
are still corrupted
3) with the usb adapter with Axis AX88772A I have no problem with nfs
and samba with standard setting (the same setting I used with the
Realtek RTL8168C/8111C)
I hope these information will help to find the solution and I'm will
available for others tests.
Here my lspci -vvv:
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
Subsystem: Advanced Micro Devices [AMD] RS780 Host Bridge
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI
bridge (ext gfx port 0) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fbe00000-fbefffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI
bridge (PCIE port 2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fbf00000-fbffffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport
00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (prog-if 01 [AHCI 1.0])
Subsystem: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 42
Region 0: I/O ports at c000 [size=8]
Region 1: I/O ports at b000 [size=4]
Region 2: I/O ports at a000 [size=8]
Region 3: I/O ports at 9000 [size=4]
Region 4: I/O ports at 8000 [size=16]
Region 5: Memory at fbdffc00 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ahci
00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller (prog-if 10 [OHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbdfd000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:12.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB
OHCI1 Controller (prog-if 10 [OHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI SB7x0 USB
OHCI1 Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbdfe000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4397
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fbdff800 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: ehci_hcd
00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI0 Controller (prog-if 10 [OHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4398
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fbdfb000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB
OHCI1 Controller (prog-if 10 [OHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4399
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fbdfc000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB EHCI Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 19
Region 0: Memory at fbdff400 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: ehci_hcd
00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus
Controller (rev 3c)
Subsystem: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx-
Capabilities: <access denied>
00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 IDE Controller (prog-if 8a [Master SecP PriP])
Subsystem: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 IDE Controller
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at ff00 [size=16]
Capabilities: <access denied>
Kernel driver in use: pata_atiixp
00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00
Azalia (Intel HDA)
Subsystem: ASUSTeK Computer Inc. Device 8357
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbdf4000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 LPC host controller
Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4383
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to
PCI Bridge (prog-if 01 [Subtractive decode])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: fff00000-000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI
SB7x0/SB8x0/SB9x0 USB OHCI2 Controller (prog-if 10 [OHCI])
Subsystem: Advanced Micro Devices [AMD] nee ATI Device 4396
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 18
Region 0: Memory at fbdfa000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
HyperTransport Configuration
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: <access denied>
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Address Map
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
DRAM Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Miscellaneous Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Capabilities: <access denied>
Kernel driver in use: k10temp
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor
Link Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI Juniper [Radeon HD 5700 Series] (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. Device 2140
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 43
Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 2: Memory at fbec0000 (64-bit, non-prefetchable) [size=128K]
Region 4: I/O ports at d000 [size=256]
Expansion ROM at fbea0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: radeon
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Juniper
HDMI Audio [Radeon HD 5700 Series]
Subsystem: Micro-Star International Co., Ltd. Device aa58
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 44
Region 0: Memory at fbefc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: snd_hda_intel
02:00.0 Ethernet controller: Atheros Communications Inc.
AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)
Subsystem: ASUSTeK Computer Inc. Device 831c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at fbfc0000 (64-bit, non-prefetchable) [size=256K]
Region 2: I/O ports at ec00 [size=128]
Capabilities: <access denied>
Kernel driver in use: ATL1E
And the lsusb :Bus 001 Device 004: ID 0b95:772a ASIX Electronics Corp.
AX88772A Fast Ethernet
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Srivatsa S. Bhat @ 2013-02-25 19:26 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Michel Lespinasse, linux-doc, peterz, fweisbec, linux-kernel,
namhyung, mingo, linux-arch, linux, xiaoguangrong, wangyun,
paulmck, nikunj, linux-pm, rusty, rostedt, rjw, vincent.guittot,
tglx, linux-arm-kernel, netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <CACvQF53bdh4_BxF0y1fnTVR+T2OmRc0jmWQYftsvx92-fg-Lug@mail.gmail.com>
Hi Lai,
On 02/25/2013 09:23 PM, Lai Jiangshan wrote:
> Hi, Srivatsa,
>
> The target of the whole patchset is nice for me.
Cool! Thanks :-)
> A question: How did you find out the such usages of
> "preempt_disable()" and convert them? did all are converted?
>
Well, I scanned through the source tree for usages which implicitly
disabled CPU offline and converted them over. Its not limited to uses
of preempt_disable() alone - even spin_locks, rwlocks, local_irq_disable()
etc also help disable CPU offline. So I tried to dig out all such uses
and converted them. However, since the merge window is open, a lot of
new code is flowing into the tree. So I'll have to rescan the tree to
see if there are any more places to convert.
> And I think the lock is too complex and reinvent the wheel, why don't
> you reuse the lglock?
lglocks? No way! ;-) See below...
> I wrote an untested draft here.
>
> Thanks,
> Lai
>
> PS: Some HA tools(I'm writing one) which takes checkpoints of
> virtual-machines frequently, I guess this patchset can speedup the
> tools.
>
> From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
> From: Lai Jiangshan <laijs@cn.fujitsu.com>
> Date: Mon, 25 Feb 2013 23:14:27 +0800
> Subject: [PATCH] lglock: add read-preference local-global rwlock
>
> locality via lglock(trylock)
> read-preference read-write-lock via fallback rwlock_t
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
> include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
> kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 76 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/lglock.h b/include/linux/lglock.h
> index 0d24e93..30fe887 100644
> --- a/include/linux/lglock.h
> +++ b/include/linux/lglock.h
> @@ -67,4 +67,35 @@ void lg_local_unlock_cpu(struct lglock *lg, int cpu);
> void lg_global_lock(struct lglock *lg);
> void lg_global_unlock(struct lglock *lg);
>
> +struct lgrwlock {
> + unsigned long __percpu *fallback_reader_refcnt;
> + struct lglock lglock;
> + rwlock_t fallback_rwlock;
> +};
> +
> +#define DEFINE_LGRWLOCK(name) \
> + static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
> + = __ARCH_SPIN_LOCK_UNLOCKED; \
> + static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
> + struct lgrwlock name = { \
> + .fallback_reader_refcnt = &name ## _refcnt, \
> + .lglock = { .lock = &name ## _lock } }
> +
> +#define DEFINE_STATIC_LGRWLOCK(name) \
> + static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
> + = __ARCH_SPIN_LOCK_UNLOCKED; \
> + static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
> + static struct lgrwlock name = { \
> + .fallback_reader_refcnt = &name ## _refcnt, \
> + .lglock = { .lock = &name ## _lock } }
> +
> +static inline void lg_rwlock_init(struct lgrwlock *lgrw, char *name)
> +{
> + lg_lock_init(&lgrw->lglock, name);
> +}
> +
> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw);
> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw);
> +void lg_rwlock_global_write_lock(struct lgrwlock *lgrw);
> +void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw);
> #endif
> diff --git a/kernel/lglock.c b/kernel/lglock.c
> index 6535a66..463543a 100644
> --- a/kernel/lglock.c
> +++ b/kernel/lglock.c
> @@ -87,3 +87,48 @@ void lg_global_unlock(struct lglock *lg)
> preempt_enable();
> }
> EXPORT_SYMBOL(lg_global_unlock);
> +
> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
> +{
> + struct lglock *lg = &lgrw->lglock;
> +
> + preempt_disable();
> + if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
> + if (likely(arch_spin_trylock(this_cpu_ptr(lg->lock)))) {
> + rwlock_acquire_read(&lg->lock_dep_map, 0, 0, _RET_IP_);
> + return;
> + }
> + read_lock(&lgrw->fallback_rwlock);
> + }
> +
> + __this_cpu_inc(*lgrw->fallback_reader_refcnt);
> +}
> +EXPORT_SYMBOL(lg_rwlock_local_read_lock);
> +
> +void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
> +{
> + if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
> + lg_local_unlock(&lgrw->lglock);
> + return;
> + }
> +
> + if (!__this_cpu_dec_return(*lgrw->fallback_reader_refcnt))
> + read_unlock(&lgrw->fallback_rwlock);
> +
> + preempt_enable();
> +}
> +EXPORT_SYMBOL(lg_rwlock_local_read_unlock);
> +
If I read the code above correctly, all you are doing is implementing a
recursive reader-side primitive (ie., allowing the reader to call these
functions recursively, without resulting in a self-deadlock).
But the thing is, making the reader-side recursive is the least of our
problems! Our main challenge is to make the locking extremely flexible
and also safe-guard it against circular-locking-dependencies and deadlocks.
Please take a look at the changelog of patch 1 - it explains the situation
with an example.
> +void lg_rwlock_global_write_lock(struct lgrwlock *lgrw)
> +{
> + lg_global_lock(&lgrw->lglock);
This does a for-loop on all CPUs and takes their locks one-by-one. That's
exactly what we want to prevent, because that is the _source_ of all our
deadlock woes in this case. In the presence of perfect lock ordering
guarantees, this wouldn't have been a problem (that's why lglocks are
being used successfully elsewhere in the kernel). In the stop-machine()
removal case, the over-flexibility of preempt_disable() forces us to provide
an equally flexible locking alternative. Hence we can't use such per-cpu
locking schemes.
You might note that, for exactly this reason, I haven't actually used any
per-cpu _locks_ in this synchronization scheme, though it is named as
"per-cpu rwlocks". The only per-cpu component here are the refcounts, and
we consciously avoid waiting/spinning on them (because then that would be
equivalent to having per-cpu locks, which are deadlock-prone). We use
global rwlocks to get the deadlock-safety that we need.
> + write_lock(&lgrw->fallback_rwlock);
> +}
> +EXPORT_SYMBOL(lg_rwlock_global_write_lock);
> +
> +void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw)
> +{
> + write_unlock(&lgrw->fallback_rwlock);
> + lg_global_unlock(&lgrw->lglock);
> +}
> +EXPORT_SYMBOL(lg_rwlock_global_write_unlock);
>
Regards,
Srivatsa S. Bhat
^ permalink raw reply
* Re: How to hairpin two Ethernet interfaces together (L2 hub/repeater mode)?
From: Jamal Hadi Salim @ 2013-02-25 19:16 UTC (permalink / raw)
To: Petri Gynther; +Cc: netdev
In-Reply-To: <CAKuTDr_eC4Wrv=uGthGJk3Zps=fnyAxpqqmsSDau7ZLs4PGyZw@mail.gmail.com>
Look at tc action redirect. Add it to ingress of eth0 to match
everything and send out on eth1.
cheers,
jamal
On 13-02-22 07:10 PM, Petri Gynther wrote:
> Hi netdev:
>
> I'd like to hairpin two Ethernet interfaces together (e.g. eth0 and
> eth1) so that any frame received on eth0 is forwarded as-is to eth1
> and vice versa.
>
> Does Linux networking code support this? I've looked at the bridging
> code, but it doesn't seem to do this (at least trivially).
> Specifically, when eth0 and eth1 are added to bridge, unicast frames
> destined to eth0 (or eth1) MAC address end up to the bridge interface
> for local consumption, rather than being flooded to other ports on the
> bridge.
>
> Any trivial solutions to this? Can Linux bridge be configured in L2
> hub/repeater mode so that it simply floods every Rx frame to all other
> ports of the bridge?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH][FIX] bgmac: fix indexing of 2nd level loops
From: Rafał Miłecki @ 2013-02-25 18:22 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Tijs Van Buggenhout, Rafał Miłecki
We were using the same variable for iterating two nested loops.
Reported-by: Tijs Van Buggenhout <tvb@able.be>
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
Luckily it didn't case any real errors (thanks to the loops limits) but
I think it's ugly enough to make it a "FIX" anyway.
---
drivers/net/ethernet/broadcom/bgmac.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 67a03d5..3f62bef 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -436,6 +436,8 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
}
for (i = 0; i < BGMAC_MAX_RX_RINGS; i++) {
+ int j;
+
ring = &bgmac->rx_ring[i];
ring->num_slots = BGMAC_RX_RING_SLOTS;
ring->mmio_base = ring_base[i];
@@ -458,8 +460,8 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
bgmac_warn(bgmac, "DMA address using 0xC0000000 bit(s), it may need translation trick\n");
/* Alloc RX slots */
- for (i = 0; i < ring->num_slots; i++) {
- err = bgmac_dma_rx_skb_for_slot(bgmac, &ring->slots[i]);
+ for (j = 0; j < ring->num_slots; j++) {
+ err = bgmac_dma_rx_skb_for_slot(bgmac, &ring->slots[j]);
if (err) {
bgmac_err(bgmac, "Can't allocate skb for slot in RX ring\n");
goto err_dma_free;
@@ -496,6 +498,8 @@ static void bgmac_dma_init(struct bgmac *bgmac)
}
for (i = 0; i < BGMAC_MAX_RX_RINGS; i++) {
+ int j;
+
ring = &bgmac->rx_ring[i];
/* We don't implement unaligned addressing, so enable first */
@@ -505,11 +509,11 @@ static void bgmac_dma_init(struct bgmac *bgmac)
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_RINGHI,
upper_32_bits(ring->dma_base));
- for (i = 0, dma_desc = ring->cpu_base; i < ring->num_slots;
- i++, dma_desc++) {
+ for (j = 0, dma_desc = ring->cpu_base; j < ring->num_slots;
+ j++, dma_desc++) {
ctl0 = ctl1 = 0;
- if (i == ring->num_slots - 1)
+ if (j == ring->num_slots - 1)
ctl0 |= BGMAC_DESC_CTL0_EOT;
ctl1 |= BGMAC_RX_BUF_SIZE & BGMAC_DESC_CTL1_LEN;
/* Is there any BGMAC device that requires extension? */
@@ -517,8 +521,8 @@ static void bgmac_dma_init(struct bgmac *bgmac)
* B43_DMA64_DCTL1_ADDREXT_MASK;
*/
- dma_desc->addr_low = cpu_to_le32(lower_32_bits(ring->slots[i].dma_addr));
- dma_desc->addr_high = cpu_to_le32(upper_32_bits(ring->slots[i].dma_addr));
+ dma_desc->addr_low = cpu_to_le32(lower_32_bits(ring->slots[j].dma_addr));
+ dma_desc->addr_high = cpu_to_le32(upper_32_bits(ring->slots[j].dma_addr));
dma_desc->ctl0 = cpu_to_le32(ctl0);
dma_desc->ctl1 = cpu_to_le32(ctl1);
}
--
1.7.10.4
^ permalink raw reply related
* Re: AF_VSOCK and the LSMs
From: Casey Schaufler @ 2013-02-25 18:02 UTC (permalink / raw)
To: Paul Moore
Cc: netdev, linux-security-module, selinux, Andy King, Gerd Hoffmann,
Eric Paris, Casey Schaufler
In-Reply-To: <5429810.RVpOLLsSs4@sifl>
On 2/25/2013 8:55 AM, Paul Moore wrote:
> [NOTE/WARNING: we're veering away from the VSOCK discussion and towards a LSM
> stacking discussion; see my response to Gerd if you want to stay on topic.]
>
> On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
>> On 2/22/2013 4:45 PM, Paul Moore wrote:
>>> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
>>>> Please add an LSM blob. Please do not use a secid. I am currently
>>>> battling with secids in my efforts for multiple LSM support.
>>>>
>>>> ...
>>>>
>>>> I am going to be able to deal with secids for AF_INET only because
>>>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
>>>> be willing to have networking be optional.
>>> "prefers"? Really Casey, did you think I would let you get away with that
>>> statement? What a LSM "prefers" is really not relevant to the stacking
>>> effort, what a LSM _supports_ is what matters.
>> I suppose. My point, which you may refute if it is incorrect,
>> is that there are common, legitimate SELinux configurations which
>> eschew Netlabel in favor of XFRM.
> There are common, legitimate use cases which use exclusively NetLabel,
> exclusively labeled IPsec, and both. A LSM stacking design that forces
> SELinux to only operate with XFRM (labeled IPsec) is wrong. If you are giving
> admins the ability to selectively stack LSMs you should also allow them to
> selectively pick which non-shareable functionality they assign to each LSM.
That is the approach I'm taking. The kernel configuration
will specify which LSM gets Netlabel and which gets XFRM.
A Smack configuration that does not use Netlabel is possible,
but to my mind extremely uninteresting. If someone has a
use case that is best addressed using both Smack and SELinux*
it seems that the most likely configuration would be for
Smack to use Netlabel and SELinux XFRM.
------
* What that case might be is not something I'm especially keen
on considering in depth just now.
>>> SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and
>>> secmark.
>>>
>>> Smack _supports_ NetLabel (CIPSO).
>>>
>>> AppArmor and TOMOYO don't really do any of the forms of labeled networking
>>> that are relevant for this discussion.
>> I am informed that labeled networking is being developed as an
>> option for AppArmor.
> I've remember hearing the same several years ago too, until we see patches it
> doesn't make sense to spend a lot of time worrying about what the AppArmor
> developers plan to support. Regardless, if anything I think this only
> furthers the need to provide a mechanism to selectively assign non-shareable
> LSM functionality to individuals LSMs in a stacked scenario.
I have not seen patches, but as Smack+AppArmor and SELinux+AppArmor are
included in my success criteria for module stacking I have to keep the
plan in mind. BTW, Smack+SELinux is not a success criteria, but it would
sure feel good to be able to claim total victory.
>>> If you want to try option #3 I think we might be able to do something with
>>> NetLabel to support multiple LSMs as the label abstraction stuff should
>>> theoretically make this possible; although the NetLabel cache will need
>>> some work.
>> It is reasonably easy to restrict Netlabel to a single LSM,
>> and since SELinux seems better served by XFRM in most configurations ...
> I disagree. In some use cases SELinux is better served by XFRM, in others it
> is better served by NetLabel. Once again, I think you need to focus on what
> is possible with the LSMs rather than a particular set of use cases which
> happen to make the LSM stacking project easier.
I'm trying not to make too many architectural changes to the
code around the LSM mechanism itself. I don't see that as cost
effective or likely to be popular. If the implication of that is
that there are certain configurations that are unsupportable but
that have plausible alternatives I think it will do for phase I.
If you want SELinux using Netlabel and Smack using Netlabel at
the same time you're going to have to change something. That
might well involve reimplementing Smack in SELinux policy*,
switching SELinux to XFRM if that's reasonable or using other
mechanisms like containers. It's not like we have a shortage
of mechanisms available.
-----
* I'm still waiting to see this. It was only supposed to take
a couple days. :-)
>> and AppArmor intends to make networking an option that seems
>> like a viable strategy until Netlabel gets multiple LSM support.
> It would be nice if the AppArmor developers could share their plans - or have
> I missed them on the list? My apologies if that is the case, a pointer would
> be helpful ...
Agreed. I understand that priorities shift like sands
in the desert.
>>> Labeled IPsec is likely out due to the way it was designed unless you
>>> want to attempt to negotiate two labels during the IKE exchange (yuck). I
>>> think we can also rule out secmark as multi-LSM enabled due to the
>>> limitations on a 32 bit integer.
>> That was my take as well. But, since only SELinux uses those currently,
>> and I see little pressure for Smack to support them I don't have
>> a lot of incentive in that direction.
> Agreed.
>
>>>> If you have two LSMs that use secids you are never going to have a
>>>> rational way to get the information for both into one secid.
>>> Exactly, I don't disagree which is why I've always said that networking
>>> was going to be a major problem for the stacked LSM effort. Unfortunately
>>> it sounds like you haven't yet made any serious effort into resolving that
>>> problem other than saying "don't do that".
>> Oh believe me, I have made serious effort. I just haven't made
>> significant progress.
> True, that wasn't a fair comment for me to make - my apologies.
>
>> The good news is that there can be a networking configuration (SELinux with
>> XFRM, Smack with Netlabel, AppArmor with none) that is both supported and
>> rational.
> I disagree that the approach you are proposing is the one that should be
> adopted. I am very much in favor of providing the ability to selectively
> assign non-shareable LSM features when stacking. If you aren't able to create
> a mechanism to assign features when stacking, I think I would be more in favor
> of a "first come, first served" model (the first LSM gets whatever it wants,
> and each LSM stacked on top has to make do with what is left) over what you
> are currently proposing.
Yeah, you have to give people rope. The Kconfig files can suggest
something rational, but in the end people do the darnedest things.
Especially with security.
>> Options I have considered include:
>> - Netlabel support for discriminating LSM use by host,
>> just as it currently allows for unlabeled hosts.
> Hmm, interesting ... not sure what I think of this.
It breaks down on 127.0.0.1. Otherwise is looks pretty easy to do.
>> - Netlabel as an independent LSM. Lots of refactoring.
> Ungh, no.
4am, five time zones from home and hungover. The write-up looked
good, but it's a complete rewrite.
>> - secid maps.
> Can you elaborate on this? I can think of a few different meanings here ...
This fell out of my first shot at stacking, the one that never saw
the light of day for tax reasons. I had implemented a stacker LSM
that slid into the existing infrastructure. Hooks that asked for
secids got the secid from my LSM, not the underlying LSM secids.
There was a table much like the Smack label list that mapped the
global secids to sets of underlying secids. The obvious problem
is that that table grows quickly and can never go away.
>> - Remove secids completely in favor of blobs.
> Obviously ideal, but unlikely to happen unless the netdev crew change their
> mind on blobs in sk_buff.
>
>> I should have an updated patch set by month's end. I think it
>> will address the current LSM issues. I don't know that I can
>> say it will address everything new LSMs might want to try.
> I'll be sure to take a closer look then. I should have taken a closer look at
> your previous patches - my mistake and I'll take responsibility for that - but
> based on the discussion from the last security summit I was under the
> impression that stacking was only going to be allowed between "big" and
> "little" LSMs, that is obviously no longer the case.
It seemed like that would be a reasonable approach until AppArmor
started looking like a "big" LSM.
^ permalink raw reply
* Re: igb: NULL pointer dereference
From: Greg Rose @ 2013-02-25 17:10 UTC (permalink / raw)
To: Alex Williamson; +Cc: jeffrey.t.kirsher, linux-kernel, netdev
In-Reply-To: <1361752504.2532.9.camel@bling.home>
On Sun, 24 Feb 2013 17:35:04 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Linus' current tree I get the the oops below. I realize I'm still
> using the deprecated max_vfs= module option, but this isn't a very
> compatible or friendly migration path. I'm using an 82576 PF as an
> interface for connecting an iscsi root disk and I also use the VF off
> this interface for misc virtual machine assignment. Suggestions
> welcome on migrating to sysfs based sr-iov enabling from an initramfs
> without bouncing the PF interface, but I think the below needs to be
> fixed regardless. git bisected to:
This definitely looks like a bug. You should be able to use both
methods without a problem. I'll look into it and see if I can figure
out what's going on.
- Greg
>
> commit fa44f2f185f7f9da19d331929bb1b56c1ccd1d93
> Author: Greg Rose <gregory.v.rose@intel.com>
> Date: Thu Jan 17 01:03:06 2013 -0800
>
> igb: Enable SR-IOV configuration via PCI sysfs interface
>
> Implement callback in the driver for the new PCI bus driver
> interface that allows the user to enable/disable SR-IOV
> virtual functions in a device via the sysfs interface.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Thanks,
>
> Alex
>
>
> [ 4.831907] igb: Intel(R) Gigabit Ethernet Network Driver -
> version 4.1.2-k [ 4.838868] igb: Copyright (c) 2007-2012 Intel
> Corporation. [ 4.844710] igb 0000:01:00.0: Maximum of 7 VFs per
> PF, using max [ 4.850768] igb 0000:01:00.0: Enabling SR-IOV VFs
> using the module parameter is deprecated - please use the pci sysfs
> interface. [ 4.872310] systemd[1]: Starting dracut initqueue
> hook... Startin[ 4.877937] BUG: unable to handle kernel NULL
> pointer dereference at 0000000000000048 [ 4.887143] IP:
> [<ffffffffa015862d>] igb_reset+0xcd/0x460 [igb] [ 4.893175] PGD 0
> [ 4.895267] Oops: 0002 [#1] SMP [ 4.898666] Modules linked in:
> igb(+) ptp usb_storage pps_core iscsi_tcp be2iscsi bnx2i cnic uio
> cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx
> iscsi_boot_sysfs libiscsi scsi_transport_iscsi [ 4.918125] CPU 2
> [ 4.919959] Pid: 207, comm: systemd-udevd Not tainted 3.8.0-rc3+
> #278 LENOVO 4157CTO/LENOVO [ 4.928541] RIP:
> 0010:[<ffffffffa015862d>] [<ffffffffa015862d>] igb_reset+0xcd/0x460
> [igb] [ 4.937039] RSP: 0018:ffff880367f63b38 EFLAGS: 00010246
> [ 4.942409] RAX: 00000000000000ff RBX: ffff880367020800 RCX:
> 0000000000000001 [ 4.949601] RDX: 0000000000000000 RSI:
> 0000000000000202 RDI: ffff880367020800 [ 4.956803] RBP:
> ffff880367f63b58 R08: ffff88036814d408 R09: 0000000000000007
> [ 4.964004] R10: ffffffff813eea13 R11: 000000000000000f R12:
> ffff880367020d68 [ 4.971205] R13: ffff880371267000 R14:
> 0000000000000040 R15: ffff880367020000 [ 4.978398] FS:
> 00007fdebfc3b840(0000) GS:ffff88037fc80000(0000)
> knlGS:0000000000000000 [ 4.986549] CS: 0010 DS: 0000 ES: 0000
> CR0: 0000000080050033 [ 4.992369] CR2: 0000000000000048 CR3:
> 0000000367df3000 CR4: 00000000000007e0 [ 4.999649] DR0:
> 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.006893] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400 [ 5.014136] Process systemd-udevd (pid: 207,
> threadinfo ffff880367f62000, task ffff880367fa0000) [ 5.023108]
> Stack: [ 5.025280] ffff880371267000 ffff880371267098
> ffff880371267000 0000000000000001 [ 5.033327] ffff880367f63bd8
> ffffffffa01593e5 ffff880371267098 ffff880367020d68 [ 5.041400]
> 0000000000020000 ffff880367020800 0000000000000004 ffff880300007136
> [ 5.049451] Call Trace: [ 5.052050] [<ffffffffa01593e5>]
> igb_probe+0x855/0xde0 [igb] [ 5.058023] [<ffffffff8131eddb>]
> local_pci_probe+0x4b/0x80 [ 5.063925] [<ffffffff8131f0e1>]
> pci_device_probe+0x111/0x120 [ 5.070082] [<ffffffff813e4c1b>]
> driver_probe_device+0x8b/0x390 [ 5.076375] [<ffffffff813e4fcb>]
> __driver_attach+0xab/0xb0 [ 5.082303] [<ffffffff813e4f20>] ?
> driver_probe_device+0x390/0x390 [ 5.088736] [<ffffffff813e2ca5>]
> bus_for_each_dev+0x55/0x90 [ 5.094458] [<ffffffff813e458e>]
> driver_attach+0x1e/0x20 [ 5.099921] [<ffffffff813e41c0>]
> bus_add_driver+0x1a0/0x290 [ 5.105691] [<ffffffffa0180000>] ?
> 0xffffffffa017ffff [ 5.110937] [<ffffffffa0180000>] ?
> 0xffffffffa017ffff [ 5.116305] [<ffffffff813e5697>]
> driver_register+0x77/0x170 [ 5.122287] [<ffffffffa0180000>] ?
> 0xffffffffa017ffff [ 5.127786] [<ffffffff8131e0ab>]
> __pci_register_driver+0x4b/0x50 [ 5.134004] [<ffffffffa018004f>]
> igb_init_module+0x4f/0x1000 [igb] [ 5.140565]
> [<ffffffff8100215a>] do_one_initcall+0x12a/0x180 [ 5.146321]
> [<ffffffff810c3f3a>] load_module+0x1a8a/0x20c0 [ 5.152020]
> [<ffffffff8130f0a0>] ? ddebug_proc_open+0xc0/0xc0 [ 5.157914]
> [<ffffffff810c4647>] sys_init_module+0xd7/0x120 [ 5.163639]
> [<ffffffff81650ed9>] system_call_fastpath+0x16/0x1b [ 5.169702]
> Code: 83 e9 10 45 85 c9 89 8b 14 08 00 00 74 4d 31 c9 66 0f 1f 44 00
> 00 48 63 d1 83 c1 01 48 8d 14 52 48 c1 e2 05 48 03 93 98 0e 00 00
> <83> 62 48 08 3b 8b 94 0e 00 00 72 df 48 89 df e8 2f da ff ff 48
> [ 5.192637] RIP [<ffffffffa015862d>] igb_reset+0xcd/0x460 [igb] g
> dracut initque[ 5.198783] RSP <ffff880367f63b38> [ 5.203660]
> CR2: 0000000000000048 ue hook... [ 5.207169] ---[ end trace
> 494789df673e4a4c ]---
>
>
^ permalink raw reply
* Re: AF_VSOCK and the LSMs
From: Paul Moore @ 2013-02-25 16:55 UTC (permalink / raw)
To: Casey Schaufler
Cc: netdev, linux-security-module, selinux, Andy King, Gerd Hoffmann,
Eric Paris
In-Reply-To: <5129541B.4030806@schaufler-ca.com>
[NOTE/WARNING: we're veering away from the VSOCK discussion and towards a LSM
stacking discussion; see my response to Gerd if you want to stay on topic.]
On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
> On 2/22/2013 4:45 PM, Paul Moore wrote:
> > On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
> >> Please add an LSM blob. Please do not use a secid. I am currently
> >> battling with secids in my efforts for multiple LSM support.
> >>
> >> ...
> >>
> >> I am going to be able to deal with secids for AF_INET only because
> >> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
> >> be willing to have networking be optional.
> >
> > "prefers"? Really Casey, did you think I would let you get away with that
> > statement? What a LSM "prefers" is really not relevant to the stacking
> > effort, what a LSM _supports_ is what matters.
>
> I suppose. My point, which you may refute if it is incorrect,
> is that there are common, legitimate SELinux configurations which
> eschew Netlabel in favor of XFRM.
There are common, legitimate use cases which use exclusively NetLabel,
exclusively labeled IPsec, and both. A LSM stacking design that forces
SELinux to only operate with XFRM (labeled IPsec) is wrong. If you are giving
admins the ability to selectively stack LSMs you should also allow them to
selectively pick which non-shareable functionality they assign to each LSM.
> > SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and
> > secmark.
> >
> > Smack _supports_ NetLabel (CIPSO).
> >
> > AppArmor and TOMOYO don't really do any of the forms of labeled networking
> > that are relevant for this discussion.
>
> I am informed that labeled networking is being developed as an
> option for AppArmor.
I've remember hearing the same several years ago too, until we see patches it
doesn't make sense to spend a lot of time worrying about what the AppArmor
developers plan to support. Regardless, if anything I think this only
furthers the need to provide a mechanism to selectively assign non-shareable
LSM functionality to individuals LSMs in a stacked scenario.
> > If you want to try option #3 I think we might be able to do something with
> > NetLabel to support multiple LSMs as the label abstraction stuff should
> > theoretically make this possible; although the NetLabel cache will need
> > some work.
>
> It is reasonably easy to restrict Netlabel to a single LSM,
> and since SELinux seems better served by XFRM in most configurations ...
I disagree. In some use cases SELinux is better served by XFRM, in others it
is better served by NetLabel. Once again, I think you need to focus on what
is possible with the LSMs rather than a particular set of use cases which
happen to make the LSM stacking project easier.
> and AppArmor intends to make networking an option that seems
> like a viable strategy until Netlabel gets multiple LSM support.
It would be nice if the AppArmor developers could share their plans - or have
I missed them on the list? My apologies if that is the case, a pointer would
be helpful ...
> > Labeled IPsec is likely out due to the way it was designed unless you
> > want to attempt to negotiate two labels during the IKE exchange (yuck). I
> > think we can also rule out secmark as multi-LSM enabled due to the
> > limitations on a 32 bit integer.
>
> That was my take as well. But, since only SELinux uses those currently,
> and I see little pressure for Smack to support them I don't have
> a lot of incentive in that direction.
Agreed.
> >> If you have two LSMs that use secids you are never going to have a
> >> rational way to get the information for both into one secid.
> >
> > Exactly, I don't disagree which is why I've always said that networking
> > was going to be a major problem for the stacked LSM effort. Unfortunately
> > it sounds like you haven't yet made any serious effort into resolving that
> > problem other than saying "don't do that".
>
> Oh believe me, I have made serious effort. I just haven't made
> significant progress.
True, that wasn't a fair comment for me to make - my apologies.
> The good news is that there can be a networking configuration (SELinux with
> XFRM, Smack with Netlabel, AppArmor with none) that is both supported and
> rational.
I disagree that the approach you are proposing is the one that should be
adopted. I am very much in favor of providing the ability to selectively
assign non-shareable LSM features when stacking. If you aren't able to create
a mechanism to assign features when stacking, I think I would be more in favor
of a "first come, first served" model (the first LSM gets whatever it wants,
and each LSM stacked on top has to make do with what is left) over what you
are currently proposing.
> Options I have considered include:
> - Netlabel support for discriminating LSM use by host,
> just as it currently allows for unlabeled hosts.
Hmm, interesting ... not sure what I think of this.
> - Netlabel as an independent LSM. Lots of refactoring.
Ungh, no.
> - secid maps.
Can you elaborate on this? I can think of a few different meanings here ...
> - Remove secids completely in favor of blobs.
Obviously ideal, but unlikely to happen unless the netdev crew change their
mind on blobs in sk_buff.
> I should have an updated patch set by month's end. I think it
> will address the current LSM issues. I don't know that I can
> say it will address everything new LSMs might want to try.
I'll be sure to take a closer look then. I should have taken a closer look at
your previous patches - my mistake and I'll take responsibility for that - but
based on the discussion from the last security summit I was under the
impression that stacking was only going to be allowed between "big" and
"little" LSMs, that is obviously no longer the case.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply
* [PATCH] b43: Fix lockdep splat on module unload
From: Larry Finger @ 2013-02-25 16:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Stable
On unload, b43 produces a lockdep warning that can be summarized in the
following way:
======================================================
[ INFO: possible circular locking dependency detected ]
3.8.0-wl+ #117 Not tainted
-------------------------------------------------------
modprobe/5557 is trying to acquire lock:
((&wl->firmware_load)){+.+.+.}, at: [<ffffffff81062160>] flush_work+0x0/0x2a0
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff813bd7d2>] rtnl_lock+0x12/0x20
which lock already depends on the new lock.
[ INFO: possible circular locking dependency detected ]
======================================================
The full output is available at http://lkml.indiana.edu/hypermail/linux/kernel/1302.3/00060.html.
To summarize, commit 6b6fa58 added a 'cancel_work_sync(&wl->firmware_load)'
call in the wrong place.
The fix is to move the cancel_work_sync() call to b43_bcma_remove() and
b43_ssb_remove(). Thanks to Johannes Berg and Michael Buesch for help in
diagnosing the log output.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [V3.5+]
---
drivers/net/wireless/b43/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 806e34c..0568273 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4214,7 +4214,6 @@ redo:
mutex_unlock(&wl->mutex);
cancel_delayed_work_sync(&dev->periodic_work);
cancel_work_sync(&wl->tx_work);
- cancel_work_sync(&wl->firmware_load);
mutex_lock(&wl->mutex);
dev = wl->current_dev;
if (!dev || b43_status(dev) < B43_STAT_STARTED) {
@@ -5434,6 +5433,7 @@ static void b43_bcma_remove(struct bcma_device *core)
/* We must cancel any work here before unregistering from ieee80211,
* as the ieee80211 unreg will destroy the workqueue. */
cancel_work_sync(&wldev->restart_work);
+ cancel_work_sync(&wl->firmware_load);
B43_WARN_ON(!wl);
if (!wldev->fw.ucode.data)
@@ -5510,6 +5510,7 @@ static void b43_ssb_remove(struct ssb_device *sdev)
/* We must cancel any work here before unregistering from ieee80211,
* as the ieee80211 unreg will destroy the workqueue. */
cancel_work_sync(&wldev->restart_work);
+ cancel_work_sync(&wl->firmware_load);
B43_WARN_ON(!wl);
if (!wldev->fw.ucode.data)
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Lai Jiangshan @ 2013-02-25 15:53 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: Michel Lespinasse, linux-doc, peterz, fweisbec, linux-kernel,
namhyung, mingo, linux-arch, linux, xiaoguangrong, wangyun,
paulmck, nikunj, linux-pm, rusty, rostedt, rjw, vincent.guittot,
tglx, linux-arm-kernel, netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <51226F91.7000108@linux.vnet.ibm.com>
Hi, Srivatsa,
The target of the whole patchset is nice for me.
A question: How did you find out the such usages of
"preempt_disable()" and convert them? did all are converted?
And I think the lock is too complex and reinvent the wheel, why don't
you reuse the lglock?
I wrote an untested draft here.
Thanks,
Lai
PS: Some HA tools(I'm writing one) which takes checkpoints of
virtual-machines frequently, I guess this patchset can speedup the
tools.
>From 01db542693a1b7fc6f9ece45d57cb529d9be5b66 Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Mon, 25 Feb 2013 23:14:27 +0800
Subject: [PATCH] lglock: add read-preference local-global rwlock
locality via lglock(trylock)
read-preference read-write-lock via fallback rwlock_t
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
include/linux/lglock.h | 31 +++++++++++++++++++++++++++++++
kernel/lglock.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/include/linux/lglock.h b/include/linux/lglock.h
index 0d24e93..30fe887 100644
--- a/include/linux/lglock.h
+++ b/include/linux/lglock.h
@@ -67,4 +67,35 @@ void lg_local_unlock_cpu(struct lglock *lg, int cpu);
void lg_global_lock(struct lglock *lg);
void lg_global_unlock(struct lglock *lg);
+struct lgrwlock {
+ unsigned long __percpu *fallback_reader_refcnt;
+ struct lglock lglock;
+ rwlock_t fallback_rwlock;
+};
+
+#define DEFINE_LGRWLOCK(name) \
+ static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
+ = __ARCH_SPIN_LOCK_UNLOCKED; \
+ static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
+ struct lgrwlock name = { \
+ .fallback_reader_refcnt = &name ## _refcnt, \
+ .lglock = { .lock = &name ## _lock } }
+
+#define DEFINE_STATIC_LGRWLOCK(name) \
+ static DEFINE_PER_CPU(arch_spinlock_t, name ## _lock) \
+ = __ARCH_SPIN_LOCK_UNLOCKED; \
+ static DEFINE_PER_CPU(unsigned long, name ## _refcnt); \
+ static struct lgrwlock name = { \
+ .fallback_reader_refcnt = &name ## _refcnt, \
+ .lglock = { .lock = &name ## _lock } }
+
+static inline void lg_rwlock_init(struct lgrwlock *lgrw, char *name)
+{
+ lg_lock_init(&lgrw->lglock, name);
+}
+
+void lg_rwlock_local_read_lock(struct lgrwlock *lgrw);
+void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw);
+void lg_rwlock_global_write_lock(struct lgrwlock *lgrw);
+void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw);
#endif
diff --git a/kernel/lglock.c b/kernel/lglock.c
index 6535a66..463543a 100644
--- a/kernel/lglock.c
+++ b/kernel/lglock.c
@@ -87,3 +87,48 @@ void lg_global_unlock(struct lglock *lg)
preempt_enable();
}
EXPORT_SYMBOL(lg_global_unlock);
+
+void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
+{
+ struct lglock *lg = &lgrw->lglock;
+
+ preempt_disable();
+ if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
+ if (likely(arch_spin_trylock(this_cpu_ptr(lg->lock)))) {
+ rwlock_acquire_read(&lg->lock_dep_map, 0, 0, _RET_IP_);
+ return;
+ }
+ read_lock(&lgrw->fallback_rwlock);
+ }
+
+ __this_cpu_inc(*lgrw->fallback_reader_refcnt);
+}
+EXPORT_SYMBOL(lg_rwlock_local_read_lock);
+
+void lg_rwlock_local_read_unlock(struct lgrwlock *lgrw)
+{
+ if (likely(!__this_cpu_read(*lgrw->fallback_reader_refcnt))) {
+ lg_local_unlock(&lgrw->lglock);
+ return;
+ }
+
+ if (!__this_cpu_dec_return(*lgrw->fallback_reader_refcnt))
+ read_unlock(&lgrw->fallback_rwlock);
+
+ preempt_enable();
+}
+EXPORT_SYMBOL(lg_rwlock_local_read_unlock);
+
+void lg_rwlock_global_write_lock(struct lgrwlock *lgrw)
+{
+ lg_global_lock(&lgrw->lglock);
+ write_lock(&lgrw->fallback_rwlock);
+}
+EXPORT_SYMBOL(lg_rwlock_global_write_lock);
+
+void lg_rwlock_global_write_unlock(struct lgrwlock *lgrw)
+{
+ write_unlock(&lgrw->fallback_rwlock);
+ lg_global_unlock(&lgrw->lglock);
+}
+EXPORT_SYMBOL(lg_rwlock_global_write_unlock);
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] SUNRPC: Fix possible NULL pointer dereference
From: Syam Sidhardhan @ 2013-02-25 15:21 UTC (permalink / raw)
To: Myklebust, Trond
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA9235DE4C7-VGJ86jkg8PeBTCzCEi1xmXOR4cbS7gtM96Bgd4bDwmQ@public.gmane.org>
Hi Trond,
On Mon, Feb 25, 2013 at 4:05 AM, Myklebust, Trond
<Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 2013-02-25 at 03:53 +0530, Syam Sidhardhan wrote:
>> Check for cred == NULL has to be done before accessing cred.
>>
>> Signed-off-by: Syam Sidhardhan <s.syam-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> ---
>> net/sunrpc/auth.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
>> index f529404..18678a6 100644
>> --- a/net/sunrpc/auth.c
>> +++ b/net/sunrpc/auth.c
>> @@ -695,10 +695,13 @@ rpcauth_invalcred(struct rpc_task *task)
>> {
>> struct rpc_cred *cred = task->tk_rqstp->rq_cred;
>>
>> + if (cred == NULL)
>> + return;
>> +
>> dprintk("RPC: %5u invalidating %s cred %p\n",
>> task->tk_pid, cred->cr_auth->au_ops->au_name, cred);
>> - if (cred)
>> - clear_bit(RPCAUTH_CRED_UPTODATE, &cred->cr_flags);
>> +
>> + clear_bit(RPCAUTH_CRED_UPTODATE, &cred->cr_flags);
>> }
>>
>> int
>
> Do we need that check at all?
I'm not sure whether we need that check or not. However
similar functions such as rpcauth_refreshcred(), rpcauth_uptodatecred() etc
are doing the same check inside. Cppcheck is throwing an error too.
Regards,
Syam
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: AF_VSOCK and the LSMs
From: Paul Moore @ 2013-02-25 15:06 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Andy King, netdev, linux-security-module, selinux, Eric Paris
In-Reply-To: <512B12EA.1000003@redhat.com>
On Monday, February 25, 2013 08:29:46 AM Gerd Hoffmann wrote:
> Hi,
Hello.
> >> I think perhaps this is the wrong layer at which to embed this. Think
> >> of that structure as an ethernet header, with VMCI being ethernet; it's
> >> what the device (and the hypervisor and peer) understand. So this
> >> really cannot be changed.
> >
> > Hmmm, so can VMware/VMCI-enabled guests send vmci_datagram packets
> > directly into the kernel? It isn't wrapped by things like AF_VSOCK? If
> > that is the case, then yes, we'll probably need to add a thin wrapper
> > struct to carry the security label; similar to the control packets but not
> > quite, as we have data to deal with unlike the control packets. However,
> > if vmci_datagram is an internal only structure, why not add the extra
> > field?
>
> vmci_datagram is part of the guest/host ABI I think.
>
> Data flow looks like this:
>
> (1) guest application opens a AF_VSOCK socket
> (2) guest sends data as usual (say send syscall).
> (3) vsock core hards over the packet to the transport layer
>
> (only vmci atm, but we wanna add virtio here).
>
> (4) transport layer passes data to the hypervisor (vmci uses a
>
> virtual pci device for that, virtio will do the same).
> ...
Okay, I think I found the core of my misunderstanding: I was under the
impression that the AF_VSOCK layer lived in the host kernel, not the guest
kernel.
With the VS_VSOCK layer in the guest kernel this all becomes much less
interesting. I'll take another look today, but I think the only changes we
probably want to make are with SELinux - the "virt_socket" object class - so
we can control which applications in the guest can use AF_VSOCK sockets. I
don't think we will need any changes to Smack but I'll take a closer look.
Also, all the changes I suggested earlier to VMCI aren't necessary; as you and
Andy point out, this is the wrong layer - we can't do a whole lot of
meaningful enforcement in the guest.
Thanks for the clarification.
-Paul
--
paul moore
security and virtualization @ redhat
^ permalink raw reply
* Re: Disable IPv4-mapped - enforce IPV6_V6ONLY
From: Alexander Holler @ 2013-02-25 14:47 UTC (permalink / raw)
To: David Laight; +Cc: YOSHIFUJI Hideaki, netdev, linux-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7168@saturn3.aculab.com>
Am 25.02.2013 14:23, schrieb David Laight:
>>> A proper solution would be to either return false if net.ipv6.bindv6only is true and optval is false
>> (which would break downward compatibility because it wouldn't just be a default and setsockopt might
>> return an error) or to introduce a new sysctl variable like net.ipv6.bindv6only_enforced_silently.
>> ("silently" because setsockopt() wouldn't return an error if net.ipv6.bindv6only is true and optval
>> (v6only in the example above) is false.)
>>>
>>> I would volunteer to write a patch which introduces something like
>> net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
>>>
>>> If so, the question remains if
>>>
>>> systemctl net.ipv6.bindv6only_enforced_silently = 1
>>>
>>> should set systemctl.net.ipv6.bindv6only too or if an error should be returned if
>> net.ipv6.bindv6only is false.
>>
>> I am not convinced why you need this, and I am not in favor of
>> enfocing IPV6_V6ONLY, but... some points:
It's some kind of security feature I want to have. I just don't want to
search for applications which are listening on IPv4 ports (too) even
when only IPv6 was configured. There exists several of them.
>>
>> - We should allow system-admin to "enforce" IPV6_V6ONLY to 0 as well.
>> - CAP_NET_ADMIN users should always be able to use both modes
>> (They can do sysctl anyway.)
>> - setsockopt should fail w/ EPERM if user tries to override.
>
> I can imagine that some programs will always try to clear IPV6_V6ONLY
> (maybe for portability with other OS which default to setting it
> for security reasons) and will error-exit if it fails.
> So non-silent enforcing could be a PITA.
Exactly.
> You really don't want to (globally) stop an application setting
> IPV6_V6ONLY, such a program may well be creating separate IPv4
> and IPv6 sockets.
Agreed. Applications which are setting IPV6_V6ONLY to true usually do
know what they are doing. But some braindead (configured) applications
are disabling it (and would bail out if setsockopt() would return an error).
>
> Some of this needs to be part of some application wide 'security'
> framework - that probably doesn't exist!
>
> Should there also be similar controls for the use of IPv4
> mapped addresses in actual on-the-wire IPv6 packets - eg those
> destined for a remote gateway on an IPv6 only system?
I think that can be handled by iptables by just blocking e.g.
::ffff:0:0/96 and ::0/96.
But it's a pain to find and take care of apps which are ignoring the
default (net.ipv6.bindv6only) and are disabling IPV6_V6ONLY explicit for
whatever reason.
Therefor I would like to have that
net.ipv6.bindv6only_enforced_silently. Disabling IPv4 in general is not
what I want.
Regards,
Alexander
^ permalink raw reply
* RE: Disable IPv4-mapped - enforce IPV6_V6ONLY
From: David Laight @ 2013-02-25 13:23 UTC (permalink / raw)
To: YOSHIFUJI Hideaki, Alexander Holler; +Cc: netdev, linux-kernel
In-Reply-To: <512B4EAF.2050301@linux-ipv6.org>
> > A proper solution would be to either return false if net.ipv6.bindv6only is true and optval is false
> (which would break downward compatibility because it wouldn't just be a default and setsockopt might
> return an error) or to introduce a new sysctl variable like net.ipv6.bindv6only_enforced_silently.
> ("silently" because setsockopt() wouldn't return an error if net.ipv6.bindv6only is true and optval
> (v6only in the example above) is false.)
> >
> > I would volunteer to write a patch which introduces something like
> net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
> >
> > If so, the question remains if
> >
> > systemctl net.ipv6.bindv6only_enforced_silently = 1
> >
> > should set systemctl.net.ipv6.bindv6only too or if an error should be returned if
> net.ipv6.bindv6only is false.
>
> I am not convinced why you need this, and I am not in favor of
> enfocing IPV6_V6ONLY, but... some points:
>
> - We should allow system-admin to "enforce" IPV6_V6ONLY to 0 as well.
> - CAP_NET_ADMIN users should always be able to use both modes
> (They can do sysctl anyway.)
> - setsockopt should fail w/ EPERM if user tries to override.
I can imagine that some programs will always try to clear IPV6_V6ONLY
(maybe for portability with other OS which default to setting it
for security reasons) and will error-exit if it fails.
So non-silent enforcing could be a PITA.
OTOH there might be programs/systems where silent failure is wrong.
You really don't want to (globally) stop an application setting
IPV6_V6ONLY, such a program may well be creating separate IPv4
and IPv6 sockets.
Some of this needs to be part of some application wide 'security'
framework - that probably doesn't exist!
Should there also be similar controls for the use of IPv4
mapped addresses in actual on-the-wire IPv6 packets - eg those
destined for a remote gateway on an IPv6 only system?
David
^ permalink raw reply
* [PATCH] NET/PHY: Eliminate the forced speed reduction algorithm
From: Kirill Kapranov @ 2013-02-25 12:25 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
>From Kirill Kapranov <kkk@nita.ru>,<kapranoff@inbox.ru>
NET/PHY: Eliminate the forced speed reduction algorithm.
In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed 100 duplex full) with an ethernet cable plugged off, the mentioned algorithm slows down a NIC speed, so further hooking up a cable does not lead to "link" state.
Signed-off-by: Kirill Kapranov <kkk@nita.ru>,<kapranoff@inbox.ru>
---
The purpose of the introduced patch is deletion of the forced speed reduction algorithm realization from the driver module "phy".
The above mentioned algorithm works in the following way: if the PHY detected unlink line state (connector plugged off), NIC speed is decreased step-by-step in the sequence:
100 full duplex
100 half duplex
10 full duplex
10 half duplex
with the latency circa 10 s per step, and stops at 10-HD value.
I have looked up RFC-802.3, and found, that the mentioned algorithm is neither quoted nor described. AFAIK, no one RFC describe the mentioned algorithm, so it may be a witty invention of the developer(s).
In the case of the fixed speed and duplex set, with the autonegotiation off, for a NIC (e.g. # ethtool -s eth0 autoneg off speed 100 duplex full) with ethernet cable plugged off, mentioned algorithm slows down NIC speed, so when ethernet connector is plugged in, connection will be inoperative: an ethernet switch will try to connect with 100/full (e.g.), a NIC will stay at 10/half.
Thus, this algorithm is destructive for the fixed speed/duplex mode (with autonegotiation off).
In the AUTO mode, the mentioned algorithm is inessential. The autonegotiation procedure works fine regardless an speed/duplex settings at the moment of connector hooking up.
Thus, there is no point in using of this algorithm in driver.
Tested at 2.6.38.7, applicable up to for 3.0.4.
--- linux/drivers/net/phy/phy.c.orig 2011-05-22 02:13:59.000000000 +0400
+++ linux/drivers/net/phy/phy.c 2012-04-28 12:49:37.000000000 +0400
@@ -457,34 +457,6 @@ void phy_stop_machine(struct phy_device
}
/**
- * phy_force_reduction - reduce PHY speed/duplex settings by one step
- * @phydev: target phy_device struct
- *
- * Description: Reduces the speed/duplex settings by one notch,
- * in this order--
- * 1000/FULL, 1000/HALF, 100/FULL, 100/HALF, 10/FULL, 10/HALF.
- * The function bottoms out at 10/HALF.
- */
-static void phy_force_reduction(struct phy_device *phydev)
-{
- int idx;
-
- idx = phy_find_setting(phydev->speed, phydev->duplex);
-
- idx++;
-
- idx = phy_find_valid(idx, phydev->supported);
-
- phydev->speed = settings[idx].speed;
- phydev->duplex = settings[idx].duplex;
-
- pr_info("Trying %d/%s\n", phydev->speed,
- DUPLEX_FULL == phydev->duplex ?
- "FULL" : "HALF");
-}
-
-
-/**
* phy_error - enter HALTED state for this PHY device
* @phydev: target phy_device struct
*
@@ -814,30 +786,12 @@ void phy_state_machine(struct work_struc
phydev->adjust_link(phydev->attached_dev);
} else if (0 == phydev->link_timeout--) {
- int idx;
needs_aneg = 1;
/* If we have the magic_aneg bit,
* we try again */
if (phydev->drv->flags & PHY_HAS_MAGICANEG)
break;
-
- /* The timer expired, and we still
- * don't have a setting, so we try
- * forcing it until we find one that
- * works, starting from the fastest speed,
- * and working our way down */
- idx = phy_find_valid(0, phydev->supported);
-
- phydev->speed = settings[idx].speed;
- phydev->duplex = settings[idx].duplex;
-
- phydev->autoneg = AUTONEG_DISABLE;
-
- pr_info("Trying %d/%s\n", phydev->speed,
- DUPLEX_FULL ==
- phydev->duplex ?
- "FULL" : "HALF");
}
break;
case PHY_NOLINK:
@@ -863,7 +817,6 @@ void phy_state_machine(struct work_struc
netif_carrier_on(phydev->attached_dev);
} else {
if (0 == phydev->link_timeout--) {
- phy_force_reduction(phydev);
needs_aneg = 1;
}
}
^ permalink raw reply
* Re: [PATCH] ehea: Fix possible NULL pointer dereference
From: Thadeu Lima de Souza Cascardo @ 2013-02-25 12:09 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: netdev
In-Reply-To: <1361746798-29215-1-git-send-email-s.syam@samsung.com>
On Mon, Feb 25, 2013 at 04:29:58AM +0530, Syam Sidhardhan wrote:
> Check for (queue == NULL) has to be done before accessing queue.
>
> Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
> ---
> drivers/net/ethernet/ibm/ehea/ehea_qmr.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ibm/ehea/ehea_qmr.c b/drivers/net/ethernet/ibm/ehea/ehea_qmr.c
> index 9b03033..a0820f7 100644
> --- a/drivers/net/ethernet/ibm/ehea/ehea_qmr.c
> +++ b/drivers/net/ethernet/ibm/ehea/ehea_qmr.c
> @@ -103,12 +103,14 @@ out_nomem:
>
> static void hw_queue_dtor(struct hw_queue *queue)
> {
> - int pages_per_kpage = PAGE_SIZE / queue->pagesize;
> + int pages_per_kpage;
> int i, nr_pages;
>
> if (!queue || !queue->queue_pages)
> return;
>
> + pages_per_kpage = PAGE_SIZE / queue->pagesize;
> +
> nr_pages = queue->queue_length / queue->pagesize;
>
> for (i = 0; i < nr_pages; i += pages_per_kpage)
> --
> 1.7.9.5
>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
^ permalink raw reply
* Re: Disable IPv4-mapped - enforce IPV6_V6ONLY
From: YOSHIFUJI Hideaki @ 2013-02-25 11:44 UTC (permalink / raw)
To: Alexander Holler; +Cc: netdev, linux-kernel
In-Reply-To: <51292A2B.3000304@ahsoftware.de>
Hello.
Alexander Holler wrote:
> Am 22.02.2013 16:21, schrieb Alexander Holler:
>> Hello,
>>
>> I'm searching for a way to either enforce IPV6_V6ONLY or to block
>> IPv4-mapped addresses on ipv6-sockets (e.g. by using iptables) system-wide.
>>
>> E.g. net.ipv6.bindv6only doesn't help if something calls
>>
>> int v6on = 0;
>> setsockopt(sd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6on, sizeof(v6on))
>>
>> In such a case I still want to disable or block IPv4-mapped addresses on
>> that socket, even if the program thinks it nows it better.
>>
>> Until now I haven't found a solution.
>
> I've now done it by the following hack:
>
> -----------
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index d1e2e8e..9eefd3e 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -235,7 +235,7 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> if (optlen < sizeof(int) ||
> inet_sk(sk)->inet_num)
> goto e_inval;
> - np->ipv6only = valbool;
> + np->ipv6only = valbool || net->ipv6.sysctl.bindv6only;
> retv = 0;
> break;
> -----------
>
> A proper solution would be to either return false if net.ipv6.bindv6only is true and optval is false (which would break downward compatibility because it wouldn't just be a default and setsockopt might return an error) or to introduce a new sysctl variable like net.ipv6.bindv6only_enforced_silently. ("silently" because setsockopt() wouldn't return an error if net.ipv6.bindv6only is true and optval (v6only in the example above) is false.)
>
> I would volunteer to write a patch which introduces something like net.ipv6.bindv6only_enforced_silently if some maintainer would give me his ok.
>
> If so, the question remains if
>
> systemctl net.ipv6.bindv6only_enforced_silently = 1
>
> should set systemctl.net.ipv6.bindv6only too or if an error should be returned if net.ipv6.bindv6only is false.
I am not convinced why you need this, and I am not in favor of
enfocing IPV6_V6ONLY, but... some points:
- We should allow system-admin to "enforce" IPV6_V6ONLY to 0 as well.
- CAP_NET_ADMIN users should always be able to use both modes
(They can do sysctl anyway.)
- setsockopt should fail w/ EPERM if user tries to override.
--yoshfuji
^ permalink raw reply
* RE: [PATCH net-next 1/2] IP_GRE: Fix GRE_CSUM case.
From: Dmitry Kravkov @ 2013-02-25 11:40 UTC (permalink / raw)
To: Pravin B Shelar, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <1361772305-1665-1-git-send-email-pshelar@nicira.com>
> -----Original Message-----
> From: Pravin B Shelar [mailto:pshelar@nicira.com]
> Sent: Monday, February 25, 2013 8:05 AM
> To: davem@davemloft.net
> Cc: netdev@vger.kernel.org; Dmitry Kravkov; Pravin B Shelar
> Subject: [PATCH net-next 1/2] IP_GRE: Fix GRE_CSUM case.
>
> commit "ip_gre: allow CSUM capable devices to handle packets"
> aa0e51cdda005cd37e2, broke GRE_CSUM case.
> GRE_CSUM needs checksum computed for inner packet. Therefore
> csum-calculation can not be offloaded if tunnel device requires
> GRE_CSUM. Following patch fixes it by computing inner packet checksum
> for GRE_CSUM type, for all other type of GRE devices csum is offloaded.
>
> CC: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> net/ipv4/ip_gre.c | 12 ++++++++----
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
> index 5ef4da7..9b4996d 100644
> --- a/net/ipv4/ip_gre.c
> +++ b/net/ipv4/ip_gre.c
> @@ -735,7 +735,7 @@ drop:
> return 0;
> }
>
> -static struct sk_buff *handle_offloads(struct sk_buff *skb)
> +static struct sk_buff *handle_offloads(struct ip_tunnel *tunnel, struct sk_buff *skb)
> {
> int err;
>
> @@ -745,8 +745,12 @@ static struct sk_buff *handle_offloads(struct sk_buff *skb)
> goto error;
> skb_shinfo(skb)->gso_type |= SKB_GSO_GRE;
> return skb;
> - }
> - if (skb->ip_summed != CHECKSUM_PARTIAL)
> + } else if (skb->ip_summed == CHECKSUM_PARTIAL &&
> + tunnel->parms.o_flags&GRE_CSUM) {
> + err = skb_checksum_help(skb);
> + if (unlikely(err))
> + goto error;
> + } else if (skb->ip_summed != CHECKSUM_PARTIAL)
> skb->ip_summed = CHECKSUM_NONE;
>
> return skb;
> @@ -776,7 +780,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
> int err;
> int pkt_len;
>
> - skb = handle_offloads(skb);
> + skb = handle_offloads(tunnel, skb);
> if (IS_ERR(skb)) {
> dev->stats.tx_dropped++;
> return NETDEV_TX_OK;
> --
> 1.7.1
Tested the series on two different devices
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox