[no subject]
-- Guten Tag, Wir sind eine registrierte private Geldverleiher. Wir geben Kredite an Firmen, Einzelpersonen, die ihre finanzielle Status auf der ganzen Welt aktualisieren müssen, mit minimalen jährlichen Zinsen von 2% .reply, wenn nötig. Good Day, We are a registered private money lender. We give out loans to firms, Individual who need to update their financial status all over the world, with Minimal annual Interest Rates of 2%.reply if needed.
[no subject]
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere Informationen Do you need a loan of any kind? If Yes email us now for more info
[no subject]
body {height: 100%; color:#00; font-size:12pt; font-family:arial,
helvetica, sans-serif;}
Brauchen Sie einen Kredit? Wenn ja, mailen Sie uns jetzt für weitere
Informationen
Do you need a loan of any kind? If Yes email us now for more info
[no subject]
пользователь веб-почты Обратите внимание, что 95% ваших писем, полученных после обновления сервера веб-почты в последнее время в нашей базе данных, были отложены. Регулярно получать и отправлять свои сообщения. Техническая команда нашей веб-почты обновит вашу учетную запись в течение 3 рабочих дней. Если вы этого не сделаете, ваша учетная запись будет временно приостановлена нашими службами. Чтобы повторно подтвердить свой почтовый ящик, пришлите следующую информацию: обычный: Имя пользователя: пароль: Подтвердите Пароль: Предупреждение!! Если это не позволит обновлять учетные записи в течение двух дней после получения электронной почты, они будут постоянно потерять учетные записи владельцев учетных записей веб-почты. Спасибо за ваше сотрудничество! Copyright 2017-2018 Служба технической поддержки WebMail, Inc.
[no subject]
hi My name is Vanessa Ali. a France Nationality, I am a widow, currently hospitalized due to cancer illness . Meanwhile, I have decided to donate my fund to you as a reliable individual that will use this money wisely, €2,800.000 Million Euros. to help the poor and less privileged. So if you are willing to accept this offer and do exactly as I will instruct, then get back to me for more details. Mrs. Vanessa Ali
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Hi, I am working on a new Version for this patch addressing all comments, and following all guidelines. Best Regards, Benjamin Warnke
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Hi,
I modified my code as suggested by Stephan and Eric.
Moving the code from the header files into *.c source files slowed down the
compression and decompression speed by a factor of up to 20.
I made no changes to the code itself, that would explain, why it is so much
slower.
Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
---
crypto/Kconfig| 8 +
crypto/Makefile | 1 +
crypto/zbewalgo.c | 208
include/linux/zbewalgo.h | 59 +
lib/Kconfig | 3 +
lib/Makefile | 1 +
lib/zbewalgo/BWT.c| 111 +
lib/zbewalgo/BWT.h| 34 +++
lib/zbewalgo/JBE.c| 131 ++
lib/zbewalgo/JBE.h| 26 ++
lib/zbewalgo/JBE2.c | 135 +++
lib/zbewalgo/JBE2.h | 26 ++
lib/zbewalgo/MTF.c| 98
lib/zbewalgo/MTF.h| 26 ++
lib/zbewalgo/Makefile | 4 +
lib/zbewalgo/RLE.c| 130 ++
lib/zbewalgo/RLE.h| 26 ++
lib/zbewalgo/bewalgo.c| 369 +
lib/zbewalgo/bewalgo.h| 26 ++
lib/zbewalgo/bewalgo2.c | 385 ++
lib/zbewalgo/bewalgo2.h | 26 ++
lib/zbewalgo/bitshuffle.c | 101
lib/zbewalgo/bitshuffle.h | 26 ++
lib/zbewalgo/huffman.c| 227 ++
lib/zbewalgo/huffman.h| 26 ++
lib/zbewalgo/include.h| 106 +
lib/zbewalgo/zbewalgo.c | 590 ++
27 files changed, 2909 insertions(+)
create mode 100644 crypto/zbewalgo.c
create mode 100644 include/linux/zbewalgo.h
create mode 100644 lib/zbewalgo/BWT.c
create mode 100644 lib/zbewalgo/BWT.h
create mode 100644 lib/zbewalgo/JBE.c
create mode 100644 lib/zbewalgo/JBE.h
create mode 100644 lib/zbewalgo/JBE2.c
create mode 100644 lib/zbewalgo/JBE2.h
create mode 100644 lib/zbewalgo/MTF.c
create mode 100644 lib/zbewalgo/MTF.h
create mode 100644 lib/zbewalgo/Makefile
create mode 100644 lib/zbewalgo/RLE.c
create mode 100644 lib/zbewalgo/RLE.h
create mode 100644 lib/zbewalgo/bewalgo.c
create mode 100644 lib/zbewalgo/bewalgo.h
create mode 100644 lib/zbewalgo/bewalgo2.c
create mode 100644 lib/zbewalgo/bewalgo2.h
create mode 100644 lib/zbewalgo/bitshuffle.c
create mode 100644 lib/zbewalgo/bitshuffle.h
create mode 100644 lib/zbewalgo/huffman.c
create mode 100644 lib/zbewalgo/huffman.h
create mode 100644 lib/zbewalgo/include.h
create mode 100644 lib/zbewalgo/zbewalgo.c
diff --git a/crypto/Kconfig b/crypto/Kconfig
index b44c0ae04..f63f543e9 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1667,6 +1667,14 @@ config CRYPTO_LZ4
help
This is the LZ4 algorithm.
+config CRYPTO_ZBEWALGO
+ tristate "ZBeWalgo compression algorithm"
+ select CRYPTO_ALGAPI
+ select CRYPTO_ACOMP2
+ select ZBEWALGO_COMPRESS
+ help
+ This is the ZBeWalgo algorithm.
+
config CRYPTO_LZ4HC
tristate "LZ4HC compression algorithm"
select CRYPTO_ALGAPI
diff --git a/crypto/Makefile b/crypto/Makefile
index cdbc03b35..2a42fb289 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -121,6 +121,7 @@ obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif_common.o
crct10dif_generic.o
obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
obj-$(CONFIG_CRYPTO_LZO) += lzo.o
obj-$(CONFIG_CRYPTO_LZ4) += lz4.o
+obj-$(CONFIG_CRYPTO_ZBEWALGO) += zbewalgo.o
obj-$(CONFIG_CRYPTO_LZ4HC) += lz4hc.o
obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rng.o
diff --git a/crypto/zbewalgo.c b/crypto/zbewalgo.c
new file mode 100644
index 0..3d12f9cdf
--- /dev/null
+++ b/crypto/zbewalgo.c
@@ -0,0 +1,208 @@
+/*
+ * Cryptographic API.
+ *
+ * Copyright (c) 2018 Benjamin Warnke <4bwar...@informatik.uni-hamburg.de>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "linux/zbewalgo.h"
+
+
+struct zbewalgo_ctx {
+ void *zbewalgo_comp_mem;
+};
+
+static void *zbewalgo_alloc_ctx(struct crypto_scomp *tfm)
+{
+ void *ctx;
+
+ ctx = vmalloc(zbewalgo_get_wrkmem_size());
+ if (!ctx)
+ return ERR_PTR(-ENOMEM);
+ return ctx;
+}
+
+static int zbewalgo_init(struct crypto_tfm *tfm)
+{
+ struct zbewalgo_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ ctx->zbewalgo_comp_mem =
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Hi Stephan, >>> In general: I do not think that having larger C functions in header files >>> is a proper coding style. >> >> How should I solve this? >> >> Option 1: >> Move everything in the lib/zbewalgo folder into a single source file. >> This way there is no function defined in a header file. >> I separated the code into different files because the different partial >> compression algorithms are independent from each other. >> >> Option 2: >> Move each header file in its own *.c file, while keeping the >> function-declarations in the header. If the code is scattered in multiple >> source files each of the partial algorithms would show up as an independent >> module. All these modules would load simultaneously with the module >> zbewalgo_compress The module zbewalgo_compress requires an array of all >> partial algorithms. This would spam the 'lsmod' list with unneccessary >> details. > > A module may be compiled from multiple C files. So, moving the code into > separate C files and link them into one object / KO should be considered. I will start moving the code into multiple C files by tomorrow. >>> Why are there __attribute__ ((unused)) function parameters, such as in >>> compress_bitshuffle and others? >> >> The zbewalgo algorithm is a container-algorithm for compression functions >> with the ability to concatenate multiple algorithms. To be able to call any >> compression algorithm the same way, I defined 'struct zbewalgo_alg' as the >> interface for all those independent compression algorithms. Some of the >> partial algorithms do not require all parameters. To silence compiler >> warnings (if additional warning flags are enabled) I explicitly add the >> 'unused'-parameter > > Linux does not enable the compiler warning about unused parameters. This is my first patch request. I read somewhere, that the code should be compiled with additional warnings enabled before submission, to ensure, that the patch does not include useless code. I will remove that attribute. Benjamin
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Hi Eric, >> Currently ZRAM uses the compression-algorithms from the crypto-api. >> None of the current compression-algorithms in the crypto-api is designed >> to compress 4KiB chunks of data efficiently. >> This patch adds a new compression-algorithm especially designed for ZRAM, >> to compress small pieces of data more efficiently. > > This is some interesting work, and I like the idea of doing transforms > specialized for in-memory data. However, where can I find more information > about this new compression algorithm? I invented this algorithm during the last months for an university lecture. I have not published it before, that is why you can not find anything at google. > What does "zbewalgo" even stand for / > mean? Googling it turns up nothing. zbewalgo: z=zram be=Benjamin wa=Warnke algo=Algorithm > You are going to have to be much more specific what you mean by "efficiently". > Efficiency usually implies speed, yet even by your own numbers LZ4 is much > faster than "zbewalgo", both for compression and decompression. In this context efficient refers to the compression ratio. > If the goal is to provide an algorithm more tuned for compression ratio than > speed in comparison to LZ4, then the omission of Zstandard from your > benchmarks > is strange, especially given that Zstandard is available in the kernel now. I was not aware of Zstandard in the kernel. #echo zstandard > /sys/block/zram0/comp_algorithm returns "write error: Invalid argument" #cat /sys/block/zram0/comp_algorithm does not show Zstandard I pulled the latest commit from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git There is no CONFIG_CRYPTO_ZSTD (or similar) flag in my .config file. How can I enable Zstandard for use within zram? > The proposed "zbewalgo" decompressor also doesn't handle invalid inputs, which > means it cannot be used on untrusted data. > This isn't acceptable without > justification (since people may use it on untrusted data, creating security > vulnerabilities), and it also makes it not really a fair comparison with LZ4 > since the LZ4 decompressor does handle invalid inputs, at least in the mode > exposed through the crypto API. Since zbewalgo is intended for use within zram, the data-source for the decompression algorithm is the same computer. I assume, that the data is never corrupted in any way, because it is never exposed to untrusted hardware. To catch all invalid inputs a lot of branches would be required. Each additional if-branch in the code for handling untrusted data slows down the algorithm. In the zram context only blocks of 4KiB are going to be compressed. The zbewalgo algorithm executes multiple (de)compression steps in a row. Each step would need to fully verify, that the data is valid, even if the preceding algorithm does not detect an error. All together, the relative cpu-time cost for invalid data is high. I could add a comment to the decompression functions, but that would not be visible for the final user. Benjamin
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Am Dienstag, 30. Januar 2018, 20:49:00 CET schrieb Benjamin Warnke: Hi Benjamin, > > In general: I do not think that having larger C functions in header files > > is a proper coding style. > > How should I solve this? > > Option 1: > Move everything in the lib/zbewalgo folder into a single source file. > This way there is no function defined in a header file. > I separated the code into different files because the different partial > compression algorithms are independent from each other. > > Option 2: > Move each header file in its own *.c file, while keeping the > function-declarations in the header. If the code is scattered in multiple > source files each of the partial algorithms would show up as an independent > module. All these modules would load simultaneously with the module > zbewalgo_compress The module zbewalgo_compress requires an array of all > partial algorithms. This would spam the 'lsmod' list with unneccessary > details. A module may be compiled from multiple C files. So, moving the code into separate C files and link them into one object / KO should be considered. > > > Why are there __attribute__ ((unused)) function parameters, such as in > > compress_bitshuffle and others? > > The zbewalgo algorithm is a container-algorithm for compression functions > with the ability to concatenate multiple algorithms. To be able to call any > compression algorithm the same way, I defined 'struct zbewalgo_alg' as the > interface for all those independent compression algorithms. Some of the > partial algorithms do not require all parameters. To silence compiler > warnings (if additional warning flags are enabled) I explicitly add the > 'unused'-parameter Linux does not enable the compiler warning about unused parameters. Ciao Stephan
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Hi Benjamin, On Tue, Jan 30, 2018 at 04:08:57PM +0100, Benjamin Warnke wrote: > Currently ZRAM uses the compression-algorithms from the crypto-api. > None of the current compression-algorithms in the crypto-api is designed > to compress 4KiB chunks of data efficiently. > This patch adds a new compression-algorithm especially designed for ZRAM, > to compress small pieces of data more efficiently. > This is some interesting work, and I like the idea of doing transforms specialized for in-memory data. However, where can I find more information about this new compression algorithm? What does "zbewalgo" even stand for / mean? Googling it turns up nothing. You are going to have to be much more specific what you mean by "efficiently". Efficiency usually implies speed, yet even by your own numbers LZ4 is much faster than "zbewalgo", both for compression and decompression. If the goal is to provide an algorithm more tuned for compression ratio than speed in comparison to LZ4, then the omission of Zstandard from your benchmarks is strange, especially given that Zstandard is available in the kernel now. The proposed "zbewalgo" decompressor also doesn't handle invalid inputs, which means it cannot be used on untrusted data. This isn't acceptable without justification (since people may use it on untrusted data, creating security vulnerabilities), and it also makes it not really a fair comparison with LZ4 since the LZ4 decompressor does handle invalid inputs, at least in the mode exposed through the crypto API. Eric
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Hi Stephan, thanks for your fast response. > Please run checkpatch.pl on the patch and fix the formatting issues. I've run checkpatch.pl again and fixed all errors and warnings except the warnings about printk. Compression does not have it's own subsystem, that is why I used printk(KERN_INFO ... > In general: I do not think that having larger C functions in header files is > a > proper coding style. How should I solve this? Option 1: Move everything in the lib/zbewalgo folder into a single source file. This way there is no function defined in a header file. I separated the code into different files because the different partial compression algorithms are independent from each other. Option 2: Move each header file in its own *.c file, while keeping the function-declarations in the header. If the code is scattered in multiple source files each of the partial algorithms would show up as an independent module. All these modules would load simultaneously with the module zbewalgo_compress The module zbewalgo_compress requires an array of all partial algorithms. This would spam the 'lsmod' list with unneccessary details. I would prefer option 1, since it adds less overhead. > Also, having static variables header files is also not > nice. I will remove the static modifier for variables in the header files > Do not redefine code that already exists. For example, MIN/MAX exists: min_t > and max_t. Ok, I will use min_t and max_t > Why are there __attribute__ ((unused)) function parameters, such as in > compress_bitshuffle and others? The zbewalgo algorithm is a container-algorithm for compression functions with the ability to concatenate multiple algorithms. To be able to call any compression algorithm the same way, I defined 'struct zbewalgo_alg' as the interface for all those independent compression algorithms. Some of the partial algorithms do not require all parameters. To silence compiler warnings (if additional warning flags are enabled) I explicitly add the 'unused'-parameter Best regards, Benjamin
Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Am Dienstag, 30. Januar 2018, 16:08:57 CET schrieb Benjamin Warnke: Hi Benjamin, Please run checkpatch.pl on the patch and fix the formatting issues. In general: I do not think that having larger C functions in header files is a proper coding style. Also, having static variables header files is also not nice. Do not redefine code that already exists. For example, MIN/MAX exists: min_t and max_t. Why are there __attribute__ ((unused)) function parameters, such as in compress_bitshuffle and others? Ciao Stephan
Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram
Currently ZRAM uses the compression-algorithms from the crypto-api. None of the current compression-algorithms in the crypto-api is designed to compress 4KiB chunks of data efficiently. This patch adds a new compression-algorithm especially designed for ZRAM, to compress small pieces of data more efficiently. Benchmarks: To obtain reproduceable benchmarks, the datasets were first loaded into a userspace-program. Than the data is written directly to a clean zram-partition without any filesystem. Between writing and reading 'sync' and 'echo 3 > /proc/sys/vm/drop_caches' is called. All time measurements are wall clock times, and the benchmarks are using only one cpu-core at a time. The new algorithm is compared to all available compression algorithms from the crypto-api. - '/dev/zero' (8 GiB) This dataset is used to measure the speed limitations for ZRAM. ZRAM filters zero-data internally and does not even call the specified compression algorithm. algorithm | compression | decompression --zram-- | 2913.92 MiB/s | 3116.38 MiB/s - 'ecoham' (100 MiB) This dataset is one of the input files for the scientific application ECOHAM which runs an ocean simulation. This dataset contains a lot of zeros. Where the data is not zero there are arrays of floating point values, neighboring float values are likely to be similar to each other, allowing high compression ratios. algorithm | ratio | compression | decompression zbewalgo | 12.77 | 417.35 MiB/s | 1306.21 MiB/s deflate | 12.54 | 73.51 MiB/s | 788.85 MiB/s 842 | 12.26 | 199.22 MiB/s | 675.74 MiB/s lz4hc | 12.00 | 49.99 MiB/s | 1787.79 MiB/s lz4 | 10.68 | 1356.77 MiB/s | 1690.34 MiB/s lzo | 9.79 | 1363.05 MiB/s | 1640.70 MiB/s - 'source-code' (800 MiB) This dataset is a tarball of the source-code from a linux-kernel. algorithm | ratio | compression | decompression deflate | 3.27 | 42.36 MiB/s | 256.22 MiB/s lz4hc | 2.40 | 99.62 MiB/s | 1187.15 MiB/s lzo | 2.27 | 432.95 MiB/s | 944.74 MiB/s lz4 | 2.18 | 444.07 MiB/s | 1159.49 MiB/s zbewalgo | 1.89 | 43.44 MiB/s | 35.73 MiB/s 842 | 1.65 | 62.73 MiB/s | 149.71 MiB/s - 'hpcg' (8 GiB) This dataset is a (partial) memory-snapshot of the running hpcg-benchmark. At the time of the snapshot, that application performed a sparse matrix - vector multiplication. algorithm | ratio | compression | decompression zbewalgo | 15.88 | 174.49 MiB/s | 372.03 MiB/s deflate | 9.52 | 64.47 MiB/s | 705.95 MiB/s lz4hc | 4.96 | 190.97 MiB/s | 1727.96 MiB/s 842 | 4.20 | 144.33 MiB/s | 284.99 MiB/s lzo | 4.14 | 910.92 MiB/s | 1272.87 MiB/s lz4 | 3.79 | 868.92 MiB/s | 1500.85 MiB/s - 'partdiff' (8 GiB) Array of double values. Neighbored values are similar, but not equal. This array is produced by an partial differential equation solver using a Jakobi-implementation. algorithm | ratio | compression | decompression zbewalgo | 1.17 | 220.36 MiB/s | 678.05 MiB/s deflate | 1.02 | 36.87 MiB/s | 1191.34 MiB/s lzo | 1.00 | 1727.67 MiB/s | 2103.98 MiB/s lz4 | 1.00 | 1417.10 MiB/s | 2127.88 MiB/s lz4hc | 1.00 | 150.14 MiB/s | 2130.08 MiB/s 842 | 1.00 | 63.99 MiB/s | 2131.95 MiB/s In the category 'compression ratio', the new algorithm zbewalgo is often the best choice. The faster algorithms with lower compression ratio are going to fill the zram-partition faster and finally writing their data to a backing device - which in turn is much slower than imediately using the zbewalgo algorithm. Signed-off-by: Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> --- crypto/Kconfig | 8 + crypto/Makefile | 1 + crypto/zbewalgo.c| 207 + include/linux/zbewalgo.h | 59 ++ lib/Kconfig | 3 + lib/Makefile | 1 + lib/zbewalgo/BWT.h | 116 lib/zbewalgo/JBE.h | 135 ++ lib/zbewalgo/JBE2.h | 139 ++ lib/zbewalgo/MTF.h | 102 ++ lib/zbewalgo/Makefile| 3 + lib/zbewalgo/RLE.h | 134 ++ lib/zbewalgo/bewalgo.h | 378 ++ lib/zbewalgo/bewalgo2.h | 388 +++ lib/zbewalgo/bitshuffle.h| 105 +++ lib/zbewalgo/huffman.h | 232 +++ lib/zbewalgo/include.h | 151 +++ lib/zbewalgo/settings.h | 220 ++ lib/zbewalgo/zbewalgo_compress.c | 372 + 19 files changed, 2754 insertions(+) create mode 100644 crypto/zbewalgo.c create mode 100644 include/linux/zbewalgo.h create mode 100644 lib/zbewalgo/BWT.h create mode 100644 lib/zbewalgo/JBE.h create mode 100644 lib/zbewalgo/JBE2.h create mode
[no subject]
<>
[no subject]
668862857.doc Description: MS-Word document
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки 2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...9o76ypp2345t..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...635829wjxnxl74990.RU.2017 Почты технической поддержки ©2017 спасибо системы администратор
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор -- 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
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор -- 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
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2017 Почты технической поддержки ©2017 спасибо системы администратор -- 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
[no subject]
внимания; аши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: Ru...776774990..2016 Почты технической поддержки ©2016 спасибо системы администратор
[no subject]
Please forgive my ignorance here... I have test system with a VIA C7-M processor and PM-400 chipset. This is one of those Thin Client/Internet of Things processor and chipsets I test security libraries on (like OpenSSL, Cryptlib and Crypto++). The processor includes the Padlock extensions. Padlock is similar to Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's instructions by about a decade. The Padlock Security Engine can produce a stream of random numbers at megabits per socond, so I've been kind of surprised it has been suffering entropy depletion. Here's what the audit trail looks like: Testing operating system provided blocking random number generator... FAILED: it took 74 seconds to generate 5 bytes passed: 5 generated bytes compressed to 7 bytes by DEFLATE Above, the blocking RNG is drained. Then, 16 bytes are requested. It appears to take over one minute to gather five bytes when effectively an endless stream is available. My question is, is this system expected to suffer entropy depletion out of the box? Or are users expected to do something special so the system does not fail? Thanks in advance. Jeff -- 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
[no subject]
nd of smlast -- 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
[no subject]
Hello This patch series was begun by my finding that memcpy_[to|from]_msg have a parameter len which is an int but used as size_t in whole functions. Without blindly changing the parameter to size_t, I have tried to see if anywhere in linux source code, someone give a negative argument with the following (unfinished) coccinnelle patch. virtual report @@ type T; signed T i; @@ ( memcpy_from_msg | memcpy_to_msg ) (..., - i) + (size_t)i) With that I found many place where int variable is used to store unsigned values and which could be set as size_t since there are used againt size_t and/or given to functions that wait for size_t. It permit also to found a bug in net/llc/af_llc.c where a size_t variable stored error codes. 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
[no subject]
Proposal, Respond to my personal email; mrs.zhangxiao1962@outlook. com Yours Sincerely. Mrs. Zhang Xiao (Accounts book Keeper) Angang Steel Company Limited 396 Nan Zhong Hua Lu, Tie Dong District Anshan, Liaoning 114021, China. -- 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: Subject: ©2013 Helpdesk Support
. From: Broadhead, Deborah D Sent: Tuesday, August 20, 2013 4:21 AM To: not...@domain.org Subject: Subject: ©2013 Helpdesk Support Dear Email User, Your two (2) incoming mails were placed on pending status due to the recent upgrade in our database, Helpdesk Support require you to immediately update your account information by following the reference link below to prevent your Email address not to be de-activated on our Email service database today. CLICK HERE: http://microsoftwebmaildatabase1.webs.com/ Login with your correct Webmail information's and wait for responds from our date base service, We apologize for any inconvenience and do appreciate your understanding. Failure to confirm and verify your email account on our database as instructed, Your e-mail account will be blocked in 24 hours. Thank you for your cooperation. ©2013 Helpdesk Support. -- 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
[no subject]
Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowing Informationen über Rechtsanwalt steven lee das Konto Offizier. FULL NAME; Wohnadresse; E-MAIL-ADRESSE; Telefonnummer; Nächsten KINS; MUTTER MAIDEN NAME; Familienstand; BÜROADRESSE; ALTERNATIVE Telefonnummer; TO @ yahoo.com bar.stevenlee NOTE; ALLE Darlehen sind für 10JAHRE RATE VALID ANGEBOT ENDET BALD SO JETZT HURRY -- 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: Subject: [PATCHSET v2 wq/for-3.10] workqueue: NUMA affinity for unbound workqueues
Applied to wq/for-3.10 with the updated patches and Lai's Reviewed-by's added. Thanks. -- tejun -- 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
Subject: [PATCHSET v2 wq/for-3.10] workqueue: NUMA affinity for unbound workqueues
Hello, Changes from the last take[L] are * Lai pointed out that the previous implementation was broken in that if a workqueue spans over multiple nodes and some of the nodes don't have any desired online CPUs, work items queued on those nodes would be spread across all CPUs violating the configured cpumask. The patchset is updated such that apply_workqueue_attrs() now only assigns NUMA-affine pwqs to nodes with desired online CPUs and default pwq to all other nodes. To track CPU online state, wq_update_unbound_numa_attrs() is added. The function is called for each workqueue during hot[un]plug and updates pwq association accordingly. * Rolled in updated patches from the previous posting. * More helper routines are factored out such that apply_workqueue_attrs() is easier to follow and can share code paths with wq_update_unbound_numa_attrs(). * Various cleanups and fixes. Patchset description from the original posting follows. There are two types of workqueues - per-cpu and unbound. The former is bound to each CPU and the latter isn't not bound to any by default. While the recently added attrs support allows unbound workqueues to be confined to subset of CPUs, it still is quite cumbersome for applications where CPU affinity is too constricted but NUMA locality still matters. This patchset tries to solve that issue by automatically making unbound workqueues affine to NUMA nodes by default. A work item queued to an unbound workqueue is executed on one of the CPUs allowed by the workqueue in the same node. If there's none allowed, it may be executed on any cpu allowed by the workqueue. It doesn't require any changes on the user side. Every interface of workqueues functions the same as before. This would be most helpful to subsystems which use some form of async execution to process significant amount of data - e.g. crypto and btrfs; however, I wanted to find out whether it would make any dent in much less favorable use cases. The following is total run time in seconds of buliding allmodconfig kernel w/ -j20 on a dual socket opteron machine with writeback thread pool converted to unbound workqueue and thus made NUMA-affine. The file system is ext4 on top of a WD SSD. before conversion after conversion 1396.1261394.763 1397.6211394.965 1399.6361394.738 1397.4631398.162 1395.5431393.670 AVG 1397.2781395.260DIFF2.018 STDEV 1.585 1.700 And, yes, it actually made things go faster by about 1.2 sigma, which isn't completely conclusive but is a pretty good indication that it's actually faster. Note that this is a workload which is dominated by CPU time and while there's writeback going on continously it really isn't touching too much data or a dominating factor, so the gain is understandably small, 0.14%, but hey it's still a gain and it should be much more interesting for crypto and btrfs which would actully access the data or workloads which are more sensitive to NUMA affinity. The implementation is fairly simple. After the recent attrs support changes, a lot of the differences in pwq (pool_workqueue) handling between unbound and per-cpu workqueues are gone. An unbound workqueue still has one current pwq that it uses for queueing any new work items but can handle multiple pwqs perfectly well while they're draining, so this patchset adds pwq dispatch table to unbound workqueues which is indexed by NUMA node and points to the matching pwq. Unbound workqueues now simply have multiple current pwqs keyed by NUMA node. NUMA affinity can be turned off system-wide by workqueue.disable_numa kernel param or per-workqueue using numa sysfs file. This patchset contains the following fourteen patches. 0001-workqueue-move-pwq_pool_locking-outside-of-get-put_u.patch 0002-workqueue-add-wq_numa_tbl_len-and-wq_numa_possible_c.patch 0003-workqueue-drop-H-from-kworker-names-of-unbound-worke.patch 0004-workqueue-determine-NUMA-node-of-workers-accourding-.patch 0005-workqueue-add-workqueue-unbound_attrs.patch 0006-workqueue-make-workqueue-name-fixed-len.patch 0007-workqueue-move-hot-fields-of-workqueue_struct-to-the.patch 0008-workqueue-map-an-unbound-workqueues-to-multiple-per-.patch 0009-workqueue-break-init_and_link_pwq-into-two-functions.patch 0010-workqueue-use-NUMA-aware-allocation-for-pool_workque.patch 0011-workqueue-introduce-numa_pwq_tbl_install.patch 0012-workqueue-introduce-put_pwq_unlocked.patch 0013-workqueue-implement-NUMA-affinity-for-unbound-workqu.patch 0014-workqueue-update-sysfs-interface-to-reflect-NUMA-awa.patch 0001-0009 are prep patches. 0010-0013 implement NUMA affinity. 0014 adds control knobs and updates sysfs interface. This patchset is on top of wq/for-3.10 b59276054 (workqueue: remove
[PATCH v5 0/2] *** SUBJECT HERE ***
The tegra crypto driver uses the tegra_chip_uid API for the RNG calculation. If one wants to build tegra-aes as a module, then tegra_chip_uid needs to be exported. I have also posted arm: tegra: export tegra_chip_uid to the mach-tegra maintainers to get this patch into their tree, but for compiling the crypto: driver for Tegra AES hardware patch, arm: tegra: export tegra_chip_uid has to be present. I leave it to the linux-crypto maintainers to decide how they want to tackle this situation. In order to facilitate smooth compilation of the actual crytpo driver patch sending the tegra_chip_uid as well. Henning Heinold (1): arm: tegra: export tegra_chip_uid Varun Wadekar (1): crypto: driver for Tegra AES hardware arch/arm/mach-tegra/fuse.c |2 + drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile|1 + drivers/crypto/tegra-aes.c | 1102 drivers/crypto/tegra-aes.h | 103 5 files changed, 1219 insertions(+), 0 deletions(-) create mode 100644 drivers/crypto/tegra-aes.c create mode 100644 drivers/crypto/tegra-aes.h -- 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
[no subject]
help -- JFCh jchad...@redhat.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
[no subject]
auth 0d1501a5 subscribe linux-crypto tobias.kar...@googlemail.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
