ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
tachoknight has quit [Ping timeout: 264 seconds]
tlwoerner_ has joined #armlinux
tlwoerner has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 264 seconds]
naoki has quit [Read error: Connection reset by peer]
naoki has joined #armlinux
Pali has quit [Ping timeout: 250 seconds]
agherzan has quit [Ping timeout: 248 seconds]
a3f has quit [Ping timeout: 268 seconds]
scosu[m] has quit [Ping timeout: 268 seconds]
agherzan has joined #armlinux
a3f has joined #armlinux
scosu[m] has joined #armlinux
amitk has joined #armlinux
heat has quit [Ping timeout: 246 seconds]
iivanov has joined #armlinux
Stalevar has joined #armlinux
plappermaul has joined #armlinux
iivanov has quit [Quit: Leaving...]
apritzel has joined #armlinux
hanetzer has quit [Quit: WeeChat 3.6]
apritzel has quit [Ping timeout: 265 seconds]
cbeznea has joined #armlinux
guillaume_g has joined #armlinux
luispm has joined #armlinux
monstr has joined #armlinux
alexels has joined #armlinux
biju has joined #armlinux
iivanov has joined #armlinux
audgirka has joined #armlinux
jn has quit [Ping timeout: 255 seconds]
jn has joined #armlinux
jn has joined #armlinux
headless has joined #armlinux
viorel_suman has joined #armlinux
apritzel_ has joined #armlinux
luispm has quit [Ping timeout: 265 seconds]
sszy has joined #armlinux
Pali has joined #armlinux
luispm has joined #armlinux
luispm has quit [Ping timeout: 250 seconds]
mripard has quit [Quit: Bridge terminating on SIGTERM]
matthiasbgg[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
a3f has quit [Quit: Bridge terminating on SIGTERM]
psydroid has quit [Quit: Bridge terminating on SIGTERM]
scosu[m] has quit [Quit: Bridge terminating on SIGTERM]
agherzan has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
amstan has quit [Quit: Bridge terminating on SIGTERM]
psydroid has joined #armlinux
biju has quit [Quit: Client closed]
shoragan[m] has joined #armlinux
a3f has joined #armlinux
amstan has joined #armlinux
matthiasbgg[m] has joined #armlinux
agherzan has joined #armlinux
mvaittin has joined #armlinux
scosu[m] has joined #armlinux
mripard has joined #armlinux
luispm has joined #armlinux
headless has quit [Quit: Konversation terminated!]
zkrx has quit []
viorel_suman has quit [Quit: WeeChat 3.5]
zkrx has joined #armlinux
viorel_suman has joined #armlinux
jn has quit [Ping timeout: 248 seconds]
jn has joined #armlinux
jn has joined #armlinux
jn has quit [Changing host]
tachoknight has joined #armlinux
jn has quit [Ping timeout: 250 seconds]
hanetzer has joined #armlinux
chipxxx has joined #armlinux
Amit_T has joined #armlinux
torez has joined #armlinux
alpernebbi has quit [Read error: Connection reset by peer]
alpernebbi has joined #armlinux
heat has joined #armlinux
audgirka has quit [Quit: Leaving]
monstr has quit [Remote host closed the connection]
macromorgan has quit [Ping timeout: 260 seconds]
macromorgan has joined #armlinux
jn has joined #armlinux
jn has joined #armlinux
apritzel__ has joined #armlinux
apritzel__ has quit [Ping timeout: 250 seconds]
alexels has quit [Quit: WeeChat 3.6]
guillaume_g has quit [Quit: Konversation terminated!]
<rfs613>
any kernel crypto API folks around here? I'm trying to understand how requests are serialized (if at all).
<rfs613>
specific example, for hash, the API is .init, .update, and .final().
<rfs613>
the docs make it clear that requests can be abandoned, but that's not what I'm looking at
mag has quit [Remote host closed the connection]
<rfs613>
i an wondering what if two separate CPUs (for example) interleave calls to .init/.update/final().
<rfs613>
is that an API violation, or are the crypto drivers supposed to handle this?
zkrx has quit []
zkrx has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
mag has joined #armlinux
mag has quit [Remote host closed the connection]
viorel_suman has quit [Quit: WeeChat 3.5]
zkrx has quit []
cbeznea has quit [Ping timeout: 244 seconds]
zkrx has joined #armlinux
zkrx has quit []
zkrx has joined #armlinux
plappermaul has quit [Quit: Client closed]
plappermaul has joined #armlinux
apritzel has joined #armlinux
Amit_T has quit [Quit: Leaving]
iivanov has quit [Quit: Leaving...]
plappermaul has quit [Quit: Client closed]
chipxxx has quit [Read error: Connection reset by peer]
amitk has quit [Ping timeout: 246 seconds]
torez has quit [Quit: torez]
mag has joined #armlinux
headless has quit [Quit: Konversation terminated!]
apritzel has quit [Ping timeout: 248 seconds]
palmer has quit [K-Lined]
heat is now known as _Heat
<ardb>
rfs613: hash operations are fundamentally sequential in nature, so regardless of what the API requires, your result will be unpredictable if multiple CPUs are calling update() concurrently
<ardb>
if you want to perform separate init/update/final sequences in parallel, you need to allocate a descriptor for each one
<ardb>
the TFM can be shared though
<ardb>
(assuming you are not using a keyed hash with different keys for different streams)
<rfs613>
ardb: this is straight sha256 operation, no keys. There is a single tfm used for the entire sequence of operations.
<ardb>
ok so there are two options:
<rfs613>
the caller is verity_verify_io() in drivers/md/dm-verity-target.c
<rfs613>
it has some helper functions, but it basically just calls init/update/final in that sequence, repeatedly.
<rfs613>
but occasionally I see another call to init() before the previous update/final are complete.
<ardb>
each CPU will have its own ahash_request, right?
<rfs613>
well, it is called from a workqueue
<rfs613>
i don't see any obvious per-cpu data structure, though I may well have missed something
<ardb>
are you using some kind of crypto accelerator?
<rfs613>
yes, out of tree (for now)
<rfs613>
when i use generic-sha256 software, it works fine
<ardb>
so each dm_verity_io instance has its own ahash_request structure
<ardb>
(as far as I can tell)
<ardb>
i'd assume those cannot be used concurrently to verify different sectors
<rfs613>
i printed out the hex address of the ctx and the ahash_request, the ctx is always the same, and ahash_request is sometimes the same, sometimes different.
<rfs613>
one other thing, when I boot with nosmp on kernel commandline, the problem no longer occurs
<ardb>
but doesn't that mean the same dm_verity_io struct is being verified concurrently on two separate CPUs?
<clever>
ardb: > `you need to allocate a descriptor for each one`, and that is pretty much what bit-torrent does, divide the file up into ~16kb chunks, and then hash each seperately!
<clever>
i have been wanting to vectorize some crypto or hash operations, but i need to first understand the algo, and find one that is vector friendly
<clever>
the simplest/dumbest route, is to just do multiple different hashes in parallel
<clever>
create 16 states, init them all, then update them all with 16 different sets of inputs, and so on
<rfs613>
ardb: I guess this comes down to how workqueues interact with the scheduler. More stuff for me to understand...
<rfs613>
clever: not sure that woudl speed things up - unless you have multiple accelerators I guess, or are doing it in software so each CPU can compute in parallel (and I'd think that already happens now, but I am just guessing..)
_Heat is now known as heat
<clever>
rfs613: the vector core i'm thinking of, can do 16 mults in 2 clock cycles, and also has boolean ops like xor/or/and, which can likely run in 1 or 2 clocks per 16
<clever>
in theory, doing 16 ops in parallel, should always be faster then doing 1 op at a time, assuming the opcodes run at similar speeds
<clever>
but compared to a modern x86 processor, it may not be much faster
<ardb>
rfs613: does your driver set the CRYPTO_ALG_ASYNC correctly?
chipxxx has joined #armlinux
<rfs613>
ardb: it has .cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY
<rfs613>
and it also passes it when allocating fallback
<ardb>
ok
<ardb>
i'd like to understand why the same dm_verity_io instance is being verified on 2 CPUs at the same time
Pali has quit [Ping timeout: 246 seconds]
<rfs613>
i'm not entirely certain about the 2 CPUs at a time... but it seems to be a factor. And from the code I've looked at so far, I cannot see any other explanation for why I see an "extra" call to .init, in the middle of an existing init/update/final cycle.
<rfs613>
i'm also a bit puzzled by a statement near the bottom of Documentation/crypto/devel-algos.rst: "No resources related to request objects should remain allocated after a call to .init() or .update(), since there might be no chance to free them"
Pali has joined #armlinux
<rfs613>
if a driver needs to persist some state across the init/update/final cycle, how should this state be stored?
<rfs613>
most drivers seem to use struct foo_ahash_ctx but with the assumption that the init/update/final always get called in that sequence.