* [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 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-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-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).