| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/27 13:44 | flow | patch-triage |
0mArgs:null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"KMSANReasoning": "",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies drivers/crypto/nx/nx-842.c, which implements compression support for the IBM PowerPC Nest (NX) cryptographic accelerator coprocessor. This driver depends on CONFIG_CRYPTO_DEV_NX (which depends on CONFIG_PPC64) and platform-specific PowerPC configs (CONFIG_PPC_PSERIES / CONFIG_PPC_POWERNV). It is exclusive to the PowerPC architecture and cannot be compiled or executed on amd64.",
"WorthFuzzing": false
} |
| 1/1 | 2026/09/27 13:44 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit b536fac89641396415a10cd9395c06ba6ea5b815\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Sun Sep 27 13:44:35 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/crypto/nx/nx-842.c b/drivers/crypto/nx/nx-842.c\nindex a61208cbcd279..b4404a1389621 100644\n--- a/drivers/crypto/nx/nx-842.c\n+++ b/drivers/crypto/nx/nx-842.c\n@@ -421,6 +421,8 @@ static int decompress(struct nx842_crypto_ctx *ctx,\n \n \tslen -= spadding;\n \n+\tif (ignore \u003e dlen)\n+\t\treturn -EINVAL;\n \tdlen -= ignore;\n \tif (ignore)\n \t\tpr_debug(\"ignoring last %x bytes\\n\", ignore);\n"
} |
| 2/1 | 2026/09/27 13:44 | agent | patch-evaluator |
0mModel:core Args: null Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies drivers/crypto/nx/nx-842.c, which implements compression support for the IBM PowerPC Nest (NX) cryptographic accelerator coprocessor. This driver depends on CONFIG_CRYPTO_DEV_NX (which depends on CONFIG_PPC64) and platform-specific PowerPC configs (CONFIG_PPC_PSERIES / CONFIG_PPC_POWERNV). It is exclusive to the PowerPC architecture and cannot be compiled or executed on amd64.",
"WorthFuzzing": false
}Instruction: You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.
IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.
================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.
- REACHABILITY IS THE PRIMARY GATE:
Fuzzing can only discover bugs in code that can actually execute in standard virtualized
environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
regardless of whether it adds assertions or complex logic.
- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
Patch authors routinely label changes as "cleanups", "refactorings", or state
"No functional change intended". Do NOT take these claims at face value.
Code refactorings that rearrange logic, introduce helper functions, or alter state management
in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
If reachable executable code is modified or refactored, it MUST be fuzzed.
- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
Even if the author believes the invariant always holds, fuzzing is essential to verify whether
an unusual sequence of operations can violate it.
================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:
- Non-kernel and non-executable changes:
* Modifications to Documentation/, comments, or spelling fixes.
* User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
that do not affect the compiled kernel image (vmlinux) or kernel modules.
* Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
that do not alter control flow or data structures.
* Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
* Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
* Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
physical PCI hot-unplug or manual sysfs driver unbinding.
* Code paths exclusive to architectures other than the target architecture.
================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
* Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
* Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
* Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
* Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).
================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:
- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
Do NOT list generic, ubiquitous functions called by almost every program in the corpus
(including, but not limited to: general memory allocators and deallocators, page fault
and trap handlers, or core synchronization primitives; this is not an exhaustive list).
Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
which severely dilutes fuzzing effort away from the actual changes.
- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
List functions that specifically implement the logic being added or altered, or direct API entrypoints
for the subsystem feature under review.
- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).
================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt: Target architecture: amd64
For your convenience, here is the diff of the changes:
commit b536fac89641396415a10cd9395c06ba6ea5b815
Author: syz-cluster <triage@syzkaller.com>
Date: Sun Sep 27 13:44:35 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/crypto/nx/nx-842.c b/drivers/crypto/nx/nx-842.c
index a61208cbcd279..b4404a1389621 100644
--- a/drivers/crypto/nx/nx-842.c
+++ b/drivers/crypto/nx/nx-842.c
@@ -421,6 +421,8 @@ static int decompress(struct nx842_crypto_ctx *ctx,
slen -= spadding;
+ if (ignore > dlen)
+ return -EINVAL;
dlen -= ignore;
if (ignore)
pr_debug("ignoring last %x bytes\n", ignore);
|
| 3/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 2858 output: 28 thoughts: 103 Thoughts: **Initial Assessment of the Code Change** Okay, let's dive in. My first instinct is always to dissect the incoming patch. I need to understand the scope, so I'm starting by looking at the specific file that's been modified: `drivers/crypto/nx/nx-842.c`. Now, before I get too deep, I need to get a high-level view. What is this file really? I need to quickly establish its role within the kernel's crypto framework. Is it tied to a specific architecture? Is it powerpc-specific, generic, or even reachable on amd64, which is crucial for my understanding. Before I get bogged down in the code itself, I'll take a step back. I need to confirm the file's configuration. I should check the associated Kconfig to understand the conditions under which this code is compiled and included. This will help frame the context. |
| 4/2 | 2026/09/27 13:44 | tool | grepper |
0mArgs:{
"Expression": "nx842",
"PathPrefix": "drivers/crypto/"
}Results: {
"Output": "\nFull output is too long, showing 500 out of 840 lines.\nUse more precise expression if possible.\n\ndrivers/crypto/nx/nx-842.c-19- * specific minimum and maximum lengths. Those restrictions, provided by the\ndrivers/crypto/nx/nx-842.c:20: * nx-842 driver via nx842_constraints, mean this driver must use bounce\ndrivers/crypto/nx/nx-842.c-21- * buffers and headers to correct misaligned in or out buffers, and to split\n--\ndrivers/crypto/nx/nx-842.c-64-#define NX842_CRYPTO_HEADER_SIZE(g)\t\t\t\t\\\ndrivers/crypto/nx/nx-842.c:65:\t(sizeof(struct nx842_crypto_header) +\t\t\t\\\ndrivers/crypto/nx/nx-842.c:66:\t sizeof(struct nx842_crypto_header_group) * (g))\ndrivers/crypto/nx/nx-842.c-67-#define NX842_CRYPTO_HEADER_MAX_SIZE\t\t\t\t\\\n--\ndrivers/crypto/nx/nx-842.c-78-\ndrivers/crypto/nx/nx-842.c:79:struct nx842_crypto_param {\ndrivers/crypto/nx/nx-842.c-80-\tu8 *in;\n--\ndrivers/crypto/nx/nx-842.c-86-\ndrivers/crypto/nx/nx-842.c:87:static int update_param(struct nx842_crypto_param *p,\ndrivers/crypto/nx/nx-842.c-88-\t\t\tunsigned int slen, unsigned int dlen)\n--\ndrivers/crypto/nx/nx-842.c-103-\ndrivers/crypto/nx/nx-842.c:104:void *nx842_crypto_alloc_ctx(struct nx842_driver *driver)\ndrivers/crypto/nx/nx-842.c-105-{\ndrivers/crypto/nx/nx-842.c:106:\tstruct nx842_crypto_ctx *ctx;\ndrivers/crypto/nx/nx-842.c-107-\n--\ndrivers/crypto/nx/nx-842.c-117-\tif (!ctx-\u003ewmem || !ctx-\u003esbounce || !ctx-\u003edbounce) {\ndrivers/crypto/nx/nx-842.c:118:\t\tnx842_crypto_free_ctx(ctx);\ndrivers/crypto/nx/nx-842.c-119-\t\treturn ERR_PTR(-ENOMEM);\n--\ndrivers/crypto/nx/nx-842.c-123-}\ndrivers/crypto/nx/nx-842.c:124:EXPORT_SYMBOL_GPL(nx842_crypto_alloc_ctx);\ndrivers/crypto/nx/nx-842.c-125-\ndrivers/crypto/nx/nx-842.c:126:void nx842_crypto_free_ctx(void *p)\ndrivers/crypto/nx/nx-842.c-127-{\ndrivers/crypto/nx/nx-842.c:128:\tstruct nx842_crypto_ctx *ctx = p;\ndrivers/crypto/nx/nx-842.c-129-\n--\ndrivers/crypto/nx/nx-842.c-134-}\ndrivers/crypto/nx/nx-842.c:135:EXPORT_SYMBOL_GPL(nx842_crypto_free_ctx);\ndrivers/crypto/nx/nx-842.c-136-\ndrivers/crypto/nx/nx-842.c:137:static void check_constraints(struct nx842_constraints *c)\ndrivers/crypto/nx/nx-842.c-138-{\n--\ndrivers/crypto/nx/nx-842.c-143-\ndrivers/crypto/nx/nx-842.c:144:static int nx842_crypto_add_header(struct nx842_crypto_header *hdr, u8 *buf)\ndrivers/crypto/nx/nx-842.c-145-{\n--\ndrivers/crypto/nx/nx-842.c-160-\ndrivers/crypto/nx/nx-842.c:161:static int compress(struct nx842_crypto_ctx *ctx,\ndrivers/crypto/nx/nx-842.c:162:\t\t struct nx842_crypto_param *p,\ndrivers/crypto/nx/nx-842.c:163:\t\t struct nx842_crypto_header_group *g,\ndrivers/crypto/nx/nx-842.c:164:\t\t struct nx842_constraints *c,\ndrivers/crypto/nx/nx-842.c-165-\t\t u16 *ignore,\n--\ndrivers/crypto/nx/nx-842.c-251-\ndrivers/crypto/nx/nx-842.c:252:int nx842_crypto_compress(struct crypto_scomp *tfm,\ndrivers/crypto/nx/nx-842.c-253-\t\t\t const u8 *src, unsigned int slen,\n--\ndrivers/crypto/nx/nx-842.c-255-{\ndrivers/crypto/nx/nx-842.c:256:\tstruct nx842_crypto_ctx *ctx = pctx;\ndrivers/crypto/nx/nx-842.c:257:\tstruct nx842_crypto_header *hdr =\ndrivers/crypto/nx/nx-842.c-258-\t\t\t\tcontainer_of(\u0026ctx-\u003eheader,\ndrivers/crypto/nx/nx-842.c:259:\t\t\t\t\t struct nx842_crypto_header, hdr);\ndrivers/crypto/nx/nx-842.c:260:\tstruct nx842_crypto_param p;\ndrivers/crypto/nx/nx-842.c:261:\tstruct nx842_constraints c = *ctx-\u003edriver-\u003econstraints;\ndrivers/crypto/nx/nx-842.c-262-\tunsigned int groups, hdrsize, h;\n--\ndrivers/crypto/nx/nx-842.c-325-\tif (add_header)\ndrivers/crypto/nx/nx-842.c:326:\t\tret = nx842_crypto_add_header(hdr, dst);\ndrivers/crypto/nx/nx-842.c-327-\tif (ret)\n--\ndrivers/crypto/nx/nx-842.c-337-}\ndrivers/crypto/nx/nx-842.c:338:EXPORT_SYMBOL_GPL(nx842_crypto_compress);\ndrivers/crypto/nx/nx-842.c-339-\ndrivers/crypto/nx/nx-842.c:340:static int decompress(struct nx842_crypto_ctx *ctx,\ndrivers/crypto/nx/nx-842.c:341:\t\t struct nx842_crypto_param *p,\ndrivers/crypto/nx/nx-842.c:342:\t\t struct nx842_crypto_header_group *g,\ndrivers/crypto/nx/nx-842.c:343:\t\t struct nx842_constraints *c,\ndrivers/crypto/nx/nx-842.c-344-\t\t u16 ignore)\n--\ndrivers/crypto/nx/nx-842.c-438-\ndrivers/crypto/nx/nx-842.c:439:int nx842_crypto_decompress(struct crypto_scomp *tfm,\ndrivers/crypto/nx/nx-842.c-440-\t\t\t const u8 *src, unsigned int slen,\n--\ndrivers/crypto/nx/nx-842.c-442-{\ndrivers/crypto/nx/nx-842.c:443:\tstruct nx842_crypto_ctx *ctx = pctx;\ndrivers/crypto/nx/nx-842.c:444:\tstruct nx842_crypto_header *hdr;\ndrivers/crypto/nx/nx-842.c:445:\tstruct nx842_crypto_param p;\ndrivers/crypto/nx/nx-842.c:446:\tstruct nx842_constraints c = *ctx-\u003edriver-\u003econstraints;\ndrivers/crypto/nx/nx-842.c-447-\tint n, ret, hdr_len;\n--\ndrivers/crypto/nx/nx-842.c-459-\ndrivers/crypto/nx/nx-842.c:460:\thdr = (struct nx842_crypto_header *)src;\ndrivers/crypto/nx/nx-842.c-461-\n--\ndrivers/crypto/nx/nx-842.c-467-\tif (be16_to_cpu(hdr-\u003emagic) != NX842_CRYPTO_MAGIC) {\ndrivers/crypto/nx/nx-842.c:468:\t\tstruct nx842_crypto_header_group g = {\ndrivers/crypto/nx/nx-842.c-469-\t\t\t.padding =\t\t0,\n--\ndrivers/crypto/nx/nx-842.c-499-\tmemcpy(\u0026ctx-\u003eheader, src, hdr_len);\ndrivers/crypto/nx/nx-842.c:500:\thdr = container_of(\u0026ctx-\u003eheader, struct nx842_crypto_header, hdr);\ndrivers/crypto/nx/nx-842.c-501-\n--\ndrivers/crypto/nx/nx-842.c-523-}\ndrivers/crypto/nx/nx-842.c:524:EXPORT_SYMBOL_GPL(nx842_crypto_decompress);\ndrivers/crypto/nx/nx-842.c-525-\n--\ndrivers/crypto/nx/nx-842.h=103=struct crypto_scomp;\ndrivers/crypto/nx/nx-842.h-104-\ndrivers/crypto/nx/nx-842.h:105:static inline unsigned long nx842_get_pa(void *addr)\ndrivers/crypto/nx/nx-842.h-106-{\n--\ndrivers/crypto/nx/nx-842.h-113-/**\ndrivers/crypto/nx/nx-842.h:114: * This provides the driver's constraints. Different nx842 implementations\ndrivers/crypto/nx/nx-842.h-115- * may have varying requirements. The constraints are:\n--\ndrivers/crypto/nx/nx-842.h-131- */\ndrivers/crypto/nx/nx-842.h:132:struct nx842_constraints {\ndrivers/crypto/nx/nx-842.h-133-\tint alignment;\n--\ndrivers/crypto/nx/nx-842.h-138-\ndrivers/crypto/nx/nx-842.h:139:struct nx842_driver {\ndrivers/crypto/nx/nx-842.h-140-\tchar *name;\n--\ndrivers/crypto/nx/nx-842.h-143-\ndrivers/crypto/nx/nx-842.h:144:\tstruct nx842_constraints *constraints;\ndrivers/crypto/nx/nx-842.h-145-\n--\ndrivers/crypto/nx/nx-842.h-153-\ndrivers/crypto/nx/nx-842.h:154:struct nx842_crypto_header_group {\ndrivers/crypto/nx/nx-842.h-155-\t__be16 padding;\t\t\t/* unused bytes at start of group */\n--\ndrivers/crypto/nx/nx-842.h-159-\ndrivers/crypto/nx/nx-842.h:160:struct nx842_crypto_header {\ndrivers/crypto/nx/nx-842.h-161-\t/* New members MUST be added within the struct_group() macro below. */\ndrivers/crypto/nx/nx-842.h:162:\t__struct_group(nx842_crypto_header_hdr, hdr, __packed,\ndrivers/crypto/nx/nx-842.h-163-\t\t__be16 magic;\t\t/* NX842_CRYPTO_MAGIC */\n--\ndrivers/crypto/nx/nx-842.h-166-\t);\ndrivers/crypto/nx/nx-842.h:167:\tstruct nx842_crypto_header_group group[] __counted_by(groups);\ndrivers/crypto/nx/nx-842.h-168-} __packed;\ndrivers/crypto/nx/nx-842.h:169:static_assert(offsetof(struct nx842_crypto_header, group) == sizeof(struct nx842_crypto_header_hdr),\ndrivers/crypto/nx/nx-842.h-170-\t \"struct member likely outside of __struct_group()\");\n--\ndrivers/crypto/nx/nx-842.h-173-\ndrivers/crypto/nx/nx-842.h:174:struct nx842_crypto_ctx {\ndrivers/crypto/nx/nx-842.h-175-\tspinlock_t lock;\n--\ndrivers/crypto/nx/nx-842.h-179-\ndrivers/crypto/nx/nx-842.h:180:\tstruct nx842_crypto_header_hdr header;\ndrivers/crypto/nx/nx-842.h:181:\tstruct nx842_crypto_header_group group[NX842_CRYPTO_GROUP_MAX];\ndrivers/crypto/nx/nx-842.h-182-\ndrivers/crypto/nx/nx-842.h:183:\tstruct nx842_driver *driver;\ndrivers/crypto/nx/nx-842.h-184-};\ndrivers/crypto/nx/nx-842.h-185-\ndrivers/crypto/nx/nx-842.h:186:void *nx842_crypto_alloc_ctx(struct nx842_driver *driver);\ndrivers/crypto/nx/nx-842.h:187:void nx842_crypto_free_ctx(void *ctx);\ndrivers/crypto/nx/nx-842.h:188:int nx842_crypto_compress(struct crypto_scomp *tfm,\ndrivers/crypto/nx/nx-842.h-189-\t\t\t const u8 *src, unsigned int slen,\ndrivers/crypto/nx/nx-842.h-190-\t\t\t u8 *dst, unsigned int *dlen, void *ctx);\ndrivers/crypto/nx/nx-842.h:191:int nx842_crypto_decompress(struct crypto_scomp *tfm,\ndrivers/crypto/nx/nx-842.h-192-\t\t\t const u8 *src, unsigned int slen,\n--\ndrivers/crypto/nx/nx-common-powernv.c=26=MODULE_ALIAS_CRYPTO(\"842-nx\");\n--\ndrivers/crypto/nx/nx-common-powernv.c-31-\ndrivers/crypto/nx/nx-common-powernv.c:32:struct nx842_workmem {\ndrivers/crypto/nx/nx-common-powernv.c-33-\t/* Below fields must be properly aligned */\n--\ndrivers/crypto/nx/nx-common-powernv.c=62=static LIST_HEAD(nx_coprocs);\ndrivers/crypto/nx/nx-common-powernv.c:63:static unsigned int nx842_ct;\t/* used in icswx function */\ndrivers/crypto/nx/nx-common-powernv.c-64-\n--\ndrivers/crypto/nx/nx-common-powernv.c-71-\ndrivers/crypto/nx/nx-common-powernv.c:72:static int (*nx842_powernv_exec)(const unsigned char *in,\ndrivers/crypto/nx/nx-common-powernv.c-73-\t\t\t\tunsigned int inlen, unsigned char *out,\n--\ndrivers/crypto/nx/nx-common-powernv.c=82=static void setup_indirect_dde(struct data_descriptor_entry *dde,\n--\ndrivers/crypto/nx/nx-common-powernv.c-89-\tdde-\u003elength = cpu_to_be32(byte_count);\ndrivers/crypto/nx/nx-common-powernv.c:90:\tdde-\u003eaddress = cpu_to_be64(nx842_get_pa(ddl));\ndrivers/crypto/nx/nx-common-powernv.c-91-}\n--\ndrivers/crypto/nx/nx-common-powernv.c=121=static int setup_ddl(struct data_descriptor_entry *dde,\n--\ndrivers/crypto/nx/nx-common-powernv.c-125-{\ndrivers/crypto/nx/nx-common-powernv.c:126:\tunsigned long pa = nx842_get_pa(buf);\ndrivers/crypto/nx/nx-common-powernv.c-127-\tint i, ret, total_len = len;\n--\ndrivers/crypto/nx/nx-common-powernv.c-159-\t\tlen -= ret;\ndrivers/crypto/nx/nx-common-powernv.c:160:\t\tpa = nx842_get_pa(buf);\ndrivers/crypto/nx/nx-common-powernv.c-161-\t}\n--\ndrivers/crypto/nx/nx-common-powernv.c-184-\ndrivers/crypto/nx/nx-common-powernv.c:185:static int wait_for_csb(struct nx842_workmem *wmem,\ndrivers/crypto/nx/nx-common-powernv.c-186-\t\t\tstruct coprocessor_status_block *csb)\n--\ndrivers/crypto/nx/nx-common-powernv.c-388-\ndrivers/crypto/nx/nx-common-powernv.c:389:static int nx842_config_crb(const unsigned char *in, unsigned int inlen,\ndrivers/crypto/nx/nx-common-powernv.c-390-\t\t\tunsigned char *out, unsigned int outlen,\ndrivers/crypto/nx/nx-common-powernv.c:391:\t\t\tstruct nx842_workmem *wmem)\ndrivers/crypto/nx/nx-common-powernv.c-392-{\n--\ndrivers/crypto/nx/nx-common-powernv.c-415-\t/* set up CRB's CSB addr */\ndrivers/crypto/nx/nx-common-powernv.c:416:\tcsb_addr = nx842_get_pa(csb) \u0026 CRB_CSB_ADDRESS;\ndrivers/crypto/nx/nx-common-powernv.c-417-\tcsb_addr |= CRB_CSB_AT; /* Addrs are phys */\n--\ndrivers/crypto/nx/nx-common-powernv.c-423-/**\ndrivers/crypto/nx/nx-common-powernv.c:424: * nx842_exec_icswx - compress/decompress data using the 842 algorithm\ndrivers/crypto/nx/nx-common-powernv.c-425- *\n--\ndrivers/crypto/nx/nx-common-powernv.c-440- * @workmem: working memory buffer pointer, size determined by\ndrivers/crypto/nx/nx-common-powernv.c:441: * nx842_powernv_driver.workmem_size\ndrivers/crypto/nx/nx-common-powernv.c-442- * @fc: function code, see CCW Function Codes in nx-842.h\n--\ndrivers/crypto/nx/nx-common-powernv.c-448- * -EMSGSIZE\tInput buffer too large\ndrivers/crypto/nx/nx-common-powernv.c:449: * -EINVAL\tbuffer constraints do not fix nx842_constraints\ndrivers/crypto/nx/nx-common-powernv.c-450- * -EPROTO\thardware error during operation\n--\ndrivers/crypto/nx/nx-common-powernv.c-453- */\ndrivers/crypto/nx/nx-common-powernv.c:454:static int nx842_exec_icswx(const unsigned char *in, unsigned int inlen,\ndrivers/crypto/nx/nx-common-powernv.c-455-\t\t\t\t unsigned char *out, unsigned int *outlenp,\n--\ndrivers/crypto/nx/nx-common-powernv.c-459-\tstruct coprocessor_status_block *csb;\ndrivers/crypto/nx/nx-common-powernv.c:460:\tstruct nx842_workmem *wmem;\ndrivers/crypto/nx/nx-common-powernv.c-461-\tint ret;\n--\ndrivers/crypto/nx/nx-common-powernv.c-469-\t/* shoudn't happen, we don't load without a coproc */\ndrivers/crypto/nx/nx-common-powernv.c:470:\tif (!nx842_ct) {\ndrivers/crypto/nx/nx-common-powernv.c-471-\t\tpr_err_ratelimited(\"coprocessor CT is 0\");\n--\ndrivers/crypto/nx/nx-common-powernv.c-474-\ndrivers/crypto/nx/nx-common-powernv.c:475:\tret = nx842_config_crb(in, inlen, out, outlen, wmem);\ndrivers/crypto/nx/nx-common-powernv.c-476-\tif (ret)\n--\ndrivers/crypto/nx/nx-common-powernv.c-483-\tccw = 0;\ndrivers/crypto/nx/nx-common-powernv.c:484:\tccw = SET_FIELD(CCW_CT, ccw, nx842_ct);\ndrivers/crypto/nx/nx-common-powernv.c-485-\tccw = SET_FIELD(CCW_CI_842, ccw, 0); /* use 0 for hw auto-selection */\n--\ndrivers/crypto/nx/nx-common-powernv.c-525-/**\ndrivers/crypto/nx/nx-common-powernv.c:526: * nx842_exec_vas - compress/decompress data using the 842 algorithm\ndrivers/crypto/nx/nx-common-powernv.c-527- *\n--\ndrivers/crypto/nx/nx-common-powernv.c-542- * @workmem: working memory buffer pointer, size determined by\ndrivers/crypto/nx/nx-common-powernv.c:543: * nx842_powernv_driver.workmem_size\ndrivers/crypto/nx/nx-common-powernv.c-544- * @fc: function code, see CCW Function Codes in nx-842.h\n--\ndrivers/crypto/nx/nx-common-powernv.c-551- * -EMSGSIZE\tInput buffer too large\ndrivers/crypto/nx/nx-common-powernv.c:552: * -EINVAL\tbuffer constraints do not fix nx842_constraints\ndrivers/crypto/nx/nx-common-powernv.c-553- * -EPROTO\thardware error during operation\n--\ndrivers/crypto/nx/nx-common-powernv.c-556- */\ndrivers/crypto/nx/nx-common-powernv.c:557:static int nx842_exec_vas(const unsigned char *in, unsigned int inlen,\ndrivers/crypto/nx/nx-common-powernv.c-558-\t\t\t\t unsigned char *out, unsigned int *outlenp,\n--\ndrivers/crypto/nx/nx-common-powernv.c-562-\tstruct coprocessor_status_block *csb;\ndrivers/crypto/nx/nx-common-powernv.c:563:\tstruct nx842_workmem *wmem;\ndrivers/crypto/nx/nx-common-powernv.c-564-\tstruct vas_window *txwin;\n--\ndrivers/crypto/nx/nx-common-powernv.c-575-\ndrivers/crypto/nx/nx-common-powernv.c:576:\tret = nx842_config_crb(in, inlen, out, outlen, wmem);\ndrivers/crypto/nx/nx-common-powernv.c-577-\tif (ret)\n--\ndrivers/crypto/nx/nx-common-powernv.c-618-/**\ndrivers/crypto/nx/nx-common-powernv.c:619: * nx842_powernv_compress - Compress data using the 842 algorithm\ndrivers/crypto/nx/nx-common-powernv.c-620- *\n--\ndrivers/crypto/nx/nx-common-powernv.c-633- * @wmem: working memory buffer pointer, size determined by\ndrivers/crypto/nx/nx-common-powernv.c:634: * nx842_powernv_driver.workmem_size\ndrivers/crypto/nx/nx-common-powernv.c-635- *\ndrivers/crypto/nx/nx-common-powernv.c:636: * Returns: see @nx842_powernv_exec()\ndrivers/crypto/nx/nx-common-powernv.c-637- */\ndrivers/crypto/nx/nx-common-powernv.c:638:static int nx842_powernv_compress(const unsigned char *in, unsigned int inlen,\ndrivers/crypto/nx/nx-common-powernv.c-639-\t\t\t\t unsigned char *out, unsigned int *outlenp,\n--\ndrivers/crypto/nx/nx-common-powernv.c-641-{\ndrivers/crypto/nx/nx-common-powernv.c:642:\treturn nx842_powernv_exec(in, inlen, out, outlenp,\ndrivers/crypto/nx/nx-common-powernv.c-643-\t\t\t\t wmem, CCW_FC_842_COMP_CRC);\n--\ndrivers/crypto/nx/nx-common-powernv.c-646-/**\ndrivers/crypto/nx/nx-common-powernv.c:647: * nx842_powernv_decompress - Decompress data using the 842 algorithm\ndrivers/crypto/nx/nx-common-powernv.c-648- *\n--\ndrivers/crypto/nx/nx-common-powernv.c-661- * @wmem: working memory buffer pointer, size determined by\ndrivers/crypto/nx/nx-common-powernv.c:662: * nx842_powernv_driver.workmem_size\ndrivers/crypto/nx/nx-common-powernv.c-663- *\ndrivers/crypto/nx/nx-common-powernv.c:664: * Returns: see @nx842_powernv_exec()\ndrivers/crypto/nx/nx-common-powernv.c-665- */\ndrivers/crypto/nx/nx-common-powernv.c:666:static int nx842_powernv_decompress(const unsigned char *in, unsigned int inlen,\ndrivers/crypto/nx/nx-common-powernv.c-667-\t\t\t\t unsigned char *out, unsigned int *outlenp,\n--\ndrivers/crypto/nx/nx-common-powernv.c-669-{\ndrivers/crypto/nx/nx-common-powernv.c:670:\treturn nx842_powernv_exec(in, inlen, out, outlenp,\ndrivers/crypto/nx/nx-common-powernv.c-671-\t\t\t\t wmem, CCW_FC_842_DECOMP_CRC);\n--\ndrivers/crypto/nx/nx-common-powernv.c=907=static int __init nx_powernv_probe_vas(struct device_node *pn)\n--\ndrivers/crypto/nx/nx-common-powernv.c-948-\ndrivers/crypto/nx/nx-common-powernv.c:949:static int __init nx842_powernv_probe(struct device_node *dn)\ndrivers/crypto/nx/nx-common-powernv.c-950-{\n--\ndrivers/crypto/nx/nx-common-powernv.c-980-\ndrivers/crypto/nx/nx-common-powernv.c:981:\tif (!nx842_ct)\ndrivers/crypto/nx/nx-common-powernv.c:982:\t\tnx842_ct = ct;\ndrivers/crypto/nx/nx-common-powernv.c:983:\telse if (nx842_ct != ct)\ndrivers/crypto/nx/nx-common-powernv.c-984-\t\tpr_err(\"NX842 chip %d, CT %d != first found CT %d\\n\",\ndrivers/crypto/nx/nx-common-powernv.c:985:\t\t chip_id, ct, nx842_ct);\ndrivers/crypto/nx/nx-common-powernv.c-986-\n--\ndrivers/crypto/nx/nx-common-powernv.c=990=static void nx_delete_coprocs(void)\n--\ndrivers/crypto/nx/nx-common-powernv.c-1015-\ndrivers/crypto/nx/nx-common-powernv.c:1016:static struct nx842_constraints nx842_powernv_constraints = {\ndrivers/crypto/nx/nx-common-powernv.c-1017-\t.alignment =\tDDE_BUFFER_ALIGN,\n--\ndrivers/crypto/nx/nx-common-powernv.c-1022-\ndrivers/crypto/nx/nx-common-powernv.c:1023:static struct nx842_driver nx842_powernv_driver = {\ndrivers/crypto/nx/nx-common-powernv.c-1024-\t.name =\t\tKBUILD_MODNAME,\ndrivers/crypto/nx/nx-common-powernv.c-1025-\t.owner =\tTHIS_MODULE,\ndrivers/crypto/nx/nx-common-powernv.c:1026:\t.workmem_size =\tsizeof(struct nx842_workmem),\ndrivers/crypto/nx/nx-common-powernv.c:1027:\t.constraints =\t\u0026nx842_powernv_constraints,\ndrivers/crypto/nx/nx-common-powernv.c:1028:\t.compress =\tnx842_powernv_compress,\ndrivers/crypto/nx/nx-common-powernv.c:1029:\t.decompress =\tnx842_powernv_decompress,\ndrivers/crypto/nx/nx-common-powernv.c-1030-};\ndrivers/crypto/nx/nx-common-powernv.c-1031-\ndrivers/crypto/nx/nx-common-powernv.c:1032:static void *nx842_powernv_crypto_alloc_ctx(void)\ndrivers/crypto/nx/nx-common-powernv.c-1033-{\ndrivers/crypto/nx/nx-common-powernv.c:1034:\treturn nx842_crypto_alloc_ctx(\u0026nx842_powernv_driver);\ndrivers/crypto/nx/nx-common-powernv.c-1035-}\ndrivers/crypto/nx/nx-common-powernv.c-1036-\ndrivers/crypto/nx/nx-common-powernv.c:1037:static struct scomp_alg nx842_powernv_alg = {\ndrivers/crypto/nx/nx-common-powernv.c-1038-\t.base.cra_name\t\t= \"842\",\n--\ndrivers/crypto/nx/nx-common-powernv.c-1043-\t.streams\t\t= {\ndrivers/crypto/nx/nx-common-powernv.c:1044:\t\t.alloc_ctx\t= nx842_powernv_crypto_alloc_ctx,\ndrivers/crypto/nx/nx-common-powernv.c:1045:\t\t.free_ctx\t= nx842_crypto_free_ctx,\ndrivers/crypto/nx/nx-common-powernv.c-1046-\t},\ndrivers/crypto/nx/nx-common-powernv.c:1047:\t.compress\t\t= nx842_crypto_compress,\ndrivers/crypto/nx/nx-common-powernv.c:1048:\t.decompress\t\t= nx842_crypto_decompress,\ndrivers/crypto/nx/nx-common-powernv.c-1049-};\n--\ndrivers/crypto/nx/nx-common-powernv.c=1051=static __init int nx_compress_powernv_init(void)\n--\ndrivers/crypto/nx/nx-common-powernv.c-1075-\t\tfor_each_compatible_node(dn, NULL, \"ibm,power-nx\")\ndrivers/crypto/nx/nx-common-powernv.c:1076:\t\t\tnx842_powernv_probe(dn);\ndrivers/crypto/nx/nx-common-powernv.c-1077-\ndrivers/crypto/nx/nx-common-powernv.c:1078:\t\tif (!nx842_ct)\ndrivers/crypto/nx/nx-common-powernv.c-1079-\t\t\treturn -ENODEV;\ndrivers/crypto/nx/nx-common-powernv.c-1080-\ndrivers/crypto/nx/nx-common-powernv.c:1081:\t\tnx842_powernv_exec = nx842_exec_icswx;\ndrivers/crypto/nx/nx-common-powernv.c-1082-\t} else {\n--\ndrivers/crypto/nx/nx-common-powernv.c-1104-\ndrivers/crypto/nx/nx-common-powernv.c:1105:\t\tnx842_powernv_exec = nx842_exec_vas;\ndrivers/crypto/nx/nx-common-powernv.c-1106-\t}\ndrivers/crypto/nx/nx-common-powernv.c-1107-\ndrivers/crypto/nx/nx-common-powernv.c:1108:\tret = crypto_register_scomp(\u0026nx842_powernv_alg);\ndrivers/crypto/nx/nx-common-powernv.c-1109-\tif (ret) {\n--\ndrivers/crypto/nx/nx-common-powernv.c=1118=static void __exit nx_compress_powernv_exit(void)\n--\ndrivers/crypto/nx/nx-common-powernv.c-1120-\t/*\ndrivers/crypto/nx/nx-common-powernv.c:1121:\t * GZIP engine is supported only in power9 or later and nx842_ct\ndrivers/crypto/nx/nx-common-powernv.c-1122-\t * is used on power8 (icswx).\n--\ndrivers/crypto/nx/nx-common-powernv.c-1125-\t */\ndrivers/crypto/nx/nx-common-powernv.c:1126:\tif (!nx842_ct)\ndrivers/crypto/nx/nx-common-powernv.c-1127-\t\tvas_unregister_api_powernv();\ndrivers/crypto/nx/nx-common-powernv.c-1128-\ndrivers/crypto/nx/nx-common-powernv.c:1129:\tcrypto_unregister_scomp(\u0026nx842_powernv_alg);\ndrivers/crypto/nx/nx-common-powernv.c-1130-\n--\ndrivers/crypto/nx/nx-common-pseries.c=46=static struct nx_cop_caps nx_cop_caps;\ndrivers/crypto/nx/nx-common-pseries.c-47-\ndrivers/crypto/nx/nx-common-pseries.c:48:static struct nx842_constraints nx842_pseries_constraints = {\ndrivers/crypto/nx/nx-common-pseries.c-49-\t.alignment =\tDDE_BUFFER_ALIGN,\n--\ndrivers/crypto/nx/nx-common-pseries.c=55=static int check_constraints(unsigned long buf, unsigned int *len, bool in)\ndrivers/crypto/nx/nx-common-pseries.c-56-{\ndrivers/crypto/nx/nx-common-pseries.c:57:\tif (!IS_ALIGNED(buf, nx842_pseries_constraints.alignment)) {\ndrivers/crypto/nx/nx-common-pseries.c-58-\t\tpr_debug(\"%s buffer 0x%lx not aligned to 0x%x\\n\",\ndrivers/crypto/nx/nx-common-pseries.c-59-\t\t\t in ? \"input\" : \"output\", buf,\ndrivers/crypto/nx/nx-common-pseries.c:60:\t\t\t nx842_pseries_constraints.alignment);\ndrivers/crypto/nx/nx-common-pseries.c-61-\t\treturn -EINVAL;\ndrivers/crypto/nx/nx-common-pseries.c-62-\t}\ndrivers/crypto/nx/nx-common-pseries.c:63:\tif (*len % nx842_pseries_constraints.multiple) {\ndrivers/crypto/nx/nx-common-pseries.c-64-\t\tpr_debug(\"%s buffer len 0x%x not multiple of 0x%x\\n\",\ndrivers/crypto/nx/nx-common-pseries.c-65-\t\t\t in ? \"input\" : \"output\", *len,\ndrivers/crypto/nx/nx-common-pseries.c:66:\t\t\t nx842_pseries_constraints.multiple);\ndrivers/crypto/nx/nx-common-pseries.c-67-\t\tif (in)\ndrivers/crypto/nx/nx-common-pseries.c-68-\t\t\treturn -EINVAL;\ndrivers/crypto/nx/nx-common-pseries.c:69:\t\t*len = round_down(*len, nx842_pseries_constraints.multiple);\ndrivers/crypto/nx/nx-common-pseries.c-70-\t}\ndrivers/crypto/nx/nx-common-pseries.c:71:\tif (*len \u003c nx842_pseries_constraints.minimum) {\ndrivers/crypto/nx/nx-common-pseries.c-72-\t\tpr_debug(\"%s buffer len 0x%x under minimum 0x%x\\n\",\ndrivers/crypto/nx/nx-common-pseries.c-73-\t\t\t in ? \"input\" : \"output\", *len,\ndrivers/crypto/nx/nx-common-pseries.c:74:\t\t\t nx842_pseries_constraints.minimum);\ndrivers/crypto/nx/nx-common-pseries.c-75-\t\treturn -EINVAL;\ndrivers/crypto/nx/nx-common-pseries.c-76-\t}\ndrivers/crypto/nx/nx-common-pseries.c:77:\tif (*len \u003e nx842_pseries_constraints.maximum) {\ndrivers/crypto/nx/nx-common-pseries.c-78-\t\tpr_debug(\"%s buffer len 0x%x over maximum 0x%x\\n\",\ndrivers/crypto/nx/nx-common-pseries.c-79-\t\t\t in ? \"input\" : \"output\", *len,\ndrivers/crypto/nx/nx-common-pseries.c:80:\t\t\t nx842_pseries_constraints.maximum);\ndrivers/crypto/nx/nx-common-pseries.c-81-\t\tif (in)\ndrivers/crypto/nx/nx-common-pseries.c-82-\t\t\treturn -EINVAL;\ndrivers/crypto/nx/nx-common-pseries.c:83:\t\t*len = nx842_pseries_constraints.maximum;\ndrivers/crypto/nx/nx-common-pseries.c-84-\t}\n--\ndrivers/crypto/nx/nx-common-pseries.c-90-\ndrivers/crypto/nx/nx-common-pseries.c:91:struct nx842_workmem {\ndrivers/crypto/nx/nx-common-pseries.c-92-\t/* scatterlist */\n--\ndrivers/crypto/nx/nx-common-pseries.c-116-\ndrivers/crypto/nx/nx-common-pseries.c:117:struct ibm_nx842_counters {\ndrivers/crypto/nx/nx-common-pseries.c-118-\tatomic64_t comp_complete;\n--\ndrivers/crypto/nx/nx-common-pseries.c-126-\ndrivers/crypto/nx/nx-common-pseries.c:127:struct nx842_devdata {\ndrivers/crypto/nx/nx-common-pseries.c-128-\tstruct vio_dev *vdev;\ndrivers/crypto/nx/nx-common-pseries.c-129-\tstruct device *dev;\ndrivers/crypto/nx/nx-common-pseries.c:130:\tstruct ibm_nx842_counters *counters;\ndrivers/crypto/nx/nx-common-pseries.c-131-\tunsigned int max_sg_len;\n--\ndrivers/crypto/nx/nx-common-pseries.c-135-\ndrivers/crypto/nx/nx-common-pseries.c:136:static struct nx842_devdata __rcu *devdata;\ndrivers/crypto/nx/nx-common-pseries.c-137-static DEFINE_SPINLOCK(devdata_spinlock);\n--\ndrivers/crypto/nx/nx-common-pseries.c-139-#define NX842_COUNTER_INC(_x) \\\ndrivers/crypto/nx/nx-common-pseries.c:140:static inline void nx842_inc_##_x( \\\ndrivers/crypto/nx/nx-common-pseries.c:141:\tconst struct nx842_devdata *dev) { \\\ndrivers/crypto/nx/nx-common-pseries.c-142-\tif (dev) \\\n--\ndrivers/crypto/nx/nx-common-pseries.c=149=NX842_COUNTER_INC(swdecomp);\n--\ndrivers/crypto/nx/nx-common-pseries.c-152-\ndrivers/crypto/nx/nx-common-pseries.c:153:static void ibm_nx842_incr_hist(atomic64_t *times, unsigned int time)\ndrivers/crypto/nx/nx-common-pseries.c-154-{\n--\ndrivers/crypto/nx/nx-common-pseries.c-172-\ndrivers/crypto/nx/nx-common-pseries.c:173:static unsigned long nx842_get_desired_dma(struct vio_dev *viodev)\ndrivers/crypto/nx/nx-common-pseries.c-174-{\n--\ndrivers/crypto/nx/nx-common-pseries.c-178-\ndrivers/crypto/nx/nx-common-pseries.c:179:struct nx842_slentry {\ndrivers/crypto/nx/nx-common-pseries.c-180-\t__be64 ptr; /* Real address (use __pa()) */\n--\ndrivers/crypto/nx/nx-common-pseries.c-184-/* pHyp scatterlist entry */\ndrivers/crypto/nx/nx-common-pseries.c:185:struct nx842_scatterlist {\ndrivers/crypto/nx/nx-common-pseries.c-186-\tint entry_nr; /* number of slentries */\ndrivers/crypto/nx/nx-common-pseries.c:187:\tstruct nx842_slentry *entries; /* ptr to array of slentries */\ndrivers/crypto/nx/nx-common-pseries.c-188-};\n--\ndrivers/crypto/nx/nx-common-pseries.c-190-/* Does not include sizeof(entry_nr) in the size */\ndrivers/crypto/nx/nx-common-pseries.c:191:static inline unsigned long nx842_get_scatterlist_size(\ndrivers/crypto/nx/nx-common-pseries.c:192:\t\t\t\tstruct nx842_scatterlist *sl)\ndrivers/crypto/nx/nx-common-pseries.c-193-{\ndrivers/crypto/nx/nx-common-pseries.c:194:\treturn sl-\u003eentry_nr * sizeof(struct nx842_slentry);\ndrivers/crypto/nx/nx-common-pseries.c-195-}\ndrivers/crypto/nx/nx-common-pseries.c-196-\ndrivers/crypto/nx/nx-common-pseries.c:197:static int nx842_build_scatterlist(unsigned long buf, int len,\ndrivers/crypto/nx/nx-common-pseries.c:198:\t\t\tstruct nx842_scatterlist *sl)\ndrivers/crypto/nx/nx-common-pseries.c-199-{\ndrivers/crypto/nx/nx-common-pseries.c-200-\tunsigned long entrylen;\ndrivers/crypto/nx/nx-common-pseries.c:201:\tstruct nx842_slentry *entry;\ndrivers/crypto/nx/nx-common-pseries.c-202-\n--\ndrivers/crypto/nx/nx-common-pseries.c-206-\twhile (len) {\ndrivers/crypto/nx/nx-common-pseries.c:207:\t\tentry-\u003eptr = cpu_to_be64(nx842_get_pa((void *)buf));\ndrivers/crypto/nx/nx-common-pseries.c-208-\t\tentrylen = min_t(int, len,\n--\ndrivers/crypto/nx/nx-common-pseries.c-221-\ndrivers/crypto/nx/nx-common-pseries.c:222:static int nx842_validate_result(struct device *dev,\ndrivers/crypto/nx/nx-common-pseries.c-223-\tstruct cop_status_block *csb)\n--\ndrivers/crypto/nx/nx-common-pseries.c-280-/**\ndrivers/crypto/nx/nx-common-pseries.c:281: * nx842_pseries_compress - Compress data using the 842 algorithm\ndrivers/crypto/nx/nx-common-pseries.c-282- *\n--\ndrivers/crypto/nx/nx-common-pseries.c-295- * @wmem: ptr to buffer for working memory, size determined by\ndrivers/crypto/nx/nx-common-pseries.c:296: * nx842_pseries_driver.workmem_size\ndrivers/crypto/nx/nx-common-pseries.c-297- *\n--\ndrivers/crypto/nx/nx-common-pseries.c-304- */\ndrivers/crypto/nx/nx-common-pseries.c:305:static int nx842_pseries_compress(const unsigned char *in, unsigned int inlen,\ndrivers/crypto/nx/nx-common-pseries.c-306-\t\t\t\t unsigned char *out, unsigned int *outlen,\n--\ndrivers/crypto/nx/nx-common-pseries.c-308-{\ndrivers/crypto/nx/nx-common-pseries.c:309:\tstruct nx842_devdata *local_devdata;\ndrivers/crypto/nx/nx-common-pseries.c-310-\tstruct device *dev = NULL;\ndrivers/crypto/nx/nx-common-pseries.c:311:\tstruct nx842_workmem *workmem;\ndrivers/crypto/nx/nx-common-pseries.c:312:\tstruct nx842_scatterlist slin, slout;\ndrivers/crypto/nx/nx-common-pseries.c-313-\tstruct nx_csbcpb *csbcpb;\n--\ndrivers/crypto/nx/nx-common-pseries.c-340-\tworkmem = PTR_ALIGN(wmem, WORKMEM_ALIGN);\ndrivers/crypto/nx/nx-common-pseries.c:341:\tslin.entries = (struct nx842_slentry *)workmem-\u003eslin;\ndrivers/crypto/nx/nx-common-pseries.c:342:\tslout.entries = (struct nx842_slentry *)workmem-\u003eslout;\ndrivers/crypto/nx/nx-common-pseries.c-343-\n--\ndrivers/crypto/nx/nx-common-pseries.c-347-\tmemset(csbcpb, 0, sizeof(*csbcpb));\ndrivers/crypto/nx/nx-common-pseries.c:348:\top.csbcpb = nx842_get_pa(csbcpb);\ndrivers/crypto/nx/nx-common-pseries.c-349-\n--\n\n"
} |
| 5/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 15648 output: 33 thoughts: 16 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: **Diving into the `drivers/crypto/nx/` Directory** Alright, time to get my hands dirty, let's open up that `drivers/crypto/nx/` directory and see what's what. My initial focus is always the core build configuration – I want to understand how this driver is integrated into the larger kernel build process. So, first up, I'm heading straight for the `Kconfig` and `Makefile`. These two files are the keys to understanding how the NX crypto driver is conditionally compiled and how its source files are linked. I expect to find the standard `Kconfig` structure, defining the various options, dependencies, and help text that allow users to configure the NX crypto driver. The `Makefile` will, of course, hold the crucial instructions for building the driver module itself, including its dependencies, source files, object file generation, and potential linker flags. Knowing this foundation first will help me figure out how the rest of the files in the directory relate to each other, how they are built, and how they contribute to the overall functionality of the NX crypto device. |
| 6/2 | 2026/09/27 13:44 | tool | read-file |
0mArgs:{
"File": "drivers/crypto/nx/Makefile",
"FirstLine": 1,
"LineCount": 20
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0\n 2:\tobj-$(CONFIG_CRYPTO_DEV_NX_ENCRYPT) += nx-crypto.o\n 3:\tnx-crypto-objs := nx.o \\\n 4:\t\t\t nx-aes-cbc.o \\\n 5:\t\t\t nx-aes-ecb.o \\\n 6:\t\t\t nx-aes-gcm.o \\\n 7:\t\t\t nx-aes-ccm.o \\\n 8:\t\t\t nx-aes-ctr.o \\\n 9:\t\t\t nx-aes-xcbc.o \\\n 10:\t\t\t nx-sha256.o \\\n 11:\t\t\t nx-sha512.o\n 12:\t\n 13:\tnx-crypto-$(CONFIG_DEBUG_FS) += nx_debugfs.o\n 14:\tobj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o nx-compress.o\n 15:\tobj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o nx-compress.o\n 16:\tnx-compress-objs := nx-842.o\n 17:\tnx-compress-pseries-objs := nx-common-pseries.o\n 18:\tnx-compress-powernv-objs := nx-common-powernv.o\n"
} |
| 7/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 16307 output: 29 thoughts: 119 Thoughts: Here's my thinking process: **Diving into the Build Configuration** Okay, first things first, I'm seeing some interesting lines in this makefile snippet. It looks like it's configuring the object files for the NX crypto device compression. Specifically, I see that the `nx-compress-pseries` and `nx-compress-powernv` modules are being linked with `nx-compress.o`. And, I notice that `nx-compress-objs := nx-842.o`, meaning that the module `nx-842.o` is going to be used with the other object files mentioned. Now, where do the actual configuration options for these `CONFIG_CRYPTO_DEV_NX_*` settings live? My instincts say that the Kconfig file for crypto drivers is the place to look! I'm going to start by checking `drivers/crypto/nx/Kconfig` – that seems the most likely place since these are clearly NX specific – and if that doesn't hold the answer, I'll fall back to the more generic `drivers/crypto/Kconfig`. I need to figure out how these are enabled and what options are available. |
| 8/2 | 2026/09/27 13:44 | tool | grepper |
0mArgs:{
"Expression": "CRYPTO_DEV_NX",
"PathPrefix": "drivers/crypto"
}Results: {
"Output": "drivers/crypto/Kconfig=388=config CRYPTO_DEV_EXYNOS_HASH\n--\ndrivers/crypto/Kconfig-398-\ndrivers/crypto/Kconfig:399:config CRYPTO_DEV_NX\ndrivers/crypto/Kconfig-400-\tbool \"Support for IBM PowerPC Nest (NX) cryptographic acceleration\"\n--\ndrivers/crypto/Kconfig-407-\ndrivers/crypto/Kconfig:408:if CRYPTO_DEV_NX\ndrivers/crypto/Kconfig-409-\tsource \"drivers/crypto/nx/Kconfig\"\n--\ndrivers/crypto/Makefile=19=obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o\ndrivers/crypto/Makefile:20:obj-$(CONFIG_CRYPTO_DEV_NX) += nx/\ndrivers/crypto/Makefile-21-obj-$(CONFIG_CRYPTO_DEV_OMAP) += omap-crypto.o\n--\ndrivers/crypto/nx/Kconfig-2-\ndrivers/crypto/nx/Kconfig:3:config CRYPTO_DEV_NX_ENCRYPT\ndrivers/crypto/nx/Kconfig-4-\ttristate \"Encryption acceleration support on pSeries platform\"\n--\ndrivers/crypto/nx/Kconfig-14-\ndrivers/crypto/nx/Kconfig:15:config CRYPTO_DEV_NX_COMPRESS\ndrivers/crypto/nx/Kconfig-16-\ttristate \"Compression acceleration support\"\n--\ndrivers/crypto/nx/Kconfig-26-\ndrivers/crypto/nx/Kconfig:27:if CRYPTO_DEV_NX_COMPRESS\ndrivers/crypto/nx/Kconfig-28-\ndrivers/crypto/nx/Kconfig:29:config CRYPTO_DEV_NX_COMPRESS_PSERIES\ndrivers/crypto/nx/Kconfig-30-\ttristate \"Compression acceleration support on pSeries platform\"\n--\ndrivers/crypto/nx/Kconfig-39-\ndrivers/crypto/nx/Kconfig:40:config CRYPTO_DEV_NX_COMPRESS_POWERNV\ndrivers/crypto/nx/Kconfig-41-\ttristate \"Compression acceleration support on PowerNV platform\"\n--\ndrivers/crypto/nx/Makefile-1-# SPDX-License-Identifier: GPL-2.0\ndrivers/crypto/nx/Makefile:2:obj-$(CONFIG_CRYPTO_DEV_NX_ENCRYPT) += nx-crypto.o\ndrivers/crypto/nx/Makefile-3-nx-crypto-objs := nx.o \\\n--\ndrivers/crypto/nx/Makefile=13=nx-crypto-$(CONFIG_DEBUG_FS) += nx_debugfs.o\ndrivers/crypto/nx/Makefile:14:obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES) += nx-compress-pseries.o nx-compress.o\ndrivers/crypto/nx/Makefile:15:obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o nx-compress.o\ndrivers/crypto/nx/Makefile-16-nx-compress-objs := nx-842.o\n"
} |
| 9/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 17467 output: 34 thoughts: 33 Thoughts: Here's my take on the thought process: **Diving into Crypto Driver Configuration** Okay, so I need to understand the configuration options for these crypto drivers. Specifically, I need to know which architectures and dependencies are involved. The best place to start is undoubtedly the Kconfig files, right? They're the definitive source for this sort of information. I should check `drivers/crypto/Kconfig` and then also `drivers/crypto/nx/Kconfig`, near the relevant lines, to cover the mainline and perhaps any architecture-specific additions that might exist. That's the most direct route to seeing which configurations apply to which architectures, and what those dependancies actually are. Let's dig in and see what those files reveal. |
| 10/2 | 2026/09/27 13:44 | tool | read-file |
0mArgs:{
"File": "drivers/crypto/Kconfig",
"FirstLine": 395,
"LineCount": 20
}Results: {
"Contents": " 395:\t\t Select this to offload Exynos from HASH MD5/SHA1/SHA256.\n 396:\t\t This will select software SHA1, MD5 and SHA256 as they are\n 397:\t\t needed for small and zero-size messages.\n 398:\t\n 399:\tconfig CRYPTO_DEV_NX\n 400:\t\tbool \"Support for IBM PowerPC Nest (NX) cryptographic acceleration\"\n 401:\t\tdepends on PPC64\n 402:\t\thelp\n 403:\t\t This enables support for the NX hardware cryptographic accelerator\n 404:\t\t coprocessor that is in IBM PowerPC P7+ or later processors. This\n 405:\t\t does not actually enable any drivers, it only allows you to select\n 406:\t\t which acceleration type (encryption and/or compression) to enable.\n 407:\t\n 408:\tif CRYPTO_DEV_NX\n 409:\t\tsource \"drivers/crypto/nx/Kconfig\"\n 410:\tendif\n 411:\t\n 412:\tconfig CRYPTO_DEV_ATMEL_AUTHENC\n 413:\t\tbool \"Support for Atmel IPSEC/SSL hw accelerator\"\n 414:\t\tdepends on ARCH_AT91 || COMPILE_TEST\n"
} |
| 11/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 18030 output: 34 thoughts: 87 Thoughts: **Investigating `nx-842.c`'s Dependencies and Usage** Okay, let's see, I'm looking at line 401 in `drivers/crypto/Kconfig`, specifically the `CRYPTO_DEV_NX` configuration option. It's for IBM PowerPC Nest (NX) cryptographic acceleration, and it depends on `PPC64`. That makes sense, but... wait a minute, I need to make sure this isn't used elsewhere. The immediate question is: does anything else build, or even simply *use* `nx-842.c`? Gotta be thorough. Time to cross-reference everything. Let's start by checking `drivers/crypto/nx/Kconfig` to see if there's any immediate context or dependencies defined there. |
| 12/2 | 2026/09/27 13:44 | tool | read-file |
0mArgs:{
"File": "drivers/crypto/nx/Kconfig",
"FirstLine": 1,
"LineCount": 55
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t\n 3:\tconfig CRYPTO_DEV_NX_ENCRYPT\n 4:\t\ttristate \"Encryption acceleration support on pSeries platform\"\n 5:\t\tdepends on PPC_PSERIES \u0026\u0026 IBMVIO \u0026\u0026 !CPU_LITTLE_ENDIAN\n 6:\t\tdefault y\n 7:\t\tselect CRYPTO_AES\n 8:\t\tselect CRYPTO_CCM\n 9:\t\thelp\n 10:\t\t Support for PowerPC Nest (NX) encryption acceleration. This\n 11:\t\t module supports acceleration for AES and SHA2 algorithms on\n 12:\t\t the pSeries platform. If you choose 'M' here, this module\n 13:\t\t will be called nx_crypto.\n 14:\t\n 15:\tconfig CRYPTO_DEV_NX_COMPRESS\n 16:\t\ttristate \"Compression acceleration support\"\n 17:\t\tdefault y\n 18:\t\tselect CRYPTO_ALGAPI\n 19:\t\tselect 842_DECOMPRESS\n 20:\t\thelp\n 21:\t\t Support for PowerPC Nest (NX) compression acceleration. This\n 22:\t\t module supports acceleration for compressing memory with the 842\n 23:\t\t algorithm using the cryptographic API. One of the platform\n 24:\t\t drivers must be selected also. If you choose 'M' here, this\n 25:\t\t module will be called nx_compress.\n 26:\t\n 27:\tif CRYPTO_DEV_NX_COMPRESS\n 28:\t\n 29:\tconfig CRYPTO_DEV_NX_COMPRESS_PSERIES\n 30:\t\ttristate \"Compression acceleration support on pSeries platform\"\n 31:\t\tdepends on PPC_PSERIES \u0026\u0026 IBMVIO\n 32:\t\tdepends on PPC_VAS\n 33:\t\tdefault y\n 34:\t\thelp\n 35:\t\t Support for PowerPC Nest (NX) compression acceleration. This\n 36:\t\t module supports acceleration for compressing memory with the 842\n 37:\t\t algorithm. This supports NX hardware on the pSeries platform.\n 38:\t\t If you choose 'M' here, this module will be called nx_compress_pseries.\n 39:\t\n 40:\tconfig CRYPTO_DEV_NX_COMPRESS_POWERNV\n 41:\t\ttristate \"Compression acceleration support on PowerNV platform\"\n 42:\t\tdepends on PPC_POWERNV\n 43:\t\tdepends on PPC_VAS\n 44:\t\tdefault y\n 45:\t\thelp\n 46:\t\t Support for PowerPC Nest (NX) compression acceleration. This\n 47:\t\t module supports acceleration for compressing memory with the 842\n 48:\t\t algorithm. This supports NX hardware on the PowerNV platform.\n 49:\t\t If you choose 'M' here, this module will be called nx_compress_powernv.\n 50:\t\n 51:\tendif\n"
} |
| 13/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 19073 output: 19 thoughts: 22 Thoughts: Here's my thought process, as if I were thinking it: **Kernel Dependency Check: `nx-842.c`** Okay, time to make sure this `nx-842.c` file isn't casually being used all over the kernel. It's a key source file for this new implementation, and I need to verify that its dependencies are understood and managed. Let's start with a thorough check. I'll need to use my usual tools to perform a comprehensive search. I'll be looking for any include statements, function calls, or data structure references to ensure that it's correctly integrated and not causing any unforeseen conflicts or unwanted dependencies. My goal is to confirm that any existing uses are intentional, documented, and aligned with our design goals. If I find any surprises, I'll need to investigate further and decide how to resolve them. |
| 14/2 | 2026/09/27 13:44 | tool | grepper |
0mArgs:{
"Expression": "nx-842"
}Results: {
"Output": "MAINTAINERS=12457=F:\tdrivers/crypto/nx/Makefile\nMAINTAINERS:12458:F:\tdrivers/crypto/nx/nx-842*\nMAINTAINERS-12459-F:\tinclude/linux/sw842.h\n--\ncrypto/842.c-17- * want to use the 842 hardware compression interface, which is at:\ncrypto/842.c:18: * drivers/crypto/nx/nx-842-crypto.c\ncrypto/842.c-19- */\n--\ndrivers/crypto/nx/Makefile=15=obj-$(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV) += nx-compress-powernv.o nx-compress.o\ndrivers/crypto/nx/Makefile:16:nx-compress-objs := nx-842.o\ndrivers/crypto/nx/Makefile-17-nx-compress-pseries-objs := nx-common-pseries.o\n--\ndrivers/crypto/nx/nx-842.c-19- * specific minimum and maximum lengths. Those restrictions, provided by the\ndrivers/crypto/nx/nx-842.c:20: * nx-842 driver via nx842_constraints, mean this driver must use bounce\ndrivers/crypto/nx/nx-842.c-21- * buffers and headers to correct misaligned in or out buffers, and to split\n--\ndrivers/crypto/nx/nx-842.c-54-\ndrivers/crypto/nx/nx-842.c:55:#include \"nx-842.h\"\ndrivers/crypto/nx/nx-842.c-56-\n--\ndrivers/crypto/nx/nx-common-powernv.c-9-\ndrivers/crypto/nx/nx-common-powernv.c:10:#include \"nx-842.h\"\ndrivers/crypto/nx/nx-common-powernv.c-11-\n--\ndrivers/crypto/nx/nx-common-powernv.c=389=static int nx842_config_crb(const unsigned char *in, unsigned int inlen,\n--\ndrivers/crypto/nx/nx-common-powernv.c-441- * nx842_powernv_driver.workmem_size\ndrivers/crypto/nx/nx-common-powernv.c:442: * @fc: function code, see CCW Function Codes in nx-842.h\ndrivers/crypto/nx/nx-common-powernv.c-443- *\n--\ndrivers/crypto/nx/nx-common-powernv.c=454=static int nx842_exec_icswx(const unsigned char *in, unsigned int inlen,\n--\ndrivers/crypto/nx/nx-common-powernv.c-543- * nx842_powernv_driver.workmem_size\ndrivers/crypto/nx/nx-common-powernv.c:544: * @fc: function code, see CCW Function Codes in nx-842.h\ndrivers/crypto/nx/nx-common-powernv.c-545- *\n--\ndrivers/crypto/nx/nx-common-powernv.c=682=static struct vas_window *nx_alloc_txwin(struct nx_coproc *coproc)\n--\ndrivers/crypto/nx/nx-common-powernv.c-698-\tif (IS_ERR(txwin))\ndrivers/crypto/nx/nx-common-powernv.c:699:\t\tpr_err(\"ibm,nx-842: Can not open TX window: %ld\\n\",\ndrivers/crypto/nx/nx-common-powernv.c-700-\t\t\t\tPTR_ERR(txwin));\n--\ndrivers/crypto/nx/nx-common-powernv.c=907=static int __init nx_powernv_probe_vas(struct device_node *pn)\n--\ndrivers/crypto/nx/nx-common-powernv.c-925-\t\tret = find_nx_device_tree(dn, chip_id, vasid, NX_CT_842,\ndrivers/crypto/nx/nx-common-powernv.c:926:\t\t\t\t\t\"ibm,p9-nx-842\", \u0026ct_842);\ndrivers/crypto/nx/nx-common-powernv.c-927-\n--\ndrivers/crypto/nx/nx-common-pseries.c-15-\ndrivers/crypto/nx/nx-common-pseries.c:16:#include \"nx-842.h\"\ndrivers/crypto/nx/nx-common-pseries.c-17-#include \"nx_csbcpb.h\" /* struct nx_csbcpb */\n"
} |
| 15/2 | 2026/09/27 13:44 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 20477 output: 27 thoughts: 1108 Thoughts: **Analyzing Potential False Positives for Fuzzing Exclusion** Okay, let's dive into this. The architecture target is amd64, and we need to determine if certain code paths should be excluded from fuzzing based on the criteria outlined. Specifically, we're focusing on cases where `WorthFuzzing` should be `false`. The key negative criteria here are unreachable execution paths, and structually unreachable hardware. Unreachable execution paths are where modified code falls into categories like driver teardown callbacks or code exclusive to architectures other than the target. Structurally unreachable hardware involves vendor-specific hardware not emulated in standard QEMU. The question that jumped out at me immediately is whether `CRYPTO_DEV_NX` or `CRYPTO_DEV_NX_COMPRESS` could ever realistically be built on amd64. Let's see. I checked `drivers/crypto/Kconfig`, and sure enough, `CRYPTO_DEV_NX` *explicitly* depends on `PPC64`. Crucially, there's no `|| COMPILE_TEST` condition there to allow cross-compilation. So, it should be pretty much impossible. Now, let's verify if anything might include `nx-842.c`. I then looked at `drivers/crypto/Makefile` and `drivers/crypto/nx/Makefile`. `nx-842.o` is involved under `CRYPTO_DEV_NX_COMPRESS`, which itself is dependent on `CRYPTO_DEV_NX`. This dependency chain confirms the link. Digging deeper into `drivers/crypto/nx/Kconfig` shows that `CRYPTO_DEV_NX_COMPRESS_PSERIES` depends on `PPC_PSERIES && IBMVIO && PPC_VAS`, while `CRYPTO_DEV_NX_COMPRESS_POWERNV` depends on `PPC_POWERNV && PPC_VAS`. These are all PPC-specific configurations. So, in summary: `CRYPTO_DEV_NX` is dependent on `PPC64`, and *cannot* be enabled on amd64 (x86_64). Even if a `COMPILE_TEST` option existed (which it doesn't), the nested dependencies on `PPC_PSERIES`, `PPC_POWERNV`, and `PPC_VAS` are all PPC-specific. These are not architectures that could be compiled into the amd64 binary. Finally, I will double-check to be absolutely sure there is no software implementation in `crypto/842.c` or `lib/842/`. I will check those locations to verify. Therefore, paths involving these configurations should be safe to exclude from the fuzzing target. |
| 16/2 | 2026/09/27 13:45 | tool | grepper |
0mError:no matches Args: {
"Expression": "nx842_",
"PathPrefix": "crypto/"
}Results: {
"error": "no matches"
} |
| 17/2 | 2026/09/27 13:45 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 22211 output: 27 thoughts: 17 Thoughts: Okay, here's my attempt at summarizing that thought process, keeping in mind the expert user and using the first person perspective: **Initial Diagnostic Steps** Alright, my first instinct when encountering this issue is to dive right into the codebase. I'm thinking, "Where would the relevant logic likely reside?" My immediate check points are the `lib/842/` directory and, if that doesn't immediately yield results, the broader `lib/` directory. It's a quick, top-down approach - start with the more specific location, and expand if needed. This initial search should tell me a lot. |
| 18/2 | 2026/09/27 13:45 | tool | grepper |
0mError:no matches Args: {
"Expression": "nx842_",
"PathPrefix": "lib/"
}Results: {
"error": "no matches"
} |
| 19/2 | 2026/09/27 13:45 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 22400 output: 33 thoughts: 13 Thoughts: Here's how I'd approach summarizing that thought process, keeping in mind I'm speaking to a fellow expert: **Investigating a Cryptographic Concern: Starting Point** Alright, so the initial thought process kicks off with a specific file path: `crypto/842.c`. Immediately, my mental gears start turning. "Why this file? What's the context?" The designation "crypto" implies we're dealing with cryptographic implementations or potentially vulnerabilities within such code. The filename "842.c" is a bit less descriptive, but it might indicate a specific function or module within a larger system, or perhaps a bug ID or version number being looked at. This is my starting point, where I'll be looking for clues. |
| 20/2 | 2026/09/27 13:45 | tool | read-file |
0mArgs:{
"File": "crypto/842.c",
"FirstLine": 1,
"LineCount": 50
}Results: {
"Contents": " 1:\t// SPDX-License-Identifier: GPL-2.0-or-later\n 2:\t/*\n 3:\t * Cryptographic API for the 842 software compression algorithm.\n 4:\t *\n 5:\t * Copyright (C) IBM Corporation, 2011-2015\n 6:\t *\n 7:\t * Original Authors: Robert Jennings \u003crcj@linux.vnet.ibm.com\u003e\n 8:\t * Seth Jennings \u003csjenning@linux.vnet.ibm.com\u003e\n 9:\t *\n 10:\t * Rewrite: Dan Streetman \u003cddstreet@ieee.org\u003e\n 11:\t *\n 12:\t * This is the software implementation of compression and decompression using\n 13:\t * the 842 format. This uses the software 842 library at lib/842/ which is\n 14:\t * only a reference implementation, and is very, very slow as compared to other\n 15:\t * software compressors. You probably do not want to use this software\n 16:\t * compression. If you have access to the PowerPC 842 compression hardware, you\n 17:\t * want to use the 842 hardware compression interface, which is at:\n 18:\t * drivers/crypto/nx/nx-842-crypto.c\n 19:\t */\n 20:\t\n 21:\t#include \u003ccrypto/internal/scompress.h\u003e\n 22:\t#include \u003clinux/init.h\u003e\n 23:\t#include \u003clinux/module.h\u003e\n 24:\t#include \u003clinux/sw842.h\u003e\n 25:\t\n 26:\tstatic void *crypto842_alloc_ctx(void)\n 27:\t{\n 28:\t\tvoid *ctx;\n 29:\t\n 30:\t\tctx = kmalloc(SW842_MEM_COMPRESS, GFP_KERNEL);\n 31:\t\tif (!ctx)\n 32:\t\t\treturn ERR_PTR(-ENOMEM);\n 33:\t\n 34:\t\treturn ctx;\n 35:\t}\n 36:\t\n 37:\tstatic void crypto842_free_ctx(void *ctx)\n 38:\t{\n 39:\t\tkfree(ctx);\n 40:\t}\n 41:\t\n 42:\tstatic int crypto842_scompress(struct crypto_scomp *tfm,\n 43:\t\t\t\t const u8 *src, unsigned int slen,\n 44:\t\t\t\t u8 *dst, unsigned int *dlen, void *ctx)\n 45:\t{\n 46:\t\treturn sw842_compress(src, slen, dst, dlen, ctx);\n 47:\t}\n 48:\t\n 49:\tstatic int crypto842_sdecompress(struct crypto_scomp *tfm,\n 50:\t\t\t\t\t const u8 *src, unsigned int slen,\n"
} |
| 21/2 | 2026/09/27 13:45 | llm | patch-evaluator |
0mModel:gemini-3.8-flash Args: null Results: null Tokens: input: 23354 output: 135 thoughts: 806 Thoughts: **Analysis of PowerPC-Specific Compression Code for Fuzzing Eligibility** Okay, so here's the deal. I've been looking at this `crypto/842.c` file and its use of the `sw842_compress` and `sw842_decompress` functions from `lib/842/`. The comment in the code points me to `drivers/crypto/nx/nx-842.c`, the actual hardware interface for the PowerPC 842 compression. Digging into that, I see that this `nx-842.c` file is only compiled into `nx-compress.o` under very specific conditions, namely through `CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES` and `CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV`. These configurations in turn rely on PowerPC platforms (`PPC_PSERIES`, `PPC_POWERNV`, `PPC_VAS`), which are all guarded by `CONFIG_CRYPTO_DEV_NX`, and that's gated by `PPC64`. Essentially, this entire code path is tied to the PowerPC architecture and relies on IBM's PowerPC Nest (NX) hardware coprocessor. That means it needs specific hardware or hypervisor support not emulated in typical virtualized environments. I'm focusing on the amd64 architecture, so I know immediately this is a non-starter. Now, let's compare this to the fuzzing rules. Section 2 talks about situations where we should set `WorthFuzzing=false`. One of the cases is "Structurally unreachable hardware." This specifically mentions vendor-specific drivers requiring physical hardware not emulated in standard environments. This absolutely fits the bill. The driver is inherently tied to PowerPC and a specific hardware accelerator, the NX coprocessor, not emulated in standard environments. The other category that might apply is "Unreachable execution paths," but that's a moot point here, given the structural unreachability. So, I'm confident in my assessment. The modified code in `drivers/crypto/nx/nx-842.c` is PowerPC-specific. It's unreachable on amd64. Therefore, `WorthFuzzing` is `false`. There are no configurations to enable, and no specific symbols to focus on. My reasoning is concise, explaining the architecture dependency and hardware requirement. I've double-checked that this aligns with all the established requirements. |
| 22/2 | 2026/09/27 13:45 | tool | set-results |
0mArgs:{
"EnableConfigs": [],
"FocusSymbols": [],
"Reasoning": "The patch modifies drivers/crypto/nx/nx-842.c, which implements compression support for the IBM PowerPC Nest (NX) cryptographic accelerator coprocessor. This driver depends on CONFIG_CRYPTO_DEV_NX (which depends on CONFIG_PPC64) and platform-specific PowerPC configs (CONFIG_PPC_PSERIES / CONFIG_PPC_POWERNV). It is exclusive to the PowerPC architecture and cannot be compiled or executed on amd64.",
"WorthFuzzing": false
}Results: {
"EnableConfigs": null,
"FocusSymbols": [],
"Reasoning": "The patch modifies drivers/crypto/nx/nx-842.c, which implements compression support for the IBM PowerPC Nest (NX) cryptographic accelerator coprocessor. This driver depends on CONFIG_CRYPTO_DEV_NX (which depends on CONFIG_PPC64) and platform-specific PowerPC configs (CONFIG_PPC_PSERIES / CONFIG_PPC_POWERNV). It is exclusive to the PowerPC architecture and cannot be compiled or executed on amd64.",
"WorthFuzzing": false
} |
| 23/1 | 2026/09/27 13:45 | action | If |
0mArgs:{
"WorthFuzzing": false
}Results: null |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|