fault-injection-developer — Developer discussions about creating a fault injection test harness.

[Fault-injection-developer] RE: [DISCUSSION] make decisions about ficl

[Wang, S. <sta...@in...>]

A. yes
B. no

For question B, I think we could do some cleaning work when the 
interceptor is remove to decrease the potionial issues.

-Stan

> -----Original Message-----
> From: Zhuang, Louis 
> Sent: 2003-01-10 9:12
> To: 'Rusty Lynch'; fau...@li...
> Cc: Gao, Kevin; Wang, Frank; Wang, Stanley; Zhuang, Louis
> Subject: [DISCUSSION] make decisions about ficl
> 
> 
> > * In case the chicken-and-egg analogy is not obvious across cultural
> >   barriers...  it refers to the evolutionary question of which came 
> In fact, chicken-and-egg is really across cluture, at least 
> in China. ;->
> 
> According to ficl, we've some decisions to make. 
> First, ficl for current FITH should still use FSML as input?
> a. yes
> b. no
> Second, ficl should lock relevant drivers/modules 
> automatically as before?
> a. yes.
> b. no
> 
> For second item, locking modules is a really mess which is 
> not really relative with fault injection itself. But it can 
> protect system from mis-operating (for example, tester always 
> forgets remove PF trigger before unload tested-driver. This 
> will make kernel oops because iounmap finds some MMIO page is 
> not present.) But we can not find a clean way to lock module 
> in user space. Shall we investigate more on this? Or shall we 
> talk with Russell for this feature?
> 
> Any comments?
> 
> 
> 
> Yours truly,
> Louis Zhuang
> ---------------
> Fault Injection Test Harness Project
> BK tree: http://fault-injection.bkbits.net/linux-2.5
> Home Page: http://sf.net/projects/fault-injection
> 

[Fault-injection-developer] [DISCUSSION] make decisions about ficl

[Zhuang, L. <lou...@in...>]

> * In case the chicken-and-egg analogy is not obvious across cultural
>   barriers...  it refers to the evolutionary question of which came 
In fact, chicken-and-egg is really across cluture, at least in China. ;->

According to ficl, we've some decisions to make. 
First, ficl for current FITH should still use FSML as input?
a. yes
b. no
Second, ficl should lock relevant drivers/modules automatically as before?
a. yes.
b. no

For second item, locking modules is a really mess which is not really
relative with fault injection itself. But it can protect system from
mis-operating (for example, tester always forgets remove PF trigger before
unload tested-driver. This will make kernel oops because iounmap finds some
MMIO page is not present.) But we can not find a clean way to lock module in
user space. Shall we investigate more on this? Or shall we talk with Russell
for this feature?

Any comments?



Yours truly,
Louis Zhuang
---------------
Fault Injection Test Harness Project
BK tree: http://fault-injection.bkbits.net/linux-2.5
Home Page: http://sf.net/projects/fault-injection

Re: [Fault-injection-developer] RE: About push e100 test cases to our FITH tree

[Rusty L. <ru...@li...>]

From: "Gao, Kevin" <kev...@in...>
> Yes, put it to fith-tools is a good suggestion.
> But I want to know how will fith-tool directory existing in our project.
> The code there in is not used for much time, and overdated.
> I will try to clean up the directory.
>  
> -Kevin

I think the fact that our fith-tools code is stagnant is a direct
(and natural) result of the projects  focus on kernel level features.
As we further solidify the basic kernel interfaces, the user space
code will start to get more attention.

BTW, a well written and generally useful set of user space tools
for this type of new feature is key for the kernel space code eventually 
being accepted into Linus's tree.  We are going to have to overcome
the same *chicken-and-egg type of dilemma that kprobes is currently
suffering from.

    -rustyl

* In case the chicken-and-egg analogy is not obvious across cultural
  barriers...  it refers to the evolutionary question of which came 
  first, the chicken or the egg.  In order to have our fault injection
  capabilities (chicken) added to the kernel, we will need to have
  a significant backing of people using (egg) the features to justify
  the extra code before Linus will accept the changes.  The only
  way I see people taking advantage of fi is to have some very useful
  user space tools (fith-tools).

RE: [Fault-injection-developer] RE: About push e100 test cases to our FITH tree

[Gao, K. <kev...@in...>]

Yes, put it to fith-tools is a good suggestion.
But I want to know how will fith-tool directory existing in our =
project.
The code there in is not used for much time, and overdated.
I will try to clean up the directory.
=20
-Kevin


-----Original Message-----
From: Rusty Lynch [mailto:ru...@li...]=20
Sent: 2003=C4=EA1=D4=C29=C8=D5 6:27
To: Zhuang, Louis; Gao, Kevin;
fau...@li...; Wang, Frank; Wang, =
Stanley
Subject: Re: [Fault-injection-developer] RE: About push e100 test cases =
to
our FITH tree


MessageFrom: Zhuang, Louis=20
> These code segment can demostrate some complex usage for FITH,=20
> Maybe we can create 'e100_test' directory under 'codesegments'=20
> for these test.=20
>
> From: Gao, Kevin=20
>> Now FITH is used to test e100 driver for a period of time,=20
>> and there are some test cases for e100 still on another tracking.
>> Why not I push them into our FITH's tree.
>> Is there any issue? or idea?:)

By creating a new e100_test directory under codesegments I assume
you mean creating a new code segment called e100_test.  Any code
that is outside the scope of a code segment should not be put in
that location.

We could use a location to put arbitrary test cases.  Maybe in=20
the the fith-tool tree? Maybe fith-tool/fith_test/e100/ for all=20
the e100 test, with a README at fith-tool/fith_test/e100/README=20
that explains how to use the test cases?

    --rustyl

[Fault-injection-developer] [RFC] RE: Change Code Segment's user mode interface

[Zhuang, L. <lou...@in...>]

> Detach code segment from a trigger,
> use echo "detach trigger_name" > ctl or echo "detach" > ctl?
> I think first is better. 
> If we want attach more than one trigger to codesegment in future.
> The first way maybe have better expansibility. :)
Let's think twice at the point. "Shall we support multi-multi relationship
between trigger and codesegment"? Because there are no way to judge which
trigger is the caller of the execute, we *assume* the code segment implictly
knows who call it. The assumption implict a multi-one relationship between
trigger and code segment. Does this make sense? Shall we get rid of the
assumption for 'extensibility'? request for you coments. -Louis

Re: [Fault-injection-developer] RE: About push e100 test cases to our FITH tree

[Rusty L. <ru...@li...>]

MessageFrom: Zhuang, Louis 
> These code segment can demostrate some complex usage for FITH, 
> Maybe we can create 'e100_test' directory under 'codesegments' 
> for these test. 
>
> From: Gao, Kevin 
>> Now FITH is used to test e100 driver for a period of time, 
>> and there are some test cases for e100 still on another tracking.
>> Why not I push them into our FITH's tree.
>> Is there any issue? or idea?:)

