linux-kernel - Re: [PATCH] sysctl: Add a feature to drop caches selectively

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:	Thu, 26 Jun 2014 11:30:34 +0200
From:	Maksym Planeta <mcsim.planeta@...il.com>
To:	dedekind1@...il.com
Cc:	Thomas Knauth <thomas.knauth@....de>,
	David Rientjes <rientjes@...gle.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sysctl: Add a feature to drop caches selectively

> With a binary interface like an ioctl I can see how you could have extra
> unused fields which you can ignore now and let people start adding extra
> options like the range in the future.

Yes, ioctl is another possibility. But I would argue that sysctl is
more convenient interface, because idea of sdrop_caches is similar to
drop_caches's one and it is convenient to have these interfaces in the
same place. But if sdrop_caches uses procfs it seems that there is no
easy way to pass parameters of different types in one write operation.

> Other questions I'd ask would be - how about the access control model?
> Will only root be able to drop caches? Why can't I drop caches for my
> own file?

Access control model is the same as for drop_caches. This means that
only root can write to this file. But it is easy to add a feature that
allows any user to clean page cache of inodes that this user owns.

2014-06-25 15:42 GMT+02:00 Artem Bityutskiy <dedekind1@...il.com>:
> On Wed, 2014-06-25 at 15:23 +0200, Thomas Knauth wrote:
>> On Wed, Jun 25, 2014 at 11:56 AM, Artem Bityutskiy <dedekind1@...il.com> wrote:
>> > Thanks for the answer, although you forgot to comment on the question
>> > about possibly extending the new interface to work with file ranges in
>> > the future. For example, I have a 2 TiB file, and I am only interested
>> > in dropping caches for the first couple of gigabytes. Would I extend
>> > your interface, or would I come up with another one?
>>
>> Ah, didn't quite understand what was meant with file ranges. Again, we
>> had not considered this so far. I guess you could make a distinction
>> between directories and files here. If the path points to a file, you
>> can have an optional argument indicating the range of bytes you would
>> like to drop. Something like
>>
>> echo "my-file 0-1000,8000-1000" > /proc/sys/vm/sdrop_cache
>>
>> If this is desirable, we can add it to the patch.
>
> With a binary interface like an ioctl I can see how you could have extra
> unused fields which you can ignore now and let people start adding extra
> options like the range in the future.
>
> With this kind of interface I am not sure how to do this.
>
> Other questions I'd ask would be - how about the access control model?
> Will only root be able to drop caches? Why can't I drop caches for my
> own file?
>
> I did not put much thinking into this, but it looks like ioctl could be
> a better interface for the task you are trying to solve...
>
> Sorry if I am a bit vague, I am mostly trying to make you guys give this
> more thoughts, and come up with a deeper analysis. Interfaces are very
> important to get right, or as right as possible...
>
> --
> Best Regards,
> Artem Bityutskiy
>



-- 
Regards,
Maksym Planeta.
--
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/