On Tue, Aug 3, 2010 at 6:55 AM, Ben Hutchings <bhutchings@solarflare.com> wrote:
quoted text
> On Mon, 2010-08-02 at 15:45 -0700, Stephen Hemminger wrote:
>> On Tue, 3 Aug 2010 06:34:59 +0800
>> Changli Gao <xiaosuo@gmail.com> wrote:
>>
>> > On Tue, Aug 3, 2010 at 6:00 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
>> > > U32 classifier reads data from packet at a offset passed in from
>> > > user space. The offset should be aligned, but it is unsafe practice
>> > > to depend on values from userspace.
>> > >
>> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>> > >
>> > > --- a/net/sched/cls_u32.c       2010-08-01 11:21:06.945820852 -0700
>> > > +++ b/net/sched/cls_u32.c       2010-08-01 11:24:55.257793848 -0700
>> > > @@ -41,6 +41,7 @@
>> > >  #include <net/netlink.h>
>> > >  #include <net/act_api.h>
>> > >  #include <net/pkt_cls.h>
>> > > +#include <asm/unaligned.h>
>> > >
>> > >  struct tc_u_knode
>> > >  {
>> > > @@ -140,7 +141,7 @@ next_knode:
>> > >                        data = skb_header_pointer(skb, toff, 4, &_data);
>> > >                        if (!data)
>> > >                                goto out;
>> > > -                       if ((*data ^ key->val) & key->mask) {
>> > > +                       if ((get_unaligned_be32(data) ^ key->val) & key->mask) {
>> >
>> > be32()? I think it may break configuration.
>>
>> The data pointer is be32 * already.
>
> But get_unaligned_be32() converts to native byte order.
>

__be32 does't mean the dereferenced data will be converted to be32. It
is just a notation.

typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
typedef __u64 __bitwise __le64;
typedef __u64 __bitwise __be64;

__be* is defined the same as __le*. The compiler can't get any endian info.

Here is the discussion about http://kerneltrap.org/node/3848

Thanks.

-- 
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html