On Thu, Feb 7, 2013 at 12:14 PM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Sedat Dilek <sedat.dilek@xxxxxxxxx> writes: > >> On Thu, Feb 7, 2013 at 11:20 AM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: >>> On Thu, Feb 7, 2013 at 10:38 AM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: >>>> On Thu, Feb 7, 2013 at 7:37 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: >>>>> Hi all, >>>>> >>>>> Changes since 20130206: >>>>> >>>>> Removed tree: kvmtool (still present via the tip tree) >>>>> >>>>> The block tree lost its build failure. >>>>> >>>>> The tip tree gained a conflict against the s390 tree. >>>>> >>>>> The kvm tree gained a conflict against Linus' tree. >>>>> >>>>> The tty tree lost its build failure. >>>>> >>>>> The arm-soc tree gained conflicts against the iommu tree. >>>>> >>>>> The signal tree gained a conflict against the s390 tree. >>>>> >>>>> The akpm tree gained a conflict against the kvm tree and lost its build >>>>> failure. >>>>> >>>>> ---------------------------------------------------------------------------- >>>>> >>>> >>>> My build-script uses fakeroot and does no more start: >>>> >>>> $ ./scripts/build_linux-next.sh >>>> make options ...... CC=gcc-4.6 -j4 >>>> KBUILD_BUILD_USER=sedat.dilek@xxxxxxxxx >>>> LOCALVERSION=-next20130207-2-iniza-small >>>> dep-pkg options ... KDEB_PKGVERSION=3.8.0~rc6~next20130207-2~iniza+dileks1 >>>> fakeroot, while creating message channels: Invalid argument >>>> This may be due to a lack of SYSV IPC support. >>>> fakeroot: error while starting the `faked' daemon. >>>> kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec >>>> ... or kill -l [sigspec] >>>> >>>> >>>> Any hints? >>>> ( I could run strace... ) >>>> >>>> - Sedat - >>> >>> Attached strace outputs within yesterday's (GOOD) and today's (BAD) Linux-Next. >>> >>> - Sedat - >> >> [ CCing Al and Eric ] >> >> I compared quickly the diff between the -next versions and saw changes >> coming from signal and userns trees. >> ( Sorry for re-attaching the strace outputs. ) > > It has been about a week and a half since I have pushed anything into > the userns tree, and I don't have anything ipc related in my tree. > So the reason for the suspicion seems odd. > > The straces are useless because all they show is that fakeroot was > forked, but there is not a trace of fakeroot itself. > > Given the timing my initial suspect would be the idr_preload patches > from Tejun that were merged via Andrew's akpm tree. I didn't see > anything in there that would kill ipc but that is likely the most recent > touch to the ipc code. > [ CCing Tejun ] Hmm, still stepping in the dark... OK, fakeroot does PRELOADing so your assumption makes sense. How can I trigger fakeroot calls? Here I have... /usr/bin/faked-sysv /usr/bin/faked-tcp I think that is the main commit but I am not sure if I can revert the idr_preload part, otherwise it gets complicated: commit e2802c2defba1e5c88d7d168eb5c66813c86f249 "idr: implement idr_preload[_end]() and idr_alloc()" $ grep idr ../Linux-Next-v20130206-VS-v20130207.diff | grep ^'++Applying:' ++Applying: block: fix ext_devt_idr handling ++Applying: idr: fix a subtle bug in idr_get_next() ++Applying: nfsd: idr_destroy() no longer needs idr_remove_all() ++Applying: idr: cosmetic updates to struct / initializer definitions ++Applying: idr: relocate idr_for_each_entry() and reorganize id[r|a]_get_new() ++Applying: idr: remove _idr_rc_to_errno() hack ++Applying: idr: refactor idr_get_new_above() ++Applying: idr: implement idr_preload[_end]() and idr_alloc() ++Applying: block: convert to idr_alloc() ++Applying: block/loop: convert to idr_alloc() ++Applying: atm/nicstar: convert to idr_alloc() ++Applying: drbd: convert to idr_alloc() ++Applying: dca: convert to idr_alloc() ++Applying: dmaengine: convert to idr_alloc() ++Applying: firewire: convert to idr_alloc() ++Applying: gpio: convert to idr_alloc() ++Applying: drm: convert to idr_alloc() ++Applying: drm/exynos: convert to idr_alloc() ++Applying: drm/i915: convert to idr_alloc() ++Applying: drm/sis: convert to idr_alloc() ++Applying: drm/via: convert to idr_alloc() ++Applying: drm/vmwgfx: convert to idr_alloc() ++Applying: i2c: convert to idr_alloc() ++Applying: IB/core: convert to idr_alloc() ++Applying: IB/amso1100: convert to idr_alloc() ++Applying: IB/cxgb3: convert to idr_alloc() ++Applying: IB/cxgb4: convert to idr_alloc() ++Applying: IB/ehca: convert to idr_alloc() ++Applying: IB/ipath: convert to idr_alloc() ++Applying: IB/mlx4: convert to idr_alloc() ++Applying: IB/ocrdma: convert to idr_alloc() ++Applying: IB/qib: convert to idr_alloc() ++Applying: dm: convert to idr_alloc() ++Applying: memstick: convert to idr_alloc() ++Applying: mfd: convert to idr_alloc() ++Applying: misc/c2port: convert to idr_alloc() ++Applying: misc/tifm_core: convert to idr_alloc() ++Applying: mmc: convert to idr_alloc() ++Applying: mtd: convert to idr_alloc() ++Applying: macvtap: convert to idr_alloc() ++Applying: ppp: convert to idr_alloc() ++Applying: power: convert to idr_alloc() ++Applying: pps: convert to idr_alloc() ++Applying: remoteproc: convert to idr_alloc() ++Applying: rpmsg: convert to idr_alloc() ++Applying: scsi/bfa: convert to idr_alloc() ++Applying: scsi: convert to idr_alloc() ++Applying: target/iscsi: convert to idr_alloc() ++Applying: scsi/lpfc: convert to idr_alloc() ++Applying: thermal: convert to idr_alloc() ++Applying: uio: convert to idr_alloc() ++Applying: vfio: convert to idr_alloc() ++Applying: dlm: convert to idr_alloc() ++Applying: inotify: convert to idr_alloc() ++Applying: ocfs2: convert to idr_alloc() ++Applying: ipc: convert to idr_alloc() ++Applying: cgroup: convert to idr_alloc() ++Applying: events: convert to idr_alloc() ++Applying: posix-timers: convert to idr_alloc() ++Applying: net/9p: convert to idr_alloc() ++Applying: mac80211: convert to idr_alloc() ++Applying: sctp: convert to idr_alloc() ++Applying: nfs4client: convert to idr_alloc() - Sedat - [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=e2802c2defba1e5c88d7d168eb5c66813c86f249 > Eric -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
