linux-kernel - Re: [GIT PULL] dax fixes for 4.20-rc6

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]

Message-ID: <CAHk-=wgAONwr6pMn+D2OsMZjAB5zNaMWSW5KdTM+L72gGnhV2Q@mail.gmail.com>
Date:   Sun, 9 Dec 2018 10:01:51 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     dan.j.williams@...el.com
Cc:     Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        linux-nvdimm@...ts.01.org
Subject: Re: [GIT PULL] dax fixes for 4.20-rc6

On Sat, Dec 8, 2018 at 10:26 PM Williams, Dan J
<dan.j.williams@...el.com> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/dax-fixes-4.20-rc6

What's going on with the odd non-exclusive exclusive wait?

        prepare_to_wait_exclusive(wq, &ewait.wait, TASK_UNINTERRUPTIBLE);
        ...
        /*
         * Entry lock waits are exclusive. Wake up the next waiter since
         * we aren't sure we will acquire the entry lock and thus wake
         * the next waiter up on unlock.
         */
        if (waitqueue_active(wq))
                __wake_up(wq, TASK_NORMAL, 1, &ewait.key);

that seems to make little or no sense.

Why isn't that prepare_to_wait_exclusive() just a regular
prepare_to_wait(), and then the whole "let's wake up anybody else" can
be removed?

I've pulled it, but am awaiting explanation of what looks like some
pretty crazy code. I *suspect* it's a copy-and-paste situation where
you took the exclusive wait from somewhere else.

                Linus