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: <20251013012855.GB52546@system.software.com>
Date: Mon, 13 Oct 2025 10:28:55 +0900
From: Byungchul Park <byungchul@...com>
To: Bagas Sanjaya <bagasdotme@...il.com>
Cc: linux-kernel@...r.kernel.org, kernel_team@...ynix.com,
	torvalds@...ux-foundation.org, damien.lemoal@...nsource.wdc.com,
	linux-ide@...r.kernel.org, adilger.kernel@...ger.ca,
	linux-ext4@...r.kernel.org, mingo@...hat.com, peterz@...radead.org,
	will@...nel.org, tglx@...utronix.de, rostedt@...dmis.org,
	joel@...lfernandes.org, sashal@...nel.org, daniel.vetter@...ll.ch,
	duyuyang@...il.com, johannes.berg@...el.com, tj@...nel.org,
	tytso@....edu, willy@...radead.org, david@...morbit.com,
	amir73il@...il.com, gregkh@...uxfoundation.org, kernel-team@....com,
	linux-mm@...ck.org, akpm@...ux-foundation.org, mhocko@...nel.org,
	minchan@...nel.org, hannes@...xchg.org, vdavydov.dev@...il.com,
	sj@...nel.org, jglisse@...hat.com, dennis@...nel.org, cl@...ux.com,
	penberg@...nel.org, rientjes@...gle.com, vbabka@...e.cz,
	ngupta@...are.org, linux-block@...r.kernel.org,
	josef@...icpanda.com, linux-fsdevel@...r.kernel.org, jack@...e.cz,
	jlayton@...nel.org, dan.j.williams@...el.com, hch@...radead.org,
	djwong@...nel.org, dri-devel@...ts.freedesktop.org,
	rodrigosiqueiramelo@...il.com, melissa.srw@...il.com,
	hamohammed.sa@...il.com, harry.yoo@...cle.com,
	chris.p.wilson@...el.com, gwan-gyeong.mun@...el.com,
	max.byungchul.park@...il.com, boqun.feng@...il.com,
	longman@...hat.com, yunseong.kim@...csson.com, ysk@...lloc.com,
	yeoreum.yun@....com, netdev@...r.kernel.org,
	matthew.brost@...el.com, her0gyugyu@...il.com, corbet@....net,
	catalin.marinas@....com, bp@...en8.de, dave.hansen@...ux.intel.com,
	x86@...nel.org, hpa@...or.com, luto@...nel.org,
	sumit.semwal@...aro.org, gustavo@...ovan.org,
	christian.koenig@....com, andi.shyti@...nel.org, arnd@...db.de,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
	rppt@...nel.org, surenb@...gle.com, mcgrof@...nel.org,
	petr.pavlu@...e.com, da.gomez@...nel.org, samitolvanen@...gle.com,
	paulmck@...nel.org, frederic@...nel.org, neeraj.upadhyay@...nel.org,
	joelagnelf@...dia.com, josh@...htriplett.org, urezki@...il.com,
	mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
	qiang.zhang@...ux.dev, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com,
	chuck.lever@...cle.com, neil@...wn.name, okorniev@...hat.com,
	Dai.Ngo@...cle.com, tom@...pey.com, trondmy@...nel.org,
	anna@...nel.org, kees@...nel.org, bigeasy@...utronix.de,
	clrkwllms@...nel.org, mark.rutland@....com, ada.coupriediaz@....com,
	kristina.martsenko@....com, wangkefeng.wang@...wei.com,
	broonie@...nel.org, kevin.brodsky@....com, dwmw@...zon.co.uk,
	shakeel.butt@...ux.dev, ast@...nel.org, ziy@...dia.com,
	yuzhao@...gle.com, baolin.wang@...ux.alibaba.com,
	usamaarif642@...il.com, joel.granados@...nel.org,
	richard.weiyang@...il.com, geert+renesas@...der.be,
	tim.c.chen@...ux.intel.com, linux@...blig.org,
	alexander.shishkin@...ux.intel.com, lillian@...r-ark.net,
	chenhuacai@...nel.org, francesco@...la.it,
	guoweikang.kernel@...il.com, link@...o.com, jpoimboe@...nel.org,
	masahiroy@...nel.org, brauner@...nel.org,
	thomas.weissschuh@...utronix.de, oleg@...hat.com, mjguzik@...il.com,
	andrii@...nel.org, wangfushuai@...du.com, linux-doc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
	linaro-mm-sig@...ts.linaro.org, linux-i2c@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-modules@...r.kernel.org,
	rcu@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH v17 28/47] dept: add documentation for dept

On Fri, Oct 03, 2025 at 09:44:28AM +0700, Bagas Sanjaya wrote:
> On Thu, Oct 02, 2025 at 05:12:28PM +0900, Byungchul Park wrote:
> > This document describes the concept and APIs of dept.
> >
> > Signed-off-by: Byungchul Park <byungchul@...com>
> > ---
> >  Documentation/dependency/dept.txt     | 735 ++++++++++++++++++++++++++
> >  Documentation/dependency/dept_api.txt | 117 ++++
> >  2 files changed, 852 insertions(+)
> >  create mode 100644 Documentation/dependency/dept.txt
> >  create mode 100644 Documentation/dependency/dept_api.txt
> 
> What about writing dept docs in reST (like the rest of kernel documentation)?

Sorry for late reply, but sure.  I should and will.  Thank you!

> ---- >8 ----
> diff --git a/Documentation/dependency/dept.txt b/Documentation/locking/dept.rst
> similarity index 92%
> rename from Documentation/dependency/dept.txt
> rename to Documentation/locking/dept.rst
> index 5dd358b96734e6..7b90a0d95f0876 100644
> --- a/Documentation/dependency/dept.txt
> +++ b/Documentation/locking/dept.rst

However, I'm not sure if dept is about locking.  dept is about general
waits e.g. wait_for_completion(), wait_event(), and so on, rather than
just waits involved in typical locking mechanisms e.g. spin lock, mutex,
and so on.

[snip]

> > +
> > +   context X            context Y
> > +
			     /*
			      * Acquired A.
			      */
> > +                        mutex_lock A

			     /*
			      * Request something that will be handled
			      * through e.g. wq, deamon or any its own
			      * way, and then do 'complete B'.
			      */
			     request_xxx_and_complete_B();
        /*
	 * The request from
	 * context Y has been
	 * done.  So running
	 * toward 'complete B'.
	 */

	/*
	 * Wait for A to be
	 * released, but will
	 * never happen.
	 */
> > +   mutex_lock A <- DEADLOCK
			     /*
			      * Wait for 'complete B' to happen, but
			      * will never happen.
			      */
> > +                        wait_for_complete B <- DEADLOCK
	/*
	 * Never reachable.
	 */
> > +   complete B

			     /*
			      * Never reachable.
			      */
> > +                        mutex_unlock A
> > +   mutex_unlock A
> 
> Can you explain how DEPT detects deadlock on the second example above (like
> the first one being described in "How DEPT works" section)?

Sure.  I added the explanation inline above.  Don't hesitate if you have
any questions.  Thanks.

	Byungchul
> 
> Confused...
> 
> --
> An old man doll... just what I always wanted! - Clara

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