Re: PATCH] firewire: add padding to some struct - Kernel

This is a discussion on Re: PATCH] firewire: add padding to some struct - Kernel ; Hi, >From: Stefan Richter >Reply-To: >To: JiSheng Zhang >Subject: Re: PATCH] firewire: add padding to some struct >Date:Fri, 18 Jul 2008 13:38:25 +0200 > >JiSheng Zhang wrote: > > If p is a pointer to struct fw_cdev_event_response), p->data will point ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: PATCH] firewire: add padding to some struct

  1. Re: PATCH] firewire: add padding to some struct

    Hi,
    >From: Stefan Richter
    >Reply-To:
    >To: JiSheng Zhang
    >Subject: Re: PATCH] firewire: add padding to some struct
    >Date:Fri, 18 Jul 2008 13:38:25 +0200
    >
    >JiSheng Zhang wrote:
    > > If p is a pointer to struct fw_cdev_event_response), p->data will point to

    the
    > > padding data rather than the right place, it will cause problem under some
    > > platforms. For example, in the function handle_device_event of

    libraw1394(ported
    > > to juju stack):
    > > .....
    > > case FW_CDEV_EVENT_RESPONSE:
    > > rc = u64_to_ptr(u->response.closure);
    > > if (rc->data != NULL)
    > > memcpy(rc->data, u->response.data, rc->length);//here it will lost the last

    four
    > > bytes
    > > errcode = juju_to_raw1394_errcode(u->response.rcode);
    > > .....
    > >
    > > Although this problem can be solved by add the offset to the pointer, but the
    > > member:__u32 data[0] lost its original meaning.

    >
    > I don't understand what the problem is. As long as both kernel and
    > library use "response.data" or "&response + offsetof(typeof(response),
    > data)", they will write and read at the correct location.
    >

    This patch can fix the problem while not changing the struct definition.


    Thanks in advance,
    JiSheng

    --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    @@ -382,9 +382,9 @@

    response->response.type = FW_CDEV_EVENT_RESPONSE;
    response->response.rcode = rcode;
    - queue_event(client, &response->event,
    - &response->response, sizeof(response->response),
    - response->response.data, response->response.length);
    + queue_event(client, &response->event, &response->response,
    + sizeof(response->response) + response->response.length,
    + NULL, 0);
    }

    static int ioctl_send_request(struct client *client, void *buffer)


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: PATCH] firewire: add padding to some struct

    JiSheng Zhang writes:
    > Hi,
    > >From: Stefan Richter
    > >Reply-To:
    > >To: JiSheng Zhang
    > >Subject: Re: PATCH] firewire: add padding to some struct
    > >Date:Fri, 18 Jul 2008 13:38:25 +0200
    > >
    > >JiSheng Zhang wrote:
    > > > If p is a pointer to struct fw_cdev_event_response), p->data will point to

    > the
    > > > padding data rather than the right place, it will cause problem under some


    Define "the right place". If p->data[] isn't the place for the data,
    then something's seriously wrong with either the producer or the
    consumer of that data -- or the data type definition if either is HW.

    > > > platforms. For example, in the function handle_device_event of

    > libraw1394(ported
    > > > to juju stack):
    > > > .....
    > > > case FW_CDEV_EVENT_RESPONSE:
    > > > rc = u64_to_ptr(u->response.closure);
    > > > if (rc->data != NULL)
    > > > memcpy(rc->data, u->response.data, rc->length);//here it will lost the last

    > four
    > > > bytes
    > > > errcode = juju_to_raw1394_errcode(u->response.rcode);
    > > > .....
    > > >
    > > > Although this problem can be solved by add the offset to the pointer, but the
    > > > member:__u32 data[0] lost its original meaning.

    > >
    > > I don't understand what the problem is. As long as both kernel and
    > > library use "response.data" or "&response + offsetof(typeof(response),
    > > data)", they will write and read at the correct location.
    > >

    > This patch can fix the problem while not changing the struct definition.
    >
    >
    > Thanks in advance,
    > JiSheng
    >
    > --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    > +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    > @@ -382,9 +382,9 @@
    >
    > response->response.type = FW_CDEV_EVENT_RESPONSE;
    > response->response.rcode = rcode;
    > - queue_event(client, &response->event,
    > - &response->response, sizeof(response->response),
    > - response->response.data, response->response.length);
    > + queue_event(client, &response->event, &response->response,
    > + sizeof(response->response) + response->response.length,
    > + NULL, 0);
    > }


    Neither of these look correct.
    If sizeof(struct ...) != offsetof(struct ..., data) as you claim is possible,
    then the old code will copy too much to/from ->response but the correct amount
    to/from ->response.data, and the new code will copy too much to/from ->response.data.

    That's why C has offsetof():

    queue_event(client, &response->event,
    &response->response,
    offsetof(typeof(*response->responce), data), // I don't know the struct name
    response->response.data, response->response.length);
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: PATCH] firewire: add padding to some struct

    On Fri, 18 Jul 2008 17:27:44 +0200
    Mikael Pettersson wrote:

    > JiSheng Zhang writes:
    > > Hi,
    > > >From: Stefan Richter
    > > >Reply-To:
    > > >To: JiSheng Zhang
    > > >Subject: Re: PATCH] firewire: add padding to some struct
    > > >Date:Fri, 18 Jul 2008 13:38:25 +0200
    > > >
    > > >JiSheng Zhang wrote:
    > > > > If p is a pointer to struct fw_cdev_event_response), p->data will point to

    > > the
    > > > > padding data rather than the right place, it will cause problem under some

    >
    > Define "the right place". If p->data[] isn't the place for the data,
    > then something's seriously wrong with either the producer or the
    > consumer of that data -- or the data type definition if either is HW.
    >
    > > > > platforms. For example, in the function handle_device_event of

    > > libraw1394(ported
    > > > > to juju stack):
    > > > > .....
    > > > > case FW_CDEV_EVENT_RESPONSE:
    > > > > rc = u64_to_ptr(u->response.closure);
    > > > > if (rc->data != NULL)
    > > > > memcpy(rc->data, u->response.data, rc->length);//here it will lost the last

    > > four
    > > > > bytes
    > > > > errcode = juju_to_raw1394_errcode(u->response.rcode);
    > > > > .....
    > > > >
    > > > > Although this problem can be solved by add the offset to the pointer, but the
    > > > > member:__u32 data[0] lost its original meaning.
    > > >
    > > > I don't understand what the problem is. As long as both kernel and
    > > > library use "response.data" or "&response + offsetof(typeof(response),
    > > > data)", they will write and read at the correct location.
    > > >

    > > This patch can fix the problem while not changing the struct definition.
    > >
    > >
    > > Thanks in advance,
    > > JiSheng
    > >
    > > --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    > > +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    > > @@ -382,9 +382,9 @@
    > >
    > > response->response.type = FW_CDEV_EVENT_RESPONSE;
    > > response->response.rcode = rcode;
    > > - queue_event(client, &response->event,
    > > - &response->response, sizeof(response->response),
    > > - response->response.data, response->response.length);
    > > + queue_event(client, &response->event, &response->response,
    > > + sizeof(response->response) + response->response.length,
    > > + NULL, 0);
    > > }

    >
    > Neither of these look correct.
    > If sizeof(struct ...) != offsetof(struct ..., data) as you claim is possible,
    > then the old code will copy too much to/from ->response but the correct amount
    > to/from ->response.data, and the new code will copy too much to/from ->response.data.

    The old code will copy 4 extra bytes totally on some platforms, the new code
    is correct. The old one queue like this:
    struct ...(excluding the padding bytes)|4 padding bytes|4 padding bytes|data
    >
    > That's why C has offsetof():
    >
    > queue_event(client, &response->event,
    > &response->response,
    > offsetof(typeof(*response->responce), data), // I don't know the struct name
    > response->response.data, response->response.length);


    Bye,
    JiSheng
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: PATCH] firewire: add padding to some struct

    JiSheng Zhang writes:
    > On Fri, 18 Jul 2008 17:27:44 +0200
    > Mikael Pettersson wrote:
    >
    > > JiSheng Zhang writes:
    > > > Hi,
    > > > >From: Stefan Richter
    > > > >Reply-To:
    > > > >To: JiSheng Zhang
    > > > >Subject: Re: PATCH] firewire: add padding to some struct
    > > > >Date:Fri, 18 Jul 2008 13:38:25 +0200
    > > > >
    > > > >JiSheng Zhang wrote:
    > > > > > If p is a pointer to struct fw_cdev_event_response), p->data will point to
    > > > the
    > > > > > padding data rather than the right place, it will cause problem under some

    > >
    > > Define "the right place". If p->data[] isn't the place for the data,
    > > then something's seriously wrong with either the producer or the
    > > consumer of that data -- or the data type definition if either is HW.
    > >
    > > > > > platforms. For example, in the function handle_device_event of
    > > > libraw1394(ported
    > > > > > to juju stack):
    > > > > > .....
    > > > > > case FW_CDEV_EVENT_RESPONSE:
    > > > > > rc = u64_to_ptr(u->response.closure);
    > > > > > if (rc->data != NULL)
    > > > > > memcpy(rc->data, u->response.data, rc->length);//here it will lost the last
    > > > four
    > > > > > bytes
    > > > > > errcode = juju_to_raw1394_errcode(u->response.rcode);
    > > > > > .....
    > > > > >
    > > > > > Although this problem can be solved by add the offset to the pointer, but the
    > > > > > member:__u32 data[0] lost its original meaning.
    > > > >
    > > > > I don't understand what the problem is. As long as both kernel and
    > > > > library use "response.data" or "&response + offsetof(typeof(response),
    > > > > data)", they will write and read at the correct location.
    > > > >
    > > > This patch can fix the problem while not changing the struct definition.
    > > >
    > > >
    > > > Thanks in advance,
    > > > JiSheng
    > > >
    > > > --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    > > > +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    > > > @@ -382,9 +382,9 @@
    > > >
    > > > response->response.type = FW_CDEV_EVENT_RESPONSE;
    > > > response->response.rcode = rcode;
    > > > - queue_event(client, &response->event,
    > > > - &response->response, sizeof(response->response),
    > > > - response->response.data, response->response.length);
    > > > + queue_event(client, &response->event, &response->response,
    > > > + sizeof(response->response) + response->response.length,
    > > > + NULL, 0);
    > > > }

    > >
    > > Neither of these look correct.
    > > If sizeof(struct ...) != offsetof(struct ..., data) as you claim is possible,
    > > then the old code will copy too much to/from ->response but the correct amount
    > > to/from ->response.data, and the new code will copy too much to/from ->response.data.

    > The old code will copy 4 extra bytes totally on some platforms, the new code
    > is correct.


    The new code is only correct if the variable length payload starts
    after the struct, i.e. (void*)(&response->response + 1), and not at
    the data field, i.e. (void*)response->response.data.
    Which is it? That's why I asked:

    > > Define "the right place". If p->data[] isn't the place for the data,
    > > then something's seriously wrong with either the producer or the
    > > consumer of that data -- or the data type definition if either is HW.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: PATCH] firewire: add padding to some struct

    JiSheng Zhang wrote:
    > On Fri, 18 Jul 2008 17:27:44 +0200
    > Mikael Pettersson wrote:
    >> JiSheng Zhang writes:
    >> > --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    >> > +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    >> > @@ -382,9 +382,9 @@
    >> >
    >> > response->response.type = FW_CDEV_EVENT_RESPONSE;
    >> > response->response.rcode = rcode;
    >> > - queue_event(client, &response->event,
    >> > - &response->response, sizeof(response->response),
    >> > - response->response.data, response->response.length);
    >> > + queue_event(client, &response->event, &response->response,
    >> > + sizeof(response->response) + response->response.length,
    >> > + NULL, 0);
    >> > }

    >>
    >> Neither of these look correct.
    >> If sizeof(struct ...) != offsetof(struct ..., data) as you claim is possible,
    >> then the old code will copy too much to/from ->response but the correct amount
    >> to/from ->response.data, and the new code will copy too much to/from ->response.data.

    >
    > The old code will copy 4 extra bytes totally on some platforms, the new code
    > is correct. The old one queue like this:
    > struct ...(excluding the padding bytes)|4 padding bytes|4 padding bytes|data
    >
    >> That's why C has offsetof():
    >>
    >> queue_event(client, &response->event,
    >> &response->response,
    >> offsetof(typeof(*response->responce), data), // I don't know the struct name
    >> response->response.data, response->response.length);


    sizeof(struct ...) != offsetof(struct ..., data) happens for example on
    x86-64.

    This is what I get with the current firewire drivers in a block read
    response from firecontrol on i686:

    Command: r . 0 0xfffff0000400 20
    reading from node 0, bus 1023, offset 0XFFFFF0000400 20 bytes
    read succeeded. Data follows (hex):
    04 04 04 8F
    31 33 39 34
    F0 00 A2 22
    00 10 DC 56
    00 FE D2 D4
    Ack code: complete

    And the same on x86-64:

    Command: r . 0 0xfffff0000400 20
    reading from node 0, bus 1023, offset 0XFFFFF0000400 20 bytes
    read succeeded. Data follows (hex):
    04 04 04 8F
    04 04 04 8F
    31 33 39 34
    F0 00 A2 22
    00 10 DC 56
    Ack code: complete

    Command: r . 0 0xfffff0000400 24
    reading from node 0, bus 1023, offset 0XFFFFF0000400 20 bytes
    read succeeded. Data follows (hex):
    04 04 04 8F
    04 04 04 8F
    31 33 39 34
    F0 00 A2 22
    00 10 DC 56
    00 FE D2 D4
    Ack code: complete

    I used libraw1394 from Dan's git repo. Gscanbus shows exactly the same
    results. So, x86-64 and all other architectures where struct
    fw_cdev_event* are aligned on u64 boundaries are currently seriously
    broken... but nobody noticed it before. The only breakage which I saw
    (and is obviously the result of this bug) is that gscanbus shows a wrong
    bus topology on x86-64 but the correct one on i686. The damage from
    this bug is limited though because
    - most applications send requests which get responses with 0 or 4
    bytes payload,
    - no application (which can run on both old and new stack without
    change) uses address range mappings, i.e. get incoming requests.

    I'll look further into your proposed fix.
    --
    Stefan Richter
    -=====-==--- -=== =--==
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: PATCH] firewire: add padding to some struct

    On Sat, 19 Jul 2008 12:32:35 +0200
    Stefan Richter wrote:

    > JiSheng Zhang wrote:
    > > On Fri, 18 Jul 2008 17:27:44 +0200
    > > Mikael Pettersson wrote:
    > >> JiSheng Zhang writes:
    > >> > --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    > >> > +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    > >> > @@ -382,9 +382,9 @@
    > >> >
    > >> > response->response.type = FW_CDEV_EVENT_RESPONSE;
    > >> > response->response.rcode = rcode;
    > >> > - queue_event(client, &response->event,
    > >> > - &response->response, sizeof(response->response),
    > >> > - response->response.data, response->response.length);
    > >> > + queue_event(client, &response->event, &response->response,
    > >> > + sizeof(response->response) + response->response.length,
    > >> > + NULL, 0);
    > >> > }
    > >>
    > >> Neither of these look correct.
    > >> If sizeof(struct ...) != offsetof(struct ..., data) as you claim is possible,
    > >> then the old code will copy too much to/from ->response but the correct amount
    > >> to/from ->response.data, and the new code will copy too much to/from ->response.data.

    > >
    > > The old code will copy 4 extra bytes totally on some platforms, the new code
    > > is correct. The old one queue like this:
    > > struct ...(excluding the padding bytes)|4 padding bytes|4 padding bytes|data
    > >
    > >> That's why C has offsetof():
    > >>
    > >> queue_event(client, &response->event,
    > >> &response->response,
    > >> offsetof(typeof(*response->responce), data), // I don't know the struct name
    > >> response->response.data, response->response.length);

    >
    > sizeof(struct ...) != offsetof(struct ..., data) happens for example on
    > x86-64.
    >
    > This is what I get with the current firewire drivers in a block read
    > response from firecontrol on i686:
    >
    > Command: r . 0 0xfffff0000400 20
    > reading from node 0, bus 1023, offset 0XFFFFF0000400 20 bytes
    > read succeeded. Data follows (hex):
    > 04 04 04 8F
    > 31 33 39 34
    > F0 00 A2 22
    > 00 10 DC 56
    > 00 FE D2 D4
    > Ack code: complete
    >
    > And the same on x86-64:
    >
    > Command: r . 0 0xfffff0000400 20
    > reading from node 0, bus 1023, offset 0XFFFFF0000400 20 bytes
    > read succeeded. Data follows (hex):
    > 04 04 04 8F

    this is the 4 extra padding bytes
    > 04 04 04 8F
    > 31 33 39 34
    > F0 00 A2 22
    > 00 10 DC 56

    here lost the last 4 bytes of data
    > Ack code: complete
    >
    > Command: r . 0 0xfffff0000400 24
    > reading from node 0, bus 1023, offset 0XFFFFF0000400 20 bytes
    > read succeeded. Data follows (hex):
    > 04 04 04 8F
    > 04 04 04 8F
    > 31 33 39 34
    > F0 00 A2 22
    > 00 10 DC 56
    > 00 FE D2 D4
    > Ack code: complete
    >
    > I used libraw1394 from Dan's git repo. Gscanbus shows exactly the same
    > results. So, x86-64 and all other architectures where struct
    > fw_cdev_event* are aligned on u64 boundaries are currently seriously
    > broken... but nobody noticed it before. The only breakage which I saw

    the read_topology_map in the testlibraw of libraw1394(with support to juju)
    will show similar breakage.
    > (and is obviously the result of this bug) is that gscanbus shows a wrong
    > bus topology on x86-64 but the correct one on i686. The damage from
    > this bug is limited though because
    > - most applications send requests which get responses with 0 or 4
    > bytes payload,

    I think so.
    > - no application (which can run on both old and new stack without
    > change) uses address range mappings, i.e. get incoming requests.
    >
    > I'll look further into your proposed fix.

    Thanks

    Regards,
    JiSheng
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: PATCH] firewire: add padding to some struct

    On Sat, 19 Jul 2008 12:09:18 +0200
    Mikael Pettersson wrote:

    > JiSheng Zhang writes:
    > > On Fri, 18 Jul 2008 17:27:44 +0200
    > > Mikael Pettersson wrote:
    > >
    > > > JiSheng Zhang writes:
    > > > > Hi,
    > > > > >From: Stefan Richter
    > > > > >Reply-To:
    > > > > >To: JiSheng Zhang
    > > > > >Subject: Re: PATCH] firewire: add padding to some struct
    > > > > >Date:Fri, 18 Jul 2008 13:38:25 +0200
    > > > > >
    > > > > >JiSheng Zhang wrote:
    > > > > > > If p is a pointer to struct fw_cdev_event_response), p->data will point to
    > > > > the
    > > > > > > padding data rather than the right place, it will cause problem under some
    > > >
    > > > Define "the right place". If p->data[] isn't the place for the data,
    > > > then something's seriously wrong with either the producer or the
    > > > consumer of that data -- or the data type definition if either is HW.
    > > >
    > > > > > > platforms. For example, in the function handle_device_event of
    > > > > libraw1394(ported
    > > > > > > to juju stack):
    > > > > > > .....
    > > > > > > case FW_CDEV_EVENT_RESPONSE:
    > > > > > > rc = u64_to_ptr(u->response.closure);
    > > > > > > if (rc->data != NULL)
    > > > > > > memcpy(rc->data, u->response.data, rc->length);//here it will lost the last
    > > > > four
    > > > > > > bytes
    > > > > > > errcode = juju_to_raw1394_errcode(u->response.rcode);
    > > > > > > .....
    > > > > > >
    > > > > > > Although this problem can be solved by add the offset to the pointer, but the
    > > > > > > member:__u32 data[0] lost its original meaning.
    > > > > >
    > > > > > I don't understand what the problem is. As long as both kernel and
    > > > > > library use "response.data" or "&response + offsetof(typeof(response),
    > > > > > data)", they will write and read at the correct location.
    > > > > >
    > > > > This patch can fix the problem while not changing the struct definition.
    > > > >
    > > > >
    > > > > Thanks in advance,
    > > > > JiSheng
    > > > >
    > > > > --- old/drivers/firewire/fw-cdev.c 2008-07-14 05:51:29.000000000 +0800
    > > > > +++ new/drivers/firewire/fw-cdev.c 2008-07-18 20:20:45.841328585 +0800
    > > > > @@ -382,9 +382,9 @@
    > > > >
    > > > > response->response.type = FW_CDEV_EVENT_RESPONSE;
    > > > > response->response.rcode = rcode;
    > > > > - queue_event(client, &response->event,
    > > > > - &response->response, sizeof(response->response),
    > > > > - response->response.data, response->response.length);
    > > > > + queue_event(client, &response->event, &response->response,
    > > > > + sizeof(response->response) + response->response.length,
    > > > > + NULL, 0);
    > > > > }
    > > >
    > > > Neither of these look correct.
    > > > If sizeof(struct ...) != offsetof(struct ..., data) as you claim is possible,
    > > > then the old code will copy too much to/from ->response but the correct amount
    > > > to/from ->response.data, and the new code will copy too much to/from ->response.data.

    > > The old code will copy 4 extra bytes totally on some platforms, the new code
    > > is correct.

    > The new code is only correct if the variable length payload starts
    > after the struct, i.e. (void*)(&response->response + 1), and not at
    > the data field, i.e. (void*)response->response.data.
    > Which is it? That's why I asked:

    Yes, the payload starts at the data field(including the padding bytes). But
    there is no problem, "As long as both kernel and library use response.data"
    as Stefan said.
    >
    > > > Define "the right place". If p->data[] isn't the place for the data,
    > > > then something's seriously wrong with either the producer or the
    > > > consumer of that data -- or the data type definition if either is HW.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread