* linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied
@ 2010-06-11 15:13 Takeo Tung
2010-06-11 20:07 ` Michal Marek
0 siblings, 1 reply; 12+ messages in thread
From: Takeo Tung @ 2010-06-11 15:13 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied
2010-06-11 15:13 linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied Takeo Tung
@ 2010-06-11 20:07 ` Michal Marek
2010-06-12 8:44 ` Takeo Tung
0 siblings, 1 reply; 12+ messages in thread
From: Michal Marek @ 2010-06-11 20:07 UTC (permalink / raw)
To: Takeo Tung; +Cc: linux-kernel, Christoph Hellwig
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied
2010-06-11 20:07 ` Michal Marek
@ 2010-06-12 8:44 ` Takeo Tung
2010-06-12 9:49 ` Christoph Hellwig
0 siblings, 1 reply; 12+ messages in thread
From: Takeo Tung @ 2010-06-12 8:44 UTC (permalink / raw)
To: Michal Marek; +Cc: linux-kernel, Christoph Hellwig, kernel
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/
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied
2010-06-12 8:44 ` Takeo Tung
@ 2010-06-12 9:49 ` Christoph Hellwig
2010-06-12 19:35 ` Takeo Tung
2010-06-28 10:52 ` block: unify flags for struct bio and struct request will kernel panic Takeo Tung
0 siblings, 2 replies; 12+ messages in thread
From: Christoph Hellwig @ 2010-06-12 9:49 UTC (permalink / raw)
To: Takeo Tung; +Cc: Michal Marek, linux-kernel, viro, sfr
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;
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied
2010-06-12 9:49 ` Christoph Hellwig
@ 2010-06-12 19:35 ` Takeo Tung
2010-06-28 10:52 ` block: unify flags for struct bio and struct request will kernel panic Takeo Tung
1 sibling, 0 replies; 12+ messages in thread
From: Takeo Tung @ 2010-06-12 19:35 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Michal Marek, linux-kernel, viro, sfr
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/
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* block: unify flags for struct bio and struct request will kernel panic
2010-06-12 9:49 ` Christoph Hellwig
2010-06-12 19:35 ` Takeo Tung
@ 2010-06-28 10:52 ` Takeo Tung
2010-07-07 23:05 ` [PATCH] struct io panic on raid1 - " Takeo Tung
1 sibling, 1 reply; 12+ messages in thread
From: Takeo Tung @ 2010-06-28 10:52 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Michal Marek, linux-kernel, viro, sfr, 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
2010-06-28 10:52 ` block: unify flags for struct bio and struct request will kernel panic Takeo Tung
@ 2010-07-07 23:05 ` Takeo Tung
2010-07-07 23:17 ` Christoph Hellwig
0 siblings, 1 reply; 12+ messages in thread
From: Takeo Tung @ 2010-07-07 23:05 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Michal Marek, linux-kernel, viro, sfr, 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/
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
2010-07-07 23:05 ` [PATCH] struct io panic on raid1 - " Takeo Tung
@ 2010-07-07 23:17 ` Christoph Hellwig
2010-07-07 23:48 ` Neil Brown
0 siblings, 1 reply; 12+ messages in thread
From: Christoph Hellwig @ 2010-07-07 23:17 UTC (permalink / raw)
To: Takeo Tung; +Cc: Christoph Hellwig, Michal Marek, linux-kernel, viro, sfr
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
2010-07-07 23:17 ` Christoph Hellwig
@ 2010-07-07 23:48 ` Neil Brown
2010-07-08 0:43 ` Takeo Tung
0 siblings, 1 reply; 12+ messages in thread
From: Neil Brown @ 2010-07-07 23:48 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Takeo Tung, Michal Marek, linux-kernel, viro, sfr
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
2010-07-07 23:48 ` Neil Brown
@ 2010-07-08 0:43 ` Takeo Tung
2010-07-08 1:15 ` Neil Brown
0 siblings, 1 reply; 12+ messages in thread
From: Takeo Tung @ 2010-07-08 0:43 UTC (permalink / raw)
To: Neil Brown, Christoph Hellwig
Cc: Michal Marek, linux-kernel, viro, sfr, 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
*/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
2010-07-08 0:43 ` Takeo Tung
@ 2010-07-08 1:15 ` Neil Brown
2010-07-08 1:42 ` Takeo Tung
0 siblings, 1 reply; 12+ messages in thread
From: Neil Brown @ 2010-07-08 1:15 UTC (permalink / raw)
To: Takeo Tung; +Cc: Christoph Hellwig, Michal Marek, linux-kernel, viro, sfr
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/
> >
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
2010-07-08 1:15 ` Neil Brown
@ 2010-07-08 1:42 ` Takeo Tung
0 siblings, 0 replies; 12+ messages in thread
From: Takeo Tung @ 2010-07-08 1:42 UTC (permalink / raw)
To: Neil Brown; +Cc: Christoph Hellwig, Michal Marek, linux-kernel, viro, sfr
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/
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-07-08 1:42 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-11 15:13 linux-next-20100608 will /bin/sh: scripts/basic/fixdep: Permission denied Takeo Tung
2010-06-11 20:07 ` Michal Marek
2010-06-12 8:44 ` Takeo Tung
2010-06-12 9:49 ` Christoph Hellwig
2010-06-12 19:35 ` Takeo Tung
2010-06-28 10:52 ` block: unify flags for struct bio and struct request will kernel panic Takeo Tung
2010-07-07 23:05 ` [PATCH] struct io panic on raid1 - " Takeo Tung
2010-07-07 23:17 ` Christoph Hellwig
2010-07-07 23:48 ` Neil Brown
2010-07-08 0:43 ` Takeo Tung
2010-07-08 1:15 ` Neil Brown
2010-07-08 1:42 ` Takeo Tung
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.