#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;
#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
/* 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;
* 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
* 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
* 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
* 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
projects / zfs / commitdiff