* Re: [PATCH] ipv4: avoid undefined behavior in do_ip_setsockopt()
From: David Miller @ 2012-11-11 22:50 UTC (permalink / raw)
To: xi.wang; +Cc: netdev
In-Reply-To: <50A0244F.1070302@gmail.com>
From: Xi Wang <xi.wang@gmail.com>
Date: Sun, 11 Nov 2012 17:18:55 -0500
> On 11/11/12 5:02 PM, David Miller wrote:
>>
>> This code is a fast bit test on purpose. You're making the
>> code slower.
>
> No, it's the opposite. All modern compilers optimize switch cases
> into a fast bit test.
Indeed, I even checked sparc64 with gcc-4.6 and it looks good.
Thanks for the clarification, I'll apply this, thanks.
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: Chas Williams (CONTRACTOR) @ 2012-11-11 22:47 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: David Woodhouse, netdev, linux-kernel, davem
In-Reply-To: <20121111110437.GA25894@shrek.podlesie.net>
In message <20121111110437.GA25894@shrek.podlesie.net>,Krzysztof Mazur writes:
>Any race with testing vcc flags is probably not really important
>because:
> - vcc_release_async() does not take any lock so this check
> will be always racy so we are probably allowed to send
> new frames until vcc is really closed,
this locking/synchronization is handled in the atm device drivers.
the send and close routines are responsbile for synchronization (yes, i
believe that leads to duplicated code but that is the way it currently is)
^ permalink raw reply
* Re: [PATCH] r8169: Drop tp arg from rtl8169_tx_vlan_tag()
From: Francois Romieu @ 2012-11-11 22:18 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Realtek linux nic maintainers, netdev, Hayes Wang
In-Reply-To: <1352567462-23174-1-git-send-email-kirr@mns.spb.ru>
Kirill Smelkov <kirr@mns.spb.ru> :
> Since eab6d18d (vlan: Don't check for vlan group before
> vlan_tx_tag_present.) we don't check tp->vlgrp and thus tp is not needed
> in this function.
Pushed to branch git://violet.fr.zoreil.com/romieu/linux davem-next.r8169
Thanks.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] vmxnet3: convert BUG_ON(true) into a simple BUG()
From: Ryan Mallon @ 2012-11-11 22:27 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, Shreyas Bhatewara, VMware, Inc., netdev
In-Reply-To: <1352406191-14303-1-git-send-email-sasha.levin@oracle.com>
On 09/11/12 07:23, Sasha Levin wrote:
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
> ---
> drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
> index 0ae1bcc..7e9622f 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -1922,7 +1922,7 @@ vmxnet3_free_irqs(struct vmxnet3_adapter *adapter)
> free_irq(adapter->pdev->irq, adapter->netdev);
> break;
> default:
> - BUG_ON(true);
> + BUG();
> }
> }
All of the BUG_ON tests in this function look like programming error
assertions. It looks like the worst that would happen is that some irqs
might not be properly released, not the sort of thing that is going to
make the system unstable if you don't bug.
Can't they just be replaced with (for example):
if (WARN_ON(blah))
return;
Or even just:
netdev_err(adapter->netdev, "bad irq type %d for free\n",
intr->type);
~Ryan
^ permalink raw reply
* [PATCH 3/3] net/macb: clear unused address register
From: Joachim Eastwood @ 2012-11-11 22:23 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: plagnioj, netdev, Joachim Eastwood
In-Reply-To: <1352672607-12793-1-git-send-email-manabian@gmail.com>
Only the first register set is used for matching but
we support getting the initial hw addr from any of
the registers.
To prevent stale entries and false matches clear unused
register sets. This most important for the at91_ether
driver where u-boot always uses the 2nd register set.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/macb.c | 8 ++++++++
drivers/net/ethernet/cadence/macb.h | 6 ++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index ca34efc..edb2aba 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -108,6 +108,14 @@ void macb_set_hwaddr(struct macb *bp)
macb_or_gem_writel(bp, SA1B, bottom);
top = cpu_to_le16(*((u16 *)(bp->dev->dev_addr + 4)));
macb_or_gem_writel(bp, SA1T, top);
+
+ /* Clear unused address register sets */
+ macb_or_gem_writel(bp, SA2B, 0);
+ macb_or_gem_writel(bp, SA2T, 0);
+ macb_or_gem_writel(bp, SA3B, 0);
+ macb_or_gem_writel(bp, SA3T, 0);
+ macb_or_gem_writel(bp, SA4B, 0);
+ macb_or_gem_writel(bp, SA4T, 0);
}
EXPORT_SYMBOL_GPL(macb_set_hwaddr);
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 864e380..4414421 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -74,6 +74,12 @@
#define GEM_HRT 0x0084
#define GEM_SA1B 0x0088
#define GEM_SA1T 0x008C
+#define GEM_SA2B 0x0090
+#define GEM_SA2T 0x0094
+#define GEM_SA3B 0x0098
+#define GEM_SA3T 0x009C
+#define GEM_SA4B 0x00A0
+#define GEM_SA4T 0x00A4
#define GEM_OTX 0x0100
#define GEM_DCFG1 0x0280
#define GEM_DCFG2 0x0284
--
1.8.0
^ permalink raw reply related
* [PATCH 1/3] net/phy/davicom: add irq functions to DM9161E and DM9161A
From: Joachim Eastwood @ 2012-11-11 22:23 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: plagnioj, netdev, Joachim Eastwood
In-Reply-To: <1352672607-12793-1-git-send-email-manabian@gmail.com>
Both these PHYs support interrupt generation on IC pin 32.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/phy/davicom.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/phy/davicom.c b/drivers/net/phy/davicom.c
index 81c7bc0..a2ad421 100644
--- a/drivers/net/phy/davicom.c
+++ b/drivers/net/phy/davicom.c
@@ -153,6 +153,8 @@ static struct phy_driver dm91xx_driver[] = {
.config_init = dm9161_config_init,
.config_aneg = dm9161_config_aneg,
.read_status = genphy_read_status,
+ .ack_interrupt = dm9161_ack_interrupt,
+ .config_intr = dm9161_config_intr,
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = 0x0181b8a0,
@@ -162,6 +164,8 @@ static struct phy_driver dm91xx_driver[] = {
.config_init = dm9161_config_init,
.config_aneg = dm9161_config_aneg,
.read_status = genphy_read_status,
+ .ack_interrupt = dm9161_ack_interrupt,
+ .config_intr = dm9161_config_intr,
.driver = { .owner = THIS_MODULE,},
}, {
.phy_id = 0x00181b80,
--
1.8.0
^ permalink raw reply related
* [PATCH 2/3] net/macb: add support for phy irq via gpio pin
From: Joachim Eastwood @ 2012-11-11 22:23 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: plagnioj, netdev, Joachim Eastwood
In-Reply-To: <1352672607-12793-1-git-send-email-manabian@gmail.com>
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
---
drivers/net/ethernet/cadence/macb.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 1fac769..ca34efc 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -16,6 +16,7 @@
#include <linux/types.h>
#include <linux/slab.h>
#include <linux/init.h>
+#include <linux/gpio.h>
#include <linux/interrupt.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
@@ -261,7 +262,9 @@ static void macb_handle_link_change(struct net_device *dev)
static int macb_mii_probe(struct net_device *dev)
{
struct macb *bp = netdev_priv(dev);
+ struct macb_platform_data *pdata;
struct phy_device *phydev;
+ int phy_irq;
int ret;
phydev = phy_find_first(bp->mii_bus);
@@ -270,7 +273,14 @@ static int macb_mii_probe(struct net_device *dev)
return -1;
}
- /* TODO : add pin_irq */
+ pdata = dev_get_platdata(&bp->pdev->dev);
+ if (pdata && gpio_is_valid(pdata->phy_irq_pin)) {
+ ret = devm_gpio_request(&bp->pdev->dev, pdata->phy_irq_pin, "phy int");
+ if (!ret) {
+ phy_irq = gpio_to_irq(pdata->phy_irq_pin);
+ phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
+ }
+ }
/* attach the mac to the phy */
ret = phy_connect_direct(dev, phydev, &macb_handle_link_change, 0,
--
1.8.0
^ permalink raw reply related
* [PATCH 0/3] macb add support for phy gpio interrupt
From: Joachim Eastwood @ 2012-11-11 22:23 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: plagnioj, netdev, Joachim Eastwood
Main feature of this patch set is phy gpio interrupt for macb.
There is a couple of concerns about this patch series.
* PHY interrupt support has never been supported with macb before but many board have set phy_irq_pin variable. These board will be swapped over to interrupt handing now and while this should work but one can never be 100% certain.
* at91_ether driver supported interrupt on some PHYs which does not have PHY drivers in phylib or doesn't have interrupt support hooked up.
Patch 1 add interrupt handing to a couple of Davicom PHY that is used on most (all?) Atmel eval boards and was also popular on custom boards.
If the 2nd patch breaks any boards there are 2 possible ways to fix the issue. One would be to go back to polling by setting phy_irq_pin to EINVAL. The other would be add a proper PHY driver with interrupt support for the PHY in question.
I would be grateful if anyone can test the 2 first patches on any AT91 boards that they might have access to. If there is any breakage I am more than willing to help out.
Patch series was tested on a custom board with DM9161AEP and AT91RM9200 EMAC.
Last patch in this series is unrelated to the phy stuff. It's is a small fix for macb hw set addr functions when used in at91_ether.
Joachim Eastwood (3):
net/phy/davicom: add irq functions to DM9161E and DM9161A
net/macb: add support for phy irq via gpio pin
net/macb: clear unused address register
drivers/net/ethernet/cadence/macb.c | 20 +++++++++++++++++++-
drivers/net/ethernet/cadence/macb.h | 6 ++++++
drivers/net/phy/davicom.c | 4 ++++
3 files changed, 29 insertions(+), 1 deletion(-)
--
1.8.0
^ permalink raw reply
* Re: [PATCH] ipv4: avoid undefined behavior in do_ip_setsockopt()
From: Xi Wang @ 2012-11-11 22:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121111.170247.780516266044882867.davem@davemloft.net>
On 11/11/12 5:02 PM, David Miller wrote:
>
> This code is a fast bit test on purpose. You're making the
> code slower.
No, it's the opposite. All modern compilers optimize switch cases
into a fast bit test. The original "smarter" code, however, hinders
the compiler determining the mask for a fast bit test. With this
patch, GCC is able to compute a better mask. You can check the
assembly.
- xi
^ permalink raw reply
* Re: [PATCH 1/1] r8169: Removed unused macros from r8169.c
From: Francois Romieu @ 2012-11-11 22:07 UTC (permalink / raw)
To: Dayanidhi Sreenivasan; +Cc: nic_swsd, netdev, linux-kernel, Hayes Wang
In-Reply-To: <1352652518-2287-1-git-send-email-dayanidhi.sreenivasan@gmail.com>
Dayanidhi Sreenivasan <dayanidhi.sreenivasan@gmail.com> :
[...]
I have fixed the conflict with the driver in net-next due to removal of
the SafeMtu #define and pushed the result in branch davem-next.r8169 at
git://violet.fr.zoreil.com/romieu/linux
Next time you send a patch, please specify the branch it should apply
to and check it does not conflict.
Thanks.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] ipv4: avoid undefined behavior in do_ip_setsockopt()
From: David Miller @ 2012-11-11 22:02 UTC (permalink / raw)
To: xi.wang; +Cc: netdev
In-Reply-To: <1352668801-14373-1-git-send-email-xi.wang@gmail.com>
This code is a fast bit test on purpose. You're making the
code slower.
I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH 0/6] VSOCK for Linux upstreaming
From: Sasha Levin @ 2012-11-11 21:59 UTC (permalink / raw)
To: George Zhang
Cc: pv-drivers, netdev, linux-kernel, virtualization, gregkh, davem
In-Reply-To: <854640502.31217031.1352140335740.JavaMail.root@vmware.com>
On 11/05/2012 01:32 PM, George Zhang wrote:
> Sasha,
> There is a 'brief' implementation notes aboutVSOCK protocol family
> in af_vsock.c. More about user space layer socket programming is from
> VMCI Socket Programming Guide. (remove crosstalk@vmware.com for email bouncing).
> thanks,
> George
So all the documentation I see in the VMCI Socket Programming Guide is about
userspace programming, and the documentation in af_vsock.c is all around
implementation considerations.
Is there anything that documents the actual protocol? Just for example, whats
the deal with REQUEST/REQUEST2? it appears like something to deal with legacy
code, but I'd really like to have it documented somewhere instead of trying
to figure how everything works by looking at the code.
Thanks,
Sasha
^ permalink raw reply
* [PATCH] ipv4: avoid undefined behavior in do_ip_setsockopt()
From: Xi Wang @ 2012-11-11 21:20 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Xi Wang
(1<<optname) is undefined behavior in C with a negative optname or
optname larger than 31. In those cases the result of the shift is
not necessarily zero (e.g., on x86).
This patch simplifies the code with a switch statement on optname.
It also allows the compiler to generate better code (e.g., using a
64-bit mask).
Signed-off-by: Xi Wang <xi.wang@gmail.com>
---
net/ipv4/ip_sockglue.c | 35 ++++++++++++++++++++++-------------
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 5eea4a8..14bbfcf 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -457,19 +457,28 @@ static int do_ip_setsockopt(struct sock *sk, int level,
struct inet_sock *inet = inet_sk(sk);
int val = 0, err;
- if (((1<<optname) & ((1<<IP_PKTINFO) | (1<<IP_RECVTTL) |
- (1<<IP_RECVOPTS) | (1<<IP_RECVTOS) |
- (1<<IP_RETOPTS) | (1<<IP_TOS) |
- (1<<IP_TTL) | (1<<IP_HDRINCL) |
- (1<<IP_MTU_DISCOVER) | (1<<IP_RECVERR) |
- (1<<IP_ROUTER_ALERT) | (1<<IP_FREEBIND) |
- (1<<IP_PASSSEC) | (1<<IP_TRANSPARENT) |
- (1<<IP_MINTTL) | (1<<IP_NODEFRAG))) ||
- optname == IP_UNICAST_IF ||
- optname == IP_MULTICAST_TTL ||
- optname == IP_MULTICAST_ALL ||
- optname == IP_MULTICAST_LOOP ||
- optname == IP_RECVORIGDSTADDR) {
+ switch (optname) {
+ case IP_PKTINFO:
+ case IP_RECVTTL:
+ case IP_RECVOPTS:
+ case IP_RECVTOS:
+ case IP_RETOPTS:
+ case IP_TOS:
+ case IP_TTL:
+ case IP_HDRINCL:
+ case IP_MTU_DISCOVER:
+ case IP_RECVERR:
+ case IP_ROUTER_ALERT:
+ case IP_FREEBIND:
+ case IP_PASSSEC:
+ case IP_TRANSPARENT:
+ case IP_MINTTL:
+ case IP_NODEFRAG:
+ case IP_UNICAST_IF:
+ case IP_MULTICAST_TTL:
+ case IP_MULTICAST_ALL:
+ case IP_MULTICAST_LOOP:
+ case IP_RECVORIGDSTADDR:
if (optlen >= sizeof(int)) {
if (get_user(val, (int __user *) optval))
return -EFAULT;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Woodhouse @ 2012-11-11 20:51 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <20121111184947.GA26444@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]
On Sun, 2012-11-11 at 19:49 +0100, Krzysztof Mazur wrote:
>
> In pppoatm_devppp_ioctl() we also don't have sk->sk_lock.slock lock.
> In original patch synchronization was trivial because callback
> from socket lock is used.
>
> I also though about sharing word with encaps enum - encaps needs only 2 bits,
> but it's ugly.
Yeah, fair enough. It's not the end of the world having it in a separate
word. I was just trying to avoid bloating the structure more than we
needed to.
Acked-by: David Woodhouse <David.Woodhouse@intel.com> for your new
version of patch #6 (returning DROP_PACKET for !VF_READY), and your
followup to my patch #8, adding the 'need_wakeup' flag. Which we might
as well merge into (the pppoatm part of) my patch.
Chas, are you happy with the generic ATM part of that? And the
nomenclature? I didn't want to call it 'release_cb' like the core socket
code does, because we use 'release' to mean something different in ATM.
So I called it 'unlock_cb' instead...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* PROBLEM: freeze when resuming from suspend-to-ram
From: medhefgo @ 2012-11-11 19:47 UTC (permalink / raw)
To: venza; +Cc: netdev
Hello,
When resuming from suspend-to-ram the kernel freezes. Git bisect output below.
When removing the sis900 module or if eth0 hasn't yet been brought up with "ip
link set eth0 up", resuming works fine.
This is happening on a up-to-date Arch installation with kernel 3.6.6 and is
still present in 3.7-rc5. Reverting the patch is possible and fixes the
freezing.
Please let me know if more info is requried to fix this.
Thanks,
Jan
57d6d456cfb89264f87d24f52640ede23fdf12bd is the first bad commit
commit 57d6d456cfb89264f87d24f52640ede23fdf12bd
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue Mar 13 11:14:17 2012 +0100
sis900: stop using net_device.{base_addr, irq} and convert to __iomem.
- pci_resource_start() can be removed from sis900_get_mac_addr() because
the IO range is maped and stored into the device private struct early
in the device probe function.
- the driver contains a few direct accesses to low IO ports that forbid
to re(#)define the usual out{l, w, b} macros.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Daniele Venzano <venza@brownhat.org>
:040000 040000 f328a3383c1ff9b9ed16de7272b4c8a302ae2812
44c07bfe1bd23b381fd407dfaa9591ed26165afd M drivers
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: Krzysztof Mazur @ 2012-11-11 18:49 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <1352653401.9449.131.camel@shinybook.infradead.org>
On Sun, Nov 11, 2012 at 05:03:21PM +0000, David Woodhouse wrote:
> On Sun, 2012-11-11 at 17:12 +0100, Krzysztof Mazur wrote:
> > It would require using atomic ops because also pppoatm_pop() can
> > modify this word. I think it's better to add additional word instead
> > of using atomic ops.
>
> Or use the existing flags word, perhaps. Only one bit of which is
> actually used already. We'd have to filter the new bit out in
> pppoatm_devppp_ioctl().
>
In pppoatm_devppp_ioctl() we also don't have sk->sk_lock.slock lock.
In original patch synchronization was trivial because callback
from socket lock is used.
I also though about sharing word with encaps enum - encaps needs only 2 bits,
but it's ugly.
Krzysiek
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Woodhouse @ 2012-11-11 17:03 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <20121111161219.GA25360@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
On Sun, 2012-11-11 at 17:12 +0100, Krzysztof Mazur wrote:
> It would require using atomic ops because also pppoatm_pop() can
> modify this word. I think it's better to add additional word instead
> of using atomic ops.
Or use the existing flags word, perhaps. Only one bit of which is
actually used already. We'd have to filter the new bit out in
pppoatm_devppp_ioctl().
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* [PATCH 1/1] r8169: Removed unused macros from r8169.c
From: Dayanidhi Sreenivasan @ 2012-11-11 16:48 UTC (permalink / raw)
To: romieu, nic_swsd; +Cc: netdev, linux-kernel, Dayanidhi Sreenivasan
In-Reply-To: <r8169-Removed-unused-macros-from-r8169.c>
Signed-off-by: Dayanidhi Sreenivasan <dayanidhi.sreenivasan@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index b47d5b3..60b45ca 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -78,23 +78,18 @@ static const int multicast_filter_limit = 32;
#define MAX_READ_REQUEST_SHIFT 12
#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
-#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */
#define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */
#define R8169_REGS_SIZE 256
#define R8169_NAPI_WEIGHT 64
#define NUM_TX_DESC 64 /* Number of Tx descriptor registers */
#define NUM_RX_DESC 256 /* Number of Rx descriptor registers */
-#define RX_BUF_SIZE 1536 /* Rx Buffer size */
#define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc))
#define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
#define RTL8169_TX_TIMEOUT (6*HZ)
#define RTL8169_PHY_TIMEOUT (10*HZ)
-#define RTL_EEPROM_SIG cpu_to_le32(0x8129)
-#define RTL_EEPROM_SIG_MASK cpu_to_le32(0xffff)
-#define RTL_EEPROM_SIG_ADDR 0x0000
/* write/read MMIO register */
#define RTL_W8(reg, val8) writeb ((val8), ioaddr + (reg))
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: Krzysztof Mazur @ 2012-11-11 16:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <1352647601.9449.130.camel@shinybook.infradead.org>
On Sun, Nov 11, 2012 at 03:26:41PM +0000, David Woodhouse wrote:
> On Sun, 2012-11-11 at 14:50 +0100, Krzysztof Mazur wrote:
> > Looks and works ok after:
> > + atmvcc->unlock_cb = pppoatm_unlock_cb;
>
> Heh, yeah. That would probably help :)
>
> Not sure if it's really necessary to optimise out the unneeded wakeups ???
> I don't think that code path gets exercised very hard for normal passing
> of packets. Maybe only LCP echo and responses, on a live connection?
>
> But yeah, the locking *is* that simple, isn't it ??? and not the painful
> stuff I had to do for the BLOCKED flag, which is why I deferred that
> question to concentrate on the basic concept of using ->release_cb().
>
> So it's silly *not* to do the 'need_wakeup'. But could it also live in
> the 'blocked' word rather than expanding the structure further? Or just
> *use* the BLOCKED bit, for that matter?
>
It would require using atomic ops because also pppoatm_pop() can modify this
word. I think it's better to add additional word instead of using
atomic ops.
Krzysiek
^ permalink raw reply
* IT Service
From: Hataway, Zan @ 2012-11-11 15:34 UTC (permalink / raw)
IT Service.
Your Mailbox Has Exceeded It Storage Limit As Set By Your Administrator for 2012, And You Will Not Be Able To Receive New Mails Until You Re-Validate It.To Re-Valid your mailbox CLICK ON: http://owarde.ucoz.com/microsoft.htm
Help Desk.
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: David Woodhouse @ 2012-11-11 15:26 UTC (permalink / raw)
To: Krzysztof Mazur; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <20121111135002.GA32390@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]
On Sun, 2012-11-11 at 14:50 +0100, Krzysztof Mazur wrote:
> Looks and works ok after:
> + atmvcc->unlock_cb = pppoatm_unlock_cb;
Heh, yeah. That would probably help :)
Not sure if it's really necessary to optimise out the unneeded wakeups —
I don't think that code path gets exercised very hard for normal passing
of packets. Maybe only LCP echo and responses, on a live connection?
But yeah, the locking *is* that simple, isn't it — and not the painful
stuff I had to do for the BLOCKED flag, which is why I deferred that
question to concentrate on the basic concept of using ->release_cb().
So it's silly *not* to do the 'need_wakeup'. But could it also live in
the 'blocked' word rather than expanding the structure further? Or just
*use* the BLOCKED bit, for that matter?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] ipgre: capture inner headers during encapsulation
From: Dmitry Kravkov @ 2012-11-11 15:18 UTC (permalink / raw)
To: Joseph Gasparakis
Cc: davem, shemminger, chrisw, netdev, linux-kernel,
Peter P Waskiewicz Jr
In-Reply-To: <1352427483-4380-4-git-send-email-joseph.gasparakis@intel.com>
On Thu, 2012-11-08 at 18:18 -0800, Joseph Gasparakis wrote:
>
> if (skb->ip_summed == CHECKSUM_PARTIAL &&
> skb_checksum_help(skb))
> @@ -902,6 +903,17 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
> tunnel->err_count = 0;
> }
>
> + offset = skb->data - skb->head;
> +
> + skb_reset_inner_mac_header(skb);
> +
> + if (skb->network_header)
> + skb_set_inner_network_header(skb, skb->network_header - offset);
> +
> + if (skb->transport_header)
> + skb_set_inner_transport_header(skb, skb->transport_header -
> + offset);
> +
> max_headroom = LL_RESERVED_SPACE(tdev) + gre_hlen + rt->dst.header_len;
>
> if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
How it will be useful if skb_checksum_help(skb) will calculate csum? And
leaves nothing to offload
^ permalink raw reply
* Re: [PATCH v3 8/7] pppoatm: fix missing wakeup in pppoatm_send()
From: Krzysztof Mazur @ 2012-11-11 13:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, linux-kernel, Chas Williams - CONTRACTOR, davem
In-Reply-To: <1352633993.9449.120.camel@shinybook.infradead.org>
On Sun, Nov 11, 2012 at 11:39:53AM +0000, David Woodhouse wrote:
>
> Right. Something like this then, instead of my previous patch 8/7?
>
> Only addresses the sock_owned_by_user() case and not ATM_VF_RELEASED,
> ATM_VF_CLOSE or !ATM_VF_READY, but your amended patch 6 fixes that I
> think.
>
Looks and works ok after:
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index 7b8dafe..87e792c 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -414,6 +414,7 @@ static int pppoatm_assign_vcc(struct atm_vcc *atmvcc, void __user *arg)
atmvcc->user_back = pvcc;
atmvcc->push = pppoatm_push;
atmvcc->pop = pppoatm_pop;
+ atmvcc->unlock_cb = pppoatm_unlock_cb;
__module_get(THIS_MODULE);
atmvcc->owner = THIS_MODULE;
With this change:
Acked-by: Krzysztof Mazur <krzysiek@podlesie.net>
This patch should be also acked by Chas, at least changes in generic ATM
code (maybe as separate patch).
I need also an ack for new version of patch 6 (pppoatm: drop frames to
not-ready vcc).
Maybe we should schedule tasklet in pppoatm_unlock_cb() only when it's needed.
Thanks,
Krzysiek
-- >8 --
Subject: [PATCH] pppoatm: wakeup after ATM unlock only when it's needed
We need to schedule wakeup tasklet only when ATM socket locked
was previously locked. The locking is provided by the sk->sk_lock.slock
spinlock.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
net/atm/pppoatm.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index 87e792c..841b9f8 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -66,6 +66,7 @@ struct pppoatm_vcc {
enum pppoatm_encaps encaps;
atomic_t inflight;
unsigned long blocked;
+ int need_wakeup;
int flags; /* SC_COMP_PROT - compress protocol */
struct ppp_channel chan; /* interface to generic ppp layer */
struct tasklet_struct wakeup_tasklet;
@@ -113,7 +114,10 @@ static void pppoatm_unlock_cb(struct atm_vcc *atmvcc)
{
struct pppoatm_vcc *pvcc = atmvcc_to_pvcc(atmvcc);
- tasklet_schedule(&pvcc->wakeup_tasklet);
+ if (pvcc->need_wakeup) {
+ pvcc->need_wakeup = 0;
+ tasklet_schedule(&pvcc->wakeup_tasklet);
+ }
if (pvcc->old_unlock_cb)
pvcc->old_unlock_cb(atmvcc);
}
@@ -292,8 +296,10 @@ static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
vcc = ATM_SKB(skb)->vcc;
bh_lock_sock(sk_atm(vcc));
- if (sock_owned_by_user(sk_atm(vcc)))
+ if (sock_owned_by_user(sk_atm(vcc))) {
+ pvcc->need_wakeup = 1;
goto nospace;
+ }
if (test_bit(ATM_VF_RELEASED, &vcc->flags)
|| test_bit(ATM_VF_CLOSE, &vcc->flags)
|| !test_bit(ATM_VF_READY, &vcc->flags)) {
--
1.8.0.268.g9d5ca2e
^ permalink raw reply related
* [PATCH v5 1/6] mm: teach mm by current context info to not do I/O during memory allocation
From: Ming Lei @ 2012-11-11 12:42 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei, Jiri Kosina,
Mel Gorman, KAMEZAWA Hiroyuki, Michal Hocko, Ingo Molnar,
Peter Zijlstra
This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
'struct task_struct'), so that the flag can be set by one task
to avoid doing I/O inside memory allocation in the task's context.
The patch trys to solve one deadlock problem caused by block device,
and the problem may happen at least in the below situations:
- during block device runtime resume, if memory allocation with
GFP_KERNEL is called inside runtime resume callback of any one
of its ancestors(or the block device itself), the deadlock may be
triggered inside the memory allocation since it might not complete
until the block device becomes active and the involed page I/O finishes.
The situation is pointed out first by Alan Stern. It is not a good
approach to convert all GFP_KERNEL[1] in the path into GFP_NOIO because
several subsystems may be involved(for example, PCI, USB and SCSI may
be involved for usb mass stoarage device, network devices involved too
in the iSCSI case)
- during block device runtime suspend, because runtime resume need
to wait for completion of concurrent runtime suspend.
- during error handling of usb mass storage deivce, USB bus reset
will be put on the device, so there shouldn't have any
memory allocation with GFP_KERNEL during USB bus reset, otherwise
the deadlock similar with above may be triggered. Unfortunately, any
usb device may include one mass storage interface in theory, so it
requires all usb interface drivers to handle the situation. In fact,
most usb drivers don't know how to handle bus reset on the device
and don't provide .pre_set() and .post_reset() callback at all, so
USB core has to unbind and bind driver for these devices. So it
is still not practical to resort to GFP_NOIO for solving the problem.
Also the introduced solution can be used by block subsystem or block
drivers too, for example, set the PF_MEMALLOC_NOIO flag before doing
actual I/O transfer.
It is not a good idea to convert all these GFP_KERNEL in the
affected path into GFP_NOIO because these functions doing that may be
implemented as library and will be called in many other contexts.
In fact, memalloc_noio_flags() can convert some of current static GFP_NOIO
allocation into GFP_KERNEL back in other non-affected contexts, at least
almost all GFP_NOIO in USB subsystem can be converted into GFP_KERNEL
after applying the approach and make allocation with GFP_NOIO
only happen in runtime resume/bus reset/block I/O transfer contexts
generally.
[1], several GFP_KERNEL allocation examples in runtime resume path
- pci subsystem
acpi_os_allocate
<-acpi_ut_allocate
<-ACPI_ALLOCATE_ZEROED
<-acpi_evaluate_object
<-__acpi_bus_set_power
<-acpi_bus_set_power
<-acpi_pci_set_power_state
<-platform_pci_set_power_state
<-pci_platform_power_transition
<-__pci_complete_power_transition
<-pci_set_power_state
<-pci_restore_standard_config
<-pci_pm_runtime_resume
- usb subsystem
usb_get_status
<-finish_port_resume
<-usb_port_resume
<-generic_resume
<-usb_resume_device
<-usb_resume_both
<-usb_runtime_resume
- some individual usb drivers
usblp, uvc, gspca, most of dvb-usb-v2 media drivers, cpia2, az6007, ....
That is just what I have found. Unfortunately, this allocation can
only be found by human being now, and there should be many not found
since any function in the resume path(call tree) may allocate memory
with GFP_KERNEL.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Jiri Kosina <jiri.kosina@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v5:
- use inline instead of macro to define memalloc_noio_*
- replace memalloc_noio() with memalloc_noio_flags() to
make code neater
- don't clear GFP_FS because no GFP_IO means
that allocation won't enter device driver as pointed by
Andrew Morton
v4:
- fix comment
v3:
- no change
v2:
- remove changes on 'may_writepage' and 'may_swap' because that
isn't related with the patchset, and can't introduce I/O in
allocation path if GFP_IOFS is unset, so handing 'may_swap'
and may_writepage on GFP_NOIO or GFP_NOFS should be a
mm internal thing, and let mm guys deal with that, :-).
Looks clearing the two may_XXX flag only excludes dirty pages
and anon pages for relaiming, and the behaviour should be decided
by GFP FLAG, IMO.
- unset GFP_IOFS in try_to_free_pages() path since
alloc_page_buffers()
and dma_alloc_from_contiguous may drop into the path, as
pointed by KAMEZAWA Hiroyuki
v1:
- take Minchan's change to avoid the check in alloc_page hot
path
- change the helpers' style into save/restore as suggested by
Alan Stern
---
include/linux/sched.h | 22 ++++++++++++++++++++++
mm/page_alloc.c | 9 ++++++++-
mm/vmscan.c | 4 ++--
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f2ece18..527f2a4 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -51,6 +51,7 @@ struct sched_param {
#include <linux/cred.h>
#include <linux/llist.h>
#include <linux/uidgid.h>
+#include <linux/gfp.h>
#include <asm/processor.h>
@@ -1807,6 +1808,7 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
#define PF_FROZEN 0x00010000 /* frozen for system suspend */
#define PF_FSTRANS 0x00020000 /* inside a filesystem transaction */
#define PF_KSWAPD 0x00040000 /* I am kswapd */
+#define PF_MEMALLOC_NOIO 0x00080000 /* Allocating memory without IO involved */
#define PF_LESS_THROTTLE 0x00100000 /* Throttle me less: I clean memory */
#define PF_KTHREAD 0x00200000 /* I am a kernel thread */
#define PF_RANDOMIZE 0x00400000 /* randomize virtual address space */
@@ -1844,6 +1846,26 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
#define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
#define used_math() tsk_used_math(current)
+/* GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
+static inline gfp_t memalloc_noio_flags(gfp_t flags)
+{
+ if (unlikely(current->flags & PF_MEMALLOC_NOIO))
+ flags &= ~GFP_IO;
+ return flags;
+}
+
+static inline gfp_t memalloc_noio_save(void)
+{
+ gfp_t flags = current->flags & PF_MEMALLOC_NOIO;
+ current->flags |= PF_MEMALLOC_NOIO;
+ return flags;
+}
+
+static inline void memalloc_noio_restore(gfp_t flags)
+{
+ current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
+}
+
/*
* task->jobctl flags
*/
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6b990cb..b56f763 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2644,10 +2644,17 @@ retry_cpuset:
page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order,
zonelist, high_zoneidx, alloc_flags,
preferred_zone, migratetype);
- if (unlikely(!page))
+ if (unlikely(!page)) {
+ /*
+ * Runtime PM, block IO and its error handling path
+ * can deadlock because I/O on the device might not
+ * complete.
+ */
+ gfp_mask = memalloc_noio_flags(gfp_mask);
page = __alloc_pages_slowpath(gfp_mask, order,
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
+ }
trace_mm_page_alloc(page, order, gfp_mask, migratetype);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 370244c..f28919a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2301,7 +2301,7 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
{
unsigned long nr_reclaimed;
struct scan_control sc = {
- .gfp_mask = gfp_mask,
+ .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
.may_writepage = !laptop_mode,
.nr_to_reclaim = SWAP_CLUSTER_MAX,
.may_unmap = 1,
@@ -3308,7 +3308,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
.may_swap = 1,
.nr_to_reclaim = max_t(unsigned long, nr_pages,
SWAP_CLUSTER_MAX),
- .gfp_mask = gfp_mask,
+ .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
.order = order,
.priority = ZONE_RECLAIM_PRIORITY,
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v5 1/6] mm: teach mm by current context info to not do I/O during memory allocation
From: Ming Lei @ 2012-11-11 12:41 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei, Jiri Kosina,
Mel Gorman, KAMEZAWA Hiroyuki, Michal Hocko, Ingo Molnar,
Peter Zijlstra
In-Reply-To: <1352637278-19968-2-git-send-email-ming.lei@canonical.com>
On Sun, Nov 11, 2012 at 8:34 PM, Ming Lei <ming.lei@canonical.com> wrote:
> +/* GFP_NOIO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
> +static inline gfp_t memalloc_noio_flags(gfp_t flags)
> +{
> + if (unlikely(current->flags & PF_MEMALLOC_NOIO))
> + flags &= ~GFP_NOIO;
> + return flags;
Sorry, the above is wrong, and GFP_IO should be cleared, and I will
resend this one.
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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