with latest -git (f6bccf6), -tip testing on one of my test-boxes found a
boot hang.
It just hangs during fsck, "Checking filesystems", so i suspect the
block IO changes.
Test system is ext3, athlon64, 1GB RAM, PATA - nothing fancy and very
dependable.
( i also saw a weird mount failure and panic and a weird segfault -
pointing in the direction of memory corruption. )
i'll try to narrow it down, get more debug info and possibly bisect it,
just wanted to give an advance warning that something is fishy with
-git.
This was with pure -git compiled to a bzImage, no other patches applied.
Ingo
* Ingo Molnar <[email protected]> wrote:
> with latest -git (f6bccf6), -tip testing on one of my test-boxes found
> a boot hang.
>
> It just hangs during fsck, "Checking filesystems", so i suspect the
> block IO changes.
bisection ongoing. Current bisection window:
nr of bisection commits: 128
----------------------------
ad3316b: block: Find bio sector offset given idx and offset
b02739b: block: gendisk integrity wrapper
ad7fce9: block: Switch blk_integrity_compare from bdev to gendisk
0c032ab: block: Fix double put in blk_integrity_unregister
74aa8c2: block: Introduce integrity data ownership flag
b04accc: block: revert part of d7533ad0e132f92e75c1b2eb7c26387b25a583c1
8deaf72: bio.h: Remove unused conditional code
d00e29f: block: remove end_{queued|dequeued}_request()
99cd338: block: change elevator to use __blk_end_request()
7afb3a6: gdrom: change to use __blk_end_request()
2a9df50: memstick: change to use __blk_end_request()
8316982: virtio_blk: change to use __blk_end_request()
0497b34: blktrace: use BLKTRACE_BDEV_SIZE as the name size for setup structure
ef9e3fa: block: add lld busy state exporting interface
336c3d8: block: Fix blk_start_queueing() to not kick a stopped queue
c0ddffa: include blktrace_api.h in headers_install
e3ba9ae: block: reserve some tags just for sync IO
f7d7b7a: block: as/cfq ssd idle check update
8bff7c6: libata: set queue SSD flag for SSD devices
a68bbdd: block: add queue flag for SSD/non-rotational devices
9e49184: floppy: support arbitrary first-sector numbers
061837b: drivers/block: Use DIV_ROUND_UP
905bd78: cciss: Fix cciss SCSI rescan code to better notice device changes
79eb014: fix an example of scatterlists handling in DMA-API.txt
4ee5eaf: block: add a queue flag for request stacking support
82124d6: block: add request submission interface
32fab44: block: add request update interface
e3335de: block: blk_cleanup_queue() should call blk_sync_queue()
9246b5f: block: Expand Xen blkfront for > 16 xvd
9c02f2b: block: cleanup some of the integrity stuff in blkdev.h
7ba1fba: block: use rq complete marking in blk_abort_request()
581d4e2: block: add fault injection mechanism for faking request timeouts
0a0d96b: block: add bio_kmalloc()
3e6053d: block: adjust blkdev_issue_discard for swap
4677735: sg: remove unnecessary blk_rq_unmap_user
0b6cb26: sg: remove sg_read_xfer
c3919af: sg: remove sg_write_xfer
626710c: sg: incorporate sg_build_direct into sg_start_req
44c7b0e: sg: remove __sg_start_req
fd1c1de: sg: remove b_malloc_len in sg_scatter_hold struct
7e56cb0: sg: remove SG_ALLOW_DIO_CODE define
a91a3a2: sg: rename sg_cmd_done sg_rq_end_io
224cb3e: dm: Call blk_abort_queue on failed paths
11914a5: block: Add interface to abort queued requests
242f9dc: block: unify request timeout handling
608aeef: Call flush_disk() after detecting an online resize.
56ade44: Added flush_disk to factor out common buffer cache flushing code.
f98a8ca: SCSI sd driver calls revalidate_disk wrapper.
9bc3ffb: Check for device resize when rescanning partitions
c3279d1: Adjust block device size after an online resize of a disk.
0c002c2: Wrapper for lower-level revalidate_disk routines.
243294d: block: fix duplicate headers for /proc/partitions
fad7f01: sg: set dxferp to NULL for READ with the older SG interface
8188276: block: make blk_rq_map_user take a NULL user-space buffer
839e96a: block: update comment on end_request()
55dc7db: init: DEBUG_BLOCK_EXT_DEVT requires explicit root= param
2bbedcb: block: don't test for partition size in bdget_disk() and blk_lookup_devt()
759f8ca: Change default value of CONFIG_DEBUG_BLOCK_EXT_DEVT to 'n'
aeb3d3a: block: kmalloc args reversed, small function definition fixes
01cfcdd: sg: use blk_rq_aligned helper function
8790407: block: add blk_rq_aligned helper function
4d8ab62: bio: convert bio_copy_kern to use bio_copy_user
10db10d: sg: convert the indirect IO path to use the block layer
6e5a30c: sg: convert the direct IO path to use the block layer
10865df: sg: convert the non-data path to use the block layer
152e283: block: introduce struct rq_map_data to use reserved pages
a3bce90: block: add gfp_mask argument to blk_rq_map_user and blk_rq_map_user_iov
45333d5: cfq-iosched: fix queue depth detection
6054016: block: don't use bio_has_data() in the completion path
ab780f1: block: inherit CPU completion on bio->rq and rq->rq merges
c7c22e4: block: add support for IO CPU affinity
18887ad: block: make kblockd_schedule_work() take the queue as parameter
b646fc5: block: split softirq handling into blk-softirq.c
0835da6: block: use linux/uaccess.h in elevator.c instead of asm variant
3e1a7ff: block: allow disk to have extended device number
689d6fa: block: replace @ext_minors with GENHD_FL_EXT_DEVT
540eed5: block: make partition array dynamic
074a7ac: block: move stats from disk to part0
eddb2e2: block: kill GENHD_FL_FAIL and use part0->make_it_fail
0762b8b: block: always set bdev->bd_part
4c46501: block: move holder_dir from disk to part0
b7db995: block: move policy from disk to part0
e561052: block: unify sysfs size node handling
548b10e: block: move __dev from disk to part0
80795ae: block: move capacity from disk to part0
b5d0b9d: block: introduce partition 0
ed9e198: block: implement and use {disk|part}_to_dev()
870d665: block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
f615b48: sd/ide-disk: apply extended minors to sd and ide
1f01429: block: adjust formatting for large minors and add ext_range sysfs attr
bcce3de: block: implement extended dev numbers
c995905: block: fix diskstats access
e71bf0d: block: fix disk->part[] dereferencing race
f331c02: block: don't depend on consecutive minor space
cf771cb: block: make variable and argument names more consistent
310a2c1: block: misc updates
88e3412: block: update add_partition() error handling
ec2cded: block: allow deleting zero length partition
def4e38: block: use class_dev_iterator instead of class_for_each_device()
2ac3cee: block: don't grab block_class_lock unnecessarily
ac65ece: block: fix partition info printouts
5a3ceb8: driver-core: use klist for class device list and implement iterator
a1ed5b0: klist: don't iterate over deleted entries
710027a: Add some block/ source files to the kernel-api docbook. Fix kernel-doc notation in them as needed. Fix changed function parameter names. Fix typos/spellos. In comments, change REQ_SPECIAL to REQ_TYPE_SPECIAL and REQ_BLOCK_PC to REQ_TYPE_BLOCK_PC.
5b99c2f: block: make bi_phys_segments an unsigned int instead of short
960e739: block: raid fixups for removal of bi_hw_segments
5df97b9: drop vmerge accounting
b8b3e16: block: drop virtual merging accounting
6a421c1: block: update documentation for deadline fifo_batch tunable
4fb72f7: deadline-iosched: non-functional fixes
63de428: deadline-iosched: allow non-sequential batching
766ca44: virtio_blk: use a wrapper function to access io context information of IO requests
1a8e2bd: Kill REQ_TYPE_FLUSH
e17fc0a: Allow elevators to sort/merge discard requests
d30a260: Add BLKDISCARD ioctl to allow userspace to discard sectors
2ebca85: Use WRITE_BARRIER in blkdev_issue_flush(), not (1<<BIO_RW_BARRIER)
35ba8f7: blktrace: simplify flags handling in __blk_add_trace
27b29e8: blktrace: support discard requests
fdc5397: Support 'discard sectors' operation.
eae9acd: Support 'discard sectors' operation in translation layer support core
8c540a9: Let the block device know when sectors can be discarded
fb2dce8: Add 'discard' request handling
d628eae: Fix up comments about matching flags between bio and rq
3614407: highmem: use bio_has_data() in the bounce path
051cc39: block: use bio_has_data() in the IO completion path
a9c701e: block: use bio_has_data() to check for data carrying bio
7a67f63: block: add bio_has_data() to detect whether a bio carries data or not
35e396c: SG_IO block filter whitelist missing MMC SET READ AHEAD command
so definitely block IO related it appears.
Ingo
> bisection ongoing. [...]
the result is:
# bad: [f6bccf69] Merge git://git.kernel.org/pub/scm/linux/kernel/gi
# good: [3fa8749e] Linux 2.6.27
# good: [d403a648] Merge phase #1 of git://git.kernel.org/pub/scm/lin
# bad: [ad3316bf] block: Find bio sector offset given idx and offset
# bad: [10865dfa] sg: convert the non-data path to use the block lay
# good: [88e34126] block: update add_partition() error handling
# bad: [4c46501d] block: move holder_dir from disk to part0
# good: [f615b48c] sd/ide-disk: apply extended minors to sd and ide
# bad: [80795aef] block: move capacity from disk to part0
# bad: [ed9e1982] block: implement and use {disk|part}_to_dev()
# bad: [870d6656] block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
| 870d6656126add8e383645732b03df2b7ccd4f94 is first bad commit
| commit 870d6656126add8e383645732b03df2b7ccd4f94
| Author: Tejun Heo <[email protected]>
| Date: Mon Aug 25 19:47:25 2008 +0900
|
| block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
and meanwhile 2 other test-systems failed to boot as well - both have
CONFIG_DEBUG_BLOCK_EXT_DEVT=y.
So i guess this debug feature is working as expected.
I guess we should mark CONFIG_DEBUG_BLOCK_EXT_DEVT=y as really dangerous
to enable because contemporary distributions (i tried Fedora 9) fail
with it too?
Ingo
On Fri, 10 Oct 2008, Ingo Molnar wrote:
>
> | 870d6656126add8e383645732b03df2b7ccd4f94 is first bad commit
> | commit 870d6656126add8e383645732b03df2b7ccd4f94
> | Author: Tejun Heo <[email protected]>
> | Date: Mon Aug 25 19:47:25 2008 +0900
> |
> | block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
>
> and meanwhile 2 other test-systems failed to boot as well - both have
> CONFIG_DEBUG_BLOCK_EXT_DEVT=y.
>
> So i guess this debug feature is working as expected.
Ahh, yeah, sounds that way.
> I guess we should mark CONFIG_DEBUG_BLOCK_EXT_DEVT=y as really dangerous
> to enable because contemporary distributions (i tried Fedora 9) fail
> with it too?
Tejun - do you know whether _any_ distro will boot with
CONFIG_DEBUG_BLOCK_EXT_DEVT=y?
It does sound like perhaps the option should be hidden more, if it's
really only reasonably enabled for some very specialized distro debuggers,
not normal kernel people.
Linus
Hello,
Linus Torvalds wrote:
> On Fri, 10 Oct 2008, Ingo Molnar wrote:
>> | 870d6656126add8e383645732b03df2b7ccd4f94 is first bad commit
>> | commit 870d6656126add8e383645732b03df2b7ccd4f94
>> | Author: Tejun Heo <[email protected]>
>> | Date: Mon Aug 25 19:47:25 2008 +0900
>> |
>> | block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
>>
>> and meanwhile 2 other test-systems failed to boot as well - both have
>> CONFIG_DEBUG_BLOCK_EXT_DEVT=y.
>>
>> So i guess this debug feature is working as expected.
>
> Ahh, yeah, sounds that way.
>
>> I guess we should mark CONFIG_DEBUG_BLOCK_EXT_DEVT=y as really dangerous
>> to enable because contemporary distributions (i tried Fedora 9) fail
>> with it too?
>
> Tejun - do you know whether _any_ distro will boot with
> CONFIG_DEBUG_BLOCK_EXT_DEVT=y?
Hmmm... openSUSE 11.0 didn't have any problem with it, which I was a bit
pleasantly surprised about. I haven't tested management tools but the
base system worked just fine.
> It does sound like perhaps the option should be hidden more, if it's
> really only reasonably enabled for some very specialized distro debuggers,
> not normal kernel people.
Yeap, if fedora didn't work, I think it should be hidden. Do we already
have place to hide things like this?
Thanks.
--
tejun
Tejun Heo wrote:
>
> Yeap, if fedora didn't work, I think it should be hidden. Do we already
> have place to hide things like this?
>
By the way, I don't see anything in this patchset that lets userspace
discover the parent device. Since the old rule of
partition device = parent device + partition number
... no longer holds, this is a serious omission for something that is in
mainstream (and therefore *requires* that a new interface is deployed
for anything that cares.)
This will have to be addressed before 2.6.28 final.
-hpa
On Sat, Oct 11 2008, Tejun Heo wrote:
> Hello,
>
> Linus Torvalds wrote:
> > On Fri, 10 Oct 2008, Ingo Molnar wrote:
> >> | 870d6656126add8e383645732b03df2b7ccd4f94 is first bad commit
> >> | commit 870d6656126add8e383645732b03df2b7ccd4f94
> >> | Author: Tejun Heo <[email protected]>
> >> | Date: Mon Aug 25 19:47:25 2008 +0900
> >> |
> >> | block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
> >>
> >> and meanwhile 2 other test-systems failed to boot as well - both have
> >> CONFIG_DEBUG_BLOCK_EXT_DEVT=y.
> >>
> >> So i guess this debug feature is working as expected.
> >
> > Ahh, yeah, sounds that way.
> >
> >> I guess we should mark CONFIG_DEBUG_BLOCK_EXT_DEVT=y as really dangerous
> >> to enable because contemporary distributions (i tried Fedora 9) fail
> >> with it too?
> >
> > Tejun - do you know whether _any_ distro will boot with
> > CONFIG_DEBUG_BLOCK_EXT_DEVT=y?
>
> Hmmm... openSUSE 11.0 didn't have any problem with it, which I was a bit
> pleasantly surprised about. I haven't tested management tools but the
> base system worked just fine.
10.3 worked here too, and iirc the ubuntu on my laptop did too. It's
been a month or so since I tested though, so...
> > It does sound like perhaps the option should be hidden more, if it's
> > really only reasonably enabled for some very specialized distro debuggers,
> > not normal kernel people.
>
> Yeap, if fedora didn't work, I think it should be hidden. Do we already
> have place to hide things like this?
Agree, lets make it more of an effort to enable, it should not be
something that the casual user comes across and thinks it would
interesting to try. Or at least make it clear from the help text that
this may result in a non-booting system on some distros.
--
Jens Axboe
* Tejun Heo <[email protected]> wrote:
> > It does sound like perhaps the option should be hidden more, if it's
> > really only reasonably enabled for some very specialized distro
> > debuggers, not normal kernel people.
>
> Yeap, if fedora didn't work, I think it should be hidden. Do we
> already have place to hide things like this?
in my local testing i'm using simple annotations like the one attached
further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
upstream, and merge my annotations for various kernel features that
break a generic distro bootup?
Right now i have about 40 such annotations for -tip testing:
fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
security/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
and note the stark contrast to CONFIG_BROKEN - sometimes a given
functionality is really not meant to be enabled on a generic system.
Ingo
---------------->
Subject: qa: no ext devt
From: Ingo Molnar <[email protected]>
Date: Fri Oct 10 22:54:57 CEST 2008
Signed-off-by: Ingo Molnar <[email protected]>
---
lib/Kconfig.debug | 2 ++
1 file changed, 2 insertions(+)
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
bool "Force extended block device numbers and spread them"
depends on DEBUG_KERNEL
depends on BLOCK
+ depends on BROKEN_BOOT_ALLOWED
+ select BROKEN_BOOT
default n
help
Conventionally, block device numbers are allocated from
On Sat, Oct 11 2008, Ingo Molnar wrote:
>
> * Tejun Heo <[email protected]> wrote:
>
> > > It does sound like perhaps the option should be hidden more, if it's
> > > really only reasonably enabled for some very specialized distro
> > > debuggers, not normal kernel people.
> >
> > Yeap, if fedora didn't work, I think it should be hidden. Do we
> > already have place to hide things like this?
>
> in my local testing i'm using simple annotations like the one attached
> further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
> upstream, and merge my annotations for various kernel features that
> break a generic distro bootup?
>
> Right now i have about 40 such annotations for -tip testing:
>
> fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> security/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
> lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
> lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
>
> and note the stark contrast to CONFIG_BROKEN - sometimes a given
> functionality is really not meant to be enabled on a generic system.
>
> Ingo
>
> ---------------->
> Subject: qa: no ext devt
> From: Ingo Molnar <[email protected]>
> Date: Fri Oct 10 22:54:57 CEST 2008
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> lib/Kconfig.debug | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux/lib/Kconfig.debug
> ===================================================================
> --- linux.orig/lib/Kconfig.debug
> +++ linux/lib/Kconfig.debug
> @@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
> bool "Force extended block device numbers and spread them"
> depends on DEBUG_KERNEL
> depends on BLOCK
> + depends on BROKEN_BOOT_ALLOWED
> + select BROKEN_BOOT
> default n
> help
> Conventionally, block device numbers are allocated from
What is BROKEN_BOOT_ALLOWED? Honestly, I'd prefer to just put an extra
2-3 line paragraph in the help entry, saying that it's quite possible
that current distros wont boot with this testing code enabled. Since it
default to 'n', people should read the entry before turning it on
anyway.
--
Jens Axboe
* Jens Axboe <[email protected]> wrote:
> On Sat, Oct 11 2008, Ingo Molnar wrote:
> >
> > * Tejun Heo <[email protected]> wrote:
> >
> > > > It does sound like perhaps the option should be hidden more, if it's
> > > > really only reasonably enabled for some very specialized distro
> > > > debuggers, not normal kernel people.
> > >
> > > Yeap, if fedora didn't work, I think it should be hidden. Do we
> > > already have place to hide things like this?
> >
> > in my local testing i'm using simple annotations like the one attached
> > further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
> > upstream, and merge my annotations for various kernel features that
> > break a generic distro bootup?
> >
> > Right now i have about 40 such annotations for -tip testing:
> >
> > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > security/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
> > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
> >
> > and note the stark contrast to CONFIG_BROKEN - sometimes a given
> > functionality is really not meant to be enabled on a generic system.
> >
> > Ingo
> >
> > ---------------->
> > Subject: qa: no ext devt
> > From: Ingo Molnar <[email protected]>
> > Date: Fri Oct 10 22:54:57 CEST 2008
> >
> > Signed-off-by: Ingo Molnar <[email protected]>
> > ---
> > lib/Kconfig.debug | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > Index: linux/lib/Kconfig.debug
> > ===================================================================
> > --- linux.orig/lib/Kconfig.debug
> > +++ linux/lib/Kconfig.debug
> > @@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
> > bool "Force extended block device numbers and spread them"
> > depends on DEBUG_KERNEL
> > depends on BLOCK
> > + depends on BROKEN_BOOT_ALLOWED
> > + select BROKEN_BOOT
> > default n
> > help
> > Conventionally, block device numbers are allocated from
>
> What is BROKEN_BOOT_ALLOWED? Honestly, I'd prefer to just put an extra
> 2-3 line paragraph in the help entry, saying that it's quite possible
> that current distros wont boot with this testing code enabled. Since
> it default to 'n', people should read the entry before turning it on
> anyway.
well, the extra BROKEN_BOOT_ALLOWED helps my automated test-setup to
decide whether a .config that it's testing (either sent by a reporter or
generated randomly) can be booted.
If CONFIG_BROKEN_BOOT_ALLOWED=y, then i allow config options that can
break the bootup. In that case, and _if_ such a possibly-boot-breaking
config option is enabled, CONFIG_BROKEN_BOOT is set - which my scripts
detect.
This gives the test harness the highest flexibility and annotates those
kernel features / drivers which can result in a (possibly) broken
bootup. The scripts cannot read help entries.
Ingo
On Sat, Oct 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[email protected]> wrote:
>
> > On Sat, Oct 11 2008, Ingo Molnar wrote:
> > >
> > > * Tejun Heo <[email protected]> wrote:
> > >
> > > > > It does sound like perhaps the option should be hidden more, if it's
> > > > > really only reasonably enabled for some very specialized distro
> > > > > debuggers, not normal kernel people.
> > > >
> > > > Yeap, if fedora didn't work, I think it should be hidden. Do we
> > > > already have place to hide things like this?
> > >
> > > in my local testing i'm using simple annotations like the one attached
> > > further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
> > > upstream, and merge my annotations for various kernel features that
> > > break a generic distro bootup?
> > >
> > > Right now i have about 40 such annotations for -tip testing:
> > >
> > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > security/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
> > > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
> > >
> > > and note the stark contrast to CONFIG_BROKEN - sometimes a given
> > > functionality is really not meant to be enabled on a generic system.
> > >
> > > Ingo
> > >
> > > ---------------->
> > > Subject: qa: no ext devt
> > > From: Ingo Molnar <[email protected]>
> > > Date: Fri Oct 10 22:54:57 CEST 2008
> > >
> > > Signed-off-by: Ingo Molnar <[email protected]>
> > > ---
> > > lib/Kconfig.debug | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > Index: linux/lib/Kconfig.debug
> > > ===================================================================
> > > --- linux.orig/lib/Kconfig.debug
> > > +++ linux/lib/Kconfig.debug
> > > @@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
> > > bool "Force extended block device numbers and spread them"
> > > depends on DEBUG_KERNEL
> > > depends on BLOCK
> > > + depends on BROKEN_BOOT_ALLOWED
> > > + select BROKEN_BOOT
> > > default n
> > > help
> > > Conventionally, block device numbers are allocated from
> >
> > What is BROKEN_BOOT_ALLOWED? Honestly, I'd prefer to just put an extra
> > 2-3 line paragraph in the help entry, saying that it's quite possible
> > that current distros wont boot with this testing code enabled. Since
> > it default to 'n', people should read the entry before turning it on
> > anyway.
>
> well, the extra BROKEN_BOOT_ALLOWED helps my automated test-setup to
> decide whether a .config that it's testing (either sent by a reporter or
> generated randomly) can be booted.
>
> If CONFIG_BROKEN_BOOT_ALLOWED=y, then i allow config options that can
> break the bootup. In that case, and _if_ such a possibly-boot-breaking
> config option is enabled, CONFIG_BROKEN_BOOT is set - which my scripts
> detect.
>
> This gives the test harness the highest flexibility and annotates those
> kernel features / drivers which can result in a (possibly) broken
> bootup. The scripts cannot read help entries.
OK, makes sense to me then, thanks. I was afraid it was some user
exposed parameter, in which case it sounded... interesting :-)
For users, we just need to expand the help entry a bit.
--
Jens Axboe
* Jens Axboe <[email protected]> wrote:
> On Sat, Oct 11 2008, Ingo Molnar wrote:
> >
> > * Jens Axboe <[email protected]> wrote:
> >
> > > On Sat, Oct 11 2008, Ingo Molnar wrote:
> > > >
> > > > * Tejun Heo <[email protected]> wrote:
> > > >
> > > > > > It does sound like perhaps the option should be hidden more, if it's
> > > > > > really only reasonably enabled for some very specialized distro
> > > > > > debuggers, not normal kernel people.
> > > > >
> > > > > Yeap, if fedora didn't work, I think it should be hidden. Do we
> > > > > already have place to hide things like this?
> > > >
> > > > in my local testing i'm using simple annotations like the one attached
> > > > further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
> > > > upstream, and merge my annotations for various kernel features that
> > > > break a generic distro bootup?
> > > >
> > > > Right now i have about 40 such annotations for -tip testing:
> > > >
> > > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > security/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
> > > > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
> > > >
> > > > and note the stark contrast to CONFIG_BROKEN - sometimes a given
> > > > functionality is really not meant to be enabled on a generic system.
> > > >
> > > > Ingo
> > > >
> > > > ---------------->
> > > > Subject: qa: no ext devt
> > > > From: Ingo Molnar <[email protected]>
> > > > Date: Fri Oct 10 22:54:57 CEST 2008
> > > >
> > > > Signed-off-by: Ingo Molnar <[email protected]>
> > > > ---
> > > > lib/Kconfig.debug | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > Index: linux/lib/Kconfig.debug
> > > > ===================================================================
> > > > --- linux.orig/lib/Kconfig.debug
> > > > +++ linux/lib/Kconfig.debug
> > > > @@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
> > > > bool "Force extended block device numbers and spread them"
> > > > depends on DEBUG_KERNEL
> > > > depends on BLOCK
> > > > + depends on BROKEN_BOOT_ALLOWED
> > > > + select BROKEN_BOOT
> > > > default n
> > > > help
> > > > Conventionally, block device numbers are allocated from
> > >
> > > What is BROKEN_BOOT_ALLOWED? Honestly, I'd prefer to just put an extra
> > > 2-3 line paragraph in the help entry, saying that it's quite possible
> > > that current distros wont boot with this testing code enabled. Since
> > > it default to 'n', people should read the entry before turning it on
> > > anyway.
> >
> > well, the extra BROKEN_BOOT_ALLOWED helps my automated test-setup to
> > decide whether a .config that it's testing (either sent by a reporter or
> > generated randomly) can be booted.
> >
> > If CONFIG_BROKEN_BOOT_ALLOWED=y, then i allow config options that can
> > break the bootup. In that case, and _if_ such a possibly-boot-breaking
> > config option is enabled, CONFIG_BROKEN_BOOT is set - which my scripts
> > detect.
> >
> > This gives the test harness the highest flexibility and annotates those
> > kernel features / drivers which can result in a (possibly) broken
> > bootup. The scripts cannot read help entries.
>
> OK, makes sense to me then, thanks. I was afraid it was some user
> exposed parameter, in which case it sounded... interesting :-)
>
> For users, we just need to expand the help entry a bit.
We could perhaps rename it to:
CONFIG_ALLOW_NON_GENERIC_FEATURES=y
?
It's usually things like ISA drivers or very specific hardware support
that falls into this category - none of our major features or drivers,
so you should not be worried about any limitation effects of such a
feature. The help text does not help me much in that case, it was not me
who enabled that option, i just want to use a .config from some other
person and want to reproduce a bugreport. I do that almost on a daily
basis.
And this CONFIG_ALLOW_NON_GENERIC_FEATURES=y option could even be
exposed to users. I have three first-hand usecases for it:
First usecase: when i get a .config from a tester and want to test-boot
it on a box, i dont want to spend hours of .config bisection just to
find out that it has a driver enabled that is known to break generic
boxes. Yes, this has happened to me in the past.
The second usecase where i utilize it is random kernel testing: there
randconfig is what enables drivers, not me, so the help text does not
help much.
Third usecase: where i just accidentally enable something i should not
have enabled. It's nice to have tools around that can protect me from
such mistakes. This too has happened to me.
So i find it very convenient that i can just disable
CONFIG_ALLOW_NON_GENERIC_FEATURES - which automatically disables all
possibly-broken functionality.
Ingo
On Sat, Oct 11 2008, Ingo Molnar wrote:
>
> * Jens Axboe <[email protected]> wrote:
>
> > On Sat, Oct 11 2008, Ingo Molnar wrote:
> > >
> > > * Jens Axboe <[email protected]> wrote:
> > >
> > > > On Sat, Oct 11 2008, Ingo Molnar wrote:
> > > > >
> > > > > * Tejun Heo <[email protected]> wrote:
> > > > >
> > > > > > > It does sound like perhaps the option should be hidden more, if it's
> > > > > > > really only reasonably enabled for some very specialized distro
> > > > > > > debuggers, not normal kernel people.
> > > > > >
> > > > > > Yeap, if fedora didn't work, I think it should be hidden. Do we
> > > > > > already have place to hide things like this?
> > > > >
> > > > > in my local testing i'm using simple annotations like the one attached
> > > > > further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
> > > > > upstream, and merge my annotations for various kernel features that
> > > > > break a generic distro bootup?
> > > > >
> > > > > Right now i have about 40 such annotations for -tip testing:
> > > > >
> > > > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > security/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
> > > > > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > > > lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > > > arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
> > > > >
> > > > > and note the stark contrast to CONFIG_BROKEN - sometimes a given
> > > > > functionality is really not meant to be enabled on a generic system.
> > > > >
> > > > > Ingo
> > > > >
> > > > > ---------------->
> > > > > Subject: qa: no ext devt
> > > > > From: Ingo Molnar <[email protected]>
> > > > > Date: Fri Oct 10 22:54:57 CEST 2008
> > > > >
> > > > > Signed-off-by: Ingo Molnar <[email protected]>
> > > > > ---
> > > > > lib/Kconfig.debug | 2 ++
> > > > > 1 file changed, 2 insertions(+)
> > > > >
> > > > > Index: linux/lib/Kconfig.debug
> > > > > ===================================================================
> > > > > --- linux.orig/lib/Kconfig.debug
> > > > > +++ linux/lib/Kconfig.debug
> > > > > @@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
> > > > > bool "Force extended block device numbers and spread them"
> > > > > depends on DEBUG_KERNEL
> > > > > depends on BLOCK
> > > > > + depends on BROKEN_BOOT_ALLOWED
> > > > > + select BROKEN_BOOT
> > > > > default n
> > > > > help
> > > > > Conventionally, block device numbers are allocated from
> > > >
> > > > What is BROKEN_BOOT_ALLOWED? Honestly, I'd prefer to just put an extra
> > > > 2-3 line paragraph in the help entry, saying that it's quite possible
> > > > that current distros wont boot with this testing code enabled. Since
> > > > it default to 'n', people should read the entry before turning it on
> > > > anyway.
> > >
> > > well, the extra BROKEN_BOOT_ALLOWED helps my automated test-setup to
> > > decide whether a .config that it's testing (either sent by a reporter or
> > > generated randomly) can be booted.
> > >
> > > If CONFIG_BROKEN_BOOT_ALLOWED=y, then i allow config options that can
> > > break the bootup. In that case, and _if_ such a possibly-boot-breaking
> > > config option is enabled, CONFIG_BROKEN_BOOT is set - which my scripts
> > > detect.
> > >
> > > This gives the test harness the highest flexibility and annotates those
> > > kernel features / drivers which can result in a (possibly) broken
> > > bootup. The scripts cannot read help entries.
> >
> > OK, makes sense to me then, thanks. I was afraid it was some user
> > exposed parameter, in which case it sounded... interesting :-)
> >
> > For users, we just need to expand the help entry a bit.
>
> We could perhaps rename it to:
>
> CONFIG_ALLOW_NON_GENERIC_FEATURES=y
>
> ?
Hmm dunno, that option name still doesn't really tell me what the heck
it's about...
> It's usually things like ISA drivers or very specific hardware support
> that falls into this category - none of our major features or drivers,
> so you should not be worried about any limitation effects of such a
> feature. The help text does not help me much in that case, it was not me
> who enabled that option, i just want to use a .config from some other
> person and want to reproduce a bugreport. I do that almost on a daily
> basis.
Nope, for you the help text does not do anything. So I do agree that
having a config option helps that particular case.
> And this CONFIG_ALLOW_NON_GENERIC_FEATURES=y option could even be
> exposed to users. I have three first-hand usecases for it:
>
> First usecase: when i get a .config from a tester and want to test-boot
> it on a box, i dont want to spend hours of .config bisection just to
> find out that it has a driver enabled that is known to break generic
> boxes. Yes, this has happened to me in the past.
>
> The second usecase where i utilize it is random kernel testing: there
> randconfig is what enables drivers, not me, so the help text does not
> help much.
>
> Third usecase: where i just accidentally enable something i should not
> have enabled. It's nice to have tools around that can protect me from
> such mistakes. This too has happened to me.
>
> So i find it very convenient that i can just disable
> CONFIG_ALLOW_NON_GENERIC_FEATURES - which automatically disables all
> possibly-broken functionality.
There's still a multitude of ways you could get a broken kernel, but you
have a LOT more experience in this automated testing area so I'll take
you word for it...
--
Jens Axboe
CONFIG_DEBUG_BLOCK_EXT_DEVT can break booting even on some modern
distros. Add BIG FAT WARNING to keep people at a safe distance.
Signed-off-by: Tejun Heo <[email protected]>
---
Okay, w/ or w/o Ingo's change, it would be worthwhile to warn
people more clearly so that we can at least say 'told ya'. :-)
lib/Kconfig.debug | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index aa81d28..44e67a1 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -652,6 +652,11 @@ config DEBUG_BLOCK_EXT_DEVT
depends on BLOCK
default n
help
+ BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
+ SOME DISTRIBUTIONS. DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
+ YOU ARE DOING. Distros, please enable this and fix whatever
+ is broken.
+
Conventionally, block device numbers are allocated from
predetermined contiguous area. However, extended block area
may introduce non-contiguous block device numbers. This
At Sat, 11 Oct 2008 09:50:19 +0900,
Tejun Heo wrote:
>
> Hello,
>
> Linus Torvalds wrote:
> > On Fri, 10 Oct 2008, Ingo Molnar wrote:
> >> | 870d6656126add8e383645732b03df2b7ccd4f94 is first bad commit
> >> | commit 870d6656126add8e383645732b03df2b7ccd4f94
> >> | Author: Tejun Heo <[email protected]>
> >> | Date: Mon Aug 25 19:47:25 2008 +0900
> >> |
> >> | block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT
> >>
> >> and meanwhile 2 other test-systems failed to boot as well - both have
> >> CONFIG_DEBUG_BLOCK_EXT_DEVT=y.
> >>
> >> So i guess this debug feature is working as expected.
> >
> > Ahh, yeah, sounds that way.
> >
> >> I guess we should mark CONFIG_DEBUG_BLOCK_EXT_DEVT=y as really dangerous
> >> to enable because contemporary distributions (i tried Fedora 9) fail
> >> with it too?
> >
> > Tejun - do you know whether _any_ distro will boot with
> > CONFIG_DEBUG_BLOCK_EXT_DEVT=y?
>
> Hmmm... openSUSE 11.0 didn't have any problem with it, which I was a bit
> pleasantly surprised about. I haven't tested management tools but the
> base system worked just fine.
FYI, even on openSUSE 11.0, it gets a problem when you run mkinitrd on
the kernel with CONFIG_DEBUG_BLOCK_EXT_DEVT=y. It's a problem of SUSE
mkinitrd, though.
Takashi
On Mon, Oct 13 2008, Tejun Heo wrote:
> CONFIG_DEBUG_BLOCK_EXT_DEVT can break booting even on some modern
> distros. Add BIG FAT WARNING to keep people at a safe distance.
>
> Signed-off-by: Tejun Heo <[email protected]>
> ---
> Okay, w/ or w/o Ingo's change, it would be worthwhile to warn
> people more clearly so that we can at least say 'told ya'. :-)
>
> lib/Kconfig.debug | 5 +++++
> 1 file changed, 5 insertions(+)
Agree, this looks appropriate. I'll add it.
--
Jens Axboe
H. Peter Anvin wrote:
> Tejun Heo wrote:
>>
>> Yeap, if fedora didn't work, I think it should be hidden. Do we already
>> have place to hide things like this?
>>
>
> By the way, I don't see anything in this patchset that lets userspace
> discover the parent device. Since the old rule of
>
> partition device = parent device + partition number
>
> ... no longer holds, this is a serious omission for something that is in
> mainstream (and therefore *requires* that a new interface is deployed
> for anything that cares.)
>
> This will have to be addressed before 2.6.28 final.
The sysfs directory for the parent can be reached by "cd -P
/sys/class/block/PART/..". That should be enough, right? I'll add
the partition attribute but I don't really think we need to do
anything to improve parent discovery.
Thanks.
--
tejun
With extended devt, finding out the partition number becomes a bit
more challenging as subtracting the minor number from that of the
parent device doesn't work anymore. The only thing left is parsing
the partition name which is brittle and not exactly universal (some
have '-' between the device name and partition number while others
don't). This patch introduced partition attribute which contains the
partition number of the device. This should make finding partitions
and its index easier.
This problem and solution were suggested by H. Peter Anvin.
Signed-off-by: Tejun Heo <[email protected]>
Cc: H. Peter Anvin <[email protected]>
---
fs/partitions/check.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/partitions/check.c b/fs/partitions/check.c
index 7408227..4684a49 100644
--- a/fs/partitions/check.c
+++ b/fs/partitions/check.c
@@ -195,6 +195,14 @@ check_partition(struct gendisk *hd, struct block_device *bdev)
return ERR_PTR(res);
}
+static ssize_t part_partition_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct hd_struct *p = dev_to_part(dev);
+
+ return sprintf(buf, "%d\n", p->partno);
+}
+
static ssize_t part_start_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -260,6 +268,7 @@ ssize_t part_fail_store(struct device *dev,
}
#endif
+static DEVICE_ATTR(partition, S_IRUGO, part_partition_show, NULL);
static DEVICE_ATTR(start, S_IRUGO, part_start_show, NULL);
static DEVICE_ATTR(size, S_IRUGO, part_size_show, NULL);
static DEVICE_ATTR(stat, S_IRUGO, part_stat_show, NULL);
@@ -269,6 +278,7 @@ static struct device_attribute dev_attr_fail =
#endif
static struct attribute *part_attrs[] = {
+ &dev_attr_partition.attr,
&dev_attr_start.attr,
&dev_attr_size.attr,
&dev_attr_stat.attr,
On Mon, Oct 13 2008, Tejun Heo wrote:
> With extended devt, finding out the partition number becomes a bit
> more challenging as subtracting the minor number from that of the
> parent device doesn't work anymore. The only thing left is parsing
> the partition name which is brittle and not exactly universal (some
> have '-' between the device name and partition number while others
> don't). This patch introduced partition attribute which contains the
> partition number of the device. This should make finding partitions
> and its index easier.
>
> This problem and solution were suggested by H. Peter Anvin.
Applied to for-linus
--
Jens Axboe
On Sat, 2008-10-11 at 09:19 +0200, Ingo Molnar wrote:
> * Tejun Heo <[email protected]> wrote:
>
> > > It does sound like perhaps the option should be hidden more, if it's
> > > really only reasonably enabled for some very specialized distro
> > > debuggers, not normal kernel people.
> >
> > Yeap, if fedora didn't work, I think it should be hidden. Do we
> > already have place to hide things like this?
>
> in my local testing i'm using simple annotations like the one attached
> further below. Any objections against sending my BROKEN_BOOT_ALLOWED kit
> upstream, and merge my annotations for various kernel features that
> break a generic distro bootup?
>
> Right now i have about 40 such annotations for -tip testing:
>
> fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> security/Kconfig: depends on BROKEN_BOOT_ALLOWED
What in particular under fs/Kconfig and security/*Kconfig falls into
this category, and why? What constitutes a "generic distro bootup"?
For distros that support SELinux, it obviously shouldn't break the
bootup (there have of course been cases where it has, but those were
bugs that have been addressed, including the recent /proc/net breakage),
and for other distros, it should yield no effect as no policy will be
loaded and thus SELinux just allows everything.
> drivers/net/appletalk/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/net/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/media/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/scsi/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/watchdog/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/ide/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/i2c/busses/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/block/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/video/console/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/mtd/Kconfig: depends on BROKEN_BOOT_ALLOWED
> drivers/isdn/icn/Kconfig: depends on BROKEN_BOOT_ALLOWED
> lib/Kconfig.kgdb: depends on BROKEN_BOOT_ALLOWED
> lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> lib/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig.debug: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: # depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig: depends on BROKEN_BOOT_ALLOWED
> arch/x86/Kconfig.cpu: depends on BROKEN_BOOT_ALLOWED
>
> and note the stark contrast to CONFIG_BROKEN - sometimes a given
> functionality is really not meant to be enabled on a generic system.
>
> Ingo
>
> ---------------->
> Subject: qa: no ext devt
> From: Ingo Molnar <[email protected]>
> Date: Fri Oct 10 22:54:57 CEST 2008
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> lib/Kconfig.debug | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux/lib/Kconfig.debug
> ===================================================================
> --- linux.orig/lib/Kconfig.debug
> +++ linux/lib/Kconfig.debug
> @@ -670,6 +670,8 @@ config DEBUG_BLOCK_EXT_DEVT
> bool "Force extended block device numbers and spread them"
> depends on DEBUG_KERNEL
> depends on BLOCK
> + depends on BROKEN_BOOT_ALLOWED
> + select BROKEN_BOOT
> default n
> help
> Conventionally, block device numbers are allocated from
>
> --
> 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/
--
Stephen Smalley
National Security Agency
* Stephen Smalley <[email protected]> wrote:
> > Right now i have about 40 such annotations for -tip testing:
> >
> > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > security/Kconfig: depends on BROKEN_BOOT_ALLOWED
>
> What in particular under fs/Kconfig and security/*Kconfig falls into
> this category, and why? What constitutes a "generic distro bootup"?
> For distros that support SELinux, it obviously shouldn't break the
> bootup (there have of course been cases where it has, but those were
> bugs that have been addressed, including the recent /proc/net
> breakage), and for other distros, it should yield no effect as no
> policy will be loaded and thus SELinux just allows everything.
got this one for rootplug:
--- linux.orig/security/Kconfig
+++ linux/security/Kconfig
@@ -93,6 +93,11 @@ config SECURITY_FILE_CAPABILITIES
config SECURITY_ROOTPLUG
bool "Root Plug Support"
depends on USB=y && SECURITY
+
+ # fails with hard-to-debug "could not find init" boot failure
+ depends on BROKEN_BOOT_ALLOWED
+ select BROKEN_BOOT
and this one:
--- linux.orig/security/selinux/Kconfig
+++ linux/security/selinux/Kconfig
@@ -97,6 +97,11 @@ config SECURITY_SELINUX_CHECKREQPROT_VAL
config SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT
bool "NSA SELinux enable new secmark network controls by default"
depends on SECURITY_SELINUX
+
+ # old system booted up with this cannot ssh out
+ depends on BROKEN_BOOT_ALLOWED
+ select BROKEN_BOOT
i also have this temporary annotation:
--- linux.orig/security/smack/Kconfig
+++ linux/security/smack/Kconfig
@@ -1,6 +1,9 @@
config SECURITY_SMACK
bool "Simplified Mandatory Access Control Kernel Support"
depends on NETLABEL && SECURITY_NETWORK
+ # breaks networking (TCP connections)
+ depends on BROKEN_BOOT_ALLOWED
+ select BROKEN_BOOT
default n
help
This selects the Simplified Mandatory Access Control Kernel.
has this problem been fixed? A test is only a success if the freshly
booted kernel can autonomously ssh out over a real network and can
indicate success to the QA server. I've got a good mix of old and new
distros as well.
Ingo
On Mon, Oct 13, 2008 at 03:41:35PM +0900, Tejun Heo wrote:
> CONFIG_DEBUG_BLOCK_EXT_DEVT can break booting even on some modern
> distros. Add BIG FAT WARNING to keep people at a safe distance.
Just remove the whole "debug" code. It clutters up all block drivers with
ifdefs and doesn't actually provide any benefit.
On Tue, 2008-10-14 at 17:12 +0200, Ingo Molnar wrote:
> * Stephen Smalley <[email protected]> wrote:
>
> > > Right now i have about 40 such annotations for -tip testing:
> > >
> > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
> > > security/Kconfig: depends on BROKEN_BOOT_ALLOWED
> >
> > What in particular under fs/Kconfig and security/*Kconfig falls into
> > this category, and why? What constitutes a "generic distro bootup"?
> > For distros that support SELinux, it obviously shouldn't break the
> > bootup (there have of course been cases where it has, but those were
> > bugs that have been addressed, including the recent /proc/net
> > breakage), and for other distros, it should yield no effect as no
> > policy will be loaded and thus SELinux just allows everything.
>
> got this one for rootplug:
>
> --- linux.orig/security/Kconfig
> +++ linux/security/Kconfig
> @@ -93,6 +93,11 @@ config SECURITY_FILE_CAPABILITIES
> config SECURITY_ROOTPLUG
> bool "Root Plug Support"
> depends on USB=y && SECURITY
> +
> + # fails with hard-to-debug "could not find init" boot failure
> + depends on BROKEN_BOOT_ALLOWED
> + select BROKEN_BOOT
Makes sense - rootplug truly is "specialized".
>
> and this one:
>
> --- linux.orig/security/selinux/Kconfig
> +++ linux/security/selinux/Kconfig
> @@ -97,6 +97,11 @@ config SECURITY_SELINUX_CHECKREQPROT_VAL
> config SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT
> bool "NSA SELinux enable new secmark network controls by default"
> depends on SECURITY_SELINUX
> +
> + # old system booted up with this cannot ssh out
> + depends on BROKEN_BOOT_ALLOWED
> + select BROKEN_BOOT
What is the oldest distro you test against? This one does need to be
disabled for distros that predate the policy support for secmark, but
we'd really like to deprecate and ultimately remove the legacy network
controls from SELinux.
> i also have this temporary annotation:
>
> --- linux.orig/security/smack/Kconfig
> +++ linux/security/smack/Kconfig
> @@ -1,6 +1,9 @@
> config SECURITY_SMACK
> bool "Simplified Mandatory Access Control Kernel Support"
> depends on NETLABEL && SECURITY_NETWORK
> + # breaks networking (TCP connections)
> + depends on BROKEN_BOOT_ALLOWED
> + select BROKEN_BOOT
> default n
> help
> This selects the Simplified Mandatory Access Control Kernel.
>
> has this problem been fixed? A test is only a success if the freshly
> booted kernel can autonomously ssh out over a real network and can
> indicate success to the QA server. I've got a good mix of old and new
> distros as well.
I thought that Casey had changed Smack such that packets wouldn't be
explicitly labeled by default when they were at the default/ambient
network label and thus wouldn't break sshd.
--
Stephen Smalley
National Security Agency
Christoph Hellwig wrote:
> On Mon, Oct 13, 2008 at 03:41:35PM +0900, Tejun Heo wrote:
>> CONFIG_DEBUG_BLOCK_EXT_DEVT can break booting even on some modern
>> distros. Add BIG FAT WARNING to keep people at a safe distance.
>
> Just remove the whole "debug" code. It clutters up all block drivers with
> ifdefs and doesn't actually provide any benefit.
Well, it's mostly intended for distros so that they can enable the
option and detect places where they assume consecutive minors as
otherwise most of those will go unnoticed until some user finally tries
to use more than 16 partitions. As most distros are broken at the
moment, I'm more inclined to keep the debug option and planning on
enabling it during the next devel cycle of openSUSE and ask RH and other
distros to do the same. It adds ifdefs to ide-disk and sd, which isn't
too much. I think it would be good to keep it until at least distros
break out of the consecutive or fixed device number assumption.
Thanks.
--
tejun
Stephen Smalley wrote:
> On Tue, 2008-10-14 at 17:12 +0200, Ingo Molnar wrote:
>
>> * Stephen Smalley <[email protected]> wrote:
>>
>>
>>>> Right now i have about 40 such annotations for -tip testing:
>>>>
>>>> fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
>>>> fs/Kconfig: depends on BROKEN_BOOT_ALLOWED
>>>> security/selinux/Kconfig: depends on BROKEN_BOOT_ALLOWED
>>>> security/smack/Kconfig: depends on BROKEN_BOOT_ALLOWED
>>>> security/Kconfig: depends on BROKEN_BOOT_ALLOWED
>>>>
>>> What in particular under fs/Kconfig and security/*Kconfig falls into
>>> this category, and why? What constitutes a "generic distro bootup"?
>>> For distros that support SELinux, it obviously shouldn't break the
>>> bootup (there have of course been cases where it has, but those were
>>> bugs that have been addressed, including the recent /proc/net
>>> breakage), and for other distros, it should yield no effect as no
>>> policy will be loaded and thus SELinux just allows everything.
>>>
>> got this one for rootplug:
>>
>> --- linux.orig/security/Kconfig
>> +++ linux/security/Kconfig
>> @@ -93,6 +93,11 @@ config SECURITY_FILE_CAPABILITIES
>> config SECURITY_ROOTPLUG
>> bool "Root Plug Support"
>> depends on USB=y && SECURITY
>> +
>> + # fails with hard-to-debug "could not find init" boot failure
>> + depends on BROKEN_BOOT_ALLOWED
>> + select BROKEN_BOOT
>>
>
> Makes sense - rootplug truly is "specialized".
>
>
>> and this one:
>>
>> --- linux.orig/security/selinux/Kconfig
>> +++ linux/security/selinux/Kconfig
>> @@ -97,6 +97,11 @@ config SECURITY_SELINUX_CHECKREQPROT_VAL
>> config SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT
>> bool "NSA SELinux enable new secmark network controls by default"
>> depends on SECURITY_SELINUX
>> +
>> + # old system booted up with this cannot ssh out
>> + depends on BROKEN_BOOT_ALLOWED
>> + select BROKEN_BOOT
>>
>
> What is the oldest distro you test against? This one does need to be
> disabled for distros that predate the policy support for secmark, but
> we'd really like to deprecate and ultimately remove the legacy network
> controls from SELinux.
>
>
>> i also have this temporary annotation:
>>
>> --- linux.orig/security/smack/Kconfig
>> +++ linux/security/smack/Kconfig
>> @@ -1,6 +1,9 @@
>> config SECURITY_SMACK
>> bool "Simplified Mandatory Access Control Kernel Support"
>> depends on NETLABEL && SECURITY_NETWORK
>> + # breaks networking (TCP connections)
>> + depends on BROKEN_BOOT_ALLOWED
>> + select BROKEN_BOOT
>> default n
>> help
>> This selects the Simplified Mandatory Access Control Kernel.
>>
>> has this problem been fixed? A test is only a success if the freshly
>> booted kernel can autonomously ssh out over a real network and can
>> indicate success to the QA server. I've got a good mix of old and new
>> distros as well.
>>
>
> I thought that Casey had changed Smack such that packets wouldn't be
> explicitly labeled by default when they were at the default/ambient
> network label and thus wouldn't break sshd.
>
Stephen is correct. The fix has been in for some time.