linux-kernel - Re: [PATCH v4] f2fs: add sysfs nodes to get runtime compression stat

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:   Fri, 12 Mar 2021 15:45:48 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Daeho Jeong <daeho43@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net, kernel-team@...roid.com,
        Daeho Jeong <daehojeong@...gle.com>
Subject: Re: [PATCH v4] f2fs: add sysfs nodes to get runtime compression stat

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Fri, Mar 12, 2021 at 11:37:29PM +0900, Daeho Jeong wrote:
> As you can see, if we're doing like the below.
> 
> sbi->compr_written_block += blocks;
> 
> Let's assume the initial value as 0.
> 
> <thread A>                                             <thread B>
> sbi->compr_written_block = 0;
> 
> sbi->compr_written_block = 0;
> +blocks(3);
>                                                                + blocks(2);
> sbi->compr_written_block = 3;
> 
> sbi->compr_written_block = 2;
> 
> Finally, we end up with 2, not 5.
> 
> As more threads are participating it, we might miss more counting.

Are you sure?  Isn't adding a number something that should happen in a
"safe" way?

And if you miss 2 blocks, who cares?  What is so critical about these
things that you take the cache flush of 2 atomic writes just for a
debugging statistic?

Why not just take 1 lock for everything if it's so important to get
these "correct"?

What is the performance throughput degradation of adding 2 atomic writes
to each time you write a block?

But really, will you ever notice missing a few, even if that could be
possible on your cpu (and I strongly doubt most modern cpus will miss
this...)

But this isn't my code, I just hate seeing atomic variables used for
silly things like debugging stats when they do not seem to be really
needed.  So if you want to keep them, go ahead, but realize that the
number you are reading has nothing to do with being "atomic" at all.

thanks,

greg k-h