linux-kernel - Re: [GIT PULL]: dmaengine updates for v5.19-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 29 May 2022 11:49:09 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Vinod Koul <vkoul@...nel.org>, Dave Jiang <dave.jiang@...el.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     dma <dmaengine@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL]: dmaengine updates for v5.19-rc1

On Sun, May 29, 2022 at 10:50 AM Vinod Koul <vkoul@...nel.org> wrote:
>
> Please pull to receive the dmaengine updates for this cycle. Nothing
> special, this includes a couple of new device support and new driver
> support and bunch of driver updates.

Vinod, _please_ report it when it turns out that there are semantic
merge issues in linux-next.

The whole point of linux-next is to report and find problems, but that
also means that if the issues found in linux-next are then completely
ignored, the _point_ of being in linux-next goes away.

In particular, there was a semantic drivers/dma/idxd/device.c that git
was perfectly happy to merge one way, but that needed manual
intervention to get the locking right. See

   https://lore.kernel.org/all/a6df0b8a-dc42-51e4-4b7b-62d1d11c7800@intel.com/

and this is exactly the kind of thing that should be mentioned in the
pull request, because no, I do not track every single merge issue in
linux-next.

I only catch them when something makes me go "Hmm", and in this case
it was a different conflict near-by that just happened to make me look
closer (the same one that Stephen had noted).

Stephen makes this clear in his notifications:

 "This is now fixed as far as linux-next is concerned, but any non
  trivial conflicts should be mentioned to your upstream maintainer when
  your tree is submitted for merging"

and yes, the original merge was indeed trivial and wouldn't have
needed any further mention had it _stayed_ that way.

But it didn't actually stay that way, as pointed out by Dave Jiang in
that thread.

The fact that I caught it this time doesn't mean that I will catch
things like this in general. I'm pretty good at merging, but there
really is a reason linux-next exists.

                      Linus