* Re: [PATCH v2 3/4] sctp: fix association hangs due to errors when reneging events from the ordering queue
From: Neil Horman @ 2013-02-28 14:34 UTC (permalink / raw)
To: Lee A. Roberts; +Cc: netdev
In-Reply-To: <1361991273-30578-4-git-send-email-lee.roberts@hp.com>
On Wed, Feb 27, 2013 at 11:54:32AM -0700, Lee A. Roberts wrote:
> From: "Lee A. Roberts" <lee.roberts@hp.com>
>
> Resolve SCTP association hangs observed during SCTP stress
> testing. Observable symptoms include communications hangs
> with data being held in the association reassembly and/or lobby
> (ordering) queues. Close examination of reassembly queue shows
> missing packets.
>
> In sctp_ulpq_renege_list(), events being reneged from the
> ordering queue may correspond to multiple TSNs. Identify
> all affected packets; sum freed space and renege from the
> tsnmap.
>
> Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
^ permalink raw reply
* Re: [PATCH v2 2/4] sctp: fix association hangs due to reneging packets below the cumulative TSN ACK point
From: Neil Horman @ 2013-02-28 14:33 UTC (permalink / raw)
To: Lee A. Roberts; +Cc: netdev
In-Reply-To: <1361991273-30578-3-git-send-email-lee.roberts@hp.com>
On Wed, Feb 27, 2013 at 11:54:31AM -0700, Lee A. Roberts wrote:
> From: "Lee A. Roberts" <lee.roberts@hp.com>
>
> Resolve SCTP association hangs observed during SCTP stress
> testing. Observable symptoms include communications hangs
> with data being held in the association reassembly and/or lobby
> (ordering) queues. Close examination of reassembly queue shows
> missing packets.
>
> In sctp_ulpq_renege_list(), do not renege packets below the
> cumulative TSN ACK point.
>
> Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
>
^ permalink raw reply
* Re: [PATCH v2 1/4] sctp: fix association hangs due to off-by-one errors in sctp_tsnmap_grow()
From: Neil Horman @ 2013-02-28 14:31 UTC (permalink / raw)
To: Lee A. Roberts; +Cc: netdev
In-Reply-To: <1361991273-30578-2-git-send-email-lee.roberts@hp.com>
On Wed, Feb 27, 2013 at 11:54:30AM -0700, Lee A. Roberts wrote:
> From: "Lee A. Roberts" <lee.roberts@hp.com>
>
> Resolve SCTP association hangs observed during SCTP stress
> testing. Observable symptoms include communications hangs
> with data being held in the association lobby (ordering)
> queue. Close examination of reassembly/ordering queues shows
> duplicated packets.
>
> In sctp_tsnmap_mark(), correct off-by-one error when calculating
> size value for sctp_tsnmap_grow().
>
> In sctp_tsnmap_grow(), correct off-by-one error when copying
> and resizing the tsnmap. If max_tsn_seen is in the LSB of the
> word, this bit can be lost, causing the corresponding packet
> to be transmitted again and to be entered as a duplicate into
> the SCTP reassembly/ordering queues. Change parameter name
> from "gap" (zero-based index) to "size" (one-based) to enhance
> code readability.
>
> Signed-off-by: Lee A. Roberts <lee.roberts@hp.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] drivers/isdn: checkng length to be sure not memory overflow
From: Jiri Slaby @ 2013-02-28 13:43 UTC (permalink / raw)
To: Chen Gang; +Cc: Jiri Kosina, isdn, Greg KH, alan, netdev
In-Reply-To: <512F38F8.2060804@asianux.com>
On 02/28/2013 12:01 PM, Chen Gang wrote:
> 于 2013年02月28日 18:00, Jiri Slaby 写道:
>> I don't think there are piles of people to care about ISDN much nowadays.
>
> I don't think either.
> (I found it through reading the source code, by search strncpy)
>
> if this is quite minor:
> I suggest to delete this module.
Nah, there *are* still people using ISDN.
>> So we can
>> close that it is correct to drop the rest of the buffer. In a hope that
>> +M is not followed by text longer than 50-or-so chars.
>
> can we be sure that "+M..." is no more than 100+ chars ?
> (I guess the sizeof (isdn_ctrl.parm) is 80+, but less than 100)
> if we can not be sure:
No, we cannot be sure that a user gives us less than that. Your patch
just throws the rest to fix that overflow, right? What I'm saying I
wouldn't fix more than that.
--
js
suse labs
^ permalink raw reply
* Re: [PATCH 6/8] netfront: multi-page ring support
From: annie li @ 2013-02-28 12:55 UTC (permalink / raw)
To: Wei Liu
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Ian Campbell,
konrad.wilk@oracle.com
In-Reply-To: <20130228110237.GA23777@zion.uk.xensource.com>
On 2013-2-28 19:02, Wei Liu wrote:
> On Thu, Feb 28, 2013 at 05:19:43AM +0000, ANNIE LI wrote:
>> I checked the code in Konrad's tree and am thinking this overlap issue
>> you mentioned existing in original netback(without multi-ring) and newer
>> netfront. Original netback does not support multi-ring, and your newer
>> netfront before this bug fix used "#define TX_MAX_TARGET
>> XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when
>> netfront allocating rx skbs.
>> "#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the
>> netfront to single ring, it fixed the overlap issue, but not enough.
>>
> Yes. I just saw a bug report from Xen-user list yesterday for the same
> issue in original netback (1 page ring), so the overlap issue is not
> introduced by multi-page ring implementation. If your team also sees that
> issue, do you have patch to fix that?
No. We thought your patch fixed it, and I did not check it further at
that time.
Are you sure they are same? What is the thread title in Xen-user?
The overlap issue here exists in netfront when netfront allocates skb
greedily. In Konrad's tree merged with your patch, netfront with
"#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE" should hit this overlap
issue when it runs with single ring netback.
Thanks
Annie
^ permalink raw reply
* query: localhost - 794ed393b clips hefty load tbench, does it matter?
From: Mike Galbraith @ 2013-02-28 12:49 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet
Greetings network wizards,
I was testing a 64 core box after 3.0-stable update, and noticed
$subject.
vogelweide:~/:[0]# numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 0 size: 8181 MB
node 0 free: 7353 MB
node distances:
node 0
0: 10
Sob, poor thing. Anyway, that's the box in case it matters.
Without 94ed393b.
vogelweide:~/:[0]# for i in 1 2 4 8 16 32 64 128 256 512; do tbench.sh $i 10 2>&1|grep Throughput; done
Throughput 288.784 MB/sec 1 procs
Throughput 559.937 MB/sec 2 procs
Throughput 1068.75 MB/sec 4 procs
Throughput 2159.04 MB/sec 8 procs
Throughput 4193.75 MB/sec 16 procs
Throughput 7662.24 MB/sec 32 procs
Throughput 9034.49 MB/sec 64 procs
Throughput 9045.9 MB/sec 128 procs
Throughput 9077.55 MB/sec 256 procs
Throughput 8907.48 MB/sec 512 procs
With.
vogelweide:~/:[0]# for i in 1 2 4 8 16 32 64 128 256 512; do tbench.sh $i 10 2>&1|grep Throughput; done
Throughput 288.833 MB/sec 1 procs
Throughput 520.87 MB/sec 2 procs
Throughput 937.758 MB/sec 4 procs
Throughput 1563.3 MB/sec 8 procs
Throughput 1775.14 MB/sec 16 procs
Throughput 1406.55 MB/sec 32 procs
Throughput 1448.77 MB/sec 64 procs
Throughput 1468.92 MB/sec 128 procs
Throughput 1525.35 MB/sec 256 procs
Throughput 1713.54 MB/sec 512 procs
I'm wondering if this could cause problems on a big box doing something
like say mysql queries of a local database, blasting retrieved data out
over industrial strength copper/glass or such. My desktop box surely
won't notice, but it seems heavy lifters might. I saw the reason for
it, but I was left wondering why we used to care about it, but no more,
so here I am to see if I can get my curiosity spot scratched.
I'll sorta miss good ole tbench in scheduler litmus test role. On the
bright side, localhost based scalability reports are history. Oh wait.
-Mike
^ permalink raw reply
* RE: [RFC PATCH 3/3] mlx4: Use default fdb handlers when not multifunction.
From: Yan Burman @ 2013-02-28 12:32 UTC (permalink / raw)
To: john.r.fastabend@intel.com, vyasevic@redhat.com
Cc: Or Gerlitz, Amir Vadai, netdev@vger.kernel.org,
davem@davemloft.net
In-Reply-To: <CAJZOPZLcphuZEXR+jhT35=qtOq9bfxWzWEokN6UrMorciCvvsA@mail.gmail.com>
> From: John Fastabend <john.r.fastabend@intel.com>
> Date: Thu, Feb 28, 2013 at 6:27 AM
> Subject: Re: [RFC PATCH 3/3] mlx4: Use default fdb handlers when not
> multifunction.
> To: Vlad Yasevich <vyasevic@redhat.com>, Amir Vadai <amirv@mellanox.com>
> Cc: netdev@vger.kernel.org, davem@davemloft.net
>
>
> On 2/27/2013 9:46 AM, Vlad Yasevich wrote:
> >
> > Allow the use of ndo_dflt_fdb_<add|del|dump> when the adapter is not
> > configured with virtual functins (!mlx4_is_mfunc()) This allows proper
> > IFF_UNICAST_FLT support and allows for additional handling by the
> > driver if needed.
> >
> > CC: Amir Vadai <amirv@mellanox.com>
> > Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 12 +++---------
> > 1 files changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > index 5385474..5732025 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> > @@ -1934,7 +1934,7 @@ static int mlx4_en_fdb_add(struct ndmsg *ndm,
> > struct nlattr *tb[],
>
>
> Amir are the default ops good enough here?
>
The default ops can be used instead of mlx4 fdb_add, fdb_delete, and fdb_dump.
Yan
^ permalink raw reply
* Re: [PATCH v6 04/46] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Michel Lespinasse @ 2013-02-28 11:34 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Srivatsa S. Bhat, Lai Jiangshan, linux-doc, peterz, fweisbec,
linux-kernel, namhyung, mingo, linux-arch, linux, xiaoguangrong,
wangyun, paulmck, nikunj, linux-pm, rusty, rostedt, rjw,
vincent.guittot, tglx, linux-arm-kernel, netdev, sbw, tj, akpm,
linuxppc-dev
In-Reply-To: <20130227192551.GA8333@redhat.com>
On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 02/27, Michel Lespinasse wrote:
>>
>> +void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
>> +{
>> + preempt_disable();
>> +
>> + if (__this_cpu_read(*lgrw->local_refcnt) ||
>> + arch_spin_trylock(this_cpu_ptr(lgrw->lglock->lock))) {
>> + __this_cpu_inc(*lgrw->local_refcnt);
>
> Please look at __this_cpu_generic_to_op(). You need this_cpu_inc()
> to avoid the race with irs. The same for _read_unlock.
Hmmm, I was thinking that this was safe because while interrupts might
modify local_refcnt to acquire a nested read lock, they are expected
to release that lock as well which would set local_refcnt back to its
original value ???
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply
* Re: [PATCH 6/8] netfront: multi-page ring support
From: Wei Liu @ 2013-02-28 11:02 UTC (permalink / raw)
To: ANNIE LI
Cc: xen-devel@lists.xen.org, netdev@vger.kernel.org, Ian Campbell,
konrad.wilk@oracle.com
In-Reply-To: <512EE8EF.30200@oracle.com>
On Thu, Feb 28, 2013 at 05:19:43AM +0000, ANNIE LI wrote:
>
>
> On 2013-2-27 23:49, Wei Liu wrote:
> > On Wed, 2013-02-27 at 07:39 +0000, ANNIE LI wrote:
> >> On 2013-2-26 20:35, Wei Liu wrote:
> >>> On Tue, 2013-02-26 at 06:52 +0000, ANNIE LI wrote:
> >>>> On 2013-2-16 0:00, Wei Liu wrote:
> >>>>> Signed-off-by: Wei Liu<wei.liu2@citrix.com>
> >>>>> ---
> >>>>> drivers/net/xen-netfront.c | 246 +++++++++++++++++++++++++++++++-------------
> >>>>> 1 file changed, 174 insertions(+), 72 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>>>> index 8bd75a1..de73a71 100644
> >>>>> --- a/drivers/net/xen-netfront.c
> >>>>> +++ b/drivers/net/xen-netfront.c
> >>>>> @@ -67,9 +67,19 @@ struct netfront_cb {
> >>>>>
> >>>>> #define GRANT_INVALID_REF 0
> >>>>>
> >>>>> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> >>>>> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> >>>>> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> >>>>> +#define XENNET_MAX_RING_PAGE_ORDER XENBUS_MAX_RING_PAGE_ORDER
> >>>>> +#define XENNET_MAX_RING_PAGES (1U<< XENNET_MAX_RING_PAGE_ORDER)
> >>>>> +
> >>>>> +
> >>>>> +#define NET_TX_RING_SIZE(_nr_pages) \
> >>>>> + __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> >>>>> +#define NET_RX_RING_SIZE(_nr_pages) \
> >>>>> + __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> >>>>> +
> >>>>> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>>>> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> >>>>> +
> >>>>> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)
> >>>> Not using multi-page ring here?
> >>>> In xennet_create_dev, gnttab_alloc_grant_references allocates
> >>>> TX_MAX_TARGET number of grant reference for tx. In
> >>>> xennet_release_tx_bufs, NET_TX_RING_SIZE(np->tx_ring_pages) numbers of
> >>>> grants are processed. And NET_RX_RING_SIZE(np->tx_ring_pages) is totally
> >>>> different from TX_MAX_TARGET if np->rx_ring_pages is not 1. Although
> >>>> skb_entry_is_link helps to not release invalid grants, lots of null loop
> >>>> seems unnecessary. I think TX_MAX_TARGET should be changed into some
> >>>> variableconnected with np->tx_ring_pages. Or you intended to use one
> >>>> page ring here?
> >>>>
> >>> Looking back my history, this limitation was introduced because if we
> >>> have a multi-page backend and single page frontend, the backend skb
> >>> processing could overlap.
> >> I did not see the overlap you mentioned here in netback. Although
> >> netback supports multi-page, netback->vif still uses single page if the
> >> frontend only supports single page. Netfront and netback negotiate this
> >> through xenstore in your 5/8 patch. The requests and response should not
> >> have any overlap between netback and netfront. Am I missing something?
> >>
> > I tried to dig up mail archive just now and realized that the bug report
> > was in private mail exchange with Konrad.
> >
> > I don't really remember the details now since it is more than one year
> > old, but you can find trace in Konrad's tree, CS 5b4c3dd5b255. All I can
> > remember is that this bug was triggered by mixed old/new
> > frontend/backend.
>
> I checked the code in Konrad's tree and am thinking this overlap issue
> you mentioned existing in original netback(without multi-ring) and newer
> netfront. Original netback does not support multi-ring, and your newer
> netfront before this bug fix used "#define TX_MAX_TARGET
> XENNET_MAX_TX_RING_SIZE" directly. So that would cause overlap when
> netfront allocating rx skbs.
> "#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE(1), 256)" limits the
> netfront to single ring, it fixed the overlap issue, but not enough.
>
Yes. I just saw a bug report from Xen-user list yesterday for the same
issue in original netback (1 page ring), so the overlap issue is not
introduced by multi-page ring implementation. If your team also sees that
issue, do you have patch to fix that?
Wei.
^ permalink raw reply
* Re: [PATCH] drivers/isdn: checkng length to be sure not memory overflow
From: Chen Gang @ 2013-02-28 11:01 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Jiri Kosina, isdn, Greg KH, alan, netdev
In-Reply-To: <512F2AA7.4040204@suse.cz>
于 2013年02月28日 18:00, Jiri Slaby 写道:
> I don't think there are piles of people to care about ISDN much nowadays.
I don't think either.
(I found it through reading the source code, by search strncpy)
if this is quite minor:
I suggest to delete this module.
the reason is:
it can not provide contributes, any more.
but may give a chance to the hacker which want to make an attack.
:-)
> So we can
> close that it is correct to drop the rest of the buffer. In a hope that
> +M is not followed by text longer than 50-or-so chars.
can we be sure that "+M..." is no more than 100+ chars ?
(I guess the sizeof (isdn_ctrl.parm) is 80+, but less than 100)
if we can not be sure:
do we need check and limit the length ? (I prefer to give a check)
if the module will really be delete,
I still suggest to maintain previous versions (for security issue)
thanks.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH v2] phy: Fix phy_device_free memory leak
From: Petr Malat @ 2013-02-28 11:01 UTC (permalink / raw)
To: netdev; +Cc: oss
From: Petr Malat <oss@malat.biz>
Fix memory leak in phy_device_free() for the case when phy_device*
returned by phy_device_create() is not registered in the system.
Bug description:
phy_device_create() sets name of kobject using dev_set_name(), which
allocates memory using kvasprintf(), but this memory isn't freed if
the underlying device isn't registered properly, because kobject_cleanup()
is not called in that case. This can happen (and actually is happening on
our machines) if phy_device_register(), called by mdiobus_scan(), fails.
Patch description:
Embedded struct device is initialized in phy_device_create() and it
counterpart phy_device_free() just drops one reference to the device,
which leads to proper deinitialization including releasing the kobject
name memory.
Signed-off-by: Petr Malat <oss@malat.biz>
---
Updated according to according to David Miller proposal - put_device is
used to release the memory now.
Please put me on CC, I'm not signed into the mailing list.
--- linux-3.8/drivers/net/phy/phy_device.c.orig 2013-02-19 00:58:34.000000000 +0100
+++ linux-3.8/drivers/net/phy/phy_device.c 2013-02-28 11:20:51.841528627 +0100
@@ -44,13 +44,13 @@ MODULE_LICENSE("GPL");
void phy_device_free(struct phy_device *phydev)
{
- kfree(phydev);
+ put_device(&phydev->dev);
}
EXPORT_SYMBOL(phy_device_free);
static void phy_device_release(struct device *dev)
{
- phy_device_free(to_phy_device(dev));
+ kfree(to_phy_device(dev));
}
static struct phy_driver genphy_driver;
@@ -201,6 +201,8 @@ struct phy_device *phy_device_create(str
there's no driver _already_ loaded. */
request_module(MDIO_MODULE_PREFIX MDIO_ID_FMT, MDIO_ID_ARGS(phy_id));
+ device_initialize(&dev->dev);
+
return dev;
}
EXPORT_SYMBOL(phy_device_create);
@@ -363,9 +365,9 @@ int phy_device_register(struct phy_devic
/* Run all of the fixups for this PHY */
phy_scan_fixups(phydev);
- err = device_register(&phydev->dev);
+ err = device_add(&phydev->dev);
if (err) {
- pr_err("phy %d failed to register\n", phydev->addr);
+ pr_err("PHY %d failed to add\n", phydev->addr);
goto out;
}
^ permalink raw reply
* Re: [RFC Patch net-next] vxlan: add ipv6 support
From: Thomas Graf @ 2013-02-28 10:33 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller, Stephen Hemminger
In-Reply-To: <1362031286-23295-1-git-send-email-amwang@redhat.com>
On 02/28/13 at 02:01pm, Cong Wang wrote:
> WARNING: This is just an RFC patch, it only compiles!!
>
> This patch adds IPv6 support to vxlan device, as the new version
> RFC already mentioned it:
>
> http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-03
>
> I am not sure if the following trick will work:
>
> + if (nla_len(nla) == sizeof(__be32)) {
> + ip->ip4 = nla_get_be32(nla);
> + ip->proto = htons(ETH_P_IP);
> + }
> +#if IS_ENABLED(CONFIG_IPV6)
> + else if (nla_len(nla) == sizeof(struct in6_addr)) {
> + nla_memcpy(&ip->ip6, nla, sizeof(struct in6_addr));
> + ip->proto = htons(ETH_P_IPV6);
> + }
> +#endif
>
> otherwise we have to introduce some new netlink attributes for
> IPv6 addresses? Any comments?
How about setting ndm_family to AF_INET6 and parse NDA_DST based on
that?
Assuming that nla_len(NDA_DST) > 4 == ip6 is a bit weak as like with
any Netlink attribute we only ever enforce a minimum length and never
a maximum or exact length.
^ permalink raw reply
* Re: [PATCH] net/rds: using strlcpy instead of strncpy
From: Chen Gang @ 2013-02-28 10:26 UTC (permalink / raw)
To: David Laight; +Cc: venkat.x.venkatsubra, David Miller, rds-devel, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B716D@saturn3.aculab.com>
于 2013年02月28日 17:36, David Laight 写道:
>> > diff --git a/net/rds/stats.c b/net/rds/stats.c
>> > index 7be790d..b9ac1df 100644
>> > --- a/net/rds/stats.c
>> > +++ b/net/rds/stats.c
>> > @@ -86,7 +86,7 @@ void rds_stats_info_copy(struct rds_info_iterator *iter,
>> >
>> > for (i = 0; i < nr; i++) {
>> > BUG_ON(strlen(names[i]) >= sizeof(ctr.name));
>> > - strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
>> > + strlcpy(ctr.name, names[i], sizeof(ctr.name));
>> > ctr.value = values[i];
>> >
> If the target buffer ends up being copied to userspace that
> might lead to random kernel memory being leaked.
excuse me, I do not quite understand what your meaning.
I guess what you said is:
if crt.name is not ended by '\0', it will cause issue.
the issue is:
"If the target buffer ends up being copied to userspace that
might lead to random kernel memory being leaked."
is it correct ?
if it is correct, need I add them as patch comments, too ?
else (incorrect), please give more descriptions, thanks.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH net] tcp: Don't collapse if resulting skb could overflow skb->csum_start
From: Thomas Graf @ 2013-02-28 10:26 UTC (permalink / raw)
To: davem; +Cc: netdev, foraker1
If a TCP retransmission gets partially ACKed and collapsed multiple
times it is possible for the headroom to grow beyond 64K which will
overflow the 16bit skb->csum_start which is based on the start of
the headroom. It has been observed rarely in the wild with IPoIB due
to the 64K MTU.
With this patch, the overflow has not been observed for over a week
while previously it would occur within ~ 1 day.
A big thank you to Jim Foraker <foraker1@llnl.gov> and the team at
LLNL for helping out with the investigation and testing.
Reported-by: Jim Foraker <foraker1@llnl.gov>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
net/ipv4/tcp_output.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e2b4461..1902fee 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2305,6 +2305,12 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *to,
if (after(TCP_SKB_CB(skb)->end_seq, tcp_wnd_end(tp)))
break;
+ /* Never collapse if the resulting headroom + data exceeds
+ * 64K as that is the maximum csum_start can cover.
+ */
+ if (skb_headroom(to) + to->len + skb->len > 0xFFFF)
+ break;
+
tcp_collapse_retrans(sk, to);
}
}
^ permalink raw reply related
* Helpdesk: Important Message From Account Service.
From: Broadwell, Tom L. @ 2013-02-28 9:55 UTC (permalink / raw)
Dear Account Owner,
We are currently Migrating to Microsoft Exchange 2013 (from Exchange 2003/2007). With the introduction of Internet Explorer 9, Outlook Express has apparently been removed from the installation package on our Message Center. OWA 2010 provides the same conversation view and experience as Outlook 2010: By default, messages are displayed in threads so that all the messages on a particular topic are grouped. Inability to complete information on the form within 48 hours Message Center will render your e-mail in-active from our database. Fill information on the Form by clicking on the link below:
CLICK HERE<https://docs.google.com/forms/d/1Q3VT6Jt44-TGvUixwCVszZGDEC4uKQl--eDp83B5cNw/viewform>
You will receive an e-mail within 48 hours when your mailbox account is moved.
Thank you.
Help Desk
(@)2013. All Rights Reserved
^ permalink raw reply
* I PREFERRED YOUR HELP
From: Mr Jr. Laurent @ 2013-02-28 10:02 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 59 bytes --]
I PREFERRED YOU (GO THROUGH THE ATTACHMENT FOR THE MESSAGE)
[-- Attachment #2: Laur.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 13109 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/isdn: checkng length to be sure not memory overflow
From: Jiri Slaby @ 2013-02-28 10:00 UTC (permalink / raw)
To: Chen Gang; +Cc: Jiri Kosina, isdn, Greg KH, alan, netdev
In-Reply-To: <512EB6CA.6030609@asianux.com>
On 02/28/2013 02:45 AM, Chen Gang wrote:
> 于 2013年02月27日 18:44, Jiri Slaby 写道:
>> On 02/27/2013 11:25 AM, Chen Gang wrote:
>>>> 于 2013年02月27日 17:48, Jiri Slaby 写道:
>>>>>> I have no idea if
>>>>>> this is correct from the ISDN POV as we drop the end of the buffer
>>>>
>>>> pardon ? what about "ISDN POV".
>> "point of view" aka POV.
>>
>> Hmm, "also known as" alias "aka" :).
>
>
> sorry, I still not quite understand (I am really not familiar with ISDN)
>
> so I have to bother you with 2 questions, please help reply, thanks.
>
> A) is our current patch OK ?
> a. yes, ok, need do nothing for it, just is waiting for Acked-by or applying.
> b. no, need improving (e.g. additional consideration, comments, or others)
> c. no, it is useless patch.
>
> B) does "ISDN POV" point to another issue ?
> if yes:
> I will read source code or search document on net, and should not bother you again.
> if possible, I can try to send relative patches, next.
> else (no):
> could you please say more details again ?
No, the sentence was "I have no idea if this is correct from the ISDN
point of view because we drop the end of the buffer." I don't think
there are piles of people to care about ISDN much nowadays. So we can
close that it is correct to drop the rest of the buffer. In a hope that
+M is not followed by text longer than 50-or-so chars.
There is nothing more to fix. (Well, there is, but not in this context.)
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] drivers/isdn: break out of the loop after call isdn_tty_send_msg
From: Jiri Slaby @ 2013-02-28 9:54 UTC (permalink / raw)
To: Chen Gang; +Cc: Jiri Kosina, isdn, Greg KH, Alan Cox, netdev
In-Reply-To: <512EC79C.3010700@asianux.com>
On 02/28/2013 03:57 AM, Chen Gang wrote:
>
> need break out of the loop after call isdn_tty_send_msg.
> isdn_tty_send_msg is intended to eat the rest of the string.
> so need not scan again the string which appended "+M...".
Yes, looks good.
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> drivers/isdn/i4l/isdn_tty.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/isdn/i4l/isdn_tty.c b/drivers/isdn/i4l/isdn_tty.c
> index d8a7d83..8ac7b33 100644
> --- a/drivers/isdn/i4l/isdn_tty.c
> +++ b/drivers/isdn/i4l/isdn_tty.c
> @@ -3587,7 +3587,7 @@ isdn_tty_parse_at(modem_info *info)
> case 'M': /* MESSAGE */
> p++;
> isdn_tty_send_msg(info, m, p);
> - break;
> + goto tail;
> default:
> PARSE_ERROR;
> }
> @@ -3601,6 +3601,8 @@ isdn_tty_parse_at(modem_info *info)
> PARSE_ERROR;
> }
> }
> +
> +tail:
> #ifdef CONFIG_ISDN_AUDIO
> if (!info->vonline)
> #endif
>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH] n_gsm: Add Mutex to avoid race when net destroy
From: Jiri Slaby @ 2013-02-28 9:53 UTC (permalink / raw)
To: channing, Greg Kroah-Hartman; +Cc: linux-kernel, ML netdev
In-Reply-To: <1362029486.31563.5.camel@bichao>
On 02/28/2013 06:31 AM, channing wrote:
>
> when gsm Net is enabled, data on dlci is transferrd by
> gsm_mux_net_start_xmit(), while userspace may trigger
> ioctrl to call gsm_destroy_network() during data was
> transferring, because there is no mutex protection between
> the two functions, following scenario may happen:
>
> 1) gsm_mux_net_start_xmit() calls muxnet_get(mux_net);
> 2) gsm_destroy_network() is called from ioctrl, and it
> will not call net_free() to release net device because
> net device is still referred in step 1)
> 3) continue execute step 1), gsm_mux_net_start_xmit()
> calls muxnet_put(mux_net), and then calls net_free() to
> release net device.
> 4) if userspace triggers gsm_create_network() at same time
> with net_free() in step 3). it will hit race on dlci->net.
>
> This patch is to add a mutex in tx function to avoid race
> between it and destroy function.
>
> Signed-off-by: Chao Bi <chao.bi@intel.com>
> Signed-off-by: Pillet Vincent <vincentx.pillet@intel.com>
> ---
> drivers/tty/n_gsm.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index 4a43ef5..0ca810a 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -2660,6 +2660,7 @@ static int gsm_mux_net_start_xmit(struct sk_buff *skb,
> {
> struct gsm_mux_net *mux_net = (struct gsm_mux_net *)netdev_priv(net);
> struct gsm_dlci *dlci = mux_net->dlci;
> + mutex_lock(&dlci->mutex);
Nack, start_xmit may be called in an atomic context -- you cannot call
mutex.
> muxnet_get(mux_net);
>
> skb_queue_head(&dlci->skb_list, skb);
> @@ -2669,6 +2670,7 @@ static int gsm_mux_net_start_xmit(struct sk_buff *skb,
> /* And tell the kernel when the last transmit started. */
> net->trans_start = jiffies;
> muxnet_put(mux_net);
Instead the concept is broken. If this was the last reference (as
described in your steps above), it would blow up for the same reason I
refer to above, i.e. net_free here would call unregister_netdev which is
not atomic. Plus it will definitely deadlock because unregister_netdev
waits for start_xmit to finish.
It should stop the queue and schedule a workqueue to lock the mutex,
unregister the hetdev and reset dlci->net. (Or maybe just call
muxnet_put with the lock held.)
That will fix 4), but there is still a bug: what protects
gsm_create_network to be called twice or more in a sequence thus
re-setting dlci->net to a new and new pointer?
> + mutex_unlock(&dlci->mutex);
> return NETDEV_TX_OK;
> }
thanks,
--
js
suse labs
^ permalink raw reply
* RE: [PATCH] net/rds: using strlcpy instead of strncpy
From: David Laight @ 2013-02-28 9:36 UTC (permalink / raw)
To: Chen Gang, venkat.x.venkatsubra, David Miller, rds-devel, netdev
In-Reply-To: <512F1534.9020404@asianux.com>
> when src strlen is sizeof(ctr.name) - 1, the dest str is not '\0' end.
> better use strlcpy instead.
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> net/rds/stats.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/rds/stats.c b/net/rds/stats.c
> index 7be790d..b9ac1df 100644
> --- a/net/rds/stats.c
> +++ b/net/rds/stats.c
> @@ -86,7 +86,7 @@ void rds_stats_info_copy(struct rds_info_iterator *iter,
>
> for (i = 0; i < nr; i++) {
> BUG_ON(strlen(names[i]) >= sizeof(ctr.name));
> - strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
> + strlcpy(ctr.name, names[i], sizeof(ctr.name));
> ctr.value = values[i];
>
If the target buffer ends up being copied to userspace that
might lead to random kernel memory being leaked.
David
^ permalink raw reply
* Re: [RFC PATCH 0/5] net: low latency Ethernet device polling
From: Eliezer Tamir @ 2013-02-28 8:38 UTC (permalink / raw)
To: Ben Greear
Cc: Rick Jones, Eliezer Tamir, linux-kernel, netdev, Dave Miller,
Jesse Brandeburg, e1000-devel, Willem de Bruijn, Andi Kleen, HPA,
Eliezer Tamir
In-Reply-To: <512E7DD1.1010209@candelatech.com>
On 27/02/2013 23:42, Ben Greear wrote:
> On 02/27/2013 12:40 PM, Eliezer Tamir wrote:
>> On 27/02/2013 21:58, Rick Jones wrote:
>>> On 02/27/2013 09:55 AM, Eliezer Tamir wrote:
>>>> *rx-usecs=0 is usually not useful in a production environment.
>>>
>>> I would think that latency-sensitive folks would be using rx-usecs=0 in
>>> production - at least if the NIC in use didn't have low enough latency
>>> with its default interrupt coalescing/avoidance heuristics.
>>
>> It will only work well if you have no bulk traffic on the same port as
>> the low latency traffic at all.
>
> Have you done any tests for bulk throughput with busy-poll? Yes, it
> will eat a core,
> but that might be worth it in some cases if there was significant
> throughput increase...
My impression was that most bulk use cases are handled exceptionally
well by napi along with some kind of adaptive moderation scheme, esp. if
you compare to cases where napi is not being used.
If you can recommend a specific use case where busy polling will be an
advantage for bulk traffic, I will happily try it out.
Thanks,
Eliezer
^ permalink raw reply
* hv_netvsc: WARNING in softirq.c
From: Richard GENOUD @ 2013-02-28 8:34 UTC (permalink / raw)
To: K. Y. Srinivasan; +Cc: devel, Haiyang Zhang, linux-kernel, netdev
Hi,
Here is the kernel trace I got this morning (kern.log):
Feb 27 22:32:59 devlabo kernel: [10688.187062] hv_vmbus: child device vmbus_0_8 unregistered
Feb 27 22:34:37 devlabo kernel: [10688.187196] ------------[ cut here ]------------
Feb 27 22:34:37 devlabo kernel: [10688.187203] WARNING: at /build/buildd-linux_3.2.35-2-amd64-v9djlH/linux-3.2.35/kernel/softirq.c:159 _local_bh_enable_ip.isra.11+0x3d/0x88()
Feb 27 22:34:37 devlabo kernel: [10688.187206] Hardware name: Virtual Machine
Feb 27 22:34:37 devlabo kernel: [10688.187208] Modules linked in: des_generic ecb md4 hmac nls_utf8 cifs nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop snd_pcm snd_page_alloc snd_timer snd joydev processor hid_hyperv crc32c_intel hid thermal_sys i2c_piix4 evdev button soundcore hv_utils i2c_core psmouse serio_raw pcspkr ext4 crc16 jbd2 mbcache sd_mod crc_t10dif hv_netvsc hv_storvsc sg sr_mod cdrom ata_generic floppy hv_vmbus ata_piix libata scsi_mod [last unloaded: scsi_wait_scan]
Feb 27 22:34:37 devlabo kernel: [10688.187244] Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.35-2
Feb 27 22:34:37 devlabo kernel: [10688.187246] Call Trace:
Feb 27 22:34:37 devlabo kernel: [10688.187248] <IRQ> [<ffffffff81046a75>] ? warn_slowpath_common+0x78/0x8c
Feb 27 22:34:37 devlabo kernel: [10688.187257] [<ffffffff8104bf76>] ? _local_bh_enable_ip.isra.11+0x3d/0x88
Feb 27 22:34:37 devlabo kernel: [10688.187262] [<ffffffffa00a59b5>] ? rndis_filter_receive+0x236/0x259 [hv_netvsc]
Feb 27 22:34:37 devlabo kernel: [10688.187267] [<ffffffffa00a4e5f>] ? netvsc_channel_cb+0x37a/0x449 [hv_netvsc]
Feb 27 22:34:37 devlabo kernel: [10688.187273] [<ffffffffa006211b>] ? vmbus_on_event+0x91/0xdd [hv_vmbus]
Feb 27 22:34:37 devlabo kernel: [10688.187277] [<ffffffff812432d5>] ? add_interrupt_randomness+0x38/0x155
Feb 27 22:34:37 devlabo kernel: [10688.187283] [<ffffffff8104b89a>] ? tasklet_action+0x73/0xc2
Feb 27 22:34:37 devlabo kernel: [10688.187287] [<ffffffff8104c084>] ? __do_softirq+0xb9/0x177
Feb 27 22:34:37 devlabo kernel: [10688.187292] [<ffffffff8135426c>] ? call_softirq+0x1c/0x30
Feb 27 22:34:37 devlabo kernel: [10688.187297] [<ffffffff8100f8dd>] ? do_softirq+0x3c/0x7b
Feb 27 22:34:37 devlabo kernel: [10688.187300] [<ffffffff8104c2ec>] ? irq_exit+0x3c/0x9a
Feb 27 22:34:37 devlabo kernel: [10688.187303] [<ffffffff8100f60d>] ? do_IRQ+0x82/0x98
Feb 27 22:34:37 devlabo kernel: [10688.187307] [<ffffffff8134d32e>] ? common_interrupt+0x6e/0x6e
Feb 27 22:34:37 devlabo kernel: [10688.187309] <EOI> [<ffffffff81065dbd>] ? timekeeping_get_ns+0xd/0x2a
Feb 27 22:34:37 devlabo kernel: [10688.187317] [<ffffffff8106bc20>] ? arch_local_irq_enable+0x4/0x8
Feb 27 22:34:37 devlabo kernel: [10688.187321] [<ffffffff8100d286>] ? cpu_idle+0xe8/0xf2
Feb 27 22:34:37 devlabo kernel: [10688.187324] [<ffffffff816abb33>] ? start_kernel+0x3b3/0x3be
Feb 27 22:34:37 devlabo kernel: [10688.187328] [<ffffffff816ab140>] ? early_idt_handlers+0x140/0x140
Feb 27 22:34:37 devlabo kernel: [10688.187331] [<ffffffff816ab3c4>] ? x86_64_start_kernel+0x104/0x111
Feb 27 22:34:37 devlabo kernel: [10688.187333] ---[ end trace 39158641c6e4b495 ]---
and there was a lot of them :
Feb 26 22:35:14 devlabo kernel: [37398.788119] ------------[ cut here ]------------
Feb 26 22:35:14 devlabo kernel: [37398.788129] WARNING: at /build/buildd-linux_3.2.35-2-amd64-v9djlH/linux-3.2.35/kernel/softirq.c:159 _local_bh_enable_ip.isra.11+0x3d/0x88()
Feb 26 22:35:14 devlabo kernel: [37398.788132] Hardware name: Virtual Machine
Feb 26 22:35:14 devlabo kernel: [37398.788133] Modules linked in: nfsd nfs nfs_acl auth_rpcgss lockd sunrpc des_generic ecb md4 hmac nls_utf8 cifs fscache loop snd_pcm snd_page_alloc snd_timer joydev crc32c_intel i2c_piix4 snd processor hid_hyperv hid hv_utils soundcore button thermal_sys pcspkr i2c_core psmouse evdev serio_raw ext4 crc16 jbd2 mbcache sd_mod crc_t10dif hv_netvsc hv_storvsc sg sr_mod cdrom ata_generic ata_piix libata scsi_mod floppy hv_vmbus [last unloaded: scsi_wait_scan]
Feb 26 22:35:14 devlabo kernel: [37398.788169] Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.35-2
Feb 26 22:35:14 devlabo kernel: [37398.788171] Call Trace:
Feb 26 22:35:14 devlabo kernel: [37398.788172] <IRQ> [<ffffffff81046a75>] ? warn_slowpath_common+0x78/0x8c
Feb 26 22:35:14 devlabo kernel: [37398.788181] [<ffffffff8104bf76>] ? _local_bh_enable_ip.isra.11+0x3d/0x88
Feb 26 22:35:14 devlabo kernel: [37398.788186] [<ffffffffa009e9b5>] ? rndis_filter_receive+0x236/0x259 [hv_netvsc]
Feb 26 22:35:14 devlabo kernel: [37398.788190] [<ffffffffa009de5f>] ? netvsc_channel_cb+0x37a/0x449 [hv_netvsc]
Feb 26 22:35:14 devlabo kernel: [37398.788196] [<ffffffffa000111b>] ? vmbus_on_event+0x91/0xdd [hv_vmbus]
Feb 26 22:35:14 devlabo kernel: [37398.788200] [<ffffffff8104b89a>] ? tasklet_action+0x73/0xc2
Feb 26 22:35:14 devlabo kernel: [37398.788203] [<ffffffff8104c084>] ? __do_softirq+0xb9/0x177
Feb 26 22:35:14 devlabo kernel: [37398.788207] [<ffffffff81061755>] ? run_posix_cpu_timers+0x23/0x346
Feb 26 22:35:14 devlabo kernel: [37398.788211] [<ffffffff8135426c>] ? call_softirq+0x1c/0x30
Feb 26 22:35:14 devlabo kernel: [37398.788216] [<ffffffff8100f8dd>] ? do_softirq+0x3c/0x7b
Feb 26 22:35:14 devlabo kernel: [37398.788218] [<ffffffff8104c2ec>] ? irq_exit+0x3c/0x9a
Feb 26 22:35:14 devlabo kernel: [37398.788222] [<ffffffff810241c8>] ? smp_apic_timer_interrupt+0x74/0x82
Feb 26 22:35:14 devlabo kernel: [37398.788225] [<ffffffff81352ade>] ? apic_timer_interrupt+0x6e/0x80
Feb 26 22:35:14 devlabo kernel: [37398.788227] <EOI> [<ffffffff81013a17>] ? native_sched_clock+0x27/0x2f
Feb 26 22:35:14 devlabo kernel: [37398.788233] [<ffffffff8102b360>] ? native_safe_halt+0x2/0x3
Feb 26 22:35:14 devlabo kernel: [37398.788236] [<ffffffff81014508>] ? default_idle+0x47/0x7f
Feb 26 22:35:14 devlabo kernel: [37398.788238] [<ffffffff8100d24d>] ? cpu_idle+0xaf/0xf2
Feb 26 22:35:14 devlabo kernel: [37398.788241] [<ffffffff816abb33>] ? start_kernel+0x3b3/0x3be
Feb 26 22:35:14 devlabo kernel: [37398.788244] [<ffffffff816ab140>] ? early_idt_handlers+0x140/0x140
Feb 26 22:35:14 devlabo kernel: [37398.788247] [<ffffffff816ab3c4>] ? x86_64_start_kernel+0x104/0x111
Feb 26 22:35:14 devlabo kernel: [37398.788249] ---[ end trace 8f3991272dc0c5cc ]---
Feb 26 22:35:14 devlabo kernel: [37398.789256] hv_vmbus: child device vmbus_0_8 unregistered
Feb 3 22:31:55 devlabo kernel: [37819.617243] ------------[ cut here ]------------
Feb 3 22:31:55 devlabo kernel: [37819.617253] WARNING: at /build/buildd-linux_3.2.35-2-amd64-v9djlH/linux-3.2.35/kernel/softirq.c:159 _local_bh_enable_ip.isra.11+0x3d/0x88()
Feb 3 22:31:55 devlabo kernel: [37819.617257] Hardware name: Virtual Machine
Feb 3 22:31:55 devlabo kernel: [37819.617259] Modules linked in: nfsd nfs nfs_acl auth_rpcgss lockd sunrpc des_generic ecb md4 hmac nls_utf8 cifs fscache loop joydev snd_pcm hid_hyperv hid snd_page_alloc snd_timer snd hv_utils i2c_piix4 i2c_core soundcore processor psmouse crc32c_intel thermal_sys button pcspkr evdev serio_raw ext4 crc16 jbd2 mbcache sd_mod crc_t10dif hv_netvsc hv_storvsc sg sr_mod cdrom ata_generic hv_vmbus ata_piix floppy libata scsi_mod [last unloaded: scsi_wait_scan]
Feb 3 22:31:55 devlabo kernel: [37819.617308] Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.35-2
Feb 3 22:31:55 devlabo kernel: [37819.617311] Call Trace:
Feb 3 22:31:55 devlabo kernel: [37819.617313] <IRQ> [<ffffffff81046a75>] ? warn_slowpath_common+0x78/0x8c
Feb 3 22:31:55 devlabo kernel: [37819.617324] [<ffffffff8104bf76>] ? _local_bh_enable_ip.isra.11+0x3d/0x88
Feb 3 22:31:55 devlabo kernel: [37819.617331] [<ffffffffa00a09b5>] ? rndis_filter_receive+0x236/0x259 [hv_netvsc]
Feb 3 22:31:55 devlabo kernel: [37819.617339] [<ffffffffa009fe5f>] ? netvsc_channel_cb+0x37a/0x449 [hv_netvsc]
Feb 3 22:31:55 devlabo kernel: [37819.617347] [<ffffffffa006211b>] ? vmbus_on_event+0x91/0xdd [hv_vmbus]
Feb 3 22:31:55 devlabo kernel: [37819.617353] [<ffffffff8104b89a>] ? tasklet_action+0x73/0xc2
Feb 3 22:31:55 devlabo kernel: [37819.617357] [<ffffffff8104c084>] ? __do_softirq+0xb9/0x177
Feb 3 22:31:55 devlabo kernel: [37819.617362] [<ffffffff81061755>] ? run_posix_cpu_timers+0x23/0x346
Feb 3 22:31:55 devlabo kernel: [37819.617366] [<ffffffff8104c350>] ? raise_softirq_irqoff+0x6/0x25
Feb 3 22:31:55 devlabo kernel: [37819.617372] [<ffffffff8135426c>] ? call_softirq+0x1c/0x30
Feb 3 22:31:55 devlabo kernel: [37819.617378] [<ffffffff8100f8dd>] ? do_softirq+0x3c/0x7b
Feb 3 22:31:55 devlabo kernel: [37819.617382] [<ffffffff8104c2ec>] ? irq_exit+0x3c/0x9a
Feb 3 22:31:55 devlabo kernel: [37819.617387] [<ffffffff810241c8>] ? smp_apic_timer_interrupt+0x74/0x82
Feb 3 22:31:55 devlabo kernel: [37819.617391] [<ffffffff81352ade>] ? apic_timer_interrupt+0x6e/0x80
Feb 3 22:31:55 devlabo kernel: [37819.617394] <EOI> [<ffffffff81013a17>] ? native_sched_clock+0x27/0x2f
Feb 3 22:31:55 devlabo kernel: [37819.617402] [<ffffffff8102b360>] ? native_safe_halt+0x2/0x3
Feb 3 22:31:55 devlabo kernel: [37819.617407] [<ffffffff81014508>] ? default_idle+0x47/0x7f
Feb 3 22:31:55 devlabo kernel: [37819.617411] [<ffffffff8100d24d>] ? cpu_idle+0xaf/0xf2
Feb 3 22:31:55 devlabo kernel: [37819.617415] [<ffffffff816abb33>] ? start_kernel+0x3b3/0x3be
Feb 3 22:31:55 devlabo kernel: [37819.617420] [<ffffffff816ab140>] ? early_idt_handlers+0x140/0x140
Feb 3 22:31:55 devlabo kernel: [37819.617424] [<ffffffff816ab3c4>] ? x86_64_start_kernel+0x104/0x111
Feb 3 22:31:55 devlabo kernel: [37819.617427] ---[ end trace a20acc0adc92e993 ]---
Feb 3 22:31:55 devlabo kernel: [37819.618127] hv_vmbus: child device vmbus_0_8 unregistered
It does not happen every day, but quite often : 4 times in February
I'll ask my sysadm if there's something special at 22h30 in the host,
because it's always happening around this time.
Machine is debian wheezy (7) under windows server 2008 R2
Regards
Richard
^ permalink raw reply
* [PATCH] net/rds: using strlcpy instead of strncpy
From: Chen Gang @ 2013-02-28 8:28 UTC (permalink / raw)
To: venkat.x.venkatsubra, David Miller, rds-devel, netdev
when src strlen is sizeof(ctr.name) - 1, the dest str is not '\0' end.
better use strlcpy instead.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
net/rds/stats.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/rds/stats.c b/net/rds/stats.c
index 7be790d..b9ac1df 100644
--- a/net/rds/stats.c
+++ b/net/rds/stats.c
@@ -86,7 +86,7 @@ void rds_stats_info_copy(struct rds_info_iterator *iter,
for (i = 0; i < nr; i++) {
BUG_ON(strlen(names[i]) >= sizeof(ctr.name));
- strncpy(ctr.name, names[i], sizeof(ctr.name) - 1);
+ strlcpy(ctr.name, names[i], sizeof(ctr.name));
ctr.value = values[i];
rds_info_copy(iter, &ctr, sizeof(ctr));
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH 3/5] wl1251: call pm_runtime_put_sync in pm_runtime_get_sync failed case
From: Luciano Coelho @ 2013-02-28 8:18 UTC (permalink / raw)
To: Li Fei
Cc: linville, wfp5p, gregkh, notasas, rjw, linux-wireless, netdev,
linux-kernel, chuansheng.liu
In-Reply-To: <1362037892.6212.13.camel@fli24-HP-Compaq-8100-Elite-CMT-PC>
On Thu, 2013-02-28 at 15:51 +0800, Li Fei wrote:
> Even in failed case of pm_runtime_get_sync, the usage_count
> is incremented. In order to keep the usage_count with correct
> value and runtime power management to behave correctly, call
> pm_runtime_put(_sync) in such case.
>
> Signed-off-by Liu Chuansheng <chuansheng.liu@intel.com>
> Signed-off-by: Li Fei <fei.li@intel.com>
> ---
Looks good. I'll apply this via my tree.
Thanks!
--
Luca.
^ permalink raw reply
* [PATCH ethtool] Restore 20000baseKR2 cap display
From: Yaniv Rosner @ 2013-02-28 10:10 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Yaniv Rosner
Restore the 20000baseKR2 which was removed by mistake back in June 2012.
Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
---
ethtool.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 55bc082..acac32a 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -513,6 +513,7 @@ dump_link_caps(const char *prefix, const char *an_prefix, u32 mask,
{ 0, ADVERTISED_10000baseT_Full, "10000baseT/Full" },
{ 0, ADVERTISED_10000baseKX4_Full, "10000baseKX4/Full" },
{ 0, ADVERTISED_20000baseMLD2_Full, "20000baseMLD2/Full" },
+ { 0, ADVERTISED_20000baseKR2_Full, "20000baseKR2/Full" },
{ 0, ADVERTISED_40000baseKR4_Full, "40000baseKR4/Full" },
{ 0, ADVERTISED_40000baseCR4_Full, "40000baseCR4/Full" },
{ 0, ADVERTISED_40000baseSR4_Full, "40000baseSR4/Full" },
--
1.7.7.1
^ permalink raw reply related
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