linux-kernel - Re: [PATCH] CIFS: make cifsd (more)

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] [day] [month] [year] [list]

Message-ID: <a781481a0706300738g2e92d959qeb50bebdf34db13f@mail.gmail.com>
Date:	Sat, 30 Jun 2007 20:08:01 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Steve French" <smfrench@...il.com>
Cc:	"Jeff Layton" <jlayton@...hat.com>,
	"Christoph Hellwig" <hch@...radead.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] CIFS: make cifsd (more)

[ Trimmed Cc: list ]

On 6/30/07, Steve French <smfrench@...il.com> wrote:
> The reason that cifs switched from wait_for_completion to the kthread
> call to cifs_demultiplex_thread in the first place is because without
> use of kthread it won't work with a linux-vserver.   See the thread:
>
> http://marc.info/?l=linux-cifs-client&m=117552761703381&w=2
>
> If we take out the kthread call, we break those guys.
>
> I agree that using sk_callbacks is worth looking into - I only found
> ocfs2 and SunRPC (NFS) though that used it.   Is there a better
> example though?   The NFS socket handling code is huge
> (net/sunrpc/xprtsck.c) - something seems wrong when replacing a few
> lines of code with a new 1675 line file.  There must be a better
> example of doing what you suggest...

You're correct. "Right" / "elegant" solutions are rarely (if ever?) complex
and involved. Simplicity _is_ good. I see no point in converting 5 good
lines of maintainable, readable, solid code with 1000 lines of kludge :-)
just to work-around this kthreads limitation. But then, of course, the call
is yours.

> I am tempted to drop the socket timeout (which cifs sets to 7 seconds)
> to a smaller number and not use signals at all rather than add that
> much complexity

Timeout too low => CPU wastage => power wastage. [ Think laptop
batteries, with say 5 cifsd kthreads waking up once every second ... ]
Timeout too high => umount(2) hangs, annoys user, user takes
drastic actions ... so think of some good "magic number" :-)

I don't quite think of all these suggestions as solutions at all -- they
are workarounds at best, IMHO (for kthread's limitation in dealing with
kernel threads that want to block -- I still don't see any fundamental
reasoning / logic behind why kthreads should be banned from doing
blocking recv's -- if there is, please let me know too).

Don't have much else to say than what I already have on the two
threads discussing this.

Satyam
-
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/