linux-kernel - Re: [PATCH 3/3] target: simplify target_wait_for_sess

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:	Tue, 14 May 2013 22:19:09 -0400
From:	Jörn Engel <joern@...fs.org>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	target-devel <target-devel@...r.kernel.org>
Subject: Re: [PATCH 3/3] target: simplify target_wait_for_sess_cmds()

On Tue, 14 May 2013 20:05:30 -0700, Nicholas A. Bellinger wrote:
> On Tue, 2013-05-14 at 12:29 -0400, Jörn Engel wrote:
> > On Mon, 13 May 2013 20:08:44 -0700, Nicholas A. Bellinger wrote:
> > > On Mon, 2013-05-13 at 18:00 -0400, Jörn Engel wrote:
> > > > 
> > > > I agree that the overhead doesn't matter.  The msleep(100) spells this
> > > > out rather explicitly.  What does matter is that a) the patch retains
> > > > old behaviour with much simpler code and b) it fixes a race that kills
> > > > the machine.  I can live without a, but very much want to keep b. ;)
> > > 
> > > Fucking around with ->sess_cmd_lock during each loop of ->sess_cmd_list
> > > in target_wait_for_sess_cmds is not simpler code..
> > 
> > I could argue that fucking around with ->sess_cmd_lock during each
> > loop is simpler than the communication through cmd_wait_set and
> > cmd_wait_comp.  But simplicity is ultimately subjective and we can
> > argue all day.
> 
> What I don't like is the endless loop in target_wait_for_sess_cmds()
> that acquires and releases ->sess_cmd_lock for every command, with a
> hard-coded msleep thrown in.

Not for every command.  If the list is empty, it waits exactly 0x.  If
all the commands finish within 100ms, it waits exactly 1x.  Otherwise
it waits for as long as it takes, plus up to 100ms.

I agree this sucks, but the alternative was more code and we got it
wrong.  The old adage is that for every 20 lines of code you add a
bug, and these 32 lines definitely had one.  Which is why I almost
always prefer less code.

There is more to complexity than mere line count.  Your original code
also made it impossible to judge the correctness of the code without
using grep.  My loop is "either the commands eventually all complete,
or we hang forever."  Your loop was "grep for cmd_wait_set, grep for
cmd_wait_comp and check every function that lights up.  Assuming all
of that is correct, either the commands eventually all complete, or we
hang forever."

But if I cannot convince you, I guess we have to live with the bug
as-is.  Telling management that I have to spend another week of my
time and several weeks of testing for a bug that is already fixed is a
hard sell.  And even if I had that much free time and my wife didn't
complain, I don't have the necessary equipment.  So the decision is
yours.  You are the maintainer and have every right to block my patch.

Jörn

--
Modules are evil. They are a security issue, and they encourage a
"distro kernel" approach that takes forever to compile. Just say no.
Build a lean and mean kernel that actually has what you need, and nothing
more. And don't spend stupid time compiling modules you won't need.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/