similar to: [PATCH] btrfs: use kmalloc for lzo de/compress buffer

From: Lasse Collin <lasse.collin@tukaani.org> The code assumes that the input is valid and not truncated. Add checks to avoid reading past the end of the input buffer. Change the type of "skip" from u8 to int to fix a possible integer overflow. Signed-off-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Jan Beulich <jbeulich@suse.com> ---

The prescription for Boot Info Table says that checksumming begins at byte 64 of isolinux.bin. When prepcore writes isolinux.bin it begins copying bytes from the input file at the offset given by variable "start". But it begins checksumming at offset 64 of the input file. The problem exists since introduction of prepcore by release 4.00. ISO 9660 programs usually fix it when they write

Originated/took from Steffen Winterfeldt and Michael Matz in opensuse's Syslinux package: https://bugzilla.opensuse.org/show_bug.cgi?id=1125616 "fix lzo memory aliasing issue" --- lzo/Makefile +++ lzo/Makefile @@ -19,6 +19,8 @@ LIB = lzo.a BINS = prepcore +OPTFLAGS += -fno-strict-aliasing + all : makeoutputdirs $(BINS) makeoutputdirs: -- -Ady

CentOS Errata and Security Advisory 2014:0861 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0861.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 5573a762c075a0d03f070c6bd0b47c41311fff66e21e034863d514ee65d8c081 lzo-2.03-3.1.el6_5.1.i686.rpm

CentOS Errata and Security Advisory 2014:0861 Moderate Upstream details at : https://access.redhat.com/errata/RHSA-2014:0861 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 898c40521dfa677aa2217a083a9f382618b359d7a1a0361167427123f3397632 lzo-2.06-6.el7_0.2.i686.rpm

Hello, I try to install tinc under cygwin. When I make an ./configure with tinc-1.0.1 I get the error-message checking for lzo1x_1_compress in -llzo... no configure: error:"lzo libraries not found" I have installed lzo-1.08. But it was not from the cygwin-Homepage and so I think that there was a wrong installation-path for the lzo-libraries. How can I find out where to install the

[adding libguestfs list, for nbdkit reference below] On 10/4/18 8:39 AM, Stefan Fröberg wrote: > Hello. > Is it possible to improve NBD throughtput with LZO compression ? As in, have a way for the client and server to negotiate that both understand an LZO extension, at which point the client can request a read or write with a flag set to mark that the data is LZO-compressed, for less

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've added lzo compression support for tinc 1.0pre8. Lzo is a very fast compressor (see http://www.oberhumer.com/opensource/lzo/). I've implemented it by using two new compression levels. Compression level 10 is for fast compression using lzo1x-1 algorithm. Compression level 11 is for slow compression using lzo1x-999 algorithm.

From: Shyam Saini <mayhs11saini at gmail.com> Date: Sat, 24 Dec 2016 00:44:58 +0530 > when some other buffer is immediately copied into allocated region. > Replace calls to kmalloc followed by a memcpy with a direct > call to kmemdup. > > Signed-off-by: Shyam Saini <mayhs11saini at gmail.com> Applied.

when some other buffer is immediately copied into allocated region. Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. Signed-off-by: Shyam Saini <mayhs11saini at gmail.com> --- drivers/net/virtio_net.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index ba1aa24..dde4bc4 100644 ---

On Wed, Jun 17, 2020 at 04:57:07PM -0500, Gustavo A. R. Silva wrote: > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mistakes. > > This code was detected with the help of Coccinelle and, audited and > fixed manually. > > Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> Queued up for

when some other buffer is immediately copied into allocated region. Replace calls to kmalloc followed by a memcpy with a direct call to kmemdup. Signed-off-by: Shyam Saini <mayhs11saini at gmail.com> --- drivers/net/virtio_net.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index ba1aa24..dde4bc4 100644 ---

In tree-log.c:replay_one_name(), if memory allocation for the name fails, ensure we iput the dir inode we got before before we return. Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com> --- fs/btrfs/tree-log.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index ff60d89..6797a93 100644 ---

On Mon, May 22, 2023 at 02:20:19PM +0530, Prathu Baronia wrote: >Use kzalloc() to allocate new zeroed out msg node instead of >memsetting a node allocated with kmalloc(). > >Signed-off-by: Prathu Baronia <prathubaronia2011 at gmail.com> >--- > drivers/vhost/vhost.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > >diff --git a/drivers/vhost/vhost.c

Some archs defconfigs have CONFIG_FRAME_WARN set to 1024, which lead to this warning: drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c: warning: the frame size of 1184 bytes is larger than 1024 bytes Reported-by: Geert Uytterhoeven <geert at linux-m68k.org> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c | 12

Replaced calls to kmalloc followd by memcpy with a single call to kmemdup. This patch was found using coccicheck. Signed-off-by: Alexandru Gheorghiu <gheorghiuandru at gmail.com> --- fs/ocfs2/localalloc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/ocfs2/localalloc.c b/fs/ocfs2/localalloc.c index aebeacd..839183f 100644 --- a/fs/ocfs2/localalloc.c +++

Signed-off-by: Mihnea Dobrescu-Balaur <mihneadb at gmail.com> --- drivers/block/xen-blkfront.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index c3dae2e..9620644 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1203,11 +1203,10 @@ static int blkif_recover(struct

Signed-off-by: Mihnea Dobrescu-Balaur <mihneadb at gmail.com> --- drivers/block/xen-blkfront.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index c3dae2e..9620644 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1203,11 +1203,10 @@ static int blkif_recover(struct

Hi Some developers here said a long time ago that someone should show the code for LZO compression support for ZFS before talking about the next step. I made that code with a friend and we also made a little benchmark to give a first impression: http://denisy.dyndns.org/lzo_vs_lzjb/ I hope we made no technical error, but if you find something not accurate, we will correct it. Denis -- This

Hi, I planned to boost my btrfs performance today. here some errors I met: my ''btrfs filesystem show'' result: ~ # btrfs filesystem show failed to read /dev/sr0 Label: none uuid: 9b9aa9d9-760e-445c-a0ab-68e102d9f02e Total devices 1 FS bytes used 36.59GB devid 1 size 49.52GB used 49.52GB path /dev/sda6 Label: none uuid: 559dec06-4fd0-47c1-97b8-cc4fa6153fa0