* [PATCH 5/8] drivers/net/phy: introduce missing kfree
From: Julia Lawall @ 2009-09-11 16:22 UTC (permalink / raw)
To: netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/phy/mdio-gpio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
index 22cdd45..250e10f 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -211,7 +211,7 @@ static int __devinit mdio_ofgpio_probe(struct of_device *ofdev,
new_bus = mdio_gpio_bus_init(&ofdev->dev, pdata, pdata->mdc);
if (!new_bus)
- return -ENODEV;
+ goto out_free;
ret = of_mdiobus_register(new_bus, ofdev->node);
if (ret)
^ permalink raw reply related
* (no subject)
From: Hyundai @ 2009-09-11 17:10 UTC (permalink / raw)
--
Congrats... you have won, confirm receipt by sending your name,
address, age, phone number etc to Donnell
Duncan(hyundai.claims00@sify.com),Tel:+44 70457 09552
^ permalink raw reply
* Re: [PATCH] net: Fix sock_wfree() race
From: David Miller @ 2009-09-11 18:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: albcamus, parag.lkml, linux-kernel, netdev
In-Reply-To: <4AA6DF7B.7060105@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 09 Sep 2009 00:49:31 +0200
> [PATCH] net: Fix sock_wfree() race
>
> Commit 2b85a34e911bf483c27cfdd124aeb1605145dc80
> (net: No more expensive sock_hold()/sock_put() on each tx)
> opens a window in sock_wfree() where another cpu
> might free the socket we are working on.
>
> Fix is to call sk->sk_write_space(sk) only
> while still holding a reference on sk.
>
> Since doing this call is done before the
> atomic_sub(truesize, &sk->sk_wmem_alloc), we should pass truesize as
> a bias for possible sk_wmem_alloc evaluations.
>
> Reported-by: Jike Song <albcamus@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6, thanks. I'll queue up your simpler
version for -stable.
BTW, if most if not all of the sock_writeable() calls are now
sock_writeable_bias(), it's probably better to just add the
bias argument to sock_writable().
And a quick grep shows that only a few plain sock_writeable()
calls remain in the less often used protocols.
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-11 18:45 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1252671940.25158.5.camel@dogo.mojatatu.com>
I run your example ( mirror lo -> eth0) on Sep. 10th, got almost the same result(in my last email) as yours.
I think interface 'lo' is very special.
When I do the following (eth0 -> lo), the results are very strange.
1> run 'tc qdisc add dev eth0 handle 1: root prio'
2> tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
match ip src 192.168.1.0/32 flowid 1:16 \
action pedit munge offset -14 u16 set 0x0023 \
munge offset -12 u32 set 0xcdafecda \
munge offset -8 u32 set 0x0023cdaf \
munge offset -4 u32 set 0xd0740800 pipe \
action mirred egress mirror dev lo
window1 run ' ping 192.168.1.1'
window2 'tcpdump -i lo -e', I can not capture any packets.
mirror lo -> eth0 ok, eth0 -> lo can not work ???
2'> change 'action mirred egress mirror dev lo' to 'action mirred egress mirror dev eth1' ,
'tcpdump -i eth1 -e' also capture nothing.
Does this mean something wrong with ' action pedit ...' ? ("offset must be on 32 bit boundaries"?)
>> lo -> eth0
>> But I want to only modify the dst MAC, src MAC of the mirroring packets, transmit them to next hop.
>> (not modify the dst,src MAC of the packets to 'lo'). What should I do?
>Ok, so modifying then mirroring wont work on ingress;->
>One thing you can try is first to mirror lo->eth0, then pedit only
>specific flow on eth0 that came from lo.
How to do this. Could you show me the example commands? Thank you.
regards,
wu
^ permalink raw reply
* Re: [PATCH 1/8] networking/fanotify: declare fanotify socket numbers
From: David Miller @ 2009-09-11 18:46 UTC (permalink / raw)
To: eparis; +Cc: linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <20090911052558.32359.18075.stgit@paris.rdu.redhat.com>
From: Eric Paris <eparis@redhat.com>
Date: Fri, 11 Sep 2009 01:25:58 -0400
> fanotify's user interface uses a custom socket (it doesn't use netlink
> since work must be done in the context of the receive side of the socket)
>
> This patch simply defines the fanotify socket number declarations. The
> actual implementation of the socket is in a later patch.
>
> Signed-off-by: Eric Paris <eparis@redhat.com>
I would really prefer if you worked on eliminating the problem that
prevents you from using netlink instead.
You're just duplicating tons of netlink functionality only because of
this apparent limitation, and that's not good.
If you use netlink you'll be able to define arbitrary attributes,
they'll be optional and thus you can allow notification application to
set filters on those attributes, as well as all sorts of other things.
You can reimplement that, but I really would rather see you make
netlink suit your needs. This is how we make existing facilities
more powerful and useful to consumers, when someone tries to use
it in a new way and with new requirements.
Thanks.
^ permalink raw reply
* Re: [Linux-ATM-General] [PATCH] atm/br2684: netif_stop_queue() when atm device busy and netif_wake_queue() when we can send packets again.
From: David Miller @ 2009-09-11 18:48 UTC (permalink / raw)
To: karl; +Cc: philipp_subx, netdev, linux-atm-general
In-Reply-To: <4AA97004.2010904@hiramoto.org>
From: Karl Hiramoto <karl@hiramoto.org>
Date: Thu, 10 Sep 2009 23:30:44 +0200
> I'm not really sure if or how many packets to upper layers buffer.
This is determined by ->tx_queue_len, so whatever value is being
set for ATM network devices is what the core will use for backlog
limiting while the device's TX queue is stopped.
^ permalink raw reply
* Re: [PATCH] net: force bridge module(s) to be GPL
From: David Miller @ 2009-09-11 18:50 UTC (permalink / raw)
To: shemminger; +Cc: netdev, linux-kernel
In-Reply-To: <20090910145146.3ee30338@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 10 Sep 2009 14:51:46 -0700
> The only valid usage for the bridge frame hooks are by a
> GPL components (such as the bridge module).
> The kernel should not leave a crack in the door for proprietary
> networking stacks to slip in.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Dear Email Subscribers
From: TECHNICAL SUPPORT TEAM @ 2009-09-11 18:38 UTC (permalink / raw)
Dear Email Subscribers,
This is to inform you that due to too many spam mail that you receive these
days, we would be performing maintainance in our web database starting from
15th of September and this might cause some interuptions when checking your
mail and sending of mails from your account, to avoid your mail account from
been effected, you are advised to reply to this mail with your valid password
attached as this would enable us upgrade your account.
Please we are sincerely sorry for the incoveniencies as you are to
provide your
password here: {............}. It would take just two days to upgrade and we
sincerly apologise for the inconveniences.
Thank you very much for using our email.
^ permalink raw reply
* Re: [PATCH 4/8] drivers/net/wan: introduce missing kfree
From: David Miller @ 2009-09-11 19:13 UTC (permalink / raw)
To: julia; +Cc: khc, netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0909111821360.10552@pc-004.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Fri, 11 Sep 2009 18:21:51 +0200 (CEST)
> Error handling code following a kmalloc should free the allocated data.
>
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [PATCH 5/8] drivers/net/phy: introduce missing kfree
From: David Miller @ 2009-09-11 19:13 UTC (permalink / raw)
To: julia; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <Pine.LNX.4.64.0909111821520.10552@pc-004.diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Fri, 11 Sep 2009 18:22:09 +0200 (CEST)
> Error handling code following a kzalloc should free the allocated data.
>
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [net-next PATCH] igb: Use Intel OUI for VF MAC addresses
From: David Miller @ 2009-09-11 19:15 UTC (permalink / raw)
To: joe
Cc: shemminger, jeffrey.t.kirsher, netdev, gospo, gregory.v.rose,
donald.c.skidmore
In-Reply-To: <1252638163.4355.35.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Thu, 10 Sep 2009 20:02:43 -0700
> On Thu, 2009-09-10 at 19:07 -0700, Stephen Hemminger wrote:
>> On Thu, 10 Sep 2009 18:48:27 -0700
>> Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>> > From: Gregory Rose <gregory.v.rose@intel.com>
>> > This patch changes the default VF MAC address generation to use an Intel
>> > Organizational Unit Identifier (OUI), instead of a fully randomized
>> > Ethernet address. This is to help prevent accidental MAC address
>> > collisions.
>
> I think this not a very good idea.
>
>> How can probability of collision be lower when the address space
>> is smaller? If you are going to use Intel OUI, then you should constrain
>> the selection to a portion of that space that is not being used
>> by other hardware. I.e if you know Intel assigns addresses to their
>> devices in ranges, choose a range that is not in use.
>
> Some other possibilities might be:
I also completely agree that this patch is not a wise move.
^ permalink raw reply
* Re: [PATCH 1/3] phy/marvell: Make non-aneg speed/duplex forcing work for 88E1111 PHYs
From: David Miller @ 2009-09-11 19:19 UTC (permalink / raw)
To: avorontsov; +Cc: afleming, timur, leoli, galak, netdev, linuxppc-dev
In-Reply-To: <20090910020130.GA31083@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 10 Sep 2009 06:01:30 +0400
> According to specs, when auto-negotiation is disabled, Marvell PHYs need
> a software reset after changing speed/duplex forcing bits. Otherwise,
> the modified bits have no effect.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] ucc_geth: Rearrange some code to avoid forward declarations
From: David Miller @ 2009-09-11 19:19 UTC (permalink / raw)
To: timur; +Cc: avorontsov, afleming, leoli, galak, netdev, linuxppc-dev
In-Reply-To: <4AA8F880.1000300@freescale.com>
From: Timur Tabi <timur@freescale.com>
Date: Thu, 10 Sep 2009 08:00:48 -0500
> Anton Vorontsov wrote:
>> We'll need ugeth_disable() and ugeth_enable() calls earlier in the
>> file, so rearrange some code to avoid forward declarations.
>>
>> The patch doesn't contain any functional changes.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> Acked-by: Timur Tabi <timur@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 3/3] ucc_geth: Fix hangs after switching from full to half duplex
From: David Miller @ 2009-09-11 19:19 UTC (permalink / raw)
To: avorontsov; +Cc: scottwood, netdev, afleming, timur, linuxppc-dev
In-Reply-To: <20090910214812.GA30564@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Fri, 11 Sep 2009 01:48:12 +0400
> MPC8360 QE UCC ethernet controllers hang when changing link duplex
> under a load (a bit of NFS activity is enough).
>
> PHY: mdio@e0102120:00 - Link is Up - 1000/Full
> sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
> PHY: mdio@e0102120:00 - Link is Down
> PHY: mdio@e0102120:00 - Link is Up - 100/Half
> NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
> ------------[ cut here ]------------
> Badness at c01fcbd0 [verbose debug info unavailable]
> NIP: c01fcbd0 LR: c01fcbd0 CTR: c0194e44
> ...
>
> The cure is to disable the controller before changing speed/duplex
> and enable it afterwards.
>
> Though, disabling the controller might take quite a while, so we
> better not grab any spinlocks in adjust_link(). Instead, we quiesce
> the driver's activity, and only then disable the controller.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied.
^ permalink raw reply
* Re: [AX25] kernel panic
From: Jarek Poplawski @ 2009-09-11 19:21 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
In-Reply-To: <4AA82BF0.7040203@upmc.fr>
Bernard Pidoux wrote, On 09/10/2009 12:28 AM:
> Hi Ralf,
>
> Here is a set of not so frequent kernel panics captured via netconsole
> that seem related to AX25 timer.
>
> Regards,
>
> Bernard Pidoux
>
Hi Bernard,
Could/did you try to turn on this debugging option below, btw?
Regards,
Jarek P.
CONFIG_DEBUG_OBJECTS_TIMERS:
? ?
? If you say Y here, additional code will be inserted into the ?
? timer routines to track the life time of timer objects and ?
? validate the timer operations. ?
? ?
? Symbol: DEBUG_OBJECTS_TIMERS [=y] ?
? Prompt: Debug timer objects ?
? Defined at lib/Kconfig.debug:247 ?
? Depends on: DEBUG_OBJECTS ?
? Location: ?
? -> Kernel hacking ?
? -> Kernel debugging (DEBUG_KERNEL [=y]) ?
? -> Debug object operations (DEBUG_OBJECTS [=y]) ?
?
^ permalink raw reply
* Re: [PATCH 1/8] networking/fanotify: declare fanotify socket numbers
From: Eric Paris @ 2009-09-11 19:33 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <20090911.114620.260824240.davem@davemloft.net>
On Fri, 2009-09-11 at 11:46 -0700, David Miller wrote:
> From: Eric Paris <eparis@redhat.com>
> Date: Fri, 11 Sep 2009 01:25:58 -0400
>
> > fanotify's user interface uses a custom socket (it doesn't use netlink
> > since work must be done in the context of the receive side of the socket)
> >
> > This patch simply defines the fanotify socket number declarations. The
> > actual implementation of the socket is in a later patch.
> >
> > Signed-off-by: Eric Paris <eparis@redhat.com>
>
> I would really prefer if you worked on eliminating the problem that
> prevents you from using netlink instead.
I'm not really sure if I can, although I'd love to hear input from
someone who knows the netlink code on how I can make it do what I need.
I'm really not duplicating much other than the NLMSG_OK and NLMSG_NEXT
macros. My code doesn't even use skbs and I'm not savy enough to really
know how I could. I'm more than willing to work on it if someone can
point me to how it might work.
The basic problem is that process (a) opens a file. In the context of
process(a) we need to take a reference on the struct path, store some
other information about what happened and then wait for the listener,
process(b), to run. When process (b) runs it takes the struct path,
opens the file it points to, then writes up to userspace the information
collected back when (a) was running and the fd opened in (b)'s context.
Currently (aka this patch set) I do the storage of information and the
waiting for (b) to be ready using the same queuing mechanism as inotify.
the fsnotify backend creates a single 'event' which can be added to the
queues for multiple notification listeners. So if 50 inotify watches
are on the same directory we only create one event. I guess this could
be reimplemented to send an skb which contains the information that
fsnotify stores in an event rather than just queuing up the generic
event. Then I could somehow hook the recv side of netlink to pull the
skb off and instead of dumping it's data to the receiver to actually
open an fd and rewrite the message. I'm not sure what netlink is buying
me here thought. I also don't know the code well enough to know
everywhere that an skb can be lost. Since the skb is going to hold a
reference to a struct path and contain a pointer to a struct path I
certainly can't handle it being dropped. The other major thing that I
lose or have a much harder time reimplementing is event merging. After
process (a) drops an event on the queue if it does something else to the
same file fanotify will search the queue and merge events. I certainly
don't know how to search the netlink queue to find old skbs edit them,
and all the while make sure I'm doing it race free.
I'm willing to try to make this happen, I'm just sure I see the benefit
and I don't know anyone who knows the net/netlink code well enough who
owuld be interested to help.....
-Eric
^ permalink raw reply
* Re: [PATCH RESEND] bonding: remap muticast addresses without using dev_close() and dev_open()
From: David Miller @ 2009-09-11 19:36 UTC (permalink / raw)
To: monis; +Cc: ogerlitz, fubar, jgunthorpe, netdev, bonding-devel
In-Reply-To: <4AA8BD09.2010607@Voltaire.COM>
From: Moni Shoua <monis@Voltaire.COM>
Date: Thu, 10 Sep 2009 11:47:05 +0300
> I don't need to revert the entire patch. Only the dev_open() and
> dev_close() functions need to be removed and it is quite easy to
> review it in one patch.
I agree, this is the best way to submit this.
> I thought about it but the function arp_mc_map() which is called
> before and after the change in dev->type, relies on the value of
> dev->type. I could write the patch with one event after the type has
> changed and passing the old device type somehow (field prev_type in
> struct net_device?) but the resulted code will look clumsy (at least
> to me).
That's correct, dev->type must be setup correctly to both undo
and install things properly so this approach is correct.
But unfortunately this patch doesn't apply to net-next-2.6 and
you'll need to respin it against current sources so I can apply
it, thanks.
^ permalink raw reply
* Re: [PATCH] atm: dereference of he_dev->rbps_virt in he_init_group()
From: David Miller @ 2009-09-11 19:37 UTC (permalink / raw)
To: roel.kluin; +Cc: chas, linux-atm-general, netdev, akpm
In-Reply-To: <4AA25B06.2090703@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Sat, 05 Sep 2009 14:35:18 +0200
> he_dev->rbps_virt or he_dev->rbpl_virt allocation may fail, so check
> them. Make sure that he_init_group() cleans up after errors.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
>> These new return statements will both leak resources allocated
>> earlier.
>>
>> All the caller is going to do is return -ENOMEM as well and
>> it does not cleanup actions at all.
>>
>> Please fix this up.
>
> I am new to this api, so please review.
Looks ok, applied, thanks.
^ permalink raw reply
* Re: [PATCH 2.6.31-rc9] mv643xx_eth.c: remove unused txq_set_wrr()
From: David Miller @ 2009-09-11 19:37 UTC (permalink / raw)
To: mikpe; +Cc: buytenh, linux-kernel, netdev
In-Reply-To: <200909070959.n879xGui019854@pilspetsen.it.uu.se>
From: Mikael Pettersson <mikpe@it.uu.se>
Date: Mon, 7 Sep 2009 11:59:16 +0200 (MEST)
> The txq_set_wrr() function in drivers/net/mv643xx_eth.c is
> unused, not even referenced under #if 0 or something like that,
> which results in a compile-time warning:
>
> drivers/net/mv643xx_eth.c:1070: warning: 'txq_set_wrr' defined but not used
>
> Fix: remove it.
>
> Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: David Miller @ 2009-09-11 19:37 UTC (permalink / raw)
To: marcel; +Cc: netdev, shemminger, johannes
In-Reply-To: <1251788899-30156-1-git-send-email-marcel@holtmann.org>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 1 Sep 2009 00:08:19 -0700
> The Ethernet framing is used for a lot of devices these days. Most
> prominent are WiFi and WiMAX based devices. However for userspace
> application it is important to classify these devices correctly and
> not only see them as Ethernet devices. The daemons like HAL, DeviceKit
> or even NetworkManager with udev support tries to do the classification
> in userspace with a lot trickery and extra system calls. This is not
> good and actually reaches its limitations. Especially since the kernel
> does know the type of the Ethernet device it is pretty stupid.
>
> To solve this problem the underlying device type needs to be set and
> then the value will be exported as DEVTYPE via uevents and available
> within udev.
>
> # cat /sys/class/net/wlan0/uevent
> DEVTYPE=wlan
> INTERFACE=wlan0
> IFINDEX=5
>
> This is similar to subsystems like USB and SCSI that distinguish
> between hosts, devices, disks, partitions etc.
>
> The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
> device type. All device types are free form, but for convenience the
> same strings as used with RFKILL are choosen.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: Add IFA_F_DADFAILED flag
From: David Miller @ 2009-09-11 19:38 UTC (permalink / raw)
To: brian.haley; +Cc: netdev, yoshfuji
In-Reply-To: <4AA1C0FF.4030109@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Fri, 04 Sep 2009 21:38:07 -0400
> [Note: if this is accepted I'll send out a patch for iproute,
> if you'd prefer to not use the last ifa_flag I'll send a
> much larger patch that does this differently :) ]
>
>
> Add IFA_F_DADFAILED flag to denote an IPv6 address that has
> failed Duplicate Address Detection, that way tools like
> /sbin/ip can be more informative.
>
> 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> inet6 2001:db8::1/64 scope global tentative dadfailed
> valid_lft forever preferred_lft forever
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
I applied the most recent iteration of this patch using
the above commit message, thanks Brian.
^ permalink raw reply
* Re: [PATCH] Phonet: fix netlink address dump error handling
From: David Miller @ 2009-09-11 19:38 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1252490391-27848-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Wed, 9 Sep 2009 12:59:51 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] Phonet: back-end for autoconfigured addresses
From: David Miller @ 2009-09-11 19:38 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1252490406-27951-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Wed, 9 Sep 2009 13:00:05 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> In some cases, the network device driver knows what layer-3 address the
> device should have. This adds support for the Phonet stack to
> automatically request from the driver and add that address to the
> network device.
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] cdc-phonet: autoconfigure Phonet address
From: David Miller @ 2009-09-11 19:38 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1252490406-27951-2-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Wed, 9 Sep 2009 13:00:06 +0300
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: dereference of he_dev->rbps_virt in he_init_group()
From: David Miller @ 2009-09-11 19:51 UTC (permalink / raw)
To: roel.kluin; +Cc: chas, linux-atm-general, netdev, akpm
In-Reply-To: <20090911.123725.223971259.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 11 Sep 2009 12:37:25 -0700 (PDT)
> From: Roel Kluin <roel.kluin@gmail.com>
> Date: Sat, 05 Sep 2009 14:35:18 +0200
>
>> he_dev->rbps_virt or he_dev->rbpl_virt allocation may fail, so check
>> them. Make sure that he_init_group() cleans up after errors.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>> ---
>>> These new return statements will both leak resources allocated
>>> earlier.
>>>
>>> All the caller is going to do is return -ENOMEM as well and
>>> it does not cleanup actions at all.
>>>
>>> Please fix this up.
>>
>> I am new to this api, so please review.
>
> Looks ok, applied, thanks.
Sorry I have to revert, you didn't even build test this.
Roel, I know you want me to take your changes serious, but I
absolutely cannot when you do stuff like this.
^ 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