Re: 2.6.24 panics initializing ne2k in mips.
On Sat, Feb 23, 2008 at 7:19 AM, Rob Landley <[EMAIL PROTECTED]> wrote: > On Friday 22 February 2008 08:17:44 you wrote: > > On Tue, Jan 29, 2008 at 8:16 PM, Ralf Baechle <[EMAIL PROTECTED]> wrote: > > > Known problem. The issue only hits when probing IRQs as the NE2000 > > > driver does. This got dropped on the floor in December. > > > > In 2.6.24.2 under qemu (default config as well as my one) its still > > dies at this point. > > The patches that fixed it for me were: > > http://kernel.org/hg/index.cgi/linux-2.6/rev/85295 > http://kernel.org/hg/index.cgi/linux-2.6/rev/85296 > > Which, as you can see, were already committed to the kernel repository during > the 2.6.25 merge window. > > They don't seem to be in the 2.6.24.2 tarball, though. > > I dunno if that's the same problem you're seeing or not... Yep that was the problem. Thanks for the help Rob. This fixes the 2.6.24 kernel for qemu, I would like to see these patches put into the stable series. Is that OK for everyone? if they are in the 2.6.25 tree then we just send the commit ids to the stable team... I will send the details to stable on monday if knobody shouts. Samuel -- 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/
2.6.25-git-current several Section mismatch in reference from ...
compiling with make CONFIG_DEBUG_SECTION_MISMATCH=y I see the following warnings: CC kernel/stacktrace.o CC kernel/irq/handle.o LD mm/built-in.o WARNING: mm/built-in.o(.meminit.text+0x89e): Section mismatch in reference from the function free_area_init_core() to the function .init.text:setup_usemap() The function __meminit free_area_init_core() references a function __init setup_usemap(). If setup_usemap is only used by free_area_init_core then annotate setup_usemap with a matching annotation. WARNING: mm/built-in.o(.data+0x10a4): Section mismatch in reference from the variable cpu_callback_nb.23582 to the function .devinit.text:cpu_callback() The variable cpu_callback_nb.23582 references the function __devinit cpu_callback() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, CC ipc/util.o CC fs/mpage.o [...] LDS arch/x86/kernel/vmlinux.lds CC kernel/power/swsusp.o CC fs/nfsctl.o LD arch/x86/kernel/built-in.o WARNING: arch/x86/kernel/built-in.o(.text+0x13277): Section mismatch in reference from the function cpu_exit_clear() to the function .cpuinit.text:cpu_uninit() The function cpu_exit_clear() references the function __cpuinit cpu_uninit(). This is often because cpu_exit_clear lacks a __cpuinit annotation or the annotation of cpu_uninit is wrong. LD security/built-in.o [...] CC kernel/latencytop.o CC [M] fs/cifs/dir.o CC block/genhd.o LD kernel/built-in.o fs/cifs/dir.c: In function ‘cifs_ci_compare’: fs/cifs/dir.c:594: warning: passing argument 1 of ‘__constant_memcpy’ discards qualifiers from pointer target type fs/cifs/dir.c:594: warning: passing argument 1 of ‘__memcpy’ discards qualifiers from pointer target type fs/cifs/dir.c:594: warning: passing argument 1 of ‘__constant_memcpy’ discards qualifiers from pointer target type fs/cifs/dir.c:594: warning: passing argument 1 of ‘__memcpy’ discards qualifiers from pointer target type WARNING: kernel/built-in.o(.text+0x30269): Section mismatch in reference from the function take_cpu_down() to the variable .cpuinit.data:cpu_chain The function take_cpu_down() references the variable __cpuinitdata cpu_chain. This is often because take_cpu_down lacks a __cpuinitdata annotation or the annotation of cpu_chain is wrong. WARNING: kernel/built-in.o(.text+0x302f7): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain The function _cpu_down() references the variable __cpuinitdata cpu_chain. This is often because _cpu_down lacks a __cpuinitdata annotation or the annotation of cpu_chain is wrong. WARNING: kernel/built-in.o(.text+0x3036d): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain The function _cpu_down() references the variable __cpuinitdata cpu_chain. This is often because _cpu_down lacks a __cpuinitdata annotation or the annotation of cpu_chain is wrong. WARNING: kernel/built-in.o(.text+0x303cf): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain The function _cpu_down() references the variable __cpuinitdata cpu_chain. This is often because _cpu_down lacks a __cpuinitdata annotation or the annotation of cpu_chain is wrong. WARNING: kernel/built-in.o(.text+0x303fb): Section mismatch in reference from the function _cpu_down() to the variable .cpuinit.data:cpu_chain The function _cpu_down() references the variable __cpuinitdata cpu_chain. This is often because _cpu_down lacks a __cpuinitdata annotation or the annotation of cpu_chain is wrong. WARNING: kernel/built-in.o(.text+0x3050e): Section mismatch in reference from the function unregister_cpu_notifier() to the variable .cpuinit.data:cpu_chain The function unregister_cpu_notifier() references the variable __cpuinitdata cpu_chain. This is often because unregister_cpu_notifier lacks a __cpuinitdata annotation or the annotation of cpu_chain is wrong. WARNING: kernel/built-in.o(.data+0x270): Section mismatch in reference from the variable profile_cpu_callback_nb.19213 to the function .devinit.text:profile_cpu_callback() The variable profile_cpu_callback_nb.19213 references the function __devinit profile_cpu_callback() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: kernel/built-in.o(.data+0x1b48): Section mismatch in reference from the variable workqueue_cpu_callback_nb.13434 to the function .devinit.text:workqueue_cpu_callback() The variable workqueue_cpu_callback_nb.13434 references the function __devinit workqueue_cpu_callback() If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template,
Re: [PATCH 09/16] um: use get_personality()
On Fri, 22 Feb 2008 20:39:00 +0800 (CST) WANG Cong <[EMAIL PROTECTED]> wrote: > From: Jeff Dike <[EMAIL PROTECTED]> > Subject: Re: [PATCH 09/16] um: use get_personality() > Date: Wed, 20 Feb 2008 11:27:34 -0500 > Message-ID: <[EMAIL PROTECTED]> > > > On Wed, Feb 20, 2008 at 07:19:13PM +0800, WANG Cong wrote: > > > Signed-off-by: WANG Cong <[EMAIL PROTECTED]> > > > > Looks good - you should add some sort of changelog though. > > > > Thanks, Jeff. > > It seems that you're the only one who received this patchset of mine. > And I found that lkml.org didn't receive these neither. ;( > > I don't know if Andrew received all of them, if not, I must resend. > No, I don't seem to have received them. -- 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: regression: CD burning (k3b) went broke
On Fri, 2008-02-22 at 08:32 +0100, Jens Axboe wrote: > On Thu, Feb 21 2008, Mike Galbraith wrote: > > Greetings, > > > > K3b recently (9a4c854..5d9c4a7 pull) began terminally griping about > > buffer underrun upon every attempt to burn a CD. I can't fully bisect > > the problem because intervening kernels hang soft during boot. Using > > git bisect visualize, and converting to postable text: > > > > bisect/bad block: add request->raw_data_len > > (6b00769fe1502b4ad97bb327ef7ac971b208bfb5) > > bisect block: update bio according to DMA alignment padding > > (40b01b9bbdf51ae543a04744283bf2d56c4a6afa) > > libata: update ATAPI overflow draining > > bisect/good-e164094964e6e20fe7fce418e06a9dce952bb7a4 > > Tejun? He must be off having a life or something ;-) Meanwhile back at the ranch, reverting 6b00769fe1502b4ad97bb327ef7ac971b208bfb5 40b01b9bbdf51ae543a04744283bf2d56c4a6afa and the one entangled line from dde2020754aeb14e17052d61784dcb37f252aac2 did restore my burner. -Mike -- 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: Regression [Was: Boot hang with stack protector on x86_64]
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > could you try the fix below ontop of x86.git#testing, does it solve > your boot hang? find below another fix that is somewhat better as it does not affect the native kernel and !PARAVIRT. btw., this also explains why this bug wasnt reported sooner against x86.git#testing: people done normally use PARAVIRT on 64-bit yet. (there is no 64-bit host support) Ingo > Subject: x86: stackprotector & PARAVIRT fix From: Ingo Molnar <[EMAIL PROTECTED]> Date: Sat Feb 23 07:06:55 CET 2008 on paravirt enabled 64-bit kernels the paravirt ops do function calls themselves - which is bad with the stackprotector - for example pda_init() loads 0 into %gs and then does MSR_GS_BASE write (which modifies gs.base) - but that MSR write is a function call on paravirt, which with stackprotector tries to read the stack canary from the PDA ... crashing the bootup. the solution was suggested by Arjan van de Ven: to exclude paravirt.c from stackprotector, too many lowlevel functionality is in it. It's not like we'll have paravirt functions with character arrays on their stack anyway... Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- arch/x86/kernel/Makefile |1 + 1 file changed, 1 insertion(+) Index: linux-x86.q/arch/x86/kernel/Makefile === --- linux-x86.q.orig/arch/x86/kernel/Makefile +++ linux-x86.q/arch/x86/kernel/Makefile @@ -15,6 +15,7 @@ nostackp := $(call cc-option, -fno-stack CFLAGS_vsyscall_64.o := $(PROFILING) -g0 $(nostackp) CFLAGS_hpet.o := $(nostackp) CFLAGS_tsc_64.o:= $(nostackp) +CFLAGS_paravirt.o := $(nostackp) obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o obj-y += traps_$(BITS).o irq_$(BITS).o -- 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.25-rc2 regression - hang on suspend
On Fri, 2008-02-22 at 16:56 +0100, Rafael J. Wysocki wrote: > On Friday, 22 of February 2008, Soeren Sonnenburg wrote: > > On Fri, 2008-02-22 at 00:06 +0100, Rafael J. Wysocki wrote: > > > On Thursday, 21 of February 2008, Soeren Sonnenburg wrote: > > > > On Thu, 2008-02-21 at 01:31 +0100, Rafael J. Wysocki wrote: > > > > > On Wednesday, 20 of February 2008, Soeren Sonnenburg wrote: > > > > > > On Wed, 2008-02-20 at 00:50 +0100, Rafael J. Wysocki wrote: > > [...] > > Also when compiling these many kernels via make -j4 I noted that I could > > hardly move the mouse / use the keyboard, but saw random jumps and > > key-repetitions... > > This last bit is most likely a scheduler issue. Do you have > CONFIG_GROUP_SCHED > set by chance? If you do, please try to unset it and see if that helps. Yes I had. Disabling this helped a lot -- the kernel seems to behave normally with this option unset. Soeren -- 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 [RT] 08/14] add a loop counter based timeout mechanism
On Fri, 2008-02-22 at 13:36 -0700, Peter W. Morreale wrote: > On Fri, 2008-02-22 at 11:55 -0800, Sven-Thorsten Dietrich wrote: > > > > In high-contention, short-hold time situations, it may even make sense > > to have multiple CPUs with multiple waiters spinning, depending on > > hold-time vs. time to put a waiter to sleep and wake them up. > > > > The wake-up side could also walk ahead on the queue, and bring up > > spinners from sleeping, so that they are all ready to go when the lock > > flips green for them. > > > > I did try an attempt at this one time. The logic was merely if the > pending owner was running, wakeup the next waiter. The results were > terrible for the benchmarks used, as compared to the current > implementation. Yup, but you cut the CONTEXT where I said: "for very large SMP systems" Specifically, what I mean, is an SMP system, where I have enough CPUs to do this: let (t_Tcs) be the time to lock, transition and unlock an un-contended critical section (i.e. the one that I am the pending waiter for). let (t_W) be the time to wake up a sleeping task. and let (t_W > t_Tcs) Then, "for very large SMP systems" if S = (t_W / t_Tcs), then S designates the number of tasks to transition a critical section before the first sleeper would wake up. and the number of CPUs > S. The time for an arbitrary number of tasks N > S which are all competing for lock L, to transition a critical section (T_N_cs), approaches: T_N_cs = (N * t_W) if you have only 1 task spinning. but if you can have N tasks spinning, (T_N_cs) approaches: T_N_cs = (N * t_Tcs) and with the premise, that t_W > t_Tcs, you should see a dramatic throughput improvement when running PREEMPT_RT on VERY LARGE SMP systems. I want to disclaim, that the math above is very much simplified, but I hope its sufficient to demonstrate the concept. I have to acknowledge Ingo's comments, that this is all suspect until proven to make a positive difference in "non-marketing" workloads. I personally *think* we are past that already, and the adaptive concept can and will be extended and scaled as M-socket and N-core based SMP proliferates into to larger grid-based systems. But there is plenty more to do to prove it. (someone send me a 1024 CPU box and a wind-powered-generator) Sven > > What this meant was that virtually every unlock performed a wakeup, if > not for the new pending owner, than the next-in-line waiter. > > My impression at the time was that the contention for the rq lock is > significant, regardless of even if the task being woken up was already > running. > > I can generate numbers if that helps. > > -PWM > > > -- 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] drivers/thermal/thermal.c: fix a check-after-use
On Tuesday 19 February 2008 19:14, Adrian Bunk wrote: > This patch fixes a check-after-use spotted by the Coverity checker. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > 570462ca4441d8d63dfd46efe6e5b2b1c251a611 diff --git > a/drivers/thermal/thermal.c b/drivers/thermal/thermal.c > index e782b3e..958654b 100644 > --- a/drivers/thermal/thermal.c > +++ b/drivers/thermal/thermal.c > @@ -308,10 +308,10 @@ int thermal_zone_bind_cooling_device(struct > thermal_zone_device *tz, > struct thermal_cooling_device_instance *pos; > int result; > > - if (trip >= tz->trips || (trip < 0 && trip != THERMAL_TRIPS_NONE)) > + if (!tz || !cdev) > return -EINVAL; > > - if (!tz || !cdev) > + if (trip >= tz->trips || (trip < 0 && trip != THERMAL_TRIPS_NONE)) > return -EINVAL; > > dev = > > -- this patch no longer applies because the bogus check for a programming error was already replaced by a better check of run-time params. thanks, -len -- 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.25-rc2 + smartd = hang
Jeff Garzik wrote: >> If this is the prefered driver these days, maybe it shouldn't be marked >> experimental in the menu anymore? > > It's not marked experimental. > the comment on the very top of drivers/ata says: tristate "Serial ATA (prod) and Parallel ATA (experimental) drivers" this is a bit confusing -- 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: [stable] [patch 34/38] kbuild: allow -fstack-protector to take effect
On Fri, Feb 22, 2008 at 07:53:56PM -0800, Greg KH wrote: > On Sat, Feb 23, 2008 at 04:41:15AM +0100, Sam Ravnborg wrote: > > On Fri, Feb 22, 2008 at 04:53:49PM -0800, Greg KH wrote: > > > On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote: > > > > On Fri, 22 Feb 2008 16:31:33 -0800 > > > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > 2.6.24-stable review patch. If anyone has any objections, please let > > > > > us know. > > > > > > > > > > > > not ready for -stable yet. if ever for backporting (doubtful) > > > > > > Ok, dropped from -stable, thanks. > > > > For the record I agree with Arjan that it is not yet -stable ready. > > Ok. Then who sent this to the stable alias in the first place? > > Sam, you added the "cc: [EMAIL PROTECTED]" to the patch, and that caused > it to be sent to us when it went into Linus's tree. If you don't want > things like this to go into the -stable tree, don't mark it as such :) When I added the tag I was convinced this was -stable material. Only later the testing done by James revealed that this was bogus and I had long forgotten I added -stable to the patch. Sam -- 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: Regression [Was: Boot hang with stack protector on x86_64]
James,
could you try the fix below ontop of x86.git#testing, does it solve your
boot hang?
Ingo
--->
Subject: x86: stackprotector fix: do not zap %gs
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Sat Feb 23 07:06:55 CET 2008
pda_init() puts 0 into %gs - that's wrong because any %gs access will
fault from now on and we already have a dummy PDA set up that can be
accessed just fine.
This normally does not matter because almost nothing accesses %gs this
early ... but the stackprotector now does to read the canary ...
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
arch/x86/kernel/setup64.c |2 --
1 file changed, 2 deletions(-)
Index: linux-x86.q/arch/x86/kernel/setup64.c
===
--- linux-x86.q.orig/arch/x86/kernel/setup64.c
+++ linux-x86.q/arch/x86/kernel/setup64.c
@@ -165,8 +165,6 @@ void pda_init(int cpu)
{
struct x8664_pda *pda = cpu_pda(cpu);
- /* Setup up data that may be needed in __get_free_pages early */
- asm volatile("movl %0,%%fs ; movl %0,%%gs" :: "r" (0));
/* Memory clobbers used to order PDA accessed */
mb();
wrmsrl(MSR_GS_BASE, pda);
--
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/
[RFC] Genirq and CPU isolation
Hi Thomas,
While reviewing CPU isolation patches Peter pointed out that instead of
changing arch specific irq handling I should be extending genirq code.
Which makes perfect sense. Why didn't I think of that before :)
Basically the idea is that by default isolated CPUs must not get HW
irqs routed to them (besides IPIs and stuff of course).
Does the patch included below look like the right approach ?
btw select_smp_affinity() which is currently used only by alpha seemed
out of place. It's called multiple times for shared irqs. ie Every time
new handler is registered irq is moved to a different CPU.
So I moved it under "if (!shared)" check inside setup_irq().
The patch introduces generic version of the select_smp_affinity() that
sets the affinity mask to "online_cpus - isolated_cpus", and updates
x86_32 and alpha load balancers to ignore isolated cpus.
Booted on Core2 laptop and dual Opteron boxes with and w/o isolcpus=
options and everything seems to work as expected.
I wanted to run this by you before I include it in my patch series.
Thanx
Max
diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index facf82a..6b01702 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -51,7 +51,7 @@ select_smp_affinity(unsigned int irq)
if (!irq_desc[irq].chip->set_affinity || irq_user_affinity[irq])
return 1;
- while (!cpu_possible(cpu))
+ while (!cpu_possible(cpu) || cpu_isolated(cpu))
cpu = (cpu < (NR_CPUS-1) ? cpu + 1 : 0);
last_cpu = cpu;
diff --git a/arch/x86/kernel/genapic_flat_64.c
b/arch/x86/kernel/genapic_flat_64.c
index e02e58c..07352b7 100644
--- a/arch/x86/kernel/genapic_flat_64.c
+++ b/arch/x86/kernel/genapic_flat_64.c
@@ -21,9 +21,7 @@
static cpumask_t flat_target_cpus(void)
{
- cpumask_t target;
- cpus_andnot(target, cpu_online_map, cpu_isolated_map);
- return target;
+ return cpu_online_map;
}
static cpumask_t flat_vector_allocation_domain(int cpu)
diff --git a/arch/x86/kernel/io_apic_32.c b/arch/x86/kernel/io_apic_32.c
index 4ca5486..9c8816f 100644
--- a/arch/x86/kernel/io_apic_32.c
+++ b/arch/x86/kernel/io_apic_32.c
@@ -468,7 +468,7 @@ static void do_irq_balance(void)
for_each_possible_cpu(i) {
int package_index;
CPU_IRQ(i) = 0;
- if (!cpu_online(i))
+ if (!cpu_online(i) || cpu_isolated(i))
continue;
package_index = CPU_TO_PACKAGEINDEX(i);
for (j = 0; j < NR_IRQS; j++) {
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 176e5e7..287bc64 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -253,14 +253,7 @@ static inline void set_balance_irq_affinity(unsigned int
irq, cpumask_t mask)
}
#endif
-#ifdef CONFIG_AUTO_IRQ_AFFINITY
extern int select_smp_affinity(unsigned int irq);
-#else
-static inline int select_smp_affinity(unsigned int irq)
-{
- return 1;
-}
-#endif
extern int no_irq_affinity;
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 438a014..e74db94 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -376,6 +376,9 @@ int setup_irq(unsigned int irq, struct irqaction *new)
} else
/* Undo nested disables: */
desc->depth = 1;
+
+ /* Set default affinity mask once everything is setup */
+ select_smp_affinity(irq);
}
/* Reset broken irq detection when installing new handler */
desc->irq_count = 0;
@@ -488,6 +491,26 @@ void free_irq(unsigned int irq, void *dev_id)
}
EXPORT_SYMBOL(free_irq);
+#ifndef CONFIG_AUTO_IRQ_AFFINITY
+/**
+ * Generic version of the affinity autoselector.
+ * Called under desc->lock from setup_irq().
+ * btw Should we rename this to select_irq_affinity() ?
+ */
+int select_smp_affinity(unsigned int irq)
+{
+ cpumask_t usable_cpus;
+
+ if (!irq_can_set_affinity(irq))
+ return 0;
+
+ cpus_andnot(usable_cpus, cpu_online_map, cpu_isolated_map);
+ irq_desc[irq].affinity = usable_cpus;
+ irq_desc[irq].chip->set_affinity(irq, usable_cpus);
+ return 0;
+}
+#endif
+
/**
* request_irq - allocate an interrupt line
* @irq: Interrupt line to allocate
@@ -555,8 +578,6 @@ int request_irq(unsigned int irq, irq_handler_t handler,
action->next = NULL;
action->dev_id = dev_id;
- select_smp_affinity(irq);
-
#ifdef CONFIG_DEBUG_SHIRQ
if (irqflags & IRQF_SHARED) {
/*
--
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/
[PATCH -mm 4/4] alpha: remove unused DEBUG_FORCEDAC define in IOMMU
This just removes unused DEBUG_FORCEDAC define in the IOMMU code. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> Cc: Richard Henderson <[EMAIL PROTECTED]> Cc: Ivan Kokshaysky <[EMAIL PROTECTED]> Cc: Andrew Morton <[EMAIL PROTECTED]> --- arch/alpha/kernel/pci_iommu.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 54540c3..be6fa10 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -31,7 +31,6 @@ #endif #define DEBUG_NODIRECT 0 -#define DEBUG_FORCEDAC 0 #define ISA_DMA_MASK 0x00ff -- 1.5.3.4 -- 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/
[PATCH -mm 3/4] alpha: make IOMMU respect the segment boundary limits
This patch makes the IOMMU code not allocate a memory area spanning
LLD's segment boundary.
is_span_boundary() judges whether a memory area spans LLD's segment
boundary. If iommu_arena_find_pages() finds such a area, it tries to
find the next available memory area.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Cc: Richard Henderson <[EMAIL PROTECTED]>
Cc: Ivan Kokshaysky <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci_iommu.c | 40 ++--
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index e54f829..54540c3 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -126,13 +126,34 @@ iommu_arena_new(struct pci_controller *hose, dma_addr_t
base,
return iommu_arena_new_node(0, hose, base, window_size, align);
}
+static inline int is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size)
+{
+ shift = (shift + index) & (boundary_size - 1);
+ return shift + nr > boundary_size;
+}
+
/* Must be called with the arena lock held */
static long
-iommu_arena_find_pages(struct pci_iommu_arena *arena, long n, long mask)
+iommu_arena_find_pages(struct device *dev, struct pci_iommu_arena *arena,
+ long n, long mask)
{
unsigned long *ptes;
long i, p, nent;
int pass = 0;
+ unsigned long base;
+ unsigned long boundary_size;
+
+ BUG_ON(arena->dma_base & ~PAGE_MASK);
+ base = arena->dma_base >> PAGE_SHIFT;
+ if (dev)
+ boundary_size = ALIGN(dma_get_max_seg_size(dev) + 1, PAGE_SIZE)
+ >> PAGE_SHIFT;
+ else
+ boundary_size = ALIGN(1UL << 32, PAGE_SIZE) >> PAGE_SHIFT;
+
+ BUG_ON(!is_power_of_2(boundary_size));
/* Search forward for the first mask-aligned sequence of N free ptes */
ptes = arena->ptes;
@@ -142,6 +163,11 @@ iommu_arena_find_pages(struct pci_iommu_arena *arena, long
n, long mask)
again:
while (i < n && p+i < nent) {
+ if (!i && is_span_boundary(p, n, base, boundary_size)) {
+ p = ALIGN(p + 1, mask + 1);
+ goto again;
+ }
+
if (ptes[p+i])
p = ALIGN(p + i + 1, mask + 1), i = 0;
else
@@ -170,7 +196,8 @@ again:
}
static long
-iommu_arena_alloc(struct pci_iommu_arena *arena, long n, unsigned int align)
+iommu_arena_alloc(struct device *dev, struct pci_iommu_arena *arena, long n,
+ unsigned int align)
{
unsigned long flags;
unsigned long *ptes;
@@ -181,7 +208,7 @@ iommu_arena_alloc(struct pci_iommu_arena *arena, long n,
unsigned int align)
/* Search for N empty ptes */
ptes = arena->ptes;
mask = max(align, arena->align_entry) - 1;
- p = iommu_arena_find_pages(arena, n, mask);
+ p = iommu_arena_find_pages(dev, arena, n, mask);
if (p < 0) {
spin_unlock_irqrestore(>lock, flags);
return -1;
@@ -231,6 +258,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr,
size_t size,
unsigned long paddr;
dma_addr_t ret;
unsigned int align = 0;
+ struct device *dev = pdev ? >dev : NULL;
paddr = __pa(cpu_addr);
@@ -278,7 +306,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr,
size_t size,
/* Force allocation to 64KB boundary for ISA bridges. */
if (pdev && pdev == isa_bridge)
align = 8;
- dma_ofs = iommu_arena_alloc(arena, npages, align);
+ dma_ofs = iommu_arena_alloc(dev, arena, npages, align);
if (dma_ofs < 0) {
printk(KERN_WARNING "pci_map_single failed: "
"could not allocate dma page tables\n");
@@ -565,7 +593,7 @@ sg_fill(struct device *dev, struct scatterlist *leader,
struct scatterlist *end,
paddr &= ~PAGE_MASK;
npages = calc_npages(paddr + size);
- dma_ofs = iommu_arena_alloc(arena, npages, 0);
+ dma_ofs = iommu_arena_alloc(dev, arena, npages, 0);
if (dma_ofs < 0) {
/* If we attempted a direct map above but failed, die. */
if (leader->dma_address == 0)
@@ -832,7 +860,7 @@ iommu_reserve(struct pci_iommu_arena *arena, long pg_count,
long align_mask)
/* Search for N empty ptes. */
ptes = arena->ptes;
- p = iommu_arena_find_pages(arena, pg_count, align_mask);
+ p = iommu_arena_find_pages(NULL, arena, pg_count, align_mask);
if (p < 0) {
spin_unlock_irqrestore(>lock, flags);
return -1;
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
[PATCH -mm 1/4] alpha: convert IOMMU to use ALIGN()
This patch is preparation for modifications to fix the IOMMU segment
boundary problem.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Cc: Richard Henderson <[EMAIL PROTECTED]>
Cc: Ivan Kokshaysky <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci_iommu.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 26d3789..bbf9990 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -136,11 +136,11 @@ iommu_arena_find_pages(struct pci_iommu_arena *arena,
long n, long mask)
/* Search forward for the first mask-aligned sequence of N free ptes */
ptes = arena->ptes;
nent = arena->size >> PAGE_SHIFT;
- p = (arena->next_entry + mask) & ~mask;
+ p = ALIGN(arena->next_entry, mask + 1);
i = 0;
while (i < n && p+i < nent) {
if (ptes[p+i])
- p = (p + i + 1 + mask) & ~mask, i = 0;
+ p = ALIGN(p + i + 1, mask + 1), i = 0;
else
i = i + 1;
}
@@ -153,7 +153,7 @@ iommu_arena_find_pages(struct pci_iommu_arena *arena, long
n, long mask)
p = 0, i = 0;
while (i < n && p+i < nent) {
if (ptes[p+i])
- p = (p + i + 1 + mask) & ~mask, i = 0;
+ p = ALIGN(p + i + 1, mask + 1), i = 0;
else
i = i + 1;
}
--
1.5.3.4
--
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/
[PATCH -mm 0/4] fix iommu segment boundary problems (alpha)
This patchset is another sequel to my patchset to fix iommu segment boundary problems, IOMMUs allocate memory areas without considering a low level driver's segment boundary limits: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11919.html This patchset fixes the Alpha IOMMU code. There are four patches in this patchset. The first two patches are preparation for the third patch, which fixes the IOMMU segment boundary problem. The fourth patch just a cleanup, which removes an unused code. This is against 2.6.25-rc2-mm1. -- 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/
[PATCH -mm 2/4] alpha: IOMMU had better access to the free space bitmap at only one place
iommu_arena_find_pages duplicates the code to access to the bitmap for
free space management. This patch convert the IOMMU code to have only
one place to access the bitmap, in the popular way that other IOMMUs
(e.g. POWER and SPARC) do.
This patch is preparation for modifications to fix the IOMMU segment
boundary problem.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Cc: Richard Henderson <[EMAIL PROTECTED]>
Cc: Ivan Kokshaysky <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci_iommu.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index bbf9990..e54f829 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -132,12 +132,15 @@ iommu_arena_find_pages(struct pci_iommu_arena *arena,
long n, long mask)
{
unsigned long *ptes;
long i, p, nent;
+ int pass = 0;
/* Search forward for the first mask-aligned sequence of N free ptes */
ptes = arena->ptes;
nent = arena->size >> PAGE_SHIFT;
p = ALIGN(arena->next_entry, mask + 1);
i = 0;
+
+again:
while (i < n && p+i < nent) {
if (ptes[p+i])
p = ALIGN(p + i + 1, mask + 1), i = 0;
@@ -146,19 +149,18 @@ iommu_arena_find_pages(struct pci_iommu_arena *arena,
long n, long mask)
}
if (i < n) {
-/* Reached the end. Flush the TLB and restart the
- search from the beginning. */
- alpha_mv.mv_pci_tbi(arena->hose, 0, -1);
-
- p = 0, i = 0;
- while (i < n && p+i < nent) {
- if (ptes[p+i])
- p = ALIGN(p + i + 1, mask + 1), i = 0;
- else
- i = i + 1;
- }
-
- if (i < n)
+ if (pass < 1) {
+ /*
+* Reached the end. Flush the TLB and restart
+* the search from the beginning.
+ */
+ alpha_mv.mv_pci_tbi(arena->hose, 0, -1);
+
+ pass++;
+ p = 0;
+ i = 0;
+ goto again;
+ } else
return -1;
}
--
1.5.3.4
--
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/
[PATCH 4/4] gxfb: use PCI_DEVICE() for gxfb's pci device table
Drop the class/class_mask stuff; it's unnecessary
as long as the vendor and device IDs match.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
drivers/video/geode/gxfb_core.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/video/geode/gxfb_core.c b/drivers/video/geode/gxfb_core.c
index 07ff4bc..08fa25e 100644
--- a/drivers/video/geode/gxfb_core.c
+++ b/drivers/video/geode/gxfb_core.c
@@ -396,9 +396,7 @@ static void gxfb_remove(struct pci_dev *pdev)
}
static struct pci_device_id gxfb_id_table[] = {
- { PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_GX_VIDEO,
- PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY << 16,
- 0xff, 0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_GX_VIDEO) },
{ 0, }
};
--
1.5.3.7
--
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/
[PATCH 2/4] gxfb: Set the right registers to tweak the sync polarity
This one's from Jordan..
>From f29234fa3f3ece430c48227d0e2c0f0bcbff6e0f Mon Sep 17 00:00:00 2001
From: Jordan Crouse <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 19:48:40 -0500
Subject: [PATCH] gxfb: Set the right registers to tweak the sync polarity
While running in flatpanel mode it is important to change the FP
sync bits (VG register 0x408) rather then the CRT sync bits
(VG register 0x008). This patch keeps the CRT sync bits at default
when a flatpanel exists.
Note that this also fixes inverted logic; we want CRT_VSYNC_POL to
be set (ie, vsync is normally high) when FB_SYNC_VERT_HIGH_ACT is unset.
Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
---
drivers/video/geode/video_gx.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/video/geode/video_gx.c b/drivers/video/geode/video_gx.c
index febf09c..a53936f 100644
--- a/drivers/video/geode/video_gx.c
+++ b/drivers/video/geode/video_gx.c
@@ -207,7 +207,7 @@ gx_configure_tft(struct fb_info *info)
fp = 0x0F10;
- /* Add sync polarity */
+ /* Configure sync polarity */
if (!(info->var.sync & FB_SYNC_VERT_HIGH_ACT))
fp |= GX_FP_PT2_VSP;
@@ -268,11 +268,15 @@ static void gx_configure_display(struct fb_info *info)
/* Enable hsync and vsync. */
dcfg |= GX_DCFG_HSYNC_EN | GX_DCFG_VSYNC_EN;
- /* Sync polarities. */
- if (info->var.sync & FB_SYNC_HOR_HIGH_ACT)
- dcfg |= GX_DCFG_CRT_HSYNC_POL;
- if (info->var.sync & FB_SYNC_VERT_HIGH_ACT)
- dcfg |= GX_DCFG_CRT_VSYNC_POL;
+ /* Only change the sync polarities if we are running
+* in CRT mode. The FP polarities will be handled in
+* gxfb_configure_tft */
+ if (par->enable_crt) {
+ if (!(info->var.sync & FB_SYNC_HOR_HIGH_ACT))
+ dcfg |= GX_DCFG_CRT_HSYNC_POL;
+ if (!(info->var.sync & FB_SYNC_VERT_HIGH_ACT))
+ dcfg |= GX_DCFG_CRT_VSYNC_POL;
+ }
/* Enable the display logic */
/* Set up the DACS to blank normally */
--
1.5.3.7
--
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/
[PATCH 3/4] gxfb: Don't enable the CRT DACs when we are in flatpanel mode
This one's also from Jordan.
>From dea8d19f689706985b30be745ef1151082866374 Mon Sep 17 00:00:00 2001
From: Jordan Crouse <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 19:55:09 -0500
Subject: [PATCH] gxfb: Don't enable the CRT DACs when we are in flatpanel mode
When the FP strap is enabled, don't turn on the CRT DACs - that will save
about 35 mA of power.
Updated/cleaned up by Andres Salomon.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
---
drivers/video/geode/video_gx.c | 32 +---
1 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/video/geode/video_gx.c b/drivers/video/geode/video_gx.c
index a53936f..b436155 100644
--- a/drivers/video/geode/video_gx.c
+++ b/drivers/video/geode/video_gx.c
@@ -238,18 +238,6 @@ static void gx_configure_display(struct fb_info *info)
struct geodefb_par *par = info->par;
u32 dcfg, misc;
- /* Set up the MISC register */
-
- misc = readl(par->vid_regs + GX_MISC);
-
- /* Power up the DAC */
- misc &= ~(GX_MISC_A_PWRDN | GX_MISC_DAC_PWRDN);
-
- /* Disable gamma correction */
- misc |= GX_MISC_GAM_EN;
-
- writel(misc, par->vid_regs + GX_MISC);
-
/* Write the display configuration */
dcfg = readl(par->vid_regs + GX_DCFG);
@@ -268,14 +256,28 @@ static void gx_configure_display(struct fb_info *info)
/* Enable hsync and vsync. */
dcfg |= GX_DCFG_HSYNC_EN | GX_DCFG_VSYNC_EN;
- /* Only change the sync polarities if we are running
-* in CRT mode. The FP polarities will be handled in
-* gxfb_configure_tft */
+ misc = readl(par->vid_regs + GX_MISC);
+
+ /* Disable gamma correction */
+ misc |= GX_MISC_GAM_EN;
+
if (par->enable_crt) {
+
+ /* Power up the CRT DACs */
+ misc &= ~(GX_MISC_A_PWRDN | GX_MISC_DAC_PWRDN);
+ writel(misc, par->vid_regs + GX_MISC);
+
+ /* Only change the sync polarities if we are running
+* in CRT mode. The FP polarities will be handled in
+* gxfb_configure_tft */
if (!(info->var.sync & FB_SYNC_HOR_HIGH_ACT))
dcfg |= GX_DCFG_CRT_HSYNC_POL;
if (!(info->var.sync & FB_SYNC_VERT_HIGH_ACT))
dcfg |= GX_DCFG_CRT_VSYNC_POL;
+ } else {
+ /* Power down the CRT DACs if in FP mode */
+ misc |= (GX_MISC_A_PWRDN | GX_MISC_DAC_PWRDN);
+ writel(misc, par->vid_regs + GX_MISC);
}
/* Enable the display logic */
--
1.5.3.7
--
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/
[PATCH 1/4] gxfb: Replace FBSIZE config option with a kernel argument
Use a command line option (fbsize:) rather than hardcoding the vram size.
LxFB already does this; it's useful for machines that can't query the
BIOS for fb size. This patch originated from David Woodhouse, was
modified by Jordan Crouse, and was then modified further by me.
Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
---
drivers/video/geode/Kconfig | 20
drivers/video/geode/display_gx.c |7 ---
drivers/video/geode/gxfb_core.c | 19 ---
3 files changed, 12 insertions(+), 34 deletions(-)
diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig
index 7608429..c5d8ba4 100644
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -38,26 +38,6 @@ config FB_GEODE_GX
If unsure, say N.
-config FB_GEODE_GX_SET_FBSIZE
- bool "Manually specify the Geode GX framebuffer size"
- depends on FB_GEODE_GX
- default n
- ---help---
- If you want to manually specify the size of your GX framebuffer,
- say Y here, otherwise say N to dynamically probe it.
-
- Say N unless you know what you are doing.
-
-config FB_GEODE_GX_FBSIZE
- hex "Size of the GX framebuffer, in bytes"
- depends on FB_GEODE_GX_SET_FBSIZE
- default "0x160"
- ---help---
- Specify the size of the GX framebuffer. Normally, you will
- want this to be MB aligned. Common values are 0x8 (8MB)
- and 0x160 (16MB). Don't change this unless you know what
- you are doing
-
config FB_GEODE_GX1
tristate "AMD Geode GX1 framebuffer support (EXPERIMENTAL)"
depends on FB && FB_GEODE && EXPERIMENTAL
diff --git a/drivers/video/geode/display_gx.c b/drivers/video/geode/display_gx.c
index 0f16e4b..8cd7572 100644
--- a/drivers/video/geode/display_gx.c
+++ b/drivers/video/geode/display_gx.c
@@ -21,12 +21,6 @@
#include "geodefb.h"
#include "display_gx.h"
-#ifdef CONFIG_FB_GEODE_GX_SET_FBSIZE
-unsigned int gx_frame_buffer_size(void)
-{
- return CONFIG_FB_GEODE_GX_FBSIZE;
-}
-#else
unsigned int gx_frame_buffer_size(void)
{
unsigned int val;
@@ -41,7 +35,6 @@ unsigned int gx_frame_buffer_size(void)
val = (unsigned int)(inw(0xAC1E)) & 0xFFl;
return (val << 19);
}
-#endif
int gx_line_delta(int xres, int bpp)
{
diff --git a/drivers/video/geode/gxfb_core.c b/drivers/video/geode/gxfb_core.c
index cf841ef..07ff4bc 100644
--- a/drivers/video/geode/gxfb_core.c
+++ b/drivers/video/geode/gxfb_core.c
@@ -36,6 +36,7 @@
#include "video_gx.h"
static char *mode_option;
+static int fbsize;
/* Modes relevant to the GX (taken from modedb.c) */
static const struct fb_videomode gx_modedb[] __initdata = {
@@ -207,7 +208,6 @@ static int gxfb_blank(int blank_mode, struct fb_info *info)
static int __init gxfb_map_video_memory(struct fb_info *info, struct pci_dev
*dev)
{
struct geodefb_par *par = info->par;
- int fb_len;
int ret;
ret = pci_enable_device(dev);
@@ -232,21 +232,20 @@ static int __init gxfb_map_video_memory(struct fb_info
*info, struct pci_dev *de
ret = pci_request_region(dev, 0, "gxfb (framebuffer)");
if (ret < 0)
return ret;
- if ((fb_len = gx_frame_buffer_size()) < 0)
- return -ENOMEM;
+
info->fix.smem_start = pci_resource_start(dev, 0);
- info->fix.smem_len = fb_len;
+ info->fix.smem_len = fbsize ? fbsize : gx_frame_buffer_size();
info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
if (!info->screen_base)
return -ENOMEM;
- /* Set the 16MB aligned base address of the graphics memory region
+ /* Set the 16MiB aligned base address of the graphics memory region
* in the display controller */
writel(info->fix.smem_start & 0xFF00,
par->dc_regs + DC_GLIU0_MEM_OFFSET);
- dev_info(>dev, "%d Kibyte of video memory at 0x%lx\n",
+ dev_info(>dev, "%d KiB of video memory at 0x%lx\n",
info->fix.smem_len / 1024, info->fix.smem_start);
return 0;
@@ -425,7 +424,10 @@ static int __init gxfb_setup(char *options)
if (!*opt)
continue;
- mode_option = opt;
+ if (!strncmp(opt, "fbsize:", 7))
+ fbsize = simple_strtoul(opt+7, NULL, 0);
+ else
+ mode_option = opt;
}
return 0;
@@ -456,5 +458,8 @@ module_exit(gxfb_cleanup);
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, "video mode (x[-][@])");
+module_param(fbsize, int, 0);
+MODULE_PARM_DESC(fbsize, "video memory size");
+
MODULE_DESCRIPTION("Framebuffer driver for the AMD Geode GX");
MODULE_LICENSE("GPL");
--
1.5.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Re: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008, Alexey Zaytsev wrote: > Well, it looks like Michael is not the bcm43xx maintaner. I sent the > patch to him, > because it was his code that broke the driver, and I thought it would > be easy for him to review my patch, as it touches his code. See? I'm tired of this "how dare can you break my kernel!?" bullshit. That's exactly the reason why I NACKed this patch. I do _not_ understand the KConfig SELECT logic. And I do think almost nobody does understand how that all works together. In the past people came with similiar patches like yours that looked obviously OK. They said sentences like "it is trivial to get the SELECT logics right". But it turned out they were wrong and it introduced other regressions that I was made responsible for. SELECT is _extremely_ difficult to get right, as it completely ignores dependencies. See all this FOOBAR_POSSIBLE select logic that we use in SSB to get SELECT working correctly with dependencies. So my solution for this particular breakage you are seeing here is to wait for the bcm43xx removal, which will happen soon. That will fix it and will have almost zero chance to introduce new bugs. > Well, if you read my first email, that is exactly what I intended to > do, but even if > Michael would be able to fix the b43 driver to work with my hardware, the code > will only show up in 2.6.25, leaving some 2.6.24 users with broken > wifi. So I thought Blah. The people with a bcm4311 revision 1 wireless card plus a bcm44xx ethernet card. You can count those people on two fingers. > it would be a good thing to add my simple fix that enabled the old driver to > the > -stable tree, so that we could have working wifi soon. > > This is still my intension, I'll resend to the proper maintainters. Ok thanks. We'll see if it really was a simple fix then. If it turns out to break something you will get mail. :) You can send this patch to a netdev maintainer or the wireless maintainer. Maybe one of those will sign it off. Good luck. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Saturday 23 February 2008, Gordon Farquharson wrote:
> On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> > > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > >
> > > > Option 1) is the worst of the three as that can cost
> > > > of many hours bug-hunting.
> > > > Option 3) may seem optimal but I do not like to add more
> > > > complexity to this part of the build. And really I do not
> > > > know a reliable way to detech when we do cross builds anyway.
> > > >
> > > > Leaving us with option 2) that is simple, strighforward and harmless.
> > >
> > > Are you willing to sign off on and commit the patch?
> >
> > Only with a big fat comment added that the alignment is only needed
> > because of a broken sanity check in file2alias.c.
>
> How about this?
>
> ---
>
> Align the members of the SSB device structure to a 32 bit boundary so
> that the b43 driver can be built for arm using a cross compiler. This
> change is required so that the test in scripts/mod/file2alias.c that
> checks that the size of the device ID type against the size of the
> section in the object file succeeds (see
> http://lkml.org/lkml/2008/2/18/481 for discussion).
>
> Signed-off-by: Gordon Farquharson <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 139d49d..93083ad 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -351,7 +351,9 @@ struct sdio_device_id {
> struct ssb_device_id {
> __u16 vendor;
> __u16 coreid;
> - __u8revision;
> + /* Explicit padding to support cross-compilation. */
A big fat comment is something like that:
/* Explicit padding to support a broken sanity check in file2alias.c.
* The check will compare the size of the structure in the kernel
* object file to the userspace the kernel is compiled on.
* This breaks on cross-compilation. This padding is a workaround
* for this. */
> + __u8revision
> + __attribute__((aligned(sizeof(__u32;
> };
> #define SSB_DEVICE(_vendor, _coreid, _revision) \
> { .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
>
--
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] [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os
works for me! applied. thanks, -len ps. CONFIG_ACPI_CUSTOM_DSDT's only use is to guard the use of CONFIG_ACPI_CUSTOM_DSDT_FILE: #ifdef CONFIG_ACPI_CUSTOM_DSDT #include CONFIG_ACPI_CUSTOM_DSDT_FILE #endif we could get rid of it if cpp could so something like #if (CONFIG_ACPI_CUSTOM_DSDT_FILE != "") #include CONFIG_ACPI_CUSTOM_DSDT_FILE #endif but it doesn't look like cpp has a concept of strings in expressions. On Friday 22 February 2008 14:25, Randy Dunlap wrote: > Let's see what the ACPI people think about this change. > > Thanks, Sam. > --- > From: Randy Dunlap <[EMAIL PROTECTED]> > > Make ACPI_CUSTOM_DSDT boolean config symbol a hidden and derived > value, based on the value of ACPI_CUSTOM_DSDT_FILE (string). > Only the latter is presented to the user as a config option. > > This fixes problems with "make randconfig" setting ACPI_CUSTOM_DSDT > but leaving ACPI_CUSTOM_DSDT_FILE empty/blank. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > drivers/acpi/Kconfig | 19 +-- > 1 file changed, 9 insertions(+), 10 deletions(-) > > --- linux-2.6.25-rc2-git5.orig/drivers/acpi/Kconfig > +++ linux-2.6.25-rc2-git5/drivers/acpi/Kconfig > @@ -283,24 +283,23 @@ config ACPI_TOSHIBA > If you have a legacy free Toshiba laptop (such as the Libretto L1 > series), say Y. > > -config ACPI_CUSTOM_DSDT > - bool "Include Custom DSDT" > +config ACPI_CUSTOM_DSDT_FILE > + string "Custom DSDT Table file to include" > + default "" > depends on !STANDALONE > - default n > help > This option supports a custom DSDT by linking it into the kernel. > See Documentation/acpi/dsdt-override.txt > > - If unsure, say N. > - > -config ACPI_CUSTOM_DSDT_FILE > - string "Custom DSDT Table file to include" > - depends on ACPI_CUSTOM_DSDT > - default "" > - help > Enter the full path name to the file which includes the AmlCode > declaration. > > + If unsure, don't enter a file name. > + > +config ACPI_CUSTOM_DSDT > + bool > + default ACPI_CUSTOM_DSDT_FILE != "" > + > config ACPI_CUSTOM_DSDT_INITRD > bool "Read Custom DSDT from initramfs" > depends on BLK_DEV_INITRD > -- > 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/ > -- 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: Question about your git habits
Daniel Barkalow wrote: I find that the sequence of changes I make is pretty much unrelated to the sequence of changes that end up in the project's history, because my changes as I make them involve writing a lot of stubs (so I can build) and then filling them out. It's beneficial to have version control on this so that, if I screw up filling out a stub, I can get back to where I was. Having made a complete series, I then generate a new series of commits, each of which does one thing, without any bugs that I've resolved, such that the net result is the end of the messy history, except with any debugging or useless stuff skipped. It's this series that gets merged into the project history, and I discard the other history. The real trick is that the early patches in a lot of series often refactor existing code in ways that are generally good and necessary for your eventual outcome, but which you'd never think of until you've written more of the series. That summarizes well how I do original development, too. Whether its a branch of an existing repo, or a newly cloned repo, when working on new code I will do a first pass, committing as I go to provide useful checkpoints. Once I reach a satisfactory state, I'll refactor the patches so that they make sense for upstream submission. Jeff -- 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: Question about your git habits
On 23-02-08 01:37, Chase Venters wrote: Or perhaps you create a temporary topical branch for each thing you are working on, and commit arbitrary changes then checkout another branch when you need to change gears, finally --squashing the intermediate commits when a particular piece of work is done? No very specific advice to give but this is what I do and then pull all (compilable) topic branches into a "local" branch for complation. Just wanted to remark that a definite downside is that switching branches a lot also touches the tree a lot and hence tends to trigger quite unwelcome amounts of recompiles. Using ccache would proably be effective in this situation but I keep neglecting to check it out... Rene -- 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: [Bug 10030] Suspend doesn't work when SD card is inserted
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote: > Unfortunately, I missed your Bugzilla comment at > http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28 Strange... But obviously you did see it eventually. > Well, in the face of it, I'm considering to remove the code that > acquires device semaphores from the suspend core for now. Evidently, this > change turns out to be painfully premature. I wonder if that's really the best thing. How would we then learn about drivers trying to register or unregister a device during a sleep transition? Do you think it might be possible instead to somehow allow these unregistrations to go through, while still failing or blocking registrations? It shouldn't be too hard to modify the driver core so that it calls the driver's remove() method without trying to acquire dev->sem if your in_suspend_context() test succeeds. I have to admit, I still don't understand what's going on with the MMC driver. Why is there a workqueue involved? If the workqueue fails to unregister the device, why should it bother the suspend routine? After all, if the suspend routine can afford to wait for the workqueue to finish then it could just as well afford to do the unregistration itself. > Also, we have apparent problems with pm_sleep_lock() > being take in device_add() (see > http://bugzilla.kernel.org/show_bug.cgi?id=9874). We'll have to get more information from the bug reporter to figure out what really happened there. Ultimately it may turn out some drivers just aren't very careful about when they try to register new devices. Doing the registration by way of a workqueue can be problematic if the workqueue happens to run during a system sleep transition. That will still be true if you revert the acquire-all-semaphores patch. Alan Stern -- 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: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)
On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Sat, 23 Feb 2008, Rafael J. Wysocki wrote: > > OK, please have a look at the modified patch below. > > All right, I'm fine with it. Now we just need to confirm that it works for > people.. Looks good. Applied Rafael patch on top of your latest git tree that has Jesse's i915 fix. No green screen. Tested with STD (platform), STR, and plain echo mem > /sys/power/state. Thanks, Jeff. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> >
> > > Option 1) is the worst of the three as that can cost
> > > of many hours bug-hunting.
> > > Option 3) may seem optimal but I do not like to add more
> > > complexity to this part of the build. And really I do not
> > > know a reliable way to detech when we do cross builds anyway.
> > >
> > > Leaving us with option 2) that is simple, strighforward and harmless.
> >
> > Are you willing to sign off on and commit the patch?
>
> Only with a big fat comment added that the alignment is only needed
> because of a broken sanity check in file2alias.c.
How about this?
---
Align the members of the SSB device structure to a 32 bit boundary so
that the b43 driver can be built for arm using a cross compiler. This
change is required so that the test in scripts/mod/file2alias.c that
checks that the size of the device ID type against the size of the
section in the object file succeeds (see
http://lkml.org/lkml/2008/2/18/481 for discussion).
Signed-off-by: Gordon Farquharson <[EMAIL PROTECTED]>
---
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 139d49d..93083ad 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -351,7 +351,9 @@ struct sdio_device_id {
struct ssb_device_id {
__u16 vendor;
__u16 coreid;
- __u8revision;
+ /* Explicit padding to support cross-compilation. */
+ __u8revision
+ __attribute__((aligned(sizeof(__u32;
};
#define SSB_DEVICE(_vendor, _coreid, _revision) \
{ .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
--
Gordon Farquharson
GnuPG Key ID: 32D6D676
--
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 33/38] SCSI: gdth: scan for scsi devices
On Sat, 2008-02-23 at 05:02 +0200, Boaz Harrosh wrote: > On Sat, Feb 23, 2008 at 2:31 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > 2.6.24-stable review patch. If anyone has any objections, please let us > > know. > > > > -- > > From: Boaz Harrosh <[EMAIL PROTECTED]> > > > > commit: 61c92814dc324b541391757062ff02fbf3b08086 > > > > The patch: "gdth: switch to modern scsi host registration" > > > > missed one simple fact when moving a way from scsi_module.c. > > That is to call scsi_scan_host() on the probed host. > > With this the gdth driver from 2.6.24 is again able to > > see drives and boot. > > > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> > > Tested-by: Joerg Dorchain <[EMAIL PROTECTED]> > > Tested-by: Stefan Priebe <[EMAIL PROTECTED]> > > Tested-by: Jon Chelton <[EMAIL PROTECTED]> > > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > > --- > > drivers/scsi/gdth.c |9 + > > 1 file changed, 9 insertions(+) > > > > --- a/drivers/scsi/gdth.c > > +++ b/drivers/scsi/gdth.c > > @@ -4838,6 +4838,9 @@ static int __init gdth_isa_probe_one(ulo > > if (error) > > goto out_free_coal_stat; > > list_add_tail(>list, _instances); > > + > > + scsi_scan_host(shp); > > + > > return 0; > > > > out_free_coal_stat: > > @@ -4965,6 +4968,9 @@ static int __init gdth_eisa_probe_one(us > > if (error) > > goto out_free_coal_stat; > > list_add_tail(>list, _instances); > > + > > + scsi_scan_host(shp); > > + > > return 0; > > > > out_free_ccb_phys: > > @@ -5102,6 +5108,9 @@ static int __init gdth_pci_probe_one(gdt > > if (error) > > goto out_free_coal_stat; > > list_add_tail(>list, _instances); > > + > > + scsi_scan_host(shp); > > + > > return 0; > > > > out_free_coal_stat: > > > > -- > > Greg, James Hi > > This patch is not enough, and will not return a gdth system to working > order. With this patch disks > will show up again, only to crash later. All the 5 patches I sent are > needed, to return to a working > state. James please apply to mainline, so they can be accepted into stable. > of the 5 only 2 I have seen in mainline. 3 are missing. > (if they were submitted, I might have missed them, as I'm traveling, then > sorry) OK, If I look at mainline plust rc fixes, there are three patches, two of which were confirmed by testers, and one of which is obvious. Could you send the missing two to linux-scsi with a Tested-by tag? Thanks, James -- 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: Question about your git habits
On Fri, 22 Feb 2008, Chase Venters wrote: > I've been making myself more familiar with git lately and I'm curious what > habits others have adopted. (I know there are a few documents in circulation > that deal with using git to work on the kernel but I don't think this has > been specifically covered). > > My question is: If you're working on multiple things at once, do you tend to > clone the entire repository repeatedly into a series of separate working > directories and do your work there, then pull that work (possibly comprising > a series of "temporary" commits) back into a separate local master > respository with --squash, either into "master" or into a branch containing > the new feature? > > Or perhaps you create a temporary topical branch for each thing you are > working on, and commit arbitrary changes then checkout another branch when > you need to change gears, finally --squashing the intermediate commits when a > particular piece of work is done? I find that the sequence of changes I make is pretty much unrelated to the sequence of changes that end up in the project's history, because my changes as I make them involve writing a lot of stubs (so I can build) and then filling them out. It's beneficial to have version control on this so that, if I screw up filling out a stub, I can get back to where I was. Having made a complete series, I then generate a new series of commits, each of which does one thing, without any bugs that I've resolved, such that the net result is the end of the messy history, except with any debugging or useless stuff skipped. It's this series that gets merged into the project history, and I discard the other history. The real trick is that the early patches in a lot of series often refactor existing code in ways that are generally good and necessary for your eventual outcome, but which you'd never think of until you've written more of the series. Generating a new commit sequence is necessary to end up with a history where it looks from the start like you know where you're going and have everything done that needs to be done when you get to the point of needing it. Furthermore, you want to be able to test these commits in isolation, without the distraction of the changes that actually prompted them, which means that you want to have your working tree is a state that you never actually had it in as you were developing the end result. This means that you'll usually want to rewrite commits for any series that isn't a single obvious patch, so it's not a big deal to commit any time you want to work on some different branch. -Daniel *This .sig left intentionally blank* -- 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: [stable] [patch 34/38] kbuild: allow -fstack-protector to take effect
On Sat, Feb 23, 2008 at 04:41:15AM +0100, Sam Ravnborg wrote: > On Fri, Feb 22, 2008 at 04:53:49PM -0800, Greg KH wrote: > > On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote: > > > On Fri, 22 Feb 2008 16:31:33 -0800 > > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > 2.6.24-stable review patch. If anyone has any objections, please let > > > > us know. > > > > > > > > > not ready for -stable yet. if ever for backporting (doubtful) > > > > Ok, dropped from -stable, thanks. > > For the record I agree with Arjan that it is not yet -stable ready. Ok. Then who sent this to the stable alias in the first place? Sam, you added the "cc: [EMAIL PROTECTED]" to the patch, and that caused it to be sent to us when it went into Linus's tree. If you don't want things like this to go into the -stable tree, don't mark it as such :) thanks, greg k-h -- 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: [stable] [patch 33/38] SCSI: gdth: scan for scsi devices
On Sat, Feb 23, 2008 at 05:02:40AM +0200, Boaz Harrosh wrote: > On Sat, Feb 23, 2008 at 2:31 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > 2.6.24-stable review patch. If anyone has any objections, please let us > > know. > > > > -- > > From: Boaz Harrosh <[EMAIL PROTECTED]> > > > > commit: 61c92814dc324b541391757062ff02fbf3b08086 > > > > The patch: "gdth: switch to modern scsi host registration" > > > > missed one simple fact when moving a way from scsi_module.c. > > That is to call scsi_scan_host() on the probed host. > > With this the gdth driver from 2.6.24 is again able to > > see drives and boot. > > > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> > > Tested-by: Joerg Dorchain <[EMAIL PROTECTED]> > > Tested-by: Stefan Priebe <[EMAIL PROTECTED]> > > Tested-by: Jon Chelton <[EMAIL PROTECTED]> > > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > > --- > > drivers/scsi/gdth.c |9 + > > 1 file changed, 9 insertions(+) > > > > --- a/drivers/scsi/gdth.c > > +++ b/drivers/scsi/gdth.c > > @@ -4838,6 +4838,9 @@ static int __init gdth_isa_probe_one(ulo > > if (error) > > goto out_free_coal_stat; > > list_add_tail(>list, _instances); > > + > > + scsi_scan_host(shp); > > + > > return 0; > > > > out_free_coal_stat: > > @@ -4965,6 +4968,9 @@ static int __init gdth_eisa_probe_one(us > > if (error) > > goto out_free_coal_stat; > > list_add_tail(>list, _instances); > > + > > + scsi_scan_host(shp); > > + > > return 0; > > > > out_free_ccb_phys: > > @@ -5102,6 +5108,9 @@ static int __init gdth_pci_probe_one(gdt > > if (error) > > goto out_free_coal_stat; > > list_add_tail(>list, _instances); > > + > > + scsi_scan_host(shp); > > + > > return 0; > > > > out_free_coal_stat: > > > > -- > > Greg, James Hi > > This patch is not enough, and will not return a gdth system to working > order. With this patch disks > will show up again, only to crash later. All the 5 patches I sent are > needed, to return to a working > state. James please apply to mainline, so they can be accepted into stable. > of the 5 only 2 I have seen in mainline. 3 are missing. > (if they were submitted, I might have missed them, as I'm traveling, then > sorry) Ok, I'll take this for now, and let James send me any further ones he deems necessary. thanks, greg k-h -- 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.25-rc2 3/9] Kconfig: Improve init/Kconfig help descriptions - NAMESPACES
Quoting Nick Andrew ([EMAIL PROTECTED]): > On Fri, Feb 22, 2008 at 04:14:12PM -0600, Serge E. Hallyn wrote: > > Quoting Nick Andrew ([EMAIL PROTECTED]): > > > config UTS_NS > > > bool "UTS namespace" > > > depends on NAMESPACES > > > help > > > - In this namespace tasks see different info provided with the > > > - uname() system call > > > + Enable support for multiple UTS system attributes. > > > + > > > + Each UTS namespace provides an individual view of the > > > + information returned by the uname() system call including > > > + hostname, kernel version and domain name. > > > + > > > + This is used by container systems (e.g. vservers) so that > > > + each container has its own hostname and other attributes. > > > + Tasks in the container are placed in the UTS namespace > > > + corresponding to the container. > > > > this paragraph reads a little weird... really what happens is that > > each forked task is in the same UTS namespace as its parent, unless > > it was cloned with CLONE_NEWUTS or has done unshare(CLONE_NEWUTS), > > in which case it receives a copy. > > You mean only the third paragraph, right? I hope the other two are > accurate. > > I'm trying to describe how the feature is used by container systems > and my description is obviously inaccurate. There are subtle semantic > differences between the way the different namespaces work, which you've > pointed out. I think mentioning CLONE_NEWUTS or other flags is too > technical for help descriptions. > > For UTS_NS and IPC_NS I think I could remove that paragraph because > the end user hint "Answer Y if you will be using a container system" > remains. For USER_NS and PID_NS however, these features are tagged > EXPERIMENTAL so the hint is "If unsure, say N" and I think I need > to at least mention the use in container systems or find some better > clarifying description which doesn't get too technical. > > > > + This is used by container systems (e.g. vservers). > > > + Tasks in the container are placed in the IPC namespace > > > + corresponding to the container. > > > > Same as with UTS, except that upon CLONE_NEWIPC the task receives a > > blank new ipc namespace, not a copy of the original. > > Per above my response is to remove the paragraph. > > > > config PID_NS > > > [...] > > > default n > > > depends on NAMESPACES && EXPERIMENTAL > > > help > > > - Suport process id namespaces. This allows having multiple > > > - process with the same pid as long as they are in different > > > - pid namespaces. This is a building block of containers. > > > + Enable experimental support for hierarchical process id namespaces. > > > > > > - Unless you want to work with an experimental feature > > > - say N here. > > > + This is a function used by container-based virtualisation > > > + systems (e.g. vservers). Each process will have a distinct > > > + Process ID in each PID namespace which the process is in. > > > + Processes in the container are placed in the PID namespace > > > + corresponding to the container, and cannot see or affect > > > + processes in any parent PID namespace. > > > > A cloned process inherits the pid namespace hierarchy from its > > parent. If it was cloned with CLONE_NEWPID, the hierarchy is > > topped with one additional newly created pid namespace. This > > is the only pid namespace in which the new process will be able > > to see processes, while it will be visible in all namespaces in > > its pidns hierarchy. > > Yes, I understand that. Would you agree that your problem is with the > wording "Processes in the container are placed in the PID namespace > corresponding to the container"? And that this is the part that needs > to be fixed? Yup. thanks, -serge > ... todo = revisit these descriptions soon, not today though > > Nick. > -- > PGP Key ID = 0x418487E7 http://www.nick-andrew.net/ > PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7 -- 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 34/38] kbuild: allow -fstack-protector to take effect
On Fri, Feb 22, 2008 at 04:53:49PM -0800, Greg KH wrote: > On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote: > > On Fri, 22 Feb 2008 16:31:33 -0800 > > Greg KH <[EMAIL PROTECTED]> wrote: > > > > > 2.6.24-stable review patch. If anyone has any objections, please let > > > us know. > > > > > > not ready for -stable yet. if ever for backporting (doubtful) > > Ok, dropped from -stable, thanks. For the record I agree with Arjan that it is not yet -stable ready. Sam -- 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: [RFC] [PATCH] x86: Use ELF section to list CPU vendor specific code (Linux Tiny)
Matt Mackall wrote:
This is not quite what Peter and I were thinking of, I think. It's not
at all generic. How about a section that simply contains a set of
function pointers, a macro to add things to that section, and a function
that calls all the pointers in that section. Eg:
CALLBACK_SECTION(init_cpu_amd, "cpuvendor.init");
invoke_callback_section("cpuvendor.init");
..which would give us a generic facility we could use in various places.
Indeed, we already have enough instances of this kind of stuff.
-hpa
--
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: build #373 issue for v2.6.25-rc2-477-g1a4c6be in ./crypto/authenc.c
On Fri, Feb 22, 2008 at 12:23:15PM +, Toralf Förster wrote:
> Hello,
>
> the build with the attached .config failed, make ends with:
> ...
> CC arch/x86/lib/strstr_32.o
> CC arch/x86/lib/usercopy_32.o
> AR arch/x86/lib/lib.a
> LD vmlinux.o
> MODPOST vmlinux.o
> WARNING: modpost: Found 15 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> crypto/built-in.o: In function `crypto_authenc_alloc':
> authenc.c:(.text+0x10f4f): undefined reference to `crypto_grab_skcipher'
> make: *** [.tmp_vmlinux1] Error 1
This patch should fix the problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 898acc5..69f1be6 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -575,6 +575,7 @@ config CRYPTO_TEST
config CRYPTO_AUTHENC
tristate "Authenc support"
select CRYPTO_AEAD
+ select CRYPTO_BLKCIPHER
select CRYPTO_MANAGER
select CRYPTO_HASH
help
--
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 33/38] SCSI: gdth: scan for scsi devices
On Sat, Feb 23, 2008 at 2:31 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > 2.6.24-stable review patch. If anyone has any objections, please let us > know. > > -- > From: Boaz Harrosh <[EMAIL PROTECTED]> > > commit: 61c92814dc324b541391757062ff02fbf3b08086 > > The patch: "gdth: switch to modern scsi host registration" > > missed one simple fact when moving a way from scsi_module.c. > That is to call scsi_scan_host() on the probed host. > With this the gdth driver from 2.6.24 is again able to > see drives and boot. > > Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> > Tested-by: Joerg Dorchain <[EMAIL PROTECTED]> > Tested-by: Stefan Priebe <[EMAIL PROTECTED]> > Tested-by: Jon Chelton <[EMAIL PROTECTED]> > Signed-off-by: James Bottomley <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- > drivers/scsi/gdth.c |9 + > 1 file changed, 9 insertions(+) > > --- a/drivers/scsi/gdth.c > +++ b/drivers/scsi/gdth.c > @@ -4838,6 +4838,9 @@ static int __init gdth_isa_probe_one(ulo > if (error) > goto out_free_coal_stat; > list_add_tail(>list, _instances); > + > + scsi_scan_host(shp); > + > return 0; > > out_free_coal_stat: > @@ -4965,6 +4968,9 @@ static int __init gdth_eisa_probe_one(us > if (error) > goto out_free_coal_stat; > list_add_tail(>list, _instances); > + > + scsi_scan_host(shp); > + > return 0; > > out_free_ccb_phys: > @@ -5102,6 +5108,9 @@ static int __init gdth_pci_probe_one(gdt > if (error) > goto out_free_coal_stat; > list_add_tail(>list, _instances); > + > + scsi_scan_host(shp); > + > return 0; > > out_free_coal_stat: > > -- Greg, James Hi This patch is not enough, and will not return a gdth system to working order. With this patch disks will show up again, only to crash later. All the 5 patches I sent are needed, to return to a working state. James please apply to mainline, so they can be accepted into stable. of the 5 only 2 I have seen in mainline. 3 are missing. (if they were submitted, I might have missed them, as I'm traveling, then sorry) Boaz -- 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] atmel_spi: support zero length transfer
> > > David, do you think writing 0 bytes is a valid use of this API? > > > > Just a zero byte transfer ... no, though it depends what you mean > > by "valid". (I'm not sure I'd expect all controller drivers to > > reject such requests.) That has no effect on bits-on-the-wire, > > and would make trouble for various DMA engines. > > So, the behaviour is undefined, something between 'crash my dma engine', > 'assert chip select and wait some time', or 'do_nothing'... No, it's fully defined. "Crash my engine" is not OK. The delay is controlled by transfer.delay_usecs ... possibly zero, which is best viewed as a degenerate case. > Is this kind of device so common that we need to do all that work? or can we > leave it as is (verified to work only with atmel_spi)? You can't avoid testing each combination of SPI protocol driver and SPI master controller driver you rely on ... especially when protocol tweaking options (cs_change, delay_usecs, bits_per_word, etc) are used at the per-transfer level. This driver stack isn't as readily tested as, say, USB. However, protocol drivers should be able to rely on controller drivers to reject requests that they don't even try to handle; that's basic. - Dave -- 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] Add SDIO 'type' parameter to sysfs
Hi Andy, Add 'type' attribute of the SDIO device to represent Standard Function interface code in the human readable form. these kind of things should not be part of the Linux kernel. A userspace tool (call it lssdio if you want) should handle it. Regards Marcel -- 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: [RFC] [PATCH] x86: Use ELF section to list CPU vendor specific code (Linux Tiny)
On Fri, 2008-02-15 at 12:00 +0100, Thomas Petazzoni wrote:
> Hi,
>
> Le Mon, 11 Feb 2008 16:54:30 -0800,
> "H. Peter Anvin" <[EMAIL PROTECTED]> a écrit :
>
> > b) would be my first choice, and yes, it would be a good thing to
> > have a generalized mechanism for this. For the registrant, it's
> > pretty easy: just add a macro that adds a pointer to a named
> > section. We then need a way to get the base address and length of
> > each such section in order to be able to execute each function in
> > sequence.
>
> You'll find below a tentative patch that implements this. Tuple
> (vendor, pointer to cpu_dev structure) are stored in a
> x86cpuvendor.init section of the kernel, which is then read by the
> generic CPU code in arch/x86/kernel/cpu/common.c to fill the cpu_devs[]
> function.
This is not quite what Peter and I were thinking of, I think. It's not
at all generic. How about a section that simply contains a set of
function pointers, a macro to add things to that section, and a function
that calls all the pointers in that section. Eg:
CALLBACK_SECTION(init_cpu_amd, "cpuvendor.init");
invoke_callback_section("cpuvendor.init");
..which would give us a generic facility we could use in various places.
--
Mathematics is the supreme nostalgia of our time.
--
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: [spi-devel-general] [PATCH] atmel_spi: support zero length transfer
On Friday 22 February 2008, Ned Forrester wrote: > > So, what I think you said is that it would be better for pxa2xx_spi to > silently ignore a zero-length message, passing it back with the rest of > the message when all is complete, than to reject the message. Yes. Remember that the reason to _use_ such a message is to get the inline delay ... and that if you've got code to handle that case (transfer.len == 0 && transfer.delay_usecs != 0) it's almost trivial to support the degenerate "delay_usecs == 0" case too. > I see no > reason why that could not be done, though it may be tricky to set other > things like SSP modes and chip select and *not* start the DMA. It would > have to be tested, so I'm not sure when I could try that. Normally I'd expect it's little more than a "goto", but the pxa2xx_spi structure is relatively complex. > >> I agree with Marc: any such delay will be undefined, in the general > >> case. It might work for a specific driver implementation. > > > > Is that what Marc said? I couldn't tell. In any case, I disagree; > > the semantics of that delay are clearly define. > > Maybe I am missing something. Aren't we talking about a transfer in a > message, with or without other transfers, who's only unique > characteristic is that that its length is zero? There were two cases ... delay_usecs being zero, or not. In either case, the semantics are the same: after the transfer (len == 0), delay that many microseconds (zero or more). > Or are you and Atsushi talking about using spi_transfer.delay_usecs > *with* a zero length transfer to effectively put a delay between the > assertion of CS and the start of the first clock? If so, then I guess I > missed the original point. Sorry. As I noted, there are two cases. The reason to use a zero length transfer is to get a delay ... in his case, specifically before the first clock, but in general *anywhere* in the transfer. But the degenerate case is "delay for zero microseconds". > -- > > By the way, reading spi.h again, it looks like spi_transfer.delay_usecs > is supposed to be implemented between the last bit movement of a > transfer and any change of CS at the end of a transfer. Is that right? Yes. > I think that pxa2xx_spi is dropping CS, if requested, immediately at > the end of transfer, and then putting spi_transfer.delay_usecs between > that transfer and the next. That's a bug then; it will matter with some drivers. > >> If it were necessary to scan a > >> whole message for zero-length transfers and refuse to queue an offending > >> message, then that adds burden to all messages. > > > > Sanity checking messages as they're submitted is easy; and it's > > also the natural point for setting up DMA mappings (and making > > those cachelines available for better use). > > Hmmm Obviously I have much to learn about modern computers. It had > not occurred to me, even after reading "Linux Device Drivers", Corbet, > et.al, that by DMA mapping, one frees the cache for other uses. It > makes sense. That's certainly what happens on systems where the buffer is from "normal" memory and the cache is DMA-incoherent ... like most ARMs, and probably the majority of non-x86 hardware. Think of that as being a level or two deeper than what LDD covers. > In my application I pass many large buffers to the master > driver, and I map them in the protocol driver. I did that without good > reason, but now I see it was the proper choice. > > Unfortunately, pxa2xx_spi does any DMA mapping not done by the protocol > driver in pump_transfers, as each transfer is submitted to the hardware. That's not wrong ... but it's sub-optimal: those cache lines could have been doing better things all that time, and cleaning them out in the middle of a transfer will slow it down by some amount. > There is not currently any message checking done in transfer(), the > only error return from that is if the master driver is shutdown (queue > stopped). The current scheme is to return the message with non-zero > spi_message.status if it has failed *after* execution has been > attempted. Again ... not wrong, but sub-optimal: when it happens (which won't be common, fortunately!) the SPI slave will be left in a rude state. And the protocol driver may not know how to recover. > I don't look forward to making major changes, if we really > want all DMA mapping and error checking to be in transfer(), though I > see no reason why it could not be done. There's no rush on cleanups like that. They'd be reasonable tasks for someone with some time to spare, who wanted to get their feet wet in some driver updates and who could set up some kind of test rig. (Like one with a programmable slave that could be made to do all sorts of stuff that might otherwise be a bit uncommon. A microcontroller slave would be easy ... programming a CPLD or FPGA would be much trickier!) - Dave -- To unsubscribe from this list: send the line "unsubscribe
Re: Question about your git habits
On 2008/2/23, Al Viro <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote: > > Al Viro <[EMAIL PROTECTED]> writes: > > > > > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote: > > > > > >> >do you tend to clone the entire repository repeatedly into a series > > >> >of separate working directories > > >> > > >> Too time consuming on consumer drives with projects the size of Linux. > > > > > > git clone -l -s > > > > > > is not particulary slow... > > > > How big is a checkout of a single revision of kernel these days, > > compared to a well-packed history since v2.6.12-rc2? > > > > The cost of writing out the work tree files isn't ignorable and > > probably more than writing out the repository data (which -s > > saves for you). > > > Depends... I'm using ext2 for that and noatime everywhere, so that might > change the picture, but IME it's fast enough... As for the size, it gets > to ~320Mb on disk, which is comparable to the pack size (~240-odd Mb). Yesterday, i had git cloned git://foo.com/bar.git ( 777 MiB ) Today, i've git cloned git://foo.com/bar.git ( 779 MiB ) Both repos are different binaries , and i used 777 MiB + 779 MiB = 1556 MiB of bandwidth in two days. It's much! Why don't we implement "binary delta between old git repo and recent git repo" with "SHA1 built git repo verifier"? Suppose the size cost of this binary delta is e.g. around 52 MiB instead of 2 MiB due to numerous mismatching of binary parts, then the bandwidth in two days will be 777 MiB + 52 MiB = 829 MiB instead of 1556 MiB. Unfortunately, this "binary delta of repos" is not implemented yet :| -- 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/
[PATCH spelling] Tighten up the use of loose
'Lose' is when you don't win or you've lost something, and 'loose'
is when something isn't tight. I just want to tighten up the
spelling a bit regarding some loose comments.
Signed-off-by: Nick Andrew <[EMAIL PROTECTED]>
---
Yes, this is a digression.
Documentation/edac.txt |2 +-
Documentation/filesystems/hfs.txt |2 +-
arch/mips/kernel/vpe.c |2 +-
arch/sh/lib64/c-checksum.c |4 ++--
drivers/char/serial167.c|2 +-
drivers/media/dvb/ttpci/av7110.c|2 +-
drivers/message/i2o/i2o_block.c |2 +-
drivers/misc/ibmasm/event.c |2 +-
drivers/net/spider_net.c|2 +-
drivers/serial/mpc52xx_uart.c |4 ++--
drivers/usb/serial/ftdi_sio.c |2 +-
fs/jffs2/fs.c |2 +-
fs/ntfs/aops.c |2 +-
include/linux/securebits.h |2 +-
mm/migrate.c|2 +-
mm/slub.c |4 ++--
net/ieee80211/softmac/ieee80211softmac_module.c |2 +-
net/wireless/wext.c |2 +-
18 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index a5c3684..bad5fef 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -280,7 +280,7 @@ Polling period control file:
The time period, in milliseconds, for polling for error information.
Too small a value wastes resources. Too large a value might delay
- necessary handling of errors and might loose valuable information for
+ necessary handling of errors and might lose valuable information for
locating the error. 1000 milliseconds (once each second) is the current
default. Systems which require all the bandwidth they can get, may
increase this.
diff --git a/Documentation/filesystems/hfs.txt
b/Documentation/filesystems/hfs.txt
index bd0fa77..28f0225 100644
--- a/Documentation/filesystems/hfs.txt
+++ b/Documentation/filesystems/hfs.txt
@@ -61,7 +61,7 @@ the a little strange:
Finder's metadata.
o They are however created (with default values), deleted and renamed
along with the corresponding data fork or directory.
- o Copying files to a different filesystem will loose those attributes
+ o Copying files to a different filesystem will lose those attributes
that are essential for MacOS to work.
diff --git a/arch/mips/kernel/vpe.c b/arch/mips/kernel/vpe.c
index eed2dc4..c6cf1ae 100644
--- a/arch/mips/kernel/vpe.c
+++ b/arch/mips/kernel/vpe.c
@@ -1112,7 +1112,7 @@ static int vpe_release(struct inode *inode, struct file
*filp)
/* It's good to be able to run the SP and if it chokes have a look at
the /dev/rt?. But if we reset the pointer to the shared struct we
- loose what has happened. So perhaps if garbage is sent to the vpe
+ lose what has happened. So perhaps if garbage is sent to the vpe
device, use it as a trigger for the reset. Hopefully a nice
executable will be along shortly. */
if (ret < 0)
diff --git a/arch/sh/lib64/c-checksum.c b/arch/sh/lib64/c-checksum.c
index 5dfbd8b..83d0776 100644
--- a/arch/sh/lib64/c-checksum.c
+++ b/arch/sh/lib64/c-checksum.c
@@ -35,7 +35,7 @@ static inline unsigned short foldto16(unsigned long x)
static inline unsigned short myfoldto16(unsigned long long x)
{
- /* Fold down to 32-bits so we don't loose in the typedef-less
+ /* Fold down to 32-bits so we don't lose in the typedef-less
network stack. */
/* 64 to 33 */
x = (x & 0x) + (x >> 32);
@@ -199,7 +199,7 @@ __wsum csum_tcpudp_nofold(__be32 saddr, __be32 daddr,
result = (__force u64) saddr + (__force u64) daddr +
(__force u64) sum + ((len + proto) << 8);
- /* Fold down to 32-bits so we don't loose in the typedef-less
+ /* Fold down to 32-bits so we don't lose in the typedef-less
network stack. */
/* 64 to 33 */
result = (result & 0x) + (result >> 32);
diff --git a/drivers/char/serial167.c b/drivers/char/serial167.c
index df8cd0c..201eb83 100644
--- a/drivers/char/serial167.c
+++ b/drivers/char/serial167.c
@@ -418,7 +418,7 @@ static irqreturn_t cd2401_rxerr_interrupt(int irq, void
*dev_id)
TTY_OVERRUN);
/*
If the flip buffer itself is
- overflowing, we still loose
+ overflowing, we still lose
the next incoming character.
*/
Re: [RFC][PATCH] make /proc/pid/pagemap work with huge pages and return page size
(sorry for the delay, travelling)
On Wed, 2008-02-20 at 14:57 +0100, Hans Rosenfeld wrote:
> The current code for /proc/pid/pagemap does not work with huge pages (on
> x86). The code will make no difference between a normal pmd and a huge
> page pmd, trying to parse the contents of the huge page as ptes. Another
> problem is that there is no way to get information about the page size a
> specific mapping uses.
>
> Also, the current way the "not present" and "swap" bits are encoded in
> the returned pfn isn't very clean, especially not if this interface is
> going to be extended.
Fair.
> I propose to change /proc/pid/pagemap to return a pseudo-pte instead of
> just a raw pfn. The pseudo-pte will contain:
>
> - 58 bits for the physical address of the first byte in the page, even
> less bits would probably be sufficient for quite a while
>
> - 4 bits for the page size, with 0 meaning native page size (4k on x86,
> 8k on alpha, ...) and values 1-15 being specific to the architecture
> (I used 1 for 2M, 2 for 4M and 3 for 1G for x86)
>
> - a "swap" bit indicating that a not present page is paged out, with the
> physical address field containing page file number and block number
> just like before
>
> - a "present" bit just like in a real pte
This is ok-ish, but I can't say I like it much. Especially the page size
field.
But I don't really have many ideas here. Perhaps having a bit saying
"this entry is really a continuation of the previous one". Then any page
size can be trivially represented. This might also make the code on both
sides simpler?
> By shortening the field for the physical address, some more interesting
> information could be included, like read/write permissions and the like.
> The page size could also be returned directly, 6 bits could be used to
> express any page shift in a 64 bit system, but I found the encoded page
> size more useful for my specific use case.
>
>
> The attached patch changes the /proc/pid/pagemap code to use such a
> pseudo-pte. The huge page handling is currently limited to 2M/4M pages
> on x86, 1G pages will need some more work. To keep the simple mapping of
> virtual addresses to file index intact, any huge page pseudo-pte is
> replicated in the user buffer to map the equivalent range of small
> pages.
>
> Note that I had to move the pmd_pfn() macro from asm-x86/pgtable_64.h to
> asm-x86/pgtable.h, it applies to both 32 bit and 64 bit x86.
>
> Other architectures will probably need other changes to support huge
> pages and return the page size.
>
> I think that the definition of the pseudo-pte structure and the page
> size codes should be made available through a header file, but I didn't
> do this for now.
>
> Signed-Off-By: Hans Rosenfeld <[EMAIL PROTECTED]>
>
> ---
> fs/proc/task_mmu.c | 68 +
> include/asm-x86/pgtable.h|2 +
> include/asm-x86/pgtable_64.h |1 -
> 3 files changed, 50 insertions(+), 21 deletions(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 49958cf..58af588 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -527,16 +527,23 @@ struct pagemapread {
> char __user *out, *end;
> };
>
> -#define PM_ENTRY_BYTES sizeof(u64)
> -#define PM_RESERVED_BITS3
> -#define PM_RESERVED_OFFSET (64 - PM_RESERVED_BITS)
> -#define PM_RESERVED_MASK(((1LL< PM_RESERVED_OFFSET)
> -#define PM_SPECIAL(nr) (((nr) << PM_RESERVED_OFFSET) | PM_RESERVED_MASK)
> -#define PM_NOT_PRESENT PM_SPECIAL(1LL)
> -#define PM_SWAP PM_SPECIAL(2LL)
> -#define PM_END_OF_BUFFER1
> -
> -static int add_to_pagemap(unsigned long addr, u64 pfn,
> +struct ppte {
> + uint64_t paddr:58;
> + uint64_t psize:4;
> + uint64_t swap:1;
> + uint64_t present:1;
> +};
> +
> +#ifdef CONFIG_X86
> +#define PM_PSIZE_1G 3
> +#define PM_PSIZE_4M 2
> +#define PM_PSIZE_2M 1
> +#endif
> +
> +#define PM_ENTRY_BYTES sizeof(struct ppte)
> +#define PM_END_OF_BUFFER 1
> +
> +static int add_to_pagemap(unsigned long addr, struct ppte ppte,
> struct pagemapread *pm)
> {
> /*
> @@ -545,13 +552,13 @@ static int add_to_pagemap(unsigned long addr, u64 pfn,
>* the pfn.
>*/
> if (pm->out + PM_ENTRY_BYTES >= pm->end) {
> - if (copy_to_user(pm->out, , pm->end - pm->out))
> + if (copy_to_user(pm->out, , pm->end - pm->out))
> return -EFAULT;
> pm->out = pm->end;
> return PM_END_OF_BUFFER;
> }
>
> - if (put_user(pfn, pm->out))
> + if (copy_to_user(pm->out, , sizeof(ppte)))
> return -EFAULT;
> pm->out += PM_ENTRY_BYTES;
> return 0;
> @@ -564,7 +571,7 @@ static int pagemap_pte_hole(unsigned long start, unsigned
> long end,
> unsigned long addr;
> int err = 0;
> for (addr = start; addr < end; addr += PAGE_SIZE) {
> - err = add_to_pagemap(addr,
Re: Question about your git habits
On Fri, Feb 22, 2008 at 05:51:04PM -0800, Junio C Hamano wrote: > Al Viro <[EMAIL PROTECTED]> writes: > > > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote: > > > >> >do you tend to clone the entire repository repeatedly into a series > >> >of separate working directories > >> > >> Too time consuming on consumer drives with projects the size of Linux. > > > > git clone -l -s > > > > is not particulary slow... > > How big is a checkout of a single revision of kernel these days, > compared to a well-packed history since v2.6.12-rc2? > > The cost of writing out the work tree files isn't ignorable and > probably more than writing out the repository data (which -s > saves for you). Depends... I'm using ext2 for that and noatime everywhere, so that might change the picture, but IME it's fast enough... As for the size, it gets to ~320Mb on disk, which is comparable to the pack size (~240-odd Mb). -- 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: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote: > > In the revised patch below I redefined the PM_EVENT_* things as flags so > that I can "or" them and defined PM_EVENT_SLEEP in analogy with > CONFIG_PM_SLEEP. Ok, looks fine by me. > > Didn't you miss the apci_pci_choose_state() thing that also needs this > > extension? > > No, I didn't. That one operates on the ACPI D* states. Ok. I consider that just about the worst interface ever, but whatever... > OK, please have a look at the modified patch below. All right, I'm fine with it. Now we just need to confirm that it works for people.. Linus -- 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: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)
On Saturday, 23 of February 2008, Linus Torvalds wrote:
>
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>
> > --- linux-2.6.orig/drivers/char/drm/i915_drv.c
> > +++ linux-2.6/drivers/char/drm/i915_drv.c
> > @@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
> >dev_priv->saveGR[0x18]);
> >
> > /* Attribute controller registers */
> > + inb(st01);
> > for (i = 0; i < 20; i++)
> > i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
> > inb(st01); /* switch back to index mode */
>
> I'm doing this part separately, please drop it - it has nothing to do with
> the rest of the patch.
Dropped.
> I'd also suggest that you just add a helper function like
>
> int pm_event_powerdown(struct pm_message mesg)
> {
> return mesg.event >= PM_EVENT_SUSPEND;
> }
>
> or something, so that you can have code like
>
> if (pm_event_powerdown(mesg))
> pci_set_power_state(pdev, PCI_D3hot);
>
> instead of the test for EVENT_SUSPEND/HIBERNATE explicitly.
In the revised patch below I redefined the PM_EVENT_* things as flags so
that I can "or" them and defined PM_EVENT_SLEEP in analogy with
CONFIG_PM_SLEEP.
> Of course, the places that already do a switch-statement are much better
> kept that way and just add PM_EVENT_HIBERNATE to the list.
>
> > --- linux-2.6.orig/drivers/pci/pci.c
> > +++ linux-2.6/drivers/pci/pci.c
> > @@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
> > case PM_EVENT_PRETHAW:
> > /* REVISIT both freeze and pre-thaw "should" use D0 */
> > case PM_EVENT_SUSPEND:
> > + case PM_EVENT_HIBERNATE:
> > return PCI_D3hot;
>
> Didn't you miss the apci_pci_choose_state() thing that also needs this
> extension?
No, I didn't. That one operates on the ACPI D* states.
> > Index: linux-2.6/drivers/usb/host/u132-hcd.c
> > ===
> > --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> > +++ linux-2.6/drivers/usb/host/u132-hcd.c
> > @@ -3214,14 +3214,18 @@ static int u132_suspend(struct platform_
> > return -ESHUTDOWN;
> > } else {
> > int retval = 0;
> > -if (state.event == PM_EVENT_FREEZE) {
> > +
> > + switch (state.event) {
> > + case PM_EVENT_FREEZE:
> > retval = u132_bus_suspend(hcd);
> > -} else if (state.event == PM_EVENT_SUSPEND) {
> > + break;
> > + case PM_EVENT_SUSPEND:
> > + case PM_EVENT_HIBERNATE:
> > int ports = MAX_U132_PORTS;
> > while (ports-- > 0) {
> > port_power(u132, ports, 0);
> > }
> > -}
> > + break;
> > if (retval == 0)
> > pdev->dev.power.power_state = state;
> > return retval;
>
> Looks like a missing close-brace to me there - you removed the final '}'.
>
> Or am I blind?
No, you aren't. :-)
> Apart from those issues it looks fine to me.
OK, please have a look at the modified patch below.
Thanks,
Rafael
---
Documentation/power/devices.txt| 13 -
drivers/ata/ahci.c |2 +-
drivers/ata/ata_piix.c |2 +-
drivers/ata/libata-core.c |2 +-
drivers/ide/ppc/pmac.c |4 ++--
drivers/macintosh/mediabay.c |3 ++-
drivers/pci/pci.c |1 +
drivers/scsi/aic7xxx/aic79xx_osm_pci.c |2 +-
drivers/scsi/aic7xxx/aic7xxx_osm_pci.c |2 +-
drivers/scsi/mesh.c|1 +
drivers/scsi/sd.c |3 +--
drivers/usb/host/sl811-hcd.c |1 +
drivers/usb/host/u132-hcd.c| 11 ---
drivers/video/chipsfb.c|2 +-
drivers/video/nvidia/nvidia.c |2 +-
include/linux/pm.h |9 -
kernel/power/disk.c|4 ++--
net/rfkill/rfkill.c|2 +-
18 files changed, 42 insertions(+), 24 deletions(-)
Index: linux-2.6/kernel/power/disk.c
===
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -391,7 +391,7 @@ int hibernation_platform_enter(void)
goto Close;
suspend_console();
- error = device_suspend(PMSG_SUSPEND);
+ error = device_suspend(PMSG_HIBERNATE);
if (error)
goto Resume_console;
@@ -404,7 +404,7 @@ int hibernation_platform_enter(void)
goto Finish;
local_irq_disable();
- error = device_power_down(PMSG_SUSPEND);
+ error = device_power_down(PMSG_HIBERNATE);
if (!error) {
hibernation_ops->enter();
/* We should never
Re: Question about your git habits
Al Viro <[EMAIL PROTECTED]> writes: > On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote: > >> >do you tend to clone the entire repository repeatedly into a series >> >of separate working directories >> >> Too time consuming on consumer drives with projects the size of Linux. > > git clone -l -s > > is not particulary slow... How big is a checkout of a single revision of kernel these days, compared to a well-packed history since v2.6.12-rc2? The cost of writing out the work tree files isn't ignorable and probably more than writing out the repository data (which -s saves for you). -- 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: Question about your git habits
On Sat, Feb 23, 2008 at 02:37:00AM +0100, Jan Engelhardt wrote: > >do you tend to clone the entire repository repeatedly into a series > >of separate working directories > > Too time consuming on consumer drives with projects the size of Linux. git clone -l -s is not particulary slow... -- 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: Question about your git habits
On Feb 22 2008 18:37, Chase Venters wrote: > >I've been making myself more familiar with git lately and I'm curious what >habits others have adopted. (I know there are a few documents in circulation >that deal with using git to work on the kernel but I don't think this has >been specifically covered). > >My question is: If you're working on multiple things at once, Impossible; Humans only have one core with only seven registers -- according to CodingStyle chapter 6 paragraph 4. >do you tend to clone the entire repository repeatedly into a series >of separate working directories Too time consuming on consumer drives with projects the size of Linux. >and do your work there, then pull >that work (possibly comprising a series of "temporary" commits) back >into a separate local master respository with --squash, either into >"master" or into a branch containing the new feature? No, just commit the current unfinished work to a new branch and deal with it later (cherry-pick, rebase, reset --soft, commit --amend -i, you name it). Or if all else fails, use git-stash. You do not have to push these temporary branches at all, so it is much nicer than svn. (Once all the work is done and cleanly in master, you can kill off all branches without having a record of their previous existence.) >Or perhaps you create a temporary topical branch for each thing you >are working on, and commit arbitrary changes then checkout another >branch when you need to change gears, finally --squashing the >intermediate commits when a particular piece of work is done? if I don't collect arbitrary changes, I don't need squashing (see reset --soft/amend above) -- 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: Question about your git habits
2008/2/23, Chase Venters <[EMAIL PROTECTED]> wrote: > > ... blablabla > > My question is: If you're working on multiple things at once, do you tend to > clone the entire repository repeatedly into a series of separate working > directories and do your work there, then pull that work (possibly comprising > a series of "temporary" commits) back into a separate local master > respository with --squash, either into "master" or into a branch containing > the new feature? > > ... blablabla > > I'm using git to manage my project and I'm trying to determine the most > optimal workflow I can. I figure that I'm going to have an "official" master > repository for the project, and I want to keep the revision history clean in > that repository (ie, no messy intermediate commits that don't compile or only > implement a feature half way). I recomend you to use these complementary tools 1. google: gitk screenshots ( e.g. http://lwn.net/Articles/140350/ ) 2. google: "git-gui" screenshots ( e.g. http://www.spearce.org/2007/01/git-gui-screenshots.html ) 3. google: gitweb color meld ;) -- 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/
[patch 2.6.25-rc2-git 2/2] atmel_tc clocksource/clockevent code
Clocksource and clockevent device based on the Atmel TC blocks.
The clockevent device handles both periodic and oneshot modes, so this
enables NO_HZ and high res timers on some platforms that previously
couldn't use those mechanisms.
This works on both AVR32 and AT91 chips, given relevant patches for
tclib support (always) and clockevents (or else this will only look
like a higher precision clocksource). It's an updated and modularized
version of an AT91-only patch that has circulated for some time now.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
As with the preceding patch, this depends on platform updates that
won't merge before 2.6.26 ... in this case, updates to switch over
to clocksources (at91sam9 chips, but not at91rm9200) and clockevents
(avr32 and at91sam9), on top of platform_device setup.
drivers/clocksource/Makefile |1
drivers/clocksource/tcb_clksrc.c | 303 +++
drivers/misc/Kconfig | 25 +++
3 files changed, 329 insertions(+)
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ATMEL_TCB_CLKSRC) += tcb_clksrc.o
obj-$(CONFIG_X86_CYCLONE_TIMER)+= cyclone.o
obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
obj-$(CONFIG_SCx200HR_TIMER) += scx200_hrt.o
--- /dev/null
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -0,0 +1,303 @@
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/*
+ * We're configured to use a specific TC block, one that's not hooked
+ * up to external hardware, to provide a time solution:
+ *
+ * - Two channels combine to create a free-running 32 bit counter
+ * with a base rate of 5+ MHz, packaged as a clocksource (with
+ * resolution better than 200 nsec).
+ *
+ * - The third channel may be used to provide a 16-bit clockevent
+ * source, used in either periodic or oneshot mode. This runs
+ * at 32 KiHZ, and can handle delays of up to two seconds.
+ *
+ * A boot clocksource and clockevent source are also currently needed,
+ * unless the relevant platforms (ARM/AT91, AVR32/AT32) are changed so
+ * this code can be used when init_timers() is called, well before most
+ * devices are set up. (Some low end AT91 parts, which can run uClinux,
+ * have only the timers in one TC block... they currently don't support
+ * the tclib code, because of that initialization issue.)
+ *
+ * REVISIT behavior during system suspend states... we should disable
+ * all clocks and save the power. Easily done for clockevent devices,
+ * but clocksources won't necessarily get the needed notifications.
+ * For deeper system sleep states, this will be mandatory...
+ */
+
+static void __iomem *tcaddr;
+
+static cycle_t tc_get_cycles(void)
+{
+ unsigned long flags;
+ u32 lower, upper;
+
+ raw_local_irq_save(flags);
+retry:
+ upper = __raw_readl(tcaddr + ATMEL_TC_REG(1, CV));
+ lower = __raw_readl(tcaddr + ATMEL_TC_REG(0, CV));
+ if (upper != __raw_readl(tcaddr + ATMEL_TC_REG(1, CV)))
+ goto retry;
+
+ raw_local_irq_restore(flags);
+ return (upper << 16) | lower;
+}
+
+static struct clocksource clksrc = {
+ .name = "tcb_clksrc",
+ .rating = 200,
+ .read = tc_get_cycles,
+ .mask = CLOCKSOURCE_MASK(32),
+ .shift = 18,
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS,
+};
+
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
+#define USE_TC_CLKEVT
+#endif
+
+#ifdef CONFIG_ARCH_AT91RM9200
+/* The AT91rm9200 system timer is a oneshot-capable 32k timer that's
+ * always running ... configuring a TC channel to work the same way
+ * would just waste some power.
+ */
+#undef USE_TC_CLKEVT
+#endif
+
+#ifdef USE_TC_CLKEVT
+
+/* For now, we always use the 32K clock ... this optimizes for NO_HZ,
+ * because using one of the divided clocks would usually mean the
+ * tick rate can never be less than several dozen Hz (vs 0.5 Hz).
+ *
+ * A divided clock could be good for high resolution timers, since
+ * 30.5 usec resolution can seem "low".
+ */
+static u32 timer_clock;
+
+static void tc_mode(enum clock_event_mode m, struct clock_event_device *d)
+{
+ __raw_writel(0xff, tcaddr + ATMEL_TC_REG(2, IDR));
+ __raw_writel(ATMEL_TC_CLKDIS, tcaddr + ATMEL_TC_REG(2, CCR));
+
+ switch (m) {
+
+ /* By not making the gentime core emulate periodic mode on top
+* of oneshot, we get lower overhead and improved accuracy.
+*/
+ case CLOCK_EVT_MODE_PERIODIC:
+ /* slow clock, count up to RC, then irq and restart */
+ __raw_writel(timer_clock
+ | ATMEL_TC_WAVE | ATMEL_TC_WAVESEL_UP_AUTO,
+ tcaddr + ATMEL_TC_REG(2, CMR));
+ __raw_writel((32768 + HZ/2) / HZ, tcaddr + ATMEL_TC_REG(2, RC));
+
+ /* Enable clock and interrupts on RC
[patch 2.6.25-rc2-git 1/2] atmel_tc library
Create based on and the
at91sam9263 and at32ap7000 datasheets. Most AT91 and AT32 SOCs have one
or two of these TC blocks, which include three 16-bit timers that can be
interconnected in various ways.
These TC blocks can be used for external interfacing (such as PWM and
measurement), or used as somewhat quirky sixteen-bit timers.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Note that this won't be usable until the AT91 and AT32 platforms
incorporate patches to configure the relevant platform devices.
Those changes are probably 2.6.26 material.
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1
drivers/misc/atmel_tclib.c | 107 +
include/linux/atmel_tc.h | 221 +
4 files changed, 337 insertions(+)
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -22,6 +22,14 @@ config ATMEL_PWM
purposes including software controlled power-efficent backlights
on LCD displays, motor control, and waveform generation.
+config ATMEL_TCLIB
+ bool "Atmel AT32/AT91 Timer/Counter Library"
+ depends on (AVR32 || ARCH_AT91)
+ help
+ Select this if you want a library to allocate the Timer/Counter
+ blocks found on many Atmel processors. This facilitates using
+ these blocks by different drivers despite processor differences.
+
config IBM_ASM
tristate "Device driver for IBM RSA service processor"
depends on X86 && PCI && INPUT && EXPERIMENTAL
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_ACER_WMI) += acer-wmi.o
obj-$(CONFIG_ASUS_LAPTOP) += asus-laptop.o
obj-$(CONFIG_ATMEL_PWM)+= atmel_pwm.o
obj-$(CONFIG_ATMEL_SSC)+= atmel-ssc.o
+obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_TC1100_WMI) += tc1100-wmi.o
obj-$(CONFIG_LKDTM)+= lkdtm.o
obj-$(CONFIG_TIFM_CORE)+= tifm_core.o
--- /dev/null
+++ b/drivers/misc/atmel_tclib.c
@@ -0,0 +1,107 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/*
+ * This is a thin library to solve the problem of how to portably allocate
+ * one of the TC blocks. For simplicity, it doesn't currently expect to
+ * share individual timers between different drivers.
+ */
+
+#if defined(CONFIG_AVR32)
+/* AVR32 has these divide PBB */
+const u8 atmel_tc_divisors[5] = { 0, 4, 8, 16, 32, };
+EXPORT_SYMBOL(atmel_tc_divisors);
+
+#elif defined(CONFIG_ARCH_AT91)
+/* AT91 has these divide MCK */
+const u8 atmel_tc_divisors[5] = { 2, 8, 32, 128, 0, };
+EXPORT_SYMBOL(atmel_tc_divisors);
+
+#endif
+
+/* we "know" that there will be either one or two TC blocks */
+static struct platform_device *blocks[2];
+
+
+/**
+ * atmel_tc_alloc - allocate a specified TC block
+ * @block: which block to allocate
+ * @iomem: used to return its IO memory resource
+ *
+ * Caller allocates a block. If it is available, its I/O space is requested
+ * and returned through the iomem pointer, and the device node for the block
+ * is returned. When it is not available, NULL is returned.
+ *
+ * On some platforms, each TC channel has its own clocks and IRQs. Drivers
+ * should clk_get() and clk_enable() "t0_clk", "t1_clk, and "t2_clk".
+ * In the same vein, they should platform_get_irq() for irqs 0, 1, and 2.
+ * On other platforms, only irq 0 and "t0_clk" will be available; drivers
+ * should handle with both configurations.
+ */
+struct platform_device *atmel_tc_alloc(unsigned block, struct resource **iomem)
+{
+ struct platform_device *tc;
+ struct resource *r;
+
+ if (block >= ARRAY_SIZE(blocks) || !iomem)
+ return NULL;
+
+ tc = blocks[block];
+ if (tc) {
+ r = platform_get_resource(tc, IORESOURCE_MEM, 0);
+ if (r)
+ r = request_mem_region(r->start, 256, NULL);
+ *iomem = r;
+ if (!r)
+ tc = NULL;
+ }
+
+ return tc;
+}
+EXPORT_SYMBOL_GPL(atmel_tc_alloc);
+
+/**
+ * atmel_tc_free - release a specified TC block
+ * @block: which block to release
+ *
+ * This reverses the effect of atmel_tc_alloc(), invalidating the resource
+ * returned by that routine and making the TC available to other drivers.
+ */
+void atmel_tc_free(struct platform_device *tc)
+{
+ if (tc->id >= 0 && tc->id < ARRAY_SIZE(blocks)) {
+ struct resource *r;
+
+ r = platform_get_resource(tc, IORESOURCE_MEM, 0);
+ release_mem_region(r->start, 256);
+ }
+}
+EXPORT_SYMBOL_GPL(atmel_tc_free);
+
+static int __init tc_probe(struct platform_device *pdev)
+{
+ static char __initdata e2big[] =
+ KERN_ERR "tclib: can't record TC block %d\n";
+
+ if (pdev->id < 0 || pdev->id >= ARRAY_SIZE(blocks)) {
+ printk(e2big, pdev->id);
+ return -ENFILE;
+ }
+
Re: [Bug 10030] Suspend doesn't work when SD card is inserted
On Friday, 22 of February 2008, Alan Stern wrote: > On Thu, 21 Feb 2008, Rafael J. Wysocki wrote: > > > BTW, below is a simplified version of the patch, without the mutex > > protecting > > suspending_task. I'd like to push it upstream if it looks good. > > It does look good. Go ahead and push. > > Acked-by: Alan Stern <[EMAIL PROTECTED]> > > > Please also have a look at http://bugzilla.kernel.org/show_bug.cgi?id=10030. > > There seems to be another issue related to us holding devices' semaphores. > > Namely, it looks like, when the user removes the card, a concurrent thread > > (from a workqueue) calls device_del() and blocks on the dev->sem held by > > us and then something else deadlocks with this thread. I'll be looking into > > this tomorrow. > > I've been too busy with other things to look at the activity on that > bug report. Tonight or tomorrow... Unfortunately, I missed your Bugzilla comment at http://bugzilla.kernel.org/show_bug.cgi?id=10030#c28 Well, in the face of it, I'm considering to remove the code that acquires device semaphores from the suspend core for now. Evidently, this change turns out to be painfully premature. Also, we have apparent problems with pm_sleep_lock() being take in device_add() (see http://bugzilla.kernel.org/show_bug.cgi?id=9874). Thanks, Rafael -- 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 00/37] Permit filesystem local caching
Daniel Phillips <[EMAIL PROTECTED]> wrote: > I am eventually going to suggest cutting the backing filesystem entirely out > of the picture, You still need a database to manage the cache. A filesystem such as Ext3 makes a very handy database for four reasons: (1) It exists and works. (2) It has a well defined interface within the kernel. (3) I can place my cache on, say, my root partition on my laptop. I don't have to dedicate a partition to the cache. (4) Userspace cache management tools (such as cachefilesd) have an already existing interface to use: rmdir, unlink, open, getdents, etc.. I do have a cache-on-blockdev thing, but it's basically a wandering tree filesystem inside. It is, or was, much faster than ext3 on a clean cache, but it degrades horribly over time because my free space reclamation sucks - it gradually randomises the block allocation sequence over time. So, what would you suggest instead of a backing filesystem? > I really do not like idea of force fitting this cache into a generic > vfs model. Sun was collectively smoking some serious crack when they > cooked that one up. But there is also the ageless principle "isness is > more important than niceness". What do you mean? I'm not doing it like Sun. The cache is a side path from the netfs. It should be transparent to the user, the VFS and the server. The only place it might not be transparent is that you might to have to instruct the netfs mount to use the cache. I'd prefer to do it some other way than passing parameters to mount, though, as (1) this causes fun with NIS distributed automounter maps, and (2) people are asking for a finer grain of control than per-mountpoint. Unfortunately, I can't seem to find a way to do it that's acceptable to Al. > Which would require a change to NFS, not an option because you hope to > work with standard servers? Of course with years to think about this, > the required protocol changes were put into v4. Not. I don't think there's much I can do about NFS. It requires the filesystem from which the NFS server is dealing to have inode uniquifiers, which are then incorporated into the file handle. I don't think the NFS protocol itself needs to change to support this. > Have you completely exhausted optimization ideas for the file handle > lookup? No, but there aren't many. CacheFiles doesn't actually do very much, and it's hard to reduce that not very much. The most obvious thing is to prepopulate the dcache, but that's at the expense of memory usage. Actually, if I cache the name => FH mapping I used last time, I can make a start on looking up in the cache whilst simultaneously accessing the server. If what's on the server has changed, I can ditch the speculative cache lookup I was making and start a new cache lookup. However, storing directory entries has penalties of its own, though it'll be necesary if we want to do disconnected operation. > > Where "lookup table" == "dcache". That would be good yes. cachefilesd > > prescans all the files in the cache, which ought to do just that, but it > > doesn't seem to be very effective. I'm not sure why. > > RCU? Anyway, it is something to be tracked down and put right. cachefilesd runs in userspace. It's possible it isn't doing enough to preload all the metadata. > What I tried to say. So still... got any ideas? That extra synchronous > network round trip is a killer. Can it be made streaming/async to keep > throughput healthy? That's a per-netfs thing. With the test rig I've got, it's going to the on-disk cache that's the killer. Going over the network is much faster. See the results I posted. For the tarball load, and using Ext3 to back the cache: Cold NFS cache, no disk cache: 0m22.734s Warm on-disk cache, cold pagecaches:1m54.350s The problem is reading using tar is a worst case workload for this. Everything it does is pretty much completely synchronous. One thing that might help is if things like tar and find can be made to use fadvise() on directories to hint to the filesystem (NFS, AFS, whatever) that it's going to access every file in those directories. Certainly AFS could make use of that: the directory is read as a file, and the netfs then parses the file to get a list of vnode IDs that that directory points to. It could then do bulk status fetch operations to instantiate the inodes 50 at a time. I don't know whether NFS could use it. Someone like Trond or SteveD or Chuck would have to answer that. David -- 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/
[patch 2.6.25-rc2-git] gpio: and "no GPIO support here" stubs
Add a defining fail/warn stubs for GPIO calls on platforms
that don't support the GPIO programming interface. That includes the
arch-specific implementation glue otherwise.
This facilitates a new model for GPIO usage: drivers that can use GPIOs
if they're available, but don't require them. One example of such a
driver is NAND driver for various FreeScale chips. On platforms update
with GPIO support, they can be used instead of a worst-case delay to
verify that the BUSY signal is off.
(Also includes a couple minor unrelated doc updates.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Please include before 2.6.25-final ...
Documentation/gpio.txt | 16 ++--
include/linux/gpio.h | 95 +
2 files changed, 107 insertions(+), 4 deletions(-)
--- g26.orig/Documentation/gpio.txt 2008-02-22 16:20:36.0 -0800
+++ g26/Documentation/gpio.txt 2008-02-22 17:02:00.0 -0800
@@ -2,6 +2,9 @@ GPIO Interfaces
This provides an overview of GPIO access conventions on Linux.
+These calls use the gpio_* naming prefix. No other calls should use that
+prefix, or the related __gpio_* prefix.
+
What is a GPIO?
===
@@ -69,11 +72,13 @@ in this document, but drivers acting as
not care how it's implemented.)
That said, if the convention is supported on their platform, drivers should
-use it when possible. Platforms should declare GENERIC_GPIO support in
-Kconfig (boolean true), which multi-platform drivers can depend on when
-using the include file:
+use it when possible. Platforms must declare GENERIC_GPIO support in their
+Kconfig (boolean true), and provide an file. Drivers that can't
+work without standard GPIO calls should have Kconfig entries which depend
+on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as
+optimized-away stubs, when drivers use the include file:
- #include
+ #include
If you stick to this convention then it'll be easier for other developers to
see what your code is doing, and help maintain it.
@@ -326,6 +331,9 @@ pulldowns integrated on some platforms.
or support them in the same way; and any given board might use external
pullups (or pulldowns) so that the on-chip ones should not be used.
(When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
+Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a
+platform-specific issue, as are models like (not) having a one-to-one
+correspondence between configurable pins and GPIOs.
There are other system-specific mechanisms that are not specified here,
like the aforementioned options for input de-glitching and wire-OR output.
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/include/linux/gpio.h2008-02-22 17:05:48.0 -0800
@@ -0,0 +1,95 @@
+#ifndef __LINUX_GPIO_H
+#define __LINUX_GPIO_H
+
+/* see Documentation/gpio.txt */
+
+#ifdef CONFIG_GENERIC_GPIO
+#include
+
+#else
+
+/*
+ * Some platforms don't support the GPIO programming interface.
+ *
+ * In case some driver uses it anyway (it should normally have
+ * depended on GENERIC_GPIO), these routines help the compiler
+ * optimize out much GPIO-related code ... or trigger a runtime
+ * warning when something is wrongly called.
+ */
+
+static inline int gpio_is_valid(int number)
+{
+ return 0;
+}
+
+static inline int gpio_request(unsigned gpio, const char *label)
+{
+ return -ENOSYS;
+}
+
+static inline void gpio_free(unsigned gpio)
+{
+ /* GPIO can never have been requested */
+ WARN_ON(1);
+}
+
+static inline int gpio_direction_input(unsigned gpio)
+{
+ return -ENOSYS;
+}
+
+static inline int gpio_direction_output(unsigned gpio, int value)
+{
+ return -ENOSYS;
+}
+
+static inline int gpio_get_value(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_set_value(unsigned gpio, int value)
+{
+ /* GPIO can never have been requested or set as output */
+ WARN_ON(1);
+}
+
+static inline int gpio_cansleep(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline int gpio_get_value_cansleep(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_set_value_cansleep(unsigned gpio, int value)
+{
+ /* GPIO can never have been requested or set as output */
+ WARN_ON(1);
+}
+
+static inline int gpio_to_irq(unsigned gpio)
+{
+ /* GPIO can never have been requested or set as input */
+ WARN_ON(1);
+ return -EINVAL;
+}
+
+static inline int irq_to_gpio(unsigned irq)
+{
+ /* irq can never have been returned from gpio_to_irq() */
+ WARN_ON(1);
+ return -EINVAL;
+}
+
+#endif
+
+#endif /* __LINUX_GPIO_H */
--
To unsubscribe from this list:
Re: [PATCH 2.6.25-rc2 3/9] Kconfig: Improve init/Kconfig help descriptions - NAMESPACES
On Fri, Feb 22, 2008 at 04:14:12PM -0600, Serge E. Hallyn wrote: > Quoting Nick Andrew ([EMAIL PROTECTED]): > > config UTS_NS > > bool "UTS namespace" > > depends on NAMESPACES > > help > > - In this namespace tasks see different info provided with the > > - uname() system call > > + Enable support for multiple UTS system attributes. > > + > > + Each UTS namespace provides an individual view of the > > + information returned by the uname() system call including > > + hostname, kernel version and domain name. > > + > > + This is used by container systems (e.g. vservers) so that > > + each container has its own hostname and other attributes. > > + Tasks in the container are placed in the UTS namespace > > + corresponding to the container. > > this paragraph reads a little weird... really what happens is that > each forked task is in the same UTS namespace as its parent, unless > it was cloned with CLONE_NEWUTS or has done unshare(CLONE_NEWUTS), > in which case it receives a copy. You mean only the third paragraph, right? I hope the other two are accurate. I'm trying to describe how the feature is used by container systems and my description is obviously inaccurate. There are subtle semantic differences between the way the different namespaces work, which you've pointed out. I think mentioning CLONE_NEWUTS or other flags is too technical for help descriptions. For UTS_NS and IPC_NS I think I could remove that paragraph because the end user hint "Answer Y if you will be using a container system" remains. For USER_NS and PID_NS however, these features are tagged EXPERIMENTAL so the hint is "If unsure, say N" and I think I need to at least mention the use in container systems or find some better clarifying description which doesn't get too technical. > > + This is used by container systems (e.g. vservers). > > + Tasks in the container are placed in the IPC namespace > > + corresponding to the container. > > Same as with UTS, except that upon CLONE_NEWIPC the task receives a > blank new ipc namespace, not a copy of the original. Per above my response is to remove the paragraph. > > config PID_NS > > [...] > > default n > > depends on NAMESPACES && EXPERIMENTAL > > help > > - Suport process id namespaces. This allows having multiple > > - process with the same pid as long as they are in different > > - pid namespaces. This is a building block of containers. > > + Enable experimental support for hierarchical process id namespaces. > > > > - Unless you want to work with an experimental feature > > - say N here. > > + This is a function used by container-based virtualisation > > + systems (e.g. vservers). Each process will have a distinct > > + Process ID in each PID namespace which the process is in. > > + Processes in the container are placed in the PID namespace > > + corresponding to the container, and cannot see or affect > > + processes in any parent PID namespace. > > A cloned process inherits the pid namespace hierarchy from its > parent. If it was cloned with CLONE_NEWPID, the hierarchy is > topped with one additional newly created pid namespace. This > is the only pid namespace in which the new process will be able > to see processes, while it will be visible in all namespaces in > its pidns hierarchy. Yes, I understand that. Would you agree that your problem is with the wording "Processes in the container are placed in the PID namespace corresponding to the container"? And that this is the part that needs to be fixed? ... todo = revisit these descriptions soon, not today though Nick. -- PGP Key ID = 0x418487E7 http://www.nick-andrew.net/ PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7 -- 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] make smackfs.c:smk_unlbl_ambient() static
--- Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch makes the needlessly global smk_unlbl_ambient() static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Casey Schaufler <[EMAIL PROTECTED]>
Oops.
>
> ---
> 60c7072cb922cdecdb8a4f08e5710c014e0e8a8c diff --git
> a/security/smack/smackfs.c b/security/smack/smackfs.c
> index 358c92c..7c6e671 100644
> --- a/security/smack/smackfs.c
> +++ b/security/smack/smackfs.c
> @@ -371,7 +371,7 @@ void smk_cipso_doi(void)
> /**
> * smk_unlbl_ambient - initialize the unlabeled domain
> */
> -void smk_unlbl_ambient(char *oldambient)
> +static void smk_unlbl_ambient(char *oldambient)
> {
> int rc;
> struct netlbl_audit audit_info;
> --
> 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/
>
>
>
Casey Schaufler
[EMAIL PROTECTED]
--
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: [stable] patch kbuild-allow-fstack-protector-to-take-effect.patch added to 2.6.24-stable tree
On Fri, Feb 22, 2008 at 06:59:14PM -0500, Dave Jones wrote: > On Fri, Feb 22, 2008 at 03:42:16PM -0800, Greg Kroah-Hartman wrote: > > > > > I thought that thread was for the much larger patches, not just this > > > > Makefile change. > > > > > > At the least we'll likely want to also pick up the other stack protector > fixes > > > that went into .25rc if we turn it on in .24 > > > > Hm, that sounds like a new feature :) > > > > I thought the makefile change was just a bugfix in the broken makefile. > > Well, it is. But it'll cause it to enable something that has been broken for > a while. > FWIW, I think having the stack protector reenabled in -stable is a worthwhile > goal, > but only once it's stabilised for a while in the development tree. > > My fear by just reenabling this for -stable is that when distros push out > updates > based on the latest -stable, we'll see more systems like James' problematic > system. Fair enough, between this worry, and Arjan saying "no way", I've now dropped it :) thanks, greg k-h -- 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: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> --- linux-2.6.orig/drivers/char/drm/i915_drv.c
> +++ linux-2.6/drivers/char/drm/i915_drv.c
> @@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
> dev_priv->saveGR[0x18]);
>
> /* Attribute controller registers */
> + inb(st01);
> for (i = 0; i < 20; i++)
> i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
> inb(st01); /* switch back to index mode */
I'm doing this part separately, please drop it - it has nothing to do with
the rest of the patch.
I'd also suggest that you just add a helper function like
int pm_event_powerdown(struct pm_message mesg)
{
return mesg.event >= PM_EVENT_SUSPEND;
}
or something, so that you can have code like
if (pm_event_powerdown(mesg))
pci_set_power_state(pdev, PCI_D3hot);
instead of the test for EVENT_SUSPEND/HIBERNATE explicitly.
Of course, the places that already do a switch-statement are much better
kept that way and just add PM_EVENT_HIBERNATE to the list.
> --- linux-2.6.orig/drivers/pci/pci.c
> +++ linux-2.6/drivers/pci/pci.c
> @@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
> case PM_EVENT_PRETHAW:
> /* REVISIT both freeze and pre-thaw "should" use D0 */
> case PM_EVENT_SUSPEND:
> + case PM_EVENT_HIBERNATE:
> return PCI_D3hot;
Didn't you miss the apci_pci_choose_state() thing that also needs this
extension?
> Index: linux-2.6/drivers/usb/host/u132-hcd.c
> ===
> --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> +++ linux-2.6/drivers/usb/host/u132-hcd.c
> @@ -3214,14 +3214,18 @@ static int u132_suspend(struct platform_
> return -ESHUTDOWN;
> } else {
> int retval = 0;
> -if (state.event == PM_EVENT_FREEZE) {
> +
> + switch (state.event) {
> + case PM_EVENT_FREEZE:
> retval = u132_bus_suspend(hcd);
> -} else if (state.event == PM_EVENT_SUSPEND) {
> + break;
> + case PM_EVENT_SUSPEND:
> + case PM_EVENT_HIBERNATE:
> int ports = MAX_U132_PORTS;
> while (ports-- > 0) {
> port_power(u132, ports, 0);
> }
> -}
> + break;
> if (retval == 0)
> pdev->dev.power.power_state = state;
> return retval;
Looks like a missing close-brace to me there - you removed the final '}'.
Or am I blind?
Apart from those issues it looks fine to me.
Linus
--
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/
RFE: __alloc_pages() SLAB_PANIC & gfp_mask
Group, Currrently I do not subscribe to this mail alias, so please keep the cc. Currently a few calls exist where WAIT is specified ( (GFP_KERNEL)for the slab/slob allocators and also as an additional argument, SLAB_PANIC is checked against the return of the request for memory allocation. SLAB_PANIC is not passed to __alloc_pages() as part of the gfp_mask. If the memory allocation fails, and the flag is turned on, then a panic will ensure.. There is a very simple fix for this. The assumption is too basicly ASSERT a guarantee that memory failure in this case will not occur. The suggestion is to add the SLAB_PANIC arg to the gfp_mask, add it to the mask in the SLAB/SLUB callers, and have that checked within __alloc_pages if a mem alloc failure is about to occur after the check for no WAITers. If it is set, then force additional loops within the function. This would remove new cache creates from causing a panic when a low memory condition exists. Mitchell Erblich -- 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/
Question about your git habits
I've been making myself more familiar with git lately and I'm curious what habits others have adopted. (I know there are a few documents in circulation that deal with using git to work on the kernel but I don't think this has been specifically covered). My question is: If you're working on multiple things at once, do you tend to clone the entire repository repeatedly into a series of separate working directories and do your work there, then pull that work (possibly comprising a series of "temporary" commits) back into a separate local master respository with --squash, either into "master" or into a branch containing the new feature? Or perhaps you create a temporary topical branch for each thing you are working on, and commit arbitrary changes then checkout another branch when you need to change gears, finally --squashing the intermediate commits when a particular piece of work is done? I'm using git to manage my project and I'm trying to determine the most optimal workflow I can. I figure that I'm going to have an "official" master repository for the project, and I want to keep the revision history clean in that repository (ie, no messy intermediate commits that don't compile or only implement a feature half way). On older projects I was using a certalized revision control system like *cough* Subversion *cough* and I'd create separate branches which I'd check out into their own working trees. It seems to me that having multiple working trees (effectively, cloning the "master" repository every time I need to make anything but a trivial change) would be most effective under git as well as it doesn't require creating messy, intermediate commits in the first place (but allows for them if they are used). But I wonder how that approach would scale with a project whose git repo weighed hundreds of megs or more. (With a centralized rcs, of course, you don't have to lug around a copy of the whole project history in each working tree.) Insight appreciated, and I apologize if I've failed to RTFM somewhere. Thanks, Chase -- 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/
[PATCH] x86_64: clean up e820_reserve_resources
e820_resource_resources could use insert_resource instead of request_resource
also move code_resource, data_resource, bss_resource, and crashk_res
out of e820_reserve_resources.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Index: linux-2.6/arch/x86/kernel/e820_64.c
===
--- linux-2.6.orig/arch/x86/kernel/e820_64.c
+++ linux-2.6/arch/x86/kernel/e820_64.c
@@ -229,8 +229,7 @@ unsigned long __init e820_end_of_ram(voi
/*
* Mark e820 reserved areas as busy for the resource manager.
*/
-void __init e820_reserve_resources(struct resource *code_resource,
- struct resource *data_resource, struct resource *bss_resource)
+void __init e820_reserve_resources(void)
{
int i;
for (i = 0; i < e820.nr_map; i++) {
@@ -245,21 +244,7 @@ void __init e820_reserve_resources(struc
res->start = e820.map[i].addr;
res->end = res->start + e820.map[i].size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- request_resource(_resource, res);
- if (e820.map[i].type == E820_RAM) {
- /*
-* We don't know which RAM region contains kernel data,
-* so we try it repeatedly and let the resource manager
-* test it.
-*/
- request_resource(res, code_resource);
- request_resource(res, data_resource);
- request_resource(res, bss_resource);
-#ifdef CONFIG_KEXEC
- if (crashk_res.start != crashk_res.end)
- request_resource(res, _res);
-#endif
- }
+ insert_resource(_resource, res);
}
}
Index: linux-2.6/arch/x86/kernel/setup_64.c
===
--- linux-2.6.orig/arch/x86/kernel/setup_64.c
+++ linux-2.6/arch/x86/kernel/setup_64.c
@@ -250,6 +250,7 @@ static void __init reserve_crashkernel(v
(unsigned long)(total_mem >> 20));
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
+ insert_resource(_resource, _res);
}
}
#else
@@ -324,6 +325,11 @@ void __init setup_arch(char **cmdline_p)
finish_e820_parsing();
+ /* after parse_early_param, so could debug it */
+ insert_resource(_resource, _resource);
+ insert_resource(_resource, _resource);
+ insert_resource(_resource, _resource);
+
early_gart_iommu_check();
e820_register_active_regions(0, 0, -1UL);
@@ -456,7 +462,7 @@ void __init setup_arch(char **cmdline_p)
/*
* We trust e820 completely. No explicit ROM probing in memory.
*/
- e820_reserve_resources(_resource, _resource, _resource);
+ e820_reserve_resources();
e820_mark_nosave_regions();
/* request I/O space for devices used on all i[345]86 PCs */
Index: linux-2.6/include/asm-x86/e820_64.h
===
--- linux-2.6.orig/include/asm-x86/e820_64.h
+++ linux-2.6/include/asm-x86/e820_64.h
@@ -21,8 +21,7 @@ extern void add_memory_region(unsigned l
extern void setup_memory_region(void);
extern void contig_e820_setup(void);
extern unsigned long e820_end_of_ram(void);
-extern void e820_reserve_resources(struct resource *code_resource,
- struct resource *data_resource, struct resource *bss_resource);
+extern void e820_reserve_resources(void);
extern void e820_mark_nosave_regions(void);
extern int e820_any_mapped(unsigned long start, unsigned long end, unsigned
type);
extern int e820_all_mapped(unsigned long start, unsigned long end, unsigned
type);
--
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/
[patch 04/38] inotify: fix check for one-shot watches before destroying them
2.6.24-stable review patch. If anyone has any objections, please let us know. -- From: Ulisses Furquim <[EMAIL PROTECTED]> patch ac74c00e499ed276a965e5b5600667d5dc04a84a in mainline. As the IN_ONESHOT bit is never set when an event is sent we must check it in the watch's mask and not in the event's mask. Signed-off-by: Ulisses Furquim <[EMAIL PROTECTED]> Reported-by: "Clem Taylor" <[EMAIL PROTECTED]> Tested-by: "Clem Taylor" <[EMAIL PROTECTED]> Cc: Amy Griffis <[EMAIL PROTECTED]> Cc: Robert Love <[EMAIL PROTECTED]> Cc: John McCutchan <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- fs/inotify_user.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/inotify_user.c +++ b/fs/inotify_user.c @@ -269,7 +269,7 @@ static void inotify_dev_queue_event(stru /* we can safely put the watch as we don't reference it while * generating the event */ - if (mask & IN_IGNORED || mask & IN_ONESHOT) + if (mask & IN_IGNORED || w->mask & IN_ONESHOT) put_inotify_watch(w); /* final put */ /* coalescing: drop this event if it is a dupe of the previous */ -- -- 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/
[PATCHv2 2/2] char: fix possible double-unlock in esp.c
Hitting either of the break statements in the while loop would cause a double-unlock of info->lock. [Jiri Slaby suggested simply returning is safe here, rather than a goto] Noticed by sparse: drivers/char/esp.c:2042:2: warning: context imbalance in 'rs_wait_until_sent' - unexpected unlock Signed-off-by: Harvey Harrison <[EMAIL PROTECTED]> --- drivers/char/esp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/esp.c b/drivers/char/esp.c index 01fbddd..0a33d09 100644 --- a/drivers/char/esp.c +++ b/drivers/char/esp.c @@ -2030,10 +2030,10 @@ static void rs_wait_until_sent(struct tty_struct *tty, int timeout) msleep_interruptible(jiffies_to_msecs(char_time)); if (signal_pending(current)) - break; + return; if (timeout && time_after(jiffies, orig_jiffies + timeout)) - break; + return; spin_lock_irqsave(>lock, flags); serial_out(info, UART_ESI_CMD1, ESI_NO_COMMAND); -- 1.5.4.2.200.g99e75 -- 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 34/38] kbuild: allow -fstack-protector to take effect
On Fri, Feb 22, 2008 at 04:46:17PM -0800, Arjan van de Ven wrote: > On Fri, 22 Feb 2008 16:31:33 -0800 > Greg KH <[EMAIL PROTECTED]> wrote: > > > 2.6.24-stable review patch. If anyone has any objections, please let > > us know. > > > not ready for -stable yet. if ever for backporting (doubtful) Ok, dropped from -stable, thanks. greg k-h -- 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 34/38] kbuild: allow -fstack-protector to take effect
On Fri, 22 Feb 2008 16:31:33 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > 2.6.24-stable review patch. If anyone has any objections, please let > us know. not ready for -stable yet. if ever for backporting (doubtful) > > -- > From: Sam Ravnborg <[EMAIL PROTECTED]> > > commit: e06b8b98da071f7dd78fb7822991694288047df0 > > Arjan van de Ven <[EMAIL PROTECTED]> wrote: > === > I just read the excellent LWN writeup of the vmsplice > security thing, and that got me wondering why this attack > wasn't stopped by the CONFIG_CC_STACKPROTECTOR option... > because it plain should have been... > > Some analysis later.. it turns out that the following line > in the top level Makefile, added by you in October 2007, > entirely disables CONFIG_CC_STACKPROTECTOR ;( > With this line removed the exploit will be nicely stopped. > > CFLAGS += $(call cc-option, -fno-stack-protector) > > Now I realize that certain distros have patched gcc to > compensate for their lack of distro wide CFLAGS, and it's > great to work around that... but would there be a way to NOT > disable this for CONFIG_CC_STACKPROTECTOR please? > It would have made this exploit not possible for those kernels > that enable this feature (and that includes distros like Fedora) > === > > Move the assignment to KBUILD_CFLAGS up before including > the arch specific Makefile so arch makefiles may override > the setting. > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Arjan van de Ven <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- > Makefile |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > --- a/Makefile > +++ b/Makefile > @@ -507,6 +507,10 @@ else > KBUILD_CFLAGS+= -O2 > endif > > +# Force gcc to behave correct even for buggy distributions > +# Arch Makefiles may override this setting > +KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > + > include $(srctree)/arch/$(SRCARCH)/Makefile > > ifdef CONFIG_FRAME_POINTER > @@ -520,9 +524,6 @@ KBUILD_CFLAGS += -g > KBUILD_AFLAGS+= -gdwarf-2 > endif > > -# Force gcc to behave correct even for buggy distributions > -KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) > - > # arch Makefile may override CC so keep this after arch Makefile is > included NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) > -print-file-name=include) CHECKFLAGS += $(NOSTDINC_FLAGS) > -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/4 resend] [x86] Add generic GPIO support to x86
On Friday 22 February 2008, Anton Vorontsov wrote:
> > +static inline int gpio_request(unsigned gpio, const char *label)
> > +{
> > + return -EINVAL;
>
> Could we return -ENOSYS instead, so drivers will able to distinguish
> between "something really failed" and "there is no gpio support,
> fallback to other methods"? Without this, the notorious NAND driver
> will hardly benefit from this change. ;-)
Sure; that'll be gpio_request() and the gpio_direction_*() calls only
though, since those are the initial setup calls drivers make.
- Dave
--
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/
[PATCH try #1] Kconfig: cleanup usr/Kconfig help descriptions
Modify the help descriptions of usr/Kconfig for clarity, accuracy and consistency. This patch mostly clarifies what INITRAMFS_SOURCE does, i.e. optionally build a CPIO archive of the initial root filesystem (initramfs) and compress it and link it into the kernel. Note that usually the initramfs is separate, and loaded by a bootloader (and I give a list of the common ones, for clarity). Correct the filename of gen_init_cpio.c and clarify that any filenames specified contain lists of directives for the archive builder, rather than files to be added directly into the archive. Improve grammar on INITRAMFS_ROOT_UID and INITRAMFS_ROOT_GID and use consistent terminology. Signed-off-by: Nick Andrew <[EMAIL PROTECTED]> --- I think I might be starting to get the hang of this :-) usr/Kconfig | 51 +-- 1 files changed, 33 insertions(+), 18 deletions(-) diff --git a/usr/Kconfig b/usr/Kconfig index 86cecb5..0ad8713 100644 --- a/usr/Kconfig +++ b/usr/Kconfig @@ -6,41 +6,56 @@ config INITRAMFS_SOURCE string "Initramfs source file(s)" default "" help - This can be either a single cpio archive with a .cpio suffix or a - space-separated list of directories and files for building the - initramfs image. A cpio archive should contain a filesystem archive - to be used as an initramfs image. Directories should contain a - filesystem layout to be included in the initramfs image. Files - should contain entries according to the format described by the - "usr/gen_init_cpio" program in the kernel tree. + Specify the contents of an early userspace image to be linked + into the kernel image. + + A booting kernel usually obtains an initramfs image from a + bootloader (e.g. loadlin, lilo or grub). Alternately one can + be built and linked into the kernel image using this option. + + You can specify either a single cpio archive filename with a .cpio + suffix or a space-separated list of directories and files for + building the initramfs image. The result will be a compressed + cpio archive containing a filesystem layout which will be + used as an initramfs image by the booting kernel. + + A cpio archive should contain a filesystem layout which will + become the initramfs image. + + Directories should contain a filesystem layout to be included + into the initramfs image. + + Files should contain a list of directives according to the + format described by the program in + the kernel tree. When multiple directories and files are specified then the initramfs image will be the aggregate of all of them. See for more details. - If you are not sure, leave it blank. + If unsure, leave it blank. config INITRAMFS_ROOT_UID int "User ID to map to 0 (user root)" depends on INITRAMFS_SOURCE!="" default "0" help - This setting is only meaningful if the INITRAMFS_SOURCE is - contains a directory. Setting this user ID (UID) to something - other than "0" will cause all files owned by that UID to be - owned by user root in the initial ramdisk image. + This setting is only meaningful if INITRAMFS_SOURCE contains + a directory. Setting this user ID (UID) to something other + than "0" will cause all files owned by that UID in the source + directories to be owned by user root in the initramfs image. - If you are not sure, leave it set to "0". + If unsure, leave it set to "0". config INITRAMFS_ROOT_GID int "Group ID to map to 0 (group root)" depends on INITRAMFS_SOURCE!="" default "0" help - This setting is only meaningful if the INITRAMFS_SOURCE is - contains a directory. Setting this group ID (GID) to something - other than "0" will cause all files owned by that GID to be - owned by group root in the initial ramdisk image. + This setting is only meaningful if INITRAMFS_SOURCE contains + a directory. Setting this group ID (GID) to something other + than "0" will cause all files owned by that GID in the source + directories to be owned by group root in the initramfs image. - If you are not sure, leave it set to "0". + If unsure, leave it set to "0". -- 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 [RT] 11/14] optimize the !printk fastpath through the lock acquisition
On Fri, Feb 22, 2008 at 2:20 PM, Gregory Haskins <[EMAIL PROTECTED]> wrote: > Agreed, but it's still correct afaict. I added an extra might_sleep() > to a path that really might sleep. I should have mentioned that in the > header. > > In any case, its moot. Andi indicated this patch is probably a no-op so > I was considering dropping it on the v2 pass. The might_sleep is annotation and well as a conditional preemption point for the regular kernel. You might want to do a schedule check there, but it's the wrong function if memory serves me correctly. It's reserved for things that actually are design to sleep. The rt_spin*() function are really a method of preserving BKL semantics across real schedule() calls. You'd have to use something else instead for that purpose like cond_reschedule() instead. bill -- 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/
[patch 38/38] x86_64: CPA, fix cache attribute inconsistency bug
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Ingo Molnar <[EMAIL PROTECTED]>
(no matching git id as the upstream code is rewritten)
fix CPA cache attribute bug in v2.6.24. When phys_base is nonzero (when
CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates the
secondary alias address by -14 MB (depending on the configured offset).
The default 64-bit kernels of Fedora and Ubuntu are affected:
$ grep RELOCA /boot/config-2.6.23.9-85.fc8
CONFIG_RELOCATABLE=y
$ grep RELOC /boot/config-2.6.22-14-generic
CONFIG_RELOCATABLE=y
and probably on many other distros as well.
the bug affects all pages in the first 40 MB of physical RAM that
are allocated by some subsystem that does ioremap_nocache() on them:
if (__pa(address) < KERNEL_TEXT_SIZE) {
Hence we might leave page table entries with inconsistent cache
attributes around (pages mapped at both UnCacheable and Write-Back),
and we can also set the wrong kernel text pages to UnCacheable.
the effects of this bug can be random slowdowns and other misbehavior.
If for example AGP allocates its aperture pages into the first 40 MB
of physical RAM, then the -14 MB bug might mark random kernel texto
pages as uncacheable, slowing down a random portion of the 64-bit
kernel until the AGP driver is unloaded.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/x86/mm/pageattr_64.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/mm/pageattr_64.c
+++ b/arch/x86/mm/pageattr_64.c
@@ -207,7 +207,7 @@ int change_page_attr_addr(unsigned long
if (__pa(address) < KERNEL_TEXT_SIZE) {
unsigned long addr2;
pgprot_t prot2;
- addr2 = __START_KERNEL_map + __pa(address);
+ addr2 = __START_KERNEL_map + __pa(address) - phys_base;
/* Make sure the kernel mappings stay executable */
prot2 = pte_pgprot(pte_mkexec(pfn_pte(0, prot)));
err = __change_page_attr(addr2, pfn, prot2,
--
--
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/
[patch 36/38] POWERPC: Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Olaf Hering <[EMAIL PROTECTED]>
Commit: 092ca5bd61da6344f3b249754b337f2d48dfe08d
[POWERPC] Revert chrp_pci_fixup_vt8231_ata devinit to fix libata on pegasos
Commit 6d98bda79bea0e1be26c0767d0e9923ad3b72f2e changed the init order
for chrp_pci_fixup_vt8231_ata().
It can not work anymore because either the irq is not yet set to 14 or
pci_get_device() returns nothing. At least the printk() in
chrp_pci_fixup_vt8231_ata() does not trigger anymore.
pata_via works again on Pegasos with the change below.
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/chrp/pci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/chrp/pci.c
+++ b/arch/powerpc/platforms/chrp/pci.c
@@ -354,7 +354,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_WI
* mode as well. The same fixup must be done to the class-code property in
* the IDE node /[EMAIL PROTECTED]/[EMAIL PROTECTED],1
*/
-static void __devinit chrp_pci_fixup_vt8231_ata(struct pci_dev *viaide)
+static void chrp_pci_fixup_vt8231_ata(struct pci_dev *viaide)
{
u8 progif;
struct pci_dev *viaisa;
@@ -375,4 +375,4 @@ static void __devinit chrp_pci_fixup_vt8
pci_dev_put(viaisa);
}
-DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1,
chrp_pci_fixup_vt8231_ata);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1,
chrp_pci_fixup_vt8231_ata);
--
--
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/
[patch 37/38] bonding: fix NULL pointer deref in startup processing
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Jay Vosburgh <[EMAIL PROTECTED]>
patch 4fe4763cd8cacd81d892193efb48b99c99c15323 in mainline.
Fix the "are we creating a duplicate" check to not compare
the name if the name is NULL (meaning that the system should select
a name). Bug reported by Benny Amorsen <[EMAIL PROTECTED]>.
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4883,14 +4883,16 @@ int bond_create(char *name, struct bond_
down_write(_rwsem);
/* Check to see if the bond already exists. */
- list_for_each_entry_safe(bond, nxt, _dev_list, bond_list)
- if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) {
- printk(KERN_ERR DRV_NAME
+ if (name) {
+ list_for_each_entry_safe(bond, nxt, _dev_list, bond_list)
+ if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) {
+ printk(KERN_ERR DRV_NAME
": cannot add bond %s; it already exists\n",
- name);
- res = -EPERM;
- goto out_rtnl;
- }
+ name);
+ res = -EPERM;
+ goto out_rtnl;
+ }
+ }
bond_dev = alloc_netdev(sizeof(struct bonding), name ? name : "",
ether_setup);
--
--
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/
[patch 34/38] kbuild: allow -fstack-protector to take effect
2.6.24-stable review patch. If anyone has any objections, please let us know. -- From: Sam Ravnborg <[EMAIL PROTECTED]> commit: e06b8b98da071f7dd78fb7822991694288047df0 Arjan van de Ven <[EMAIL PROTECTED]> wrote: === I just read the excellent LWN writeup of the vmsplice security thing, and that got me wondering why this attack wasn't stopped by the CONFIG_CC_STACKPROTECTOR option... because it plain should have been... Some analysis later.. it turns out that the following line in the top level Makefile, added by you in October 2007, entirely disables CONFIG_CC_STACKPROTECTOR ;( With this line removed the exploit will be nicely stopped. CFLAGS += $(call cc-option, -fno-stack-protector) Now I realize that certain distros have patched gcc to compensate for their lack of distro wide CFLAGS, and it's great to work around that... but would there be a way to NOT disable this for CONFIG_CC_STACKPROTECTOR please? It would have made this exploit not possible for those kernels that enable this feature (and that includes distros like Fedora) === Move the assignment to KBUILD_CFLAGS up before including the arch specific Makefile so arch makefiles may override the setting. Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Cc: Arjan van de Ven <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- Makefile |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/Makefile +++ b/Makefile @@ -507,6 +507,10 @@ else KBUILD_CFLAGS += -O2 endif +# Force gcc to behave correct even for buggy distributions +# Arch Makefiles may override this setting +KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) + include $(srctree)/arch/$(SRCARCH)/Makefile ifdef CONFIG_FRAME_POINTER @@ -520,9 +524,6 @@ KBUILD_CFLAGS += -g KBUILD_AFLAGS += -gdwarf-2 endif -# Force gcc to behave correct even for buggy distributions -KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector) - # arch Makefile may override CC so keep this after arch Makefile is included NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include) CHECKFLAGS += $(NOSTDINC_FLAGS) -- -- 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/
[patch 35/38] PCMCIA: Fix station address detection in smc
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Chuck Ebbert <[EMAIL PROTECTED]>
Commit: a1a98b72dbd17e53cd92b8e78f404525ebcfd981
Fix station address detection in smc
Megahertz EM1144 PCMCIA ethernet adapter needs special handling
because it has two VERS_1 tuples and the station address is in
the second one. Conversion to generic handling of these fields
broke it. Reverting that fixes the device.
https://bugzilla.redhat.com/show_bug.cgi?id=233255
Thanks go to Jon Stanley for not giving up on this one until the
problem was found.
Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/net/pcmcia/smc91c92_cs.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/net/pcmcia/smc91c92_cs.c
+++ b/drivers/net/pcmcia/smc91c92_cs.c
@@ -559,8 +559,16 @@ static int mhz_setup(struct pcmcia_devic
/* Read the station address from the CIS. It is stored as the last
(fourth) string in the Version 1 Version/ID tuple. */
-if (link->prod_id[3]) {
- station_addr = link->prod_id[3];
+tuple->DesiredTuple = CISTPL_VERS_1;
+if (first_tuple(link, tuple, parse) != CS_SUCCESS) {
+ rc = -1;
+ goto free_cfg_mem;
+}
+/* Ugh -- the EM1144 card has two VERS_1 tuples!?! */
+if (next_tuple(link, tuple, parse) != CS_SUCCESS)
+ first_tuple(link, tuple, parse);
+if (parse->version_1.ns > 3) {
+ station_addr = parse->version_1.str + parse->version_1.ofs[3];
if (cvt_ascii_address(dev, station_addr) == 0) {
rc = 0;
goto free_cfg_mem;
--
--
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/
[patch 32/38] USB: fix pm counter leak in usblp
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Oliver Neukum <[EMAIL PROTECTED]>
commit 1902869019918411c148c18cc3a22aade569ac9a upstream
if you fail in open() you must decrement the pm counter again.
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/class/usblp.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -428,6 +428,7 @@ static int usblp_open(struct inode *inod
usblp->rcomplete = 0;
if (handle_bidir(usblp) < 0) {
+ usb_autopm_put_interface(intf);
usblp->used = 0;
file->private_data = NULL;
retval = -EIO;
--
--
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/
[patch 33/38] SCSI: gdth: scan for scsi devices
2.6.24-stable review patch. If anyone has any objections, please let us know. -- From: Boaz Harrosh <[EMAIL PROTECTED]> commit: 61c92814dc324b541391757062ff02fbf3b08086 The patch: "gdth: switch to modern scsi host registration" missed one simple fact when moving a way from scsi_module.c. That is to call scsi_scan_host() on the probed host. With this the gdth driver from 2.6.24 is again able to see drives and boot. Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> Tested-by: Joerg Dorchain <[EMAIL PROTECTED]> Tested-by: Stefan Priebe <[EMAIL PROTECTED]> Tested-by: Jon Chelton <[EMAIL PROTECTED]> Signed-off-by: James Bottomley <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/scsi/gdth.c |9 + 1 file changed, 9 insertions(+) --- a/drivers/scsi/gdth.c +++ b/drivers/scsi/gdth.c @@ -4838,6 +4838,9 @@ static int __init gdth_isa_probe_one(ulo if (error) goto out_free_coal_stat; list_add_tail(>list, _instances); + + scsi_scan_host(shp); + return 0; out_free_coal_stat: @@ -4965,6 +4968,9 @@ static int __init gdth_eisa_probe_one(us if (error) goto out_free_coal_stat; list_add_tail(>list, _instances); + + scsi_scan_host(shp); + return 0; out_free_ccb_phys: @@ -5102,6 +5108,9 @@ static int __init gdth_pci_probe_one(gdt if (error) goto out_free_coal_stat; list_add_tail(>list, _instances); + + scsi_scan_host(shp); + return 0; out_free_coal_stat: -- -- 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/
[patch 30/38] genirq: do not leave interupts enabled on free_irq
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Thomas Gleixner <[EMAIL PROTECTED]>
commit 89d694b9dbe769ca1004e01db0ca43964806a611
The default_disable() function was changed in commit:
76d2160147f43f982dfe881404cfde9fd0a9da21
genirq: do not mask interrupts by default
It removed the mask function in favour of the default delayed
interrupt disabling. Unfortunately this also broke the shutdown in
free_irq() when the last handler is removed from the interrupt for
those architectures which rely on the default implementations. Now we
can end up with a enabled interrupt line after the last handler was
removed, which can result in spurious interrupts.
Fix this by adding a default_shutdown function, which is only
installed, when the irqchip implementation does provide neither a
shutdown nor a disable function.
Pointed-out-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Tested-by: Michael Hennerich <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/irq/chip.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -246,6 +246,17 @@ static unsigned int default_startup(unsi
}
/*
+ * default shutdown function
+ */
+static void default_shutdown(unsigned int irq)
+{
+ struct irq_desc *desc = irq_desc + irq;
+
+ desc->chip->mask(irq);
+ desc->status |= IRQ_MASKED;
+}
+
+/*
* Fixup enable/disable function pointers
*/
void irq_chip_set_defaults(struct irq_chip *chip)
@@ -256,8 +267,15 @@ void irq_chip_set_defaults(struct irq_ch
chip->disable = default_disable;
if (!chip->startup)
chip->startup = default_startup;
+ /*
+* We use chip->disable, when the user provided its own. When
+* we have default_disable set for chip->disable, then we need
+* to use default_shutdown, otherwise the irq line is not
+* disabled on free_irq():
+*/
if (!chip->shutdown)
- chip->shutdown = chip->disable;
+ chip->shutdown = chip->disable != default_disable ?
+ chip->disable : default_shutdown;
if (!chip->name)
chip->name = chip->typename;
if (!chip->end)
--
--
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/
[patch 31/38] S390: Fix futex_atomic_cmpxchg_std inline assembly.
2.6.24-stable review patch. If anyone has any objections, please let us know. -- From: Heiko Carstens <[EMAIL PROTECTED]> commit: d5b02b3ff1d9a2e1074f559c84ed378cfa6fc3c0 upstream Add missing exception table entry so that the kernel can handle proctection exceptions as well on the cs instruction. Currently only specification exceptions are handled correctly. The missing entry allows user space to crash the kernel. Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- arch/s390/lib/uaccess_std.c |8 1 file changed, 4 insertions(+), 4 deletions(-) --- a/arch/s390/lib/uaccess_std.c +++ b/arch/s390/lib/uaccess_std.c @@ -293,10 +293,10 @@ int futex_atomic_cmpxchg_std(int __user asm volatile( " sacf 256\n" - " cs %1,%4,0(%5)\n" - "0: lr %0,%1\n" - "1: sacf 0\n" - EX_TABLE(0b,1b) + "0: cs %1,%4,0(%5)\n" + "1: lr %0,%1\n" + "2: sacf 0\n" + EX_TABLE(0b,2b) EX_TABLE(1b,2b) : "=d" (ret), "+d" (oldval), "=m" (*uaddr) : "0" (-EFAULT), "d" (newval), "a" (uaddr), "m" (*uaddr) : "cc", "memory" ); -- -- 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/
[patch 28/38] hrtimer: check relative timeouts for overflow
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Thomas Gleixner <[EMAIL PROTECTED]>
commit: 5a7780e725d1bb4c3094fcc12f1c5c5faea1e988
Various user space callers ask for relative timeouts. While we fixed
that overflow issue in hrtimer_start(), the sites which convert
relative user space values to absolute timeouts themself were uncovered.
Instead of putting overflow checks into each place add a function
which does the sanity checking and convert all affected callers to use
it.
Thanks to Frans Pop, who reported the problem and tested the fixes.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Tested-by: Frans Pop <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/linux/ktime.h |2 ++
kernel/futex.c|2 +-
kernel/futex_compat.c |2 +-
kernel/hrtimer.c | 38 +-
kernel/posix-timers.c |8 +---
5 files changed, 30 insertions(+), 22 deletions(-)
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -310,6 +310,8 @@ static inline ktime_t ktime_sub_us(const
return ktime_sub_ns(kt, usec * 1000);
}
+extern ktime_t ktime_add_safe(const ktime_t lhs, const ktime_t rhs);
+
/*
* The resolution of the clocks. The resolution value is returned in
* the clock_getres() system call to give application programmers an
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2094,7 +2094,7 @@ asmlinkage long sys_futex(u32 __user *ua
t = timespec_to_ktime(ts);
if (cmd == FUTEX_WAIT)
- t = ktime_add(ktime_get(), t);
+ t = ktime_add_safe(ktime_get(), t);
tp =
}
/*
--- a/kernel/futex_compat.c
+++ b/kernel/futex_compat.c
@@ -175,7 +175,7 @@ asmlinkage long compat_sys_futex(u32 __u
t = timespec_to_ktime(ts);
if (cmd == FUTEX_WAIT)
- t = ktime_add(ktime_get(), t);
+ t = ktime_add_safe(ktime_get(), t);
tp =
}
if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE)
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -325,6 +325,24 @@ unsigned long ktime_divns(const ktime_t
}
#endif /* BITS_PER_LONG >= 64 */
+/*
+ * Add two ktime values and do a safety check for overflow:
+ */
+
+ktime_t ktime_add_safe(const ktime_t lhs, const ktime_t rhs)
+{
+ ktime_t res = ktime_add(lhs, rhs);
+
+ /*
+* We use KTIME_SEC_MAX here, the maximum timeout which we can
+* return to user space in a timespec:
+*/
+ if (res.tv64 < 0 || res.tv64 < lhs.tv64 || res.tv64 < rhs.tv64)
+ res = ktime_set(KTIME_SEC_MAX, 0);
+
+ return res;
+}
+
/* High resolution timer related functions */
#ifdef CONFIG_HIGH_RES_TIMERS
@@ -682,13 +700,7 @@ hrtimer_forward(struct hrtimer *timer, k
*/
orun++;
}
- timer->expires = ktime_add(timer->expires, interval);
- /*
-* Make sure, that the result did not wrap with a very large
-* interval.
-*/
- if (timer->expires.tv64 < 0)
- timer->expires = ktime_set(KTIME_SEC_MAX, 0);
+ timer->expires = ktime_add_safe(timer->expires, interval);
return orun;
}
@@ -839,7 +851,7 @@ hrtimer_start(struct hrtimer *timer, kti
new_base = switch_hrtimer_base(timer, base);
if (mode == HRTIMER_MODE_REL) {
- tim = ktime_add(tim, new_base->get_time());
+ tim = ktime_add_safe(tim, new_base->get_time());
/*
* CONFIG_TIME_LOW_RES is a temporary way for architectures
* to signal that they simply return xtime in
@@ -848,16 +860,8 @@ hrtimer_start(struct hrtimer *timer, kti
* timeouts. This will go away with the GTOD framework.
*/
#ifdef CONFIG_TIME_LOW_RES
- tim = ktime_add(tim, base->resolution);
+ tim = ktime_add_safe(tim, base->resolution);
#endif
- /*
-* Careful here: User space might have asked for a
-* very long sleep, so the add above might result in a
-* negative number, which enqueues the timer in front
-* of the queue.
-*/
- if (tim.tv64 < 0)
- tim.tv64 = KTIME_MAX;
}
timer->expires = tim;
--- a/kernel/posix-timers.c
+++ b/kernel/posix-timers.c
@@ -766,9 +766,11 @@ common_timer_set(struct k_itimer *timr,
/* SIGEV_NONE timers are not queued ! See common_timer_get */
if (((timr->it_sigev_notify & ~SIGEV_THREAD_ID) == SIGEV_NONE)) {
/* Setup correct expiry time for relative timers */
- if (mode == HRTIMER_MODE_REL)
- timer->expires = ktime_add(timer->expires,
-
[patch 29/38] hrtimer: catch expired CLOCK_REALTIME timers early
2.6.24-stable review patch. If anyone has any objections, please let us know. -- From: Thomas Gleixner <[EMAIL PROTECTED]> commit 63070a79ba482c274bad10ac8c4b587a3e011f2c A CLOCK_REALTIME timer, which has an absolute expiry time less than the clock realtime offset calls with a negative delta into the clock events code and triggers the WARN_ON() there. This is a false positive and needs to be prevented. Check the result of timer->expires - timer->base->offset right away and return -ETIME right away. Thanks to Frans Pop, who reported the problem and tested the fixes. Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Tested-by: Frans Pop <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- kernel/hrtimer.c | 11 +++ 1 file changed, 11 insertions(+) --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -427,6 +427,8 @@ static int hrtimer_reprogram(struct hrti ktime_t expires = ktime_sub(timer->expires, base->offset); int res; + WARN_ON_ONCE(timer->expires.tv64 < 0); + /* * When the callback is running, we do not reprogram the clock event * device. The timer callback is either running on a different CPU or @@ -437,6 +439,15 @@ static int hrtimer_reprogram(struct hrti if (hrtimer_callback_running(timer)) return 0; + /* +* CLOCK_REALTIME timer might be requested with an absolute +* expiry time which is less than base->offset. Nothing wrong +* about that, just avoid to call into the tick code, which +* has now objections against negative expiry values. +*/ + if (expires.tv64 < 0) + return -ETIME; + if (expires.tv64 >= expires_next->tv64) return 0; -- -- 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/
[patch 26/38] hrtimer: fix *rmtp/restarts handling in compat_sys_nanosleep()
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Oleg Nesterov <[EMAIL PROTECTED]>
commit 416529374b4793ba2d2e97e736d108a2e0f3ef07
Spotted by Pavel Emelyanov and Alexey Dobriyan.
compat_sys_nanosleep() implicitly uses hrtimer_nanosleep_restart(), this can't
work. Make a suitable compat_nanosleep_restart() helper.
Introduced by commit c70878b4e0b6cf8d2f1e46319e48e821ef4a8aba
hrtimer: hook compat_sys_nanosleep up to high res timer code
Also, set ->addr_limit = KERNEL_DS before doing hrtimer_nanosleep(), this func
was changed by the previous patch and now takes the "__user *" parameter.
Thanks to Ingo Molnar for fixing the bug in this patch.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: Pavel Emelyanov <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Toyo Abe <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/compat.c | 44
1 file changed, 40 insertions(+), 4 deletions(-)
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -40,10 +40,36 @@ int put_compat_timespec(const struct tim
__put_user(ts->tv_nsec, >tv_nsec)) ? -EFAULT : 0;
}
+static long compat_nanosleep_restart(struct restart_block *restart)
+{
+ struct compat_timespec __user *rmtp;
+ struct timespec rmt;
+ mm_segment_t oldfs;
+ long ret;
+
+ rmtp = (struct compat_timespec __user *)(restart->arg1);
+ restart->arg1 = (unsigned long)
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+ ret = hrtimer_nanosleep_restart(restart);
+ set_fs(oldfs);
+
+ if (ret) {
+ restart->fn = compat_nanosleep_restart;
+ restart->arg1 = (unsigned long)rmtp;
+
+ if (rmtp && put_compat_timespec(, rmtp))
+ return -EFAULT;
+ }
+
+ return ret;
+}
+
asmlinkage long compat_sys_nanosleep(struct compat_timespec __user *rqtp,
struct compat_timespec __user *rmtp)
{
struct timespec tu, rmt;
+ mm_segment_t oldfs;
long ret;
if (get_compat_timespec(, rqtp))
@@ -52,11 +78,21 @@ asmlinkage long compat_sys_nanosleep(str
if (!timespec_valid())
return -EINVAL;
- ret = hrtimer_nanosleep(, rmtp ? : NULL, HRTIMER_MODE_REL,
- CLOCK_MONOTONIC);
+ oldfs = get_fs();
+ set_fs(KERNEL_DS);
+ ret = hrtimer_nanosleep(,
+ rmtp ? (struct timespec __user *) : NULL,
+ HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+ set_fs(oldfs);
+
+ if (ret) {
+ struct restart_block *restart
+ = _thread_info()->restart_block;
+
+ restart->fn = compat_nanosleep_restart;
+ restart->arg1 = (unsigned long)rmtp;
- if (ret && rmtp) {
- if (put_compat_timespec(, rmtp))
+ if (rmtp && put_compat_timespec(, rmtp))
return -EFAULT;
}
--
--
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/
[patch 27/38] SLUB: Deal with annoying gcc warning on kfree()
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Christoph Lameter <[EMAIL PROTECTED]>
patch 5bb983b0cce9b7b281af15730f7019116dd42568 in mainline.
gcc 4.2 spits out an annoying warning if one casts a const void *
pointer to a void * pointer. No warning is generated if the
conversion is done through an assignment.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
mm/slub.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2592,6 +2592,7 @@ EXPORT_SYMBOL(ksize);
void kfree(const void *x)
{
struct page *page;
+ void *object = (void *)x;
if (unlikely(ZERO_OR_NULL_PTR(x)))
return;
@@ -2601,7 +2602,7 @@ void kfree(const void *x)
put_page(page);
return;
}
- slab_free(page->slab, page, (void *)x, __builtin_return_address(0));
+ slab_free(page->slab, page, object, __builtin_return_address(0));
}
EXPORT_SYMBOL(kfree);
--
--
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/
[patch 25/38] hrtimer: fix *rmtp handling in hrtimer_nanosleep()
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Oleg Nesterov <[EMAIL PROTECTED]>
commit 080344b98805553f9b01de0f59a41b1533036d8d
Spotted by Pavel Emelyanov and Alexey Dobriyan.
hrtimer_nanosleep() sets restart_block->arg1 = rmtp, but this rmtp points to
the local variable which lives in the caller's stack frame. This means that
if sys_restart_syscall() actually happens and it is interrupted as well, we
don't update the user-space variable, but write into the already dead stack
frame.
Introduced by commit 04c227140fed77587432667a574b14736a06dd7f
hrtimer: Rework hrtimer_nanosleep to make sys_compat_nanosleep easier
Change the callers to pass "__user *rmtp" to hrtimer_nanosleep(), and change
hrtimer_nanosleep() to use copy_to_user() to actually update *rmtp.
Small problem remains. man 2 nanosleep states that *rtmp should be written if
nanosleep() was interrupted (it says nothing whether it is OK to update *rmtp
if nanosleep returns 0), but (with or without this patch) we can dirty *rem
even if nanosleep() returns 0.
NOTE: this patch doesn't change compat_sys_nanosleep(), because it has other
bugs. Fixed by the next patch.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Alexey Dobriyan <[EMAIL PROTECTED]>
Cc: Michael Kerrisk <[EMAIL PROTECTED]>
Cc: Pavel Emelyanov <[EMAIL PROTECTED]>
Cc: Peter Zijlstra <[EMAIL PROTECTED]>
Cc: Toyo Abe <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/linux/hrtimer.h |2 -
kernel/hrtimer.c| 51 +---
kernel/posix-timers.c | 17 ++--
3 files changed, 31 insertions(+), 39 deletions(-)
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -300,7 +300,7 @@ hrtimer_forward(struct hrtimer *timer, k
/* Precise sleep: */
extern long hrtimer_nanosleep(struct timespec *rqtp,
- struct timespec *rmtp,
+ struct timespec __user *rmtp,
const enum hrtimer_mode mode,
const clockid_t clockid);
extern long hrtimer_nanosleep_restart(struct restart_block *restart_block);
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1291,11 +1291,26 @@ static int __sched do_nanosleep(struct h
return t->task == NULL;
}
+static int update_rmtp(struct hrtimer *timer, struct timespec __user *rmtp)
+{
+ struct timespec rmt;
+ ktime_t rem;
+
+ rem = ktime_sub(timer->expires, timer->base->get_time());
+ if (rem.tv64 <= 0)
+ return 0;
+ rmt = ktime_to_timespec(rem);
+
+ if (copy_to_user(rmtp, , sizeof(*rmtp)))
+ return -EFAULT;
+
+ return 1;
+}
+
long __sched hrtimer_nanosleep_restart(struct restart_block *restart)
{
struct hrtimer_sleeper t;
- struct timespec *rmtp;
- ktime_t time;
+ struct timespec __user *rmtp;
restart->fn = do_no_restart_syscall;
@@ -1305,12 +1320,11 @@ long __sched hrtimer_nanosleep_restart(s
if (do_nanosleep(, HRTIMER_MODE_ABS))
return 0;
- rmtp = (struct timespec *)restart->arg1;
+ rmtp = (struct timespec __user *)restart->arg1;
if (rmtp) {
- time = ktime_sub(t.timer.expires, t.timer.base->get_time());
- if (time.tv64 <= 0)
- return 0;
- *rmtp = ktime_to_timespec(time);
+ int ret = update_rmtp(, rmtp);
+ if (ret <= 0)
+ return ret;
}
restart->fn = hrtimer_nanosleep_restart;
@@ -1319,12 +1333,11 @@ long __sched hrtimer_nanosleep_restart(s
return -ERESTART_RESTARTBLOCK;
}
-long hrtimer_nanosleep(struct timespec *rqtp, struct timespec *rmtp,
+long hrtimer_nanosleep(struct timespec *rqtp, struct timespec __user *rmtp,
const enum hrtimer_mode mode, const clockid_t clockid)
{
struct restart_block *restart;
struct hrtimer_sleeper t;
- ktime_t rem;
hrtimer_init(, clockid, mode);
t.timer.expires = timespec_to_ktime(*rqtp);
@@ -1336,10 +1349,9 @@ long hrtimer_nanosleep(struct timespec *
return -ERESTARTNOHAND;
if (rmtp) {
- rem = ktime_sub(t.timer.expires, t.timer.base->get_time());
- if (rem.tv64 <= 0)
- return 0;
- *rmtp = ktime_to_timespec(rem);
+ int ret = update_rmtp(, rmtp);
+ if (ret <= 0)
+ return ret;
}
restart = _thread_info()->restart_block;
@@ -1355,8 +1367,7 @@ long hrtimer_nanosleep(struct timespec *
asmlinkage long
sys_nanosleep(struct timespec __user *rqtp, struct timespec __user *rmtp)
{
- struct timespec tu, rmt;
- int ret;
+ struct timespec tu;
[patch 24/38] Disable G5 NAP mode during SMU commands on U3
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
patch 592a607bbc053bc6f614a0e619326009f4b3829e in mainline.
It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time while waiting for an SMU command to complete,
then the SMU will fail. It could be related to the weird backward
mechanism the SMU uses to get to system memory via i2c to the
northbridge that doesn't operate properly when the said bridge is
in napping along with the CPU. That is on U3 at least, U4 doesn't
seem to be affected.
This didn't show before NO_HZ as the timer wakeup was enough to make
it work it seems, but that is no longer the case.
This fixes it by disabling NAP mode on those machines while
an SMU command is in flight.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/powermac/feature.c | 11 ++-
drivers/macintosh/smu.c | 25 -
include/asm-powerpc/pmac_feature.h|8
3 files changed, 42 insertions(+), 2 deletions(-)
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2565,6 +2565,8 @@ static void __init probe_uninorth(void)
/* Locate core99 Uni-N */
uninorth_node = of_find_node_by_name(NULL, "uni-n");
+ uninorth_maj = 1;
+
/* Locate G5 u3 */
if (uninorth_node == NULL) {
uninorth_node = of_find_node_by_name(NULL, "u3");
@@ -2575,8 +2577,10 @@ static void __init probe_uninorth(void)
uninorth_node = of_find_node_by_name(NULL, "u4");
uninorth_maj = 4;
}
- if (uninorth_node == NULL)
+ if (uninorth_node == NULL) {
+ uninorth_maj = 0;
return;
+ }
addrp = of_get_property(uninorth_node, "reg", NULL);
if (addrp == NULL)
@@ -3029,3 +3033,8 @@ void pmac_resume_agp_for_card(struct pci
pmac_agp_resume(pmac_agp_bridge);
}
EXPORT_SYMBOL(pmac_resume_agp_for_card);
+
+int pmac_get_uninorth_variant(void)
+{
+ return uninorth_maj;
+}
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -85,6 +85,7 @@ struct smu_device {
u32 cmd_buf_abs;/* command buffer absolute */
struct list_headcmd_list;
struct smu_cmd *cmd_cur; /* pending command */
+ int broken_nap;
struct list_headcmd_i2c_list;
struct smu_i2c_cmd *cmd_i2c_cur; /* pending i2c command */
struct timer_list i2c_timer;
@@ -135,6 +136,19 @@ static void smu_start_cmd(void)
fend = faddr + smu->cmd_buf->length + 2;
flush_inval_dcache_range(faddr, fend);
+
+ /* We also disable NAP mode for the duration of the command
+* on U3 based machines.
+* This is slightly racy as it can be written back to 1 by a sysctl
+* but that never happens in practice. There seem to be an issue with
+* U3 based machines such as the iMac G5 where napping for the
+* whole duration of the command prevents the SMU from fetching it
+* from memory. This might be related to the strange i2c based
+* mechanism the SMU uses to access memory.
+*/
+ if (smu->broken_nap)
+ powersave_nap = 0;
+
/* This isn't exactly a DMA mapping here, I suspect
* the SMU is actually communicating with us via i2c to the
* northbridge or the CPU to access RAM.
@@ -211,6 +225,10 @@ static irqreturn_t smu_db_intr(int irq,
misc = cmd->misc;
mb();
cmd->status = rc;
+
+ /* Re-enable NAP mode */
+ if (smu->broken_nap)
+ powersave_nap = 1;
bail:
/* Start next command if any */
smu_start_cmd();
@@ -461,7 +479,7 @@ int __init smu_init (void)
if (np == NULL)
return -ENODEV;
- printk(KERN_INFO "SMU driver %s %s\n", VERSION, AUTHOR);
+ printk(KERN_INFO "SMU: Driver %s %s\n", VERSION, AUTHOR);
if (smu_cmdbuf_abs == 0) {
printk(KERN_ERR "SMU: Command buffer not allocated !\n");
@@ -533,6 +551,11 @@ int __init smu_init (void)
goto fail;
}
+ /* U3 has an issue with NAP mode when issuing SMU commands */
+ smu->broken_nap = pmac_get_uninorth_variant() < 4;
+ if (smu->broken_nap)
+ printk(KERN_INFO "SMU: using NAP mode workaround\n");
+
sys_ctrler = SYS_CTRLER_SMU;
return 0;
--- a/include/asm-powerpc/pmac_feature.h
+++ b/include/asm-powerpc/pmac_feature.h
@@ -392,6 +392,14 @@ extern u32 __iomem *uninorth_base;
#define UN_BIS(r,v)(UN_OUT((r), UN_IN(r) | (v)))
#define UN_BIC(r,v)(UN_OUT((r), UN_IN(r) & ~(v)))
+/*
[patch 23/38] Be more robust about bad arguments in get_user_pages()
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
From: Jonathan Corbet <[EMAIL PROTECTED]>
patch 900cf086fd2fbad07f72f4575449e0d0958f860f in mainline.
So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how could a failure to check for
*read* access turn into a root exploit? It turns out that it's a buffer
overflow problem which is made easy by the way get_user_pages() is
coded.
In particular, "len" is a signed int, and it is only checked at the
*end* of a do {} while() loop. So, if it is passed in as zero, the loop
will execute once and decrement len to -1. At that point, the loop will
proceed until the next invalid address is found; in the process, it will
likely overflow the pages array passed in to get_user_pages().
I think that, if get_user_pages() has been asked to grab zero pages,
that's what it should do. Thus this patch; it is, among other things,
enough to block the (already fixed) root exploit and any others which
might be lurking in similar code. I also think that the number of pages
should be unsigned, but changing the prototype of this function probably
requires some more careful review.
Signed-off-by: Jonathan Corbet <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
mm/memory.c |2 ++
1 file changed, 2 insertions(+)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -980,6 +980,8 @@ int get_user_pages(struct task_struct *t
int i;
unsigned int vm_flags;
+ if (len <= 0)
+ return 0;
/*
* Require read or write permissions.
* If 'force' is set, we only require the "MAY" flags.
--
--
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/
[patch 22/38] AUDIT: Increase skb->truesize in audit_expand
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 406a1d868001423c85a3165288e566e65f424fe6
The recent UDP patch exposed this bug in the audit code. It
was calling pskb_expand_head without increasing skb->truesize.
The caller of pskb_expand_head needs to do so because that function
is designed to be called in places where truesize is already fixed
and therefore it doesn't update its value.
Because the audit system is using it in a place where the truesize
has not yet been fixed, it needs to update its value manually.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Acked-by: James Morris <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/audit.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1200,13 +1200,17 @@ struct audit_buffer *audit_log_start(str
static inline int audit_expand(struct audit_buffer *ab, int extra)
{
struct sk_buff *skb = ab->skb;
- int ret = pskb_expand_head(skb, skb_headroom(skb), extra,
- ab->gfp_mask);
+ int oldtail = skb_tailroom(skb);
+ int ret = pskb_expand_head(skb, 0, extra, ab->gfp_mask);
+ int newtail = skb_tailroom(skb);
+
if (ret < 0) {
audit_log_lost("out of memory in audit_expand");
return 0;
}
- return skb_tailroom(skb);
+
+ skb->truesize += newtail - oldtail;
+ return newtail;
}
/*
--
--
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/
[patch 20/38] INET: Prevent out-of-sync truesize on ip_fragment slow path
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 29ffe1a5c52dae13b6efead97aab9b058f38fce4
When ip_fragment has to hit the slow path the value of skb->truesize
may go out of sync because we would have updated it without changing
the packet length. This violates the constraints on truesize.
This patch postpones the update of skb->truesize to prevent this.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/ip_output.c |4 +++-
net/ipv6/ip6_output.c |4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -462,6 +462,7 @@ int ip_fragment(struct sk_buff *skb, int
if (skb_shinfo(skb)->frag_list) {
struct sk_buff *frag;
int first_len = skb_pagelen(skb);
+ int truesizes = 0;
if (first_len - hlen > mtu ||
((first_len - hlen) & 7) ||
@@ -485,7 +486,7 @@ int ip_fragment(struct sk_buff *skb, int
sock_hold(skb->sk);
frag->sk = skb->sk;
frag->destructor = sock_wfree;
- skb->truesize -= frag->truesize;
+ truesizes += frag->truesize;
}
}
@@ -496,6 +497,7 @@ int ip_fragment(struct sk_buff *skb, int
frag = skb_shinfo(skb)->frag_list;
skb_shinfo(skb)->frag_list = NULL;
skb->data_len = first_len - skb_headlen(skb);
+ skb->truesize -= truesizes;
skb->len = first_len;
iph->tot_len = htons(first_len);
iph->frag_off = htons(IP_MF);
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -609,6 +609,7 @@ static int ip6_fragment(struct sk_buff *
if (skb_shinfo(skb)->frag_list) {
int first_len = skb_pagelen(skb);
+ int truesizes = 0;
if (first_len - hlen > mtu ||
((first_len - hlen) & 7) ||
@@ -631,7 +632,7 @@ static int ip6_fragment(struct sk_buff *
sock_hold(skb->sk);
frag->sk = skb->sk;
frag->destructor = sock_wfree;
- skb->truesize -= frag->truesize;
+ truesizes += frag->truesize;
}
}
@@ -662,6 +663,7 @@ static int ip6_fragment(struct sk_buff *
first_len = skb_pagelen(skb);
skb->data_len = first_len - skb_headlen(skb);
+ skb->truesize -= truesizes;
skb->len = first_len;
ipv6_hdr(skb)->payload_len = htons(first_len -
sizeof(struct ipv6hdr));
--
--
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/
[patch 21/38] BLUETOOTH: Add conn add/del workqueues to avoid connection fail.
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: b6c0632105f7d7548f1d642ba830088478d4f2b0
The bluetooth hci_conn sysfs add/del executed in the default
workqueue. If the del_conn is executed after the new add_conn with
same target, add_conn will failed with warning of "same kobject name".
Here add btaddconn & btdelconn workqueues, flush the btdelconn
workqueue in the add_conn function to avoid the issue.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/bluetooth/hci_sysfs.c | 48 +++---
1 file changed, 37 insertions(+), 11 deletions(-)
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -12,6 +12,8 @@
#undef BT_DBG
#define BT_DBG(D...)
#endif
+static struct workqueue_struct *btaddconn;
+static struct workqueue_struct *btdelconn;
static inline char *typetostr(int type)
{
@@ -279,6 +281,7 @@ static void add_conn(struct work_struct
struct hci_conn *conn = container_of(work, struct hci_conn, work);
int i;
+ flush_workqueue(btdelconn);
if (device_add(>dev) < 0) {
BT_ERR("Failed to register connection device");
return;
@@ -313,6 +316,7 @@ void hci_conn_add_sysfs(struct hci_conn
INIT_WORK(>work, add_conn);
+ queue_work(btaddconn, >work);
schedule_work(>work);
}
@@ -349,6 +353,7 @@ void hci_conn_del_sysfs(struct hci_conn
INIT_WORK(>work, del_conn);
+ queue_work(btdelconn, >work);
schedule_work(>work);
}
@@ -398,31 +403,52 @@ int __init bt_sysfs_init(void)
{
int err;
+ btaddconn = create_singlethread_workqueue("btaddconn");
+ if (!btaddconn) {
+ err = -ENOMEM;
+ goto out;
+ }
+ btdelconn = create_singlethread_workqueue("btdelconn");
+ if (!btdelconn) {
+ err = -ENOMEM;
+ goto out_del;
+ }
+
bt_platform = platform_device_register_simple("bluetooth", -1, NULL, 0);
- if (IS_ERR(bt_platform))
- return PTR_ERR(bt_platform);
+ if (IS_ERR(bt_platform)) {
+ err = PTR_ERR(bt_platform);
+ goto out_platform;
+ }
err = bus_register(_bus);
- if (err < 0) {
- platform_device_unregister(bt_platform);
- return err;
- }
+ if (err < 0)
+ goto out_bus;
bt_class = class_create(THIS_MODULE, "bluetooth");
if (IS_ERR(bt_class)) {
- bus_unregister(_bus);
- platform_device_unregister(bt_platform);
- return PTR_ERR(bt_class);
+ err = PTR_ERR(bt_class);
+ goto out_class;
}
return 0;
+
+out_class:
+ bus_unregister(_bus);
+out_bus:
+ platform_device_unregister(bt_platform);
+out_platform:
+ destroy_workqueue(btdelconn);
+out_del:
+ destroy_workqueue(btaddconn);
+out:
+ return err;
}
void bt_sysfs_cleanup(void)
{
+ destroy_workqueue(btaddconn);
+ destroy_workqueue(btdelconn);
class_destroy(bt_class);
-
bus_unregister(_bus);
-
platform_device_unregister(bt_platform);
}
--
--
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/
[patch 18/38] IPCOMP: Fetch nexthdr before ipch is destroyed
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 2614fa59fa805cd488083c5602eb48533cdbc018
When I moved the nexthdr setting out of IPComp I accidently moved
the reading of ipch->nexthdr after the decompression. Unfortunately
this means that we'd be reading from a stale ipch pointer which
doesn't work very well.
This patch moves the reading up so that we get the correct nexthdr
value.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/ipcomp.c |5 -
net/ipv6/ipcomp6.c |5 -
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -74,6 +74,7 @@ out:
static int ipcomp_input(struct xfrm_state *x, struct sk_buff *skb)
{
+ int nexthdr;
int err = -ENOMEM;
struct ip_comp_hdr *ipch;
@@ -84,13 +85,15 @@ static int ipcomp_input(struct xfrm_stat
/* Remove ipcomp header and decompress original payload */
ipch = (void *)skb->data;
+ nexthdr = ipch->nexthdr;
+
skb->transport_header = skb->network_header + sizeof(*ipch);
__skb_pull(skb, sizeof(*ipch));
err = ipcomp_decompress(x, skb);
if (err)
goto out;
- err = ipch->nexthdr;
+ err = nexthdr;
out:
return err;
--- a/net/ipv6/ipcomp6.c
+++ b/net/ipv6/ipcomp6.c
@@ -64,6 +64,7 @@ static LIST_HEAD(ipcomp6_tfms_list);
static int ipcomp6_input(struct xfrm_state *x, struct sk_buff *skb)
{
+ int nexthdr;
int err = -ENOMEM;
struct ip_comp_hdr *ipch;
int plen, dlen;
@@ -79,6 +80,8 @@ static int ipcomp6_input(struct xfrm_sta
/* Remove ipcomp header and decompress original payload */
ipch = (void *)skb->data;
+ nexthdr = ipch->nexthdr;
+
skb->transport_header = skb->network_header + sizeof(*ipch);
__skb_pull(skb, sizeof(*ipch));
@@ -108,7 +111,7 @@ static int ipcomp6_input(struct xfrm_sta
skb->truesize += dlen - plen;
__skb_put(skb, dlen - plen);
skb_copy_to_linear_data(skb, scratch, dlen);
- err = ipch->nexthdr;
+ err = nexthdr;
out_put_cpu:
put_cpu();
--
--
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/
[patch 19/38] INET_DIAG: Fix inet_diag_lock_handler error path.
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 8cf8e5a67fb07f583aac94482ba51a7930dab493
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=9825
The inet_diag_lock_handler function uses ERR_PTR to encode errors but
its callers were testing against NULL.
This only happens when the only inet_diag modular user, DCCP, is not
built into the kernel or available as a module.
Also there was a problem with not dropping the mutex lock when a handler
was not found, also fixed in this patch.
This caused an OOPS and ss would then hang on subsequent calls, as
_diag_table_mutex was being left locked.
Thanks to spike at ml.yaroslavl.ru for report it after trying 'ss -d'
on a kernel that doesn't have DCCP available.
This bug was introduced in cset
d523a328fb0271e1a763e985a21f2488fd816e7e ("Fix inet_diag dead-lock
regression"), after 2.6.24-rc3, so just 2.6.24 seems to be affected.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Acked-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/inet_diag.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -259,8 +259,10 @@ static int inet_diag_get_exact(struct sk
const struct inet_diag_handler *handler;
handler = inet_diag_lock_handler(nlh->nlmsg_type);
- if (!handler)
- return -ENOENT;
+ if (IS_ERR(handler)) {
+ err = PTR_ERR(handler);
+ goto unlock;
+ }
hashinfo = handler->idiag_hashinfo;
err = -EINVAL;
@@ -708,8 +710,8 @@ static int inet_diag_dump(struct sk_buff
struct inet_hashinfo *hashinfo;
handler = inet_diag_lock_handler(cb->nlh->nlmsg_type);
- if (!handler)
- goto no_handler;
+ if (IS_ERR(handler))
+ goto unlock;
hashinfo = handler->idiag_hashinfo;
@@ -838,7 +840,6 @@ done:
cb->args[2] = num;
unlock:
inet_diag_unlock_handler(handler);
-no_handler:
return skb->len;
}
--
--
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/
[patch 17/38] IPCOMP: Fix reception of incompressible packets
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: b1641064a3f4a58644bc2e8edf40c025c58473b4
I made a silly typo by entering IPPROTO_IP (== 0) instead of
IPPROTO_IPIP (== 4). This broke the reception of incompressible
packets.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/xfrm4_tunnel.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/xfrm4_tunnel.c
+++ b/net/ipv4/xfrm4_tunnel.c
@@ -50,7 +50,7 @@ static struct xfrm_type ipip_type = {
static int xfrm_tunnel_rcv(struct sk_buff *skb)
{
- return xfrm4_rcv_spi(skb, IPPROTO_IP, ip_hdr(skb)->saddr);
+ return xfrm4_rcv_spi(skb, IPPROTO_IPIP, ip_hdr(skb)->saddr);
}
static int xfrm_tunnel_err(struct sk_buff *skb, u32 info)
--
--
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/
[patch 14/38] NET: Add if_addrlabel.h to sanitized headers.
2.6.24-stable review patch. If anyone has any objections, please let us know. -- Upstream commit: dded91611a728d65721cdab3dd41d801a356fa15 if_addrlabel.h is needed for iproute2 usage. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- include/linux/Kbuild |1 + 1 file changed, 1 insertion(+) --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -217,6 +217,7 @@ unifdef-y += i2o-dev.h unifdef-y += icmp.h unifdef-y += icmpv6.h unifdef-y += if_addr.h +unifdef-y += if_addrlabel.h unifdef-y += if_arp.h unifdef-y += if_bridge.h unifdef-y += if_ec.h -- -- 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/
[patch 15/38] IPV4: fib_trie: apply fixes from fib_hash
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 936f6f8e1bc46834bbb3e3fa3ac13ab44f1e7ba6
Update fib_trie with some fib_hash fixes:
- check for duplicate alternative routes for prefix+tos+priority when
replacing route
- properly insert by matching tos together with priority
- fix alias walking to use list_for_each_entry_continue for insertion
and deletion when fa_head is not NULL
- copy state from fa to new_fa on replace (not a problem for now)
- additionally, avoid replacement without error if new route is same,
as Joonwoo Park suggests.
Signed-off-by: Julian Anastasov <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/fib_trie.c | 57
1 file changed, 36 insertions(+), 21 deletions(-)
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1203,20 +1203,45 @@ static int fn_trie_insert(struct fib_tab
* and we need to allocate a new one of those as well.
*/
- if (fa && fa->fa_info->fib_priority == fi->fib_priority) {
- struct fib_alias *fa_orig;
+ if (fa && fa->fa_tos == tos &&
+ fa->fa_info->fib_priority == fi->fib_priority) {
+ struct fib_alias *fa_first, *fa_match;
err = -EEXIST;
if (cfg->fc_nlflags & NLM_F_EXCL)
goto out;
+ /* We have 2 goals:
+* 1. Find exact match for type, scope, fib_info to avoid
+* duplicate routes
+* 2. Find next 'fa' (or head), NLM_F_APPEND inserts before it
+*/
+ fa_match = NULL;
+ fa_first = fa;
+ fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, fa_head, fa_list) {
+ if (fa->fa_tos != tos)
+ break;
+ if (fa->fa_info->fib_priority != fi->fib_priority)
+ break;
+ if (fa->fa_type == cfg->fc_type &&
+ fa->fa_scope == cfg->fc_scope &&
+ fa->fa_info == fi) {
+ fa_match = fa;
+ break;
+ }
+ }
+
if (cfg->fc_nlflags & NLM_F_REPLACE) {
struct fib_info *fi_drop;
u8 state;
- if (fi->fib_treeref > 1)
+ fa = fa_first;
+ if (fa_match) {
+ if (fa == fa_match)
+ err = 0;
goto out;
-
+ }
err = -ENOBUFS;
new_fa = kmem_cache_alloc(fn_alias_kmem, GFP_KERNEL);
if (new_fa == NULL)
@@ -1228,7 +1253,7 @@ static int fn_trie_insert(struct fib_tab
new_fa->fa_type = cfg->fc_type;
new_fa->fa_scope = cfg->fc_scope;
state = fa->fa_state;
- new_fa->fa_state &= ~FA_S_ACCESSED;
+ new_fa->fa_state = state & ~FA_S_ACCESSED;
list_replace_rcu(>fa_list, _fa->fa_list);
alias_free_mem_rcu(fa);
@@ -1245,20 +1270,11 @@ static int fn_trie_insert(struct fib_tab
* uses the same scope, type, and nexthop
* information.
*/
- fa_orig = fa;
- list_for_each_entry(fa, fa_orig->fa_list.prev, fa_list) {
- if (fa->fa_tos != tos)
- break;
- if (fa->fa_info->fib_priority != fi->fib_priority)
- break;
- if (fa->fa_type == cfg->fc_type &&
- fa->fa_scope == cfg->fc_scope &&
- fa->fa_info == fi) {
- goto out;
- }
- }
+ if (fa_match)
+ goto out;
+
if (!(cfg->fc_nlflags & NLM_F_APPEND))
- fa = fa_orig;
+ fa = fa_first;
}
err = -ENOENT;
if (!(cfg->fc_nlflags & NLM_F_CREATE))
@@ -1614,9 +1630,8 @@ static int fn_trie_delete(struct fib_tab
pr_debug("Deleting %08x/%d tos=%d t=%p\n", key, plen, tos, t);
fa_to_delete = NULL;
- fa_head = fa->fa_list.prev;
-
- list_for_each_entry(fa, fa_head, fa_list) {
+ fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, fa_head, fa_list) {
struct fib_info *fi = fa->fa_info;
if
[patch 16/38] IPV4: fib: fix route replacement, fib_info is shared
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: c18865f39276435abb9286f9a816cb5b66c99a00
fib_info can be shared by many route prefixes but we don't want
duplicate alternative routes for a prefix+tos+priority. Last change
was not correct to check fib_treeref because it accounts usage from
other prefixes. Additionally, avoid replacement without error if new
route is same, as Joonwoo Park suggests.
Signed-off-by: Julian Anastasov <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/ipv4/fib_hash.c | 47 +++
1 file changed, 31 insertions(+), 16 deletions(-)
--- a/net/ipv4/fib_hash.c
+++ b/net/ipv4/fib_hash.c
@@ -434,19 +434,43 @@ static int fn_hash_insert(struct fib_tab
if (fa && fa->fa_tos == tos &&
fa->fa_info->fib_priority == fi->fib_priority) {
- struct fib_alias *fa_orig;
+ struct fib_alias *fa_first, *fa_match;
err = -EEXIST;
if (cfg->fc_nlflags & NLM_F_EXCL)
goto out;
+ /* We have 2 goals:
+* 1. Find exact match for type, scope, fib_info to avoid
+* duplicate routes
+* 2. Find next 'fa' (or head), NLM_F_APPEND inserts before it
+*/
+ fa_match = NULL;
+ fa_first = fa;
+ fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, >fn_alias, fa_list) {
+ if (fa->fa_tos != tos)
+ break;
+ if (fa->fa_info->fib_priority != fi->fib_priority)
+ break;
+ if (fa->fa_type == cfg->fc_type &&
+ fa->fa_scope == cfg->fc_scope &&
+ fa->fa_info == fi) {
+ fa_match = fa;
+ break;
+ }
+ }
+
if (cfg->fc_nlflags & NLM_F_REPLACE) {
struct fib_info *fi_drop;
u8 state;
- if (fi->fib_treeref > 1)
+ fa = fa_first;
+ if (fa_match) {
+ if (fa == fa_match)
+ err = 0;
goto out;
-
+ }
write_lock_bh(_hash_lock);
fi_drop = fa->fa_info;
fa->fa_info = fi;
@@ -469,20 +493,11 @@ static int fn_hash_insert(struct fib_tab
* uses the same scope, type, and nexthop
* information.
*/
- fa_orig = fa;
- fa = list_entry(fa->fa_list.prev, struct fib_alias, fa_list);
- list_for_each_entry_continue(fa, >fn_alias, fa_list) {
- if (fa->fa_tos != tos)
- break;
- if (fa->fa_info->fib_priority != fi->fib_priority)
- break;
- if (fa->fa_type == cfg->fc_type &&
- fa->fa_scope == cfg->fc_scope &&
- fa->fa_info == fi)
- goto out;
- }
+ if (fa_match)
+ goto out;
+
if (!(cfg->fc_nlflags & NLM_F_APPEND))
- fa = fa_orig;
+ fa = fa_first;
}
err = -ENOENT;
--
--
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/
[patch 12/38] SELinux: Fix double free in selinux_netlbl_sock_setsid()
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: e1770d97a730ff4c3aa1775d98f4d0558390607f
As pointed out by Adrian Bunk, commit
45c950e0f839fded922ebc0bfd59b1081cc71b70 ("fix memory leak in netlabel
code") caused a double-free when security_netlbl_sid_to_secattr()
fails. This patch fixes this by removing the netlbl_secattr_destroy()
call from that function since we are already releasing the secattr
memory in selinux_netlbl_sock_setsid().
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
security/selinux/ss/services.c |1 -
1 file changed, 1 deletion(-)
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -2629,7 +2629,6 @@ int security_netlbl_sid_to_secattr(u32 s
netlbl_sid_to_secattr_failure:
POLICY_RDUNLOCK;
- netlbl_secattr_destroy(secattr);
return rc;
}
#endif /* CONFIG_NETLABEL */
--
--
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/
[patch 13/38] PKT_SCHED: ematch: oops from uninitialized variable (resend)
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 268bcca1e7b0d244afd07ea89cda672e61b0fc4a
Setting up a meta match causes a kernel OOPS because of uninitialized
elements in tree.
[ 37.322381] BUG: unable to handle kernel NULL pointer dereference at
[ 37.322381] IP: [] :em_meta:em_meta_destroy+0x17/0x80
[ 37.322381] Call Trace:
[ 37.322381] [] tcf_em_tree_destroy+0x2d/0xa0
[ 37.322381] [] tcf_em_tree_validate+0x2dc/0x4a0
[ 37.322381] [] nla_parse+0x92/0xe0
[ 37.322381] [] :cls_basic:basic_change+0x202/0x3c0
[ 37.322381] [] kmem_cache_alloc+0x67/0xa0
[ 37.322381] [] tc_ctl_tfilter+0x3b1/0x580
[ 37.322381] [] rtnetlink_rcv_msg+0x0/0x260
[ 37.322381] [] netlink_rcv_skb+0x74/0xa0
[ 37.322381] [] rtnetlink_rcv+0x18/0x20
[ 37.322381] [] netlink_unicast+0x263/0x290
[ 37.322381] [] __alloc_skb+0x96/0x160
[ 37.322381] [] netlink_sendmsg+0x274/0x340
[ 37.322381] [] sock_sendmsg+0x12b/0x140
[ 37.322381] [] autoremove_wake_function+0x0/0x30
[ 37.322381] [] autoremove_wake_function+0x0/0x30
[ 37.322381] [] sock_sendmsg+0x12b/0x140
[ 37.322381] [] zone_statistics+0xb1/0xc0
[ 37.322381] [] sys_sendmsg+0x20e/0x360
[ 37.322381] [] sockfd_lookup_light+0x41/0x80
[ 37.322381] [] handle_mm_fault+0x3eb/0x7f0
[ 37.322381] [] system_call_after_swapgs+0x7b/0x80
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/sched/ematch.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/sched/ematch.c
+++ b/net/sched/ematch.c
@@ -305,10 +305,9 @@ int tcf_em_tree_validate(struct tcf_prot
struct tcf_ematch_tree_hdr *tree_hdr;
struct tcf_ematch *em;
- if (!rta) {
- memset(tree, 0, sizeof(*tree));
+ memset(tree, 0, sizeof(*tree));
+ if (!rta)
return 0;
- }
if (rtattr_parse_nested(tb, TCA_EMATCH_TREE_MAX, rta) < 0)
goto errout;
--
--
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/
[patch 11/38] TC: oops in em_meta
2.6.24-stable review patch. If anyone has any objections, please let us
know.
--
Upstream commit: 04f217aca4d803fe72c2c54fe460d68f5233ce52
If userspace passes a unknown match index into em_meta, then
em_meta_change will return an error and the data for the match will
not be set. This then causes an null pointer dereference when the
cleanup is done in the error path via tcf_em_tree_destroy. Since the
tree structure comes kzalloc, it is initialized to NULL.
Discovered when testing a new version of tc command against an
accidental older kernel.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/sched/em_meta.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/net/sched/em_meta.c
+++ b/net/sched/em_meta.c
@@ -719,11 +719,13 @@ static int em_meta_match(struct sk_buff
static inline void meta_delete(struct meta_match *meta)
{
- struct meta_type_ops *ops = meta_type_ops(>lvalue);
+ if (meta) {
+ struct meta_type_ops *ops = meta_type_ops(>lvalue);
- if (ops && ops->destroy) {
- ops->destroy(>lvalue);
- ops->destroy(>rvalue);
+ if (ops && ops->destroy) {
+ ops->destroy(>lvalue);
+ ops->destroy(>rvalue);
+ }
}
kfree(meta);
--
--
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/
[patch 10/38] TCP: Fix a bug in strategy_allowed_congestion_control
2.6.24-stable review patch. If anyone has any objections, please let us know. -- Upstream commit: 16ca3f913001efdb6171a2781ef41c77474e3895 In strategy_allowed_congestion_control of the 2.6.24 kernel, when sysctl_string return 1 on success,it should call tcp_set_allowed_congestion_control to set the allowed congestion control.But, it don't. the sysctl_string return 1 on success, otherwise return negative, never return 0.The patch fix the problem. Signed-off-by: Shan Wei <[EMAIL PROTECTED]> Acked-by: Stephen Hemminger <[EMAIL PROTECTED]> Signed-off-by: David S. Miller <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- net/ipv4/sysctl_net_ipv4.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv4/sysctl_net_ipv4.c +++ b/net/ipv4/sysctl_net_ipv4.c @@ -248,7 +248,7 @@ static int strategy_allowed_congestion_c tcp_get_available_congestion_control(tbl.data, tbl.maxlen); ret = sysctl_string(, name, nlen, oldval, oldlenp, newval, newlen); - if (ret == 0 && newval && newlen) + if (ret == 1 && newval && newlen) ret = tcp_set_allowed_congestion_control(tbl.data); kfree(tbl.data); -- -- 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/
