* Code flow: tcp_input.c : tcp_prune_queue : Dropping frames
From: Mitchell Erblich @ 2010-06-21 21:25 UTC (permalink / raw)
To: netdev
group,
The tcp_prune_queue() calls tcp_collapse() is called to
prevent frames/pkts from being dropped due to buffer
?"ooo"? overcommit.
However, tcp_collapse() calls alloc_skb() with GFP_ATOMIC
which can grab the last of reserveable memory.
nskb = alloc_skb(copy + header, GFP_ATOMIC);
if (!nskb)
return;
It should be called with GFP_NOWAIT to keep the NON-SLEEP
aspect of the mem reservation, but not grap the last bits of mem.
Because, if the over-commit was that bad, all other allocations
have ALREADY STARTED TO FAIL. The system SHOULD be
dead.
Secondly, if the alloc failed, why try to do the reclaim?
Thus,
tcp_collapse() should return int instead of void and the
alloc return should return -1 upon failure.
tcp_prune_queue_should check for the return and skip
sk_mem_reclaim().
Why not some logging message?
Didn't see one.
Rename ofo to "ooo" as this is known as "out-of-order".
Lastly, follow-up should be done to identify the GFP_ mem
type and SHOULD not be alloc'ing mem with ATOMIC
for an "out-of-order" queue as this COULD be a form of
DENIAL of Service (DoS) attack.
Mitchell Erblich
^ permalink raw reply
* Re: [Bugme-new] [Bug 16187] New: Carrier detection failed in dhcpcd when link is up
From: Andrew Morton @ 2010-06-21 21:21 UTC (permalink / raw)
To: Allan, Bruce W
Cc: Grant Grundler, netdev@vger.kernel.org, Kyle McMartin,
bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org, casteyde.christian@free.fr,
YOSHIFUJI Hideaki
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A900158F12BEA@orsmsx509.amr.corp.intel.com>
On Fri, 18 Jun 2010 08:04:36 -0700
"Allan, Bruce W" <bruce.w.allan@intel.com> wrote:
> On Thursday, June 17, 2010 11:17 PM, Grant Grundler wrote:
> > On Tue, Jun 15, 2010 at 02:24:18PM -0700, Andrew Morton wrote:
> >>
> >> (switched to email. Please respond via emailed reply-to-all, not
> >> via the bugzilla web interface).
> >
> > I've resync to linus' tree (2.6.35-rc3) and reviewed the output of:
> > git diff v2.6.34 drivers/net/tulip/
> >
> > I don't see anything that would affect how link state
> > changes get reported to user space.
> >
> > I'm not inclined to believe this is a tulip "bug" unless
> > core netdev behavior changed and tulip is not longer
> > doing the right thing.
> >
> > hth,
> > grant
>
> I don't believe this is a tulip specific bug - the same thing has been reported against e1000e and bnx2 (IIRC); I have not had the time to investigate further.
So it's affecting three drivers.
One thing which changed in there recently is
: commit b2db756449f63f98049587f7ede4a8e85e0c79b1
: Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
: AuthorDate: Sat Mar 20 16:11:12 2010 -0700
: Commit: David S. Miller <davem@davemloft.net>
: CommitDate: Sat Mar 20 16:11:12 2010 -0700
:
: ipv6: Reduce timer events for addrconf_verify().
So perhaps someone could test the simple reversion patch, below?
I couldn't locate these e1000e and bnx2 bug reports so I couldn't cc
the reporters :(
I'm seeing several patches on netdev "use netif_carrier_off to prevent
tx timeout". Is that related?
net/ipv6/addrconf.c | 27 ++++-----------------------
1 file changed, 4 insertions(+), 23 deletions(-)
diff -puN net/ipv6/addrconf.c~revert-2 net/ipv6/addrconf.c
--- a/net/ipv6/addrconf.c~revert-2
+++ a/net/ipv6/addrconf.c
@@ -100,10 +100,6 @@
#define INFINITY_LIFE_TIME 0xFFFFFFFF
#define TIME_DELTA(a, b) ((unsigned long)((long)(a) - (long)(b)))
-#define ADDRCONF_TIMER_FUZZ_MINUS (HZ > 50 ? HZ/50 : 1)
-#define ADDRCONF_TIMER_FUZZ (HZ / 4)
-#define ADDRCONF_TIMER_FUZZ_MAX (HZ)
-
#ifdef CONFIG_SYSCTL
static void addrconf_sysctl_register(struct inet6_dev *idev);
static void addrconf_sysctl_unregister(struct inet6_dev *idev);
@@ -3159,15 +3155,15 @@ int ipv6_chk_home_addr(struct net *net,
static void addrconf_verify(unsigned long foo)
{
- unsigned long now, next, next_sec, next_sched;
struct inet6_ifaddr *ifp;
struct hlist_node *node;
+ unsigned long now, next;
int i;
rcu_read_lock_bh();
spin_lock(&addrconf_verify_lock);
now = jiffies;
- next = round_jiffies_up(now + ADDR_CHECK_FREQUENCY);
+ next = now + ADDR_CHECK_FREQUENCY;
del_timer(&addr_chk_timer);
@@ -3181,8 +3177,7 @@ restart:
continue;
spin_lock(&ifp->lock);
- /* We try to batch several events at once. */
- age = (now - ifp->tstamp + ADDRCONF_TIMER_FUZZ_MINUS) / HZ;
+ age = (now - ifp->tstamp) / HZ;
if (ifp->valid_lft != INFINITY_LIFE_TIME &&
age >= ifp->valid_lft) {
@@ -3252,21 +3247,7 @@ restart:
}
}
- next_sec = round_jiffies_up(next);
- next_sched = next;
-
- /* If rounded timeout is accurate enough, accept it. */
- if (time_before(next_sec, next + ADDRCONF_TIMER_FUZZ))
- next_sched = next_sec;
-
- /* And minimum interval is ADDRCONF_TIMER_FUZZ_MAX. */
- if (time_before(next_sched, jiffies + ADDRCONF_TIMER_FUZZ_MAX))
- next_sched = jiffies + ADDRCONF_TIMER_FUZZ_MAX;
-
- ADBG((KERN_DEBUG "now = %lu, schedule = %lu, rounded schedule = %lu => %lu\n",
- now, next, next_sec, next_sched));
-
- addr_chk_timer.expires = next_sched;
+ addr_chk_timer.expires = time_before(next, jiffies + HZ) ? jiffies + HZ : next;
add_timer(&addr_chk_timer);
spin_unlock(&addrconf_verify_lock);
rcu_read_unlock_bh();
_
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: Joe Perches @ 2010-06-21 21:22 UTC (permalink / raw)
To: Jiri Pirko; +Cc: David Miller, netdev
In-Reply-To: <20100621204411.GL2656@psychotron.bos.redhat.com>
On Mon, 2010-06-21 at 22:44 +0200, Jiri Pirko wrote:
> Mon, Jun 21, 2010 at 10:38:06PM CEST, davem@davemloft.net wrote:
> >From: Jiri Pirko <jpirko@redhat.com>
> >Date: Mon, 21 Jun 2010 21:34:06 +0200
> >> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> >> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> >Jiri, it is used by every single pr_*() logging call made
> >in this file.
> >I was hoping that this facilty and the voluminous amounty of pervasive
> >usage of this in the networking drivers nowadays would make it
> >familiar to active hackers like you :-)
>
> Ough, right, missed that. That's just strange. I don't like this.
At some point in the future, this
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
should be the default in kernel.h and only files that
want to change the setting should add it.
Then all the current uses (~175) in the rest of the
sources would be superfluous and could be removed.
I've plans to eventually convert the pr_<level> macros
to functions using a vsnprintf %pV mechanism.
see: http://lkml.org/lkml/2010/3/5/33
The KBUILD_MODNAME could also be emitted by the
pr_<level> functions rather than stored in
the format string to save quite a bit of text.
Something like below would be a start:
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8317ec4..41544c8 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -378,7 +378,7 @@ static inline char *pack_hex_byte(char *buf, u8 byte)
extern int hex_to_bin(char ch);
#ifndef pr_fmt
-#define pr_fmt(fmt) fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#endif
#define pr_emerg(fmt, ...) \
^ permalink raw reply related
* Re: [PATCH] Fix a typo in netlink.h
From: Justin P. Mattock @ 2010-06-21 21:05 UTC (permalink / raw)
To: David Miller; +Cc: trivial, netdev
In-Reply-To: <20100621.134554.59686098.davem@davemloft.net>
On 06/21/2010 01:45 PM, David Miller wrote:
> From: "Justin P. Mattock"<justinmattock@gmail.com>
> Date: Fri, 18 Jun 2010 21:29:53 -0700
>
>> Fix a typo in include/net/netlink.h
>> should be finalize instead of finanlize
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>
> Applied, thanks.
>
o.k...
Justin P. Mattock
^ permalink raw reply
* [PATCH] ipv6: fix NULL reference in proxy neighbor discovery
From: Stephen Hemminger @ 2010-06-21 21:00 UTC (permalink / raw)
To: Andreas Klauer, David Miller; +Cc: Hagen Paul Pfeifer, netdev, Octavian Purdila
In-Reply-To: <20100621200413.GA2280@EIS>
The addition of TLLAO option created a kernel OOPS regression
for the case where neighbor advertisement is being sent via
proxy path. When using proxy, ipv6_get_ifaddr() returns NULL
causing the NULL dereference.
Change causing the bug was:
commit f7734fdf61ec6bb848e0bafc1fb8bad2c124bb50
Author: Octavian Purdila <opurdila@ixiacom.com>
Date: Fri Oct 2 11:39:15 2009 +0000
make TLLAO option for NA packets configurable
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Patch for -net and -stable.
Applies to 2.6.33 and later.
--- a/net/ipv6/ndisc.c 2010-06-11 08:13:13.008657498 -0700
+++ b/net/ipv6/ndisc.c 2010-06-21 13:52:57.961486303 -0700
@@ -586,6 +586,7 @@ static void ndisc_send_na(struct net_dev
src_addr = solicited_addr;
if (ifp->flags & IFA_F_OPTIMISTIC)
override = 0;
+ inc_opt |= ifp->idev->cnf.force_tllao;
in6_ifa_put(ifp);
} else {
if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
@@ -599,7 +600,6 @@ static void ndisc_send_na(struct net_dev
icmp6h.icmp6_solicited = solicited;
icmp6h.icmp6_override = override;
- inc_opt |= ifp->idev->cnf.force_tllao;
__ndisc_send(dev, neigh, daddr, src_addr,
&icmp6h, solicited_addr,
inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
^ permalink raw reply
* Re: udp: Fix bogus UFO packet generation
From: David Miller @ 2010-06-21 20:57 UTC (permalink / raw)
To: mst; +Cc: herbert, netdev
In-Reply-To: <20100615121530.GC2361@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 15 Jun 2010 15:15:30 +0300
> On Tue, Jun 15, 2010 at 09:52:25PM +1000, Herbert Xu wrote:
>> Hi:
>>
>> udp: Fix bogus UFO packet generation
>>
>> It has been reported that the new UFO software fallback path
>> fails under certain conditions with NFS. I tracked the problem
>> down to the generation of UFO packets that are smaller than the
>> MTU. The software fallback path simply discards these packets.
>>
>> This patch fixes the problem by not generating such packets on
>> the UFO path.
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> FWIW
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: consolidate netif_needs_gso() checks
From: David Miller @ 2010-06-21 20:55 UTC (permalink / raw)
To: herbert; +Cc: jeffrey.t.kirsher, netdev, gospo, bphilips, john.r.fastabend
In-Reply-To: <20100617101857.GA1053@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 17 Jun 2010 20:18:57 +1000
> On Wed, Jun 16, 2010 at 05:18:12PM -0700, Jeff Kirsher wrote:
>> From: John Fastabend <john.r.fastabend@intel.com>
>>
>> netif_needs_gso() is checked twice in the TX path once,
>> before submitting the skb to the qdisc and once after
>> it is dequeued from the qdisc just before calling
>> ndo_hard_start(). This opens a window for a user to
>> change the gso/tso or tx checksum settings that can
>> cause netif_needs_gso to be true in one check and false
>> in the other.
>>
>> Specifically, changing TX checksum setting may cause
>> the warning in skb_gso_segment() to be triggered if
>> the checksum is calculated earlier.
>>
>> This consolidates the netif_needs_gso() calls so that
>> the stack only checks if gso is needed in
>> dev_hard_start_xmit().
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] lasi82596: fix netdev_mc_count conversion
From: David Miller @ 2010-06-21 20:50 UTC (permalink / raw)
To: deller; +Cc: linux-kernel, torvalds, linux-parisc, kyle, jpirko, netdev
In-Reply-To: <20100619224139.GA6158@p100.box>
From: Helge Deller <deller@gmx.de>
Date: Sun, 20 Jun 2010 00:41:39 +0200
> Fix commit 4cd24eaf0 (net: use netdev_mc_count and netdev_mc_empty when
> appropriate)
>
> Signed-off-by: Helge Deller <deller@gmx.de>
Applied, please CC: netdev@vger.kernel.org when posting networking
patches in the future, thanks.
> CC: Linus Torvalds <torvalds@linux-foundation.org>
> CC: Kyle McMartin <kyle@mcmartin.ca>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Jiri Pirko <jpirko@redhat.com>
>
> --- a/drivers/net/lib82596.c
> +++ b/drivers/net/lib82596.c
> @@ -1343,7 +1343,7 @@ static void set_multicast_list(struct net_device *dev)
> DEB(DEB_MULTI,
> printk(KERN_DEBUG
> "%s: set multicast list, %d entries, promisc %s, allmulti %s\n",
> - dev->name, dev->mc_count,
> + dev->name, netdev_mc_count(dev),
> dev->flags & IFF_PROMISC ? "ON" : "OFF",
> dev->flags & IFF_ALLMULTI ? "ON" : "OFF"));
>
>
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Mitchell Erblich @ 2010-06-21 20:49 UTC (permalink / raw)
To: Peter P Waskiewicz Jr
Cc: Ben Hutchings, Kirsher, Jeffrey T, jeff@garzik.org,
davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <Pine.WNT.4.64.1006211326380.4956@PPWASKIE-MOBL2.amr.corp.intel.com>
On Jun 21, 2010, at 1:31 PM, Peter P Waskiewicz Jr wrote:
> On Mon, 21 Jun 2010, Ben Hutchings wrote:
>
>> On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote:
>>> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>>>
>>> Program underlying ethernet devices with n-tuple flow classification
>>> filters.
>>>
>>> This also adds a new flag to ethtool_flags, allowing n-tuple
>>> programming to be toggled using the set_flags call.
>>
>> I just noticed a problem with the implementation which makes me wonder
>> whether this was tested at all:
>
> Yes, it was tested. We didn't hit every corner case, which I think your catch below is a corner case issue. Our hardware can only do so much.
>
>>
>> [...]
>>> +static struct cmdline_info cmdline_ntuple[] = {
>>> + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL },
>>> + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL },
>>> + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL },
>>> + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL },
>>> + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL },
>>> + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL },
>>> + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL },
>>> + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL },
>>> + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL },
>>> + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL },
>>> + { "user-def", CMDL_INT, &ntuple_fs.data, NULL },
>>> + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL },
>>> + { "action", CMDL_INT, &ntuple_fs.action, NULL },
>>> +};
>> [...]
>>> + if (mode == MODE_SNTUPLE) {
>>> + if (!strcmp(argp[i], "flow-type")) {
>>> + i += 1;
Why not " i++; " ?
>>> + if (i >= argc) {
>>> + show_usage(1);
>>> + break;
>>> + }
>>> + ntuple_fs.flow_type =
>>> + rxflow_str_to_type(argp[i]);
>>> + i += 1;
Why not " i++; " ?
>>> + parse_generic_cmdline(argc, argp, i,
>>> + &sntuple_changed,
>>> + cmdline_ntuple,
>>> + ARRAY_SIZE(cmdline_ntuple));
>>> + i = argc;
>>> + break;
>>> + } else {
>>> + show_usage(1);
>>> + }
>>> + break;
>>> + }
>> [...]
>>
>> parse_generic_cmdline() will write an int for each argument defined with
>> type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of
>> type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some
>> of them are big-endian. I also wonder whether anyone really wants to
>> enter an IPv4 address as a single integer.
>
> The assignment is broken since 'p' is an int. That can be fixed. Also, we can fix the 64-bit field. I added the user-defined field to be 64-bit so that we weren't locking anyone down. My hardware only uses 2 bytes, so I was only able to test that.
>
> When this was proposed, we added the IPv4 address as a single int. People seemed ok with it at the time, so we went with it. If you have a different approach, please present it.
>
> Cheers,
> -PJ
Without changing the flow:
NIT cleanup.
See inline.
Mitchell Erblich
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [PATCH] gainfar.c : skb_over_panic
From: David Miller @ 2010-06-21 20:47 UTC (permalink / raw)
To: liberty; +Cc: galak, netdev
In-Reply-To: <4C1F2D39.9050804@extricom.com>
From: Eran Liberty <liberty@extricom.com>
Date: Mon, 21 Jun 2010 12:13:29 +0300
> I have compared the suggested patch with what the function
> skb_recycle_check() does. Both patch and skb_recycle_check()
> have skb_reset_tail_pointer(). While the patch zero only skb->len,
> skb_recycle_check()
> clears the whole skb (up to tail). On top of that skb_recycle_check()
> preforms a whole set of other checks and cleanups. The question is,
> which action is MORE correct: the pin-point action of the patch
> suggested or the broader checks of skb_recycle_check() function?
At this stage in the code we know exactly what modifications, if any,
we've made to the SKB state. Therefore it makes sense to only fix
up the tiny amount of changes we've made instead of doing a complete
skb_recycle_call() which seems entirely excessive in this situation.
^ permalink raw reply
* Re: [PATCH] Fix a typo in netlink.h
From: David Miller @ 2010-06-21 20:45 UTC (permalink / raw)
To: justinmattock; +Cc: trivial, netdev
In-Reply-To: <1276921793-24147-1-git-send-email-justinmattock@gmail.com>
From: "Justin P. Mattock" <justinmattock@gmail.com>
Date: Fri, 18 Jun 2010 21:29:53 -0700
> Fix a typo in include/net/netlink.h
> should be finalize instead of finanlize
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: Jiri Pirko @ 2010-06-21 20:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100621.133806.226761715.davem@davemloft.net>
Mon, Jun 21, 2010 at 10:38:06PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jpirko@redhat.com>
>Date: Mon, 21 Jun 2010 21:34:06 +0200
>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>...
>> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> -
>
>Jiri, it is used by every single pr_*() logging call made
>in this file.
>
>I was hoping that this facilty and the voluminous amounty of pervasive
>usage of this in the networking drivers nowadays would make it
>familiar to active hackers like you :-)
Ough, right, missed that. That's just strange. I don't like this.
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" 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: [net-next-2.6 PATCH 4/4] e1000e: disable gig speed when in S0->Sx transition
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045946.6728.12416.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:59:48 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Most of this workaround is necessary for all ICHx/PCH parts so one of
> the two MAC-type checks can be removed.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] e1000e: packet split should not be used with early receive
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045925.6728.43858.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:59:27 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Originally it was thought there were issues with ICHx/PCH parts with packet
> split when jumbo frames were enabled but in fact it is really only when
> early-receive is enabled (via ERT register) on these parts. Use packet
> split with jumbos but only when early-receive is not enabled.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/4] e1000e: do not touch PHY page 800 registers when link speed is 1000Mbps
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045904.6728.18894.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:59:06 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The PHY on 82577/82578 has issues when the registers on page 800 are
> accessed when in gigabit mode. Do not clear the Wakeup Control register
> when resetting the part since it is on page 800 (and will be cleared on
> reset anyway).
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/4] e1000e: avoid polling h/w registers during link negotiation
From: David Miller @ 2010-06-21 20:43 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bruce.w.allan
In-Reply-To: <20100618045804.6728.37945.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Jun 2010 21:58:43 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> Avoid touching hardware registers when possible, otherwise link negotiation
> can get messed up when user-level scripts are rapidly polling the driver to
> see if/when link is up. Use the saved link state information instead when
> possible.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] NET: MIPSsim: Fix modpost warning.
From: David Miller @ 2010-06-21 20:40 UTC (permalink / raw)
To: ralf; +Cc: netdev
In-Reply-To: <20100621134450.GA10265@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 21 Jun 2010 14:44:50 +0100
> $ make CONFIG_DEBUG_SECTION_MISMATCH=y
> [...]
> WARNING: drivers/net/built-in.o(.data+0x0): Section mismatch in reference from the variable mipsnet_driver to the function .init.text:mipsnet_probe()
> The variable mipsnet_driver references
> the function __init mipsnet_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
> [...]
>
> Fixed by making mipsnet_probe __devinit.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks Ralf.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: David Miller @ 2010-06-21 20:38 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100621193405.GG2656@psychotron.bos.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Mon, 21 Jun 2010 21:34:06 +0200
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
...
> -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> -
Jiri, it is used by every single pr_*() logging call made
in this file.
I was hoping that this facilty and the voluminous amounty of pervasive
usage of this in the networking drivers nowadays would make it
familiar to active hackers like you :-)
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Peter P Waskiewicz Jr @ 2010-06-21 20:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, jeff@garzik.org, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1277150272.2100.47.camel@achroite.uk.solarflarecom.com>
On Mon, 21 Jun 2010, Ben Hutchings wrote:
> On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote:
>> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>>
>> Program underlying ethernet devices with n-tuple flow classification
>> filters.
>>
>> This also adds a new flag to ethtool_flags, allowing n-tuple
>> programming to be toggled using the set_flags call.
>
> I just noticed a problem with the implementation which makes me wonder
> whether this was tested at all:
Yes, it was tested. We didn't hit every corner case, which I think your
catch below is a corner case issue. Our hardware can only do so much.
>
> [...]
>> +static struct cmdline_info cmdline_ntuple[] = {
>> + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL },
>> + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL },
>> + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL },
>> + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL },
>> + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL },
>> + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL },
>> + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL },
>> + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL },
>> + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL },
>> + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL },
>> + { "user-def", CMDL_INT, &ntuple_fs.data, NULL },
>> + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL },
>> + { "action", CMDL_INT, &ntuple_fs.action, NULL },
>> +};
> [...]
>> + if (mode == MODE_SNTUPLE) {
>> + if (!strcmp(argp[i], "flow-type")) {
>> + i += 1;
>> + if (i >= argc) {
>> + show_usage(1);
>> + break;
>> + }
>> + ntuple_fs.flow_type =
>> + rxflow_str_to_type(argp[i]);
>> + i += 1;
>> + parse_generic_cmdline(argc, argp, i,
>> + &sntuple_changed,
>> + cmdline_ntuple,
>> + ARRAY_SIZE(cmdline_ntuple));
>> + i = argc;
>> + break;
>> + } else {
>> + show_usage(1);
>> + }
>> + break;
>> + }
> [...]
>
> parse_generic_cmdline() will write an int for each argument defined with
> type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of
> type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some
> of them are big-endian. I also wonder whether anyone really wants to
> enter an IPv4 address as a single integer.
The assignment is broken since 'p' is an int. That can be fixed. Also,
we can fix the 64-bit field. I added the user-defined field to be 64-bit
so that we weren't locking anyone down. My hardware only uses 2 bytes, so
I was only able to test that.
When this was proposed, we added the IPv4 address as a single int. People
seemed ok with it at the time, so we went with it. If you have a
different approach, please present it.
Cheers,
-PJ
^ permalink raw reply
* Re: 2.6.34 + IPv6: Oops?
From: Andreas Klauer @ 2010-06-21 20:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Hagen Paul Pfeifer, netdev, Octavian Purdila
In-Reply-To: <20100621102508.2075d677@nehalam>
On Mon, Jun 21, 2010 at 10:25:08AM -0700, Stephen Hemminger wrote:
> It is not handling the case of ifp == NULL.
>
> Maybe the following (move the assignment into the if block).
>
> --- a/net/ipv6/ndisc.c 2010-06-21 10:22:20.825637690 -0700
> +++ b/net/ipv6/ndisc.c 2010-06-21 10:24:31.573011996 -0700
> @@ -586,6 +586,7 @@ static void ndisc_send_na(struct net_dev
> src_addr = solicited_addr;
> if (ifp->flags & IFA_F_OPTIMISTIC)
> override = 0;
> + inc_opt |= ifp->idev->cnf.force_tllao;
> in6_ifa_put(ifp);
> } else {
> if (ipv6_dev_get_saddr(dev_net(dev), dev, daddr,
> @@ -599,7 +600,6 @@ static void ndisc_send_na(struct net_dev
> icmp6h.icmp6_solicited = solicited;
> icmp6h.icmp6_override = override;
>
> - inc_opt |= ifp->idev->cnf.force_tllao;
> __ndisc_send(dev, neigh, daddr, src_addr,
> &icmp6h, solicited_addr,
> inc_opt ? ND_OPT_TARGET_LL_ADDR : 0);
>
>
>
Thanks a lot! This fix seems to work fine for me (tested locally only).
I'll see what happens when I apply it to my server tomorrow.
Curious though as to why I wasn't able to reproduce it when compiling
the kernel with Gentoo's GCC. It doesn't look like it should make any
difference. Maybe I made a mistake when I tested it with Gentoo.
Regards
Andreas Klauer
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Ben Hutchings @ 2010-06-21 19:57 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: jeff, davem, netdev, gospo, Peter P Waskiewicz Jr
In-Reply-To: <20100204075101.16661.95658.stgit@localhost.localdomain>
On Wed, 2010-02-03 at 23:51 -0800, Jeff Kirsher wrote:
> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
>
> Program underlying ethernet devices with n-tuple flow classification
> filters.
>
> This also adds a new flag to ethtool_flags, allowing n-tuple
> programming to be toggled using the set_flags call.
I just noticed a problem with the implementation which makes me wonder
whether this was tested at all:
[...]
> +static struct cmdline_info cmdline_ntuple[] = {
> + { "src-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4src, NULL },
> + { "src-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4src, NULL },
> + { "dst-ip", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.ip4dst, NULL },
> + { "dst-ip-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.ip4dst, NULL },
> + { "src-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.psrc, NULL },
> + { "src-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.psrc, NULL },
> + { "dst-port", CMDL_INT, &ntuple_fs.h_u.tcp_ip4_spec.pdst, NULL },
> + { "dst-port-mask", CMDL_UINT, &ntuple_fs.m_u.tcp_ip4_spec.pdst, NULL },
> + { "vlan", CMDL_INT, &ntuple_fs.vlan_tag, NULL },
> + { "vlan-mask", CMDL_UINT, &ntuple_fs.vlan_tag_mask, NULL },
> + { "user-def", CMDL_INT, &ntuple_fs.data, NULL },
> + { "user-def-mask", CMDL_UINT, &ntuple_fs.data_mask, NULL },
> + { "action", CMDL_INT, &ntuple_fs.action, NULL },
> +};
[...]
> + if (mode == MODE_SNTUPLE) {
> + if (!strcmp(argp[i], "flow-type")) {
> + i += 1;
> + if (i >= argc) {
> + show_usage(1);
> + break;
> + }
> + ntuple_fs.flow_type =
> + rxflow_str_to_type(argp[i]);
> + i += 1;
> + parse_generic_cmdline(argc, argp, i,
> + &sntuple_changed,
> + cmdline_ntuple,
> + ARRAY_SIZE(cmdline_ntuple));
> + i = argc;
> + break;
> + } else {
> + show_usage(1);
> + }
> + break;
> + }
[...]
parse_generic_cmdline() will write an int for each argument defined with
type CMDL_INT or CMDL_UINT. But the fields in ntuple_fs are not all of
type int (or even 32-bit) - some of them are 16-bit or 64-bit, and some
of them are big-endian. I also wonder whether anyone really wants to
enter an IPv4 address as a single integer.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next-2.6] bonding: remove unused macro "pr_fmt""
From: Jiri Pirko @ 2010-06-21 19:34 UTC (permalink / raw)
To: netdev; +Cc: davem
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a95a41b..e079117 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -31,8 +31,6 @@
*
*/
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/types.h>
^ permalink raw reply related
* Re: PATCH: uninitialized memory access in tcp_parse_options
From: Mathieu Lacage @ 2010-06-21 19:10 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev
In-Reply-To: <3E37AD8C-208F-42B8-AA04-E0B294D909A8@earthlink.net>
On Mon, 2010-06-21 at 11:02 -0700, Mitchell Erblich wrote:
> The standard default for TCP with IPv4 is 536, which
> translates to 576 MTU.
>
> Thus, why don't you init mss to 536?
I don't know: I am not a tcp expert and I am not sure I really
understand the way this function is expected to be used by callers but I
sent a patch to make sure that someone would feel compelled to find the
right fix. It looks like callers of this function are expected to
initialize the fields themselves so, the idea of doing the
initialization in tcp_parse_options is probably bad.
Mathieu
--
Mathieu Lacage <mathieu.lacage@sophia.inria.fr>
Tel: +33 4 9238 5056
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:56 UTC (permalink / raw)
To: Nick Bowler
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <20100621135857.GA21159-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
On Monday, June 21, 2010, Nick Bowler wrote:
> On 00:11 Mon 21 Jun , Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
>
> Didn't see this one in the list:
>
> Why is kslowd accumulating so much CPU time?
> http://thread.gmane.org/gmane.linux.kernel/996907
Thanks, I'm going to add it to the list.
Rafael
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:54 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <1277074706.21312.8.camel@maxim-laptop>
On Monday, June 21, 2010, Maxim Levitsky wrote:
> On Mon, 2010-06-21 at 00:11 +0200, Rafael J. Wysocki wrote:
> > This message contains a list of some regressions from 2.6.34,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
> >
> > Each entry from the list will be sent additionally in an automatic reply
> > to this message with CCs to the people involved in reporting and handling
> > the issue.
> >
> >
> > Listed regressions statistics:
> >
> > Date Total Pending Unresolved
> > ----------------------------------------
> > 2010-06-21 46 37 26
> > 2010-06-09 15 13 10
> >
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16255
> > Subject : 2.6.35-rc3 deadlocks on semaphore operations
> > Submitter : Christoph Lameter <cl@linux-foundation.org>
> > Date : 2010-06-18 14:49 (3 days old)
> > Message-ID : <alpine.DEB.2.00.1006180940140.11575@router.home>
> > References : http://marc.info/?l=linux-kernel&m=127687262727707&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16248
> > Subject : inconsistent lock state
> > Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Date : 2010-06-15 11:24 (6 days old)
> > Message-ID : <20100615112434.GA3967@swordfish.minsk.epam.com>
> > References : http://marc.info/?l=linux-kernel&m=127660087625903&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16247
> > Subject : drm/i915 BUG with 2.6.35-rc
> > Submitter : Benny Halevy <bhalevy@panasas.com>
> > Date : 2010-06-14 22:38 (7 days old)
> > Message-ID : <4C16AF56.1040002@panasas.com>
> > References : http://marc.info/?l=linux-kernel&m=127655510531367&w=2
>
>
> Don't have time to test, but I confirm that running compiz without
> mode-setting (ubuntu 8.10) hangs the system. (device is i945)
> It might be related to few intel regressions on this list.
>
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> > Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2010-06-14 17:24 (7 days old)
> > Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
> I was hit by this bug. Fix is now present in iwlwifi tree.
> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=4d23e4e5eb50431426facf192354ad2506e2dd40
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16234
> > Subject : [2.6.35-rc3] reboot mutex 'bug'...
> > Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
> > Date : 2010-06-14 15:16 (7 days old)
> > Message-ID : <AANLkTimDcTnyEPmt2ZcCM1UWtn4AYKotiqyjobJApkO7@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127652861118933&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16232
> > Subject : 2.6.35-rc3 - WARNING:iwl_set_dynamic_key
> > Submitter : Mario Guenterberg <mario.guenterberg@googlemail.com>
> > Date : 2010-06-14 11:55 (7 days old)
> > Message-ID : <20100614115510.GA7904@guenti-laptop>
> > References : http://marc.info/?l=linux-kernel&m=127651695627147&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16230
> > Subject : inconsistent IN-HARDIRQ-W -> HARDIRQ-ON-W usage: fasync, 2.6.35-rc3
> > Submitter : Dominik Brodowski <linux@dominikbrodowski.net>
> > Date : 2010-06-13 9:53 (8 days old)
> > Message-ID : <20100613095305.GA13231@comet.dominikbrodowski.net>
> > References : http://marc.info/?l=linux-kernel&m=127642282208277&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
> > Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
> > Submitter : Brian Bloniarz <phunge0@hotmail.com>
> > Date : 2010-06-16 17:57 (5 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16222
> > Subject : 2.6.35-rc{12} regression: inactive console corrupted
> > Submitter : Pavel Machek <pavel@ucw.cz>
> > Date : 2010-06-12 10:33 (9 days old)
> > Message-ID : <20100612103321.GA1458@ucw.cz>
> > References : http://marc.info/?l=linux-kernel&m=127633882614501&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
> > Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-11 20:31 (10 days old)
> > Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16205
> > Subject : acpi: freeing invalid memtype bf799000-bf79a000
> > Submitter : Marcin Slusarz <marcin.slusarz@gmail.com>
> > Date : 2010-06-09 20:09 (12 days old)
> > Message-ID : <20100609200910.GA2876@joi.lan>
> > References : http://marc.info/?l=linux-kernel&m=127611427029914&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16201
> > Subject : SIOCGIWFREQ ioctl fails to get frequency info
> > Submitter : nuh <nuh@mailinator.net>
> > Date : 2010-06-14 10:45 (7 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16199
> > Subject : 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-07 18:14 (14 days old)
> > Message-ID : <AANLkTin2pPqOUx--9fIX3BH3e-cU6oCRufijcx_4ozx5@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127593447812015&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16198
> > Subject : Running make install over sshfs is painful now
> > Submitter : Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date : 2010-06-07 6:53 (14 days old)
> > Message-ID : <20100607065324.GA25590@core.coreip.homeip.net>
> > References : http://marc.info/?l=linux-kernel&m=127589362011138&w=2
> I confirm this.
> Its direct result of adding '+' to kernel version.
> This just causes only troubles.
> I suggest to have a config option for it.
Thanks for the updates.
Rafael
^ 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