On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features, rename hex_dump_to_buffer to
> hex_dump_to_buffer_ext, and replace the ascii bool parameter with flags.
[]
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/dr
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> With the wider display format, it can become hard to identify how many
> bytes into the line you are looking at.
>
> The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
> print vertical l
On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote:
> The change actions Jani's suggestion:
> https://lkml.org/lkml/2019/6/20/343
I suggest not changing any of the existing uses of
hex_dump_to_buffer and only use hex_dump_to_buffer_ext
when necessary for your extended use cases.
On Tue, 2019-06-25 at 15:06 +1000, Alastair D'Silva wrote:
> On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> > On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > In order to support additional features, rename hex_dump_to_buffer
> > > to
>
Hi Greg,
On Tue, Jun 25, 2019 at 7:10 AM Greg Ungerer wrote:
>
> Hi Sergio,
>
> On 23/6/19 3:58 pm, Sergio Paracuellos wrote:
> > On Sun, Jun 23, 2019 at 4:15 AM Brett Neumeier wrote:
> >> On Fri, Jun 21, 2019 at 7:35 AM Greg Ungerer wrote:
> >>> On 21/6/19 4:15 pm, Sergio Paracuellos wrote:
>
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Apologies for the large CC list, it's a heads up for those responsible
> for subsystems where a prototype change in generic code causes a change
> in those subsystems.
[]
> The default behaviour of hexdump is
Hi Sergio,
On 23/6/19 3:58 pm, Sergio Paracuellos wrote:
On Sun, Jun 23, 2019 at 4:15 AM Brett Neumeier wrote:
On Fri, Jun 21, 2019 at 7:35 AM Greg Ungerer wrote:
On 21/6/19 4:15 pm, Sergio Paracuellos wrote:
This patch series properly handle minor issues in this driver. These are:
* Disabl
On Mon, 2019-06-24 at 22:01 -0700, Joe Perches wrote:
> On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > In order to support additional features, rename hex_dump_to_buffer
> > to
> > hex_dump_to_buffer_ext, and replace the ascii bool parameter with
> >
On Tue, 25 Jun 2019, Ming Lei wrote:
> On Tue, Jun 25, 2019 at 12:01:24PM +1000, Finn Thain wrote:
> > > diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> > > index dccdb41bed8c..c7129f5234f0 100644
> > > --- a/drivers/s390/scsi/zfcp_dbf.c
> > > +++ b/drivers/s390/scsi/zfc
From: Alastair D'Silva
Similar to the previous patch, this patch separates groups by 2 spaces for
the hex fields, and 1 space for the ASCII field.
eg.
buf:: 454d414e 43415053 4e495f45 00584544 NAMESPAC E_INDEX.
buf:0010: 0002
Sign
From: Alastair D'Silva
In order to support additional features, rename hex_dump_to_buffer to
hex_dump_to_buffer_ext, and replace the ascii bool parameter with flags.
A wrapper is provided for callers that do not need anything but a basic
dump.
Signed-off-by: Alastair D'Silva
---
drivers/gpu/d
From: Alastair D'Silva
With the wider display format, it can become hard to identify how many
bytes into the line you are looking at.
The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to
print vertical lines to separate every N groups of bytes.
eg.
buf:: 454d414e 434
From: Alastair D'Silva
The behaviour of hexdump groups is to print the data out as if
it was a native-endian number.
This patch tweaks the documentation to make this clear, and also
adds the HEXDUMP_RETAIN_BYTE_ORDER flag to allow groups of
multiple bytes to be printed without affecting the orde
From: Alastair D'Silva
Apologies for the large CC list, it's a heads up for those responsible
for subsystems where a prototype change in generic code causes a change
in those subsystems.
This series enhances hexdump.
These improve the readability of the dumped data in certain situations
(eg. wi
From: Alastair D'Silva
Some buffers may only be partially filled with useful data, while the rest
is padded (typically with 0x00 or 0xff).
This patch introduces a flag to allow the supression of lines of repeated
bytes, which are replaced with '** Skipped %u bytes of value 0x%x **'
An inline wr
From: Alastair D'Silva
This patch removes the hardcoded row limits and allows for
other lengths. These lengths must still be a multiple of
groupsize.
This allows structs that are not 16/32 bytes to display on
a single line.
This patch also expands the self-tests to test row sizes
up to 64 bytes
From: Alastair D'Silva
The overflow tests did not account for the situation where no
overflow occurs and len < rowsize.
This patch renames the cryptic variables and accounts for the
above case.
The selftests now pass.
Signed-off-by: Alastair D'Silva
---
lib/test_hexdump.c | 48 ++
On Tue, Jun 25, 2019 at 12:01:24PM +1000, Finn Thain wrote:
> > diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> > index dccdb41bed8c..c7129f5234f0 100644
> > --- a/drivers/s390/scsi/zfcp_dbf.c
> > +++ b/drivers/s390/scsi/zfcp_dbf.c
> > @@ -552,7 +552,7 @@ static u16 zfcp_
> diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
> index dccdb41bed8c..c7129f5234f0 100644
> --- a/drivers/s390/scsi/zfcp_dbf.c
> +++ b/drivers/s390/scsi/zfcp_dbf.c
> @@ -552,7 +552,7 @@ static u16 zfcp_dbf_san_res_cap_len_if_gpn_ft(char *tag,
> if (x % (ZFCP
On Mon, Jun 24, 2019 at 05:13:24PM +0200, Steffen Maier wrote:
> Hi Ming,
>
> On 6/18/19 3:37 AM, Ming Lei wrote:
> > Use the scatterlist iterators and remove direct indexing of the
> > scatterlist array.
> >
> > This way allows us to pre-allocate one small scatterlist, which can be
> > chained w
The commit 52c4dfcead49 ("Staging: vc04_services: Cleanup in
ctrl_set_bitrate()") changed the return behavior of ctrl_set_bitrate().
This breaks probing of bcm2835-camera:
bcm2835-v4l2: mmal_init: failed to set all camera controls: -3
Cleanup: Destroy video encoder
Cleanup: Destroy ima
On Tue, Jun 25, 2019 at 02:33:06AM +0530, Ajay Kaher wrote:
coredump: fix race condition between mmget_not_zero()/get_task_mm()
and core dumping
[PATCH v4 1/3]:
Backporting of commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
[PATCH v4 2/3]:
Extension of commit 04f5866e41fb to fix the r
Hi Ming,
On 6/18/19 3:37 AM, Ming Lei wrote:
Use the scatterlist iterators and remove direct indexing of the
scatterlist array.
This way allows us to pre-allocate one small scatterlist, which can be
chained with one runtime allocated scatterlist if the pre-allocated one
isn't enough for the who
On Tue, Jun 25, 2019 at 02:33:04AM +0530, Ajay Kaher wrote:
> This patch is the extension of following upstream commit to fix
> the race condition between get_task_mm() and core dumping
> for IB->mlx4 and IB->mlx5 drivers:
>
> commit 04f5866e41fb ("coredump: fix race condition between
> mmget_not_
coredump: fix race condition between mmget_not_zero()/get_task_mm()
and core dumping
[PATCH v4 1/3]:
Backporting of commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
[PATCH v4 2/3]:
Extension of commit 04f5866e41fb to fix the race condition between
get_task_mm() and core dumping for IB->m
This patch is the extension of following upstream commit to fix
the race condition between get_task_mm() and core dumping
for IB->mlx4 and IB->mlx5 drivers:
commit 04f5866e41fb ("coredump: fix race condition between
mmget_not_zero()/get_task_mm() and core dumping")'
Thanks to Jason for pointing t
From: Andrea Arcangeli
commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
The core dumping code has always run without holding the mmap_sem for
writing, despite that is the only way to ensure that the entire vma
layout will not change from under it. Only using some signal
serialization o
From: Andrea Arcangeli
coredump: fix race condition between collapse_huge_page() and core dumping
commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream.
When fixing the race conditions between the coredump and the mmap_sem
holders outside the context of the process, we focused on
mmget_not_z
Ming,
> Today I found the whole patchset disappears from 5.3/scsi-queue, seems
> something is wrong?
Your changes are in 5.3/scsi-sg. I put them in a separate branch to
avoid having to rebase the rest of the queue in case we find more
issues.
My for-next branch is based on 5.3/scsi-queue and 5
Hi Martin,
On Thu, Jun 20, 2019 at 3:57 AM Martin K. Petersen
wrote:
>
>
> Bart,
>
> > Do you perhaps plan to push out these patches at a later time? It
> > seems like that branch has not been updated recently:
>
> I had a test failure on this end, that's why I didn't push. Appears to
> be hardwa
The coding-styles.rst states, that multiline comments should
allways contain a leading "*" in each line.
For multiline comments in general they
/*
* should look
* like this.
*/
For multiline comments in either net/ or drivers/net/ however,
they should
/* omit
* the first
* empty line.
*/
As per the last correspondence with Greg, he pointed out that the whole
driver rtl8192u should be merged some day into drivers/net/ and thus
implement different standards regarding multiline comments.
Because of that, we did the exact opposite of what we did the last time,
and changed comments such
As stated in coding-styles.rst multiline comments should be structured in a way,
that the actual comment starts on the second line of the commented portion. E.g:
/*
* Multiline comments
* should look like
* this.
*/
However, there is an exception to files in drivers/net/ and net/, where
multi
Hi Christophe,
Am 24.06.2019 um 07:33 schrieb Christophe JAILLET:
Do not allocate memory with GFP_KERNEL when holding a spin_lock, it may
sleep. Use GFP_NOWAIT instead.
Fixes: 950fd867c635 ("staging: bcm2835-camera: Replace open-coded idr with a struct
idr.")
Signed-off-by: Christophe JAILLET
On 2019/6/21 18:42, Gao Xiang wrote:
> Hi Chao,
>
> On 2019/6/21 17:46, Chao Yu wrote:
>> On 2019/6/21 0:07, Gao Xiang wrote:
>>> This patch adds a new generic decompression framework
>>> in order to replace the old LZ4-specific decompression code.
>>>
>>> Even though LZ4 is still the only support
On 2019/6/24 15:22, Gao Xiang wrote:
> This is patch v3 of erofs decompression inplace approach, which is sent
> out by my personal email since I'm out of office to attend Open Source
> Summit China 2019 these days. No major change from PATCH v2 since no
> noticeable issue raised from landing to ou
From: Gao Xiang
Decompressor needs to know whether it's a partial
or full decompression since only full decompression
can be decompressed in-place.
On kirin980 platform, sequential read is finally
increased to 812MiB/s after decompression inplace
is enabled.
Reviewed-by: Chao Yu
Signed-off-by:
From: Gao Xiang
compressed data will be usually loaded into last pages of
the extent (the last page for 4k) for in-place decompression
(more specifically, in-place IO), as ilustration below,
start of compressed logical extent
| end of this logical ext
From: Gao Xiang
This patch adds a new generic decompression framework
in order to replace the old LZ4-specific decompression code.
Even though LZ4 is still the only supported algorithm, yet
it is more cleaner and easy to integrate new algorithm than
the old almost hard-coded decompression backen
From: Gao Xiang
stagingpages are behaved as bounce pages for temporary use.
Move to compress.h since the upcoming decompressor will
allocate stagingpages as well.
Reviewed-by: Chao Yu
Signed-off-by: Gao Xiang
---
drivers/staging/erofs/compress.h | 40 +++
drivers/
On 2019/6/24 15:22, Gao Xiang wrote:
> From: Gao Xiang
>
> This patch moves per-CPU buffers to utils.c in order for
> the upcoming generic decompression framework to use it.
>
> Note that I tried to use generic per-CPU buffer or
> per-CPU page approaches to clean up further, but obvious
> perfor
This is patch v3 of erofs decompression inplace approach, which is sent
out by my personal email since I'm out of office to attend Open Source
Summit China 2019 these days. No major change from PATCH v2 since no
noticeable issue raised from landing to our products till now, mainly
as a response to
From: Gao Xiang
This patch integrates new decompression framework to
erofs decompression path, and remove the old
decompression implementation as well.
On kirin980 platform, sequential read is slightly
improved to 778MiB/s after the new decompression
backend is used.
Reviewed-by: Chao Yu
Signe
From: Gao Xiang
This patch aims at compacted compression indexes:
1) cleanup z_erofs_map_blocks_iter and move into zmap.c;
2) add compacted 4/2B decoding support.
On kirin980 platform, sequential read is increased about
6% (725MiB/s -> 770MiB/s) on enwik9 dataset if compacted 2B
feature is ena
From: Gao Xiang
This patch moves per-CPU buffers to utils.c in order for
the upcoming generic decompression framework to use it.
Note that I tried to use generic per-CPU buffer or
per-CPU page approaches to clean up further, but obvious
performanace regression (about 2% for sequential read) was
From: Gao Xiang
This patch introduces new compacted compression indexes.
In contract to legacy compression indexes that
each 4k logical cluster has an 8-byte index,
compacted ondisk compression indexes will have
amortized 2 bytes for each 4k logical cluster (compacted 2B)
amortized 4 by
46 matches
Mail list logo
