linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied
Takeo Tung
I using linux-next-20100608 kernel, but if re-complier the kernel will found
this messages.
root@kernel-x86:/usr/src/linux# make oldconfig
HOSTCC scripts/basic/fixdep
/bin/sh: scripts/basic/fixdep: Permission denied
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2
But if I revert this patch, seems all back to normal, pls help me this is
bug patch or need adjust some system config?
Thanks,
Takeo Tung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Takeo Tung
Michal Marek
> Dear All,
>
> I using linux-next-20100608 kernel, but if re-complier the kernel will
> found
> this messages.
>
> root@kernel-x86:/usr/src/linux# make oldconfig
> HOSTCC scripts/basic/fixdep
> /bin/sh: scripts/basic/fixdep: Permission denied
> make[1]: *** [scripts/basic/fixdep] Error 1
> make: *** [scripts_basic] Error 2
>
> But if I revert this patch, seems all back to normal, pls help me this is
> bug patch or need adjust some system config?
>
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=9d9b938248736826e86db9b16a3b435bdb5d649f
Do I understand it correctly that you can't rebuild your kernel if
you're running linux-next-20100608 and that the problem goes away if you
revert the above patch, recompile somewhere else and boot the new
kernel? I.e. it's unlikely a problem with fixdep itself?
Adding Christoph Hellwig to cc.
Michal
Takeo Tung
yes.
1. I complier liux-next-20100608 kernel, and boot the linux-next-20100608
kernel, and try re-complier kernel, will found this message.
/bin/sh: scripts/basic/fixdep: Permission denied
2. reboot other safe kernel, and revert the above patch, and complier it,
and boot the new kernel, seems no this error.
but I don't know why, bcoz seems code is ok.
Thanks,
Takeo Tung
--------------------------------------------------
From: "Michal Marek" <mma...@suse.cz>
Sent: Saturday, June 12, 2010 4:07 AM
To: "Takeo Tung" <ker...@takeo.idv.tw>
Cc: <linux-...@vger.kernel.org>; "Christoph Hellwig" <h...@lst.de>
Subject: Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep:
Permission denied
Christoph Hellwig
last version of the patch:
Index: linux-2.6/fs/attr.c
===================================================================
--- linux-2.6.orig/fs/attr.c 2010-06-12 11:45:50.458003839 +0200
+++ linux-2.6/fs/attr.c 2010-06-12 11:45:59.103005305 +0200
@@ -34,7 +34,7 @@ int inode_change_ok(const struct inode *
* First check size constraints. These can't be overriden using
* ATTR_FORCE.
*/
- if (attr->ia_mode & ATTR_SIZE) {
+ if (ia_valid & ATTR_SIZE) {
int error = inode_newsize_ok(inode, attr->ia_size);
if (error)
return error;
Takeo Tung
I was try this patch, seems all is normal now. thanks for your patch.
Best Regards,
Takeo Tung
--------------------------------------------------
From: "Christoph Hellwig" <h...@lst.de>
Sent: Saturday, June 12, 2010 5:49 PM
To: "Takeo Tung" <ker...@takeo.idv.tw>
Cc: "Michal Marek" <mma...@suse.cz>; <linux-...@vger.kernel.org>;
<vi...@zeniv.linux.org.uk>; <s...@canb.auug.org.au>
Subject: Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep:
Permission denied
> Please try the patch below, looks like I did a horrible messup in the
Takeo Tung
As subject, I revert the patch, seems boot is normal, but apply the patch,
kernel will panic on scsi_setup_fs_cmnd, could you can check this? bcoz I
check long time,
no found why kernel will panic.
Thanks,
Takeo Tung
Takeo Tung
I was check the patch again. I found the panic status haapen on Soft RAID 1.
I review it. found some define using bool, so some like ( x & REQ_SYNC) only
0 or 1.
so if bi_rw = rw | sync will bi_rw = rw | 0 or rw | 1. not rw | ( 1 <<
__REQ_SYNC).
So I write a patch is fix it. seems normal now. could you review the patch
or any comment?
Thanks
Takeo Tung
Signed-off-by: Takeo Tung <ker...@takeo.idv.tw>
--------
diff -urNp ./drivers/md/raid10.c.orig ./drivers/md/raid10.c
--- ./drivers/md/raid10.c.orig 2010-07-07 19:24:12.000000000 +0800
+++ ./drivers/md/raid10.c 2010-07-07 19:24:36.000000000 +0800
@@ -799,7 +799,7 @@ static int make_request(mddev_t *mddev,
int i;
int chunk_sects = conf->chunk_mask + 1;
const int rw = bio_data_dir(bio);
- const bool do_sync = (bio->bi_rw & REQ_SYNC);
+ const unsigned long do_sync = (bio->bi_rw & REQ_SYNC);
struct bio_list bl;
unsigned long flags;
mdk_rdev_t *blocked_rdev;
@@ -1716,7 +1716,7 @@ static void raid10d(mddev_t *mddev)
raid_end_bio_io(r10_bio);
bio_put(bio);
} else {
- const bool do_sync =
(r10_bio->master_bio->bi_rw & REQ_SYNC);
+ const unsigned long do_sync =
(r10_bio->master_bio->bi_rw & REQ_SYNC);
bio_put(bio);
rdev = conf->mirrors[mirror].rdev;
if (printk_ratelimit())
diff -urNp ./drivers/md/raid1.c.orig ./drivers/md/raid1.c
--- ./drivers/md/raid1.c.orig 2010-07-07 19:21:45.000000000 +0800
+++ ./drivers/md/raid1.c 2010-07-07 19:24:10.000000000 +0800
@@ -787,8 +787,8 @@ static int make_request(mddev_t *mddev,
struct bio_list bl;
struct page **behind_pages = NULL;
const int rw = bio_data_dir(bio);
- const bool do_sync = (bio->bi_rw & REQ_SYNC);
- bool do_barriers;
+ const unsigned long do_sync = (bio->bi_rw & REQ_SYNC);
+ unsigned long do_barriers;
mdk_rdev_t *blocked_rdev;
/*
@@ -1640,7 +1640,7 @@ static void raid1d(mddev_t *mddev)
* We already have a nr_pending reference on these
rdevs.
*/
int i;
- const bool do_sync = (r1_bio->master_bio->bi_rw &
REQ_SYNC);
+ const unsigned long do_sync =
(r1_bio->master_bio->bi_rw & REQ_SYNC);
clear_bit(R1BIO_BarrierRetry, &r1_bio->state);
clear_bit(R1BIO_Barrier, &r1_bio->state);
for (i=0; i < conf->raid_disks; i++)
@@ -1696,7 +1696,7 @@ static void raid1d(mddev_t *mddev)
(unsigned long long)r1_bio->sector);
raid_end_bio_io(r1_bio);
} else {
- const bool do_sync =
r1_bio->master_bio->bi_rw & REQ_SYNC;
+ const unsigned long do_sync =
r1_bio->master_bio->bi_rw & REQ_SYNC;
r1_bio->bios[r1_bio->read_disk] =
mddev->ro ? IO_BLOCKED : NULL;
r1_bio->read_disk = disk;
diff -urNp ./drivers/block/loop.c.orig ./drivers/block/loop.c
--- ./drivers/block/loop.c.orig 2010-07-07 19:21:12.000000000 +0800
+++ ./drivers/block/loop.c 2010-07-07 19:21:23.000000000 +0800
@@ -476,7 +476,7 @@ static int do_bio_filebacked(struct loop
pos = ((loff_t) bio->bi_sector << 9) + lo->lo_offset;
if (bio_rw(bio) == WRITE) {
- bool barrier = (bio->bi_rw & REQ_HARDBARRIER);
+ unsigned long barrier = (bio->bi_rw & REQ_HARDBARRIER);
struct file *file = lo->lo_backing_file;
if (barrier) {
diff -urNp ./block/blk-core.c.orig ./block/blk-core.c
--- ./block/blk-core.c.orig 2010-07-07 19:14:55.000000000 +0800
+++ ./block/blk-core.c 2010-07-07 19:27:20.000000000 +0800
@@ -1198,9 +1198,9 @@ static int __make_request(struct request
int el_ret;
unsigned int bytes = bio->bi_size;
const unsigned short prio = bio_prio(bio);
- const bool sync = (bio->bi_rw & REQ_SYNC);
- const bool unplug = (bio->bi_rw & REQ_UNPLUG);
- const unsigned int ff = bio->bi_rw & REQ_FAILFAST_MASK;
+ const unsigned long sync = (bio->bi_rw & REQ_SYNC);
+ const unsigned long unplug = (bio->bi_rw & REQ_UNPLUG);
+ const unsigned long ff = bio->bi_rw & REQ_FAILFAST_MASK;
int rw_flags;
if ((bio->bi_rw & REQ_HARDBARRIER) &&
@@ -1719,7 +1719,7 @@ EXPORT_SYMBOL_GPL(blk_insert_cloned_requ
*/
unsigned int blk_rq_err_bytes(const struct request *rq)
{
- unsigned int ff = rq->cmd_flags & REQ_FAILFAST_MASK;
+ unsigned long ff = rq->cmd_flags & REQ_FAILFAST_MASK;
unsigned int bytes = 0;
struct bio *bio;
---------------------------
--------------------------------------------------
From: "Takeo Tung" <ker...@takeo.idv.tw>
Sent: Monday, June 28, 2010 6:52 PM
To: "Christoph Hellwig" <h...@lst.de>
Cc: "Michal Marek" <mma...@suse.cz>; <linux-...@vger.kernel.org>;
<vi...@zeniv.linux.org.uk>; <s...@canb.auug.org.au>; "Takeo Tung"
<ker...@takeo.idv.tw>
Subject: block: unify flags for struct bio and struct request will kernel
panic
Christoph Hellwig
> Dear Christoph,
>
> I was check the patch again. I found the panic status haapen on Soft RAID
> 1. I review it. found some define using bool, so some like ( x & REQ_SYNC)
> only 0 or 1.
> so if bi_rw = rw | sync will bi_rw = rw | 0 or rw | 1. not rw | ( 1 <<
> __REQ_SYNC).
>
> So I write a patch is fix it. seems normal now. could you review the patch
> or any comment?
The patch looks correct to me, although your mailer mangled the
whitespace badly. If Neil wants to keep the flag as bool we could
also add a !! around the bit flag checks.
Neil Brown
Christoph Hellwig <h...@lst.de> wrote:
> On Thu, Jul 08, 2010 at 07:05:39AM +0800, Takeo Tung wrote:
> > Dear Christoph,
> >
> > I was check the patch again. I found the panic status haapen on Soft RAID
> > 1. I review it. found some define using bool, so some like ( x & REQ_SYNC)
> > only 0 or 1.
> > so if bi_rw = rw | sync will bi_rw = rw | 0 or rw | 1. not rw | ( 1 <<
> > __REQ_SYNC).
> >
> > So I write a patch is fix it. seems normal now. could you review the patch
> > or any comment?
>
> The patch looks correct to me, although your mailer mangled the
> whitespace badly. If Neil wants to keep the flag as bool we could
> also add a !! around the bit flag checks.
I think it is best to make them "unsigned long" holding the actual but.
They were only made 'bool' because that is was bio_rw_flagged() returned.
Converting to a bool then back to a bit-flag is unnecessary.
Thanks,
NeilBrown
Neil Brown
"Takeo Tung" <ker...@takeo.idv.tw> wrote:
> Hello,
>
> ok. I rewrite the patch back to bool and re-add bio_rw_flagged fucntion. pls
> review it and any comment?
I'm not sure why you did that.
I meant to say that I liked the fact that you had changed from 'bool' to
'unsigned long' and that I thought using 'bool' was unnecessary. Maybe I
didn't say that very clearly.
It doesn't matter to me particularly which approach is used, but please don't
re-introduce bio_rw_flagged because you think I want it - I don't.
Thanks,
NeilBrown
>
> Thanks,
> Takeo Tung
>
> --------------------------------------------------
> From: "Neil Brown" <ne...@suse.de>
> Sent: Thursday, July 08, 2010 7:48 AM
> To: "Christoph Hellwig" <h...@lst.de>
> Cc: "Takeo Tung" <ker...@takeo.idv.tw>; "Michal Marek" <mma...@suse.cz>;
> <linux-...@vger.kernel.org>; <vi...@zeniv.linux.org.uk>;
> <s...@canb.auug.org.au>
> Subject: Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for
> struct bio and struct request will kernel panic
>
Takeo Tung
Ok. bcoz I don't sure you like define is 'bool' or 'unsigned long', if using
'unsigned long', I no problem now. sorry for my poor english.
Thanks,
Takeo Tung
--------------------------------------------------
From: "Neil Brown" <ne...@suse.de>
Sent: Thursday, July 08, 2010 9:15 AM
To: "Takeo Tung" <ker...@takeo.idv.tw>
Cc: "Christoph Hellwig" <h...@lst.de>; "Michal Marek" <mma...@suse.cz>;