[PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
fs/seq_file.c| 35 +++
include/linux/seq_file.h | 4
2 files changed, 39 insertions(+)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 3857b72..fec4a6b 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/cred.h
#include linux/mm.h
+#include linux/printk.h
#include asm/uaccess.h
#include asm/page.h
@@ -794,6 +795,40 @@ void seq_pad(struct seq_file *m, char c)
}
EXPORT_SYMBOL(seq_pad);
+/* Analogue of print_hex_dump() */
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int prefix_type,
+ int rowsize, int groupsize, const void *buf, size_t len,
+ bool ascii)
+{
+ const u8 *ptr = buf;
+ int i, linelen, remaining = len;
+ unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+
+ if (rowsize != 16 rowsize != 32)
+ rowsize = 16;
+
+ for (i = 0; i len; i += rowsize) {
+ linelen = min(remaining, rowsize);
+ remaining -= rowsize;
+
+ hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
+ linebuf, sizeof(linebuf), ascii);
+
+ switch (prefix_type) {
+ case DUMP_PREFIX_ADDRESS:
+ seq_printf(m, %s%p: %s\n, prefix_str, ptr + i,
linebuf);
+ break;
+ case DUMP_PREFIX_OFFSET:
+ seq_printf(m, %s%.8x: %s\n, prefix_str, i, linebuf);
+ break;
+ default:
+ seq_printf(m, %s%s\n, prefix_str, linebuf);
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(seq_hex_dump);
+
struct list_head *seq_list_start(struct list_head *head, loff_t pos)
{
struct list_head *lh;
diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index 52e0097..6a8be4c 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -107,6 +107,10 @@ int seq_write(struct seq_file *seq, const void *data,
size_t len);
__printf(2, 3) int seq_printf(struct seq_file *, const char *, ...);
__printf(2, 0) int seq_vprintf(struct seq_file *, const char *, va_list args);
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int prefix_type,
+ int rowsize, int groupsize, const void *buf, size_t len,
+ bool ascii);
+
int seq_path(struct seq_file *, const struct path *, const char *);
int seq_dentry(struct seq_file *, struct dentry *, const char *);
int seq_path_root(struct seq_file *m, const struct path *path,
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 0/5] fs/seq_file: introduce seq_hex_dump() helper
This introduces a new helper and switches current users to use it. parisc and s390 weren't tested anyhow, the other are compile tested. Andy Shevchenko (5): seq_file: provide an analogue of print_hex_dump() saa7164: convert to seq_hex_dump() crypto: qat - use seq_hex_dump() to dump buffers parisc: use seq_hex_dump() to dump buffers [S390] zcrypt: use seq_hex_dump() to dump buffers .../crypto/qat/qat_common/adf_transport_debug.c| 16 ++ drivers/media/pci/saa7164/saa7164-core.c | 31 +++ drivers/parisc/ccio-dma.c | 14 ++--- drivers/parisc/sba_iommu.c | 11 ++- drivers/s390/crypto/zcrypt_api.c | 10 +-- fs/seq_file.c | 35 ++ include/linux/seq_file.h | 4 +++ 7 files changed, 52 insertions(+), 69 deletions(-) -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 5/5] [S390] zcrypt: use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/s390/crypto/zcrypt_api.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index 0e18c5d..d1f9983 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -1203,16 +1203,8 @@ static void sprinthx(unsigned char *title, struct
seq_file *m,
static void sprinthx4(unsigned char *title, struct seq_file *m,
unsigned int *array, unsigned int len)
{
- int r;
-
seq_printf(m, \n%s\n, title);
- for (r = 0; r len; r++) {
- if ((r % 8) == 0)
- seq_printf(m, );
- seq_printf(m, %08X , array[r]);
- if ((r % 8) == 7)
- seq_putc(m, '\n');
- }
+ seq_hex_dump(m, , DUMP_PREFIX_NONE, 32, 4, array, len, false);
seq_putc(m, '\n');
}
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 3/5] crypto: qat - use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/crypto/qat/qat_common/adf_transport_debug.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_transport_debug.c
b/drivers/crypto/qat/qat_common/adf_transport_debug.c
index 6b69745..8b103cf 100644
--- a/drivers/crypto/qat/qat_common/adf_transport_debug.c
+++ b/drivers/crypto/qat/qat_common/adf_transport_debug.c
@@ -86,9 +86,7 @@ static int adf_ring_show(struct seq_file *sfile, void *v)
{
struct adf_etr_ring_data *ring = sfile-private;
struct adf_etr_bank_data *bank = ring-bank;
- uint32_t *msg = v;
void __iomem *csr = ring-bank-csr_addr;
- int i, x;
if (v == SEQ_START_TOKEN) {
int head, tail, empty;
@@ -111,18 +109,8 @@ static int adf_ring_show(struct seq_file *sfile, void *v)
seq_puts(sfile, --- Ring data \n);
return 0;
}
- seq_printf(sfile, %p:, msg);
- x = 0;
- i = 0;
- for (; i (ADF_MSG_SIZE_TO_BYTES(ring-msg_size) 2); i++) {
- seq_printf(sfile, %08X, *(msg + i));
- if ((ADF_MSG_SIZE_TO_BYTES(ring-msg_size) 2) != i + 1
- (++x == 8)) {
- seq_printf(sfile, \n%p:, msg + i + 1);
- x = 0;
- }
- }
- seq_puts(sfile, \n);
+ seq_hex_dump(sfile, , DUMP_PREFIX_ADDRESS, 16, 4,
+v, ADF_MSG_SIZE_TO_BYTES(ring-msg_size), false);
return 0;
}
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
Instead of custom approach let's use recently introduced seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/parisc/ccio-dma.c | 14 +++---
drivers/parisc/sba_iommu.c | 11 +++
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 8b490d7..9d353d2 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -1101,20 +1101,12 @@ static const struct file_operations ccio_proc_info_fops
= {
static int ccio_proc_bitmap_info(struct seq_file *m, void *p)
{
- int len = 0;
struct ioc *ioc = ioc_list;
while (ioc != NULL) {
- u32 *res_ptr = (u32 *)ioc-res_map;
- int j;
-
- for (j = 0; j (ioc-res_size / sizeof(u32)); j++) {
- if ((j 7) == 0)
- len += seq_puts(m, \n );
- len += seq_printf(m, %08x, *res_ptr);
- res_ptr++;
- }
- len += seq_puts(m, \n\n);
+ seq_hex_dump(m,, DUMP_PREFIX_NONE, 32, 4, ioc-res_map,
+ioc-res_size, false);
+ seq_putc(m, '\n');
ioc = ioc-next;
break; /* XXX - remove me */
}
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index 1ff1b67..fbc4db9 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -1857,15 +1857,10 @@ sba_proc_bitmap_info(struct seq_file *m, void *p)
{
struct sba_device *sba_dev = sba_list;
struct ioc *ioc = sba_dev-ioc[0]; /* FIXME: Multi-IOC support! */
- unsigned int *res_ptr = (unsigned int *)ioc-res_map;
- int i, len = 0;
- for (i = 0; i (ioc-res_size/sizeof(unsigned int)); ++i, ++res_ptr) {
- if ((i 7) == 0)
- len += seq_printf(m, \n );
- len += seq_printf(m, %08x, *res_ptr);
- }
- len += seq_printf(m, \n);
+ seq_hex_dump(m,, DUMP_PREFIX_NONE, 32, 4, ioc-res_map,
+ioc-res_size, false);
+ seq_printf(m, \n);
return 0;
}
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/5] saa7164: convert to seq_hex_dump()
Instead of custom approach let's use recently added seq_hex_dump() helper.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/pci/saa7164/saa7164-core.c | 31 ---
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index 1bf0697..6f81584 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -1065,7 +1065,6 @@ static int saa7164_proc_show(struct seq_file *m, void *v)
struct saa7164_dev *dev;
struct tmComResBusInfo *b;
struct list_head *list;
- int i, c;
if (saa7164_devcount == 0)
return 0;
@@ -1089,35 +1088,13 @@ static int saa7164_proc_show(struct seq_file *m, void
*v)
seq_printf(m, .m_pdwGetReadPos = 0x%x (0x%08x)\n,
b-m_dwGetWritePos, saa7164_readl(b-m_dwGetWritePos));
- c = 0;
seq_printf(m, \n Set Ring:\n);
- seq_printf(m, \n addr 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f\n);
- for (i = 0; i b-m_dwSizeSetRing; i++) {
- if (c == 0)
- seq_printf(m, %04x:, i);
+ seq_hex_dump(m, , DUMP_PREFIX_OFFSET, 16, 1,
+b-m_pdwSetRing, b-m_dwSizeSetRing, false);
- seq_printf(m, %02x, *(b-m_pdwSetRing + i));
-
- if (++c == 16) {
- seq_printf(m, \n);
- c = 0;
- }
- }
-
- c = 0;
seq_printf(m, \n Get Ring:\n);
- seq_printf(m, \n addr 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f\n);
- for (i = 0; i b-m_dwSizeGetRing; i++) {
- if (c == 0)
- seq_printf(m, %04x:, i);
-
- seq_printf(m, %02x, *(b-m_pdwGetRing + i));
-
- if (++c == 16) {
- seq_printf(m, \n);
- c = 0;
- }
- }
+ seq_hex_dump(m, , DUMP_PREFIX_OFFSET, 16, 1,
+b-m_pdwGetRing, b-m_dwSizeGetRing, false);
mutex_unlock(b-lock);
--
2.0.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/5] saa7164: convert to seq_hex_dump()
On Wed, Jul 9, 2014 at 11:24 AM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Instead of custom approach let's use recently added seq_hex_dump() helper. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com ack Reviewed-by: Steven Toth st...@kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote:
Instead of custom approach let's use recently introduced seq_hex_dump()
helper.
Doesn't this also change the output from
to
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/5] fs/seq_file: introduce seq_hex_dump() helper
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote: This introduces a new helper and switches current users to use it. While seq_print_hex_dump seems useful, I'm not sure existing forms can be changed to use it if any output content changes. seq_ is supposed to be a stable API. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 4/5] parisc: use seq_hex_dump() to dump buffers
In one case indeed it does, in another - no, though it seems it prints
same data (by meaning) in both cases. I would like driver maintainer
to say a word what they think about it.
On Wed, Jul 9, 2014 at 9:26 PM, Joe Perches j...@perches.com wrote:
On Wed, 2014-07-09 at 18:24 +0300, Andy Shevchenko wrote:
Instead of custom approach let's use recently introduced seq_hex_dump()
helper.
Doesn't this also change the output from
to
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: dts - Addition of missing SEC compatibile property in c29x device tree
On Tuesday, July 08, 2014 at 03:21:11 PM, Herbert Xu wrote: On Tue, Jul 01, 2014 at 07:37:23PM +0530, Nitesh Narayan Lal wrote: The driver is compatible with SEC version 4.0, which was missing from device tree resulting that the caam driver doesn't gets probed. Since SEC is backward compatible with older versions, so this patch adds those missing versions in c29x device tree. Signed-off-by: Nitesh Narayan Lal b44...@freescale.com Signed-off-by: Vakul Garg b16...@freescale.com Patch applied. Are you sure DT changes go through linux-crypto tree ? Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] crypto: caam - fix memleak in caam_jr module
On Friday, July 04, 2014 at 12:54:06 AM, Kim Phillips wrote: On Thu, 3 Jul 2014 15:07:50 +0300 Cristian Stoica cristian.sto...@freescale.com wrote: This patch fixes a memory leak that appears when caam_jr module is unloaded. Cc: sta...@vger.kernel.org # 3.13+ Signed-off-by: Cristian Stoica cristian.sto...@freescale.com --- drivers/crypto/caam/jr.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index 1d80bd3..e0b91fc 100644 --- a/drivers/crypto/caam/jr.c +++ b/drivers/crypto/caam/jr.c @@ -453,7 +453,7 @@ static int caam_jr_probe(struct platform_device *pdev) int error; jrdev = pdev-dev; - jrpriv = kmalloc(sizeof(struct caam_drv_private_jr), + jrpriv = devm_kzalloc(jrdev, sizeof(struct caam_drv_private_jr), GFP_KERNEL); alignment. Also, why are we replacing a _m_alloc with a _z_alloc? I am fine with replacing kmalloc with kzalloc in this context. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] ima: use ahash API for file hash calculation
On Tuesday, July 08, 2014 at 10:07:16 AM, Dmitry Kasatkin wrote: [...] Right, but my concern is not about unloading the kernel module, but about the IMA module parameters left initialized. The existing code will continue using ahash (software version), even though the kernel module was unloaded, not shash. My question is about the software implementations of ahash vs. shash performance. Mimi If HW driver will not be available, ahash loads generic driver which is using shash. Performance of that will be the same as for using shash directly. Hi Dmitry, I think Mimi is concerned about the crypto accelerator dying mid- flight. Imagine a situation where you have a hardware crypto accelerator connected via USB. You happily use IMA with this setup for days and then someone comes around and pulls the USB cable out. Will this be able to cope with such situation, for example by switching to software operations or such in some sane way ? I presume that's the concern here. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Wednesday, July 09, 2014 at 05:24:26 PM, Andy Shevchenko wrote:
The new seq_hex_dump() is a complete analogue of print_hex_dump().
We have few users of this functionality already. It allows to reduce their
codebase.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
fs/seq_file.c| 35 +++
include/linux/seq_file.h | 4
2 files changed, 39 insertions(+)
diff --git a/fs/seq_file.c b/fs/seq_file.c
index 3857b72..fec4a6b 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/cred.h
#include linux/mm.h
+#include linux/printk.h
#include asm/uaccess.h
#include asm/page.h
@@ -794,6 +795,40 @@ void seq_pad(struct seq_file *m, char c)
}
EXPORT_SYMBOL(seq_pad);
+/* Analogue of print_hex_dump() */
+void seq_hex_dump(struct seq_file *m, const char *prefix_str, int
prefix_type, + int rowsize, int groupsize, const void *buf,
size_t len,
+ bool ascii)
+{
+ const u8 *ptr = buf;
+ int i, linelen, remaining = len;
+ unsigned char linebuf[32 * 3 + 2 + 32 + 1];
+
+ if (rowsize != 16 rowsize != 32)
+ rowsize = 16;
+
+ for (i = 0; i len; i += rowsize) {
+ linelen = min(remaining, rowsize);
+ remaining -= rowsize;
+
+ hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
+linebuf, sizeof(linebuf), ascii);
+
+ switch (prefix_type) {
+ case DUMP_PREFIX_ADDRESS:
+ seq_printf(m, %s%p: %s\n, prefix_str, ptr + i,
linebuf);
+ break;
+ case DUMP_PREFIX_OFFSET:
+ seq_printf(m, %s%.8x: %s\n, prefix_str, i, linebuf);
+ break;
+ default:
+ seq_printf(m, %s%s\n, prefix_str, linebuf);
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(seq_hex_dump);
The above function looks like almost verbatim copy of print_hex_dump(). The
only
difference I can spot is that it's calling seq_printf() instead of printk().
Can
you not instead generalize print_hex_dump() and based on it's invocation, make
it call either seq_printf() or printk() ?
Best regards,
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/5] seq_file: provide an analogue of print_hex_dump()
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote: The above function looks like almost verbatim copy of print_hex_dump(). The only difference I can spot is that it's calling seq_printf() instead of printk(). Can you not instead generalize print_hex_dump() and based on it's invocation, make it call either seq_printf() or printk() ? How do you propose doing that given any seq_foo call requires a struct seq_file * and print_hex_dump needs a KERN_LEVEL. Is there an actual value to it? -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] ima: use ahash API for file hash calculation
On 10 July 2014 00:00, Marek Vasut ma...@denx.de wrote: On Tuesday, July 08, 2014 at 10:07:16 AM, Dmitry Kasatkin wrote: [...] Right, but my concern is not about unloading the kernel module, but about the IMA module parameters left initialized. The existing code will continue using ahash (software version), even though the kernel module was unloaded, not shash. My question is about the software implementations of ahash vs. shash performance. Mimi If HW driver will not be available, ahash loads generic driver which is using shash. Performance of that will be the same as for using shash directly. Hi Dmitry, I think Mimi is concerned about the crypto accelerator dying mid- flight. Imagine a situation where you have a hardware crypto accelerator connected via USB. You happily use IMA with this setup for days and then someone comes around and pulls the USB cable out. Will this be able to cope with such situation, for example by switching to software operations or such in some sane way ? I presume that's the concern here. Best regards, Marek Vasut Hi Marek, Nice to here from you. How was your rest stay at Japan? I have not seen any expression of such concern. But as we fallback to early allocated shash, which is not USB yet, then there is no problem. ahash itself does not bring any other additional problem than shash itself. They are compiled builtin together. Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
