[patch 00/47] 2.6.25-stable review - Kernel

This is a discussion on [patch 00/47] 2.6.25-stable review - Kernel ; 2.6.25-stable review patch. If anyone has any objections, please let us know. ------------------ From: Eric W. Biederman commit 05d81d2222beec7b63ac8c1c8cdb5bb4f82c2bad upstream I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird mysterious crash in sysfs. ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 54 of 54

Thread: [patch 00/47] 2.6.25-stable review

  1. [patch 37/47] serial8250: sanity check nr_uarts on all paths.

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

    ------------------
    From: Eric W. Biederman

    commit 05d81d2222beec7b63ac8c1c8cdb5bb4f82c2bad upstream

    I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird
    mysterious crash in sysfs. After taking an in-depth look I realized that
    CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of
    the serial8250_ports array.

    Ouch!!!

    Don't let this happen to someone else.

    Signed-off-by: Eric W. Biederman
    Acked-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    drivers/serial/8250.c | 3 +++
    1 file changed, 3 insertions(+)

    --- a/drivers/serial/8250.c
    +++ b/drivers/serial/8250.c
    @@ -2564,6 +2564,9 @@ static struct console serial8250_console

    static int __init serial8250_console_init(void)
    {
    + if (nr_uarts > UART_NR)
    + nr_uarts = UART_NR;
    +
    serial8250_isa_init_ports();
    register_console(&serial8250_console);
    return 0;

    --
    --
    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 46/47] hrtimer: prevent migration for raising softirq

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

    ------------------
    From: Steven Rostedt

    commit ee3ece830f6db9837f7ac67008f532a8c1e755f4 upstream.

    Due to a possible deadlock, the waking of the softirq was pushed outside
    of the hrtimer base locks. See commit 0c96c5979a522c3323c30a078a70120e29b5bdbc

    Unfortunately this allows the task to migrate after setting up the softirq
    and raising it. Since softirqs run a queue that is per-cpu we may raise the
    softirq on the wrong CPU and this will keep the queued softirq task from
    running.

    To solve this issue, this patch disables preemption around the releasing
    of the hrtimer lock and raising of the softirq.

    Signed-off-by: Steven Rostedt
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    kernel/hrtimer.c | 8 ++++++++
    1 file changed, 8 insertions(+)

    --- a/kernel/hrtimer.c
    +++ b/kernel/hrtimer.c
    @@ -896,10 +896,18 @@ hrtimer_start(struct hrtimer *timer, kti
    */
    raise = timer->state == HRTIMER_STATE_PENDING;

    + /*
    + * We use preempt_disable to prevent this task from migrating after
    + * setting up the softirq and raising it. Otherwise, if me migrate
    + * we will raise the softirq on the wrong CPU.
    + */
    + preempt_disable();
    +
    unlock_hrtimer_base(timer, &flags);

    if (raise)
    hrtimer_raise_softirq();
    + preempt_enable();

    return ret;
    }

    --
    --
    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 44/47] pxamci: fix byte aligned DMA transfers

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

    ------------------
    From: Philipp Zabel

    commit 97f8571e663c808ad2d01a396627235167291556 upstream

    The pxa27x DMA controller defaults to 64-bit alignment. This caused
    the SCR reads to fail (and, depending on card type, error out) when
    card->raw_scr was not aligned on a 8-byte boundary.

    For performance reasons all scatter-gather addresses passed to
    pxamci_request should be aligned on 8-byte boundaries, but if
    this can't be guaranteed, byte aligned DMA transfers in the
    have to be enabled in the controller to get correct behaviour.

    Signed-off-by: Philipp Zabel
    Signed-off-by: Pierre Ossman
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    drivers/mmc/host/pxamci.c | 13 +++++++++++++
    1 file changed, 13 insertions(+)

    --- a/drivers/mmc/host/pxamci.c
    +++ b/drivers/mmc/host/pxamci.c
    @@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxa
    unsigned int nob = data->blocks;
    unsigned long long clks;
    unsigned int timeout;
    + bool dalgn = 0;
    u32 dcmd;
    int i;

    @@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxa
    host->sg_cpu[i].dcmd = dcmd | length;
    if (length & 31 && !(data->flags & MMC_DATA_READ))
    host->sg_cpu[i].dcmd |= DCMD_ENDIRQEN;
    + /* Not aligned to 8-byte boundary? */
    + if (sg_dma_address(&data->sg[i]) & 0x7)
    + dalgn = 1;
    if (data->flags & MMC_DATA_READ) {
    host->sg_cpu[i].dsadr = host->res->start + MMC_RXFIFO;
    host->sg_cpu[i].dtadr = sg_dma_address(&data->sg[i]);
    @@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxa
    host->sg_cpu[host->dma_len - 1].ddadr = DDADR_STOP;
    wmb();

    + /*
    + * The PXA27x DMA controller encounters overhead when working with
    + * unaligned (to 8-byte boundaries) data, so switch on byte alignment
    + * mode only if we have unaligned data.
    + */
    + if (dalgn)
    + DALGN |= (1 << host->dma);
    + else
    + DALGN &= (1 << host->dma);
    DDADR(host->dma) = host->sg_dma;
    DCSR(host->dma) = DCSR_RUN;
    }

    --
    --
    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 39/47] drivers/isdn/i4l/isdn_common.c fix small resource leak

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

    ------------------
    From: Darren Jenkins

    commit 4fc89e3911aa5357b55b85b60c4beaeb8a48a290 upstream

    Coverity CID: 1356 RESOURCE_LEAK

    I found a very old patch for this that was Acked but did not get applied
    https://lists.linux-foundation.org/p...er/016362.html

    There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when
    copy_from_user() returns an un-copied data length (length != 0). The below
    patch should be a minimally invasive fix.

    Signed-off-by: Darren Jenkins
    Acked-by: Karsten Keil
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    drivers/isdn/i4l/isdn_common.c | 4 +++-
    1 file changed, 3 insertions(+), 1 deletion(-)

    --- a/drivers/isdn/i4l/isdn_common.c
    +++ b/drivers/isdn/i4l/isdn_common.c
    @@ -1977,8 +1977,10 @@ isdn_writebuf_stub(int drvidx, int chan,
    if (!skb)
    return -ENOMEM;
    skb_reserve(skb, hl);
    - if (copy_from_user(skb_put(skb, len), buf, len))
    + if (copy_from_user(skb_put(skb, len), buf, len)) {
    + dev_kfree_skb(skb);
    return -EFAULT;
    + }
    ret = dev->drv[drvidx]->interface->writebuf_skb(drvidx, chan, 1, skb);
    if (ret <= 0)
    dev_kfree_skb(skb);

    --
    --
    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 00/47] 2.6.25-stable review

    Greg KH wrote:
    > This is the start of the stable review cycle for the 2.6.25.12 release.
    > There are 47 patches in this series, all will be posted as a response to
    > this one. If anyone has any issues with these being applied, please let
    > us know. If anyone is a maintainer of the proper subsystem, and wants
    > to add a Signed-off-by: line to the patch, please respond with it.
    >
    > These patches are sent out with a number of different people on the
    > Cc: line. If you wish to be a reviewer, please email stable@kernel.org
    > to add your name to the list. If you want to be off the reviewer list,
    > also email us.
    >
    > Responses should be made by July 24, 22:00:00 UTC. Anything received
    > after that time might be too late.
    >

    Greg,

    Would it be possible to add the seven patches that I sent two days ago?
    It is very important that patch #1 gets into the first dot release, to
    avoid confusion with cx18 firmware revisions. Thanks.

    These were sent to stable at kernel dot org:

    [2.6.26.y PATCH 1/7] V4L: cx18: Upgrade to newer firmware & update
    documentation
    http://linuxtv.org/pipermail/v4l-dvb...ly/007427.html

    [2.6.26.y PATCH 2/7] DVB: dib0700: add support for Hauppauge Nova-TD
    Stick 52009
    http://linuxtv.org/pipermail/v4l-dvb...ly/007429.html

    [2.6.26.y PATCH 3/7] V4L: uvcvideo: Fix a buffer overflow in format
    descriptor parsing
    http://linuxtv.org/pipermail/v4l-dvb...ly/007428.html

    [2.6.26.y PATCH 4/7] V4L: uvcvideo: Use GFP_NOIO when allocating memory
    during resume
    http://linuxtv.org/pipermail/v4l-dvb...ly/007430.html

    [2.6.26.y PATCH 5/7] V4L: uvcvideo: Don't free URB buffers on suspend
    http://linuxtv.org/pipermail/v4l-dvb...ly/007431.html

    [2.6.26.y PATCH 6/7] V4L: uvcvideo: Make input device support optional
    http://linuxtv.org/pipermail/v4l-dvb...ly/007432.html

    [2.6.26.y PATCH 7/7] V4L: uvcvideo: Add support for Medion Akoya Mini
    E1210 integrated webcam
    http://linuxtv.org/pipermail/v4l-dvb...ly/007433.html

    Regards,

    Mike Krufky
    --
    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 00/47] 2.6.25-stable review

    Michael Krufky wrote:
    > Greg KH wrote:
    >
    >> This is the start of the stable review cycle for the 2.6.25.12 release.

    > Would it be possible to add the seven patches that I sent two days ago?
    > It is very important that patch #1 gets into the first dot release, to
    > avoid confusion with cx18 firmware revisions. Thanks.


    Please disregard that email -- I mistakenly thought this was a 2.6.26.1
    review cycle -- my mistake!

    I'm sorry for the noise.

    -Mike
    --
    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 44/47] pxamci: fix byte aligned DMA transfers

    Hi,

    On Wed, Jul 23, 2008 at 1:17 AM, Greg KH wrote:
    > 2.6.25-stable review patch. If anyone has any objections, please let us
    > know.


    There is an ugly typo in the patch below that was fixed by Karl Beldan:
    http://git.kernel.org/?p=linux/kerne...30e007072429c3

    Not sure how you handle this, maybe this patch should only go in
    together with the other.

    > ------------------
    > From: Philipp Zabel
    >
    > commit 97f8571e663c808ad2d01a396627235167291556 upstream
    >
    > The pxa27x DMA controller defaults to 64-bit alignment. This caused
    > the SCR reads to fail (and, depending on card type, error out) when
    > card->raw_scr was not aligned on a 8-byte boundary.
    >
    > For performance reasons all scatter-gather addresses passed to
    > pxamci_request should be aligned on 8-byte boundaries, but if
    > this can't be guaranteed, byte aligned DMA transfers in the
    > have to be enabled in the controller to get correct behaviour.
    >
    > Signed-off-by: Philipp Zabel
    > Signed-off-by: Pierre Ossman
    > Signed-off-by: Linus Torvalds
    > Signed-off-by: Greg Kroah-Hartman
    >
    > ---
    > drivers/mmc/host/pxamci.c | 13 +++++++++++++
    > 1 file changed, 13 insertions(+)
    >
    > --- a/drivers/mmc/host/pxamci.c
    > +++ b/drivers/mmc/host/pxamci.c
    > @@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxa
    > unsigned int nob = data->blocks;
    > unsigned long long clks;
    > unsigned int timeout;
    > + bool dalgn = 0;
    > u32 dcmd;
    > int i;
    >
    > @@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxa
    > host->sg_cpu[i].dcmd = dcmd | length;
    > if (length & 31 && !(data->flags & MMC_DATA_READ))
    > host->sg_cpu[i].dcmd |= DCMD_ENDIRQEN;
    > + /* Not aligned to 8-byte boundary? */
    > + if (sg_dma_address(&data->sg[i]) & 0x7)
    > + dalgn = 1;
    > if (data->flags & MMC_DATA_READ) {
    > host->sg_cpu[i].dsadr = host->res->start + MMC_RXFIFO;
    > host->sg_cpu[i].dtadr = sg_dma_address(&data->sg[i]);
    > @@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxa
    > host->sg_cpu[host->dma_len - 1].ddadr = DDADR_STOP;
    > wmb();
    >
    > + /*
    > + * The PXA27x DMA controller encounters overhead when working with
    > + * unaligned (to 8-byte boundaries) data, so switch on byte alignment
    > + * mode only if we have unaligned data.
    > + */
    > + if (dalgn)
    > + DALGN |= (1 << host->dma);
    > + else
    > + DALGN &= (1 << host->dma);

    ^^^^^ here

    > DDADR(host->dma) = host->sg_dma;
    > DCSR(host->dma) = DCSR_RUN;
    > }
    >
    > --
    >


    regards
    Philipp
    --
    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: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

    On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
    > Hi,
    >
    > On Wed, Jul 23, 2008 at 1:17 AM, Greg KH wrote:
    > > 2.6.25-stable review patch. If anyone has any objections, please let us
    > > know.

    >
    > There is an ugly typo in the patch below that was fixed by Karl Beldan:
    > http://git.kernel.org/?p=linux/kerne...30e007072429c3
    >
    > Not sure how you handle this, maybe this patch should only go in
    > together with the other.


    As the above mentioned patch isn't in Linus's tree yet, I can't take it.

    Care to send it to stable@kernel.org when it does go in? Or is this
    current patch just broken without it and not worth adding at all?

    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/

  9. Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers



    On Wed, 23 Jul 2008, Greg KH wrote:

    > On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
    > >
    > > There is an ugly typo in the patch below that was fixed by Karl Beldan:
    > > http://git.kernel.org/?p=linux/kerne...30e007072429c3
    > >
    > > Not sure how you handle this, maybe this patch should only go in
    > > together with the other.

    >
    > As the above mentioned patch isn't in Linus's tree yet, I can't take it.
    >
    > Care to send it to stable@kernel.org when it does go in? Or is this
    > current patch just broken without it and not worth adding at all?


    Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c
    upstream. I don't know why it has a different SHA1 in the mmc tree, but I
    assume that it's because the MMC tree has rebased at some point. Ugh.

    Linus
    --
    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/

  10. Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

    On Wed, Jul 23, 2008 at 01:24:12PM -0700, Linus Torvalds wrote:
    >
    >
    > On Wed, 23 Jul 2008, Greg KH wrote:
    >
    > > On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
    > > >
    > > > There is an ugly typo in the patch below that was fixed by Karl Beldan:
    > > > http://git.kernel.org/?p=linux/kerne...30e007072429c3
    > > >
    > > > Not sure how you handle this, maybe this patch should only go in
    > > > together with the other.

    > >
    > > As the above mentioned patch isn't in Linus's tree yet, I can't take it.
    > >
    > > Care to send it to stable@kernel.org when it does go in? Or is this
    > > current patch just broken without it and not worth adding at all?

    >
    > Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c
    > upstream. I don't know why it has a different SHA1 in the mmc tree, but I
    > assume that it's because the MMC tree has rebased at some point. Ugh.


    Ah, thanks, I missed that.

    Hm, that is added post 2.6.26, so I'll add this fixup patch to the
    ..25-stable tree, and also add this one to the .26-stable queue.

    Philipp, is that correct, or does this original one also need to get
    added to the .26-stable queue 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/

  11. Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

    On Wed, Jul 23, 2008 at 10:32 PM, Greg KH wrote:
    > On Wed, Jul 23, 2008 at 01:24:12PM -0700, Linus Torvalds wrote:
    >>
    >>
    >> On Wed, 23 Jul 2008, Greg KH wrote:
    >>
    >> > On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
    >> > >
    >> > > There is an ugly typo in the patch below that was fixed by Karl Beldan:
    >> > > http://git.kernel.org/?p=linux/kerne...30e007072429c3
    >> > >
    >> > > Not sure how you handle this, maybe this patch should only go in
    >> > > together with the other.
    >> >
    >> > As the above mentioned patch isn't in Linus's tree yet, I can't take it.
    >> >
    >> > Care to send it to stable@kernel.org when it does go in? Or is this
    >> > current patch just broken without it and not worth adding at all?

    >>
    >> Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c
    >> upstream. I don't know why it has a different SHA1 in the mmc tree, but I
    >> assume that it's because the MMC tree has rebased at some point. Ugh.


    Thank you, I think when I wrote my mail it wasn't pulled yet.

    > Ah, thanks, I missed that.
    >
    > Hm, that is added post 2.6.26, so I'll add this fixup patch to the
    > .25-stable tree, and also add this one to the .26-stable queue.


    Ok, thank you.

    > Philipp, is that correct, or does this original one also need to get
    > added to the .26-stable queue as well?


    AFAICT, the original one (97f8571e663c808ad2d01a396627235167291556) is
    post-26, too.

    Both should be applied together. Although it is unlikely that with the
    broken patch MMC accesses will accidentally clear the DALGN bits of
    other running (unaligned) DMA chains (I'm not aware of any drivers
    using unaligned DMA), the PXA27x developer manual says that this "must
    not" be done. If it would result in memory corruption or lockups, I
    don't know.

    regards
    Philipp
    --
    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/

  12. Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

    On Thu, Jul 24, 2008 at 12:33:34PM +0200, pHilipp Zabel wrote:
    > Both should be applied together. Although it is unlikely that with the
    > broken patch MMC accesses will accidentally clear the DALGN bits of
    > other running (unaligned) DMA chains (I'm not aware of any drivers
    > using unaligned DMA), the PXA27x developer manual says that this "must
    > not" be done. If it would result in memory corruption or lockups, I
    > don't know.


    Ok, I'll add them both to the .26 queue as well.

    thanks for the information,

    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/

  13. Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers



    On Thu, 24 Jul 2008, pHilipp Zabel wrote:
    > > On Wed, Jul 23, 2008 at 01:24:12PM -0700, Linus Torvalds wrote:
    > >>
    > >> Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c
    > >> upstream. I don't know why it has a different SHA1 in the mmc tree, but I
    > >> assume that it's because the MMC tree has rebased at some point. Ugh.

    >
    > Thank you, I think when I wrote my mail it wasn't pulled yet.


    Pulling doesn't change the SHA1 ID of a commit, so _if_ it had been stable
    in the -mmc tree, it would have had the same commit in the kernel too.
    That's very much a design issue in git: the same commit always has the
    same ID. _ALWAYS_.

    So the fact that the ID changed implies that something odd happened in the
    -mmc tree. Most likely a rebase. And again, this implies that somebody
    rebased already-public commits, since otherwise nobody would have ever
    even seen the original SHA1 ID.

    Which is not good behaviour, _exactly_ because it makes it much harder for
    people to work together - suddenly a commit that got reported (for
    whatever reason: bug-report or 'please backport', it's all the same issue
    in the end) no longer exists.

    Linus
    --
    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/

  14. Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

    On Thu, 24 Jul 2008 12:22:56 -0700 (PDT)
    Linus Torvalds wrote:

    >
    > Pulling doesn't change the SHA1 ID of a commit, so _if_ it had been stable
    > in the -mmc tree, it would have had the same commit in the kernel too.
    > That's very much a design issue in git: the same commit always has the
    > same ID. _ALWAYS_.
    >
    > So the fact that the ID changed implies that something odd happened in the
    > -mmc tree. Most likely a rebase. And again, this implies that somebody
    > rebased already-public commits, since otherwise nobody would have ever
    > even seen the original SHA1 ID.


    Indeed I did. Things got shuffled around a bit when I updated the
    patch queue with more stuff and the old attempt hadn't gotten merged
    yet.

    >
    > Which is not good behaviour, _exactly_ because it makes it much harder for
    > people to work together - suddenly a commit that got reported (for
    > whatever reason: bug-report or 'please backport', it's all the same issue
    > in the end) no longer exists.


    I've always considered my "for-linus" branch to be primarily that, but I
    guess I can be more careful so that other people can use it as well.

    Rgds
    --
    -- Pierre Ossman

    WARNING: This correspondence is being monitored by the
    Swedish government. Make sure your server uses encryption
    for SMTP traffic and consider using PGP for end-to-end
    encryption.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (GNU/Linux)

    iEYEARECAAYFAkiI50cACgkQ7b8eESbyJLg/5gCfb3eZqB2BqaLbIPBr515f2xAF
    Vc8An0aZsmONRRcsswb7EUdsm0xhVZJ0
    =S3aQ
    -----END PGP SIGNATURE-----


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3