linux-kernel - Re: Unify common parts of i8259.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 May 2008 22:47:50 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@...e.cz>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, macro@....pg.gda.pl
Subject: Re: Unify common parts of i8259.c


* Pavel Machek <pavel@...e.cz> wrote:

> Merge common parts of i8259_{32,64} into i8259.c.

hm, did you intend this to be a 'mechanic' (i.e. no functionality 
changes expected) unification?

i stuck it into -tip for testing and it caused a boot failure after a 
couple of bootups, with this config:

  http://redhat.com/~mingo/misc/config-Tue_May_20_22_15_40_CEST_2008.bad

the hang is during early bootup, after SLUB init:

  SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
  [ hard hang ]

full bootlog below. Reverting your patch fixes the bootup. The next line 
would be:

  Calibrating delay using timer specific routine.. 4023.05 BogoMIPS (lpj=8046112)

so somewhere between that and the SLUB init is it hanging.

If this change is intentionally not mechanic then please split this into 
the mechanic and non-mechanic portions, to make it all bisectable. If 
it's supposed to be mechanic then there's a bug in it - in that case a 
more gradual conversion is useful too.

We'd prefer to have 10 or 20 small commits instead one large commit - 
because in -tip we can bisect any problems to the exact change that 
caused it - while now we are left to guess about a rather large change:

   6 files changed, 347 insertions(+), 609 deletions(-)

in fact such a big change might warrant 30 or 50 small changes as well - 
the smaller the changes, the better. Such a 1000-lines change we cannot 
reasonably bisect.

	Ingo

-------------->
Linux version 2.6.26-rc3-sched-devel.git (mingo@...ne) (gcc version 4.2.2) #483 Tue May 20 22:16:05 CEST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
debug: ignoring loglevel setting.
127MB HIGHMEM available.
896MB LOWMEM available.
  early res: 0 [0-fff] BIOS data page
  early res: 1 [100000-487a8b] TEXT DATA BSS
  early res: 2 [487a8c-48afff] INIT_PG_TABLE
  early res: 3 [9f800-fffff] BIOS reserved
Entering add_active_range(0, 0, 262128) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
  HighMem    229376 ->   262128
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   262128
On node 0 totalpages: 262128
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1760 pages used for memmap
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 255 pages used for memmap
  HighMem zone: 32497 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260081
Kernel command line: root=/dev/sda1 console=ttyS0,115200 console=tty debug initcall_debug enforcing=0 apic=verbose ignore_loglevel sysrq_always_enabled selinux=0 nmi_watchdog=0
debug: sysrq always enabled.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 2010.291 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1035232k/1048512k available (1788k kernel code, 12628k reserved, 562k data, 140k init, 131008k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffee000 - 0xfffff000   (  68 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc034e000 - 0xc0371000   ( 140 kB)
      .data : 0xc02bf20c - 0xc034bcf0   ( 562 kB)
      .text : 0xc0100000 - 0xc02bf20c   (1788 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ hard hang ]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/