Hi JFS maintainers,

I'm investigating a KMSAN warning reported by syzbot:
https://syzkaller.appspot.com/bug?extid=d3a57c32b9112d7b01ec

The KMSAN trace shows uninitialized memory being read in txLock():

BUG: KMSAN: uninit-value in txLock+0x13a2/0x2900 fs/jfs/jfs_txnmgr.c:659

Uninit was created at:
  vmalloc_noprof+0xce/0x140 mm/vmalloc.c:4146
  txInit+0xb5c/0xfa0 fs/jfs/jfs_txnmgr.c:297

The issue is that txInit() allocates the global TxLock array using
vmalloc(), which doesn't zero the memory. When txLock() later accesses
TxLock[].next fields, it reads uninitialized memory.

I have a simple fix - changing vmalloc() to vzalloc() in txInit():

diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c
index c16578af3a77..4c72103a0b46 100644
--- a/fs/jfs/jfs_txnmgr.c
+++ b/fs/jfs/jfs_txnmgr.c
@@ -294,7 +294,7 @@ int txInit(void)
  * tlock id = 0 is reserved.
  */
  size = sizeof(struct tlock) * nTxLock;
- TxLock = vmalloc(size);
+ TxLock = vzalloc(size);
  if (TxLock == NULL) {
  vfree(TxBlock);
  return -ENOMEM;

This fixes the KMSAN warning. However, when testing with the reproducer,
this change exposes a different issue:

[  307.772029][ T6674] BUG at fs/jfs/jfs_txnmgr.c:662 assert(last)

It seems that with zeroed memory, the assert at line 662 now fails
because the code is trying to traverse a transaction lock list starting
from atlhead=0, and TxLock[0].next is now 0 (instead of garbage).

I believe my vzalloc() patch is correct - it fixes undefined behavior.
The assert failure appears to be a separate pre-existing logic bug that
was previously hidden by garbage memory values.

Questions:
1. Is my analysis correct?
2. Should I submit just the vzalloc() patch?
3. Should the assert be replaced with proper error handling?
4. Is there a case where atlhead=0 is valid and the code should handle it?

I'm a kernel newbie and would appreciate guidance on the right approach.

Thanks,
Deepanshu Kartikey