Can gcc-4.0-hppa64 and gcc-4.0 be dropped for etch? My current plan is to keep gcc-4.1-hppa64 and gcc-3.4-hppa64. we can drop gcc-3.4-hppa64 as well, but will have to keep the other compilers from the GCC-3.4 package anyway. Matthias
On Fri, Oct 06, 2006 at 11:01:24AM -0700, Linus Torvalds wrote: > On Fri, 6 Oct 2006, Russell King wrote: > > > > If it's obvious and trivial, it should be easy for anyone to fix, even > > the person who broke it. Especially as there are build logs automatically > > generated for every -git tree at http://armlinux.simtec.co.uk/kautobuild/ > > Ok, I just committed a rough first cut at fixing up arm/. Could you do: git-pull git://git.parisc-linux.org/git/linux-2.6.git irq-fixes Or apply the patch below, if that's easier diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c index 9bdd019..2ece7c7 100644 --- a/arch/parisc/kernel/irq.c +++ b/arch/parisc/kernel/irq.c @@ -35,8 +35,8 @@ #include <asm/smp.h> #undef PARISC_IRQ_CR16_COUNTS -extern irqreturn_t timer_interrupt(int, void *, struct pt_regs *); -extern irqreturn_t ipi_interrupt(int, void *, struct pt_regs *); +extern irqreturn_t timer_interrupt(int, void *); +extern irqreturn_t ipi_interrupt(int, void *); #define EIEM_MASK(irq) (1UL<<(CPU_IRQ_MAX - irq))(Continue reading)
On Fri, Oct 06, 2006 at 08:54:44PM -0600, Matthew Wilcox wrote:
> git-pull git://git.parisc-linux.org/git/linux-2.6.git irq-fixes
>
> Or apply the patch below, if that's easier
And the next series of patches actually make it boot.
git-pull git://git.parisc-linux.org/git/linux-2.6.git irq-fixes
Kyle McMartin:
[PARISC] Make firmware calls irqsafe-ish...
Matthew Wilcox:
[PARISC] Use set_irq_regs
[PA-RISC] Fix boot breakage
[PARISC] pdc_init no longer exists
[PARISC] More pt_regs removal
arch/parisc/kernel/drivers.c | 6 -
arch/parisc/kernel/firmware.c | 250 +++++++++++++++++++++++++-----------------
arch/parisc/kernel/irq.c | 3
arch/parisc/kernel/smp.c | 15 --
arch/parisc/kernel/time.c | 32 ++---
include/asm-parisc/pdc.h | 2
6 files changed, 177 insertions(+), 131 deletions(-)
Enable HIL configuration options on HP300 Signed-Off-By: Kars de Jong <jongk <at> linux-m68k.org> Signed-Off-By: Geert Uytterhoeven <geert <at> linux-m68k.org> --- keyboard/Kconfig | 4 ++-- misc/Kconfig | 2 +- mouse/Kconfig | 2 +- serio/Kconfig | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) --- linux/drivers/input/keyboard/Kconfig 2005/06/18 16:15:57 1.1.1.12 +++ linux/drivers/input/keyboard/Kconfig 2005/08/29 19:17:44 1.2 @@ -154,7 +154,7 @@ config KEYBOARD_AMIGA config KEYBOARD_HIL_OLD tristate "HP HIL keyboard support (simple driver)" - depends on GSC + depends on GSC || HP300 default y help The "Human Interface Loop" is a older, 8-channel USB-like @@ -171,7 +171,7 @@ config KEYBOARD_HIL_OLD config KEYBOARD_HIL tristate "HP HIL keyboard support" - depends on GSC + depends on GSC || HP300 default y(Continue reading)
Hi, A few months back, there was some discussion about increasing MAX_ARG_PAGES (http://thread.gmane.org/gmane.linux.kernel/418858). Since this is a problem which Google seems to bump into on a regular basis -- we just keep jacking up the limit -- I thought I'd have a stab at implementing the preferred solution as outlined by Linus. I've attached a patch which replaces the pages array from the linux_binprm struct with a stack vm_area added to the new process's mm_struct. The region grows using the normal page fault / stack extension mechanism. Since the vm_area is swappable -- which I've confirmed via testing -- we don't have to worry about memory starvation. I've tested this on the um/i386, i386, and x86_64 architectures with the elf and script binfmts. I'd like to get feedback from the Linux community. If anyone would like to test/implement the areas I've missed, I'd greatly appreciate it. Some outstanding issues / concerns: - I haven't addressed the CONFIG_STACK_GROWSUP (parisc) case. Would someone on the parisc list be willing to have a go at this? Grant Grundler has offered to provide me access to hardware, but I'd prefer to let a pa-risc guru have a go. - I haven't tested this on a NOMMU architecture. Could someone please validate this?(Continue reading)
On Tue, 2006-10-10 at 17:05 -0700, Ollie Wild wrote: on first sight it looks like you pin the entire userspace buffer at the same time (but I can misread the code; this stuff is a bit of a spaghetti by nature); that would be a DoS scenario if true... -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com
On Tue, 2006-10-10 at 17:05 -0700, Ollie Wild wrote:
> + vma->vm_flags &= ~VM_EXEC;
> + // FIXME: Are the next two lines sufficient, or do I need to
> + // do some additional magic?
> + vma->vm_flags |= mm->def_flags;
> + vma->vm_page_prot = protection_map[vma->vm_flags & 0x7];
Yeah, you'll need to change the PTEs for those pages you created by
calling get_user_page() by calling an mprotect like function; perhaps
something like:
struct vm_area_struct *prev;
unsigned long vm_flags = vma->vm_flags;
s/vma->vm_flags/vm_flags/g
err = mprotect_fixup(vma, &prev, vma->vm_start, vma->vm_end, vm_flags);
BUG_ON(prev != vma);
mprotect_fixup will then set the new protection on all PTEs and update
vma->vm_flags and vma->vm_page_prot.
> + /* Move stack pages down in memory. */
> + if (stack_shift) {
> + // FIXME: Verify the shift is OK.
> +
What exactly are you wondering about? the call to move_vma looks sane to
me
(Continue reading)
> on first sight it looks like you pin the entire userspace buffer at the > same time (but I can misread the code; this stuff is a bit of a > spaghetti by nature); that would be a DoS scenario if true... I'm not sure I understand. Could you please elaborate? Thanks, Ollie
> Yeah, you'll need to change the PTEs for those pages you created by
> calling get_user_page() by calling an mprotect like function; perhaps
> something like:
Thanks. I've incorporated your changes (updated patch attached).
> > + /* Move stack pages down in memory. */
> > + if (stack_shift) {
> > + // FIXME: Verify the shift is OK.
> > +
>
> What exactly are you wondering about? the call to move_vma looks sane to
> me
My concern was that the binfmt handler may have setup other vm areas
which overlap the new range. The move_vma() function doesn't do
overlap checking. I'm not sure if this is something I need to guard
against, or if it falls in the "Don't do that!" category.
Ollie
On Fri, Oct 06, 2006 at 01:56:00AM +0200, Matthias Klose wrote: > Can gcc-4.0-hppa64 and gcc-4.0 be dropped for etch? I don't recall seeing any other opinions on this one: Yes > My current plan is > to keep gcc-4.1-hppa64 and gcc-3.4-hppa64. we can drop gcc-3.4-hppa64 > as well, but will have to keep the other compilers from the GCC-3.4 > package anyway. I'm pretty comfortable with gcc-4.1-hppa64 for kernel builds. I haven't tested any kernels built in the past couple of weeks but I know it worked for me in August. thanks grant
RSS Feed10 | |
|---|---|
1 | |
11 | |
11 | |
62 | |
52 | |
56 | |
91 | |
133 | |
151 | |
52 | |
43 | |
225 | |
124 | |
138 | |
15 | |
28 | |
8 | |
15 | |
7 | |
32 | |
63 | |
24 | |
42 | |
229 | |
48 | |
10 | |
57 | |
16 | |
32 | |
42 | |
58 | |
3 | |
3 | |
28 | |
28 | |
2 |
