search for: out_buffer

From: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> The "zstd at breakpoint.cc" compression algorithm enables ZSTD based compression as defined in RFC8478. The compression is delayed until the server sends the SSH_MSG_USERAUTH_SUCCESS which is the same time as with the "zlib at openssh.com" method. Signed-off-by: Sebastian Andrzej Siewior <sebastian at

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

...its_remaining"...) I'm not really sure I understand your code, but it looks much more complicated than it should be. Normally, the decode code should look like: speex_bits_init(&bits); speex_bits_read_from(&bits, packet, length); while (1) { err = speex_decode_int(state, bits, out_buffer); if (err != 0) break; play_audio(out_buffer); } if (err == -2) ms_warning("there was an error decoding"); I see from your code that you use speex_bits_remaining(&bits) but I can't really understand why. Could you explain? Jean-Marc

...E, &tmp); // set quality tmp = 10; speex_encoder_ctl ( state, SPEEX_SET_QUALITY, &tmp); // initialize bits speex_bits_init(&bits); while( 1 ) { // read FRAME_SIZE bytes from buffer // convert to short for ( int i = 0; i < FRAME_SIZE; i++) in[i] = out_buffer[i]; speex_bits_reset(&bits); // encode speex_encode ( state, in, &bits); // copy bits to an array of chars nbBytes = speex_bits_write ( &bits, cbits, 200); // copy these cbits into a buffer CopyBuffer(pBuffer + dwLength, cbits, nbBytes)...

...not really sure I understand your code, but it looks much more > complicated than it should be. Normally, the decode code should look like: > > speex_bits_init(&bits); > speex_bits_read_from(&bits, packet, length); > while (1) > { > err = speex_decode_int(state, bits, out_buffer); > if (err != 0) > break; > play_audio(out_buffer); > } > if (err == -2) > ms_warning("there was an error decoding"); > > > I see from your code that you use speex_bits_remaining(&bits) but I > can't really understand why. Could you explai...

>> The main idea is that Speex supports many bit-rates, but for one reason >> or another, some modes may be left out in implementations (e.g. for RAM >> or network reasons). What we're saying here is that you should make an >> effoft to at least support (and offer) the 8 kbps mode to maximise >> compatibility. > > I understood this. But as you may know: the

hello hpa, please pull for the latest git pull git://brane.itp.tuwien.ac.at/~mattems/klibc.git maks with the following shortlog: maximilian attems (9): mount: add nodev, noexec and nosuid options mount: add -n option cpio: small cleanups readlink: s/link/link_name/ kinit, mknod: s/(major|minor)/\1_num/ klibc: strcspn, strpbrk, strspn include string.h

...tWaitForSingleObject+0x3b(handle=0x8c, alertable=0, timeout=(nil)) [/build/buildd/wine1.3-1.4/dlls/ntdll/sync.c:1169] in ntdll (0x00a4e818) 6 0x7bc3f367 server_ioctl_file+0x226(handle=0x54, event=0x0(nil), apc=(nil), apc_context=0x0(nil), io=0xa4e9e8, code=0x110008, in_buffer=0x0(nil), in_size=0, out_buffer=0x0(nil), out_size=0) [/build/buildd/wine1.3-1.4/dlls/ntdll/file.c:1276] in ntdll (0x00a4e918) 7 0x7bc42217 NtFsControlFile+0xa6(handle=0x54, event=0x0(nil), apc=(nil), apc_context=0x0(nil), io=0xa4e9e8, code=0x110008, in_buffer=0x0(nil), in_size=0, out_buffer=0x0(nil), out_size=0) [/build/buildd...

...Documentation/CodingStyle index a096836..af2b5e9 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -397,8 +397,7 @@ cleanup needed then just return directly. Choose label names which say what the goto does or why the goto exists. An example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid -using GW-BASIC names like "err1:" and "err2:". Also don't name them after the -goto location like "err_kmalloc_failed:" +using GW-BASIC names like "err1:" and "err2:". The rationale for us...

...Documentation/CodingStyle index a096836..af2b5e9 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -397,8 +397,7 @@ cleanup needed then just return directly. Choose label names which say what the goto does or why the goto exists. An example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid -using GW-BASIC names like "err1:" and "err2:". Also don't name them after the -goto location like "err_kmalloc_failed:" +using GW-BASIC names like "err1:" and "err2:". The rationale for us...

The Wine development release 1.7.29 is now available. What's new in this release (see below for details): - Support for shaping and BiDi mirroring in DirectWrite. - Some page fault handling fixes. - A few more C runtime functions. - Various bug fixes. The source is available from the following locations: http://prdownloads.sourceforge.net/wine/wine-1.7.29.tar.bz2

...dbc2d7c5c 100644 --- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c +++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c @@ -305,12 +305,12 @@ static void do_request_cleanup(struct cpt_vf *cptvf, } } - kzfree(info->scatter_components); - kzfree(info->gather_components); - kzfree(info->out_buffer); - kzfree(info->in_buffer); - kzfree((void *)info->completion_addr); - kzfree(info); + kfree_sensitive(info->scatter_components); + kfree_sensitive(info->gather_components); + kfree_sensitive(info->out_buffer); + kfree_sensitive(info->in_buffer); + kfree_sensitive((void *)info-&g...

...dbc2d7c5c 100644 --- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c +++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c @@ -305,12 +305,12 @@ static void do_request_cleanup(struct cpt_vf *cptvf, } } - kzfree(info->scatter_components); - kzfree(info->gather_components); - kzfree(info->out_buffer); - kzfree(info->in_buffer); - kzfree((void *)info->completion_addr); - kzfree(info); + kfree_sensitive(info->scatter_components); + kfree_sensitive(info->gather_components); + kfree_sensitive(info->out_buffer); + kfree_sensitive(info->in_buffer); + kfree_sensitive((void *)info-&g...

...dbc2d7c5c 100644 --- a/drivers/crypto/cavium/cpt/cptvf_reqmanager.c +++ b/drivers/crypto/cavium/cpt/cptvf_reqmanager.c @@ -305,12 +305,12 @@ static void do_request_cleanup(struct cpt_vf *cptvf, } } - kzfree(info->scatter_components); - kzfree(info->gather_components); - kzfree(info->out_buffer); - kzfree(info->in_buffer); - kzfree((void *)info->completion_addr); - kzfree(info); + kfree_sensitive(info->scatter_components); + kfree_sensitive(info->gather_components); + kfree_sensitive(info->out_buffer); + kfree_sensitive(info->in_buffer); + kfree_sensitive((void *)info-&g...

v5: - Break the btrfs patch out as a separate patch to be processed independently. - Update the commit log of patch 1 to make it less scary. - Add a kzfree backward compatibility macro in patch 2. v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary memzero_explicit()" patch for now as there can be a bit more discussion on what is best. It will be introduced as a separate patch later on after this one is merged. This patchset makes a global rename of the kzfree()

This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer. Instead, the new kfree_sensitive() uses