* Re: [PATCH v2] Add MSG_WAITFORONE flag to recvmmsg
From: David Miller @ 2010-03-27 15:29 UTC (permalink / raw)
To: acme; +Cc: blblack, netdev, drepper, linux-kernel
In-Reply-To: <20100327140717.GN3625@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Sat, 27 Mar 2010 11:07:17 -0300
> Em Fri, Mar 26, 2010 at 08:54:28PM -0700, David Miller escreveu:
>> From: Brandon L Black <blblack@gmail.com>
>> Date: Fri, 26 Mar 2010 21:18:03 -0500
>>
>> >
>> > From: Brandon L Black <blblack@gmail.com>
>> >
>> > Add new flag MSG_WAITFORONE for the recvmmsg() syscall.
>> > When this flag is specified for a blocking socket, recvmmsg()
>> > will only block until at least 1 packet is available. The
>> > default behavior is to block until all vlen packets are
>> > available. This flag has no effect on non-blocking sockets
>> > or when used in combination with MSG_DONTWAIT.
>> >
>> > Signed-off-by: Brandon L Black <blblack@gmail.com>
>>
>> Arnaldo, please review this, thanks.
>
> I'm ok with it.
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] benet: Fix compile warnnings in drivers/net/benet/be_ethtool.c
From: David Miller @ 2010-03-27 15:32 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: wzt.wzt, linux-kernel, netdev, linux-drivers, sathyap
In-Reply-To: <20100326171616.GA20879@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Fri, 26 Mar 2010 22:46:18 +0530
> On 26/03/10 14:12 +0800, wzt.wzt@gmail.com wrote:
>> Fix the following warnings:
>>
>> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>>
>> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
>
> I would suggest using be2net instead of benet during the commit.
> be2net: Fix compile warnnings in drivers/net/benet/be_ethtool.c
>
> Acked-by: Ajit Khaparde <ajitk@serverengines.com>
Well, you cannot be surprised that people will use "benet"
since that is the name of the directory the driver lives
under. It is not even referred to as "be2net" in the
MAINTAINERS entry.
I'm applying this fix as-is.
^ permalink raw reply
* Re: [net-2.6 PATCH] igb: use correct bits to identify if managability is enabled
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100326031506.10368.40559.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:15:06 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> igb was previously checking the wrong bits in the MANC register to determine
> if managability was enabled. As a result it was incorrectly powering down and
> resetting the phy when it didn't need to.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: Do not run all Diagnostic offline tests when VFs are active
From: David Miller @ 2010-03-27 15:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, gregory.v.rose
In-Reply-To: <20100326030647.10085.16720.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 25 Mar 2010 20:06:48 -0700
> From: Greg Rose <gregory.v.rose@intel.com>
>
> When running the offline diagnostic tests check to see if any VFs are
> online. If so then only run the link test. This is necessary because
> the VFs running in guest VMs aren't aware of when the PF is taken
> offline for a diagnostic test. Also put a message to the system log
> telling the system administrator to take the VFs offline manually if
> (s)he wants to run a full diagnostic. Return 1 on each of the tests
> not run to alert the user of the condition.
>
> Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4BACECA6.2050506@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 26 Mar 2010 18:19:34 +0100
> When a multicast packet arrived in ip6_mr_input(), if there is no
> cache ip6mr_cache_unresolved() will be called and this function will
> add an entry with parent == 65535.
>
> And the second problem is that when a vif is removed, no cleanup is
> made in cache entry. Hence, we can have a cache entry which points to
> an invalid vif (dev is set ot NULL).
I've applied your fix, thanks Nicolas.
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000: do not modify tx_queue_len on link speed change
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, franco, emil.s.tantilov, jesse.brandeburg
In-Reply-To: <20100326212557.18793.62063.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 26 Mar 2010 14:25:58 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Previously the driver tweaked txqueuelen to avoid false Tx hang reports
> seen at half duplex. This had the effect of overriding user set values
> on link change/reset. Testing shows that adjusting only the timeout
> factor is sufficient to prevent Tx hang reports at half duplex.
>
> This patch removes all instances of tx_queue_len in the driver.
>
> Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>
>
> CC: Franco Fichtner <franco@lastsummer.de>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/9] drivers/net: Fix continuation lines
From: David Miller @ 2010-03-27 15:34 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, jcliburn, chris.snook, jie.yang, atl1-devel, netdev
In-Reply-To: <6b7a0c43891d5af5796b681898d901bbf2e1cda1.1269655208.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 26 Mar 2010 19:27:55 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Martin Sustrik @ 2010-03-27 16:54 UTC (permalink / raw)
To: Andi Kleen; +Cc: Christoph Lameter, David Miller, netdev, linux-kernel
In-Reply-To: <20100327131138.GD20695@one.firstfloor.org>
Andi Kleen wrote:
> I did a quick read and the manpage/interface seem reasonable to me.
You may also have a look at original PGM implementation by Luigi Rizzo
(FreeBSD). It's not maintained, but it might give you broader view.
http://info.iet.unipi.it/~luigi/pgm-code/
Martin
^ permalink raw reply
* Re: CVE-2009-4537
From: David Miller @ 2010-03-27 17:36 UTC (permalink / raw)
To: michael.s.gilbert; +Cc: linux-kernel, netdev, nhorman
In-Reply-To: <20100327.103407.260084965.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 27 Mar 2010 10:34:07 -0700 (PDT)
> From: Michael Gilbert <michael.s.gilbert@gmail.com>
> Date: Sat, 27 Mar 2010 14:21:00 -0400
>
>> Hi,
>>
>> CVE-2009-4537 has been disclosed without any upstream activity for a
>> while now. Discussion about the issue dried up in January [0], and a
>> patch had been proposed [1], but no arguments were seen either for or
>> against it. Note that redhat has already shipped that in their various
>> kernel security updates. Would it make sense to merge those changes
>> officially?
>
> A different version of the fix went into the tree.
Ignore me, that was a fix for a different problem.
I was waiting for Francois to come up with a cleaner fix
but he stopped working on it, so yes I should put in
the fix you mention or something similar.
Neil, can you formally submit a version of the r8169
CVE for upstream?
Thanks.
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: Robert Hancock @ 2010-03-27 17:46 UTC (permalink / raw)
To: � Engel; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <20100327063838.GB11959@Dublin.logfs.org>
On 03/27/2010 12:38 AM, � Engel wrote:
> On Fri, 26 March 2010 19:55:44 -0600, Robert Hancock wrote:
>>
>> Well, that one's 36 bits, but it's unclear whether that driver would
>> actually be likely to access anything over 4GB. It's possible that
>> there's just some general problem with 64-bit DMA on that machine.
>
> That may very well be. I've had trouble using a PCIe card in that
> machine as well. "Solution" was to buy a different computer. Sad, I
> know, but not my money.
Hm, do you recall/have the details of what happened with the other card?
It's possible this is some general problem with that machine/motherboard
and not actually an issue with what the driver is doing. What kind of
board is that?
>
>> The fact that even stuff like lspci and MII is breaking seems odd,
>> though. It could be that model of card doesn't like the PCIDAC register
>> bit being set (maybe it means something different on that model, or
>> something).
>>
>> I suppose a publicly accessible datasheet for these chips is too much to
>> hope for?
>
> Which chips?
>
> J�rn
> --
> 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
* Re: r8169 mac reading/writing broken
From: Timo Teräs @ 2010-03-27 20:37 UTC (permalink / raw)
To: François Romieu; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BADFAE4.5040906@iki.fi>
Timo Teräs wrote:
> François Romieu wrote:
>> Timo Teräs <timo.teras@iki.fi> :
>> [...]
>>> It seems that adding single printk between writing MAC0 and MAC4
>>> fixes it.
>>> I guess it needs a bit of delay between the writes or something.
>>
>> Can you test with a single RTL_R32 after each MACx write ?
>
> Adding reading back of the written value fixes it too. Though,
> disassembly says that it added an extra instructions also (needs to
> load the 'high' from stack before writing it) so the added delay is
> probably slightly more than just the io read.
I'm not too familiar with PCI details, but this smells a bit
like that write-combining is happening and the NIC does not like
that.
Any ideas how to check this?
The system experiencing this is a "VIA Eden 1.2Ghz" box.
Or is swapping MAC0/MAC4 writes, or adding the extra read an
acceptable fix/workaround?
- Timo
^ permalink raw reply
* [PATCH kernel 2.6.34-rc2] pcnet_cs: add new id
From: Ken Kawasaki @ 2010-03-27 20:55 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100228083420.9ca8e285.ken_kawasaki@spring.nifty.jp>
pcnet_cs:
*add new id (Allied Telesis LM33-PCM-T Lan&Modem multifunction card)
*use PROD_ID for LA-PCM.(because LA-PCM and LM33-PCM-T use the same MANF_ID).
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.34-rc2/drivers/net/pcmcia/pcnet_cs.c.orig 2010-03-21 20:39:59.000000000 +0900
+++ linux-2.6.34-rc2/drivers/net/pcmcia/pcnet_cs.c 2010-03-27 14:42:34.000000000 +0900
@@ -1549,6 +1549,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_PFC_DEVICE_MANF_CARD(0, 0x021b, 0x0101),
PCMCIA_PFC_DEVICE_MANF_CARD(0, 0x08a1, 0xc0ab),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "AnyCom", "Fast Ethernet + 56K COMBO", 0x578ba6e7, 0xb0ac62c4),
+ PCMCIA_PFC_DEVICE_PROD_ID12(0, "ATKK", "LM33-PCM-T", 0xba9eb7e2, 0x077c174e),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "D-Link", "DME336T", 0x1a424a1c, 0xb23897ff),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "Grey Cell", "GCS3000", 0x2a151fac, 0x48b932ae),
PCMCIA_PFC_DEVICE_PROD_ID12(0, "Linksys", "EtherFast 10&100 + 56K PC Card (PCMLM56)", 0x0733cc81, 0xb3765033),
@@ -1740,7 +1741,7 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_MFC_DEVICE_CIS_PROD_ID12(0, "DAYNA COMMUNICATIONS", "LAN AND MODEM MULTIFUNCTION", 0x8fdf8f89, 0xdd5ed9e8, "cis/DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID4(0, "NSC MF LAN/Modem", 0x58fc6056, "cis/DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(0, 0x0175, 0x0000, "cis/DP83903.cis"),
- PCMCIA_DEVICE_CIS_MANF_CARD(0xc00f, 0x0002, "cis/LA-PCM.cis"),
+ PCMCIA_DEVICE_CIS_PROD_ID12("Allied Telesis,K.K", "Ethernet LAN Card", 0x2ad62f3c, 0x9fd2f0a2, "cis/LA-PCM.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("KTI", "PE520 PLUS", 0xad180345, 0x9d58d392, "cis/PE520.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("NDC", "Ethernet", 0x01c43ae1, 0x00b2e941, "cis/NE2K.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("PMX ", "PE-200", 0x34f3f1c8, 0x10b59f8c, "cis/PE-200.cis"),
--- linux-2.6.34-rc2/drivers/serial/serial_cs.c.orig 2010-03-22 06:53:31.000000000 +0900
+++ linux-2.6.34-rc2/drivers/serial/serial_cs.c 2010-03-27 14:42:53.000000000 +0900
@@ -745,6 +745,7 @@ static struct pcmcia_device_id serial_id
PCMCIA_PFC_DEVICE_PROD_ID13(1, "Xircom", "REM10", 0x2e3ee845, 0x76df1d29),
PCMCIA_PFC_DEVICE_PROD_ID13(1, "Xircom", "XEM5600", 0x2e3ee845, 0xf1403719),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "AnyCom", "Fast Ethernet + 56K COMBO", 0x578ba6e7, 0xb0ac62c4),
+ PCMCIA_PFC_DEVICE_PROD_ID12(1, "ATKK", "LM33-PCM-T", 0xba9eb7e2, 0x077c174e),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "D-Link", "DME336T", 0x1a424a1c, 0xb23897ff),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "Gateway 2000", "XJEM3336", 0xdd9989be, 0x662c394c),
PCMCIA_PFC_DEVICE_PROD_ID12(1, "Grey Cell", "GCS3000", 0x2a151fac, 0x48b932ae),
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: François Romieu @ 2010-03-27 21:11 UTC (permalink / raw)
To: Timo Teräs; +Cc: Ivan Vecera, netdev
In-Reply-To: <4BAE6C92.2060801@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
[...]
> Any ideas how to check this?
Check the datasheet of VIA's chipset for a WC control bit - there
ought to be one - and disable it.
> Or is swapping MAC0/MAC4 writes, or adding the extra read an
> acceptable fix/workaround?
swapping should reliably disable WC. It would be fine.
--
Ueimor
^ permalink raw reply
* Re: [Regression] r8169: enable 64-bit DMA by default for PCI Express devices (v2)
From: J�rn Engel @ 2010-03-27 22:00 UTC (permalink / raw)
To: Robert Hancock; +Cc: David Miller, torvalds, linux-kernel, netdev, romieu
In-Reply-To: <4BAE4464.9060909@gmail.com>
On Sat, 27 March 2010 11:46:12 -0600, Robert Hancock wrote:
>
> Hm, do you recall/have the details of what happened with the other card?
It lost interrupts. I had a testcase that should have received three
interrupts and only two were received by the driver. 100%
reproducable. Card used MSI-Interrupts (no MSI-X) and worked
reasonably well otherwise. But it is a prototype, so the card is just
as likely to be the cause as the motherboard.
> It's possible this is some general problem with that machine/motherboard
> and not actually an issue with what the driver is doing. What kind of
> board is that?
Possible, yes. But I wouldn't know how to prove it.
Asrock G31M-S with Intel E5200.
J�rn
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: Ben Hutchings @ 2010-03-27 23:20 UTC (permalink / raw)
To: François Romieu; +Cc: Timo Teräs, Ivan Vecera, netdev
In-Reply-To: <20100327211133.GA3624@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
On Sat, 2010-03-27 at 22:11 +0100, François Romieu wrote:
> Timo Teräs <timo.teras@iki.fi> :
> [...]
> > Any ideas how to check this?
>
> Check the datasheet of VIA's chipset for a WC control bit - there
> ought to be one - and disable it.
>
> > Or is swapping MAC0/MAC4 writes, or adding the extra read an
> > acceptable fix/workaround?
>
> swapping should reliably disable WC. It would be fine.
This bug was also reported by a Debian user in
<http://bugs.debian.org/573007>, also using a VIA chipset.
This sort of behaviour has been seen before with 64-bit registers
written in two 32-bit chunks, on some ARM platforms. You worked around
that for the descriptor pointers with:
ommit b39fe41f481d20c201012e4483e76c203802dda7
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon Sep 11 20:10:58 2006 +0200
r8169: quirk for the 8110sb on arm platform
A similar problem seems to afflict the multicast hash register on this
platform - see <http://bugs.debian.org/407217>, and sorry I didn't
report this earlier when I got confirmation of my hypothesis.
I wonder whether there are special rules that need to be followed for
updating such registers and which the driver is not following, or a more
general bug in the Realtek chips that should be consistently
worked-around for all 64-bit registers.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: r8169 mac reading/writing broken
From: David Miller @ 2010-03-27 23:30 UTC (permalink / raw)
To: ben; +Cc: romieu, timo.teras, ivecera, netdev
In-Reply-To: <1269732054.8653.155.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 27 Mar 2010 23:20:54 +0000
> I wonder whether there are special rules that need to be followed
> for updating such registers and which the driver is not following,
> or a more general bug in the Realtek chips that should be
> consistently worked-around for all 64-bit registers.
I suspect that MMIO to 64-bit registers in 32-bit chunks is not
reliable with these parts, given all of the information we have so
far.
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: David Miller @ 2010-03-27 23:37 UTC (permalink / raw)
To: jengelh; +Cc: schwab, tony.luck, netdev
In-Reply-To: <alpine.LSU.2.01.1003271313230.2740@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Sat, 27 Mar 2010 13:14:46 +0100 (CET)
> net: fix unaligned access in IFLA_STATS64
Applied to net-next-2.6, thanks Jan.
Hey, don't we need some adjustments to if_nlmsg_size()? I don't see
it accounting for IFLA_STATS64/"struct rtnl_link_stats64" there.
^ permalink raw reply
* Re: bonding: fix broken multicast with round-robin mode
From: David Miller @ 2010-03-27 23:40 UTC (permalink / raw)
To: andy; +Cc: netdev
Applied, thanks Andy.
^ permalink raw reply
* Re: [PATCH kernel 2.6.34-rc2] pcnet_cs: add new id
From: David Miller @ 2010-03-27 23:56 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20100328055537.13ef6c01.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 28 Mar 2010 05:55:37 +0900
>
> pcnet_cs:
> *add new id (Allied Telesis LM33-PCM-T Lan&Modem multifunction card)
> *use PROD_ID for LA-PCM.(because LA-PCM and LM33-PCM-T use the same MANF_ID).
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thanks Ken.
^ permalink raw reply
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: Jan Engelhardt @ 2010-03-28 0:11 UTC (permalink / raw)
To: David Miller; +Cc: schwab, tony.luck, netdev
In-Reply-To: <20100327.163730.179928738.davem@davemloft.net>
On Sunday 2010-03-28 00:37, David Miller wrote:
>
>> net: fix unaligned access in IFLA_STATS64
>
>Applied to net-next-2.6, thanks Jan.
>
>Hey, don't we need some adjustments to if_nlmsg_size()? I don't see
>it accounting for IFLA_STATS64/"struct rtnl_link_stats64" there.
If I am not mistaken, the answer is "not strictly". But of course it's
nicer if we don't need to realloc just because we were too conservative
in the initial calculation.
git://dev.medozas.de/linux net
parent c5c57d7c7837858aa499610a3ee760b39f1de937 (v2.6.34-rc1-1276-gc5c57d7)
commit 305876b7c1c720db30239d08d56b3a058d56aa21
Author: Jan Engelhardt <jengelh@medozas.de>
Date: Sun Mar 28 01:03:32 2010 +0100
net: increase preallocated size of nlmsg to accomodate for IFLA_STATS64
When more data is stuffed into an nlmsg than initially projected, an
extra allocation needs to be done. Reserve enough for IFLA_STATS64 so
that this does not to needlessy happen.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
net/core/rtnetlink.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ed0766f..bf919b6 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -653,6 +653,7 @@ static inline size_t if_nlmsg_size(const struct net_device *dev)
+ nla_total_size(IFNAMSIZ) /* IFLA_QDISC */
+ nla_total_size(sizeof(struct rtnl_link_ifmap))
+ nla_total_size(sizeof(struct rtnl_link_stats))
+ + nla_total_size(sizeof(struct rtnl_link_stats64))
+ nla_total_size(MAX_ADDR_LEN) /* IFLA_ADDRESS */
+ nla_total_size(MAX_ADDR_LEN) /* IFLA_BROADCAST */
+ nla_total_size(4) /* IFLA_TXQLEN */
--
# Created with git-export-patch
^ permalink raw reply related
* Re: Seeing new kernel unaligned access messages in linux-next on ia64
From: David Miller @ 2010-03-28 0:17 UTC (permalink / raw)
To: jengelh; +Cc: schwab, tony.luck, netdev
In-Reply-To: <alpine.LSU.2.01.1003280107420.14977@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Sun, 28 Mar 2010 01:11:13 +0100 (CET)
> On Sunday 2010-03-28 00:37, David Miller wrote:
>>
>>> net: fix unaligned access in IFLA_STATS64
>>
>>Applied to net-next-2.6, thanks Jan.
>>
>>Hey, don't we need some adjustments to if_nlmsg_size()? I don't see
>>it accounting for IFLA_STATS64/"struct rtnl_link_stats64" there.
>
> If I am not mistaken, the answer is "not strictly". But of course it's
> nicer if we don't need to realloc just because we were too conservative
> in the initial calculation.
Right.
> net: increase preallocated size of nlmsg to accomodate for IFLA_STATS64
>
> When more data is stuffed into an nlmsg than initially projected, an
> extra allocation needs to be done. Reserve enough for IFLA_STATS64 so
> that this does not to needlessy happen.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Applied, thanks a lot!
^ permalink raw reply
* [PATCH] r8169: fix broken register writes
From: François Romieu @ 2010-03-28 0:31 UTC (permalink / raw)
To: David Miller; +Cc: ben, timo.teras, ivecera, netdev
In-Reply-To: <20100327.163005.28815553.davem@davemloft.net>
This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7
though said registers are not even documented as 64-bit registers
- as opposed to the initial TxDescStartAddress ones - but as single
bytes which must be combined into 32 bits at the MMIO read/write
level before being merged into a 64 bit logical entity.
Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR
registers (aka "multicast is broken for ages on ARM) and to
Timo Teräs <timo.teras@iki.fi> for the MAC registers.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/r8169.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9d3ebf3..966407c 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2821,8 +2821,8 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
spin_lock_irq(&tp->lock);
RTL_W8(Cfg9346, Cfg9346_Unlock);
- RTL_W32(MAC0, low);
RTL_W32(MAC4, high);
+ RTL_W32(MAC0, low);
RTL_W8(Cfg9346, Cfg9346_Lock);
spin_unlock_irq(&tp->lock);
@@ -4754,8 +4754,8 @@ static void rtl_set_rx_mode(struct net_device *dev)
mc_filter[1] = swab32(data);
}
- RTL_W32(MAR0 + 0, mc_filter[0]);
RTL_W32(MAR0 + 4, mc_filter[1]);
+ RTL_W32(MAR0 + 0, mc_filter[0]);
RTL_W32(RxConfig, tmp);
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] r8169: fix broken register writes
From: Ben Hutchings @ 2010-03-28 0:47 UTC (permalink / raw)
To: François Romieu; +Cc: David Miller, timo.teras, ivecera, netdev
In-Reply-To: <20100328003143.GA8501@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Sun, 2010-03-28 at 02:31 +0100, François Romieu wrote:
> This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7
> though said registers are not even documented as 64-bit registers
> - as opposed to the initial TxDescStartAddress ones - but as single
> bytes which must be combined into 32 bits at the MMIO read/write
> level before being merged into a 64 bit logical entity.
[...]
Thanks François. Which hardware have you tested this on so far? I was
hesitant to make changes because of the huge number of variants.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH] decnet: Remove unused FIB metric macros.
From: David Miller @ 2010-03-28 2:26 UTC (permalink / raw)
To: netdev
Unlike the ipv4 side, these are completely unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Committed to net-next-2.6
include/net/dn_fib.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/net/dn_fib.h b/include/net/dn_fib.h
index 52da6c3..bbcde32 100644
--- a/include/net/dn_fib.h
+++ b/include/net/dn_fib.h
@@ -50,10 +50,6 @@ struct dn_fib_info {
__le16 fib_prefsrc;
__u32 fib_priority;
__u32 fib_metrics[RTAX_MAX];
-#define dn_fib_mtu fib_metrics[RTAX_MTU-1]
-#define dn_fib_window fib_metrics[RTAX_WINDOW-1]
-#define dn_fib_rtt fib_metrics[RTAX_RTT-1]
-#define dn_fib_advmss fib_metrics[RTAX_ADVMSS-1]
int fib_nhs;
int fib_power;
struct dn_fib_nh fib_nh[0];
--
1.7.0.3
^ permalink raw reply related
* Re: [PATCH] r8169: fix broken register writes
From: David Miller @ 2010-03-28 2:38 UTC (permalink / raw)
To: romieu; +Cc: ben, timo.teras, ivecera, netdev
In-Reply-To: <20100328003143.GA8501@electric-eye.fr.zoreil.com>
From: François Romieu <romieu@fr.zoreil.com>
Date: Sun, 28 Mar 2010 01:31:43 +0100
> This is quite similar to b39fe41f481d20c201012e4483e76c203802dda7
> though said registers are not even documented as 64-bit registers
> - as opposed to the initial TxDescStartAddress ones - but as single
> bytes which must be combined into 32 bits at the MMIO read/write
> level before being merged into a 64 bit logical entity.
>
> Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR
> registers (aka "multicast is broken for ages on ARM) and to
> Timo Teräs <timo.teras@iki.fi> for the MAC registers.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied, thanks Francois.
Probably the rest of the driver should be audited for other
areas where we may end up having this problem.
Or, we should create readq/writeq macros (like other drivers do on
32-bit platforms, f.e. see drivers/net/niu.c) which write the two
32-bit parts in this required order. Then access the registers using
readq/writeq entities throughout the driver.
This would have two benefits:
1) Coverage for all possible bug cases.
2) Real 64-bit accesses on 64-bit platforms.
Just some suggestions.
Thanks.
^ 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