lkml.org 
[lkml]   [2011]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [159/244] ipc/mqueue.c: fix mq_open() return value
    ----- Original Message -----
    > On Thu, 29 Sep 2011 19:31:41 -0400 (EDT)
    >
    > (Please hit <enter> occasionally?)

    It's this frikkin' Zimbra mail client. Something about it using
    text/flowed or something like that. Anyway, I'll manually line
    wrap.

    > This is all waaaaay too confusing. For starters, please never say
    > "the
    > patch" or "it" or "new patch". Patches have names - let's use them,
    > and greatly reduce the amount of head-spinning. (And I mean "names",
    > not git hashes, which can be different in different trees).
    >
    > There are no patches againt ipc/mqueue.c pending in any tree I can
    > see
    > apart from the 4+fix from yourself, which are in -mm and will be in
    > linux-next next time I send an update to Stephen:
    >
    > ipc-mqueue-cleanup-definition-names-and-locations.patch
    > ipc-mqueue-switch-back-to-using-non-max-values-on-create.patch
    > ipc-mqueue-enforce-hard-limits.patch
    > ipc-mqueue-update-maximums-for-the-mqueue-subsystem.patch
    > ipc-mqueue-update-maximums-for-the-mqueue-subsystem-checkpatch-fixes.patch
    >
    > Everything else is already in Linus's tree.
    >
    > I don't have a clue what's going on here. Let's start again.

    Your right. The patch I was referring to was the patch I NAKed,
    which is this patch:
    d40dcdb ipc/mqueue.c: fix mq_open() return value

    I didn't think it was in Linus' tree because of faulty memory. I
    remembered seeing ENOMEM as the return and not EMFILE when I wrote
    my patches. But, that makes sense given that I was originally staring
    at our internal 2.6.18 kernel tree as I wrote the code, and only
    later did I port it to Linus' tree. I spent a lot more time looking
    at our internal tree where the above patch doesn't exist.

    So, as I said, Greg I withdraw my NAK and we'll just fix it up in
    your stable tree after my patches have been reviewed/accepted in
    some version of Linus' tree.

    --
    Doug Ledford <dledford@redhat.com>
    GPG KeyID: CFBFF194
    http://people.redhat.com/dledford



    \
     
     \ /
      Last update: 2011-09-30 03:57    [W:4.182 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site