By creating a new e100_test directory under codesegments I assume
you mean creating a new code segment called e100_test.  Any code
that is outside the scope of a code segment should not be put in
that location.

We could use a location to put arbitrary test cases.  Maybe in 
the the fith-tool tree? Maybe fith-tool/fith_test/e100/ for all 
the e100 test, with a README at fith-tool/fith_test/e100/README 
that explains how to use the test cases?

    --rustyl

RE: [Fault-injection-developer] RFC: Change Code Segment's user mode interface

[Gao, K. <kev...@in...>]

Detach code segment from a trigger,
use echo "detach trigger_name" > ctl or echo "detach" > ctl?
I think first is better.=20
If we want attach more than one trigger to codesegment in future.
The first way maybe have better expansibility. :)

-Kevin

-----Original Message-----
From: Zhuang, Louis [mailto:lou...@in...]=20
Sent: 2003=C4=EA1=D4=C28=C8=D5 17:53
To: Wang, Stanley; 'fau...@li...'
Subject: RE: [Fault-injection-developer] RFC: Change Code Segment's =
user
mode interface


Good! fi_core will conform to it. -Louis

> -----Original Message-----
> From: Wang, Stanley [mailto:sta...@in...]
> Sent: Wednesday, January 08, 2003 5:48 PM
> To: 'fau...@li...'
> Subject: [Fault-injection-developer] RFC: Change Code Segment's user
> mode interface
>=20
>=20
> Hi, folks
> How about change a bit the usage of
> /sys/fault_injection/code_segments/xxx/ctl?
> I think the following would be better:
> Attach code segment with a trigger:
> echo "attach trigger_name" > ctl
>=20
> Detach code segment from a trigger:
> echo "detach" > ctl
>=20
> View the attached trigger's name:
> cat ctl
>=20
> Any comment?
>=20
> Your Sincerely,
> Stanley Wang=20
>=20
> SW Engineer, Intel Corporation.
> Intel China Software Lab.=20
> Tel: 021-52574545 ext. 1171=20
> iNet: 8-752-1171=20
> =20
> Opinions expressed are those of the author and do not represent Intel
> Corporation
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 =
See!
> http://www.vasoftware.com
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> =
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
>=20


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fault-injection-developer mailing list
Fau...@li...
https://lists.sourceforge.net/lists/listinfo/fault-injection-developer

RE: [Fault-injection-developer] RFC: Change Code Segment's user mode interface

[Zhuang, L. <lou...@in...>]

Good! fi_core will conform to it. -Louis

> -----Original Message-----
> From: Wang, Stanley [mailto:sta...@in...]
> Sent: Wednesday, January 08, 2003 5:48 PM
> To: 'fau...@li...'
> Subject: [Fault-injection-developer] RFC: Change Code Segment's user
> mode interface
> 
> 
> Hi, folks
> How about change a bit the usage of
> /sys/fault_injection/code_segments/xxx/ctl?
> I think the following would be better:
> Attach code segment with a trigger:
> echo "attach trigger_name" > ctl
> 
> Detach code segment from a trigger:
> echo "detach" > ctl
> 
> View the attached trigger's name:
> cat ctl
> 
> Any comment?
> 
> Your Sincerely,
> Stanley Wang 
> 
> SW Engineer, Intel Corporation.
> Intel China Software Lab. 
> Tel: 021-52574545 ext. 1171 
> iNet: 8-752-1171 
>  
> Opinions expressed are those of the author and do not represent Intel
> Corporation
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> 

[Fault-injection-developer] RFC: Change Code Segment's user mode interface

[Wang, S. <sta...@in...>]

Hi, folks
How about change a bit the usage of
/sys/fault_injection/code_segments/xxx/ctl?
I think the following would be better:
Attach code segment with a trigger:
echo "attach trigger_name" > ctl

Detach code segment from a trigger:
echo "detach" > ctl

View the attached trigger's name:
cat ctl

Any comment?

Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] make one-to-multi relationship between trigger and code segment

[Zhuang, L. <lou...@in...>]

Dear all,
	As we agreed previous email, I make multi code-segments attach to
one trigger. You can see it in 
/sys/fault-injection/trigger/<tri_name>/opcode.

  - Louis 

You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.

===================================================================


ChangeSet@1.977.1.1, 2003-01-08 12:59:15+08:00, lo...@ha...
  make one-to-multi relationship between trigger and code segment


 drivers/fi/fi_core.c |   89
+++++++++++++++++++++++++++++++++++----------------
 include/linux/fi.h   |    3 +
 2 files changed, 64 insertions(+), 28 deletions(-)


diff -Nru a/drivers/fi/fi_core.c b/drivers/fi/fi_core.c
--- a/drivers/fi/fi_core.c	Wed Jan  8 13:06:52 2003
+++ b/drivers/fi/fi_core.c	Wed Jan  8 13:06:52 2003
@@ -152,6 +152,7 @@
 	if (!n)
 		return -ENOMEM;
 	memset(n,0,sizeof(struct trigger));
+	INIT_LIST_HEAD(&n->cs_list);
 	
 	strncpy(n->kobj.name, t->kobj.name, KOBJ_NAME_LEN);
 	n->kobj.subsys = &trigger_subsys;
@@ -186,19 +187,38 @@
 	return 0;
 }
 
-static inline ssize_t del_trigger(struct trigger *t)
+static inline void del_code_segment(struct code_segment *cs)
+{
+	struct trigger *t = cs->tri;
+	
+	list_del(&cs->list);
+	cs->tri = NULL;
+	kobject_put(&cs->kobj);
+	kobject_put(&t->kobj);
+}
+
+static inline void del_cs_list(struct list_head *head) {
+	struct list_head *pos;
+	struct list_head *tmp;
+	list_for_each_safe(pos, tmp, head) {
+		del_code_segment(list_entry(pos, struct code_segment,
list));
+	}
+}	
+	
+static inline ssize_t del_trigger(const char *tri_name)
 {
 	struct trigger * n;
 
-	n = find_trigger_by_name(t->kobj.name);
+	n = find_trigger_by_name(tri_name);
 	if (n) {
 		unarm_trigger(n);
 		remove_trigger_files(n);
+		del_cs_list(&n->cs_list);
 		kobject_unregister(&n->kobj);
 		return 0;
 	}
 
-	err("trigger %s does not exist", t->kobj.name);
+	err("trigger %s does not exist", tri_name);
 	return -EINVAL;
 }
 
@@ -214,22 +234,12 @@
 	sysfs_remove_file(&cs->kobj, &code_segment_attr_trigger.attr);
 }
 
