* Re: [PATCH] 3c59x: sparse warning fix
From: Steffen Klassert @ 2007-09-13 6:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, netdev
In-Reply-To: <20070905152359.26215f89@oldman>
On Wed, Sep 05, 2007 at 03:23:59PM +0100, Stephen Hemminger wrote:
> --- a/drivers/net/3c59x.c 2007-09-05 15:15:16.000000000 +0100
> +++ b/drivers/net/3c59x.c 2007-09-05 15:16:29.000000000 +0100
> @@ -1122,7 +1122,7 @@ static int __devinit vortex_probe1(struc
> + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
> &vp->rx_ring_dma);
> retval = -ENOMEM;
> - if (vp->rx_ring == 0)
> + if (!vp->rx_ring)
> goto free_region;
>
> vp->tx_ring = (struct boom_tx_desc *)(vp->rx_ring + RX_RING_SIZE);
> @@ -2476,7 +2476,8 @@ boomerang_rx(struct net_device *dev)
>
> /* Check if the packet is long enough to just accept without
> copying to a properly sized skbuff. */
> - if (pkt_len < rx_copybreak && (skb = dev_alloc_skb(pkt_len + 2)) != 0) {
> + if (pkt_len < rx_copybreak &&
> + (skb = dev_alloc_skb(pkt_len + 2)) ) {
> skb_reserve(skb, 2); /* Align IP on 16 byte boundaries */
> pci_dma_sync_single_for_cpu(VORTEX_PCI(vp), dma, PKT_BUF_SZ, PCI_DMA_FROMDEVICE);
> /* 'skb_put()' points to the start of sk_buff data area. */
> -
Thanks,
Acked-by: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
^ permalink raw reply
* Re: [net-2.6.24][XFRM][patch 0/1] fix allmodconfig
From: David Miller @ 2007-09-13 6:51 UTC (permalink / raw)
To: dlezcano; +Cc: netdev, latten
In-Reply-To: <20070912152715.747974665@mai.toulouse-stg.fr.ibm.com>
From: dlezcano@fr.ibm.com
Date: Wed, 12 Sep 2007 17:27:15 +0200
> Fixes missing export symbols
This should already be corrected in net-2.6.24
^ permalink raw reply
* Re: [PATCH] [-MM, FIX V3] e1000e: incorporate napi_struct changes from net-2.6.24.git
From: David Miller @ 2007-09-13 6:55 UTC (permalink / raw)
To: auke-jan.h.kok; +Cc: Robert.Olsson, akpm, jeff, netdev
In-Reply-To: <46E816F5.9010409@intel.com>
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
Date: Wed, 12 Sep 2007 09:42:29 -0700
> David Miller wrote:
> >
> > diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> > index 7b0bcdb..58bb758 100644
> > --- a/drivers/net/e1000/e1000_main.c
> > +++ b/drivers/net/e1000/e1000_main.c
> > @@ -3944,7 +3944,7 @@ e1000_clean(struct napi_struct *napi, int budget)
> > &work_done, budget);
> >
> > /* If no Tx and not enough Rx work done, exit the polling mode */
> > - if ((tx_cleaned && (work_done < budget)) ||
> > + if ((!tx_cleaned && (work_done < budget)) ||
> > !netif_running(poll_dev)) {
> > quit_polling:
> > if (likely(adapter->itr_setting & 3))
>
>
> Ack, this is exactly what I did to fix e1000e as well.
Thanks for reviewing.
^ permalink raw reply
* Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates
From: David Miller @ 2007-09-13 6:57 UTC (permalink / raw)
To: mandeep.baines
Cc: shemminger, jchapman, hadi, billfink, netdev, jeff, ossthema
In-Reply-To: <535ddc6b0709120947x3458c87dk7dac9a2b8edf26f6@mail.gmail.com>
From: "Mandeep Baines" <mandeep.baines@gmail.com>
Date: Wed, 12 Sep 2007 09:47:46 -0700
> Why would disabling IRQ's be expensive on non-MSI PCI devices?
> Wouldn't it just require a single MMIO write to clear the interrupt
> mask of the device.
MMIO's are the most expensive part of the whole interrupt
servicing routines and minimizing them is absolutely
crucial.
This is why many devices do things like report status purely
in memory data structures, automatically disable interrupts
on either MSI delivery or status register read, etc.
Often you will see the first MMIO access in the interrupt
handler at the top of the profiles.
^ permalink raw reply
* hello.ccz, i have some question to ask you, please contack me
From: 潘炳宇 @ 2007-09-13 6:58 UTC (permalink / raw)
To: netdev
^ permalink raw reply
* bridge problem
From: 潘炳宇 @ 2007-09-13 7:03 UTC (permalink / raw)
To: netdev
i get a bridge problem when patch my kernel 2.4.32
^ permalink raw reply
* Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170
From: Johannes Berg @ 2007-09-13 7:16 UTC (permalink / raw)
To: David Miller
Cc: herbert, satyam, flo, linux-kernel, netdev, linux-wireless,
michal.k.k.piotrowski, ipw3945-devel, yi.zhu
In-Reply-To: <20070912.053411.21914920.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
On Wed, 2007-09-12 at 05:34 -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Thu, 06 Sep 2007 17:19:55 +0200
>
> >
> > Oh btw. Can we stick a might_sleep() into dev_close() *before* the test
> > whether the device is up? That way, we'd have seen the bug, but
> > apparently nobody before Florian ever did a 'ip link set wmaster0 down'
> > while the other interfaces were still open.
>
> I've added this to net-2.6.24
Great, thanks. Now I just hope John gets around to merging all the
accumulated fixes :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [net-2.6.24][NETNS][patch 1/1] fix allnoconfig compilation error
From: David Miller @ 2007-09-13 7:17 UTC (permalink / raw)
To: dlezcano; +Cc: ebiederm, containers, netdev
In-Reply-To: <20070913060545.740930015@mai.toulouse-stg.fr.ibm.com>
From: dlezcano@fr.ibm.com
Date: Thu, 13 Sep 2007 08:01:52 +0200
> From: Daniel Lezcano <dlezcano@fr.ibm.com>
>
> When CONFIG_NET=no, init_net is unresolved because net_namespace.c
> is not compiled and the include pull init_net definition.
>
> This problem was very similar with the ipc namespace where the kernel
> can be compiled with SYSV ipc out.
>
> This patch fix that defining a macro which simply remove init_net
> initialization from nsproxy namespace aggregator.
>
> Compiled and booted on qemu-i386 with CONFIG_NET=no and CONFIG_NET=yes.
>
> Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH] net: Fix race when opening a proc file while a network namespace is exiting.
From: David Miller @ 2007-09-13 7:19 UTC (permalink / raw)
To: paulmck; +Cc: ebiederm, netdev, containers
In-Reply-To: <20070912224653.GK9830@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Wed, 12 Sep 2007 15:46:53 -0700
> Looks much better!
>
> Acked-by: Paul E. McKenney <paulmck@us.ibm.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH 1/3 v4] rfkill: Remove IRDA
From: David Miller @ 2007-09-13 7:23 UTC (permalink / raw)
To: ivdoorn; +Cc: dtor, netdev, inaky
In-Reply-To: <200709122014.26660.IvDoorn@gmail.com>
From: Ivo van Doorn <ivdoorn@gmail.com>
Date: Wed, 12 Sep 2007 20:14:26 +0200
> As Dmitry pointed out earlier, rfkill-input.c
> doesn't support irda because there are no users
> and we shouldn't add unrequired KEY_ defines.
>
> However, RFKILL_TYPE_IRDA was defined in the
> rfkill.h header file and would confuse people
> about whether it is implemented or not.
>
> This patch removes IRDA support completely,
> so it can be added whenever a driver wants the
> feature.
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Applied to net-2.6.24
^ permalink raw reply
* Re: [PATCH 2/3 v4] rfkill: Add support for ultrawideband
From: David Miller @ 2007-09-13 7:23 UTC (permalink / raw)
To: ivdoorn; +Cc: dtor, netdev, inaky
In-Reply-To: <200709122014.29435.IvDoorn@gmail.com>
From: Ivo van Doorn <ivdoorn@gmail.com>
Date: Wed, 12 Sep 2007 20:14:29 +0200
> This patch will add support for UWB keys to rfkill,
> support for this has been requested by Inaky.
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> CC: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Applied to net-2.6.24
^ permalink raw reply
* Re: [PATCH 3/3 v4] rfkill: Add rfkill documentation
From: David Miller @ 2007-09-13 7:24 UTC (permalink / raw)
To: ivdoorn; +Cc: dtor, netdev, inaky, randy.dunlap
In-Reply-To: <200709122014.39600.IvDoorn@gmail.com>
From: Ivo van Doorn <ivdoorn@gmail.com>
Date: Wed, 12 Sep 2007 20:14:39 +0200
> Add a documentation file which contains
> a short description about rfkill with some
> notes about drivers and the userspace interface.
>
> Changes since v1 and v2:
> - Spellchecking
>
> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
> Acked-by: Dmitry Torokhov <dtor@mail.ru>
> Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Applied to net-2.6.24, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] [IPV6]: Fix unbalanced socket reference with MSG_CONFIRM.
From: David Miller @ 2007-09-13 8:12 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20070913.093528.54061581.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Thu, 13 Sep 2007 09:35:28 +0900 (JST)
> | [PATCH 1/4] [IPV6]: Fix unbalanced socket reference with MSG_CONFIRM.
>
> Ah, I should say, socket locking, probably...
> Anyway, lock_sock() and release_sock() are not paired approriately.
Thanks for these fixes, I'll merge these in as soon as I
can, which might take a little bit since I'm traveling today.
^ permalink raw reply
* Re: [PATCH] [RFC] allow admin/users to specify rto_min in milliseconds rather than jiffies
From: Stephen Hemminger @ 2007-09-13 8:39 UTC (permalink / raw)
To: Rick Jones; +Cc: David Miller, Rick Jones, netdev
In-Reply-To: <46E84BFA.2070101@hp.com>
On Wed, 12 Sep 2007 13:28:42 -0700
Rick Jones <rick.jones2@hp.com> wrote:
> >> The api in netlink should be in milliseconds rather than compensating
> >> in the application (iproute2).
> >
> >
> > My understanding of the in-kernel rtnetlink code is far from complete,
> > but it doesn't seem to have much in the way of provisions for unit
> > conversion, which would suggest no nice suffix-based ui as in tc, and ip
> > is already doing some massaging of units on the display side for a
> > couple of the other parameters, so I'm at something of a loss.
>
> So, I used the source and looked and saw that tc seems to convert
> everything to nanoseconds and passes that to the kernel. The user can
> give it seconds, milliseconds, microseconds or nanoseconds by using a
> suffix. It then does something ostensibly intelligent to display those
> to the user.
>
> Ip converts nothing when passing things to the kernel (rtt rttvar or rto
> - when/if at least the intial rto changes are included - were they?),
> but when they come-out of the kernel ip converts them to milliseconds.
> So the units in != the units out.
>
> Tc seems much more friendly and less prone to user error.
>
> I'm still not sure how "easily" rtnetlink can do conversions itself -
> feedback there would be _very_ welcome - but at the very least, having
> ip provide at least the illusion of what tc does would seem to be a good
> thing.
>
> rick jones
Your observations are correct. rtnetlink can't/shouldn't be doing conversions
itself. The 'ip' command should use a consistent unit for all values and
do conversions if necessary.
^ permalink raw reply
* [BUG] tg3 cannot do PXE (loses MAC address) after soft reboot
From: Lucas Nussbaum @ 2007-09-13 8:39 UTC (permalink / raw)
To: netdev; +Cc: mchan
Hi,
We use PXE with Broadcom NetXtreme cards. After a soft reboot (using the
"reboot" command), the system cannot get an IP address using DHCP. On
the console, a MAC address of 00 00 00 00 00 00 is shown. When rebooting
with "reboot -f" or with the reset button, everything works as expected.
This used to work, and broke between 2.6.16 and 2.6.17. Using git bissect,
I could trace this back to that commit:
commit bc1c756741b065cfebf850e4164c0e2aae9d527f
Author: Michael Chan <mchan@broadcom.com>
Date: Mon Mar 20 17:48:03 2006 -0800
[TG3]: Support shutdown WoL.
During boot, the following messages are displayed:
Broadcom NetXtreme Gigabit Ethernet Boot Agent v2.2.8
[...]
Broadcom UNDI, PXE-2.1 (build 082) v2.2.8
[...]
CLIENT MAC ADDR: 00 10 18 01 E5 2F GUID: 44454C4C 4800 1052 8032
B9C04F53304A
After a soft reboot, the last line is changed to:
CLIENT MAC ADDR: 00 00 00 00 00 00 GUID: 44454C4C 4800 1052 8032
B9C04F53304A
lspci -v for the card:
02:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
Subsystem: Broadcom Corporation NetXtreme BCM5703 1000Base-T
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 177
Memory at fcf00000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
Thank you,
--
| Lucas Nussbaum PhD student |
| lucas.nussbaum@imag.fr LIG / Projet MESCAL |
| jabber: lucas@nussbaum.fr +33 (0)6 64 71 41 65 |
| homepage: http://www-id.imag.fr/~nussbaum/ |
^ permalink raw reply
* Re: [CORRECTION][PATCH] Fix a potential NULL pointer dereference in uli526x_interrupt() in drivers/net/tulip/uli526x.c
From: Andrew Morton @ 2007-09-13 9:03 UTC (permalink / raw)
To: Micah Gruber; +Cc: linux-kernel, netdev, jgarzik, Grant Grundler
In-Reply-To: <46DD13CE.6010905@gmail.com>
On Tue, 04 Sep 2007 16:14:06 +0800 Micah Gruber <micah.gruber@gmail.com> wrote:
> This patch fixes a potential null dereference bug where we dereference dev before a null check. This patch simply moves the dereferencing after the null check.
>
> Signed-off-by: Micah Gruber <micah.gruber@gmail.com>
> ---
>
> --- a/drivers/net/tulip/uli526x.c
> +++ b/drivers/net/tulip/uli526x.c
> @@ -663,7 +663,7 @@
> {
> struct net_device *dev = dev_id;
> struct uli526x_board_info *db = netdev_priv(dev);
> - unsigned long ioaddr = dev->base_addr;
> + unsigned long ioaddr;
> unsigned long flags;
>
> if (!dev) {
> @@ -671,6 +671,8 @@
> return IRQ_NONE;
> }
>
> + ioaddr = dev->base_addr;
> +
> spin_lock_irqsave(&db->lock, flags);
> outl(0, ioaddr + DCR7);
>
I suspect the fix we want is:
--- a/drivers/net/tulip/uli526x.c~fix-a-potential-null-pointer-dereference-in-uli526x_interrupt
+++ a/drivers/net/tulip/uli526x.c
@@ -666,11 +666,6 @@ static irqreturn_t uli526x_interrupt(int
unsigned long ioaddr = dev->base_addr;
unsigned long flags;
- if (!dev) {
- ULI526X_DBUG(1, "uli526x_interrupt() without DEVICE arg", 0);
- return IRQ_NONE;
- }
-
spin_lock_irqsave(&db->lock, flags);
outl(0, ioaddr + DCR7);
_
^ permalink raw reply
* Re: [PATCH] veth: Cleanly handle a missing peer_tb argument on creation.
From: Pavel Emelyanov @ 2007-09-13 9:02 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, Patrick McHardy, netdev, Stephen Hemminger
In-Reply-To: <m1ejh3aosm.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Pavel Emelyanov <xemul@openvz.org> writes:
>
>> Eric W. Biederman wrote:
>>> Pavel Emelyanov <xemul@openvz.org> writes:
>>>
>>>>> + }
>>>>>
>>>>> - tbp = peer_tb;
>>>>> - } else
>>>>> - tbp = tb;
>>>> The intention of this part was to get the same parameters for
>>>> peer as for the first device if no "peer" argument was specified
>>>> for ip utility. Does it still work?
>>> I know it is problematic because we try to assign the same name
>>> to both network devices, if we assign a name to the primary
>>> network device. That can't work.
>> This can - as you can see I reallocate the name lower.
>
> Hmm. I just see:
> if (tbp[IFLA_IFNAME])
> nla_strlcpy(ifname, tbp[IFLA_IFNAME], IFNAMSIZ);
>
> Then lower I see:
> if (tb[IFLA_IFNAME])
> nla_strlcpy(dev->name, tb[IFLA_IFNAME], IFNAMSIZ);
>
> If (tb == tbp) then dev->name == ifname
> Unless I'm completely misreading that code.
>
>>> Beyond that I had some really weird crashes while testing this
>>> piece of code, especially when I did not specify a peer parameter.
>> Can you please give me the exact command that caused an oops.
>> I try simple ip link add type veth and everything is just fine.
>
> It might have been 64bit specific.
>
> What I have in my history is:
> ./ip/ip link add veth23 type veth
>
> I forget exactly how it failed but as I recall it wasn't as
> nice as an oops. My memory may be a bit foggy though.
>
> If I haven't provided a bit enough clue I guess I can go back
> and remove the patch and try to reproduce the failure again.
Neither ip link add type veth nor your one fail on my x86_64 box.
However, maybe you didn't like that your command didn't produce
any devices. I can explain this. You order two *equal* devices with
the same name veth23. This has to fail. However if you request
devices with generic name veth%d or with different names everything
is good.
So could you please give more clues on what's bad with veth driver.
>>> So it was just easier to avoid the problem with this patch then
>>> to completely root cause it.
>> Let me handle this problem. AFAIR this was one of wishes from
>> Patrick that we make two equal devices in case peer is not given,
>> not just the default peer.
>
> Ok. I have if we can track down the weird cases I have no problem
> if we handle this. I think it still might be simpler if just
> copy tb onto peer_tb instead of using tbp.
>
> Eric
>
^ permalink raw reply
* Re: bridge problem
From: Stephen Hemminger @ 2007-09-13 9:16 UTC (permalink / raw)
To: "潘炳宇"; +Cc: netdev
In-Reply-To: <200709131503208757279@gmail.com>
On Thu, 13 Sep 2007 15:03:24 +0800
"潘炳宇" <panbingyu@gmail.com> wrote:
> i get a bridge problem when patch my kernel 2.4.32
You need to describe the problem more fully to get assistance.
^ permalink raw reply
* Re: [CORRECTION][PATCH] Fix a potential NULL pointer dereference in uli526x_interrupt() in drivers/net/tulip/uli526x.c
From: Kyle McMartin @ 2007-09-13 9:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: Micah Gruber, linux-kernel, netdev, jgarzik, Grant Grundler
In-Reply-To: <20070913020346.979647c1.akpm@linux-foundation.org>
On Thu, Sep 13, 2007 at 02:03:46AM -0700, Andrew Morton wrote:
> I suspect the fix we want is:
>
ack. The trend seems to be to avoid this redundant check in the
interrupt handler.
^ permalink raw reply
* Re: [PATCH] Fix a lock problem in generic phy code
From: Hans-Jürgen Koch @ 2007-09-13 9:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, netdev, afleming
In-Reply-To: <46E8B8C4.5010203@garzik.org>
Am Donnerstag 13 September 2007 schrieb Jeff Garzik:
> Hans-Jürgen Koch wrote:
> > Lock debugging finds a problem in phy.c and phy_device.c,
> > this patch fixes it. Tested on an AT91SAM9263-EK board,
> > kernel 2.6.23-rc4.
> >
> > Signed-off-by: Hans J. Koch <hjk@linutronix.de>
>
> applied
Thanks! Andrew applied it to -mm, too.
Hans
^ permalink raw reply
* [PATCH 1/1] ipv6: remove redundant RTM_DELLINK message
From: Milan Kocian @ 2007-09-13 9:57 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, netdev
In-Reply-To: <20070912145323.GE18480@postel.suug.ch>
remove useless message. We get right message from other subsystem.
---
--- a/net/ipv6/addrconf.c 2007-09-13 11:22:31.087494976 +0200
+++ b/net/ipv6/addrconf.c 2007-09-13 11:25:56.056225711 +0200
@@ -2486,9 +2486,7 @@ static int addrconf_ifdown(struct net_de
else
ipv6_mc_down(idev);
- /* Step 5: netlink notification of this interface */
idev->tstamp = jiffies;
- inet6_ifinfo_notify(RTM_DELLINK, idev);
/* Shot the device (if unregistered) */
Signed-off-by: Milan Kocian <milon@wq.cz>
^ permalink raw reply
* Re: [PATCH 4/4] [IPROUTE2] iproute2: link_veth support bug fixes.
From: Stephen Hemminger @ 2007-09-13 10:30 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Pavel Emelyanov, netdev, Patrick McHardy
In-Reply-To: <m1ir6fapdt.fsf@ebiederm.dsl.xmission.com>
On Wed, 12 Sep 2007 09:13:02 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Pavel Emelyanov <xemul@openvz.org> writes:
>
> > [snip]
> >
> >> @@ -25,6 +26,3 @@ clean:
> >>
> >> LDLIBS += -ldl
> >> LDFLAGS += -Wl,-export-dynamic
> >> -
> >> -%.so: %.c
> >> - $(CC) $(CFLAGS) -shared $< -o $@
> >
> > %) How do we get the .so file then?
>
> The code was built into iproute2, so we don't need the .so file.
> That rule does not work on arch/x86_64 so I had to do something
> and the easiest was to simply compile the code in. Like Patrick
> did with his recent VLAN support.
>
> The usefulness of a .so file seems to be distributing the code
> outside of /bin/ip. Although I think we currently have some issues with
> mixed 32bit and 64bit systems because we have "/usr/lib/ip/link_*.so"
> hard coded.
>
> A .so file always seems to override the compiled in version so I don't
> think we loose any flexibility on that front.
>
> Eric
Fixing the 64 bit library path is on my to fix list.
^ permalink raw reply
* [RFC] af_packet: allow disabling timestamps
From: Stephen Hemminger @ 2007-09-13 10:42 UTC (permalink / raw)
To: Unai Uribarri, David S. Miller; +Cc: Evgeniy Polyakov, netdev
In-Reply-To: <1186685450.24669.81.camel@localhost.localdomain>
Currently, af_packet does not allow disabling timestamps. This patch changes
that but doesn't force global timestamps on.
This shows up in bugzilla as:
http://bugzilla.kernel.org/show_bug.cgi?id=4809
Patch against net-2.6.24 tree.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/net/core/sock.c 2007-09-12 15:08:43.000000000 +0200
+++ b/net/core/sock.c 2007-09-13 12:10:19.000000000 +0200
@@ -259,7 +259,8 @@ static void sock_disable_timestamp(struc
{
if (sock_flag(sk, SOCK_TIMESTAMP)) {
sock_reset_flag(sk, SOCK_TIMESTAMP);
- net_disable_timestamp();
+ if (sk->sk_family != PF_PACKET)
+ net_disable_timestamp();
}
}
@@ -1645,7 +1646,8 @@ void sock_enable_timestamp(struct sock *
{
if (!sock_flag(sk, SOCK_TIMESTAMP)) {
sock_set_flag(sk, SOCK_TIMESTAMP);
- net_enable_timestamp();
+ if (sk->sk_family != PF_PACKET)
+ net_enable_timestamp();
}
}
EXPORT_SYMBOL(sock_enable_timestamp);
--- a/net/packet/af_packet.c 2007-09-12 17:07:00.000000000 +0200
+++ b/net/packet/af_packet.c 2007-09-13 12:09:10.000000000 +0200
@@ -572,7 +572,6 @@ static int tpacket_rcv(struct sk_buff *s
unsigned long status = TP_STATUS_LOSING|TP_STATUS_USER;
unsigned short macoff, netoff;
struct sk_buff *copy_skb = NULL;
- struct timeval tv;
if (dev->nd_net != &init_net)
goto drop;
@@ -650,12 +649,19 @@ static int tpacket_rcv(struct sk_buff *s
h->tp_snaplen = snaplen;
h->tp_mac = macoff;
h->tp_net = netoff;
- if (skb->tstamp.tv64)
- tv = ktime_to_timeval(skb->tstamp);
- else
- do_gettimeofday(&tv);
- h->tp_sec = tv.tv_sec;
- h->tp_usec = tv.tv_usec;
+
+ if (sock_flag(sk, SOCK_TIMESTAMP)) {
+ struct timeval tv;
+ if (skb->tstamp.tv64)
+ tv = ktime_to_timeval(skb->tstamp);
+ else
+ do_gettimeofday(&tv);
+ h->tp_sec = tv.tv_sec;
+ h->tp_usec = tv.tv_usec;
+ } else {
+ h->tp_sec = 0;
+ h->tp_usec = 0;
+ }
sll = (struct sockaddr_ll*)((u8*)h + TPACKET_ALIGN(sizeof(*h)));
sll->sll_halen = 0;
@@ -1014,6 +1020,7 @@ static int packet_create(struct net *net
sock->ops = &packet_ops_spkt;
sock_init_data(sock, sk);
+ sock_set_flag(sk, SOCK_TIMESTAMP);
po = pkt_sk(sk);
sk->sk_family = PF_PACKET;
^ permalink raw reply
* Re: [PATCH][MIPS][7/7] AR7: ethernet
From: Ralf Baechle @ 2007-09-13 11:35 UTC (permalink / raw)
To: Thiemo Seufer
Cc: Matteo Croce, linux-mips, Eugene Konev, netdev, davem, kuznet,
pekkas, jmorris, yoshfuji, kaber, openwrt-devel, Andrew Morton,
Jeff Garzik
In-Reply-To: <20070913014246.GB15247@networkno.de>
On Thu, Sep 13, 2007 at 02:42:46AM +0100, Thiemo Seufer wrote:
> > All struct members here are sized such that there is no padding needed, so
> > the packed attribute doesn't buy you anything - unless of course the
> > entire structure is missaligned but I don't see how that would be possible
> > in this driver so the __attribute__ ((packed)) should go - it result in
> > somwhat larger and slower code.
>
> FWIW, a modern gcc will warn about such superfluous packed attributes,
> that's another reason to remove those.
I doubt it will in this case; the packed structure is dereferenced by a
pointer so no way for gcc to know the alignment.
Ralf
^ permalink raw reply
* Re: Distributed storage. Security attributes and ducumentation update.
From: Evgeniy Polyakov @ 2007-09-13 12:22 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: netdev, linux-kernel, linux-fsdevel
In-Reply-To: <20070910221445.GL11801@linux.vnet.ibm.com>
Hi Paul.
On Mon, Sep 10, 2007 at 03:14:45PM -0700, Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > Further TODO list includes:
> > * implement optional saving of mirroring/linear information on the remote
> > nodes (simple)
> > * implement netlink based setup (simple)
> > * new redundancy algorithm (complex)
> >
> > Homepage:
> > http://tservice.net.ru/~s0mbre/old/?section=projects&item=dst
>
> A couple questions below, but otherwise looks good from an RCU viewpoint.
>
> Thanx, Paul
Thanks for your comments, and sorry for late reply I was at KS/London
trip.
> > + if (--num) {
> > + list_for_each_entry_rcu(n, &node->shared, shared) {
>
> This function is called under rcu_read_lock() or similar, right?
> (Can't tell from this patch.) It is also OK to call it from under the
> update-side mutex, of course.
Actually not, but it does not require it, since entry can not be removed
during this operations since appropriate reference counter for given node is
being held. It should not be RCU at all.
> > +static int dst_mirror_read(struct dst_request *req)
> > +{
> > + struct dst_node *node = req->node, *n, *min_dist_node;
> > + struct dst_mirror_priv *priv = node->priv;
> > + u64 dist, d;
> > + int err;
> > +
> > + req->bio_endio = &dst_mirror_read_endio;
> > +
> > + do {
> > + err = -ENODEV;
> > + min_dist_node = NULL;
> > + dist = -1ULL;
> > +
> > + /*
> > + * Reading is never performed from the node under resync.
> > + * If this will cause any troubles (like all nodes must be
> > + * resynced between each other), this check can be removed
> > + * and per-chunk dirty bit can be tested instead.
> > + */
> > +
> > + if (!test_bit(DST_NODE_NOTSYNC, &node->flags)) {
> > + priv = node->priv;
> > + if (req->start > priv->last_start)
> > + dist = req->start - priv->last_start;
> > + else
> > + dist = priv->last_start - req->start;
> > + min_dist_node = req->node;
> > + }
> > +
> > + list_for_each_entry_rcu(n, &node->shared, shared) {
>
> I see one call to this function that appears to be under the update-side
> mutex, but I cannot tell if the other calls are safe. (Safe as in either
> under the update-side mutex or under rcu_read_lock() and friends.)
The same here - those processing function are called from
generic_make_request() from any lock on top of them. Each node is linked
into the list of the first added node, which reference counter is
increased in higher layer. Right now there is no way to add or remove
nodes after array was started, such functionality requires storage tree
lock to be taken and RCU can not be used (since it requires sleeping and
I did not investigate sleepable RCU for this purpose).
So, essentially RCU is not used in DST :)
Thanks for review, Paul.
--
Evgeniy Polyakov
^ 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