[tip:perf/urgent] perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}
Commit-ID: e9024d519d892b38176cafd46f68a7c77412
Gitweb: https://git.kernel.org/tip/e9024d519d892b38176cafd46f68a7c77412
Author: David S. Miller
AuthorDate: Tue, 30 Oct 2018 12:12:26 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 31 Oct 2018 09:57:51 -0300
perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}
When processing using 'perf report -g caller', which is the default, we
ended up reverting the callchain entries received from the kernel, but
simply reverting throws away the information that tells that from a
point onwards the addresses are for userspace, kernel, guest kernel,
guest user, hypervisor.
The idea is that if we are walking backwards, for each cluster of
non-cpumode entries we have to first scan backwards for the next one and
use that for the cluster.
This seems silly and more expensive than it needs to be but it is enough
for a initial fix.
The code here is really complicated because it is intimately intertwined
with the lbr and branch handling, as well as this callchain order,
further fixes will be needed to properly take into account the cpumode
in those cases.
Another problem with ORDER_CALLER is that the NULL "0" IP that is at the
end of most callchains shows up at the top of the histogram because
every callchain contains it and with ORDER_CALLER it is the first entry.
Signed-off-by: David S. Miller
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Souvik Banerjee
Cc: Wang Nan
Cc: sta...@vger.kernel.org # 4.19
Link: https://lkml.kernel.org/n/tip-2wt3ayp6j2y2f2xowixa8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 111ae858cbcb..8ee8ab39d8ac 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2140,6 +2140,27 @@ static int resolve_lbr_callchain_sample(struct thread
*thread,
return 0;
}
+static int find_prev_cpumode(struct ip_callchain *chain, struct thread *thread,
+struct callchain_cursor *cursor,
+struct symbol **parent,
+struct addr_location *root_al,
+u8 *cpumode, int ent)
+{
+ int err = 0;
+
+ while (--ent >= 0) {
+ u64 ip = chain->ips[ent];
+
+ if (ip >= PERF_CONTEXT_MAX) {
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, cpumode, ip,
+ false, NULL, NULL, 0);
+ break;
+ }
+ }
+ return err;
+}
+
static int thread__resolve_callchain_sample(struct thread *thread,
struct callchain_cursor *cursor,
struct perf_evsel *evsel,
@@ -2246,6 +2267,12 @@ static int thread__resolve_callchain_sample(struct
thread *thread,
}
check_calls:
+ if (callchain_param.order != ORDER_CALLEE) {
+ err = find_prev_cpumode(chain, thread, cursor, parent, root_al,
+ , chain->nr - first_call);
+ if (err)
+ return (err < 0) ? err : 0;
+ }
for (i = first_call, nr_entries = 0;
i < chain_nr && nr_entries < max_stack; i++) {
u64 ip;
@@ -2260,9 +2287,15 @@ check_calls:
continue;
#endif
ip = chain->ips[j];
-
if (ip < PERF_CONTEXT_MAX)
++nr_entries;
+ else if (callchain_param.order != ORDER_CALLEE) {
+ err = find_prev_cpumode(chain, thread, cursor, parent,
+ root_al, , j);
+ if (err)
+ return (err < 0) ? err : 0;
+ continue;
+ }
err = add_callchain_ip(thread, cursor, parent,
root_al, , ip,
[tip:perf/urgent] perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}
Commit-ID: e9024d519d892b38176cafd46f68a7c77412
Gitweb: https://git.kernel.org/tip/e9024d519d892b38176cafd46f68a7c77412
Author: David S. Miller
AuthorDate: Tue, 30 Oct 2018 12:12:26 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 31 Oct 2018 09:57:51 -0300
perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc}
When processing using 'perf report -g caller', which is the default, we
ended up reverting the callchain entries received from the kernel, but
simply reverting throws away the information that tells that from a
point onwards the addresses are for userspace, kernel, guest kernel,
guest user, hypervisor.
The idea is that if we are walking backwards, for each cluster of
non-cpumode entries we have to first scan backwards for the next one and
use that for the cluster.
This seems silly and more expensive than it needs to be but it is enough
for a initial fix.
The code here is really complicated because it is intimately intertwined
with the lbr and branch handling, as well as this callchain order,
further fixes will be needed to properly take into account the cpumode
in those cases.
Another problem with ORDER_CALLER is that the NULL "0" IP that is at the
end of most callchains shows up at the top of the histogram because
every callchain contains it and with ORDER_CALLER it is the first entry.
Signed-off-by: David S. Miller
Tested-by: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Souvik Banerjee
Cc: Wang Nan
Cc: sta...@vger.kernel.org # 4.19
Link: https://lkml.kernel.org/n/tip-2wt3ayp6j2y2f2xowixa8...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/machine.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 111ae858cbcb..8ee8ab39d8ac 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -2140,6 +2140,27 @@ static int resolve_lbr_callchain_sample(struct thread
*thread,
return 0;
}
+static int find_prev_cpumode(struct ip_callchain *chain, struct thread *thread,
+struct callchain_cursor *cursor,
+struct symbol **parent,
+struct addr_location *root_al,
+u8 *cpumode, int ent)
+{
+ int err = 0;
+
+ while (--ent >= 0) {
+ u64 ip = chain->ips[ent];
+
+ if (ip >= PERF_CONTEXT_MAX) {
+ err = add_callchain_ip(thread, cursor, parent,
+ root_al, cpumode, ip,
+ false, NULL, NULL, 0);
+ break;
+ }
+ }
+ return err;
+}
+
static int thread__resolve_callchain_sample(struct thread *thread,
struct callchain_cursor *cursor,
struct perf_evsel *evsel,
@@ -2246,6 +2267,12 @@ static int thread__resolve_callchain_sample(struct
thread *thread,
}
check_calls:
+ if (callchain_param.order != ORDER_CALLEE) {
+ err = find_prev_cpumode(chain, thread, cursor, parent, root_al,
+ , chain->nr - first_call);
+ if (err)
+ return (err < 0) ? err : 0;
+ }
for (i = first_call, nr_entries = 0;
i < chain_nr && nr_entries < max_stack; i++) {
u64 ip;
@@ -2260,9 +2287,15 @@ check_calls:
continue;
#endif
ip = chain->ips[j];
-
if (ip < PERF_CONTEXT_MAX)
++nr_entries;
+ else if (callchain_param.order != ORDER_CALLEE) {
+ err = find_prev_cpumode(chain, thread, cursor, parent,
+ root_al, , j);
+ if (err)
+ return (err < 0) ? err : 0;
+ continue;
+ }
err = add_callchain_ip(thread, cursor, parent,
root_al, , ip,
Re: Serial maintainership
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu, 8 Sep 2005 14:22:37 -0700 (PDT) > On Thu, 8 Sep 2005, David S. Miller wrote: > > > > Ok, I'll revert the patch and fix the sunsab.c driver as > > Russell indicated. So much for type checking... > > Actually, I think there's a simpler fix. Instead of reverting, how about > something like this? > > (You might even remove the #ifdef inside the function by then, since "ch" > being a constant zero will make 90% of it go away anyway). > > rmk? Davem? I'm fine with this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Thu, 8 Sep 2005 13:39:35 -0700 (PDT) > So it's certainly a valid optimization to know that the arguments aren't > even evaluated, and thus it's sometimes really wrong to change a macro > into an inline function. Ok, I'll revert the patch and fix the sunsab.c driver as Russell indicated. So much for type checking... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Russell King <[EMAIL PROTECTED]> Date: Thu, 8 Sep 2005 21:22:36 +0100 > the "regs" argument may not exist in the parent context in the > !SUPPORT_SYSRQ case. Then pass in a NULL in the ARM serial drivers instead of this ugly dependency upon the macro not using the argument. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Thu, 8 Sep 2005 09:27:56 -0700 (PDT)
> Mistakes happen, and the way you fix them is not to pull a tantrum, but
> tell people that they are idiots and they broke something, and get them to
> fix it instead.
In all this noise I still haven't seen what is wrong with
the build warning fix I made.
Even as networking maintainer, other people put changes into the
networking as build or warning fixes, and I have to live with that.
If I don't like what happened, I call it out and send in a more
appropriate fix. This is never something worth peeing my pants in
public about.
Anyways, let's discuss the concrete problem here.
The previous definition of uart_handle_sysrq_char(), when
SUPPORT_SYSRQ was disabled, was a plain macro define to "(0)" but this
makes gcc emit empty statement warnings (and rightly so) in cases such
as:
if (tty == NULL) {
uart_handle_sysrq_char(>port, ch, regs);
continue;
}
(that example is from drivers/sun/sunsab.c)
So I changed it so that it was an inline function, borrowing the
existing code, so that we get the warning erased _and_ we get type
checking even when SUPPORT_SYSRQ is disabled. So we end up with:
static inline int
uart_handle_sysrq_char(struct uart_port *port, unsigned int ch,
struct pt_regs *regs)
{
#ifdef SUPPORT_SYSRQ
if (port->sysrq) {
if (ch && time_before(jiffies, port->sysrq)) {
handle_sysrq(ch, regs, NULL);
port->sysrq = 0;
return 1;
}
port->sysrq = 0;
}
#endif
return 0;
}
which is what is there now. I can't see what's so wrong with that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 8 Sep 2005 09:27:56 -0700 (PDT)
Mistakes happen, and the way you fix them is not to pull a tantrum, but
tell people that they are idiots and they broke something, and get them to
fix it instead.
In all this noise I still haven't seen what is wrong with
the build warning fix I made.
Even as networking maintainer, other people put changes into the
networking as build or warning fixes, and I have to live with that.
If I don't like what happened, I call it out and send in a more
appropriate fix. This is never something worth peeing my pants in
public about.
Anyways, let's discuss the concrete problem here.
The previous definition of uart_handle_sysrq_char(), when
SUPPORT_SYSRQ was disabled, was a plain macro define to (0) but this
makes gcc emit empty statement warnings (and rightly so) in cases such
as:
if (tty == NULL) {
uart_handle_sysrq_char(up-port, ch, regs);
continue;
}
(that example is from drivers/sun/sunsab.c)
So I changed it so that it was an inline function, borrowing the
existing code, so that we get the warning erased _and_ we get type
checking even when SUPPORT_SYSRQ is disabled. So we end up with:
static inline int
uart_handle_sysrq_char(struct uart_port *port, unsigned int ch,
struct pt_regs *regs)
{
#ifdef SUPPORT_SYSRQ
if (port-sysrq) {
if (ch time_before(jiffies, port-sysrq)) {
handle_sysrq(ch, regs, NULL);
port-sysrq = 0;
return 1;
}
port-sysrq = 0;
}
#endif
return 0;
}
which is what is there now. I can't see what's so wrong with that.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Russell King [EMAIL PROTECTED] Date: Thu, 8 Sep 2005 21:22:36 +0100 the regs argument may not exist in the parent context in the !SUPPORT_SYSRQ case. Then pass in a NULL in the ARM serial drivers instead of this ugly dependency upon the macro not using the argument. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Linus Torvalds [EMAIL PROTECTED] Date: Thu, 8 Sep 2005 13:39:35 -0700 (PDT) So it's certainly a valid optimization to know that the arguments aren't even evaluated, and thus it's sometimes really wrong to change a macro into an inline function. Ok, I'll revert the patch and fix the sunsab.c driver as Russell indicated. So much for type checking... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial maintainership
From: Linus Torvalds [EMAIL PROTECTED] Date: Thu, 8 Sep 2005 14:22:37 -0700 (PDT) On Thu, 8 Sep 2005, David S. Miller wrote: Ok, I'll revert the patch and fix the sunsab.c driver as Russell indicated. So much for type checking... Actually, I think there's a simpler fix. Instead of reverting, how about something like this? (You might even remove the #ifdef inside the function by then, since ch being a constant zero will make 90% of it go away anyway). rmk? Davem? I'm fine with this. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] ipw2100: remove by-hand function entry/exit debugging
From: Ingo Oeser <[EMAIL PROTECTED]> Date: Wed, 7 Sep 2005 15:39:08 +0200 > Jeff Garzik wrote: > > I find them useful in my own drivers; they are definitely not pure noise. > > gcc -finstrument-functions I was going to mention this as well, and also the idea to enable CONFIG_MCOUNT on a per-file basis. We should never be doing by hand what can be automated. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] ipw2100: remove by-hand function entry/exit debugging
From: Ingo Oeser [EMAIL PROTECTED] Date: Wed, 7 Sep 2005 15:39:08 +0200 Jeff Garzik wrote: I find them useful in my own drivers; they are definitely not pure noise. gcc -finstrument-functions I was going to mention this as well, and also the idea to enable CONFIG_MCOUNT on a per-file basis. We should never be doing by hand what can be automated. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Arcnet, linux 2.6.13
From: Esben Nielsen <[EMAIL PROTECTED]> Date: Tue, 6 Sep 2005 20:56:40 +0200 (METDST) > Andrew and David: I CC'ed you guyes because you took care of it the last > time :-) Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: proto_unregister sleeps while atomic
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 07 Sep 2005 01:42:48 +0200 > The only other user of proto_list besides proto_register, which > doesn't care, are the seqfs functions. They use the slab pointer, > but in a harmless way: > > proto->slab == NULL ? "no" : "yes", > > Anyway, I've moved it up to the top. Ok thanks, patch applied. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: proto_unregister sleeps while atomic
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 07 Sep 2005 01:02:01 +0200 > You're right, good catch. This patch fixes it by moving the lock > down to the list-operation which it is supposed to protect. I think we need to unlink from the list first if you're going to do it this way. Otherwise someone can find the protocol via lookup, and then bogusly try to use the SLAB cache we're freeing up. Or does something else prevent this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline"
From: Andi Kleen <[EMAIL PROTECTED]> Date: Tue, 6 Sep 2005 22:23:50 +0200 > I don't think the functionality of having single copies in case > an out of line version was needed was ever required by the Linux kernel. Alpha does, exactly for the kind of case this gcc inlining feature was designed for. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] [2.6 patch] include/asm-x86_64 extern inline - static inline
From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 22:23:50 +0200 I don't think the functionality of having single copies in case an out of line version was needed was ever required by the Linux kernel. Alpha does, exactly for the kind of case this gcc inlining feature was designed for. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: proto_unregister sleeps while atomic
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 07 Sep 2005 01:02:01 +0200 You're right, good catch. This patch fixes it by moving the lock down to the list-operation which it is supposed to protect. I think we need to unlink from the list first if you're going to do it this way. Otherwise someone can find the protocol via lookup, and then bogusly try to use the SLAB cache we're freeing up. Or does something else prevent this? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: proto_unregister sleeps while atomic
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 07 Sep 2005 01:42:48 +0200 The only other user of proto_list besides proto_register, which doesn't care, are the seqfs functions. They use the slab pointer, but in a harmless way: proto-slab == NULL ? no : yes, Anyway, I've moved it up to the top. Ok thanks, patch applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Arcnet, linux 2.6.13
From: Esben Nielsen [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 20:56:40 +0200 (METDST) Andrew and David: I CC'ed you guyes because you took care of it the last time :-) Applied, thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/ipv4/tcp.c:775! with 2.6.13-git5
From: "Colin Harrison" <[EMAIL PROTECTED]>
Date: Mon, 5 Sep 2005 16:43:44 +0100
> I'm getting the following BUG report with 2.6.13-git5:-
Should be fixed by this patch. And please use netdev@vger.kernel.org
for networking kernel stuff, thanks.
diff-tree fb5f5e6e0cebd574be737334671d1aa8f170d5f3 (from
1198ad002ad36291817c7bf0308ab9c50ee2571d)
Author: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon Sep 5 18:55:48 2005 -0700
[TCP]: Fix TCP_OFF() bug check introduced by previous change.
The TCP_OFF assignment at the bottom of that if block can indeed set
TCP_OFF without setting TCP_PAGE. Since there is not much to be
gained from avoiding this situation, we might as well just zap the
offset. The following patch should fix it.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -769,10 +769,10 @@ new_segment:
if (off == PAGE_SIZE) {
put_page(page);
TCP_PAGE(sk) = page = NULL;
- TCP_OFF(sk) = off = 0;
+ off = 0;
}
} else
- BUG_ON(off);
+ off = 0;
if (copy > PAGE_SIZE - off)
copy = PAGE_SIZE - off;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig fix (GEN_RTC dependencies)
From: [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 01:56:45 +0100 > Yet another architecture not coverd by GEN_RTC - sparc64 never > picked it until now and it doesn't have asm/rtc.h to go with it, so > it wouldn't compile anyway (or have these ioctls in the user-visible > headers, for that matter). > > FWIW, I'm very tempted to introduce ARCH_HAS_GEN_RTC and have > it set in arch/*/Kconfig for architectures that know what to do with this > stuff - for something supposedly generic the list of architectures where > it doesn't work is getting too long... > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> I'll add this patch to my sparc tree, thanks Al. Admittedly, the whole RTC situation is quite a mess I have to agree. To make the problem worse, we have two sets of RTC ioctls which userland makes use of on Sparc. The older ones which the SBUS RTC driver exported and supported, and the normal ones the rest of the world uses. Because the normal RTC driver gets used as well, userland actually tries both ioctl sets. Therefore, it probably would work to completely do away with the SBUS RTC ioctl support, and only use the normal ones. This would make using the generic RTC driver much easier, I would think. Anyways, I've added this to my sparc64 TODO list at: http://vger.kernel.org/~davem/sparc64_todo.html so that I can get to dealing with this at some point. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig fix (GEN_RTC dependencies)
From: [EMAIL PROTECTED] Date: Tue, 6 Sep 2005 01:56:45 +0100 Yet another architecture not coverd by GEN_RTC - sparc64 never picked it until now and it doesn't have asm/rtc.h to go with it, so it wouldn't compile anyway (or have these ioctls in the user-visible headers, for that matter). FWIW, I'm very tempted to introduce ARCH_HAS_GEN_RTC and have it set in arch/*/Kconfig for architectures that know what to do with this stuff - for something supposedly generic the list of architectures where it doesn't work is getting too long... Signed-off-by: Al Viro [EMAIL PROTECTED] I'll add this patch to my sparc tree, thanks Al. Admittedly, the whole RTC situation is quite a mess I have to agree. To make the problem worse, we have two sets of RTC ioctls which userland makes use of on Sparc. The older ones which the SBUS RTC driver exported and supported, and the normal ones the rest of the world uses. Because the normal RTC driver gets used as well, userland actually tries both ioctl sets. Therefore, it probably would work to completely do away with the SBUS RTC ioctl support, and only use the normal ones. This would make using the generic RTC driver much easier, I would think. Anyways, I've added this to my sparc64 TODO list at: http://vger.kernel.org/~davem/sparc64_todo.html so that I can get to dealing with this at some point. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/ipv4/tcp.c:775! with 2.6.13-git5
From: Colin Harrison [EMAIL PROTECTED]
Date: Mon, 5 Sep 2005 16:43:44 +0100
I'm getting the following BUG report with 2.6.13-git5:-
Should be fixed by this patch. And please use netdev@vger.kernel.org
for networking kernel stuff, thanks.
diff-tree fb5f5e6e0cebd574be737334671d1aa8f170d5f3 (from
1198ad002ad36291817c7bf0308ab9c50ee2571d)
Author: Herbert Xu [EMAIL PROTECTED]
Date: Mon Sep 5 18:55:48 2005 -0700
[TCP]: Fix TCP_OFF() bug check introduced by previous change.
The TCP_OFF assignment at the bottom of that if block can indeed set
TCP_OFF without setting TCP_PAGE. Since there is not much to be
gained from avoiding this situation, we might as well just zap the
offset. The following patch should fix it.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -769,10 +769,10 @@ new_segment:
if (off == PAGE_SIZE) {
put_page(page);
TCP_PAGE(sk) = page = NULL;
- TCP_OFF(sk) = off = 0;
+ off = 0;
}
} else
- BUG_ON(off);
+ off = 0;
if (copy PAGE_SIZE - off)
copy = PAGE_SIZE - off;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sun, 4 Sep 2005 14:42:18 -0700 > It seems a strange thing to check though. Do we really need it? Other platforms already do, it's a very good sanity check. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Dave Jones <[EMAIL PROTECTED]>
Subject: Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm
tree
Date: Sun, 4 Sep 2005 16:23:33 -0400
> On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
> > unsigned long __copy_to_user_ll(void __user *to, const void *from,
> unsigned long n)
> > {
> >BUG_ON((long) n < 0);
>
> Ehh? It's unsigned. This will never be true.
It's to catch the user slipping in enormous lengths to
the user copy routines.
Sparc64 makes this check as well. From U3memcpy.S:
srlx%o2, 31, %g2
cmp %g2, 0
tne %xcc, 5
%o2 is the length, we make sure the upper 33-bits are clear.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Dave Jones [EMAIL PROTECTED]
Subject: Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm
tree
Date: Sun, 4 Sep 2005 16:23:33 -0400
On Sun, Sep 04, 2005 at 01:16:00PM -0700, Andrew Morton wrote:
unsigned long __copy_to_user_ll(void __user *to, const void *from,
unsigned long n)
{
BUG_ON((long) n 0);
Ehh? It's unsigned. This will never be true.
It's to catch the user slipping in enormous lengths to
the user copy routines.
Sparc64 makes this check as well. From U3memcpy.S:
srlx%o2, 31, %g2
cmp %g2, 0
tne %xcc, 5
%o2 is the length, we make sure the upper 33-bits are clear.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86-cache-pollution-aware-__copy_from_user_ll.patch added to -mm tree
From: Andrew Morton [EMAIL PROTECTED] Date: Sun, 4 Sep 2005 14:42:18 -0700 It seems a strange thing to check though. Do we really need it? Other platforms already do, it's a very good sanity check. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1 login fails
From: "Brown, Len" <[EMAIL PROTECTED]> Date: Sat, 3 Sep 2005 12:58:15 -0400 > CONFIG_AUDIT=y indeed did the trick. > > When will I be able to delete CONFIG_AUDIT from my kernel again? It's a regression we accidently added to the netlink socket family, we will fix it. But please use the workaround of enabling CONFIG_AUDIT until we fix it, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-mm1 login fails
From: Brown, Len [EMAIL PROTECTED] Date: Sat, 3 Sep 2005 12:58:15 -0400 CONFIG_AUDIT=y indeed did the trick. When will I be able to delete CONFIG_AUDIT from my kernel again? It's a regression we accidently added to the netlink socket family, we will fix it. But please use the workaround of enabling CONFIG_AUDIT until we fix it, thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
From: Nick Piggin <[EMAIL PROTECTED]> Date: Sat, 03 Sep 2005 07:47:48 +1000 > So neither could currently supported atomic_t ops be shared with > userland accesses? Correct. > Then I think it would not be breaking any interface rule to do an > atomic_t atomic_cmpxchg either. Definitely for my usage it will > not be shared with userland. Ok. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
From: Nick Piggin <[EMAIL PROTECTED]> Date: Sat, 03 Sep 2005 07:22:18 +1000 > This atomic_cmpxchg, unlike a "regular" cmpxchg, has the advantage > that the memory altered should always be going through the atomic_ > accessors, and thus should be implementable with spinlocks. > > See for example, arch/sparc/lib/atomic32.c > > At least, that's what I'm hoping for. Ok, as long as the rule is that all accesses have to go through accessor macros, it would work. This is not true for existing uses of cmpxchg() btw, userland accesses shared locks with the kernel would using any kind of accessors we can control. This means that your atomic_cmpxchg() cannot be used for locking objects shared with userland, as DRM wants, since the hashed spinlock trick does not work in such a case. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
From: Andi Kleen <[EMAIL PROTECTED]> Date: 02 Sep 2005 22:41:31 +0200 > > Yeah quite a few. I suspect most MIPS also would have a problem in this > > area. > > cmpxchg can be done with LL/SC can't it? Any MIPS should have that. Right. On PARISC, I don't see where they are emulating compare and swap as indicated. They are doing the funny hashed spinlocks for the atomic_t operations and bitops, but that is entirely different. cmpxchg() has to operate in an environment where, unlike the atomic_t and bitops, you cannot control the accessors to the object at all. The DRM is the only place in the kernel that requires cmpxchg() and you can thus make a list of what platform can provide cmpxchg() by which ones support DRM and thus provide the cmpxchg() macro already in asm/system.h We really can't require support for this primitive kernel wide, it's simply not possible on a couple chips. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sparc: "extern inline" -> "static inline"
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Fri, 2 Sep 2005 22:24:44 +0200 > "extern inline" doesn't make much sense. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Patch does not apply to Linus's current tree, every change in include/asm-sparc/spinlock.h was rejected. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more of sparc32 dependencies fallout
From: Alan Cox <[EMAIL PROTECTED]> Subject: Re: [PATCH] more of sparc32 dependencies fallout Date: Fri, 02 Sep 2005 21:24:08 +0100 > On Gwe, 2005-09-02 at 20:12 +0100, [EMAIL PROTECTED] wrote: > > config MOXA_SMARTIO > > tristate "Moxa SmartIO support" > > - depends on SERIAL_NONSTANDARD > > + depends on SERIAL_NONSTANDARD && (BROKEN || !SPARC32) > > help > > > Why mark it "BROKEN" and !SPARC32. Why not mark it (ISA || PCI) ? Its > only available as a plugin card and its apparently working He marked it BROKEN "OR" !SPARC32, not "AND". Also, SPARC32 supports PCI on Javastation machines. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more of sparc32 dependencies fallout
From: [EMAIL PROTECTED] Date: Fri, 2 Sep 2005 20:12:01 +0100 > More stuff that got exposed to sparc32 build due to inclusion of > drivers/char/Kconfig in arch/sparc/Kconfig needs to be excluded. > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Applied, thanks Al. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dereference of uninitialized pointer in zatm
From: [EMAIL PROTECTED] Date: Fri, 2 Sep 2005 19:46:42 +0100 > Fixing breakage from [NET]: Kill skb->list - original was > assign vcc > do a bunch of stuff using ZATM_VCC(vcc)->pool as common subexpression > Now we do > int pos = ZATM_VCC(vcc)->pool; > assign vcc > do a bunch of stuff > even though vcc is not even initialized when we enter that block... > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Applied, thanks Al. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner <[EMAIL PROTECTED]> Date: Thu, 1 Sep 2005 22:51:48 -0400 > I have an idea why this is going on. Packets are pre-allocated by the > driver to be a max packet size, so when you send small packets, it > wastes a lot of memory. Currently Linux uses the packets at the > beginning of a connection to make a guess at how best to advertise its > window so as not to overflow the socket's memory bounds. Since you > start out with big segments then go to small ones, this is defeating > that mechanism. It's actually documented in the comments in > tcp_input.c. :) > > * The scheme does not work when sender sends good segments opening > * window and then starts to feed us spagetti. But it should work > * in common situations. Otherwise, we have to rely on queue collapsing. That's a strong possibility, good catch John. Although, I'm still not ruling out some box in the middle even though I consider it less likely than your theory. So you're suggesting that tcp_prune_queue() should do the: if (atomic_read(>sk_rmem_alloc) >= sk->sk_rcvbuf) tcp_clamp_window(sk, tp); check after attempting to collapse the queue. But, that window clamping should fix the problem, as we recalculate the window to advertise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: John Heffner [EMAIL PROTECTED] Date: Thu, 1 Sep 2005 22:51:48 -0400 I have an idea why this is going on. Packets are pre-allocated by the driver to be a max packet size, so when you send small packets, it wastes a lot of memory. Currently Linux uses the packets at the beginning of a connection to make a guess at how best to advertise its window so as not to overflow the socket's memory bounds. Since you start out with big segments then go to small ones, this is defeating that mechanism. It's actually documented in the comments in tcp_input.c. :) * The scheme does not work when sender sends good segments opening * window and then starts to feed us spagetti. But it should work * in common situations. Otherwise, we have to rely on queue collapsing. That's a strong possibility, good catch John. Although, I'm still not ruling out some box in the middle even though I consider it less likely than your theory. So you're suggesting that tcp_prune_queue() should do the: if (atomic_read(sk-sk_rmem_alloc) = sk-sk_rcvbuf) tcp_clamp_window(sk, tp); check after attempting to collapse the queue. But, that window clamping should fix the problem, as we recalculate the window to advertise. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dereference of uninitialized pointer in zatm
From: [EMAIL PROTECTED] Date: Fri, 2 Sep 2005 19:46:42 +0100 Fixing breakage from [NET]: Kill skb-list - original was assign vcc do a bunch of stuff using ZATM_VCC(vcc)-pool as common subexpression Now we do int pos = ZATM_VCC(vcc)-pool; assign vcc do a bunch of stuff even though vcc is not even initialized when we enter that block... Signed-off-by: Al Viro [EMAIL PROTECTED] Applied, thanks Al. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more of sparc32 dependencies fallout
From: [EMAIL PROTECTED] Date: Fri, 2 Sep 2005 20:12:01 +0100 More stuff that got exposed to sparc32 build due to inclusion of drivers/char/Kconfig in arch/sparc/Kconfig needs to be excluded. Signed-off-by: Al Viro [EMAIL PROTECTED] Applied, thanks Al. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more of sparc32 dependencies fallout
From: Alan Cox [EMAIL PROTECTED] Subject: Re: [PATCH] more of sparc32 dependencies fallout Date: Fri, 02 Sep 2005 21:24:08 +0100 On Gwe, 2005-09-02 at 20:12 +0100, [EMAIL PROTECTED] wrote: config MOXA_SMARTIO tristate Moxa SmartIO support - depends on SERIAL_NONSTANDARD + depends on SERIAL_NONSTANDARD (BROKEN || !SPARC32) help Why mark it BROKEN and !SPARC32. Why not mark it (ISA || PCI) ? Its only available as a plugin card and its apparently working He marked it BROKEN OR !SPARC32, not AND. Also, SPARC32 supports PCI on Javastation machines. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] sparc: extern inline - static inline
From: Adrian Bunk [EMAIL PROTECTED] Date: Fri, 2 Sep 2005 22:24:44 +0200 extern inline doesn't make much sense. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Patch does not apply to Linus's current tree, every change in include/asm-sparc/spinlock.h was rejected. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
From: Andi Kleen [EMAIL PROTECTED] Date: 02 Sep 2005 22:41:31 +0200 Yeah quite a few. I suspect most MIPS also would have a problem in this area. cmpxchg can be done with LL/SC can't it? Any MIPS should have that. Right. On PARISC, I don't see where they are emulating compare and swap as indicated. They are doing the funny hashed spinlocks for the atomic_t operations and bitops, but that is entirely different. cmpxchg() has to operate in an environment where, unlike the atomic_t and bitops, you cannot control the accessors to the object at all. The DRM is the only place in the kernel that requires cmpxchg() and you can thus make a list of what platform can provide cmpxchg() by which ones support DRM and thus provide the cmpxchg() macro already in asm/system.h We really can't require support for this primitive kernel wide, it's simply not possible on a couple chips. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
From: Nick Piggin [EMAIL PROTECTED] Date: Sat, 03 Sep 2005 07:22:18 +1000 This atomic_cmpxchg, unlike a regular cmpxchg, has the advantage that the memory altered should always be going through the atomic_ accessors, and thus should be implementable with spinlocks. See for example, arch/sparc/lib/atomic32.c At least, that's what I'm hoping for. Ok, as long as the rule is that all accesses have to go through accessor macros, it would work. This is not true for existing uses of cmpxchg() btw, userland accesses shared locks with the kernel would using any kind of accessors we can control. This means that your atomic_cmpxchg() cannot be used for locking objects shared with userland, as DRM wants, since the hashed spinlock trick does not work in such a case. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.13] lockless pagecache 2/7
From: Nick Piggin [EMAIL PROTECTED] Date: Sat, 03 Sep 2005 07:47:48 +1000 So neither could currently supported atomic_t ops be shared with userland accesses? Correct. Then I think it would not be breaking any interface rule to do an atomic_t atomic_cmpxchg either. Definitely for my usage it will not be shared with userland. Ok. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Jesper Juhl <[EMAIL PROTECTED]> Date: Fri, 2 Sep 2005 00:49:20 +0200 > Hmm, I see plenty of content in the post. Want me to farward you a > copy off list ? Please do, I didn't see anything. It still needs to be reposted to netdev@vger.kernel.org anyways :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
Thanks for the empty posting. Please provide the content you intended to post, and furthermore please post it to the network developer mailing list, netdev@vger.kernel.org Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto_free_tfm callers no longer need to check for NULL
Applied, thanks Jesper. Can you avoid those "/./" things from showing up in the file paths of the patches you post? They upset the GIT patch application scripts and diff verifiers, so I had to edit them out by hand. Thanks again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DECnet Tidy
From: Patrick Caulfield <[EMAIL PROTECTED]> Date: Tue, 30 Aug 2005 09:47:36 +0100 > Patch from Steve which I've vetted and tested: > > "This patch is really intended has a move towards fixing the sendmsg/recvmsg > > functions in various ways so that we will finally have working nagle. Also > > reduces code duplication. " > > Signed-off-by: Patrick Caulfield <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix minor bug in sungem.h
From: Geoff Levand <[EMAIL PROTECTED]> Date: Wed, 24 Aug 2005 17:23:11 -0700 > This changes the Sun Gem Ether driver's tx ring buffer > length to the proper constant. Currently TX_RING_SIZE > and RX_RING_SIZE are equal, so no malfunction occurs. > > Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> Applied, thanks for catching this Geoff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] include/net/ip_vs.h: "extern inline" -> "static inline"
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Wed, 24 Aug 2005 17:58:06 +0200 > "extern inline" doesn't make much sense. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin <[EMAIL PROTECTED]> Date: Thu, 01 Sep 2005 15:13:52 -0400 > The aoe driver looks OK, but it turns out there's a byte swapping bug > in the vblade that could be related if he's running the vblade on a > big endian host (even though he said it was an x86 host), but I > haven't heard back from the original poster yet. I see, thanks for looking into this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin <[EMAIL PROTECTED]> Date: Wed, 31 Aug 2005 11:50:55 -0400 > Jim MacBaine <[EMAIL PROTECTED]> writes: > > > Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.<6> > > etherd/e0.0: unknown partition table > > Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has > > 67553994410557440 > > sectors > > OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is > 61440 sectors, so this should be a simple byte order fix. More strangely, the upper and lower 32-bit words are swapped. The bytes within each 32-bit word are swapped correctly. So the calculation maybe should be something like: __le32 *p = (__le32 *) [100 << 1]; u32 high32 = le32_to_cpup(p); u32 low32 = le32_to_cpup(p + 1); ssize = (((u64)high32 << 32) | (u64) low32); But that doesn't make any sense, and even ide_fix_driveid() in drivers/ide/ide-iops.c does a le64_to_cpu() for this value: id->lba_capacity_2 = __le64_to_cpu(id->lba_capacity_2); I wonder if this is some artifact of how AOE devices encode this field when sending it to the client. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin [EMAIL PROTECTED] Date: Wed, 31 Aug 2005 11:50:55 -0400 Jim MacBaine [EMAIL PROTECTED] writes: Aug 31 15:18:49 sunny kernel: devfs_mk_dir: invalid argument.6 etherd/e0.0: unknown partition table Aug 31 15:18:49 sunny kernel: aoe: 0011d8xx e0.0 v4000 has 67553994410557440 sectors OK. 67553994410557440 is 61440 byte swapped in 64 bits, and 30MB is 61440 sectors, so this should be a simple byte order fix. More strangely, the upper and lower 32-bit words are swapped. The bytes within each 32-bit word are swapped correctly. So the calculation maybe should be something like: __le32 *p = (__le32 *) id[100 1]; u32 high32 = le32_to_cpup(p); u32 low32 = le32_to_cpup(p + 1); ssize = (((u64)high32 32) | (u64) low32); But that doesn't make any sense, and even ide_fix_driveid() in drivers/ide/ide-iops.c does a le64_to_cpu() for this value: id-lba_capacity_2 = __le64_to_cpu(id-lba_capacity_2); I wonder if this is some artifact of how AOE devices encode this field when sending it to the client. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aoe fails on sparc64
From: Ed L Cashin [EMAIL PROTECTED] Date: Thu, 01 Sep 2005 15:13:52 -0400 The aoe driver looks OK, but it turns out there's a byte swapping bug in the vblade that could be related if he's running the vblade on a big endian host (even though he said it was an x86 host), but I haven't heard back from the original poster yet. I see, thanks for looking into this. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix minor bug in sungem.h
From: Geoff Levand [EMAIL PROTECTED] Date: Wed, 24 Aug 2005 17:23:11 -0700 This changes the Sun Gem Ether driver's tx ring buffer length to the proper constant. Currently TX_RING_SIZE and RX_RING_SIZE are equal, so no malfunction occurs. Signed-off-by: Geoff Levand [EMAIL PROTECTED] Applied, thanks for catching this Geoff. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DECnet Tidy
From: Patrick Caulfield [EMAIL PROTECTED] Date: Tue, 30 Aug 2005 09:47:36 +0100 Patch from Steve which I've vetted and tested: This patch is really intended has a move towards fixing the sendmsg/recvmsg functions in various ways so that we will finally have working nagle. Also reduces code duplication. Signed-off-by: Patrick Caulfield [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] include/net/ip_vs.h: extern inline - static inline
From: Adrian Bunk [EMAIL PROTECTED] Date: Wed, 24 Aug 2005 17:58:06 +0200 extern inline doesn't make much sense. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto_free_tfm callers no longer need to check for NULL
Applied, thanks Jesper. Can you avoid those /./ things from showing up in the file paths of the patches you post? They upset the GIT patch application scripts and diff verifiers, so I had to edit them out by hand. Thanks again. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
Thanks for the empty posting. Please provide the content you intended to post, and furthermore please post it to the network developer mailing list, netdev@vger.kernel.org Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
From: Jesper Juhl [EMAIL PROTECTED] Date: Fri, 2 Sep 2005 00:49:20 +0200 Hmm, I see plenty of content in the post. Want me to farward you a copy off list ? Please do, I didn't see anything. It still needs to be reposted to netdev@vger.kernel.org anyways :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix kprobes handling of simultaneous probe hit/unregister
From: Jim Keniston <[EMAIL PROTECTED]> Date: 31 Aug 2005 14:53:37 -0700 > This bug doesn't exist on ppc64 and ia64, where a breakpoint > instruction leaves the IP pointing to the beginning of the instruction. > I don't know about sparc64. (Dave, could you please advise?) On sparc64 instructions are all 32-bit, 4-byte aligned, and a breakpoint instruction leaves the PC pointing at the beginning of that breakpoint instruction. So I think sparc64 should be OK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix kprobes handling of simultaneous probe hit/unregister
From: Jim Keniston [EMAIL PROTECTED] Date: 31 Aug 2005 14:53:37 -0700 This bug doesn't exist on ppc64 and ia64, where a breakpoint instruction leaves the IP pointing to the beginning of the instruction. I don't know about sparc64. (Dave, could you please advise?) On sparc64 instructions are all 32-bit, 4-byte aligned, and a breakpoint instruction leaves the PC pointing at the beginning of that breakpoint instruction. So I think sparc64 should be OK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
From: Andi Kleen <[EMAIL PROTECTED]> Subject: Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured. Date: Wed, 31 Aug 2005 01:38:08 +0200 > On Wednesday 31 August 2005 01:05, Luck, Tony wrote: > > >Please do not generate any code if the feature cannot ever be > > >used (CONFIG_KPROBES off). With this patch we still have lots of > > >unnecessary code being executed on each page fault. > > > > I can (eventually) wrap this call inside the #ifdef CONFIG_KPROBES. > > At least the original die notifiers were designed as a generic debugger > interface, not a kprobes specific thing. So I don't think it's a good idea. Me neither, I think a way too big deal is being made about about this by the ia64 folks. Just put the dang hook in there unconditionally already :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured.
From: Andi Kleen [EMAIL PROTECTED] Subject: Re: [PATCH] Only process_die notifier in ia64_do_page_fault if KPROBES is configured. Date: Wed, 31 Aug 2005 01:38:08 +0200 On Wednesday 31 August 2005 01:05, Luck, Tony wrote: Please do not generate any code if the feature cannot ever be used (CONFIG_KPROBES off). With this patch we still have lots of unnecessary code being executed on each page fault. I can (eventually) wrap this call inside the #ifdef CONFIG_KPROBES. At least the original die notifiers were designed as a generic debugger interface, not a kprobes specific thing. So I don't think it's a good idea. Me neither, I think a way too big deal is being made about about this by the ia64 folks. Just put the dang hook in there unconditionally already :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
From: Jon Smirl <[EMAIL PROTECTED]> Date: Tue, 30 Aug 2005 00:35:11 -0400 > As far as I can tell no one has built recent hardware this way. But I > believe there are some old SCSI controllers that do this. I provided a > ROM API for disabling sysfs access, if we identify one of these cards > we should just add a call to it's driver to disable ROM access instead > of bothering with the copy. Currently the copy is not being used > anywhere in the kernel. Qlogic ISP is one such card, but there are several others. I think enabling the ROM is a very bad idea, since we in fact know it disables the I/O and MEM space decoders on a non-empty set of PCI cards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT) > So 2.6.13 is being "safe". It allocates the space for the ROM in the > resource tables, but it neither enables it nor does it write the > (disabled) address out to the device, since both of those actions have > been shown to break on PC's. And sadly (or happily, depends on your > viewpoint), PC's have a _much_ wider range of hardware, so they are the > ones we have to work around. Actually, I can tell you that it is a known fact that Qlogic ISP PCI cards will not respond to I/O and MEM space when you enable the ROM. And this behavior exists in quite a few other PCI parts as well. So I think the kernel, by not enabling the ROM, is doing the right thing here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
From: Linus Torvalds [EMAIL PROTECTED] Date: Mon, 29 Aug 2005 21:09:24 -0700 (PDT) So 2.6.13 is being safe. It allocates the space for the ROM in the resource tables, but it neither enables it nor does it write the (disabled) address out to the device, since both of those actions have been shown to break on PC's. And sadly (or happily, depends on your viewpoint), PC's have a _much_ wider range of hardware, so they are the ones we have to work around. Actually, I can tell you that it is a known fact that Qlogic ISP PCI cards will not respond to I/O and MEM space when you enable the ROM. And this behavior exists in quite a few other PCI parts as well. So I think the kernel, by not enabling the ROM, is doing the right thing here. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ignore disabled ROM resources at setup
From: Jon Smirl [EMAIL PROTECTED] Date: Tue, 30 Aug 2005 00:35:11 -0400 As far as I can tell no one has built recent hardware this way. But I believe there are some old SCSI controllers that do this. I provided a ROM API for disabling sysfs access, if we identify one of these cards we should just add a call to it's driver to disable ROM access instead of bothering with the copy. Currently the copy is not being used anywhere in the kernel. Qlogic ISP is one such card, but there are several others. I think enabling the ROM is a very bad idea, since we in fact know it disables the I/O and MEM space decoders on a non-empty set of PCI cards. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Andi Kleen <[EMAIL PROTECTED]> Date: 27 Aug 2005 04:34:07 +0200 > "David S. Miller" <[EMAIL PROTECTED]> writes: > > > From: Alexey Dobriyan <[EMAIL PROTECTED]> > > Date: Sat, 27 Aug 2005 02:58:48 +0400 > > > > > What's the point of having unlikely() attached to every possible if ()? > > > > If can result in smaller code, for one thing, even if it > > isn't a performance critical path. > > Really? At least on x86 it tends to generate bigger code when > block reordering is enabled because a jump forward and a jump > backward and a possible label alignment are bigger than just > a single jump forward. In the cases I've studied on sparc64 it keeps gcc from doing basic block replication in the unlikely paths. I've only checked gcc-3.4 and earlier, gcc-4.x is just big bloated useless garbage and should be avoided for a couple of years. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Sat, 27 Aug 2005 02:58:48 +0400 > What's the point of having unlikely() attached to every possible if ()? If can result in smaller code, for one thing, even if it isn't a performance critical path. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Sat, 27 Aug 2005 02:58:48 +0400 What's the point of having unlikely() attached to every possible if ()? If can result in smaller code, for one thing, even if it isn't a performance critical path. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] IBM HDAPS accelerometer driver, with probing.
From: Andi Kleen [EMAIL PROTECTED] Date: 27 Aug 2005 04:34:07 +0200 David S. Miller [EMAIL PROTECTED] writes: From: Alexey Dobriyan [EMAIL PROTECTED] Date: Sat, 27 Aug 2005 02:58:48 +0400 What's the point of having unlikely() attached to every possible if ()? If can result in smaller code, for one thing, even if it isn't a performance critical path. Really? At least on x86 it tends to generate bigger code when block reordering is enabled because a jump forward and a jump backward and a possible label alignment are bigger than just a single jump forward. In the cases I've studied on sparc64 it keeps gcc from doing basic block replication in the unlikely paths. I've only checked gcc-3.4 and earlier, gcc-4.x is just big bloated useless garbage and should be avoided for a couple of years. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some missing spin_unlocks
From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: Re: some missing spin_unlocks Date: Tue, 23 Aug 2005 19:40:06 +0200 > On Tue, 2005-08-23 at 10:30 -0700, David S. Miller wrote: > > From: Arjan van de Ven <[EMAIL PROTECTED]> > > Date: Tue, 23 Aug 2005 18:54:03 +0200 > > > > > does it matter? can ANYTHING be spinning on the lock? if not .. can we > > > just let the lock go poof and not unlock it... > > > > I believe socket lookup can, otherwise the code is OK as-is. > > lookup while the object is in progress of being destroyed sounds really > bad though This happens all the time with TCP sockets, for example. When we're trying to kill off a socket which is in time wait state, the receive path can find it, grab a reference, and process a packet against it right as we're trying to kill it off. This is completely normal. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some missing spin_unlocks
From: Ted Unangst <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 15:26:47 -0700
> net/rose/rose_route.c rose_route_frame, line 998
> returns without unlocking rose_node_list_lock, rose_neigh_list_lock, or
> rose_route_list_lock
I fixed this one with the patch below.
> net/rose/rose_timer.c rose_heartbeat_expiry, line 141
> rose_destroy_socket does not unlock sk as far as i can see
This one needs more care. We can't drop the lock, because
the destroy actions need to be protected by that lock, but
we can't release the lock after rose_destroy_socket() because
the object may not even exist any longer.
The problem there, at the core, is that the timer doesn't
grab a reference to the socket, which would make the solution
to this bug very straight forward.
Someone should work on that :-)
diff-tree 61ef36aa6cf356649863a24a850c2183cb762c61 (from
daf53344fadaa8c47c6b0864e7f34efcbb66e391)
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Tue Aug 23 09:42:38 2005 -0700
[ROSE]: Fix missing unlocks in rose_route_frame()
Noticed by Coverity checker.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -994,8 +994,10 @@ int rose_route_frame(struct sk_buff *skb
* 1. The frame isn't for us,
* 2. It isn't "owned" by any existing route.
*/
- if (frametype != ROSE_CALL_REQUEST) /* XXX */
- return 0;
+ if (frametype != ROSE_CALL_REQUEST) { /* XXX */
+ ret = 0;
+ goto out;
+ }
len = (((skb->data[3] >> 4) & 0x0F) + 1) / 2;
len += (((skb->data[3] >> 0) & 0x0F) + 1) / 2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some missing spin_unlocks
From: Ted Unangst [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 15:26:47 -0700
net/rose/rose_route.c rose_route_frame, line 998
returns without unlocking rose_node_list_lock, rose_neigh_list_lock, or
rose_route_list_lock
I fixed this one with the patch below.
net/rose/rose_timer.c rose_heartbeat_expiry, line 141
rose_destroy_socket does not unlock sk as far as i can see
This one needs more care. We can't drop the lock, because
the destroy actions need to be protected by that lock, but
we can't release the lock after rose_destroy_socket() because
the object may not even exist any longer.
The problem there, at the core, is that the timer doesn't
grab a reference to the socket, which would make the solution
to this bug very straight forward.
Someone should work on that :-)
diff-tree 61ef36aa6cf356649863a24a850c2183cb762c61 (from
daf53344fadaa8c47c6b0864e7f34efcbb66e391)
Author: David S. Miller [EMAIL PROTECTED]
Date: Tue Aug 23 09:42:38 2005 -0700
[ROSE]: Fix missing unlocks in rose_route_frame()
Noticed by Coverity checker.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -994,8 +994,10 @@ int rose_route_frame(struct sk_buff *skb
* 1. The frame isn't for us,
* 2. It isn't owned by any existing route.
*/
- if (frametype != ROSE_CALL_REQUEST) /* XXX */
- return 0;
+ if (frametype != ROSE_CALL_REQUEST) { /* XXX */
+ ret = 0;
+ goto out;
+ }
len = (((skb-data[3] 4) 0x0F) + 1) / 2;
len += (((skb-data[3] 0) 0x0F) + 1) / 2;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: some missing spin_unlocks
From: Arjan van de Ven [EMAIL PROTECTED] Subject: Re: some missing spin_unlocks Date: Tue, 23 Aug 2005 19:40:06 +0200 On Tue, 2005-08-23 at 10:30 -0700, David S. Miller wrote: From: Arjan van de Ven [EMAIL PROTECTED] Date: Tue, 23 Aug 2005 18:54:03 +0200 does it matter? can ANYTHING be spinning on the lock? if not .. can we just let the lock go poof and not unlock it... I believe socket lookup can, otherwise the code is OK as-is. lookup while the object is in progress of being destroyed sounds really bad though This happens all the time with TCP sockets, for example. When we're trying to kill off a socket which is in time wait state, the receive path can find it, grab a reference, and process a packet against it right as we're trying to kill it off. This is completely normal. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing spin_unlock in tcp_v4_get_port
From: Ted Unangst <[EMAIL PROTECTED]>
Subject: missing spin_unlock in tcp_v4_get_port
Date: Mon, 22 Aug 2005 14:17:36 -0700
> There appears to be a missing spin_unlock in tcp_v4_get_port.
>
> do {rover++;
> if (rover > high)
> rover = low;
> head = _bhash[tcp_bhashfn(rover)];
> spin_lock(>lock);
> head->lock is acquired.
> tb_for_each(tb, node, >chain)
> if (tb->port == rover)
> goto next;
> we don't find what we want. break out of while loop.
> break;
> next:
> spin_unlock(>lock);
> } while (--remaining > 0);
> tcp_port_rover = rover;
> spin_unlock(_portalloc_lock);
>
> /* Exhausted local port range during search? */
> ret = 1;
> if (remaining <= 0)
> goto fail;
> here we go to fail; head->lock is still acquired.
Only if remaining <= 0, in which case we broke out of the loop due to
the "while (--remaining > 0)" test, not because of the "break;"
statement, and thus the lock is not held.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_PRINTK_TIME woes
From: Jason Uhlenkott <[EMAIL PROTECTED]> Date: Mon, 22 Aug 2005 13:33:06 -0700 > On Mon, Aug 22, 2005 at 01:20:52PM -0700, David S. Miller wrote: > > Not really, when I'm debugging TCP events over gigabit > > these timestamps are exceptionally handy. > > Yes, but how many of those figures are really significant? I strongly > suspect that the overhead of printk() is high enough, even when we're > just spewing to the dmesg buffer and not the console, that we have a > lot more precision than accuracy at nanosecond resolution. I turn off VC logging, and I turn off disk sync'ing, so it goes straight to the page cache. I really do need sub-microsecond timings when I put a lot of printk tracing into the stack. This is a useful feature, please do not labotomize it just because it's difficult to implement on ia64. Just make a "printk_get_timestamp_because_ia64_sucks()" interface or something like that :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: skge missing ifdefs.
From: Dave Jones <[EMAIL PROTECTED]>
Date: Mon, 22 Aug 2005 15:59:13 -0400
> This is still broken afaics in todays -git.
They are certainly there in Linus's current GIT tree.
...
#ifdef CONFIG_PM
static int skge_suspend(struct pci_dev *pdev, pm_message_t state)
...
static int skge_resume(struct pci_dev *pdev)
...
#endif
static struct pci_driver skge_driver = {
...
#ifdef CONFIG_PM
.suspend = skge_suspend,
.resume = skge_resume,
#endif
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_PRINTK_TIME woes
From: [EMAIL PROTECTED] Date: Mon, 22 Aug 2005 10:42:22 -0700 > At the other extreme ... the current use of sched_clock() with > potentially nano-second resolution is way over the top. Not really, when I'm debugging TCP events over gigabit these timestamps are exceptionally handy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_PRINTK_TIME woes
From: [EMAIL PROTECTED] Date: Mon, 22 Aug 2005 10:42:22 -0700 At the other extreme ... the current use of sched_clock() with potentially nano-second resolution is way over the top. Not really, when I'm debugging TCP events over gigabit these timestamps are exceptionally handy. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: skge missing ifdefs.
From: Dave Jones [EMAIL PROTECTED]
Date: Mon, 22 Aug 2005 15:59:13 -0400
This is still broken afaics in todays -git.
They are certainly there in Linus's current GIT tree.
...
#ifdef CONFIG_PM
static int skge_suspend(struct pci_dev *pdev, pm_message_t state)
...
static int skge_resume(struct pci_dev *pdev)
...
#endif
static struct pci_driver skge_driver = {
...
#ifdef CONFIG_PM
.suspend = skge_suspend,
.resume = skge_resume,
#endif
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_PRINTK_TIME woes
From: Jason Uhlenkott [EMAIL PROTECTED] Date: Mon, 22 Aug 2005 13:33:06 -0700 On Mon, Aug 22, 2005 at 01:20:52PM -0700, David S. Miller wrote: Not really, when I'm debugging TCP events over gigabit these timestamps are exceptionally handy. Yes, but how many of those figures are really significant? I strongly suspect that the overhead of printk() is high enough, even when we're just spewing to the dmesg buffer and not the console, that we have a lot more precision than accuracy at nanosecond resolution. I turn off VC logging, and I turn off disk sync'ing, so it goes straight to the page cache. I really do need sub-microsecond timings when I put a lot of printk tracing into the stack. This is a useful feature, please do not labotomize it just because it's difficult to implement on ia64. Just make a printk_get_timestamp_because_ia64_sucks() interface or something like that :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing spin_unlock in tcp_v4_get_port
From: Ted Unangst [EMAIL PROTECTED]
Subject: missing spin_unlock in tcp_v4_get_port
Date: Mon, 22 Aug 2005 14:17:36 -0700
There appears to be a missing spin_unlock in tcp_v4_get_port.
do {rover++;
if (rover high)
rover = low;
head = tcp_bhash[tcp_bhashfn(rover)];
spin_lock(head-lock);
head-lock is acquired.
tb_for_each(tb, node, head-chain)
if (tb-port == rover)
goto next;
we don't find what we want. break out of while loop.
break;
next:
spin_unlock(head-lock);
} while (--remaining 0);
tcp_port_rover = rover;
spin_unlock(tcp_portalloc_lock);
/* Exhausted local port range during search? */
ret = 1;
if (remaining = 0)
goto fail;
here we go to fail; head-lock is still acquired.
Only if remaining = 0, in which case we broke out of the loop due to
the while (--remaining 0) test, not because of the break;
statement, and thus the lock is not held.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
From: Adrian Bunk <[EMAIL PROTECTED]> Date: Sat, 20 Aug 2005 21:03:09 +0200 > This breaks the compilation with CONFIG_PROC_FS=n: .. > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied, thanks Adrian. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] net/core/sysctl_net_core.c: fix PROC_FS=n compile
From: Adrian Bunk [EMAIL PROTECTED] Date: Sat, 20 Aug 2005 21:03:09 +0200 This breaks the compilation with CONFIG_PROC_FS=n: .. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.5 bug? per-socket TCP keepalive settings
From: Sebastian Kuzminsky <[EMAIL PROTECTED]> Date: Thu, 18 Aug 2005 16:07:32 -0600 > Linux provides 3 non-standard TCP socket options for tweaking the > keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT, > and TCP_KEEPINTVL. The values set on a socket with these options should > override the system-wide default. There is a fourth setting, the SO_KEEPALIVE socket option, which also must be enabled explicitly by the application to enable keepalives. It defaults to off. Your application sets this, so all is fine so far. > The right thing is to wait IDLE seconds, then send CNT probes INTVL > seconds apart, then reset the TCP connection. > > The wrong behavior I'm seeing is the first probe goes out on schedule, > and sometimes a few more probes go out on schedule, but then it stops > sending anything at all. It doesnt send the last of the probes, and it > doesnt send the reset. The connection is stuck in the ESTABLISHED state, > according to netstat. Your test case is questionable, because you do not receive even one ACK in established state, thus the tp->rcv_tstamp variable has no way to get initialized. The only ACK you receive is the one in response to the connection setup SYN, and we don't initialize tp->rcv_stamp for that ACK. The keepalive time checks absolutely require that tp->rcv_tstamp has a valid value, and until you process an ACK in ESTABLISHED state it does not. If you send successfully or receive successfully at least one byte over the connection, and thusly process at least one ACK in ESTABLISHED state, I think you'll find that the keepalives behave properly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From: Ollie Wild <[EMAIL PROTECTED]> Date: Thu, 18 Aug 2005 12:05:31 -0700 > Patrick McHardy wrote: > > >Checking the return value of ip_append_data seems cleaner to me. > >Patch attached. > > > > > Works for me. Applied, thanks everyone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overflows in /proc/net/dev
From: Chris Wedgwood <[EMAIL PROTECTED]> Date: Thu, 18 Aug 2005 09:33:58 -0700 > I thought the concensurs here was that because doing reliable atomic > updates of 64-bit values isn't possible on some (most?) 32-bit > architectures so we need additional locking to make this work which is > undesirable? (It might even be a FAQ by now as this comes up fairly > often). That's correct. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.
From: Anton Blanchard <[EMAIL PROTECTED]> Date: Fri, 19 Aug 2005 04:29:55 +1000 > Calling itanium the "fastest 64bit processor at any given clock frequency" > on lkml is likewise inflammatory :) I totally agree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 09:14:47 +0200
> After reading your suggestions, I understand we still need two slabs.
> One (filp_cachep) without the readahead data, the other one
> (filp_ra_cachep) with it.
Correct.
> static inline struct file_ra_state *get_ra_state(struct file *f)
> {
> #ifdef CONFIG_DEBUG_READAHEAD
> BUG_ON(filp_ra_cachep != GET_PAGE_CACHE(virt_to_page(f)));
> #endif
> return (struct file_ra_state *)(f+1);
> }
Or, instead of mucking with SLAB internals, just put something like
a "filp_ra_present" debugging binary state into filp while it gets
debugged.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 18 Aug 2005 09:14:47 +0200
After reading your suggestions, I understand we still need two slabs.
One (filp_cachep) without the readahead data, the other one
(filp_ra_cachep) with it.
Correct.
static inline struct file_ra_state *get_ra_state(struct file *f)
{
#ifdef CONFIG_DEBUG_READAHEAD
BUG_ON(filp_ra_cachep != GET_PAGE_CACHE(virt_to_page(f)));
#endif
return (struct file_ra_state *)(f+1);
}
Or, instead of mucking with SLAB internals, just put something like
a filp_ra_present debugging binary state into filp while it gets
debugged.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix dst_entry leak in icmp_push_reply()
From: Ollie Wild [EMAIL PROTECTED] Date: Thu, 18 Aug 2005 12:05:31 -0700 Patrick McHardy wrote: Checking the return value of ip_append_data seems cleaner to me. Patch attached. Works for me. Applied, thanks everyone. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overflows in /proc/net/dev
From: Chris Wedgwood [EMAIL PROTECTED] Date: Thu, 18 Aug 2005 09:33:58 -0700 I thought the concensurs here was that because doing reliable atomic updates of 64-bit values isn't possible on some (most?) 32-bit architectures so we need additional locking to make this work which is undesirable? (It might even be a FAQ by now as this comes up fairly often). That's correct. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.
From: Anton Blanchard [EMAIL PROTECTED] Date: Fri, 19 Aug 2005 04:29:55 +1000 Calling itanium the fastest 64bit processor at any given clock frequency on lkml is likewise inflammatory :) I totally agree. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12.5 bug? per-socket TCP keepalive settings
From: Sebastian Kuzminsky [EMAIL PROTECTED] Date: Thu, 18 Aug 2005 16:07:32 -0600 Linux provides 3 non-standard TCP socket options for tweaking the keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT, and TCP_KEEPINTVL. The values set on a socket with these options should override the system-wide default. There is a fourth setting, the SO_KEEPALIVE socket option, which also must be enabled explicitly by the application to enable keepalives. It defaults to off. Your application sets this, so all is fine so far. The right thing is to wait IDLE seconds, then send CNT probes INTVL seconds apart, then reset the TCP connection. The wrong behavior I'm seeing is the first probe goes out on schedule, and sometimes a few more probes go out on schedule, but then it stops sending anything at all. It doesnt send the last of the probes, and it doesnt send the reset. The connection is stuck in the ESTABLISHED state, according to netstat. Your test case is questionable, because you do not receive even one ACK in established state, thus the tp-rcv_tstamp variable has no way to get initialized. The only ACK you receive is the one in response to the connection setup SYN, and we don't initialize tp-rcv_stamp for that ACK. The keepalive time checks absolutely require that tp-rcv_tstamp has a valid value, and until you process an ACK in ESTABLISHED state it does not. If you send successfully or receive successfully at least one byte over the connection, and thusly process at least one ACK in ESTABLISHED state, I think you'll find that the keepalives behave properly. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFT 4/5] CLOCK-Pro page replacement
From: Andrew Morton <[EMAIL PROTECTED]> Date: Wed, 17 Aug 2005 21:05:32 -0700 > Perhaps by uprevving the compiler version? Can't be, we definitely support gcc-2.95 and that compiler definitely has the bug on sparc64. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFT 4/5] CLOCK-Pro page replacement
From: Andrew Morton <[EMAIL PROTECTED]> Date: Wed, 17 Aug 2005 17:38:18 -0700 > I'm prety sure we fixed that somehow. But I forget how. I wish you could remember :-) I honestly don't think we did. The DEFINE_PER_CPU() definition still looks the same, and the way the .data.percpu section is layed out in the vmlinux.lds.S is still the same as well. The places which are not handled currently are in not-often-used areas such as IPVS, some S390 drivers, and some other platform specific code (likely platforms where the gcc problem in question never existed). I do note two important spots where the initialization is not present, the loopback driver statistics and the scsi_done_q. Hmmm... If we are handling it somehow, that would be nice to know for certain, because we could thus remove all of the ugly initializers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