-static inline void arm_code_segment(struct code_segment *cs, struct trigger
*t) 
+static inline void add_code_segment(struct code_segment *cs, struct trigger
*t) 
 {
 	kobject_get(&t->kobj);
 	kobject_get(&cs->kobj);
+	list_add(&cs->list, &t->cs_list);
 	cs->tri = t;
-	t->cs = cs;
-}
-
-static inline void unarm_code_segment(struct code_segment *cs)
-{
-	struct trigger *t = cs->tri;
-	
-	t->cs = NULL;
-	cs->tri = NULL;
-	kobject_put(&cs->kobj);
-	kobject_put(&t->kobj);
 }
 
 /*
@@ -480,17 +490,33 @@
 	.show	= trigger_intcpt_read,	
 };
 
+static inline ssize_t print_cs_list(struct list_head *head, 
+				    char *page, int count) 
+{
+	int i = 0;
+	struct code_segment *pos;
+	list_for_each_entry(pos, head, list) {
+		i += snprintf(page+i, count-i, 
+		              "code segment name: %s\n", 
+			      pos->kobj.name);
+	}
+	return i;
+}
+
 static ssize_t trigger_opcode_read(struct trigger * p, char * page, 
 				   size_t count, loff_t off)
 {
 	dbg("opcode = %i", p->opcode);
 	if (off) return 0;
-	if (p->cs) {
-		return snprintf(page,count,"cs name:
%s\n",p->cs->kobj.name);
-	} else {
+	if (list_empty(&p->cs_list)) {
 		return snprintf(page,count,"op code: %i\n",p->opcode);
+	} else {
+		int i;
+		i =  print_cs_list(&p->cs_list, page, count);
+		return i;
 	}
 }
+
 static struct trigger_attribute trigger_attr_opcode = {
 	.attr	= { .name = "opcode", .mode = S_IRUGO },
 	.show	= trigger_opcode_read,	
@@ -501,12 +527,13 @@
 {
 	dbg("operand = %i", p->operand);
 	if (off) return 0;
-	if (p->cs) {
-		return snprintf(page,count,"(no used)\n");
-	} else {
+	if (list_empty(&p->cs_list)) {
 		return snprintf(page,count,"%i\n",p->operand);
+	} else {
+		return snprintf(page,count,"(no used)\n");
 	}
 }
+
 static struct trigger_attribute trigger_attr_operand = {
 	.attr	= { .name = "operand", .mode = S_IRUGO },
 	.show	= trigger_operand_read,	
@@ -517,6 +544,7 @@
 {
 	return 0;
 }
+
 static ssize_t trigger_ctl_store(struct subsystem * s, const char * page, 
 				 size_t count, loff_t off)
 {
@@ -556,7 +584,7 @@
 		dbg("intcpt = '%s'", intcpt);
 		ret = add_trigger(&tmp, intcpt);
 	} else if (!strcmp(ctl,"del") && num == 2) {
-		ret = del_trigger(&tmp);
+		ret = del_trigger(tmp.kobj.name);
 	} else {
 		err("Invalid command format: %s, %i tokens found",ctl,num);
 		ret = -EINVAL;
@@ -647,11 +675,15 @@
 
 	sscanf(page, "%s", tri_name);
 	
-	if (cs->tri) unarm_code_segment(cs);
+	if (cs->tri) del_code_segment(cs);
 	
 	dbg("Try to find %s trigger", tri_name);
 	t = find_trigger_by_name(tri_name);
-	if(t) arm_code_segment(cs, t);
+	if (t) { 
+		add_code_segment(cs, t);
+	} else {
+		err("Unable to find trigger %s", tri_name);
+	}
 	return count;
 }
 
@@ -725,8 +757,11 @@
 	dbg("count=%d, skip=%d, min=%d, max=%d, val=%d",
 	    atomic_read(&t->count), t->skip, t->min, t->max, val);
 	
-	if (t->cs) {
-		t->cs->execute_trigger(t, i, val, len, type, data);
+	if (!list_empty(&t->cs_list)) {
+		struct code_segment *pos;
+		list_for_each_entry (pos, &t->cs_list, list) {
+			pos->execute_trigger(t, i, val, len, type, data);
+		}
 		return;
 	}
 	
@@ -812,7 +847,7 @@
 
 void fi_unregister_code_segment(struct code_segment *cs)
 {
-	if (cs->tri) unarm_code_segment(cs);
+	if (cs->tri) del_code_segment(cs);
 	remove_code_segment_files(cs);
 	kobject_unregister(&cs->kobj);
 }
diff -Nru a/include/linux/fi.h b/include/linux/fi.h
--- a/include/linux/fi.h	Wed Jan  8 13:06:52 2003
+++ b/include/linux/fi.h	Wed Jan  8 13:06:52 2003
@@ -56,6 +56,7 @@
 struct trigger;
 struct interceptor;
 struct code_segment {
+	struct list_head list;
 	void (*execute_trigger) (struct trigger *t, 
 				 struct interceptor *i, 
 				 __u32 val, 
@@ -76,7 +77,7 @@
 	int protection;
 	int hertz;
 	int registered;
-	struct code_segment *cs;
+	struct list_head cs_list;
 	struct interceptor *intcpt;
 	atomic_t count;
 	/* opaque data struct for register */



Yours truly,
Louis Zhuang
---------------
Fault Injection Test Harness Project
BK tree: http://fault-injection.bkbits.net/linux-2.5
Home Page: http://sf.net/projects/fault-injection

[Fault-injection-developer] Updated: fi_test

[Wang, S. <sta...@in...>]

I added PIO access function in the fi_test, hence we could 
test fi_dbp with it.
Here is the patch:
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.972   -> 1.972.2.3
#	drivers/fi/testing/fi_test.c	1.12    -> 1.13   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/01/07	st...@ma...	1.972.2.2
# Add PIO access support for FITH's test module.
# --------------------------------------------
# 03/01/07	lo...@ha...	1.974
# Merge bk://fau...@fa.../linux-2.5
# into hawk.sh.intel.com:/home/work/2.5-fi
# --------------------------------------------
# 03/01/07	lo...@ha...	1.975
# Add missed license
# --------------------------------------------
#
diff -Nru a/drivers/fi/testing/fi_test.c b/drivers/fi/testing/fi_test.c
--- a/drivers/fi/testing/fi_test.c	Tue Jan  7 16:43:10 2003
+++ b/drivers/fi/testing/fi_test.c	Tue Jan  7 16:43:10 2003
@@ -28,17 +28,30 @@
 #define warn(format, arg...) printk(KERN_WARNING "%s: " format "\n",
MY_NAME , ## arg)
 
 
+#define PP_BASE 0x378
 #define MM_BASE 0x00001000
 
 static int debug;
 
 void *mmio_address;
 volatile unsigned long global_counter = 0;
+ssize_t io_show(struct subsystem *s, char *page,
+	       size_t count, loff_t off);
+ssize_t io_store(struct subsystem *s, const char *page,
+	       size_t count, loff_t off);
+
 ssize_t mmio_show(struct subsystem *s, char *page,
 	       size_t count, loff_t off);
 ssize_t mmio_store(struct subsystem *s, const char *page,
 	       size_t count, loff_t off);
 
