linux-kernel - Re: [PATCH] debugfs: add get/set for atomic types

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]

Date:	Fri, 26 Oct 2012 16:55:47 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org,
	Robert Jennings <rcj@...ux.vnet.ibm.com>
Subject: Re: [PATCH] debugfs: add get/set for atomic types

On Fri, Oct 26, 2012 at 01:46:38PM -0500, Seth Jennings wrote:
> On 10/26/2012 11:13 AM, Greg Kroah-Hartman wrote:
> > On Fri, Oct 26, 2012 at 10:49:01AM -0500, Seth Jennings wrote:
> >> debugfs currently lacks the ability to create attributes
> >> that set/get atomic_t values.
> >>
> >> This patch adds support for this through a new
> >> debugfs_create_atomic_t() function.
> > 
> > Why would you want to set an atomic variable type from userspace?
> 
> In my particular use case, I'm not setting from userspace, only getting.

That's good, you wouldn't want to set an atomic from userspace.

> All the other types are symmetric, being both settable and gettable,
> so I was just trying to blend with the other types.

Fair enough.

> > What in-kernel code needs this?
> 
> None, yet.  I am working on code that does.
> 
> If you would rather me send this as part of the patchset for that
> code, I can.  I just wanted to get this in early if I could since it
> is functionality I can see others using.
> 
> For an example, see drivers/staging/ramster/zcache-main.c:132 where
> both atomic and non-atomic version of stats are being maintained so
> that the non-atomic version can be read by debugfs.
> 
> Beside not having an in-kernel user yet, does this approach look good
> to you?

It looks reasonable, but please hold off and submit this as part of a
patch series that needs it.  No need to add it now.

thanks,

greg k-h
--
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/