* Re: [Bugme-new] [Bug 27212] New: Warning kmemcheck: Caught 64-bit read from uninitialized memory in netlink_broadcast_filtered
From: Pekka Enberg @ 2011-02-15 5:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon,
casteyde.christian, Changli Gao, Vegard Nossum, David Miller,
linux-kernel, Christoph Lameter, David Rientjes
In-Reply-To: <1297704922.2996.60.camel@edumazet-laptop>
On Mon, Feb 14, 2011 at 7:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 21 janvier 2011 à 09:49 +0200, Pekka Enberg a écrit :
>
>> It actually looks like a bug in SLUB+kmemcheck. The
>> kmemcheck_slab_alloc() call in slab_post_alloc_hook() should use ksize()
>> instead of s->objsize. SLAB seems to do the right thing already. Anyone
>> care to send a patch my way?
>>
>
> Hmm, what do you think of following patch ?
>
> Thanks, and sorry for the delay.
Looks good to me. Christoph, David, any objections to the patch?
> [PATCH] slub: fix kmemcheck calls to match ksize() hints
>
> Recent use of ksize() in network stack (commit ca44ac38 : net: don't
> reallocate skb->head unless the current one hasn't the needed extra size
> or is shared) triggers kmemcheck warnings, because ksize() can return
> more space than kmemcheck is aware of.
>
> Pekka Enberg noticed SLAB+kmemcheck is doing the right thing, while SLUB
> +kmemcheck doesnt.
>
> Bugzilla reference #27212
>
> Reported-by: Christian Casteyde <casteyde.christian@free.fr>
> Suggested-by: Pekka Enberg <penberg@kernel.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: David Miller <davem@davemloft.net>
> CC: Changli Gao <xiaosuo@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> ---
> mm/slub.c | 49 ++++++++++++++++++++++++++-----------------------
> 1 file changed, 26 insertions(+), 23 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index e15aa7f..ee0aeb8 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -797,10 +797,34 @@ static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags)
> return should_failslab(s->objsize, flags, s->flags);
> }
>
> +static inline size_t slab_ksize(const struct kmem_cache *s)
> +{
> +#ifdef CONFIG_SLUB_DEBUG
> + /*
> + * Debugging requires use of the padding between object
> + * and whatever may come after it.
> + */
> + if (s->flags & (SLAB_RED_ZONE | SLAB_POISON))
> + return s->objsize;
> +
> +#endif
> + /*
> + * If we have the need to store the freelist pointer
> + * back there or track user information then we can
> + * only use the space before that information.
> + */
> + if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER))
> + return s->inuse;
> + /*
> + * Else we can use all the padding etc for the allocation
> + */
> + return s->size;
> +}
> +
> static inline void slab_post_alloc_hook(struct kmem_cache *s, gfp_t flags, void *object)
> {
> flags &= gfp_allowed_mask;
> - kmemcheck_slab_alloc(s, flags, object, s->objsize);
> + kmemcheck_slab_alloc(s, flags, object, slab_ksize(s));
> kmemleak_alloc_recursive(object, s->objsize, 1, s->flags, flags);
> }
>
> @@ -2696,7 +2720,6 @@ EXPORT_SYMBOL(__kmalloc_node);
> size_t ksize(const void *object)
> {
> struct page *page;
> - struct kmem_cache *s;
>
> if (unlikely(object == ZERO_SIZE_PTR))
> return 0;
> @@ -2707,28 +2730,8 @@ size_t ksize(const void *object)
> WARN_ON(!PageCompound(page));
> return PAGE_SIZE << compound_order(page);
> }
> - s = page->slab;
>
> -#ifdef CONFIG_SLUB_DEBUG
> - /*
> - * Debugging requires use of the padding between object
> - * and whatever may come after it.
> - */
> - if (s->flags & (SLAB_RED_ZONE | SLAB_POISON))
> - return s->objsize;
> -
> -#endif
> - /*
> - * If we have the need to store the freelist pointer
> - * back there or track user information then we can
> - * only use the space before that information.
> - */
> - if (s->flags & (SLAB_DESTROY_BY_RCU | SLAB_STORE_USER))
> - return s->inuse;
> - /*
> - * Else we can use all the padding etc for the allocation
> - */
> - return s->size;
> + return slab_ksize(page->slab);
> }
> EXPORT_SYMBOL(ksize);
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [RFC PATCH 0/5] Cache PMTU/redirects in inetpeer
From: David Miller @ 2011-02-15 5:46 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110210.150957.115925131.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 10 Feb 2011 15:09:57 -0800 (PST)
> From: David Miller <davem@davemloft.net>
> Date: Wed, 09 Feb 2011 22:12:49 -0800 (PST)
>
>> This is what I've been working on for the past several days.
>
> Just FYI I've pushed just the infrastructure bits (patches 1, 2,
> and 3) into net-next-2.6 since those have no side effects.
>
> I won't push the other two until I can do some good testing on
> them.
I've now pushed the final two patches from the original series
into net-next-2.6
Please if anyone runs into troubles, give a good bug report and I
will fix the problems as quickly as possible.
Thanks!
^ permalink raw reply
* Re: [PATCH] net: provide capability and group sets via SCM
From: David Miller @ 2011-02-15 1:49 UTC (permalink / raw)
To: casey
Cc: linux-kernel, netdev, ext-jarkko.2.sakkinen, Janne.Karhunen,
elena.reshetova
In-Reply-To: <4D51C38B.1060902@schaufler-ca.com>
From: Casey Schaufler <casey@schaufler-ca.com>
Date: Tue, 08 Feb 2011 14:28:27 -0800
>
> Subject: [PATCH] net: provide group lists and capability set via CMSG
>
> Provide the namespace converted group list of the peer
> process using the SCM mechanism. Provide the capability
> set of the peer process. The capability set is not
> namespace converted on the assumption that there is no
> such conversion available or required.
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
You can't just hit the asm-generic header, you have to also hit
all of the architectures that don't use the asm-generic header,
including sparc, powerpc, mips, s390, arm, alpha, cris, frv, h8300,
ia64, m32r, m68k, m68knommu, mn10300, parisc, and xtensa.
^ permalink raw reply
* Re: [PATCH] arp_notify: unconditionally send gratuitous ARP for NETDEV_NOTIFY_PEERS.
From: David Miller @ 2011-02-15 1:46 UTC (permalink / raw)
To: ian.campbell; +Cc: netdev
In-Reply-To: <1297446256-23917-1-git-send-email-ian.campbell@citrix.com>
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 11 Feb 2011 17:44:16 +0000
> NETDEV_NOTIFY_PEER is an explicit request by the driver to send a link
> notification while NETDEV_UP/NETDEV_CHANGEADDR generate link
> notifications as a sort of side effect.
>
> In the later cases the sysctl option is present because link
> notification events can have undesired effects e.g. if the link is
> flapping. I don't think this applies in the case of an explicit
> request from a driver.
>
> This patch makes NETDEV_NOTIFY_PEER unconditional, if preferred we
> could add a new sysctl for this case which defaults to on.
>
> This change causes Xen post-migration ARP notifications (which cause
> switches to relearn their MAC tables etc) to be sent by default.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Ok, applied, thanks.
^ permalink raw reply
* Re: [PATCH] phy/micrel: add ability to support 50MHz RMII clock on KZS8051RNL
From: David Miller @ 2011-02-15 1:38 UTC (permalink / raw)
To: baruch; +Cc: netdev, david.choi
In-Reply-To: <e426eef4b15c4e1c77981094c3c8020012aaca42.1297685030.git.baruch@tkos.co.il>
From: Baruch Siach <baruch@tkos.co.il>
Date: Mon, 14 Feb 2011 14:05:33 +0200
> Platform code can now set the MICREL_PHY_50MHZ_CLK bit of dev_flags in a fixup
> routine (registered with phy_register_fixup_for_uid()), to make the KZS8051RNL
> PHY work with 50MHz RMII reference clock.
>
> Cc: David J. Choi <david.choi@micrel.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH net-26 0/4] cxgb4vf: minor bug fixes -- revised patch set
From: David Miller @ 2011-02-15 1:37 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 14 Feb 2011 14:56:21 -0800
> [01/04]: Check driver parameters in the right place ...
> [02/04]: Behave properly when CONFIG_DEBUG_FS isn't defined ...
> [03/04]: Quiesce Virtual Interfaces on shutdown ...
> [04/04]: Use defined Mailbox Timeout
All applied, thanks.
^ permalink raw reply
* (unknown),
From: Western Union Transfer @ 2011-02-14 23:21 UTC (permalink / raw)
We have been trying to reach you since the past few days,
as my associate has helped me to send your first payment
of $7,500 USD to you as instructed by Mr. David Cameron
the United Kingdom prime minister after the last G20
meeting that was held in United Kingdom, making you one
of the beneficiaries. Here is the information below.
MONEY TRANSFER CONTROL NUMBER: 3928738492
SENDER NAME:Solomon Daniel
AMOUNT: $7,500 USD
I told him to keep sending you $7,500 USD twice a week
until the FULL payment of ($360.000 United State Dollars)
is completed.
Note a certificate will be made to change the Receiver Name as
stated by the British prime minister, send your Full Names
and your direct phone contact via Email to: Mr Gary Moore
The money will not reflect until the clearance certificate is
issue to you by the G20 committee.
contact Mr. Gary Moore for your clearance certificate.
Mr Gary Moore
E-mail:western_uniontransfer09@zbavitu.net
D/L:+44 7024018331
^ permalink raw reply
* Re: Process for subsystem maintainers to get Hyper-V code out of staging. - CORRECTED RECIPIENTS
From: Robert Hancock @ 2011-02-15 0:45 UTC (permalink / raw)
To: Hank Janssen
Cc: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, ide, KY Srinivasan, Hashir Abdi,
Mike Sterling, Haiyang Zhang, gregkh@suse.de" "
In-Reply-To: <8AFC7968D54FB448A30D8F38F259C56233F957D3@TK5EX14MBXC114.redmond.corp.microsoft.com>
On 02/14/2011 05:42 PM, Hank Janssen wrote:
>
> MY APOLOGIES-I made a typo on James email address. I corrected it and resend.
> Sorry for the double email.
>
>
> Stephen/James/David,
>
> Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
> We have been extending these drivers with additional functionality and our primary focus now
> is doing the work needed to exit the staging area.
>
> To give you some background, the following are Hyper-V specific Linux drivers:
>
> hv_vmbus The vmbus driver that is the bridge between guest and the
> host
> hv_storvsc The SCSI device driver
> hv_blkvsc The IDE driver
Given that the IDE subsystem (drivers/ide) is currently in
maintenance-only mode, and isn't used by modern distributions, you
likely want to make this a libata driver instead.
Though, from what's in current git, it's not clear to me what the HV IDE
(and SCSI) drivers are attempting to do. Is it really something that
looks like an IDE controller from the guest OS point of view? If not,
then having it as an IDE driver would be the wrong thing to do, it
should be more of a generic block driver. In that case, then, why are
there both SCSI and IDE drivers in the first place?
> hv_netvsc The network driver
>
> We think our drivers are pretty close to be reviewed by the subsystem maintainers.
>
> We have been working with Greg on hv_vmbus, and several other driver issues as it relates to
> exiting staging. And now we are looking for guidance for the other drivers.
>
> 1. Most important thing of course, did we contact the correct subsystem
> maintainers?
> i. IDE/Blkvsc David Miller
> ii. SCSI/Storvsc James Bottomley
> iii. Network/Netvsc Stephen Hemminger
> 2. What is the process to submit the code for review?
> 3. Which mailing list(s) do we need to use for the code reviews
> 4. I assume normal patch format is required?
> 5. What additional information is needed
> 6. Once they leave staging where do they need to go? Because they all
> pretty much come as a package we were thinking drivers/hyperv might
> be a good place.
>
> There are still a few outstanding items we are currently working on. But they should be
> wrapped up shortly. (There are a few remaining FIXME comments in the code we are
> cleaning up as I write this). But if possible we would like to get your feedback even
> as we are addressing the issues we currently know about.
>
> Thanks
>
> Hank.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" 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: Process for subsystem maintainers to get Hyper-V code out of staging.
From: Greg KH @ 2011-02-14 23:45 UTC (permalink / raw)
To: Hank Janssen
Cc: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, linux-ide@vger.kernel.org,
Jame.Bottomley@HansenPartnership.com, linux-scsi@vger.kernel.org,
KY Srinivasan, Hashir Abdi, Mike Sterling, Haiyang Zhang
In-Reply-To: <8AFC7968D54FB448A30D8F38F259C56233F95737@TK5EX14MBXC114.redmond.corp.microsoft.com>
On Mon, Feb 14, 2011 at 11:30:07PM +0000, Hank Janssen wrote:
>
> Stephen/James/David,
>
> Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
> We have been extending these drivers with additional functionality and our primary focus
> now is doing the work needed to exit the staging area.
>
> To give you some background, the following are Hyper-V specific Linux drivers:
>
> hv_vmbus The vmbus driver that is the bridge between guest and the
> host
> hv_storvsc The SCSI device driver
> hv_blkvsc The IDE driver
> hv_netvsc The network driver
>
> We think our drivers are pretty close to be reviewed by the subsystem maintainers.
>
> We have been working with Greg on hv_vmbus, and several other driver issues as it
> relates to exiting staging. And now we are looking for guidance for the other drivers.
>
> 1. Most important thing of course, did we contact the correct subsystem
> maintainers?
> i. IDE/Blkvsc David Miller
> ii. SCSI/Storvsc James Bottomley
> iii. Network/Netvsc Stephen Hemminger
That's what the MAINTAINERS file says, right?
> 2. What is the process to submit the code for review?
Like Documentation/SubmittingPatches shows, send patches.
> 3. Which mailing list(s) do we need to use for the code reviews
Again, MAINTAINERS shows this.
> 4. I assume normal patch format is required?
Yes.
> 5. What additional information is needed
What's normally needed.
> 6. Once they leave staging where do they need to go? Because they all
> pretty much come as a package we were thinking drivers/hyperv might
> be a good place.
That's up to the subsystem, if they want all network drivers in
drivers/net/ then they go there, same for scsi, it's up to the
maintainer.
> There are still a few outstanding items we are currently working on. But they should be
> wrapped up shortly. (There are a few remaining FIXME comments in the code we are
> cleaning up as I write this). But if possible we would like to get your feedback even as
> we are addressing the issues we currently know about.
I would wait and only ask for review _after_ you fix the things you know
about first. Otherwise it just wastes everyone's time.
thanks,
greg k-h
^ permalink raw reply
* RE: Process for subsystem maintainers to get Hyper-V code out of staging. - CORRECTED RECIPIENTS
From: Hank Janssen @ 2011-02-14 23:42 UTC (permalink / raw)
To: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, "linux-ide@vger.ke
Cc: KY Srinivasan, Hashir Abdi, Mike Sterling, Haiyang Zhang,
gregkh@suse.de
MY APOLOGIES-I made a typo on James email address. I corrected it and resend.
Sorry for the double email.
Stephen/James/David,
Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
We have been extending these drivers with additional functionality and our primary focus now
is doing the work needed to exit the staging area.
To give you some background, the following are Hyper-V specific Linux drivers:
hv_vmbus The vmbus driver that is the bridge between guest and the
host
hv_storvsc The SCSI device driver
hv_blkvsc The IDE driver
hv_netvsc The network driver
We think our drivers are pretty close to be reviewed by the subsystem maintainers.
We have been working with Greg on hv_vmbus, and several other driver issues as it relates to
exiting staging. And now we are looking for guidance for the other drivers.
1. Most important thing of course, did we contact the correct subsystem
maintainers?
i. IDE/Blkvsc David Miller
ii. SCSI/Storvsc James Bottomley
iii. Network/Netvsc Stephen Hemminger
2. What is the process to submit the code for review?
3. Which mailing list(s) do we need to use for the code reviews
4. I assume normal patch format is required?
5. What additional information is needed
6. Once they leave staging where do they need to go? Because they all
pretty much come as a package we were thinking drivers/hyperv might
be a good place.
There are still a few outstanding items we are currently working on. But they should be
wrapped up shortly. (There are a few remaining FIXME comments in the code we are
cleaning up as I write this). But if possible we would like to get your feedback even
as we are addressing the issues we currently know about.
Thanks
Hank.
^ permalink raw reply
* Process for subsystem maintainers to get Hyper-V code out of staging.
From: Hank Janssen @ 2011-02-14 23:30 UTC (permalink / raw)
To: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, "linux-ide@vger.ke
Cc: KY Srinivasan, Hashir Abdi, Mike Sterling, Haiyang Zhang,
gregkh@suse.de
Stephen/James/David,
Greetings to you all. As you might be aware, we submitted Hyper-V drivers to the kernel 2009.
We have been extending these drivers with additional functionality and our primary focus
now is doing the work needed to exit the staging area.
To give you some background, the following are Hyper-V specific Linux drivers:
hv_vmbus The vmbus driver that is the bridge between guest and the
host
hv_storvsc The SCSI device driver
hv_blkvsc The IDE driver
hv_netvsc The network driver
We think our drivers are pretty close to be reviewed by the subsystem maintainers.
We have been working with Greg on hv_vmbus, and several other driver issues as it
relates to exiting staging. And now we are looking for guidance for the other drivers.
1. Most important thing of course, did we contact the correct subsystem
maintainers?
i. IDE/Blkvsc David Miller
ii. SCSI/Storvsc James Bottomley
iii. Network/Netvsc Stephen Hemminger
2. What is the process to submit the code for review?
3. Which mailing list(s) do we need to use for the code reviews
4. I assume normal patch format is required?
5. What additional information is needed
6. Once they leave staging where do they need to go? Because they all
pretty much come as a package we were thinking drivers/hyperv might
be a good place.
There are still a few outstanding items we are currently working on. But they should be
wrapped up shortly. (There are a few remaining FIXME comments in the code we are
cleaning up as I write this). But if possible we would like to get your feedback even as
we are addressing the issues we currently know about.
Thanks
Hank.
^ permalink raw reply
* Re: [RFC PATCH V2 0/5] macvtap TX zero copy between guest and host kernel
From: Shirley Ma @ 2011-02-14 23:06 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Avi Kivity, Arnd Bergmann, xiaohui.xin, netdev, kvm, linux-kernel
In-Reply-To: <20110214130957.GA3128@redhat.com>
On Mon, 2011-02-14 at 15:09 +0200, Michael S. Tsirkin wrote:
> What's the status here? Since there are core net changes, we'll need
> to
> see the final version soon if it's to appear in 2.6.39.
I am updating the patch and retesting it for the new kernel. I am trying
to understand why zero copy patch caused small message size guest exits
doubled.
> Could the problem be related to the patch
> virtio_net: Add schedule check to napi_enable call
> ?
Not sure, I will retest w/i this patch.
> Also, I expect there should be driver patches for some
> devices? Where are they?
Yes, a NET_F_ZEROCOPY... flag is introduced for the device we we want to
support zero copy.
Thanks
Shirley
^ permalink raw reply
* [PATCH net-26 3/4] cxgb4vf: Quiesce Virtual Interfaces on shutdown ...
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
When a Virtual Machine is rebooted, KVM currently fails to issue a Function
Level Reset against any "Attached PCI Devices" (AKA "PCI Passthrough"). In
addition to leaving the attached device in a random state in the next booted
kernel (which sort of violates the entire idea of a reboot reseting hardware
state), this leaves our peer thinking that the link is still up. (Note that
a bug has been filed with the KVM folks, #25332, but there's been no
response on that as of yet.) So, we add a "->shutdown()" method for the
Virtual Function PCI Device to handle administrative shutdowns like a
reboot.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 41 ++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 2be1088..6aad64d 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2862,6 +2862,46 @@ static void __devexit cxgb4vf_pci_remove(struct pci_dev *pdev)
}
/*
+ * "Shutdown" quiesce the device, stopping Ingress Packet and Interrupt
+ * delivery.
+ */
+static void __devexit cxgb4vf_pci_shutdown(struct pci_dev *pdev)
+{
+ struct adapter *adapter;
+ int pidx;
+
+ adapter = pci_get_drvdata(pdev);
+ if (!adapter)
+ return;
+
+ /*
+ * Disable all Virtual Interfaces. This will shut down the
+ * delivery of all ingress packets into the chip for these
+ * Virtual Interfaces.
+ */
+ for_each_port(adapter, pidx) {
+ struct net_device *netdev;
+ struct port_info *pi;
+
+ if (!test_bit(pidx, &adapter->registered_device_map))
+ continue;
+
+ netdev = adapter->port[pidx];
+ if (!netdev)
+ continue;
+
+ pi = netdev_priv(netdev);
+ t4vf_enable_vi(adapter, pi->viid, false, false);
+ }
+
+ /*
+ * Free up all Queues which will prevent further DMA and
+ * Interrupts allowing various internal pathways to drain.
+ */
+ t4vf_free_sge_resources(adapter);
+}
+
+/*
* PCI Device registration data structures.
*/
#define CH_DEVICE(devid, idx) \
@@ -2894,6 +2934,7 @@ static struct pci_driver cxgb4vf_driver = {
.id_table = cxgb4vf_pci_tbl,
.probe = cxgb4vf_pci_probe,
.remove = __devexit_p(cxgb4vf_pci_remove),
+ .shutdown = __devexit_p(cxgb4vf_pci_shutdown),
};
/*
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-26 2/4] cxgb4vf: Behave properly when CONFIG_DEBUG_FS isn't defined ...
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
When CONFIG_DEBUG_FS we get "ERR_PTR()"s back from the debugfs routines
instead of NULL. Use the right predicates to check for this.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 072b64e..2be1088 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2040,7 +2040,7 @@ static int __devinit setup_debugfs(struct adapter *adapter)
{
int i;
- BUG_ON(adapter->debugfs_root == NULL);
+ BUG_ON(IS_ERR_OR_NULL(adapter->debugfs_root));
/*
* Debugfs support is best effort.
@@ -2061,7 +2061,7 @@ static int __devinit setup_debugfs(struct adapter *adapter)
*/
static void cleanup_debugfs(struct adapter *adapter)
{
- BUG_ON(adapter->debugfs_root == NULL);
+ BUG_ON(IS_ERR_OR_NULL(adapter->debugfs_root));
/*
* Unlike our sister routine cleanup_proc(), we don't need to remove
@@ -2700,11 +2700,11 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
/*
* Set up our debugfs entries.
*/
- if (cxgb4vf_debugfs_root) {
+ if (!IS_ERR_OR_NULL(cxgb4vf_debugfs_root)) {
adapter->debugfs_root =
debugfs_create_dir(pci_name(pdev),
cxgb4vf_debugfs_root);
- if (adapter->debugfs_root == NULL)
+ if (IS_ERR_OR_NULL(adapter->debugfs_root))
dev_warn(&pdev->dev, "could not create debugfs"
" directory");
else
@@ -2759,7 +2759,7 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
*/
err_free_debugfs:
- if (adapter->debugfs_root) {
+ if (!IS_ERR_OR_NULL(adapter->debugfs_root)) {
cleanup_debugfs(adapter);
debugfs_remove_recursive(adapter->debugfs_root);
}
@@ -2828,7 +2828,7 @@ static void __devexit cxgb4vf_pci_remove(struct pci_dev *pdev)
/*
* Tear down our debugfs entries.
*/
- if (adapter->debugfs_root) {
+ if (!IS_ERR_OR_NULL(adapter->debugfs_root)) {
cleanup_debugfs(adapter);
debugfs_remove_recursive(adapter->debugfs_root);
}
@@ -2916,12 +2916,12 @@ static int __init cxgb4vf_module_init(void)
/* Debugfs support is optional, just warn if this fails */
cxgb4vf_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
- if (!cxgb4vf_debugfs_root)
+ if (IS_ERR_OR_NULL(cxgb4vf_debugfs_root))
printk(KERN_WARNING KBUILD_MODNAME ": could not create"
" debugfs entry, continuing\n");
ret = pci_register_driver(&cxgb4vf_driver);
- if (ret < 0)
+ if (ret < 0 && !IS_ERR_OR_NULL(cxgb4vf_debugfs_root))
debugfs_remove(cxgb4vf_debugfs_root);
return ret;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-26 1/4] cxgb4vf: Check driver parameters in the right place ...
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
Check module parameter validity in the module initialization routine instead
of the PCI Device Probe routine.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 56166ae..072b64e 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2489,17 +2489,6 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
struct net_device *netdev;
/*
- * Vet our module parameters.
- */
- if (msi != MSI_MSIX && msi != MSI_MSI) {
- dev_err(&pdev->dev, "bad module parameter msi=%d; must be %d"
- " (MSI-X or MSI) or %d (MSI)\n", msi, MSI_MSIX,
- MSI_MSI);
- err = -EINVAL;
- goto err_out;
- }
-
- /*
* Print our driver banner the first time we're called to initialize a
* device.
*/
@@ -2802,7 +2791,6 @@ err_release_regions:
err_disable_device:
pci_disable_device(pdev);
-err_out:
return err;
}
@@ -2915,6 +2903,17 @@ static int __init cxgb4vf_module_init(void)
{
int ret;
+ /*
+ * Vet our module parameters.
+ */
+ if (msi != MSI_MSIX && msi != MSI_MSI) {
+ printk(KERN_WARNING KBUILD_MODNAME
+ ": bad module parameter msi=%d; must be %d"
+ " (MSI-X or MSI) or %d (MSI)\n",
+ msi, MSI_MSIX, MSI_MSI);
+ return -EINVAL;
+ }
+
/* Debugfs support is optional, just warn if this fails */
cxgb4vf_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
if (!cxgb4vf_debugfs_root)
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-26 0/4] cxgb4vf: minor bug fixes -- revised patch set
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem
This is the same as the previous patch set but with the unacceptable patch
removed. Let me know if there's anything else I should do. Thanks and
sorry for not know the rules about that unacceptable patch.
[01/04]: Check driver parameters in the right place ...
[02/04]: Behave properly when CONFIG_DEBUG_FS isn't defined ...
[03/04]: Quiesce Virtual Interfaces on shutdown ...
[04/04]: Use defined Mailbox Timeout
drivers/net/cxgb4vf/cxgb4vf_main.c | 80 +++++++++++++++++++++++++++---------
drivers/net/cxgb4vf/t4vf_hw.c | 2 +-
2 files changed, 61 insertions(+), 21 deletions(-)
^ permalink raw reply
* [PATCH net-26 4/4] cxgb4vf: Use defined Mailbox Timeout
From: Casey Leedom @ 2011-02-14 22:56 UTC (permalink / raw)
To: netdev; +Cc: davem, Casey Leedom
In-Reply-To: <1297724185-27452-1-git-send-email-leedom@chelsio.com>
VF Driver should use mailbox command timeout specified in t4fw_interface.h
rather than hard-coded value of 500ms.
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/cxgb4vf/t4vf_hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index 0f51c80..192db22 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -171,7 +171,7 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
delay_idx = 0;
ms = delay[0];
- for (i = 0; i < 500; i += ms) {
+ for (i = 0; i < FW_CMD_MAX_TIMEOUT; i += ms) {
if (sleep_ok) {
ms = delay[delay_idx];
if (delay_idx < ARRAY_SIZE(delay) - 1)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH][trivial] Batman: Remove two duplicate includes.
From: Sven Eckelmann @ 2011-02-14 22:44 UTC (permalink / raw)
To: Jesper Juhl
Cc: trivial-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Simon Wunderlich,
Marek Lindner, David S. Miller
In-Reply-To: <alpine.LNX.2.00.1102142335331.4530-h2p7t3/P30RzeRGmFJ5qR7ZzlVVXadcDXqFh9Ls21Oc@public.gmane.org>
[-- Attachment #1: Type: Text/Plain, Size: 189 bytes --]
On Monday 14 February 2011 23:38:18 Jesper Juhl wrote:
> Remove duplicate inclusion of "send.h" and "routing.h" from
> net/batman-adv/soft-interface.c
Applied, thanks
Best regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH][trivial] Batman: Remove two duplicate includes.
From: Jesper Juhl @ 2011-02-14 22:38 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: trivial-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Simon Wunderlich,
Marek Lindner, David S. Miller
Remove duplicate inclusion of "send.h" and "routing.h" from net/batman-adv/soft-interface.c
Patch is against linux-next as of today.
Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
---
soft-interface.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index bd088f8..7e37077 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -29,14 +29,12 @@
#include "hash.h"
#include "gateway_common.h"
#include "gateway_client.h"
-#include "send.h"
#include "bat_sysfs.h"
#include <linux/slab.h>
#include <linux/ethtool.h>
#include <linux/etherdevice.h>
#include <linux/if_vlan.h>
#include "unicast.h"
-#include "routing.h"
static int bat_get_settings(struct net_device *dev, struct ethtool_cmd *cmd);
--
Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
^ permalink raw reply related
* Re: [PATCH net-26 1/5] cxgb4vf: Virtual Interfaces are always up ...
From: David Miller @ 2011-02-14 22:34 UTC (permalink / raw)
To: leedom; +Cc: netdev
In-Reply-To: <201102141431.32535.leedom@chelsio.com>
From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 14 Feb 2011 14:31:32 -0800
> | From: Casey Leedom <leedom@chelsio.com>
> | Date: Monday, February 14, 2011 11:13 am
> |
> | | No driver specific module parameters! Add something generic and common
> | | so other drivers can use it too.
> | |
> | | Otherwise every user has to learn a different way to control this
> | | attribute, depending upon the device type, which is rediculious.
> | |
> | | How many times do we have to tell driver authors this?
> |
> | Sorry. I wasn't aware of this rule. My bad. Is this writeen down
> | somewhere under Documentation? I'm not being snarky. I really would like
> | to know so I can read through the general ground rules and avoid making
> | more mistakes in the future.
> |
> | As for a generic mechanism, what's the preferred way of doing this? A
> | new ethtool flag? Sorry for being a doofus here, I'm happy to follow
> | whatever the accepted standard is. Thanks for your time and patience.
>
> Also, I assume then the the entire patch series is now rejected, right? And
> that I should resubmit the patch series without the unacceptable module
> parameter, right? I'm just trying to figure out what I need to do next.
You need to resubmit the whole series, because changing an earlier
patch causes the subsequent ones to have, at a minimum, offsets which
GIT apply will reject.
^ permalink raw reply
* Re: [PATCH net-26 1/5] cxgb4vf: Virtual Interfaces are always up ...
From: Casey Leedom @ 2011-02-14 22:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <201102141113.58068.leedom@chelsio.com>
| From: Casey Leedom <leedom@chelsio.com>
| Date: Monday, February 14, 2011 11:13 am
|
| | No driver specific module parameters! Add something generic and common
| | so other drivers can use it too.
| |
| | Otherwise every user has to learn a different way to control this
| | attribute, depending upon the device type, which is rediculious.
| |
| | How many times do we have to tell driver authors this?
|
| Sorry. I wasn't aware of this rule. My bad. Is this writeen down
| somewhere under Documentation? I'm not being snarky. I really would like
| to know so I can read through the general ground rules and avoid making
| more mistakes in the future.
|
| As for a generic mechanism, what's the preferred way of doing this? A
| new ethtool flag? Sorry for being a doofus here, I'm happy to follow
| whatever the accepted standard is. Thanks for your time and patience.
Also, I assume then the the entire patch series is now rejected, right? And
that I should resubmit the patch series without the unacceptable module
parameter, right? I'm just trying to figure out what I need to do next.
Thanks.
Casey
^ permalink raw reply
* Re: [PATCH -next] PCI: fix tlan build when CONFIG_PCI is not enabled
From: Sakari Ailus @ 2011-02-14 22:02 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, netdev, linux-pci, linux-next, LKML, davem,
Jesse Barnes
In-Reply-To: <4D599F60.4010800@iki.fi>
Sakari Ailus wrote:
> Randy Dunlap wrote:
>> From: Randy Dunlap<randy.dunlap@oracle.com>
>>
>> When CONFIG_PCI is not enabled, tlan.c has a build error:
>> drivers/net/tlan.c:503: error: implicit declaration of function 'pci_wake_from_d3'
>>
>> so add an inline function stub for this function to pci.h when
>> PCI is not enabled, similar to other stubbed PCI functions.
>>
>> Signed-off-by: Randy Dunlap<randy.dunlap@oracle.com>
>> Cc: Sakari Ailus<sakari.ailus@iki.fi>
>
> Hi Randy,
>
> I think this issue in tlan driver was caused by my recent patch which
> added the suspend/resume support to tlan:
>
> <URL:http://marc.info/?l=linux-netdev&m=129564436110754&w=3>
>
> There apparently are tlan cards which are EISA (not PCI) which I forgot
> when writing the patch. The suspend/resume has been only tested with PCI
> as I have no EISA bus (let alone EISA tlan card!).
Right; so I suppose there's no PM support in EISA anyway. Other pci
functions appear to be no-ops when CONFIG_PCI isn't defined so this
patch seems right to me --- and no changes are needed in the tlan driver.
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
--
Sakari Ailus
sakari.ailus@iki.fi
^ permalink raw reply
* Re: [PATCH] pch_gbe: Fix the MAC Address load issue.
From: David Miller @ 2011-02-14 21:37 UTC (permalink / raw)
To: toshiharu-linux
Cc: netdev, tomoya-linux, linux-kernel, qi.wang, yong.y.wang,
andrew.chih.howe.khor, joel.clark, kok.howg.ewe
In-Reply-To: <4D58ED2A.9050706@dsn.okisemi.com>
From: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date: Mon, 14 Feb 2011 17:51:54 +0900
> With the specification of hardware,
> the processing at the time of driver starting was modified.
>
> This device write automatically the MAC address read from serial ROM
> into a MAC Adress1A/1B register at the time of power on reset.
> However, when stable clock is not supplied,
> the writing of MAC Adress1A/1B register may not be completed.
> In this case, it is necessary to load MAC address to MAC Address1A/1B register
> by the MAC Address1 load register.
>
> This patch always does the above processing,
> in order not to be dependent on system environment.
>
> Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Applied.
^ permalink raw reply
* Re: [PATCH] [ROSE] AX25 packet routing improvement
From: David Miller @ 2011-02-14 21:35 UTC (permalink / raw)
To: bernard.pidoux; +Cc: netdev, ralf, f6bvp
In-Reply-To: <4D596BC9.4030509@upmc.fr>
From: Bernard Pidoux <bernard.pidoux@upmc.fr>
Date: Mon, 14 Feb 2011 18:52:09 +0100
> [PATCH] [ROSE] [AX25] finding routes simplification
>
> With previous patch, rose_get_neigh() routine
> investigates the full list of neighbor nodes
> until it finds or not an already connected node whether
> it is called locally or through a level 3 transit frame.
> If no routes are opened through an adjacent connected node
> then a classical connect request is attempted.
>
> Then there is no more reason for an extra loop such
> as the one removed by this patch.
>
> Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Also applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH] [ROSE] packet routing improvement
From: David Miller @ 2011-02-14 21:33 UTC (permalink / raw)
To: bpidoux; +Cc: netdev, ralf, f6bvp
In-Reply-To: <4D596B25.9080309@free.fr>
From: Bernard Pidoux <bpidoux@free.fr>
Date: Mon, 14 Feb 2011 18:49:25 +0100
> [PATCH] [ROSE] rose AX25 packet routing improvement
>
> FPAC AX25 packet application is using Linux kernel ROSE
> routing skills in order to connect or send packets to remote stations
> knowing their ROSE address via a network of interconnected nodes.
>
> Each FPAC node has a ROSE routing table that Linux ROSE module is
> looking at each time a ROSE frame is relayed by the node or when
> a connect request to a neighbor node is received.
>
> A previous patch improved the system time response by looking at
> already established routes each time the system was looking for a
> route to relay a frame. If a neighbor node routing the destination
> address was already connected, then the frame would be sent
> through him. If not, a connection request would be issued.
>
> The present patch extends the same routing capability to a connect
> request asked by a user locally connected into an FPAC node.
> Without this patch, a connect request was not well handled unless it
> was directed to an immediate connected neighbor of the local node.
>
> Implemented at a number of ROSE FPAC node stations, the present patch
> improved dramatically FPAC ROSE routing time response and efficiency.
>
> Signed-off-by: Bernard Pidoux <f6bvp@free.fr>
Applied to net-next-2.6
^ 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