From: Borislav Petkov <bp@alien8.de>
To: Eliav Farber <farbere@amazon.com>
Cc: mchehab@kernel.org, linux-edac@vger.kernel.org,
linux-kernel@vger.kernel.org, ronenk@amazon.com,
talel@amazon.com, hhhawa@amazon.com, jonnyc@amazon.com,
hanochu@amazon.com
Subject: Re: [PATCH 4/4] EDAC: Refactor edac_align_ptr() flow
Date: Tue, 15 Feb 2022 18:08:20 +0100 [thread overview]
Message-ID: <Ygvd6ATqmb537dEC@zn.tnic> (raw)
In-Reply-To: <20220113100622.12783-5-farbere@amazon.com>
On Thu, Jan 13, 2022 at 10:06:22AM +0000, Eliav Farber wrote:
> Modify flow to be more clear:
> - Calculate required alignment based on size.
> - Check if *p is aligned and fix if not.
> - Set return ptr to to be *p.
> - Increase *p by new size for the next call.
Right, as I said earlier, piling more on this crap design is not the
right thing to do. Looking at the call sites, what I think you should do
instead is simply compute the whole allocation size by making sure the
alignment of those substruct element pointers we're assigning to, is 8
or so, for simplicity.
You can store the offsets in those helper variables, like it is done
now.
Then do the allocation and add the offsets to the pointer kzalloc has
returned.
And then get rid of that edac_align_ptr() crap. This thing is silly
beyond repair and passing in that **p offset back'n'forth is making
stuff more complicated than it is - one can simply do that computation
before calling kzalloc and doesn't need a "helper" which ain't helping.
I'd say.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
prev parent reply other threads:[~2022-02-15 17:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 10:06 [PATCH 0/4] edac_align_ptr() bug fix and refactoring Eliav Farber
2022-01-13 10:06 ` [PATCH 1/4] EDAC: Fix calculation of returned address and next offset in edac_align_ptr() Eliav Farber
2022-01-25 14:37 ` Borislav Petkov
2022-01-27 9:58 ` Farber, Eliav
2022-02-15 12:34 ` Borislav Petkov
2022-02-15 13:06 ` Farber, Eliav
2022-01-13 10:06 ` [PATCH 2/4] EDAC: Remove unnecessary cast to char* in edac_align_ptr() function Eliav Farber
2022-01-26 18:46 ` Borislav Petkov
2022-01-13 10:06 ` [PATCH 3/4] EDAC: Refactor edac_align_ptr() to use u8/u16/u32/u64 data types Eliav Farber
2022-02-15 16:55 ` Borislav Petkov
2022-01-13 10:06 ` [PATCH 4/4] EDAC: Refactor edac_align_ptr() flow Eliav Farber
2022-02-15 17:08 ` Borislav Petkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ygvd6ATqmb537dEC@zn.tnic \
--to=bp@alien8.de \
--cc=farbere@amazon.com \
--cc=hanochu@amazon.com \
--cc=hhhawa@amazon.com \
--cc=jonnyc@amazon.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=ronenk@amazon.com \
--cc=talel@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.