+struct subsys_attribute io =
+{
+	.attr = { .name = "io", .mode = 0644 },
+	.show = io_show,
+	.store = io_store,
+};
+
 struct subsys_attribute mmio =
 {
 	.attr = { .name = "mmio", .mode = 0644 },
@@ -77,11 +90,49 @@
 	return strlen(page);
 }
 
+void do_io_access(int write, int type)
+{
+	unsigned char value=0;
+	if (write) 
+		info("Write 0X5A* to parellel port register!\n");
+	else
+		info("Expect read 0X5A* from parellel port register!\n");
+
+	switch (type){
+	case 0:
+		outb(0x5a, PP_BASE);
+		value = inb(PP_BASE);
+		break;
+	case 1:
+		outw(0x5a, PP_BASE);
+		value = inw(PP_BASE);
+		break;
+	case 2:
+		outl(0x5a, PP_BASE);
+		value = inl(PP_BASE);
+		break;
+	case 4:
+		outw_p(0x5a, PP_BASE);
+		value = inw_p(PP_BASE);
+		break;
+	case 5:
+		outl_p(0x5a, PP_BASE);
+		value = inl_p(PP_BASE);
+		break;
+	default:
+		break;
+	}
+	if (write) 
+		info("%#X was write to parellel port register!\n",value);
+	else
+		info("%#X was read from parellel port register!\n",value);
+}
+
 void do_mm_io_access(int write, int type)
 {
 	unsigned long value=0;
 	if (write) 
-		info("write 0X5A* to MMI/O address");
+		info("Write 0X5A* to MMI/O address");
 	else
 		info("Expect read 0X5A* from MMI/O address");
 
@@ -108,6 +159,70 @@
 
 }
 
+ssize_t io_show(struct subsystem *s, char *page,
+	       size_t count, loff_t off)
+{
+	return 0;
+}
+
+ssize_t io_store(struct subsystem *s, const char *page,
+	       size_t count, loff_t off)
+{
+	char cmd[16];
+	char len[16];	
+	int num = 0;
+
+	if (off) return count;
+
+	num = sscanf(page, "%15s %15s", cmd, len);
+
+	if (num < 0) {
+		err("Unknow command format!");
+		return count;
+	}
+	
+	LOG_TIME;
+	if (!strncmp(cmd, "read", 4)) {
+		if (!strncmp(len, "byte", 4)) {
+			info("COMMAND_IO_READ");
+			do_io_access(0,0);
+			goto done;
+		}
+		if (!strncmp(len, "word", 4)) {
+			info("COMMAND_IO_READW");
+			do_io_access(0,1);
+			goto done;
+		}
+		if (!strncmp(len, "long", 4)) {
+			info("COMMAND_IO_READL");
+			do_io_access(0,2);
+			goto done;
+		}
+		err("Invalid length!");
+	} else if (!strncmp(cmd, "write", 5)) {
+		if (!strncmp(len, "byte", 4)) {
+			info("COMMAND_IO_WRITE");
+			do_io_access(1,0);
+			goto done;
+		}
+		if (!strncmp(len, "word", 4)) {
+			info("COMMAND_IO_WRITEW");
+			do_io_access(1,1);
+			goto done;
+		}
+		if (!strncmp(len, "long", 4)) {
+			info("COMMAND_IO_WRITEL");
+			do_io_access(1,2);
+			goto done;
+		}
+		err("Invalid length!");
+	} else {
+		err("Unknow command!");
+	}
+done:
+	return count;
+}
+
 ssize_t mmio_show(struct subsystem *s, char *page,
 	       size_t count, loff_t off)
 {
@@ -177,6 +292,7 @@
 	dbg("Initialize fith_test.");
 	subsystem_register(&fith_test);
 	subsys_create_file(&fith_test, &mmio);
+	subsys_create_file(&fith_test, &io);
 	
 	mmio_address = ioremap(MM_BASE, 0x8);
 	info("mmio_address = %p", mmio_address);
@@ -189,6 +305,7 @@
 static void __exit fi_test_exit (void)
 {
 	dbg("Cleanup fith_test.");
+	subsys_remove_file(&fith_test, &io);
 	subsys_remove_file(&fith_test, &mmio);
 	subsystem_unregister(&fith_test);
 	iounmap(mmio_address);


Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] Updated: fi_dbp's user mode utility (fi_attach)

[Wang, S. <sta...@in...>]

According to the recent changes in kernel module format, I
rewrited the fi_attach. (We can merge it into "ficl")
Usage: 1. insmod fi_dbp and the tested module
	  2. fi_attach tested_module_name tested_module_file 
	  3. insert fault ......

Compile fi_attach:   gcc -lbfd -ldisasm -o fi_attach fi_attach.c
Here is the source code:

#include <stdio.h>
#include <bfd.h>
#include <libdis.h>

#define CTL "/sys/fault_injection/interceptors/dbp_interceptor/ctl"

int main(int argc, char **argv)
{
	bfd *f;
	asection *sec;
	unsigned char *s;
	struct instr ins;
	char **matching;
	FILE * fp;
	int i;
	int counter=0;
	unsigned long addr[10000];
	char line[4096];
	unsigned long baseaddr = 0;
	bfd_byte *data = 0;
	unsigned int pos = 0;
	unsigned int size = 0;

	if (argc != 3) {
		fprintf(stderr, "Usage: fi_attach modname modfile\n");
		exit(-1);
	}
	
	bfd_init();
	bfd_set_default_target("elf32-i386");
	f = bfd_openr(argv[2], "elf32-i386");
	if (f == NULL) {
		fprintf(stderr, "bfd_openr ERROR!\n");
		return 0;
	}

	if (bfd_check_format_matches (f, bfd_object, &matching)){
		sec = bfd_get_section_by_name(f, ".text");
		if (sec == NULL) {
			fprintf(stderr, "bfd_get_section_by_name ERROR!\n");
			goto err;
		}
	} else {
		fprintf(stderr, "Isn't bdf_object file!\n");
		goto err;
	}

	fp = fopen("/proc/modules", "r");
	if (!fp) {
		fprintf(stderr, "Can't open /proc/modules\n");
		goto err;
	}

	while (fgets(line, sizeof(line), fp)) {
		if (!strncmp(line, argv[1], strlen(argv[1]))) {
			s = line;
			while (*s!='\0') {
			s++;
			}
			while ( *s != ' ') {
				s--;
			}
			s++;
			baseaddr=strtoul(s, NULL, 16);
		} 
	}
	fclose(fp);

	if(baseaddr == 0) {
		fprintf(stderr, "Please insmod first.\n");
		goto err;
	}
	
	data = (bfd_byte *) xmalloc ((size_t) bfd_section_size (f, sec));
	bfd_get_section_contents (f, sec, (PTR) data, 0, bfd_section_size
(f, sec));

	s = data;
	
	disassemble_init(0,INTEL_SYNTAX);
	while(pos < sec->_raw_size)
	{
		size = disassemble_address(s+pos, &ins);
		if ( size > 0 )
		{
			if (!strcmp(ins.mnemonic, "in") ||
!strcmp(ins.mnemonic, "out"))
			{
				addr[counter++] = pos + baseaddr;
			}
			pos += size;
		} else {
			fprintf(stderr, "ERROR!\n");
			return -1;
		}
	}
	disassemble_cleanup();

	for (i=0;i<counter;i++) {
		fp = fopen (CTL, "w+");
		fprintf(fp, "add %lu\n", addr[i]);
		fclose(fp);
	}

err:
	bfd_close(f);
	return 0;
}
  

Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] Updated: fi_dbp

