linux-kernel - Re: [PATCH] zram: don't copy invalid compression algorithms

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150908081610.GA8633@bbox>
Date:	Tue, 8 Sep 2015 17:16:10 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	Luis Henriques <luis.henriques@...onical.com>,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH] zram: don't copy invalid compression algorithms

On Tue, Sep 08, 2015 at 02:04:42PM +0900, Sergey Senozhatsky wrote:
> On (09/08/15 13:50), Minchan Kim wrote:
> [..]
> > And it's straightforward/consistent to change the thing's state
> > only if is successful.
> > 
> 
> what for? I provided several good reasons not to do this, because

Several good reasons?

I just heard you claim to take care of scripts which don't check
function's success at the moment function is called but check it
later via reading the knob later.
If we changes it, it breaks such scripts.
So, with your claim, there are two assumption.

1. script doesn't check return val at the moment function completes
2. Instead, script checks it later via reading the knob again.
So, conclusion is we should keep wrong input in kernel side for them.

It seems you insist on "we should keep wrong input from the userspace
in the kernel to show it if user *might* ask for his debug later"
What makes you think like above?

I think such assumption is really from your brain, not real usecases.
Ok, I admit i'm not a god but if there is such thing in real practice,
we should help them to *correct* it rather than keeping such weired
thing. From the beginning, they should check his action's result with
return value, not dmesg, not reading the knob later, again.

> it makes life easier for users. we added this check in Jun 25, 2015

No, it could make more bad scripts which not checks the result
of the action but rely on current awkward zram's interface.
Consider other knobs in the kernel. A few things popped from my mind
at the moment.

/sys/block/sdb/queue/scheduler
/sys/kernel/mm/transparent_hugepage/enabled
/sys/kernel/debug/tracing/current_tracer
/sys/devices/system/clocksource/clocksource/clocksource0/current_clocksource

They are not showing wrong input user have passed although it was failed.
Could you say a example of kernel interface did intentionally like you said?

> while this functionality and scripts have been around for years, and
> apparently now it's users' problem and they must go and do something.

I believe anyone shouldn't rely on it. But who knows?
However, I want to make it sane(ie, only change compressor name
if the action is successful).
Please, let's discuss how we do it rather than whether it's useful
or not.

> 
> 
> seriously, what improvement this change brings in the first place?
> what does it make better and for whom?

As I mentioned, it makes zram's ABI consistent with others
in kernel space so it makes user feel zram is straight-forward
and sane like others.

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