linux-kernel - Re: [GIT PULL] Char/Misc driver patches for 4.12-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:   Thu, 4 May 2017 19:28:05 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Greg KH <gregkh@...uxfoundation.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Char/Misc driver patches for 4.12-rc1

On Thu, May 4, 2017 at 5:18 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
>
> Here is the big set of new char/misc driver drivers and features for
> 4.12-rc1.

Ugh. I'm not particularly happy with the conflicts I got and my
resolutions there-of.

I did resolve them - in the case of drivers/scsi/osd/osd_uld.c as per
James' suggestion from his SCSI pull. Thanks.

But even that resolution I'm not entirely happy with: somebody should
check that it cleans up oud properly

But the one I'm really unhappy with is my tpm-chip.c resolution.

In particular, commit 8dbbf5825181 ("tpm-chip: utilize new
cdev_device_add helper function") made the tpm-chip code use that
cdev_device_add/del pattern for chip->[c]dev. Fine.

But then commit fdc915f7f719 ("tpm: expose spaces via a device link
/dev/tpmrm<n>") added the *exact* same old pattern to a new
"chip->[c]devs" (note the extra 's') and did so in a particularly ugly
way too.

James, why did you do that nasty

        if (chip->flags & TPM_CHIP_FLAG_TPM2)

*twice*, instead of just doing things properly inside *one* test?

Anyway, my merge resolution tries to just apply the same
cdev_device_add/del pattern to the new chip->[c]devs entries, because
not doing so seemed criminally ugly.

It compiles. It looks better than the mess it was. But it may not work.

James, Jarkko, you need to look at that tpm merge of mine. And James,
double-check my osd_uld thing too.

                 Linus