[Wang, S. <sta...@in...>]

I rewrited part of fi_dbp. We get the "mod->module_core" through
"/proc/modules"
now. Here is the patch:


# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.972   -> 1.972.2.3
#	     kernel/module.c	1.39    -> 1.40   
#	drivers/fi/interceptors/dbp/fi_dbp.c	1.9     -> 1.11   
#	include/linux/module.h	1.38    -> 1.39   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/01/07	lo...@ha...	1.973
# make fi_core moduleable
# --------------------------------------------
# 03/01/07	ke...@ke...	1.972.1.1
# fi_core.c:
#   Remove codesegment before detach trigger issue
# --------------------------------------------
# 03/01/07	st...@ma...	1.972.2.1
# Rewrite fi_dbp.
# We get module->module_core from /proc/modules now.
# --------------------------------------------
# 03/01/07	lo...@ha...	1.974
# Merge bk://fau...@fa.../linux-2.5
# into hawk.sh.intel.com:/home/work/2.5-fi
# --------------------------------------------
# 03/01/07	lo...@ha...	1.975
# Add missed license
# --------------------------------------------
# 03/01/07	st...@ma...	1.972.2.3
# Clean up code and fix bug for fi_dbp.
# Can't clear bug fixed.
# --------------------------------------------
#
diff -Nru a/drivers/fi/interceptors/dbp/fi_dbp.c
b/drivers/fi/interceptors/dbp/fi_dbp.c
--- a/drivers/fi/interceptors/dbp/fi_dbp.c	Tue Jan  7 16:43:10 2003
+++ b/drivers/fi/interceptors/dbp/fi_dbp.c	Tue Jan  7 16:43:10 2003
@@ -47,12 +47,12 @@
 #include <asm/uaccess.h>
 #include <linux/smp.h>
 #include <asm/processor.h>
+#include <linux/list.h>
 #include <linux/kprobes.h>
 
 #include <linux/fi.h>
 
 #define MAX_WP 32
-#define MAX_MOD	16
 
 /*define reason of entering do_debug*/
 #define REASON_NOTME	0
@@ -73,11 +73,10 @@
 	unsigned long 	mask;
 };
 
-struct inst_rec_header {
-	char			modname[256];
-	int			counter;
-	struct kprobe		*kprobes;
-}inst_tab[MAX_MOD] = {[0 ... MAX_MOD-1] = {"",0,NULL}};
+struct inst_rec {
+	struct list_head	list;	
+	struct kprobe		kprobe;
+};
 
 struct {
 	struct watchpoint 	wp;
@@ -95,9 +94,7 @@
 }which_inst[NR_CPUS] = {[0 ... NR_CPUS-1] = {-1, -1, 0, 0, NULL, {0, 0, 0,
0}}};
 
 static DECLARE_MUTEX(dbp_sem);
-static int in_used;
-static int mod_index;
-static int ins_index;
+static LIST_HEAD(inst_rec_head);
 static struct interceptor dbp_interceptor;
 
 static int dbp_arm(struct trigger *t);
@@ -105,9 +102,7 @@
 void dbp_corrupt(__u32 dirty, void *data);
 int get_IO_opcode(struct opcode *op, struct pt_regs *regs);
 
-int attach_module(const char *page);
-int detach_module(const char *page);
-void add_ins(const char *page);
+int add_ins(const char *page);
 
 void post_probe_handler(struct kprobe *, struct pt_regs *, unsigned long);
 void pre_probe_handler(struct kprobe *, struct pt_regs *);
@@ -446,133 +441,44 @@
     	return ;
 }
 
