linux-kernel - Re: [GIT PULL] IOMMU updates for 5.11

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] [day] [month] [year] [list]

Date:   Wed, 16 Dec 2020 14:21:54 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Will Deacon <will@...nel.org>
Cc:     iommu <iommu@...ts.linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Joerg Roedel <joro@...tes.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Robin Murphy <robin.murphy@....com>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [GIT PULL] IOMMU updates for 5.11

On Wed, Dec 16, 2020 at 2:10 PM Will Deacon <will@...nel.org> wrote:
>
> Brill, cheers. I didn't realise you were going by subsystem, so that's
> why I was getting worried.

My "by subsystem" is a bit fuzzy, and it only really happens when I
have a _lot_ of pending pull requests. Which this merge window has had
more than most, since usually they come in a bit more spread out.

But when I have tens of pull requests in my mailbox, I tend to do them
by a very rough "similarity" metric, ie I'll generally bunch up
filesystem pulls together, but also pulls from the same person
together.

So it's not necessarily by any really strict subsystem thing, but you
can kind of see some patterns.

For example, today I started out with a group of audit and security
layer ones (and printk, which doesn't really group with much anything
else), then moved through virtualization platforms to some arch
updates, and then on to io_uring and block. Which got me to scsi and
rdma, and then iommu.

Not really much of a logical ordering really, more just me trying to
not be _entirely_ random.

But the grouping is definitely also about when things come in - I had
a different group of security layer and architecture updates on
Monday. The ones today hadn't come in yet at that point.

By tomorrow, my pending pile has hopefully shrunk so much that I do
things mainly by when they come in, rather than have a big pile and
trying to do them by some rough grouping.

           Linus