[patch 00/23] 2.6.26.8-stable review - Kernel

This is a discussion on [patch 00/23] 2.6.26.8-stable review - Kernel ; 2.6.26-stable review patch. If anyone has any objections, please let us know. ------------------ From: Shaohua Li commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream. ACPI: dock: avoid check _STA method In some BIOSes, every _STA method call will send a notification again, this cause freeze. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: [patch 00/23] 2.6.26.8-stable review

  1. [patch 20/23] ACPI: dock: avoid check _STA method

    2.6.26-stable review patch. If anyone has any objections, please let us know.

    ------------------

    From: Shaohua Li

    commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream.

    ACPI: dock: avoid check _STA method

    In some BIOSes, every _STA method call will send a notification again,
    this cause freeze. And in some BIOSes, it appears _STA should be called
    after _DCK. This tries to avoid calls _STA, and still keep the device
    present check.

    http://bugzilla.kernel.org/show_bug.cgi?id=10431

    Signed-off-by: Shaohua Li
    Signed-off-by: Len Brown
    Signed-off-by: Greg Kroah-Hartman

    ---
    drivers/acpi/dock.c | 5 ++++-
    1 file changed, 4 insertions(+), 1 deletion(-)

    --- a/drivers/acpi/dock.c
    +++ b/drivers/acpi/dock.c
    @@ -599,14 +599,17 @@ static int handle_eject_request(struct d
    static void dock_notify(acpi_handle handle, u32 event, void *data)
    {
    struct dock_station *ds = data;
    + struct acpi_device *tmp;

    switch (event) {
    case ACPI_NOTIFY_BUS_CHECK:
    - if (!dock_in_progress(ds) && dock_present(ds)) {
    + if (!dock_in_progress(ds) && acpi_bus_get_device(ds->handle,
    + &tmp)) {
    begin_dock(ds);
    dock(ds);
    if (!dock_present(ds)) {
    printk(KERN_ERR PREFIX "Unable to dock!\n");
    + complete_dock(ds);
    break;
    }
    atomic_notifier_call_chain(&dock_notifier_list,

    --
    --
    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. [patch 22/23] netfilter: snmp nat leaks memory in case of failure

    2.6.26-stable review patch. If anyone has any objections, please let us know.

    ------------------

    From: Ilpo Järvinen

    netfilter: snmp nat leaks memory in case of failure

    Upstream commit 311670f3e:

    Signed-off-by: Ilpo Jarvinen
    Signed-off-by: Patrick McHardy

    ---
    net/ipv4/netfilter/nf_nat_snmp_basic.c | 1 +
    1 file changed, 1 insertion(+)

    --- a/net/ipv4/netfilter/nf_nat_snmp_basic.c
    +++ b/net/ipv4/netfilter/nf_nat_snmp_basic.c
    @@ -742,6 +742,7 @@ static unsigned char snmp_object_decode(
    *obj = kmalloc(sizeof(struct snmp_object) + len,
    GFP_ATOMIC);
    if (*obj == NULL) {
    + kfree(p);
    kfree(id);
    if (net_ratelimit())
    printk("OOM in bsalg (%d)\n", __LINE__);

    --
    --
    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. [patch 19/23] ACPI: video: fix brightness allocation


    2.6.26-stable review patch. If anyone has any objections, please let us know.

    ------------------

    From: Julia Jomantaite

    upstream commit 469778c1740fcf3113498b6fdf4559bdec25c58f

    Thanks to Arjan for spotting this
    http://www.kerneloops.org/search.php...tch_brightness
    and suggesting it for .stable


    Fix use of uninitialized device->brightness.

    Signed-off-by: Julia Jomantaite
    Signed-off-by: Andi Kleen
    Acked-by: Zhang Rui
    Signed-off-by: Len Brown
    Signed-off-by: Greg Kroah-Hartman

    ---
    drivers/acpi/video.c | 123 ++++++++++++++++++++++++++++++---------------------
    1 file changed, 73 insertions(+), 50 deletions(-)

    --- a/drivers/acpi/video.c
    +++ b/drivers/acpi/video.c
    @@ -631,6 +631,76 @@ acpi_video_bus_DOS(struct acpi_video_bus
    * device : video output device (LCD, CRT, ..)
    *
    * Return Value:
    + * Maximum brightness level
    + *
    + * Allocate and initialize device->brightness.
    + */
    +
    +static int
    +acpi_video_init_brightness(struct acpi_video_device *device)
    +{
    + union acpi_object *obj = NULL;
    + int i, max_level = 0, count = 0;
    + union acpi_object *o;
    + struct acpi_video_device_brightness *br = NULL;
    +
    + if (!ACPI_SUCCESS(acpi_video_device_lcd_query_levels( device, &obj))) {
    + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Could not query available "
    + "LCD brightness level\n"));
    + goto out;
    + }
    +
    + if (obj->package.count < 2)
    + goto out;
    +
    + br = kzalloc(sizeof(*br), GFP_KERNEL);
    + if (!br) {
    + printk(KERN_ERR "can't allocate memory\n");
    + goto out;
    + }
    +
    + br->levels = kmalloc(obj->package.count * sizeof *(br->levels),
    + GFP_KERNEL);
    + if (!br->levels)
    + goto out_free;
    +
    + for (i = 0; i < obj->package.count; i++) {
    + o = (union acpi_object *)&obj->package.elements[i];
    + if (o->type != ACPI_TYPE_INTEGER) {
    + printk(KERN_ERR PREFIX "Invalid data\n");
    + continue;
    + }
    + br->levels[count] = (u32) o->integer.value;
    +
    + if (br->levels[count] > max_level)
    + max_level = br->levels[count];
    + count++;
    + }
    +
    + if (count < 2)
    + goto out_free_levels;
    +
    + br->count = count;
    + device->brightness = br;
    + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "found %d brightness levels\n", count));
    + kfree(obj);
    + return max_level;
    +
    +out_free_levels:
    + kfree(br->levels);
    +out_free:
    + kfree(br);
    +out:
    + device->brightness = NULL;
    + kfree(obj);
    + return 0;
    +}
    +
    +/*
    + * Arg:
    + * device : video output device (LCD, CRT, ..)
    + *
    + * Return Value:
    * None
    *
    * Find out all required AML methods defined under the output
    @@ -640,10 +710,7 @@ acpi_video_bus_DOS(struct acpi_video_bus
    static void acpi_video_device_find_cap(struct acpi_video_device *device)
    {
    acpi_handle h_dummy1;
    - int i;
    u32 max_level = 0;
    - union acpi_object *obj = NULL;
    - struct acpi_video_device_brightness *br = NULL;


    memset(&device->cap, 0, sizeof(device->cap));
    @@ -672,53 +739,7 @@ static void acpi_video_device_find_cap(s
    device->cap._DSS = 1;
    }

    - if (ACPI_SUCCESS(acpi_video_device_lcd_query_levels(d evice, &obj))) {
    -
    - if (obj->package.count >= 2) {
    - int count = 0;
    - union acpi_object *o;
    -
    - br = kzalloc(sizeof(*br), GFP_KERNEL);
    - if (!br) {
    - printk(KERN_ERR "can't allocate memory\n");
    - } else {
    - br->levels = kmalloc(obj->package.count *
    - sizeof *(br->levels), GFP_KERNEL);
    - if (!br->levels)
    - goto out;
    -
    - for (i = 0; i < obj->package.count; i++) {
    - o = (union acpi_object *)&obj->package.
    - elements[i];
    - if (o->type != ACPI_TYPE_INTEGER) {
    - printk(KERN_ERR PREFIX "Invalid data\n");
    - continue;
    - }
    - br->levels[count] = (u32) o->integer.value;
    -
    - if (br->levels[count] > max_level)
    - max_level = br->levels[count];
    - count++;
    - }
    - out:
    - if (count < 2) {
    - kfree(br->levels);
    - kfree(br);
    - } else {
    - br->count = count;
    - device->brightness = br;
    - ACPI_DEBUG_PRINT((ACPI_DB_INFO,
    - "found %d brightness levels\n",
    - count));
    - }
    - }
    - }
    -
    - } else {
    - ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Could not query available LCD brightness level\n"));
    - }
    -
    - kfree(obj);
    + max_level = acpi_video_init_brightness(device);

    if (device->cap._BCL && device->cap._BCM && max_level > 0) {
    int result;
    @@ -1705,6 +1726,8 @@ static void
    acpi_video_switch_brightness(struct acpi_video_device *device, int event)
    {
    unsigned long level_current, level_next;
    + if (!device->brightness)
    + return;
    acpi_video_device_lcd_get_level_current(device, &level_current);
    level_next = acpi_video_get_next_level(device, level_current, event);
    acpi_video_device_lcd_set_level(device, level_next);

    --
    --
    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. [patch 23/23] netfilter: restore lost ifdef guarding defrag exception

    2.6.26-stable review patch. If anyone has any objections, please let us know.

    ------------------

    From: Patrick McHardy

    netfilter: restore lost #ifdef guarding defrag exception

    Upstream commit 38f7ac3eb:

    Nir Tzachar reported a warning when sending
    fragments over loopback with NAT:

    [ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89 nf_nat_fn+0x33/0x155()

    The reason is that defragmentation is skipped for already tracked connections.
    This is wrong in combination with NAT and ip_conntrack actually had some ifdefs
    to avoid this behaviour when NAT is compiled in.

    The entire "optimization" may seem a bit silly, for now simply restoring the
    lost #ifdef is the easiest solution until we can come up with something better.

    Signed-off-by: Patrick McHardy
    Signed-off-by: Greg Kroah-Hartman

    ---
    net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 2 ++
    1 file changed, 2 insertions(+)

    --- a/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
    +++ b/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
    @@ -150,10 +150,12 @@ static unsigned int ipv4_conntrack_defra
    const struct net_device *out,
    int (*okfn)(struct sk_buff *))
    {
    +#if !defined(CONFIG_NF_NAT) && !defined(CONFIG_NF_NAT_MODULE)
    /* Previously seen (loopback)? Ignore. Do this before
    fragment check. */
    if (skb->nfct)
    return NF_ACCEPT;
    +#endif

    /* Gather fragments. */
    if (ip_hdr(skb)->frag_off & htons(IP_MF | IP_OFFSET)) {

    --
    --
    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 02/23] ext: Avoid printk floods in the face of directory corruption (CVE-2008-3528)

    Greg KH wrote:

    Please change the description of the bug to:

    "A very large directory with many read failures (either due to storage
    problems, or due to invalid size & blocks from corruption) will generate
    a printk storm as the filesystem continues to try to read all the
    blocks. This flood of messages can tie up the box until it is complete -
    which may be a very long time, especially for very large corrupted values.

    This is fixed by only reporting the corruption once each time we try to
    read the directory."

    http://git.kernel.org/?p=linux/kerne...diff;h=bd39597

    Thanks, Eugene
    --
    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 02/23] ext: Avoid printk floods in the face of directory corruption (CVE-2008-3528)

    On Mon, Nov 10, 2008 at 10:42:20AM +0800, Eugene Teo wrote:
    > Greg KH wrote:
    >
    > Please change the description of the bug to:
    >
    > "A very large directory with many read failures (either due to storage
    > problems, or due to invalid size & blocks from corruption) will generate
    > a printk storm as the filesystem continues to try to read all the
    > blocks. This flood of messages can tie up the box until it is complete -
    > which may be a very long time, especially for very large corrupted values.
    >
    > This is fixed by only reporting the corruption once each time we try to
    > read the directory."
    >
    > http://git.kernel.org/?p=linux/kerne...diff;h=bd39597


    Hm, why would I change the description to be different from what the
    developer asked it to be? It references the specific changeset you
    point to above already. I'm inclined to stick with the text that the
    developer asked to be used (especially as this is a combined 3
    changesets into one patch).

    Same thing goes for the 2.6.26-stable patch as well.

    thanks,

    greg k-h
    --
    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 02/23] ext: Avoid printk floods in the face of directory corruption (CVE-2008-3528)

    Greg KH wrote:
    > On Mon, Nov 10, 2008 at 10:42:20AM +0800, Eugene Teo wrote:
    >> Greg KH wrote:
    >>
    >> Please change the description of the bug to:
    >>
    >> "A very large directory with many read failures (either due to storage
    >> problems, or due to invalid size & blocks from corruption) will generate
    >> a printk storm as the filesystem continues to try to read all the
    >> blocks. This flood of messages can tie up the box until it is complete -
    >> which may be a very long time, especially for very large corrupted values.
    >>
    >> This is fixed by only reporting the corruption once each time we try to
    >> read the directory."
    >>
    >> http://git.kernel.org/?p=linux/kerne...diff;h=bd39597

    >
    > Hm, why would I change the description to be different from what the
    > developer asked it to be? It references the specific changeset you
    > point to above already. I'm inclined to stick with the text that the
    > developer asked to be used (especially as this is a combined 3
    > changesets into one patch).


    There were 3 changesets upstream, one for each fs; I copied the
    changelog from the ext4 changeset because it's the patch that I
    originally authored, and combined it with the ext2 & ext3 changes as well.

    The upstream ext4 changelog happened to contain some color commentary
    from Ted; the ext2 & ext3 changelogs did not.

    I don't really give a damn what the stable changelog says, and
    personally my feelings won't be hurt with either text, I'll just be
    happy to have the bug fixed in -stable.

    Thanks,
    -Eric
    --
    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/

  8. Re: [patch 20/23] ACPI: dock: avoid check _STA method

    On Fri 07. Nov - 15:16:06, Greg KH wrote:
    > 2.6.26-stable review patch. If anyone has any objections, please let us know.


    Objecting. This will only work in conjunction with

    commit 39a0ad871000d2a016a4fa113a6e53d22aabf25d
    Author: Zhao Yakui
    Date: Mon Aug 11 13:40:22 2008 +0800

    ACPI : Load device driver according to the status of acpi device

    Otherwise a device struct already exists although the device is not
    present.

    Regards,
    Holger

    >
    > ------------------
    >
    > From: Shaohua Li
    >
    > commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream.
    >
    > ACPI: dock: avoid check _STA method
    >
    > In some BIOSes, every _STA method call will send a notification again,
    > this cause freeze. And in some BIOSes, it appears _STA should be called
    > after _DCK. This tries to avoid calls _STA, and still keep the device
    > present check.
    >
    > http://bugzilla.kernel.org/show_bug.cgi?id=10431
    >
    > Signed-off-by: Shaohua Li
    > Signed-off-by: Len Brown
    > Signed-off-by: Greg Kroah-Hartman
    >
    > ---
    > drivers/acpi/dock.c | 5 ++++-
    > 1 file changed, 4 insertions(+), 1 deletion(-)
    >
    > --- a/drivers/acpi/dock.c
    > +++ b/drivers/acpi/dock.c
    > @@ -599,14 +599,17 @@ static int handle_eject_request(struct d
    > static void dock_notify(acpi_handle handle, u32 event, void *data)
    > {
    > struct dock_station *ds = data;
    > + struct acpi_device *tmp;
    >
    > switch (event) {
    > case ACPI_NOTIFY_BUS_CHECK:
    > - if (!dock_in_progress(ds) && dock_present(ds)) {
    > + if (!dock_in_progress(ds) && acpi_bus_get_device(ds->handle,
    > + &tmp)) {
    > begin_dock(ds);
    > dock(ds);
    > if (!dock_present(ds)) {
    > printk(KERN_ERR PREFIX "Unable to dock!\n");
    > + complete_dock(ds);
    > break;
    > }
    > atomic_notifier_call_chain(&dock_notifier_list,
    >

    --
    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
Page 2 of 2 FirstFirst 1 2