diff options
Diffstat (limited to 'module')
| -rw-r--r-- | module/zfs/qat.h | 63 | ||||
| -rw-r--r-- | module/zfs/qat_compress.c | 10 | ||||
| -rw-r--r-- | module/zfs/qat_crypt.c | 6 | ||||
| -rw-r--r-- | module/zfs/zio_crypt.c | 16 |
4 files changed, 48 insertions, 47 deletions
diff --git a/module/zfs/qat.h b/module/zfs/qat.h index 4866dfe15..dc8825de2 100644 --- a/module/zfs/qat.h +++ b/module/zfs/qat.h @@ -46,96 +46,97 @@ typedef enum qat_encrypt_dir { #define QAT_TIMEOUT_MS 500 /* - * The minimal and maximal buffer size, which are not restricted + * The minimal and maximal buffer size which are not restricted * in the QAT hardware, but with the input buffer size between 4KB - * and 128KB, the hardware can provide the optimal performance. + * and 128KB the hardware can provide the optimal performance. */ #define QAT_MIN_BUF_SIZE (4*1024) #define QAT_MAX_BUF_SIZE (128*1024) /* - * Used for qat kstat. + * Used for QAT kstat. */ typedef struct qat_stats { /* - * Number of jobs submitted to qat compression engine. + * Number of jobs submitted to QAT compression engine. */ kstat_named_t comp_requests; /* - * Total bytes sent to qat compression engine. + * Total bytes sent to QAT compression engine. */ kstat_named_t comp_total_in_bytes; /* - * Total bytes output from qat compression engine. + * Total bytes output from QAT compression engine. */ kstat_named_t comp_total_out_bytes; /* - * Number of jobs submitted to qat de-compression engine. + * Number of jobs submitted to QAT de-compression engine. */ kstat_named_t decomp_requests; /* - * Total bytes sent to qat de-compression engine. + * Total bytes sent to QAT de-compression engine. */ kstat_named_t decomp_total_in_bytes; /* - * Total bytes output from qat de-compression engine. + * Total bytes output from QAT de-compression engine. */ kstat_named_t decomp_total_out_bytes; /* - * Number of fails in the qat compression / decompression engine. - * Note: when qat fail happens, it doesn't mean a critical hardware - * issue. Sometimes it is because the output buffer is not big enough. - * The compression job will be transfered to gzip software - * implementation, so the functionality of ZFS is not impacted. + * Number of fails in the QAT compression / decompression engine. + * Note: when a QAT error happens, it doesn't necessarily indicate a + * critical hardware issue. Sometimes it is because the output buffer + * is not big enough. The compression job will be transfered to the + * gzip software implementation so the functionality of ZFS is not + * impacted. */ kstat_named_t dc_fails; /* - * Number of jobs submitted to qat encryption engine. + * Number of jobs submitted to QAT encryption engine. */ kstat_named_t encrypt_requests; /* - * Total bytes sent to qat encryption engine. + * Total bytes sent to QAT encryption engine. */ kstat_named_t encrypt_total_in_bytes; /* - * Total bytes output from qat encryption engine. + * Total bytes output from QAT encryption engine. */ kstat_named_t encrypt_total_out_bytes; /* - * Number of jobs submitted to qat decryption engine. + * Number of jobs submitted to QAT decryption engine. */ kstat_named_t decrypt_requests; /* - * Total bytes sent to qat decryption engine. + * Total bytes sent to QAT decryption engine. */ kstat_named_t decrypt_total_in_bytes; /* - * Total bytes output from qat decryption engine. + * Total bytes output from QAT decryption engine. */ kstat_named_t decrypt_total_out_bytes; /* - * Number of fails in the qat encryption / decryption engine. - * Note: when qat fail happens, it doesn't mean a critical hardware - * issue. Sometimes it is because the output buffer is not big enough. - * The encryption job will be transfered to the software implementation, - * so the functionality of ZFS is not impacted. + * Number of fails in the QAT encryption / decryption engine. + * Note: when a QAT error happens, it doesn't necessarily indicate a + * critical hardware issue. The encryption job will be transfered + * to the software implementation so the functionality of ZFS is + * not impacted. */ kstat_named_t crypt_fails; /* - * Number of jobs submitted to qat checksum engine. + * Number of jobs submitted to QAT checksum engine. */ kstat_named_t cksum_requests; /* - * Total bytes sent to qat checksum engine. + * Total bytes sent to QAT checksum engine. */ kstat_named_t cksum_total_in_bytes; /* - * Number of fails in the qat checksum engine. - * Note: when qat fail happens, it doesn't mean a critical hardware - * issue. The checksum job will be transfered to the software - * implementation, so the functionality of ZFS is not impacted. + * Number of fails in the QAT checksum engine. + * Note: when a QAT error happens, it doesn't necessarily indicate a + * critical hardware issue. The checksum job will be transfered to the + * software implementation so the functionality of ZFS is not impacted. */ kstat_named_t cksum_fails; } qat_stats_t; diff --git a/module/zfs/qat_compress.c b/module/zfs/qat_compress.c index 2f7dad4b4..fff0751fb 100644 --- a/module/zfs/qat_compress.c +++ b/module/zfs/qat_compress.c @@ -28,10 +28,10 @@ #include "qat.h" /* - * Max instances in QAT device, each instance is a channel to submit - * jobs to QAT hardware, this is only for pre-allocating instance, - * and session arrays, the actual number of instances are defined in - * the QAT driver's configure file. + * Max instances in a QAT device, each instance is a channel to submit + * jobs to QAT hardware, this is only for pre-allocating instance and + * session arrays; the actual number of instances are defined in the + * QAT driver's configuration file. */ #define QAT_DC_MAX_INSTANCES 48 @@ -386,7 +386,7 @@ qat_compress(qat_compress_dir_t dir, char *src, int src_len, /* move to the last page */ flat_buf_dst += (compressed_sz + hdr_sz) >> PAGE_SHIFT; - /* no space for gzip foot in the last page */ + /* no space for gzip footer in the last page */ if (((compressed_sz + hdr_sz) % PAGE_SIZE) + ZLIB_FOOT_SZ > PAGE_SIZE) goto fail; diff --git a/module/zfs/qat_crypt.c b/module/zfs/qat_crypt.c index b9931e404..e77644161 100644 --- a/module/zfs/qat_crypt.c +++ b/module/zfs/qat_crypt.c @@ -38,9 +38,9 @@ #include "qat.h" /* - * Max instances in QAT device, each instance is a channel to submit - * jobs to QAT hardware, this is only for pre-allocating instance, - * and session arrays, the actual number of instances are defined in + * Max instances in a QAT device, each instance is a channel to submit + * jobs to QAT hardware, this is only for pre-allocating instances + * and session arrays; the actual number of instances are defined in * the QAT driver's configure file. */ #define QAT_CRYPT_MAX_INSTANCES 48 diff --git a/module/zfs/zio_crypt.c b/module/zfs/zio_crypt.c index 741d64ad5..d9e88404f 100644 --- a/module/zfs/zio_crypt.c +++ b/module/zfs/zio_crypt.c @@ -81,7 +81,7 @@ * A secret binary key, generated from an HKDF function used to encrypt and * decrypt data. * - * Message Authenication Code (MAC) + * Message Authentication Code (MAC) * The MAC is an output of authenticated encryption modes such as AES-GCM and * AES-CCM. Its purpose is to ensure that an attacker cannot modify encrypted * data on disk and return garbage to the application. Effectively, it is a @@ -121,7 +121,7 @@ * OBJECT SET AUTHENTICATION: * Up to this point, everything we have encrypted and authenticated has been * at level 0 (or -2 for the ZIL). If we did not do any further work the - * on-disk format would be susceptible to attacks that deleted or rearrannged + * on-disk format would be susceptible to attacks that deleted or rearranged * the order of level 0 blocks. Ideally, the cleanest solution would be to * maintain a tree of authentication MACs going up the bp tree. However, this * presents a problem for raw sends. Send files do not send information about @@ -131,11 +131,11 @@ * for the indirect levels of the bp tree, we use a regular SHA512 of the MACs * from the level below. We also include some portable fields from blk_prop such * as the lsize and compression algorithm to prevent the data from being - * misinterpretted. + * misinterpreted. * - * At the objset level, we maintain 2 seperate 256 bit MACs in the + * At the objset level, we maintain 2 separate 256 bit MACs in the * objset_phys_t. The first one is "portable" and is the logical root of the - * MAC tree maintianed in the metadnode's bps. The second, is "local" and is + * MAC tree maintained in the metadnode's bps. The second, is "local" and is * used as the root MAC for the user accounting objects, which are also not * transferred via "zfs send". The portable MAC is sent in the DRR_BEGIN payload * of the send file. The useraccounting code ensures that the useraccounting @@ -148,13 +148,13 @@ * need to use the same IV and encryption key, so that they will have the same * ciphertext. Normally, one should never reuse an IV with the same encryption * key or else AES-GCM and AES-CCM can both actually leak the plaintext of both - * blocks. In this case, however, since we are using the same plaindata as + * blocks. In this case, however, since we are using the same plaintext as * well all that we end up with is a duplicate of the original ciphertext we * already had. As a result, an attacker with read access to the raw disk will * be able to tell which blocks are the same but this information is given away * by dedup anyway. In order to get the same IVs and encryption keys for - * equivalent blocks of data we use an HMAC of the plaindata. We use an HMAC - * here so that a reproducible checksum of the plaindata is never available to + * equivalent blocks of data we use an HMAC of the plaintext. We use an HMAC + * here so that a reproducible checksum of the plaintext is never available to * the attacker. The HMAC key is kept alongside the master key, encrypted on * disk. The first 64 bits of the HMAC are used in place of the random salt, and * the next 96 bits are used as the IV. As a result of this mechanism, dedup |