linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

[Takeo Tung]

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

Thanks,
Takeo Tung

Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

[Michal Marek]

On 11.6.2010 17:13, Takeo Tung wrote:
> 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

Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

[Takeo Tung]

Hello,

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" <mmarek@suse.cz>
Sent: Saturday, June 12, 2010 4:07 AM
To: "Takeo Tung" <kernel@takeo.idv.tw>
Cc: <linux-kernel@vger.kernel.org>; "Christoph Hellwig" <hch@lst.de>
Subject: Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: 
Permission denied

> On 11.6.2010 17:13, Takeo Tung wrote:
>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> 

Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

[Christoph Hellwig]

Please try the patch below, looks like I did a horrible messup in the
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;

Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

[Takeo Tung]

Hello,

I was try this patch, seems all is normal now. thanks for your patch.

Best Regards,
Takeo Tung

--------------------------------------------------
From: "Christoph Hellwig" <hch@lst.de>
Sent: Saturday, June 12, 2010 5:49 PM
To: "Takeo Tung" <kernel@takeo.idv.tw>
Cc: "Michal Marek" <mmarek@suse.cz>; <linux-kernel@vger.kernel.org>; 
<viro@zeniv.linux.org.uk>; <sfr@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
> 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;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> 

block: unify flags for struct bio and struct request will kernel panic

[Takeo Tung]

Dear Christoph,

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.

http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git;a=commitdiff_plain;h=74450be123b6f3cb480c358a056be398cce6aa6e

Thanks,
Takeo Tung
 

[PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic

[Takeo Tung]

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?

Thanks
Takeo Tung

Signed-off-by: Takeo Tung <kernel@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" <kernel@takeo.idv.tw>
Sent: Monday, June 28, 2010 6:52 PM
To: "Christoph Hellwig" <hch@lst.de>
Cc: "Michal Marek" <mmarek@suse.cz>; <linux-kernel@vger.kernel.org>; 
<viro@zeniv.linux.org.uk>; <sfr@canb.auug.org.au>; "Takeo Tung" 
<kernel@takeo.idv.tw>
Subject: block: unify flags for struct bio and struct request will kernel 
panic

> Dear Christoph,
>
> 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.
>
> http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git;a=commitdiff_plain;h=74450be123b6f3cb480c358a056be398cce6aa6e
>
> Thanks,
> Takeo Tung
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> 

Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic

[Christoph Hellwig]

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.

Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic

[Neil Brown]

On Thu, 8 Jul 2010 01:17:32 +0200
Christoph Hellwig <hch@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

Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic

[Takeo Tung]

[-- Attachment #1: Type: text/plain, Size: 34 bytes --]

3o,O MIME .f&!*: Multipart 6l%s!C

[-- Attachment #2: Type: text/plain, Size: 1822 bytes --]

Hello,

ok. I rewrite the patch back to bool and re-add bio_rw_flagged fucntion. pls 
review it and any comment?

Thanks,
Takeo Tung

--------------------------------------------------
From: "Neil Brown" <neilb@suse.de>
Sent: Thursday, July 08, 2010 7:48 AM
To: "Christoph Hellwig" <hch@lst.de>
Cc: "Takeo Tung" <kernel@takeo.idv.tw>; "Michal Marek" <mmarek@suse.cz>; 
<linux-kernel@vger.kernel.org>; <viro@zeniv.linux.org.uk>; 
<sfr@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

> On Thu, 8 Jul 2010 01:17:32 +0200
> Christoph Hellwig <hch@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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> 

[-- Attachment #3: bio-blkdev-rev2.patch --]
[-- Type: application/octet-stream, Size: 7940 bytes --]

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-08 08:35:19.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 bool do_sync = bio_rw_flagged(bio, REQ_SYNC);
 	struct bio_list bl;
 	unsigned long flags;
 	mdk_rdev_t *blocked_rdev;
@@ -879,7 +879,7 @@ static int make_request(mddev_t *mddev, 
 			mirror->rdev->data_offset;
 		read_bio->bi_bdev = mirror->rdev->bdev;
 		read_bio->bi_end_io = raid10_end_read_request;
-		read_bio->bi_rw = READ | do_sync;
+		read_bio->bi_rw = READ | (do_sync << __REQ_SYNC);
 		read_bio->bi_private = r10_bio;
 
 		generic_make_request(read_bio);
@@ -947,7 +947,7 @@ static int make_request(mddev_t *mddev, 
 			conf->mirrors[d].rdev->data_offset;
 		mbio->bi_bdev = conf->mirrors[d].rdev->bdev;
 		mbio->bi_end_io	= raid10_end_write_request;
-		mbio->bi_rw = WRITE | do_sync;
+		mbio->bi_rw = WRITE | (do_sync << __REQ_SYNC);
 		mbio->bi_private = r10_bio;
 
 		atomic_inc(&r10_bio->remaining);
@@ -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 bool do_sync = bio_rw_flagged(r10_bio->master_bio, REQ_SYNC);
 				bio_put(bio);
 				rdev = conf->mirrors[mirror].rdev;
 				if (printk_ratelimit())
@@ -1730,7 +1730,7 @@ static void raid10d(mddev_t *mddev)
 				bio->bi_sector = r10_bio->devs[r10_bio->read_slot].addr
 					+ rdev->data_offset;
 				bio->bi_bdev = rdev->bdev;
-				bio->bi_rw = READ | do_sync;
+				bio->bi_rw = READ | (do_sync << __REQ_SYNC);
 				bio->bi_private = r10_bio;
 				bio->bi_end_io = raid10_end_read_request;
 				unplug = 1;
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-08 08:37:08.000000000 +0800
@@ -787,7 +787,7 @@ 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);
+	const bool do_sync = bio_rw_flagged(bio, REQ_SYNC);
 	bool do_barriers;
 	mdk_rdev_t *blocked_rdev;
 
@@ -877,7 +877,7 @@ static int make_request(mddev_t *mddev, 
 		read_bio->bi_sector = r1_bio->sector + mirror->rdev->data_offset;
 		read_bio->bi_bdev = mirror->rdev->bdev;
 		read_bio->bi_end_io = raid1_end_read_request;
-		read_bio->bi_rw = READ | do_sync;
+		read_bio->bi_rw = READ | (do_sync << __REQ_SYNC);
 		read_bio->bi_private = r1_bio;
 
 		generic_make_request(read_bio);
@@ -959,7 +959,7 @@ static int make_request(mddev_t *mddev, 
 	atomic_set(&r1_bio->remaining, 0);
 	atomic_set(&r1_bio->behind_remaining, 0);
 
-	do_barriers = bio->bi_rw & REQ_HARDBARRIER;
+	do_barriers = bio_rw_flagged(bio, REQ_HARDBARRIER);
 	if (do_barriers)
 		set_bit(R1BIO_Barrier, &r1_bio->state);
 
@@ -975,7 +975,7 @@ static int make_request(mddev_t *mddev, 
 		mbio->bi_sector	= r1_bio->sector + conf->mirrors[i].rdev->data_offset;
 		mbio->bi_bdev = conf->mirrors[i].rdev->bdev;
 		mbio->bi_end_io	= raid1_end_write_request;
-		mbio->bi_rw = WRITE | do_barriers | do_sync;
+		mbio->bi_rw = WRITE | (do_barriers << __REQ_HARDBARRIER) | (do_sync << __REQ_SYNC);
 		mbio->bi_private = r1_bio;
 
 		if (behind_pages) {
@@ -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 bool do_sync = bio_rw_flagged(r1_bio->master_bio, REQ_SYNC);
 			clear_bit(R1BIO_BarrierRetry, &r1_bio->state);
 			clear_bit(R1BIO_Barrier, &r1_bio->state);
 			for (i=0; i < conf->raid_disks; i++)
@@ -1661,7 +1661,7 @@ static void raid1d(mddev_t *mddev)
 						conf->mirrors[i].rdev->data_offset;
 					bio->bi_bdev = conf->mirrors[i].rdev->bdev;
 					bio->bi_end_io = raid1_end_write_request;
-					bio->bi_rw = WRITE | do_sync;
+					bio->bi_rw = WRITE | (do_sync << __REQ_SYNC);
 					bio->bi_private = r1_bio;
 					r1_bio->bios[i] = bio;
 					generic_make_request(bio);
@@ -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 bool do_sync = bio_rw_flagged(r1_bio->master_bio, REQ_SYNC);
 				r1_bio->bios[r1_bio->read_disk] =
 					mddev->ro ? IO_BLOCKED : NULL;
 				r1_bio->read_disk = disk;
@@ -1713,7 +1713,7 @@ static void raid1d(mddev_t *mddev)
 				bio->bi_sector = r1_bio->sector + rdev->data_offset;
 				bio->bi_bdev = rdev->bdev;
 				bio->bi_end_io = raid1_end_read_request;
-				bio->bi_rw = READ | do_sync;
+				bio->bi_rw = READ | (do_sync << __REQ_SYNC);
 				bio->bi_private = r1_bio;
 				unplug = 1;
 				generic_make_request(bio);
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-08 08:38:06.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);
+		bool barrier = bio_rw_flagged(bio, 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-08 08:39:10.000000000 +0800
@@ -174,7 +174,7 @@ void blk_dump_rq_flags(struct request *r
 {
 	int bit;
 
-	printk(KERN_INFO "%s: dev %s: type=%x, flags=%x\n", msg,
+	printk(KERN_INFO "%s: dev %s: type=%x, flags=%lx\n", msg,
 		rq->rq_disk ? rq->rq_disk->disk_name : "?", rq->cmd_type,
 		rq->cmd_flags);
 
@@ -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 bool sync = bio_rw_flagged(bio, REQ_SYNC);
+	const bool unplug = bio_rw_flagged(bio, 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;
 
diff -urNp ./include/linux/blkdev.h.orig ./include/linux/blkdev.h
--- ./include/linux/blkdev.h.orig	2010-07-08 07:54:51.000000000 +0800
+++ ./include/linux/blkdev.h	2010-07-08 07:55:30.000000000 +0800
@@ -97,7 +97,7 @@ struct request {
 
 	struct request_queue *q;
 
-	unsigned int cmd_flags;
+	unsigned long cmd_flags;
 	enum rq_cmd_type_bits cmd_type;
 	unsigned long atomic_flags;
 
diff -urNp ./include/linux/bio.h.orig ./include/linux/bio.h
--- ./include/linux/bio.h.orig	2010-07-08 08:32:53.000000000 +0800
+++ ./include/linux/bio.h	2010-07-08 08:32:17.000000000 +0800
@@ -218,6 +218,11 @@ enum rq_flag_bits {
 #define REQ_IO_STAT		(1 << __REQ_IO_STAT)
 #define REQ_MIXED_MERGE		(1 << __REQ_MIXED_MERGE)
 
+static inline bool bio_rw_flagged(struct bio *bio, unsigned long flag)
+{
+	return (bio->bi_rw & flag) != 0;
+}
+
 /*
  * upper 16 bits of bi_rw define the io priority of this bio
  */

Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic

[Neil Brown]

On Thu, 8 Jul 2010 08:43:38 +0800
"Takeo Tung" <kernel@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" <neilb@suse.de>
> Sent: Thursday, July 08, 2010 7:48 AM
> To: "Christoph Hellwig" <hch@lst.de>
> Cc: "Takeo Tung" <kernel@takeo.idv.tw>; "Michal Marek" <mmarek@suse.cz>; 
> <linux-kernel@vger.kernel.org>; <viro@zeniv.linux.org.uk>; 
> <sfr@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
> 
> > On Thu, 8 Jul 2010 01:17:32 +0200
> > Christoph Hellwig <hch@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
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> > 

Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic

[Takeo Tung]

Dear Neil,

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" <neilb@suse.de>
Sent: Thursday, July 08, 2010 9:15 AM
To: "Takeo Tung" <kernel@takeo.idv.tw>
Cc: "Christoph Hellwig" <hch@lst.de>; "Michal Marek" <mmarek@suse.cz>; 
<linux-kernel@vger.kernel.org>; <viro@zeniv.linux.org.uk>; 
<sfr@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

> On Thu, 8 Jul 2010 08:43:38 +0800
> "Takeo Tung" <kernel@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" <neilb@suse.de>
>> Sent: Thursday, July 08, 2010 7:48 AM
>> To: "Christoph Hellwig" <hch@lst.de>
>> Cc: "Takeo Tung" <kernel@takeo.idv.tw>; "Michal Marek" <mmarek@suse.cz>;
>> <linux-kernel@vger.kernel.org>; <viro@zeniv.linux.org.uk>;
>> <sfr@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
>>
>> > On Thu, 8 Jul 2010 01:17:32 +0200
>> > Christoph Hellwig <hch@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
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" 
>> > in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at  http://www.tux.org/lkml/
>> >
>> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
> 

linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied

[Takeo Tung]

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

Thanks,
Takeo Tung