Notification
Risk classification
HIPER (High Impact and/or Pervasive)
Risk categories
Data Loss
Abstract
A problem has been found in IBM Storage Scale versions 5.1.0.0 through 5.1.9.8 and 5.2.0.0 through 5.2.2.1 on Linux, where direct I/O read operations into an application buffer that exists in SysV shared memory completes successfully, but later some of the Linux memory pages backing the application I/O buffer unexpectedly contain all zeros. This has the potential to cause a silent data corruption and is triggered by the swapping function within Linux.
Description
When executing a direct I/O read operation through IBM Storage Scale on Linux, data is transferred directly from the storage system to the user space buffer that is provided to IBM Storage Scale, which prevents the data from being copied to/from the IBM Storage Scale buffers (pagepool). IBM Storage Scale assumes that any Linux memory pages mapped to the user space buffers, and holding the data directly read from storage, would be appropriately marked by Linux to indicate the pages held valid user data.
However, it was discovered that, if the user space buffer provided in a direct I/O read operation was located in memory allocated via the Linux SysV shared memory API (shmget, shmat), the backing Linux memory pages would not be appropriately marked. Because the Linux memory pages were not properly marked as containing user data, the Linux swapping feature could mark the pages as free or reallocate them to another process. In this state, an attempt to read the shared memory to which the Linux memory pages had been assigned would cause the page to be filled with zeros because that is the usual behavior for shared memory in Linux when no data is thought to be contained in the shared memory. The zeroed memory always occurs on a Linux memory page size boundary, and the length of the corruption is a multiple of the Linux memory page size.
Users Affected:
The following conditions must exist for this problem to occur:
- The application is running on Linux.
- The application allocates memory by using the Linux SysV shared memory API.
- The application issues direct I/O read operations to IBM Storage Scale by using a buffer that resides in the memory allocated through the Linux SysV shared memory API.
- A swapping activity occurs in the system due to a low memory condition, or as consequence of Linux configuration settings that impact when swapping is initiated.
IBM Storage Scale 5.1.0.0 through 5.1.9.8 and 5.2.0.0 through 5.2.2.1 are affected.
Recommended Action
For customers that use a 5.1.x version, upgrade to 5.1.9.9 or later:
For customers that use a 5.2.x version, upgrade to 5.2.3.0 or later:
If an upgrade is not possible, contact IBM Storage Scale support and request an interim fix for APAR IJ53693.
The problem can be mitigated by one of the following options until the fix can be applied.
-
After allocating the SysV shared memory, invoke the shmctl() function with the SHM_LOCK option to cause all the shared memory to be pinned.
-
Use the POSIX shared memory interface, shm_open() and mmap() rather than the SysV shared memory interfaces.
Reference ID
Note: For internal reference D.343943
Date first published
25 March 2025
Was this topic helpful?
Document Information
Modified date:
19 May 2025
UID
ibm17228749