* Re: [net-next] net: Provide details on watchdog timeout.
From: David Miller @ 2010-08-09 20:08 UTC (permalink / raw)
To: shemminger; +Cc: greearb, netdev
In-Reply-To: <20100809152820.26dbffc1@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 9 Aug 2010 15:28:20 -0400
> On Mon, 9 Aug 2010 12:16:41 -0700
> Ben Greear <greearb@candelatech.com> wrote:
>
>> This also makes it printed under net_ratelimit instead
>> of WARN_ON_ONCE. The backtrace never helped me much.
>>
>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>
> Please don't remove the WARN_ because it is used by oops.kernel.org
> automated tracking.
Yes, please don't change this, there are automated tools that
know about what this thing spits out and yes the backtrace
needs to be there.
^ permalink raw reply
* Re: [net-next] net: Provide details on watchdog timeout.
From: David Miller @ 2010-08-09 20:10 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1281383954-23765-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Mon, 9 Aug 2010 12:59:14 -0700
> This keeps the WARN_ON but will also log normal kernel messages
> after the WARN_ON logic has happened once.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
I think this warning is fine as-is.
^ permalink raw reply
* Re: [net-next] net: Provide details on watchdog timeout.
From: Ben Greear @ 2010-08-09 20:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100809.131017.112606336.davem@davemloft.net>
On 08/09/2010 01:10 PM, David Miller wrote:
> From: Ben Greear<greearb@candelatech.com>
> Date: Mon, 9 Aug 2010 12:59:14 -0700
>
>> This keeps the WARN_ON but will also log normal kernel messages
>> after the WARN_ON logic has happened once.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>
> I think this warning is fine as-is.
Ok, thanks for looking.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Benjamin LaHaise @ 2010-08-09 21:03 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ben Greear, Eric Dumazet, Octavian Purdila, netdev, Cosmin Ratiu
In-Reply-To: <m1tyn3v9pp.fsf@fess.ebiederm.org>
On Mon, Aug 09, 2010 at 12:59:14PM -0700, Eric W. Biederman wrote:
> The network device deletion batching code has gone in, which is
> a big help, as have some dev_put deletions, so we hit that 250ms
> delay less often.
I'll see how much that helps. Odds are I'm going to have to move the
device deletion into a separate thread. That should give me a natural
boundary to queue up deletions at, which should fix the tunnel-flap and
partial tunnel-flap cases I'm worried about. At some point I have to
figure out how to get my API needs met by the in-kernel L2TP code, but
that's a worry for another day.
> sysfs feature wise has now settled down, and the regressions have all
> been stamped out so now should be a good time to work on scaling.
>
> I still have some preliminary patches in my tree, that I will dig up
> as time goes by.
I should have some time this evening to run a few tests, and hopefully can
post some results.
-ben
^ permalink raw reply
* Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
From: Eric W. Biederman @ 2010-08-09 21:17 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Ben Greear, Eric Dumazet, Octavian Purdila, netdev, Cosmin Ratiu
In-Reply-To: <20100809210311.GW30010@kvack.org>
Benjamin LaHaise <bcrl@lhnet.ca> writes:
> On Mon, Aug 09, 2010 at 12:59:14PM -0700, Eric W. Biederman wrote:
>> The network device deletion batching code has gone in, which is
>> a big help, as have some dev_put deletions, so we hit that 250ms
>> delay less often.
>
> I'll see how much that helps. Odds are I'm going to have to move the
> device deletion into a separate thread. That should give me a natural
> boundary to queue up deletions at, which should fix the tunnel-flap and
> partial tunnel-flap cases I'm worried about. At some point I have to
> figure out how to get my API needs met by the in-kernel L2TP code, but
> that's a worry for another day.
In case it is useful, if you delete a network namespace in general
all of the network device deletions can be batched.
Eric
^ permalink raw reply
* Re: [RFC] [PATCH] Don't destroy TCP sockets twice
From: Herbert Xu @ 2010-08-09 21:30 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <20100806110511.GA16448@basil.fritz.box>
Andi Kleen <andi@firstfloor.org> wrote:
>
> While working on something else I noticed that tcp_v4/6_destroy_sock()
> can get called twice on a socket. This happens because when a reset or
> similar happens tcp_done destroys the connection socket state, and
> then eventually when the socket is released it is destroyed again.
I'm still having problems understanding why you're getting a call
to send a FIN after tcp_done. This shouldn't happen at all because
tcp_done moves the socket to the TCP_CLOSE state, where FINs should
not be sent.
Can you clarify on how we can reproduce this problem in the
upstream kernel?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Yet another bridge netfilter crash
From: Herbert Xu @ 2010-08-09 21:42 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Stephen Hemminger, netdev
In-Reply-To: <4C599A6A.6050202@trash.net>
On Wed, Aug 04, 2010 at 06:50:50PM +0200, Patrick McHardy wrote:
.
> >> Until we come up with something better the best fix seems to
> >> be to perform the device lookup based on the iif.
> >
> > I don't think we can as the iif will point to the bridge device.
> > The physindev contains the original physical device where the
> > packet came in.
>
> If it originally points to the bridge device, there doesn't
> seem anything wrong with the device pointing to the bridge
> device after reassembly. Am I missing something?
It's there so that netfilter rules can filter based on the original
inbound interface.
If you set it to the bridge then those rules won't work anymore.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4/6] au1000-eth: fix bad printk usages
From: Joe Perches @ 2010-08-09 22:17 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, David Miller
In-Reply-To: <201008092203.41338.florian@openwrt.org>
On Mon, 2010-08-09 at 22:03 +0200, Florian Fainelli wrote:
> Use pr_(info|err) and pr_cont where required instead of calls to printk.
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> ---
> diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
> index 9a0515d..f8f1f5e 100644
> --- a/drivers/net/au1000_eth.c
> +++ b/drivers/net/au1000_eth.c
> @@ -732,24 +732,25 @@ static int au1000_rx(struct net_device *dev)
> netif_rx(skb); /* pass the packet to upper layers */
> } else {
> if (au1000_debug > 4) {
> + pr_err("rx_error: ");
This should be:
pr_err("rx_error(s):");
> if (status & RX_MISSED_FRAME)
> - printk("rx miss\n");
> + pr_cont("rx miss\n");
These blocks should be "pr_cont(" value");
with a leading space and without the "\n"
> if (status & RX_WDOG_TIMER)
> - printk("rx wdog\n");
> + pr_cont("rx wdog\n");
[etc]
> if (status & RX_U_CNTRL_FRAME)
> - printk("rx u control frame\n");
> + pr_cont("rx u control frame\n");
and finally a pr_cont("\n");
It'd also be good to add
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
before any #include
^ permalink raw reply
* [PATCH 1/2] pkt_sched: sch_sfq: Add dummy unbind_tcf and put handles. Was: [PATCH] sfq: add dummy bind/unbind handles
From: Jarek Poplawski @ 2010-08-09 22:18 UTC (permalink / raw)
To: Franchoze Eric; +Cc: David Miller, shemminger, netdev
Franchoze Eric wrote, On 08/09/2010 05:01 PM:
>
> 08.08.10, 11:04, "Jarek Poplawski" <jarkao2@gmail.com>:
>
>> David Miller wrote, On 08.08.2010 07:45:
...
>> > Agreed, I can't see a way that unbind can ever be invoked
>> > if the bind call always returns zero.
>>
>> To tell the truth, I think unbind should be implemented anyway,
>> just for consistency, safety, and easier verification. But, looking
>> at a similar case of .get and .put in the same driver, Patrick
>> seemed to do it purposely, so I expected some discussion about the
>> rules yet, and made it minimal to ease merging to older kernels.
...
>
> As for me it's better to add unbind now that get unexpected null derefance in future with API changing...
Here is my proposal which adds both unbind and put, plus some early
verification (the next patch). Of course, there is still Stephen's
alternative with later checks.
Jarek P.
----------------->
Add dummy .unbind_tcf and .put qdisc class ops for easier verification.
(All other schedulers have it like this.)
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 534f332..d8e0ae5 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -519,6 +519,10 @@ static unsigned long sfq_bind(struct Qdisc *sch, unsigned long parent,
return 0;
}
+static void sfq_put(struct Qdisc *q, unsigned long cl)
+{
+}
+
static struct tcf_proto **sfq_find_tcf(struct Qdisc *sch, unsigned long cl)
{
struct sfq_sched_data *q = qdisc_priv(sch);
@@ -572,8 +576,10 @@ static void sfq_walk(struct Qdisc *sch, struct qdisc_walker *arg)
static const struct Qdisc_class_ops sfq_class_ops = {
.get = sfq_get,
+ .put = sfq_put,
.tcf_chain = sfq_find_tcf,
.bind_tcf = sfq_bind,
+ .unbind_tcf = sfq_put,
.dump = sfq_dump_class,
.dump_stats = sfq_dump_class_stats,
.walk = sfq_walk,
^ permalink raw reply related
* [PATCH 2/2] pkt_sched: Add some basic qdisc class ops verification. Was: [PATCH] sfq: add dummy bind/unbind handles
From: Jarek Poplawski @ 2010-08-09 22:18 UTC (permalink / raw)
To: Franchoze Eric; +Cc: David Miller, shemminger, netdev
Verify in register_qdisc() some basic qdisc class handlers are present.
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index b9e8c3b..8ed2f56 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -150,22 +150,34 @@ int register_qdisc(struct Qdisc_ops *qops)
if (qops->enqueue == NULL)
qops->enqueue = noop_qdisc_ops.enqueue;
if (qops->peek == NULL) {
- if (qops->dequeue == NULL) {
+ if (qops->dequeue == NULL)
qops->peek = noop_qdisc_ops.peek;
- } else {
- rc = -EINVAL;
- goto out;
- }
+ else
+ goto out_einval;
}
if (qops->dequeue == NULL)
qops->dequeue = noop_qdisc_ops.dequeue;
+ if (qops->cl_ops) {
+ const struct Qdisc_class_ops *cops = qops->cl_ops;
+
+ if (!(cops->get && cops->put))
+ goto out_einval;
+
+ if (cops->tcf_chain && !(cops->bind_tcf && cops->unbind_tcf))
+ goto out_einval;
+ }
+
qops->next = NULL;
*qp = qops;
rc = 0;
out:
write_unlock(&qdisc_mod_lock);
return rc;
+
+out_einval:
+ rc = -EINVAL;
+ goto out;
}
EXPORT_SYMBOL(register_qdisc);
^ permalink raw reply related
* [PATCH] usbnet: rx_submit() should return an error code.
From: Elly Jones @ 2010-08-09 22:37 UTC (permalink / raw)
To: Oliver Neukum
Cc: Alan Stern, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA, USB list,
Jason Glasgow
This patch makes rx_submit() return an error code, and makes some call sites
that care check the return value. This is important because it lets us properly
handle cases where the device isn't ready to handle URB submissions (e.g., when
it is autosuspended under some drivers); previously, we would attempt and fail
to submit URBs and reschedule ourselves to try and fail again. This patch is
against Linus's 2.6 repo commit 45d7f32c7a43cbb9592886d38190e379e2eb2226.
Signed-Off-By: Elizabeth Jones <ellyjones-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
drivers/net/usb/usbnet.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 3b03794..82a992a 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -315,7 +315,7 @@ EXPORT_SYMBOL_GPL(usbnet_defer_kevent);
static void rx_complete (struct urb *urb);
-static void rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
+static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
{
struct sk_buff *skb;
struct skb_data *entry;
@@ -327,7 +327,7 @@ static void rx_submit (struct usbnet *dev, struct
urb *urb, gfp_t flags)
netif_dbg(dev, rx_err, dev->net, "no rx skb\n");
usbnet_defer_kevent (dev, EVENT_RX_MEMORY);
usb_free_urb (urb);
- return;
+ return -ENOMEM;
}
skb_reserve (skb, NET_IP_ALIGN);
@@ -357,6 +357,9 @@ static void rx_submit (struct usbnet *dev, struct
urb *urb, gfp_t flags)
netif_dbg(dev, ifdown, dev->net, "device gone\n");
netif_device_detach (dev->net);
break;
+ case -EHOSTUNREACH:
+ retval = -ENOLINK;
+ break;
default:
netif_dbg(dev, rx_err, dev->net,
"rx submit, %d\n", retval);
@@ -374,6 +377,7 @@ static void rx_submit (struct usbnet *dev, struct
urb *urb, gfp_t flags)
dev_kfree_skb_any (skb);
usb_free_urb (urb);
}
+ return retval;
}
@@ -912,6 +916,7 @@ fail_halt:
/* tasklet could resubmit itself forever if memory is tight */
if (test_bit (EVENT_RX_MEMORY, &dev->flags)) {
struct urb *urb = NULL;
+ int resched = 1;
if (netif_running (dev->net))
urb = usb_alloc_urb (0, GFP_KERNEL);
@@ -922,10 +927,12 @@ fail_halt:
status = usb_autopm_get_interface(dev->intf);
if (status < 0)
goto fail_lowmem;
- rx_submit (dev, urb, GFP_KERNEL);
+ if (rx_submit (dev, urb, GFP_KERNEL) == -ENOLINK)
+ resched = 0;
usb_autopm_put_interface(dev->intf);
fail_lowmem:
- tasklet_schedule (&dev->bh);
+ if (resched)
+ tasklet_schedule (&dev->bh);
}
}
@@ -1176,7 +1183,9 @@ static void usbnet_bh (unsigned long param)
for (i = 0; i < 10 && dev->rxq.qlen < qlen; i++) {
urb = usb_alloc_urb (0, GFP_ATOMIC);
if (urb != NULL)
- rx_submit (dev, urb, GFP_ATOMIC);
+ if (rx_submit (dev, urb, GFP_ATOMIC)
+ == -ENOLINK)
+ return;
}
if (temp != dev->rxq.qlen)
netif_dbg(dev, link, dev->net,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Yet another bridge netfilter crash
From: Changli Gao @ 2010-08-09 22:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: Patrick McHardy, Stephen Hemminger, netdev
In-Reply-To: <20100809214254.GA23824@gondor.apana.org.au>
On Tue, Aug 10, 2010 at 5:42 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Aug 04, 2010 at 06:50:50PM +0200, Patrick McHardy wrote:
> .
>> >> Until we come up with something better the best fix seems to
>> >> be to perform the device lookup based on the iif.
>> >
>> > I don't think we can as the iif will point to the bridge device.
>> > The physindev contains the original physical device where the
>> > packet came in.
>>
>> If it originally points to the bridge device, there doesn't
>> seem anything wrong with the device pointing to the bridge
>> device after reassembly. Am I missing something?
>
> It's there so that netfilter rules can filter based on the original
> inbound interface.
>
> If you set it to the bridge then those rules won't work anymore.
>
How about always using the skb->nf_bridge of the skb last received in
a defrag queue as the nf_bridge of the final defraged skb? I have
posted a patch doing such thing.
http://patchwork.ozlabs.org/patch/60904/
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [PATCH 3/3] phy.c: fix kernel-doc warnings
From: Randy Dunlap @ 2010-08-09 23:41 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix phy.c kernel-doc notation:
Warning(drivers/net/phy/phy.c:313): No description found for parameter 'ifr'
Warning(drivers/net/phy/phy.c:313): Excess function parameter 'mii_data' description in 'phy_mii_ioctl'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.35-git8.orig/drivers/net/phy/phy.c
+++ linux-2.6.35-git8/drivers/net/phy/phy.c
@@ -301,7 +301,7 @@ EXPORT_SYMBOL(phy_ethtool_gset);
/**
* phy_mii_ioctl - generic PHY MII ioctl interface
* @phydev: the phy_device struct
- * @mii_data: MII ioctl data
+ * @ifr: &struct ifreq for socket ioctl's
* @cmd: ioctl cmd to execute
*
* Note that this function is currently incompatible with the
^ permalink raw reply
* [PATCH 1/3] etherdevice.h: fix kernel-doc typo
From: Randy Dunlap @ 2010-08-09 23:40 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix etherdevice.h parameter name typo in kernel-doc:
Warning(include/linux/etherdevice.h:138): No description found for parameter 'hwaddr'
Warning(include/linux/etherdevice.h:138): Excess function parameter 'addr' description in 'dev_hw_addr_random'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/linux/etherdevice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.35-git8.orig/include/linux/etherdevice.h
+++ linux-2.6.35-git8/include/linux/etherdevice.h
@@ -129,7 +129,7 @@ static inline void random_ether_addr(u8
/**
* dev_hw_addr_random - Create random MAC and set device flag
* @dev: pointer to net_device structure
- * @addr: Pointer to a six-byte array containing the Ethernet address
+ * @hwaddr: Pointer to a six-byte array containing the Ethernet address
*
* Generate random MAC to be used by a device and set addr_assign_type
* so the state can be read by sysfs and be used by udev.
^ permalink raw reply
* i386 allmodconfig, current mainline
From: Andrew Morton @ 2010-08-09 23:43 UTC (permalink / raw)
To: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis
Cc: linux-kernel, netdev, linux-wireless, x86, linux-rdma
Guys. What's goin' on out there?
drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
drivers/power/olpc_battery.c:387: warning: initialization from incompatible pointer type
make[2]: *** [drivers/power/olpc_battery.o] Error 1
make[1]: *** [drivers/power] Error 2
drivers/mtd/maps/gpio-addr-flash.c: In function 'gpio_flash_probe':
drivers/mtd/maps/gpio-addr-flash.c:212: warning: cast to pointer from integer of different size
drivers/mtd/maps/gpio-addr-flash.c:224: warning: cast to pointer from integer of different size
drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type
drivers/net/wan/farsync.c: In function 'fst_intr_rx':
drivers/net/wan/farsync.c:1312: warning: cast to pointer from integer of different size
drivers/net/wan/farsync.c: In function 'do_bottom_half_tx':
drivers/net/wan/farsync.c:1407: warning: cast to pointer from integer of different size
fs/squashfs/xattr.c:37: warning: 'squashfs_xattr_handler' declared inline after being called
fs/squashfs/xattr.c:37: warning: previous declaration of 'squashfs_xattr_handler' was here
drivers/net/wireless/ipw2x00/ipw2100.c: In function 'ipw2100_tx_send_commands':
drivers/net/wireless/ipw2x00/ipw2100.c:3063: warning: cast to pointer from integer of different size
In file included from drivers/platform/x86/intel_scu_ipc.c:26:
/usr/src/devel/arch/x86/include/asm/mrst.h:14: warning: 'struct sfi_table_header' declared inside parameter list
/usr/src/devel/arch/x86/include/asm/mrst.h:14: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_alloc_fast_reg_page_list':
drivers/infiniband/hw/nes/nes_verbs.c:477: warning: cast to pointer from integer of different size
drivers/infiniband/hw/nes/nes_verbs.c: In function 'nes_post_send':
drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
drivers/infiniband/hw/nes/nes_verbs.c:3486: warning: cast to pointer from integer of different size
drivers/infiniband/hw/cxgb4/cq.c: In function 'destroy_cq':
drivers/infiniband/hw/cxgb4/cq.c:58: warning: cast from pointer to integer of different size
drivers/infiniband/hw/cxgb4/cq.c: In function 'create_cq':
drivers/infiniband/hw/cxgb4/cq.c:135: warning: cast from pointer to integer of different size
drivers/dma/timb_dma.c: In function 'td_fill_desc':
drivers/dma/timb_dma.c:203: warning: cast to pointer from integer of different size
drivers/net/wireless/iwmc3200wifi/rx.c: In function 'iwm_ntf_wifi_if_wrapper':
drivers/net/wireless/iwmc3200wifi/rx.c:1198: warning: comparison is always true due to limited range of data type
^ permalink raw reply
* [PATCH 2/3] net/sock.h: add missing kernel-doc notation
From: Randy Dunlap @ 2010-08-09 23:41 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Add missing kernel-doc notation to struct sock:
Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_pid'
Warning(include/net/sock.h:324): No description found for parameter 'sk_peer_cred'
Warning(include/net/sock.h:324): No description found for parameter 'sk_classid'
Warning(include/net/sock.h:324): Excess struct/union/enum/typedef member 'sk_peercred' description in 'sock'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/net/sock.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.35-git8.orig/include/net/sock.h
+++ linux-2.6.35-git8/include/net/sock.h
@@ -195,7 +195,8 @@ struct sock_common {
* @sk_priority: %SO_PRIORITY setting
* @sk_type: socket type (%SOCK_STREAM, etc)
* @sk_protocol: which protocol this socket belongs in this network family
- * @sk_peercred: %SO_PEERCRED setting
+ * @sk_peer_pid: &struct pid for this socket's peer
+ * @sk_peer_cred: %SO_PEERCRED setting
* @sk_rcvlowat: %SO_RCVLOWAT setting
* @sk_rcvtimeo: %SO_RCVTIMEO setting
* @sk_sndtimeo: %SO_SNDTIMEO setting
@@ -211,6 +212,7 @@ struct sock_common {
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
* @sk_mark: generic packet mark
+ * @sk_classid: this socket's cgroup classid
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Randy Dunlap @ 2010-08-09 23:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Faisal Latif, Chien Tung,
Dan Williams, Samuel Ortiz, linux-kernel, netdev, linux-wireless,
x86, linux-rdma
In-Reply-To: <20100809164346.6e30cf8c.akpm@linux-foundation.org>
On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton wrote:
>
> Guys. What's goin' on out there?
>
>
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
> drivers/power/olpc_battery.c:387: warning: initialization from incompatible pointer type
> make[2]: *** [drivers/power/olpc_battery.o] Error 1
> make[1]: *** [drivers/power] Error 2
David Woodhouse fixed this one today.
> fs/squashfs/xattr.c:37: warning: 'squashfs_xattr_handler' declared inline after being called
> fs/squashfs/xattr.c:37: warning: previous declaration of 'squashfs_xattr_handler' was here
I see this one on one system (with gcc 4.1.2) but not on f11 with gcc 4.4.1,
although it should be OK to "fix" it.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Stephen Rothwell @ 2010-08-10 0:15 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Faisal Latif, Chien Tung,
Dan Williams, Samuel Ortiz, linux-kernel, netdev, linux-wireless,
x86, linux-rdma
In-Reply-To: <20100809164346.6e30cf8c.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
Hi Andrew,
On Mon, 9 Aug 2010 16:43:46 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> Guys. What's goin' on out there?
I guess we are all so up to date that noone does 32 bit builds any
more ... Also noone is bothering to look at the build logs:
linus tree: http://kisskb.ellerman.id.au/kisskb/branch/3/
linux-next: http://kisskb.ellerman.id.au/kisskb/branch/9/
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
This is known and should be fixed in today's -next and hopefully being
sent to Linus.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: David Woodhouse @ 2010-08-10 0:32 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, Mike Frysinger, Jesse Barnes, Kevin Curtis,
Phillip Lougher, Faisal Latif, Chien Tung, Dan Williams,
Samuel Ortiz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Mon, 2010-08-09 at 16:43 -0700, Andrew Morton wrote:
>
> drivers/power/olpc_battery.c:387: error: unknown field 'owner' specified in initializer
> drivers/power/olpc_battery.c:387: warning: initialization from incompatible pointer type
> make[2]: *** [drivers/power/olpc_battery.o] Error 1
> make[1]: *** [drivers/power] Error 2
I fixed that today.
> drivers/mtd/maps/gpio-addr-flash.c: In function 'gpio_flash_probe':
> drivers/mtd/maps/gpio-addr-flash.c:212: warning: cast to pointer from integer of different size
> drivers/mtd/maps/gpio-addr-flash.c:224: warning: cast to pointer from integer of different size
Ew. Mike? Is this a nommu driver which is missing an ioremap()?
> drivers/pci/intel-iommu.c: In function 'dma_pte_addr':
> drivers/pci/intel-iommu.c:239: warning: passing argument 1 of '__cmpxchg64' from incompatible pointer type
- return __cmpxchg64(pte, 0ULL, 0ULL) & VTD_PAGE_MASK;
+ return __cmpxchg64(&pte->val, 0ULL, 0ULL) & VTD_PAGE_MASK;
Will test and push.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: i386 allmodconfig, current mainline
From: Dan Williams @ 2010-08-10 0:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Greg KH, David Woodhouse, Mike Frysinger, Jesse Barnes,
Kevin Curtis, Phillip Lougher, Latif, Faisal, Tung, Chien Tin,
Ortiz, Samuel,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20100809164346.6e30cf8c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On 8/9/2010 4:43 PM, Andrew Morton wrote:
>
> Guys. What's goin' on out there?
[..]
>
> drivers/dma/timb_dma.c: In function 'td_fill_desc':
> drivers/dma/timb_dma.c:203: warning: cast to pointer from integer of different size
The fix for this one is pending in my 2.6.36 pull request. I added the
missing ARCH=i386, CONFIG_HIGHMEM64G=y case to my build regression script.
--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Anirban Chakraborty @ 2010-08-10 1:43 UTC (permalink / raw)
To: Dan Carpenter
Cc: Amit Salecha, Linux Driver, David S. Miller, Sucheta Chakraborty,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20100809184254.GJ9031@bicker>
On Aug 10, 2010, at 12:12 AM, Dan Carpenter wrote:
> On Mon, Aug 09, 2010 at 09:46:32AM -0700, Anirban Chakraborty wrote:
>>
>> It looks fine except that I'd use kzalloc instead of kcalloc above.
>>
>
> It's no problem to do that, and I'm already respinning the patches but
> I'm confused. It looks like pci_info gets initialized correctly. What
> am I missing?
Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
argument that you are passing to kcalloc.
-Anirban
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Joe Perches @ 2010-08-10 2:03 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <9F31A875-3A0B-4518-8106-1012E0D2799B@qlogic.com>
On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
> argument that you are passing to kcalloc.
You probably meant to write "my preferred way"
as the kcalloc to "kzalloc with a multiply"
ratio is pretty high.
It's actually about 2.5 to 1 in favor of kcalloc.
$ grep -rw --include=*.[ch] kcalloc * | wc -l
419
$ grep -rP --include=*.[ch] "\bkzalloc\s*\(\s*\w+\s*\*\s*\w+" * | \
grep -vP "\bkzalloc\s*\(\s*sizeof\s+\*\s*\w+\s*," | wc -l
164
(the grep -vP avoids kzalloc(sizeof *p, GFP_foo)
Actually, there might be a reason to use kzalloc
in that location to match the other similar use
a few lines away, but I'd prefer that the other
use be converted to kcalloc.
cheers, Joe
^ permalink raw reply
* Auto generation of IPv6 link local address
From: Jon Smirl @ 2010-08-10 3:04 UTC (permalink / raw)
To: Netdev
When I bring my Ethernet interface up it automatically gets a link
local IPv6 address.
eth3 Link encap:Ethernet HWaddr 00:1b:21:59:65:32
inet addr:192.168.1.8 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:21ff:fe59:6532/64 Scope:Link -->
Missing from my driver
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1836635 errors:0 dropped:0 overruns:0 frame:0
TX packets:1283010 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2259859914 (2.2 GB) TX bytes:121836850 (121.8 MB)
Interrupt:16 Memory:dbd60000-dbd80000
I'm writing a device driver for new 802.15.4 hardware. When I bring it
up I don't get an automatic IPv6 link local address. What controls
whether an adapter gets a link local address added or not? My driver
should get one so I must have something wrong in my code.
wpan0 Link encap:IEEE 802.15.4 HWaddr 00:50:c2:ff:fe:a8:a8:c5
UP BROADCAST RUNNING NOARP MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Anirban Chakraborty @ 2010-08-10 3:31 UTC (permalink / raw)
To: Joe Perches
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <1281405801.1954.65.camel@Joe-Laptop.home>
On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
> On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
>> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
>> argument that you are passing to kcalloc.
>
> You probably meant to write "my preferred way"
> as the kcalloc to "kzalloc with a multiply"
> ratio is pretty high.
>
> It's actually about 2.5 to 1 in favor of kcalloc.
>
> $ grep -rw --include=*.[ch] kcalloc * | wc -l
> 419
>
> $ grep -rP --include=*.[ch] "\bkzalloc\s*\(\s*\w+\s*\*\s*\w+" * | \
> grep -vP "\bkzalloc\s*\(\s*sizeof\s+\*\s*\w+\s*," | wc -l
> 164
>
> (the grep -vP avoids kzalloc(sizeof *p, GFP_foo)
>
> Actually, there might be a reason to use kzalloc
> in that location to match the other similar use
> a few lines away, but I'd prefer that the other
> use be converted to kcalloc.
I was suggesting based on the following:
http://lwn.net/Articles/147014/
thanks,
Anirban
^ permalink raw reply
* Re: [patch 2/2] qlcnic: using too much stack
From: Joe Perches @ 2010-08-10 3:39 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Dan Carpenter, Amit Salecha, Linux Driver, David S. Miller,
Sucheta Chakraborty, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <D084A42E-7F2A-44F7-9273-DDD9214CB877@qlogic.com>
On Mon, 2010-08-09 at 20:31 -0700, Anirban Chakraborty wrote:
> On Aug 10, 2010, at 7:33 AM, Joe Perches wrote:
> > On Mon, 2010-08-09 at 18:43 -0700, Anirban Chakraborty wrote:
> >> Your patch is fine except that the preferred way is to use kzalloc over kaclloc. kzalloc does not need that extra
> >> argument that you are passing to kcalloc.
> > You probably meant to write "my preferred way"
> > as the kcalloc to "kzalloc with a multiply"
> > ratio is pretty high.
> I was suggesting based on the following:
> http://lwn.net/Articles/147014/
Note that article suggests kzalloc for allocating
a single zeroed object.
kcalloc is used for multiple zeroed objects and
protects against oversized allocations.
^ 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