-int attach_module(const char *page)
-{
-	int num=0;
-	int i=0;
-	char tmp[16];
-	
-	for(i=0;i<MAX_MOD;i++){
-		if(inst_tab[i].counter <= 0) {
-			break;
-		}
-	}
-	if(i > MAX_MOD) {
-		return -EINVAL;
-	}
-	
-	num = sscanf(page, "%15s %s %d", tmp, inst_tab[i].modname,
&inst_tab[i].counter);
-	if (num != 3) {
-		err("Invalid command format, translated no commands\n");
-		goto err;
-	}
-	
-	if (inst_tab[i].counter == 0) {
-		err("Needn't to attach %s\n", inst_tab[i].modname);
-		goto err;
-	}
-	
-	inst_tab[i].kprobes = (struct
kprobe*)kmalloc(inst_tab[i].counter*(sizeof(struct kprobe)), GFP_KERNEL);
-	if(inst_tab[i].kprobes == NULL) {
-		err("No memory @ %s\n", __FUNCTION__);
-		goto err;
-	}
-	
-	mod_index = i;
-	ins_index = 0;
-	return 0;
-err:
-	inst_tab[i].modname[0] = '\0';
-	inst_tab[i].counter = 0;
-	return -EINVAL;	
-}
-
-void add_ins(const char *page)
+int add_ins(const char *page)
 {
+	struct inst_rec	*inst;
 	char tmp[16];
 	int num=0;
 	unsigned long addr=0;
-	struct module *mod;
 	
 	num = sscanf(page, "%15s %lu", tmp, &addr);
 	if (num != 2) {
 		err("Invalid command format, translated no commands\n");
-		return;
-	}
-	if (ins_index > inst_tab[mod_index].counter - 1) {
-		err("Exceed address table!\n");
-		return;
-	}
-	mod = get_module((const char *)(inst_tab[mod_index].modname));
-	if (!mod) {
-		err("Can not get module, not be loaded?\n");
-		return;
-	}
-	dbg("module_core:%#lx\toff_set:%ld\n",(unsigned
long)mod->module_core, addr);
-	inst_tab[mod_index].kprobes[ins_index].addr = (kprobe_opcode_t
*)(addr + mod->module_core);
-	inst_tab[mod_index].kprobes[ins_index].pre_handler =
pre_probe_handler;
-	inst_tab[mod_index].kprobes[ins_index].post_handler =
post_probe_handler;
-	inst_tab[mod_index].kprobes[ins_index].fault_handler = NULL;
-	if ( register_kprobe(&(inst_tab[mod_index].kprobes[ins_index])) < 0
)	
-	{
-		err("register_kprobe failed @ %s\n", __FUNCTION__);
-		return;
-	}
-	ins_index++;
-	return;
-}
-int detach_module(const char *page)
-{
-	int num=0;
-	int i=0;
-	int j=0;
-	char tmp[16];
-	char modname[256];
-	
-	num = sscanf(page, "%15s %s", tmp, modname);
-	if (num != 2) {
-		err("Invalid command format, translated no commands\n");
-		return 0;	
+		return -EINVAL;
 	}
 
-	for(i=0;i<MAX_MOD;i++){
-		if(!strcmp(inst_tab[i].modname, modname)) {
-			break;
-		}
-	}
-	if(i > MAX_MOD) {
-		return -EINVAL;
+	inst=(struct inst_rec *)kmalloc(sizeof(struct inst_rec),
GFP_KERNEL);
+	if (!inst) {
+		err("Allocate memory failed.\n");
+		return -ENOMEM;
 	}
-	
-	for(j=0;j<inst_tab[i].counter;j++) {
-		unregister_kprobe(&(inst_tab[i].kprobes[j]));	
-	} 
-	inst_tab[i].counter = 0;
-	inst_tab[i].modname[0] = '\0';
-	if (inst_tab[i].kprobes)
+		
+	inst->kprobe.addr = (kprobe_opcode_t *)addr;
+	inst->kprobe.pre_handler = pre_probe_handler;
+	inst->kprobe.post_handler = post_probe_handler;
+	inst->kprobe.fault_handler = NULL;
+	if ( register_kprobe(&(inst->kprobe)) < 0 )	
 	{
-		kfree(inst_tab[i].kprobes);
+		kfree(inst);
+		err("register_kprobe failed @ %s\n", __FUNCTION__);
+		return -EINVAL;
 	}
+
+	list_add(&inst->list, &inst_rec_head);
 	return 0;
 }
 
 static ssize_t ctl_show(struct interceptor * p, char * page, 
 			 size_t count, loff_t off)
 {
-	int i=0;
-	int n=0;
-	int j;
-	if (off)
-		return 0;
-	n += sprintf (page, "Module\tInstructions\n");
-	while (inst_tab[i].modname[0]!='\0' && i < MAX_MOD) {
-		n += sprintf (page+n, "%s\t%d\n", inst_tab[i].modname,
inst_tab[i].counter);
-		for(j=0;j<inst_tab[i].counter;j++){
-			n += sprintf (page+n, "addr:\t%#lx\n", (unsigned
long)inst_tab[i].kprobes[j].addr);
-		}
-		i++;
-	}
-	return n;
+	return 0;
 }
 
 static ssize_t ctl_store(struct interceptor * p, const char * page, 
@@ -580,66 +486,46 @@
 {
 	char ctl[16];
 	int num;
+	int error=0;
 	
 	if (off)
 		return 0;	
 
+	down(&dbp_sem);
 	num = sscanf(page, "%15s", ctl);
 	if (!num) {
 		err("Invalid command format, translated no commands\n");
-		return count;	
+		error = -EINVAL;
+		goto err;
 	}
 		
 	if (!strncmp(ctl, "add", 3)) {
-		down(&dbp_sem);
-		if (!in_used) {
+		error = add_ins(page);
+		if(error==0){
 			up(&dbp_sem);
-			err("Use attach first.\n");
 			return count;
+		} else {
+			goto err;
 		}
-		add_ins(page);
-		up(&dbp_sem);
-		return count;
 	}
 
-	if (!strncmp(ctl, "attach", 6)) {
-		down(&dbp_sem);
-		if (in_used) {
-			up(&dbp_sem);	
-			err("FI_DBP is busy.(Attaching %s)\n",
inst_tab[mod_index].modname);
-			return count;
-		}
-		if(attach_module(page)==0)
-			in_used++;
-		up(&dbp_sem);
-		return count;
-	}
+	if (!strncmp(ctl, "clear", 5)) {
+		struct inst_rec *inst;
 
-	if (!strncmp(ctl, "end", 3)) {
-		down(&dbp_sem);
-		if (!in_used) {
-			up(&dbp_sem);
-			err("No attaching action to be ended.\n");
-			return count;
+		while (!list_empty(&inst_rec_head)) {
+			inst=list_entry(inst_rec_head.next, struct inst_rec,
list);
+			list_del(&inst->list);
+			unregister_kprobe(&inst->kprobe);
+			kfree(inst);
 		}
-		in_used--;
-		up(&dbp_sem);
-		return count;
-	}
-
-	if (!strncmp(ctl, "detach", 6)) {
-		down(&dbp_sem);
-		if (in_used) {
-			up(&dbp_sem);	
-			err("FI_DBP is busy.(Attaching %s)\n",
inst_tab[mod_index].modname);
+			up(&dbp_sem);
 			return count;
-		}
-		detach_module(page);
-		up(&dbp_sem);
-		return count;
 	}
 	err("Unknow command %s\n", page);
-	return count;
+	error = -EINVAL;
+err:
+	up(&dbp_sem);
+	return error;
 }
 
 static struct interceptor_attribute attr_ctl = {
@@ -657,8 +543,6 @@
 
 static int __init dbp_start(void)
 {
-	int i;
-
 	if (fi_register_interceptor(&dbp_interceptor)) {
 		dbg("Failed to register DBP Interceptor");
 		return -EINVAL;
@@ -666,31 +550,21 @@
 	
 	sysfs_create_file(&dbp_interceptor.kobj, &attr_ctl.attr);
 
-	for (i=0;i<MAX_MOD;i++) {
-		inst_tab[i].modname[0]='\0';
-	}
-	
 	EXPORT_NO_SYMBOLS;
 	return 0;
 }
 
 static void __exit dbp_stop(void)
 {
-	int i;
-	int j;
+	struct inst_rec *inst;
 
-	for(i=0;i<MAX_MOD;i++)
-	{
-		for(j=0;j<inst_tab[i].counter;j++) {
-			unregister_kprobe(&(inst_tab[i].kprobes[j]));	
-		} 
-		inst_tab[i].counter = 0;
-		inst_tab[i].modname[0] = '\0';
-		if (inst_tab[i].kprobes)
-		{
-			kfree(inst_tab[i].kprobes);
-		}
+	if (!list_empty(&inst_rec_head)) {
+		inst=list_entry(inst_rec_head.next, struct inst_rec, list);
+		list_del(&inst->list);
+		unregister_kprobe(&inst->kprobe);
+		kfree(inst);
 	}
+
 	sysfs_remove_file(&dbp_interceptor.kobj, &attr_ctl.attr);
 	fi_unregister_interceptor(&dbp_interceptor);
 	return;
diff -Nru a/include/linux/module.h b/include/linux/module.h
--- a/include/linux/module.h	Tue Jan  7 16:43:10 2003
+++ b/include/linux/module.h	Tue Jan  7 16:43:10 2003
@@ -315,7 +315,6 @@
 /* For extable.c to search modules' exception tables. */
 const struct exception_table_entry *search_module_extables(unsigned long
addr);
 
-extern struct module *get_module(const char *modname);
 #else /* !CONFIG_MODULES... */
 #define EXPORT_SYMBOL(sym)
 #define EXPORT_SYMBOL_GPL(sym)
@@ -360,8 +359,6 @@
 {
 	return NULL;
 }
-
-static inline struct module *get_module(const char *modname){ return NULL;
}
 #endif /* CONFIG_MODULES */
 
 #ifdef MODULE
diff -Nru a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c	Tue Jan  7 16:43:10 2003
+++ b/kernel/module.c	Tue Jan  7 16:43:10 2003
@@ -128,16 +128,6 @@
 	return NULL;
 }
 
-struct module *get_module(const char *name)
-{
-	struct module *mod;
-	down(&module_mutex);
-	mod = find_module(name);
-	up(&module_mutex);
-	return mod;
-}
-EXPORT_SYMBOL_GPL(get_module);
-
 #ifdef CONFIG_MODULE_UNLOAD
 /* Init the unload section of the module. */
 static void module_unload_init(struct module *mod)
@@ -1432,6 +1422,7 @@
 	seq_printf(m, "%s %lu",
 		   mod->name, mod->init_size + mod->core_size);
 	print_unload_info(m, mod);
+	seq_printf(m, " %p", mod->module_core);
 	seq_printf(m, "\n");
 	return 0;
 }

Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation

[Fault-injection-developer] RE: About push e100 test cases to our FITH tree

[Zhuang, L. <lou...@in...>]

These code segment can demostrate some complex usage for FITH, Maybe we can
create 'e100_test' directory under 'codesegments' for these test. 

-----Original Message-----
From: Gao, Kevin 
Sent: Tuesday, January 07, 2003 4:00 PM
To: 'fau...@li...'; Zhuang, Louis; Wang,
Frank; Wang, Stanley
Subject: About push e100 test cases to our FITH tree


Now FITH is used to test e100 driver for a period of time, 
and there are some test cases for e100 still on another tracking.
Why not I push them into our FITH's tree.
Is there any issue? or idea?:)
 
 
Kevin

[Fault-injection-developer] About push e100 test cases to our FITH tree

[Gao, K. <kev...@in...>]

Now FITH is used to test e100 driver for a period of time, 
and there are some test cases for e100 still on another tracking.
Why not I push them into our FITH's tree.
Is there any issue? or idea?:)
 
 
Kevin

[Fault-injection-developer] RE: semaphore usage in xxx_store()

[Lynch, R. <rus...@in...>]

> I think it is sysfs' responsibility to serialize these 
> accesses... Maybe we need to take a talk with Randy Dunlap in LKML

That doesn't make sense.  Why would sysfs be different from all of the 
other file systems in Linux?
 
If you poke around the kernel you will find lots of examples where 
attribute implementers take care of syncing.  

    -rustyl

[Fault-injection-developer] RE: semaphore usage in xxx_store()

[Zhuang, L. <lou...@in...>]

> I'm not sure which xxx_store() function you are talking about.
> In general if a store() operation is triggering some action
> that parallel user write operations (i.e. the same store()
> being called at the same time) might cause wacky side effects
> then I would serialize the store() operations with a semaphore.
I think it is sysfs' responsibility to serialize these accesses... Maybe we
need to take a talk with Randy Dunlap in LKML.

> 
> As a result I tend to use a semaphore in my boiler plate 
> attribute code, but if we do not need the semaphore then we
> should drop it.
 

[Fault-injection-developer] File layout changes have been made

[Rusty L. <ru...@li...>]

The new file layout as was discussed last week on the 
mailing list and in the README are now in place.  All code
is now rooted in drivers/fi/ as documented in drivers/README.

I did make a couple of tweaks to what I said last week, but
they are minor and are intended to both keep names consistent
and let me take advantage of bash command line completion.

    -rustyl

[Fault-injection-developer] RE: semaphore usage in xxx_store()

[Lynch, R. <rus...@in...>]

I'm not sure which xxx_store() function you are talking about.
In general if a store() operation is triggering some action
that parallel user write operations (i.e. the same store()
being called at the same time) might cause wacky side effects
then I would serialize the store() operations with a semaphore.

As a result I tend to use a semaphore in my boiler plate 
attribute code, but if we do not need the semaphore then we
should drop it.

    --rustyl

> -----Original Message-----
> From: Zhuang, Louis 
> Sent: Monday, January 06, 2003 1:33 AM
> To: Lynch, Rusty
> Cc: FITHML (E-mail)
> Subject: semaphore usage in xxx_store()
> 
> 
> Dear Rusty,
> 	I noticed you always down an semaphore in attribute 
> store function. But I wonder if it is too paranoia... The 
> only race condition I can image is somebody write the sysfs 
> file with unloading module... But kernel/module.c should be 
> the right place to care about it. If it is broken by that 
> condition, we should challenge another Rusty. ;->  Could you 
> give me some light about it? 
> 
> Yours truly,
> Louis Zhuang
> ---------------
> Fault Injection Test Harness Project
> BK tree: http://fault-injection.bkbits.net/linux-2.5
> Home Page: http://sf.net/projects/fault-injection
> 

RE: [Fault-injection-developer] RE: About delete the trigger, cod esegment

[Lynch, R. <rus...@in...>]

If I understood correctly, Kevin also voiced a concern over the timing of 
triggers being removed.  We could better handle this by fixing the trigger
'ctl' file to read multiple lines with one command per line so that all the
delete request could at least come in the same write operation.

    -rustyl

> -----Original Message-----
> From: Wang, Stanley [mailto:sta...@in...]
> Sent: Sunday, January 05, 2003 10:07 PM
> To: Gao, Kevin; 
> 'fau...@li...'; Zhuang, 
> Louis; Wang, Frank
> Subject: [Fault-injection-developer] RE: About delete the 
> trigger, codesegment
> 
> 
> I think that the faultset won't be eliminated :) 
> We must make FITH be compatible with our earier release.
> Hence we must us the fsml to describe the faultset. And user
> needn't add and remove all triggers in turn.
> Though the faultset concept means nothing to FITH's kernel 
> part(I suggest
> to implement it in FITH's command line tool).
> 
> Cheers!
> Stan
> 
> > -----Original Message-----
> > From: Gao, Kevin 
> > Sent: 2003-01-06 13:45
> > To: 'fau...@li...'; 
> Zhuang, Louis;
> > Wang, Frank; Wang, Stanley
> > Subject: About delete the trigger, codesegment
> > 
> > 
> > If we want to stop our corruption of driver, we always remove 
> > of disable the triggers.
> > In past time, There are some triggers in one faultset. When 
> > user wants to do a 
> > fault injection for one driver, he will put all the related 
> > trigger into one faultset. So all the
> > trigger of the fault injection can be inserted, removed together.
> > 
> > Now there is no "faultset" concept, we only use trigger to 
> > inject fault. For one fault injection
> > operation. User should inject/remove the related trigger by 
> > turn. If there is any issue/problem?
> > For example, when we remove one trigger, before remove other 
> > related trigger, if the remained 
> > trigger will cause some kernel, address or other potential issue?
> > 
> > For complex fault, One FI operation must be have many 
> > triggers. So in order to make user 
> > control there FI operation easily and clearly, I think 
> > "faultset" concept is still useful
> > 
> > Regards
> > 
> > Kevin
> > 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Fault-injection-developer mailing list
> Fau...@li...
> https://lists.sourceforge.net/lists/listinfo/fault-injection-developer
> 

[Fault-injection-developer] semaphore usage in xxx_store()

[Zhuang, L. <lou...@in...>]

Dear Rusty,
	I noticed you always down an semaphore in attribute store function.
But I wonder if it is too paranoia... The only race condition I can image is
somebody write the sysfs file with unloading module... But kernel/module.c
should be the right place to care about it. If it is broken by that
condition, we should challenge another Rusty. ;->  Could you give me some
light about it? 

Yours truly,
Louis Zhuang
---------------
Fault Injection Test Harness Project
BK tree: http://fault-injection.bkbits.net/linux-2.5
Home Page: http://sf.net/projects/fault-injection

[Fault-injection-developer] RE: About delete the trigger, codesegment

[Wang, S. <sta...@in...>]

I think that the faultset won't be eliminated :) 
We must make FITH be compatible with our earier release.
Hence we must us the fsml to describe the faultset. And user
needn't add and remove all triggers in turn.
Though the faultset concept means nothing to FITH's kernel part(I suggest
to implement it in FITH's command line tool).

Cheers!
Stan

> -----Original Message-----
> From: Gao, Kevin 
> Sent: 2003-01-06 13:45
> To: 'fau...@li...'; Zhuang, Louis;
> Wang, Frank; Wang, Stanley
> Subject: About delete the trigger, codesegment
> 
> 
> If we want to stop our corruption of driver, we always remove 
> of disable the triggers.
> In past time, There are some triggers in one faultset. When 
> user wants to do a 
> fault injection for one driver, he will put all the related 
> trigger into one faultset. So all the
> trigger of the fault injection can be inserted, removed together.
> 
> Now there is no "faultset" concept, we only use trigger to 
> inject fault. For one fault injection
> operation. User should inject/remove the related trigger by 
> turn. If there is any issue/problem?
> For example, when we remove one trigger, before remove other 
> related trigger, if the remained 
> trigger will cause some kernel, address or other potential issue?
> 
> For complex fault, One FI operation must be have many 
> triggers. So in order to make user 
> control there FI operation easily and clearly, I think 
> "faultset" concept is still useful
> 
> Regards
> 
> Kevin
> 

[Fault-injection-developer] About delete the trigger, codesegment

[Gao, K. <kev...@in...>]

If we want to stop our corruption of driver, we always remove of disable the
triggers.
In past time, There are some triggers in one faultset. When user wants to do
a 
fault injection for one driver, he will put all the related trigger into one
faultset. So all the
trigger of the fault injection can be inserted, removed together.

Now there is no "faultset" concept, we only use trigger to inject fault. For
one fault injection
operation. User should inject/remove the related trigger by turn. If there
is any issue/problem?
For example, when we remove one trigger, before remove other related
trigger, if the remained 
trigger will cause some kernel, address or other potential issue?

For complex fault, One FI operation must be have many triggers. So in order
to make user 
control there FI operation easily and clearly, I think "faultset" concept is
still useful

Regards

Kevin

RE: [Fault-injection-developer] [RFC] command in '/sys/triggers/c tl' is changed

[Zhuang, L. <lou...@in...>]

> Before, I had envisioned a trigger being created for a 'type' 
> of interceptor, 
 The very reason is 'the type of interceptor is duplicated and confused with
Watchpoint Type'. Users, even developer like me ;-), are confused why there
are interceptor type in param 3 and watchpoint type in param 5.

> not a specific interceptor.  This allows for many-to-one 
> relationship between
> interceptors and triggers, and also allows triggers and 
> interceptors to be
> install independent of each other.
> 
> Your proposal infers a one-to-one relationship between 
According to the definition of interceptor, "a component that knows how to
intercept some specific type of kernel level event or action to enable the
fault injection core to 'hook' into event or action and take some action", I
can not find out any meaningful usage of one-to-many relationship between
trigger and interceptor. 
And more, there might be several implementation for a kind of interceptor
(DBP for PIO and DR for PIO, for example). But a trigger should only attach
one of them.

> triggers and interceptors
> and requires interceptors to be installed before triggers are 
> installed.
It is one of my concerns indeed. Your explanation is much clearer than mine.
;-> If needed, the trigger can be inserted before interceptor is loaded
whether the specified param is type or name.

> 
> So... is this an unexpected side effect or an unstated assumption?
Yes, maybe we should put these information into README

> 
> Don't get me wrong.  I'm not sure that I am against 
> formalizing a one-to-one
> relation, but we need for this to not just be an undocumented 
> side effect, but
> an up front design decision so we are all working towards the 
> same goal.
> 
> Specifically:
> 
> What SHOULD be our relationship between triggers and interceptors?
>   a. one trigger associated with one interceptor
>   b. one trigger associated with many interceptors
> 
> What SHOULD be our relationship between triggers and code segments?
>   a. one trigger associated with one code segment
>   b. one trigger associated with many code segments
> 
> My opinion:
> 
> I think we could keep a fairly simple yet flexible design by 
> choosing (a) a 
> single trigger always be associated with a single 
> interceptor, and (b) allow
> for multiple code segments to be attached to any given trigger.
Aggree! ;-> That's my preference too.

> 
> In fact we could totally drop the whole notion of an 
> interceptor 'type' and 
> push all policy statements like 'it does not make sense to 
> associate code 
> segment A with interceptor B' to user space.  
If we use interceptor 'name' in trigger, it is not a policy any more, it is
a *appointment*. So we do not need to guess what user want in kernel part.
Anyway, an easy-to-use utility is always welcome.

[Fault-injection-developer] Discussion about kernel module supporting with IBM's Rusty Russel l

[Wang, S. <sta...@in...>]

FYI

Your Sincerely,
Stanley Wang 

SW Engineer, Intel Corporation.
Intel China Software Lab. 
Tel: 021-52574545 ext. 1171 
iNet: 8-752-1171 
 
Opinions expressed are those of the author and do not represent Intel
Corporation