I've been wondering about the intended use of this facilitator macro
for some time and concluded that it is plainly wrong. It should
take a pointer value from a buffer, but what is the use of a pointer
that pointed to something on the _target_ machine? It cannot be
meaningfully dereferenced on the host.
Okay, pointer arithmetics is done in one place, but IMO it is better
to explicitly state the object size there, because that's how things
are done elsewhere in the code, so it is less surprising for anybody
reading the code.
The irony is underlined by the fact that all three uses of the macro
need a subsequent typecast to ulong, which proves the whole concept
flawed.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-27-2011, 02:41 PM
Dave Anderson
Remove the VOID_PTR facilitator macro
----- Original Message -----
> I've been wondering about the intended use of this facilitator macro
> for some time and concluded that it is plainly wrong. It should
> take a pointer value from a buffer, but what is the use of a pointer
> that pointed to something on the _target_ machine? It cannot be
> meaningfully dereferenced on the host.
>
> Okay, pointer arithmetics is done in one place, but IMO it is better
> to explicitly state the object size there, because that's how things
> are done elsewhere in the code, so it is less surprising for anybody
> reading the code.
>
> The irony is underlined by the fact that all three uses of the macro
> need a subsequent typecast to ulong, which proves the whole concept
> flawed.
Probably so. It's been so long since I wrote that I don't recall
my original intent, other than maybe paranoia that some architecture
in the future would have pointers and longs of different sizes.
I'll leave the macro in defs.h though, since it's possible that
somebody's extension module uses it.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-27-2011, 05:26 PM
"David Mair"
Remove the VOID_PTR facilitator macro
Hi Dave,
>>> On 1/27/2011 at 08:41 AM, in message
<748696339.157170.1296142883615.JavaMail.root@zmai l05.collab.prod.int.phx2.redha
.com>, Dave Anderson <anderson@redhat.com> wrote:
>
> ----- Original Message -----
>> I've been wondering about the intended use of this facilitator macro
>> for some time and concluded that it is plainly wrong. It should
>> take a pointer value from a buffer, but what is the use of a pointer
>> that pointed to something on the _target_ machine? It cannot be
>> meaningfully dereferenced on the host.
>>
>> Okay, pointer arithmetics is done in one place, but IMO it is better
>> to explicitly state the object size there, because that's how things
>> are done elsewhere in the code, so it is less surprising for anybody
>> reading the code.
>>
>> The irony is underlined by the fact that all three uses of the macro
>> need a subsequent typecast to ulong, which proves the whole concept
>> flawed.
>
> Probably so. It's been so long since I wrote that I don't recall
> my original intent, other than maybe paranoia that some architecture
> in the future would have pointers and longs of different sizes.
>
> I'll leave the macro in defs.h though, since it's possible that
> somebody's extension module uses it.
>
> BTW, was there a reason that you changed this?:
>
> if (si->c_flags & SLAB_CFLGS_BUFCTL)
> - obj = si->s_mem + ((next - si->s_index) * si->c_offset);
> + obj = si->s_mem + (next - si->s_index) * si->c_offset;
It wasn't my patch so I'm only offering my ACK for the original change and my reason is that multiply has higher operator precedence than add (and subtract) in normal arithmetic so the outer parentheses were never necessary anyway. They didn't create an error but they weren't needed either. The inner parentheses are required.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-27-2011, 05:47 PM
Dave Anderson
Remove the VOID_PTR facilitator macro
----- Original Message -----
> Hi Dave,
> >
> > BTW, was there a reason that you changed this?:
> >
> > if (si->c_flags & SLAB_CFLGS_BUFCTL)
> > - obj = si->s_mem + ((next - si->s_index) * si->c_offset);
> > + obj = si->s_mem + (next - si->s_index) * si->c_offset;
>
> It wasn't my patch so I'm only offering my ACK for the original change
> and my reason is that multiply has higher operator precedence than add
> (and subtract) in normal arithmetic so the outer parentheses were
> never necessary anyway. They didn't create an error but they weren't
> needed either. The inner parentheses are required.
>
> --
> David Mair.
Right I understand that, but the sources are full of such
"extra" parentheses, some to prevent compiler warnings, but
mostly just for ease of maintainability/understanding.
I just was wondering why that line was explicitly changed.
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-27-2011, 11:14 PM
Petr Tesarik
Remove the VOID_PTR facilitator macro
Dne čtvrtek 27 Leden 2011 19:47:41 Dave Anderson napsal(a):
> ----- Original Message -----
>
> > Hi Dave,
> >
> > > BTW, was there a reason that you changed this?:
> > > if (si->c_flags & SLAB_CFLGS_BUFCTL)
> > >
> > > - obj = si->s_mem + ((next - si->s_index) * si->c_offset);
> > > + obj = si->s_mem + (next - si->s_index) * si->c_offset;
> >
> > It wasn't my patch so I'm only offering my ACK for the original change
> > and my reason is that multiply has higher operator precedence than add
> > (and subtract) in normal arithmetic so the outer parentheses were
> > never necessary anyway. They didn't create an error but they weren't
> > needed either. The inner parentheses are required.
> >
> > --
> > David Mair.
>
> Right I understand that, but the sources are full of such
> "extra" parentheses, some to prevent compiler warnings, but
> mostly just for ease of maintainability/understanding.
>
> I just was wondering why that line was explicitly changed.
No reason, except I removed them for some reason while developing the patch
and forgot to put them back afterwards. I can leave it as-is.
Oh, I've just realized that this actually changed the expression, because
originally both variables were pointers to ulong, so
(next - si->s_index)
should become
((next - si->s_index)/sizeof(ulong))
I wonder whether this was originally intended. Let me have one more look at
this.
Petr
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-27-2011, 11:32 PM
Petr Tesarik
Remove the VOID_PTR facilitator macro
Dne pátek 28 Leden 2011 01:14:51 Petr Tesarik napsal(a):
> Dne čtvrtek 27 Leden 2011 19:47:41 Dave Anderson napsal(a):
> > ----- Original Message -----
> >
> > > Hi Dave,
> > >
> > > > BTW, was there a reason that you changed this?:
> > > > if (si->c_flags & SLAB_CFLGS_BUFCTL)
> > > >
> > > > - obj = si->s_mem + ((next - si->s_index) * si->c_offset);
> > > > + obj = si->s_mem + (next - si->s_index) * si->c_offset;
> > >
> > > It wasn't my patch so I'm only offering my ACK for the original change
> > > and my reason is that multiply has higher operator precedence than add
> > > (and subtract) in normal arithmetic so the outer parentheses were
> > > never necessary anyway. They didn't create an error but they weren't
> > > needed either. The inner parentheses are required.
> > >
> > > --
> > > David Mair.
> >
> > Right I understand that, but the sources are full of such
> > "extra" parentheses, some to prevent compiler warnings, but
> > mostly just for ease of maintainability/understanding.
> >
> > I just was wondering why that line was explicitly changed.
>
> No reason, except I removed them for some reason while developing the patch
> and forgot to put them back afterwards. I can leave it as-is.
>
> Oh, I've just realized that this actually changed the expression, because
> originally both variables were pointers to ulong, so
>
> (next - si->s_index)
>
> should become
>
> ((next - si->s_index)/sizeof(ulong))
>
> I wonder whether this was originally intended. Let me have one more look at
> this.
I had to dig back in 2.2.x sources, but the divide should indeed be there.
I'll send an updated patch tomorrow (too late for me in Europe now).
Petr
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-28-2011, 09:03 AM
Petr Tesarik
Remove the VOID_PTR facilitator macro
I've been wondering about the intended use of this facilitator macro
for some time and concluded that it is plainly wrong. It should
take a pointer value from a buffer, but what is the use of a pointer
that pointed to something on the target machine?
Since it cannot be meaningfully dereferenced on the host, the only
(arguable) advantage is the ability to do pointer arithmetics on the
variables. This second patch does the correct thing wherever pointer
arithmetics was done, making the actual calculations more explicit.
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-28-2011, 01:08 PM
Dave Anderson
Remove the VOID_PTR facilitator macro
----- Original Message -----
> I've been wondering about the intended use of this facilitator macro
> for some time and concluded that it is plainly wrong. It should
> take a pointer value from a buffer, but what is the use of a pointer
> that pointed to something on the target machine?
>
> Since it cannot be meaningfully dereferenced on the host, the only
> (arguable) advantage is the ability to do pointer arithmetics on the
> variables. This second patch does the correct thing wherever pointer
> arithmetics was done, making the actual calculations more explicit.
>
> Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
Everything *looks* correct -- but this patch doesn't fix anything, while
having the capacity to break what works. The slab-related changes still
concern me, at least until I test them.
BTW, in the future, when you post patches can you add them as attachments
instead of inlining them?
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-28-2011, 08:10 PM
Dave Anderson
Remove the VOID_PTR facilitator macro
----- Original Message -----
> ----- Original Message -----
> > I've been wondering about the intended use of this facilitator macro
> > for some time and concluded that it is plainly wrong. It should
> > take a pointer value from a buffer, but what is the use of a pointer
> > that pointed to something on the target machine?
> >
> > Since it cannot be meaningfully dereferenced on the host, the only
> > (arguable) advantage is the ability to do pointer arithmetics on the
> > variables. This second patch does the correct thing wherever pointer
> > arithmetics was done, making the actual calculations more explicit.
> >
> > Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
>
> Everything *looks* correct -- but this patch doesn't fix anything, while
> having the capacity to break what works. The slab-related changes still
> concern me, at least until I test them.
As it turns out, I can't even test the slab changes, because I don't have
any more sample dumpfiles that go that far back to "pre-percpu" days. That
being the case, I'm not going to change the parts that modify dump_slab(),
dump_slab_objects() and gather_slab_free_list(). Why bother? It's
essentially dead code, but if there are still any users of it out there,
I'm not going to risk breaking it on them.
So I'm afraid it's going to continue to offend your sensibilities -- sorry
about that...
On the other hand, the changes to vm_area_dump() and next_upage() certainly
look harmless enough.
Thanks,
Dave
> BTW, in the future, when you post patches can you add them as attachments
> instead of inlining them?
>
> Thanks,
> Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
01-31-2011, 02:51 PM
Dave Anderson
Remove the VOID_PTR facilitator macro
----- Original Message -----
> I've been wondering about the intended use of this facilitator macro
> for some time and concluded that it is plainly wrong. It should
> take a pointer value from a buffer, but what is the use of a pointer
> that pointed to something on the target machine?
>
> Since it cannot be meaningfully dereferenced on the host, the only
> (arguable) advantage is the ability to do pointer arithmetics on the
> variables. This second patch does the correct thing wherever pointer
> arithmetics was done, making the actual calculations more explicit.
>
> Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
The changes to vm_area_dump(), vm_area_page_dump() and next_upage()
have been queued for the next release.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Remove the VOID_PTR facilitator macro
