linux-kernel - Re: [PATCH] IB/fmr_pool: Convert the cleanup thread into kthread worker API

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 26 Apr 2017 10:40:48 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Doug Ledford <dledford@...hat.com>
Cc:     Sean Hefty <sean.hefty@...el.com>,
        Hal Rosenstock <hal.rosenstock@...il.com>,
        linux-rdma@...r.kernel.org, Tejun Heo <tj@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] IB/fmr_pool: Convert the cleanup thread into kthread
 worker API

On Tue 2017-04-25 14:29:48, Doug Ledford wrote:
> On Mon, 2016-10-17 at 17:39 +0200, Petr Mladek wrote:
> > Kthreads are currently implemented as an infinite loop. Each
> > has its own variant of checks for terminating, freezing,
> > awakening. In many cases it is unclear to say in which state
> > it is and sometimes it is done a wrong way.
> > 
> > The plan is to convert kthreads into kthread_worker or workqueues
> > API. It allows to split the functionality into separate operations.
> > It helps to make a better structure. Also it defines a clean state
> > where no locks are taken, IRQs blocked, the kthread might sleep
> > or even be safely migrated.
> > 
> > The kthread worker API is useful when we want to have a dedicated
> > single thread for the work. It helps to make sure that it is
> > available when needed. Also it allows a better control, e.g.
> > define a scheduling priority.
> > 
> > This patch converts the frm_pool kthread into the kthread worker
> > API because I am not sure how busy the thread is. It is well
> > possible that it does not need a dedicated kthread and workqueues
> > would be perfectly fine. Well, the conversion between kthread
> > worker API and workqueues is pretty trivial.
> > 
> > The patch moves one iteration from the kthread into the work
> > function.
> > It is queued only when there is a pending work. Therefore we do not
> > need to compare flush_ser and req_ser at the beginning. On the
> > contrary,
> > the same work could be queued only once at a time. Therefore it has
> > to
> > re-queue itself if some requests are pending.
> > 
> > Otherwise, wake_up_process() is replaced by queuing the work.
> > 
> > Important: The change is only compile tested. I did not find an easy
> > way how to check it in a real life.
> > 
> > Signed-off-by: Petr Mladek <pmladek@...e.com>
> > TO: Doug Ledford <dledford@...hat.com>
> > CC: Sean Hefty <sean.hefty@...el.com>
> > CC: Hal Rosenstock <hal.rosenstock@...il.com>
> > CC: linux-rdma@...r.kernel.org
> 
> Hi Petr,
> 
> This patch has sat around for a long time.  I've decided to take it in
> this release, even though it isn't really tested, on the basis that we
> will perform some testing internally using the mthca driver (if you
> combine the mthca driver with certain upper level protocols, you can
> create a situation where FMR memory will be the preferred memory in use
> IIRC) and revert if it doesn't work properly.

Thanks a lot for taking it. I hope that it will be fine.

Best Regards,
Petr