* [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET @ 2010-06-29 15:32 Jan Beulich 2010-06-30 14:52 ` George Dunlap 0 siblings, 1 reply; 11+ messages in thread From: Jan Beulich @ 2010-06-29 15:32 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel [-- Attachment #1: Type: text/plain, Size: 940 bytes --] This wasn't defined correctly, thus allowing in the num_online_cpus() == NR_CPUS case to pass a corrupted MFN to Dom0. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2010-06-15.orig/xen/common/trace.c 2010-06-28 11:58:37.000000000 +0200 +++ 2010-06-15/xen/common/trace.c 2010-06-28 11:58:37.000000000 +0200 @@ -51,7 +51,7 @@ static struct t_info *t_info; #define T_INFO_PAGES 2 /* Size fixed at 2 pages for now. */ #define T_INFO_SIZE ((T_INFO_PAGES)*(PAGE_SIZE)) /* t_info.tbuf_size + list of mfn offsets + 1 to round up / sizeof uint32_t */ -#define T_INFO_FIRST_OFFSET ((sizeof(int16_t) + NR_CPUS * sizeof(int16_t) + 1) / sizeof(uint32_t)) +#define T_INFO_FIRST_OFFSET (((2 + NR_CPUS) * sizeof(uint16_t)) / sizeof(uint32_t)) static DEFINE_PER_CPU_READ_MOSTLY(struct t_buf *, t_bufs); static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, t_data); static DEFINE_PER_CPU_READ_MOSTLY(spinlock_t, t_lock); [-- Attachment #2: trace-t_info-first-offset.patch --] [-- Type: text/plain, Size: 934 bytes --] This wasn't defined correctly, thus allowing in the num_online_cpus() == NR_CPUS case to pass a corrupted MFN to Dom0. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2010-06-15.orig/xen/common/trace.c 2010-06-28 11:58:37.000000000 +0200 +++ 2010-06-15/xen/common/trace.c 2010-06-28 11:58:37.000000000 +0200 @@ -51,7 +51,7 @@ static struct t_info *t_info; #define T_INFO_PAGES 2 /* Size fixed at 2 pages for now. */ #define T_INFO_SIZE ((T_INFO_PAGES)*(PAGE_SIZE)) /* t_info.tbuf_size + list of mfn offsets + 1 to round up / sizeof uint32_t */ -#define T_INFO_FIRST_OFFSET ((sizeof(int16_t) + NR_CPUS * sizeof(int16_t) + 1) / sizeof(uint32_t)) +#define T_INFO_FIRST_OFFSET (((2 + NR_CPUS) * sizeof(uint16_t)) / sizeof(uint32_t)) static DEFINE_PER_CPU_READ_MOSTLY(struct t_buf *, t_bufs); static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, t_data); static DEFINE_PER_CPU_READ_MOSTLY(spinlock_t, t_lock); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-29 15:32 [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET Jan Beulich @ 2010-06-30 14:52 ` George Dunlap 2010-06-30 15:15 ` Jan Beulich 0 siblings, 1 reply; 11+ messages in thread From: George Dunlap @ 2010-06-30 14:52 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel [-- Attachment #1: Type: text/plain, Size: 1493 bytes --] Good catch. This fix produces the correct index, but: * It's not as clear, IMHO, where the math is coming from * I think it may give the wrong result if the t_info struct ever changes (e.g., more data before the cpu offset list) The bug in the original math was that I should have added 3 to round up, rather than 1. I'm attaching a patch that will hopefully fix the bug and make it more clear. Thoughts? -George On Tue, Jun 29, 2010 at 4:32 PM, Jan Beulich <JBeulich@novell.com> wrote: > This wasn't defined correctly, thus allowing in the > num_online_cpus() == NR_CPUS case to pass a corrupted MFN to > Dom0. > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > > --- 2010-06-15.orig/xen/common/trace.c 2010-06-28 11:58:37.000000000 +0200 > +++ 2010-06-15/xen/common/trace.c 2010-06-28 11:58:37.000000000 +0200 > @@ -51,7 +51,7 @@ static struct t_info *t_info; > #define T_INFO_PAGES 2 /* Size fixed at 2 pages for now. */ > #define T_INFO_SIZE ((T_INFO_PAGES)*(PAGE_SIZE)) > /* t_info.tbuf_size + list of mfn offsets + 1 to round up / sizeof uint32_t */ > -#define T_INFO_FIRST_OFFSET ((sizeof(int16_t) + NR_CPUS * sizeof(int16_t) + 1) / sizeof(uint32_t)) > +#define T_INFO_FIRST_OFFSET (((2 + NR_CPUS) * sizeof(uint16_t)) / sizeof(uint32_t)) > static DEFINE_PER_CPU_READ_MOSTLY(struct t_buf *, t_bufs); > static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, t_data); > static DEFINE_PER_CPU_READ_MOSTLY(spinlock_t, t_lock); > > > > [-- Attachment #2: trace-t_info-first-offset-v2.patch --] [-- Type: text/x-diff, Size: 1308 bytes --] Fix T_INFO_FIRST_OFFSET calculation This wasn't defined correctly, thus allowing in the num_online_cpus() == NR_CPUS case to pass a corrupted MFN to Dom0. Reported-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> diff -r 39f71ef422bd xen/common/trace.c --- a/xen/common/trace.c Tue Jun 29 17:23:53 2010 +0100 +++ b/xen/common/trace.c Wed Jun 30 15:50:33 2010 +0100 @@ -50,8 +50,11 @@ static struct t_info *t_info; #define T_INFO_PAGES 2 /* Size fixed at 2 pages for now. */ #define T_INFO_SIZE ((T_INFO_PAGES)*(PAGE_SIZE)) -/* t_info.tbuf_size + list of mfn offsets + 1 to round up / sizeof uint32_t */ -#define T_INFO_FIRST_OFFSET ((sizeof(int16_t) + NR_CPUS * sizeof(int16_t) + 1) / sizeof(uint32_t)) +/* Return the number of elements _type necessary to store at least _x bytes of data + * i.e., sizeof(_type) * ans >= _x. */ +#define fit_to_type(_type, _x) (((_x)+sizeof(_type)-1) / sizeof(_type)) +/* t_info.tbuf_size + list of mfn offsets rounded up / sizeof uint32_t */ +#define T_INFO_FIRST_OFFSET fit_to_type( uint32_t, (sizeof(int16_t) + NR_CPUS * sizeof(int16_t)) ) static DEFINE_PER_CPU_READ_MOSTLY(struct t_buf *, t_bufs); static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, t_data); static DEFINE_PER_CPU_READ_MOSTLY(spinlock_t, t_lock); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 14:52 ` George Dunlap @ 2010-06-30 15:15 ` Jan Beulich 2010-06-30 15:28 ` George Dunlap 0 siblings, 1 reply; 11+ messages in thread From: Jan Beulich @ 2010-06-30 15:15 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 30.06.10 at 16:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > Good catch. This fix produces the correct index, but: > * It's not as clear, IMHO, where the math is coming from > * I think it may give the wrong result if the t_info struct ever > changes (e.g., more data before the cpu offset list) That part your patch doesn't address either - rather than sizeof(uint16_t) as the first part of the expression you'd need to use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset). Btw., didn't we agree that public headers shouldn't make use of language extensions? struct t_info uses a variable sized array, which is an extension (standard only in C99). > The bug in the original math was that I should have added 3 to round > up, rather than 1. Correct. > I'm attaching a patch that will hopefully fix the bug and make it more > clear. Thoughts? Leaving aside the comment above this looks okay to me. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 15:15 ` Jan Beulich @ 2010-06-30 15:28 ` George Dunlap 2010-06-30 16:10 ` George Dunlap 0 siblings, 1 reply; 11+ messages in thread From: George Dunlap @ 2010-06-30 15:28 UTC (permalink / raw) To: Jan Beulich; +Cc: Keir, xen-devel@lists.xensource.com, Fraser Jan Beulich wrote: > That part your patch doesn't address either - rather than > sizeof(uint16_t) as the first part of the expression you'd need to > use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset). > I was assuming that when someone changed struct t_info that they'd modify this macro as well; I suppose then that the two complaints are really different aspects of the same one -- that it might not be clear to the person who adjusts struct t_info how to translate those changes into T_INFO_FIRST_OFFSET. I think this way is more clear. I suppose even better might be to calculate t_info.mfn_mfn_offset[NR_CPUS] (or perhaps ...[num_possible_cpus]). Hmm... let me see what I can come up with. > Btw., didn't we agree that public headers shouldn't make use of > language extensions? struct t_info uses a variable sized array, > which is an extension (standard only in C99). > I'm not an expert in this. It's lot more hassle to lay out the data the way I'd like without it. I'll defer judgment to Keir. -George ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 15:28 ` George Dunlap @ 2010-06-30 16:10 ` George Dunlap 2010-06-30 16:12 ` George Dunlap 0 siblings, 1 reply; 11+ messages in thread From: George Dunlap @ 2010-06-30 16:10 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel@lists.xensource.com, Keir Fraser, Jan Beulich [-- Attachment #1: Type: text/plain, Size: 1494 bytes --] Here's a version that calculates t_info_first_offset during initialization, based on the actual layout of struct t_info and NR_CPUs. -George On Wed, Jun 30, 2010 at 4:28 PM, George Dunlap <george.dunlap@eu.citrix.com> wrote: > Jan Beulich wrote: >> >> That part your patch doesn't address either - rather than >> sizeof(uint16_t) as the first part of the expression you'd need to >> use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset). >> > > I was assuming that when someone changed struct t_info that they'd modify > this macro as well; I suppose then that the two complaints are really > different aspects of the same one -- that it might not be clear to the > person who adjusts struct t_info how to translate those changes into > T_INFO_FIRST_OFFSET. I think this way is more clear. > > I suppose even better might be to calculate t_info.mfn_mfn_offset[NR_CPUS] > (or perhaps ...[num_possible_cpus]). Hmm... let me see what I can come up > with. >> >> Btw., didn't we agree that public headers shouldn't make use of >> language extensions? struct t_info uses a variable sized array, >> which is an extension (standard only in C99). >> > > I'm not an expert in this. It's lot more hassle to lay out the data the way > I'd like without it. I'll defer judgment to Keir. > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > [-- Attachment #2: trace-t_info-first-offset-v3.patch --] [-- Type: text/x-diff, Size: 2815 bytes --] Fix T_INFO_FIRST_OFFSET calculation This wasn't defined correctly, thus allowing in the num_online_cpus() == NR_CPUS case to pass a corrupted MFN to Dom0. Reported-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> diff -r 39f71ef422bd xen/common/trace.c --- a/xen/common/trace.c Tue Jun 29 17:23:53 2010 +0100 +++ b/xen/common/trace.c Wed Jun 30 17:01:59 2010 +0100 @@ -50,12 +50,11 @@ static struct t_info *t_info; #define T_INFO_PAGES 2 /* Size fixed at 2 pages for now. */ #define T_INFO_SIZE ((T_INFO_PAGES)*(PAGE_SIZE)) -/* t_info.tbuf_size + list of mfn offsets + 1 to round up / sizeof uint32_t */ -#define T_INFO_FIRST_OFFSET ((sizeof(int16_t) + NR_CPUS * sizeof(int16_t) + 1) / sizeof(uint32_t)) static DEFINE_PER_CPU_READ_MOSTLY(struct t_buf *, t_bufs); static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, t_data); static DEFINE_PER_CPU_READ_MOSTLY(spinlock_t, t_lock); static int data_size; +static u32 t_info_first_offset __read_mostly; /* High water mark for trace buffers; */ /* Send virtual interrupt when buffer level reaches this point */ @@ -75,13 +74,29 @@ /* which tracing events are enabled */ static u32 tb_event_mask = TRC_ALL; +/* Return the number of elements _type necessary to store at least _x bytes of data + * i.e., sizeof(_type) * ans >= _x. */ +#define fit_to_type(_type, _x) (((_x)+sizeof(_type)-1) / sizeof(_type)) + +static void calc_tinfo_first_offset(void) +{ + int offset_in_bytes; + + offset_in_bytes = ((char *)&((struct t_info *)(NULL))->mfn_offset[NR_CPUS]) - (char *)(NULL); + + t_info_first_offset = fit_to_type(uint32_t, offset_in_bytes); + + printk("%s: NR_CPUs %d, offset_in_bytes %d, t_info_first_offset %u\n", + __func__, NR_CPUS, offset_in_bytes, (unsigned)t_info_first_offset); +} + /** * check_tbuf_size - check to make sure that the proposed size will fit * in the currently sized struct t_info. */ static inline int check_tbuf_size(int size) { - return (num_online_cpus() * size + T_INFO_FIRST_OFFSET) > (T_INFO_SIZE / sizeof(uint32_t)); + return (num_online_cpus() * size + t_info_first_offset) > (T_INFO_SIZE / sizeof(uint32_t)); } /** @@ -100,7 +115,7 @@ unsigned long nr_pages; /* Start after a fixed-size array of NR_CPUS */ uint32_t *t_info_mfn_list = (uint32_t *)t_info; - int offset = T_INFO_FIRST_OFFSET; + int offset = t_info_first_offset; BUG_ON(check_tbuf_size(opt_tbuf_size)); @@ -293,6 +308,10 @@ void __init init_trace_bufs(void) { int i; + + /* Calculate offset in u32 of first mfn */ + calc_tinfo_first_offset(); + /* t_info size fixed at 2 pages for now. That should be big enough / small enough * until it's worth making it dynamic. */ t_info = alloc_xenheap_pages(1, 0); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 16:10 ` George Dunlap @ 2010-06-30 16:12 ` George Dunlap 2010-06-30 17:14 ` Keir Fraser 2010-07-01 9:49 ` Jan Beulich 0 siblings, 2 replies; 11+ messages in thread From: George Dunlap @ 2010-06-30 16:12 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel@lists.xensource.com, Keir Fraser, Jan Beulich [-- Attachment #1: Type: text/plain, Size: 1725 bytes --] Oops, please use this version, which used the appropraite gkprintk() settings... -George On Wed, Jun 30, 2010 at 5:10 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > Here's a version that calculates t_info_first_offset during > initialization, based on the actual layout of struct t_info and > NR_CPUs. > > -George > > On Wed, Jun 30, 2010 at 4:28 PM, George Dunlap > <george.dunlap@eu.citrix.com> wrote: >> Jan Beulich wrote: >>> >>> That part your patch doesn't address either - rather than >>> sizeof(uint16_t) as the first part of the expression you'd need to >>> use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset). >>> >> >> I was assuming that when someone changed struct t_info that they'd modify >> this macro as well; I suppose then that the two complaints are really >> different aspects of the same one -- that it might not be clear to the >> person who adjusts struct t_info how to translate those changes into >> T_INFO_FIRST_OFFSET. I think this way is more clear. >> >> I suppose even better might be to calculate t_info.mfn_mfn_offset[NR_CPUS] >> (or perhaps ...[num_possible_cpus]). Hmm... let me see what I can come up >> with. >>> >>> Btw., didn't we agree that public headers shouldn't make use of >>> language extensions? struct t_info uses a variable sized array, >>> which is an extension (standard only in C99). >>> >> >> I'm not an expert in this. It's lot more hassle to lay out the data the way >> I'd like without it. I'll defer judgment to Keir. >> >> -George >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >> > [-- Attachment #2: trace-t_info-first-offset-v3.patch --] [-- Type: text/x-diff, Size: 2830 bytes --] Fix T_INFO_FIRST_OFFSET calculation This wasn't defined correctly, thus allowing in the num_online_cpus() == NR_CPUS case to pass a corrupted MFN to Dom0. Reported-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> diff -r 39f71ef422bd xen/common/trace.c --- a/xen/common/trace.c Tue Jun 29 17:23:53 2010 +0100 +++ b/xen/common/trace.c Wed Jun 30 17:11:10 2010 +0100 @@ -50,12 +50,11 @@ static struct t_info *t_info; #define T_INFO_PAGES 2 /* Size fixed at 2 pages for now. */ #define T_INFO_SIZE ((T_INFO_PAGES)*(PAGE_SIZE)) -/* t_info.tbuf_size + list of mfn offsets + 1 to round up / sizeof uint32_t */ -#define T_INFO_FIRST_OFFSET ((sizeof(int16_t) + NR_CPUS * sizeof(int16_t) + 1) / sizeof(uint32_t)) static DEFINE_PER_CPU_READ_MOSTLY(struct t_buf *, t_bufs); static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, t_data); static DEFINE_PER_CPU_READ_MOSTLY(spinlock_t, t_lock); static int data_size; +static u32 t_info_first_offset __read_mostly; /* High water mark for trace buffers; */ /* Send virtual interrupt when buffer level reaches this point */ @@ -75,13 +74,29 @@ /* which tracing events are enabled */ static u32 tb_event_mask = TRC_ALL; +/* Return the number of elements _type necessary to store at least _x bytes of data + * i.e., sizeof(_type) * ans >= _x. */ +#define fit_to_type(_type, _x) (((_x)+sizeof(_type)-1) / sizeof(_type)) + +static void calc_tinfo_first_offset(void) +{ + int offset_in_bytes; + + offset_in_bytes = ((char *)&((struct t_info *)(NULL))->mfn_offset[NR_CPUS]) - (char *)(NULL); + + t_info_first_offset = fit_to_type(uint32_t, offset_in_bytes); + + gdprintk(XENLOG_INFO, "%s: NR_CPUs %d, offset_in_bytes %d, t_info_first_offset %u\n", + __func__, NR_CPUS, offset_in_bytes, (unsigned)t_info_first_offset); +} + /** * check_tbuf_size - check to make sure that the proposed size will fit * in the currently sized struct t_info. */ static inline int check_tbuf_size(int size) { - return (num_online_cpus() * size + T_INFO_FIRST_OFFSET) > (T_INFO_SIZE / sizeof(uint32_t)); + return (num_online_cpus() * size + t_info_first_offset) > (T_INFO_SIZE / sizeof(uint32_t)); } /** @@ -100,7 +115,7 @@ unsigned long nr_pages; /* Start after a fixed-size array of NR_CPUS */ uint32_t *t_info_mfn_list = (uint32_t *)t_info; - int offset = T_INFO_FIRST_OFFSET; + int offset = t_info_first_offset; BUG_ON(check_tbuf_size(opt_tbuf_size)); @@ -293,6 +308,10 @@ void __init init_trace_bufs(void) { int i; + + /* Calculate offset in u32 of first mfn */ + calc_tinfo_first_offset(); + /* t_info size fixed at 2 pages for now. That should be big enough / small enough * until it's worth making it dynamic. */ t_info = alloc_xenheap_pages(1, 0); [-- Attachment #3: Type: text/plain, Size: 138 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 16:12 ` George Dunlap @ 2010-06-30 17:14 ` Keir Fraser 2010-06-30 18:12 ` George Dunlap 2010-07-01 9:49 ` Jan Beulich 1 sibling, 1 reply; 11+ messages in thread From: Keir Fraser @ 2010-06-30 17:14 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel@lists.xensource.com, Jan Beulich I've lost track of all these trace patches. Please send a new set of patches with finalised Sign-offs and Acks as appropriate when you reach agreement. -- Keir On 30/06/2010 17:12, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote: > Oops, please use this version, which used the appropraite gkprintk() > settings... > > -George > > On Wed, Jun 30, 2010 at 5:10 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> Here's a version that calculates t_info_first_offset during >> initialization, based on the actual layout of struct t_info and >> NR_CPUs. >> >> -George >> >> On Wed, Jun 30, 2010 at 4:28 PM, George Dunlap >> <george.dunlap@eu.citrix.com> wrote: >>> Jan Beulich wrote: >>>> >>>> That part your patch doesn't address either - rather than >>>> sizeof(uint16_t) as the first part of the expression you'd need to >>>> use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset). >>>> >>> >>> I was assuming that when someone changed struct t_info that they'd modify >>> this macro as well; I suppose then that the two complaints are really >>> different aspects of the same one -- that it might not be clear to the >>> person who adjusts struct t_info how to translate those changes into >>> T_INFO_FIRST_OFFSET. I think this way is more clear. >>> >>> I suppose even better might be to calculate t_info.mfn_mfn_offset[NR_CPUS] >>> (or perhaps ...[num_possible_cpus]). Hmm... let me see what I can come up >>> with. >>>> >>>> Btw., didn't we agree that public headers shouldn't make use of >>>> language extensions? struct t_info uses a variable sized array, >>>> which is an extension (standard only in C99). >>>> >>> >>> I'm not an expert in this. It's lot more hassle to lay out the data the way >>> I'd like without it. I'll defer judgment to Keir. >>> >>> -George >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel >>> >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 17:14 ` Keir Fraser @ 2010-06-30 18:12 ` George Dunlap 2010-07-01 9:50 ` Jan Beulich 0 siblings, 1 reply; 11+ messages in thread From: George Dunlap @ 2010-06-30 18:12 UTC (permalink / raw) To: Keir Fraser; +Cc: xen-devel@lists.xensource.com, Jan Beulich Jan, I've got all the ones I've acked / sent my own versions of in a mercurial queue, easy to patchbomb. Let me know if you have any more feedback on my versions. My only objection to the last one was the volatile stuff; if you're OK with it, I'll send a series with everything but the volatile stuff, and we can continue talking about it. -George Keir Fraser wrote: > I've lost track of all these trace patches. Please send a new set of patches > with finalised Sign-offs and Acks as appropriate when you reach agreement. > > -- Keir > > On 30/06/2010 17:12, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote: > > >> Oops, please use this version, which used the appropraite gkprintk() >> settings... >> >> -George >> >> On Wed, Jun 30, 2010 at 5:10 PM, George Dunlap >> <George.Dunlap@eu.citrix.com> wrote: >> >>> Here's a version that calculates t_info_first_offset during >>> initialization, based on the actual layout of struct t_info and >>> NR_CPUs. >>> >>> -George >>> >>> On Wed, Jun 30, 2010 at 4:28 PM, George Dunlap >>> <george.dunlap@eu.citrix.com> wrote: >>> >>>> Jan Beulich wrote: >>>> >>>>> That part your patch doesn't address either - rather than >>>>> sizeof(uint16_t) as the first part of the expression you'd need to >>>>> use sizeof(struct t_info) or offsetof(struct t_info, mfn_offset). >>>>> >>>>> >>>> I was assuming that when someone changed struct t_info that they'd modify >>>> this macro as well; I suppose then that the two complaints are really >>>> different aspects of the same one -- that it might not be clear to the >>>> person who adjusts struct t_info how to translate those changes into >>>> T_INFO_FIRST_OFFSET. I think this way is more clear. >>>> >>>> I suppose even better might be to calculate t_info.mfn_mfn_offset[NR_CPUS] >>>> (or perhaps ...[num_possible_cpus]). Hmm... let me see what I can come up >>>> with. >>>> >>>>> Btw., didn't we agree that public headers shouldn't make use of >>>>> language extensions? struct t_info uses a variable sized array, >>>>> which is an extension (standard only in C99). >>>>> >>>>> >>>> I'm not an expert in this. It's lot more hassle to lay out the data the way >>>> I'd like without it. I'll defer judgment to Keir. >>>> >>>> -George >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel >>>> >>>> > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 18:12 ` George Dunlap @ 2010-07-01 9:50 ` Jan Beulich 0 siblings, 0 replies; 11+ messages in thread From: Jan Beulich @ 2010-07-01 9:50 UTC (permalink / raw) To: George Dunlap, Keir Fraser; +Cc: xen-devel@lists.xensource.com >>> On 30.06.10 at 20:12, George Dunlap <george.dunlap@eu.citrix.com> wrote: > I've got all the ones I've acked / sent my own versions of in a > mercurial queue, easy to patchbomb. Let me know if you have any more > feedback on my versions. > > My only objection to the last one was the volatile stuff; if you're OK > with it, I'll send a series with everything but the volatile stuff, and > we can continue talking about it. Sounds good to me. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-06-30 16:12 ` George Dunlap 2010-06-30 17:14 ` Keir Fraser @ 2010-07-01 9:49 ` Jan Beulich 2010-07-01 9:53 ` George Dunlap 1 sibling, 1 reply; 11+ messages in thread From: Jan Beulich @ 2010-07-01 9:49 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel@lists.xensource.com, Keir Fraser >>> On 30.06.10 at 18:12, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >+ offset_in_bytes = ((char *)&((struct t_info *)(NULL))->mfn_offset[NR_CPUS]) - (char *)(NULL); Why can't this just be offsetof(struct t_info, mfn_offset[NR_CPUS])? Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Re: [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET 2010-07-01 9:49 ` Jan Beulich @ 2010-07-01 9:53 ` George Dunlap 0 siblings, 0 replies; 11+ messages in thread From: George Dunlap @ 2010-07-01 9:53 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel@lists.xensource.com, Keir Fraser On 01/07/10 10:49, Jan Beulich wrote: >>>> On 30.06.10 at 18:12, George Dunlap<George.Dunlap@eu.citrix.com> wrote: >> + offset_in_bytes = ((char *)&((struct t_info *)(NULL))->mfn_offset[NR_CPUS]) - (char *)(NULL); > > Why can't this just be offsetof(struct t_info, mfn_offset[NR_CPUS])? Ah... forgot about that one. Thanks, I'll modify that in my patch series. -George ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-07-01 9:53 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-29 15:32 [PATCH 2/6] trace: fix T_INFO_FIRST_OFFSET Jan Beulich 2010-06-30 14:52 ` George Dunlap 2010-06-30 15:15 ` Jan Beulich 2010-06-30 15:28 ` George Dunlap 2010-06-30 16:10 ` George Dunlap 2010-06-30 16:12 ` George Dunlap 2010-06-30 17:14 ` Keir Fraser 2010-06-30 18:12 ` George Dunlap 2010-07-01 9:50 ` Jan Beulich 2010-07-01 9:49 ` Jan Beulich 2010-07-01 9:53 ` George Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).