Currently, if DMA MEMCPY test is requested by the host, and if the endpoint
DMA controller supports DMA_PRIVATE, the test will fail. This is not
correct since there is no check for DMA_MEMCPY capability and the DMA
controller can support both DMA_PRIVATE and DMA_MEMCPY.
So fix the check and also
On Thu, Jan 16, 2025 at 07:21:03PM +0530, Manivannan Sadhasivam wrote:
> Currently, if DMA MEMCPY test is requested by the host, and if the endpoint
> DMA controller supports DMA_PRIVATE, the test will fail. This is not
> correct since there is no check for DMA_MEMCPY capability an
Currently, if DMA MEMCPY test is requested by the host, and if the endpoint
DMA controller supports DMA_PRIVATE, the test will fail. This is not
correct since there is no check for DMA_MEMCPY capability and the DMA
controller can support both DMA_PRIVATE and DMA_MEMCPY.
So fix the check and also
On 9/27/24 11:24, Jason A. Donenfeld wrote:
Hi Shuah,
On Tue, Sep 24, 2024 at 01:47:23PM +0200, Jason A. Donenfeld wrote:
When switching on -O2, gcc generates SSE2 instructions that assume a
16-byte aligned stack, which the standalone test's start point wasn't
aligning. Fix this with the usual
Hi Shuah,
On Tue, Sep 24, 2024 at 01:47:23PM +0200, Jason A. Donenfeld wrote:
> When switching on -O2, gcc generates SSE2 instructions that assume a
> 16-byte aligned stack, which the standalone test's start point wasn't
> aligning. Fix this with the usual alignnent sequence.
>
> Fixes: ecb8bd70d
When switching on -O2, gcc generates SSE2 instructions that assume a
16-byte aligned stack, which the standalone test's start point wasn't
aligning. Fix this with the usual alignnent sequence.
Fixes: ecb8bd70d51 ("selftests: vDSO: build tests with O2 optimization")
Reported-by: kernel test robot
Use memcpy() in raw_cmd_done() to copy reply_buffer instead
of a for loop.
Signed-off-by: Denis Efremov
---
drivers/block/floppy.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index c58b0b079afc..c584657bacab 100644
nction 'sctp_process_asconf_param',
inlined from 'sctp_process_asconf' at net/sctp/sm_make_chunk.c:3285:14:
>> net/sctp/sm_make_chunk.c:3150:4: warning: 'memcpy' offset [17, 28] from the
>> object at 'addr' is out of the bounds of referenced subobject &#
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In function '__skb_flow_bpf_to_target',
inlined from '__skb_flow_dissect' at net/core/flow_dissector.c:1014:4:
>> net/core/flow_dissector.c:835:3: warning: 'memcpy' offset
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
bytes (the 4th and
5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]"
which would copy in wrong and unintended information. The struct
"rtllib_info_el
d,
"CcxRmState" was used in the same memcpy() of the first patch. I caught
the error in it's type while trying to fix the first.
Thank you for your encouraging words :D
Regards,
Atul
Reviewed-by: Dan Carpenter
This is very clever detective work. How did you spot the bug?
regards,
dan carpenter
The "len" field defines the size of the "data[]" array. The code is
supposed to check if "info_element->len" is greater than 4 and later
equal to 6. If this is satisfied then, the last two bytes (the 4th and
5th element of u8 "data[]" array) are copied into &q
;ugeth_primary_info, sizeof(*ug_info), GFP_KERNEL);
> if (ug_info == NULL)
> return -ENOMEM;
> - memcpy(ug_info, &ugeth_primary_info, sizeof(*ug_info));
>
> ug_info->uf_info.ucc_num = ucc_num;
>
>
Ah, yes, of course, I should have used that.
Acked-by: Rasmus Villemoes
PTR(-ENOMEM);
- memcpy(resp, cmd.resp_pkt->data, resp_size);
-
iwl_free_resp(&cmd);
return resp;
}
--
1.9.1
; 0) || (ucc_num > 7))
return -ENODEV;
- ug_info = kmalloc(sizeof(*ug_info), GFP_KERNEL);
+ ug_info = kmemdup(&ugeth_primary_info, sizeof(*ug_info), GFP_KERNEL);
if (ug_info == NULL)
return -ENOMEM;
- memcpy(ug_info, &uget
rest (to which this patch applies) is
> > supposed to check if the "info_element->len" is greater than 4 and
> > equal to 6, if this is satisfied then, the last two bytes (the
> > 4th and 5th index of u8 "data" array) are copied into
> > "
>CcxRmState".
Currently the code uses "memcpy()" with the source as
"&info_element[4]" which would copy in wrong and unintended
information.
This patch rectifies this error by using "&info_element->data[4]" which
rightly copies the last two bytes a
regression on hardware that traps
misaligned load/store and emulate them using firmware.
The current behaviour of memcpy is that it checks if both
src and dest pointers are co-aligned (aka congruent
modular SZ_REG). If aligned, it will copy data word-by-word
after first aligning pointers to word
/ngene-core.c: In function
'ngene_command_config_free_buf':
>> drivers/media/pci/ngene/ngene-core.c:388:2: warning: 'memcpy' offset [12,
>> 16] from the object at 'com' is out of the bounds of referenced subobject
>> 'config' with type
On 13-01-21, 13:49, Peter Ujfalusi wrote:
> Hi,
>
> Changes since v1:
> - Added Kishon's tested-by to the first two patch
> - Moved the variable definitions to the start of their respective functions
> - Remove braces where they are not needed
> - correct indentation of cases
> - additional patch
Hi,
Changes since v1:
- Added Kishon's tested-by to the first two patch
- Moved the variable definitions to the start of their respective functions
- Remove braces where they are not needed
- correct indentation of cases
- additional patch to clean up the ret = 0 initializations in tisci channel
Hi,
On 14/12/20 1:43 pm, Peter Ujfalusi wrote:
> Hi,
>
> Newer members of the KS3 family (after AM654) have support for burst_size
> configuration for each DMA channel.
>
> The HW default value is 64 bytes but on higher throughput channels it can be
> increased to 256 bytes (UCHANs) or 128 byes
On Tue, Nov 12, 2019 at 12:31:32PM -0800, Dmitry Torokhov wrote:
> When copying memory from one buffer to another, instead of open-coding
> loops with byte-by-byte copies let's use memcpy() which might be a bit
> faster and makes intent more clear.
>
> Signed-off-by: Dmitry To
Hi,
Newer members of the KS3 family (after AM654) have support for burst_size
configuration for each DMA channel.
The HW default value is 64 bytes but on higher throughput channels it can be
increased to 256 bytes (UCHANs) or 128 byes (HCHANs).
Aligning the buffers and length of the transfer to
gt;
> - pptable_information->smc_pptable = kmalloc(sizeof(PPTable_t),
> GFP_KERNEL);
> + pptable_information->smc_pptable =
> kmemdup(&(powerplay_table->smcPPTable),
> + sizeof(PPTable_t),
> GFP_KERNEL);
>
p;(powerplay_table->smcPPTable),
+ sizeof(PPTable_t),
GFP_KERNEL);
if (pptable_information->smc_pptable == NULL)
return -ENOMEM;
- memcpy(pptable_information->smc_pptable,
&(powerplay_table->smcPPTable), sizeof(PPTable_t));
-
result = app
Use kmemdup() for instructions using kmalloc() + memcpy(). More
information here: https://lwn.net/Articles/198928/
Issue reported by coccinelle script: scripts/coccinelle/api/memdup.cocci
Signed-off-by: Deepak R Varma
---
Changes since v1:
- Update patch subject and log message to match
*depot_alloc_stack(unsigned long
*entries, int size,
stack->handle.slabindex = depot_index;
stack->handle.offset = depot_offset >> STACK_ALLOC_ALIGN;
stack->handle.valid = 1;
- memcpy(stack->entries, entries, size * sizeof(unsigned long));
+ mem
From: Vasundhara Volam
[ Upstream commit 492adcf481292521ee8df1a482dc12acdb28aa15 ]
Using strlcpy() to copy from VPD is not correct because VPD strings
are not necessarily NULL terminated. Use memcpy() to copy the VPD
length up to the destination buffer size - 1. The destination is
zeroed
Hmm, I applied this already:
commit 33f290811d4c1a09c4e92f5bf0458525835dbcba
Author: Alex Dewar
Date: Wed Sep 9 20:02:08 2020 +0100
drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy
kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern
On 20/09/2020 10:24, Daniel Vetter wrote:
> On Sat, Sep 19, 2020 at 9:31 PM Alex Dewar wrote:
>>
>> On 2020-09-11 13:57, Neil Armstrong wrote:
>>> On 09/09/2020 21:02, Alex Dewar wrote:
>>>> kmemdup can be used instead of kmalloc+memcpy. Replace an occurren
On 20/09/2020 10:24, Daniel Vetter wrote:
> On Sat, Sep 19, 2020 at 9:31 PM Alex Dewar wrote:
>>
>> On 2020-09-11 13:57, Neil Armstrong wrote:
>>> On 09/09/2020 21:02, Alex Dewar wrote:
>>>> kmemdup can be used instead of kmalloc+memcpy. Replace an occurren
2020-09-15 19:23 GMT-07:00, Sungjong Seo :
>> Use structure assignment instead of memcpy.
>>
>> Signed-off-by: Tetsuhiro Kohada
>
> Acked-by: Sungjong Seo
Applied. Thanks for your patch!
On Sat, Sep 19, 2020 at 9:31 PM Alex Dewar wrote:
>
> On 2020-09-11 13:57, Neil Armstrong wrote:
> > On 09/09/2020 21:02, Alex Dewar wrote:
> >> kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
> >> this pattern.
> Friendly ping?
> >
On 2020-09-11 13:57, Neil Armstrong wrote:
On 09/09/2020 21:02, Alex Dewar wrote:
kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.
Friendly ping?
Issue identified with Coccinelle.
Signed-off-by: Alex Dewar
---
drivers/gpu/drm/bridge/synopsys/dw-mipi
> Use structure assignment instead of memcpy.
>
> Signed-off-by: Tetsuhiro Kohada
Acked-by: Sungjong Seo
> ---
> fs/exfat/dir.c | 7 ++-
> fs/exfat/inode.c | 2 +-
> fs/exfat/namei.c | 15 +++
> 3 files changed, 10 insertions(+), 14 deletions(-)
&g
On Wed, 2020-09-09 at 20:09 +0100, Alex Dewar wrote:
> Issue identified with Coccinelle.
>
> Signed-off-by: Alex Dewar
Thank you.
Mimi
From: Sam Tebbs
Import the latest memcpy implementation into memcpy,
copy_{from, to and in}_user.
The implementation of the user routines is separated into two forms:
one for when UAO is enabled and one for when UAO is disabled, with
the two being chosen between with a runtime patch.
This avoids
Strings' strcmp
arm64: Import latest version of Cortex Strings' strlen
arm64: Import latest version of Cortex Strings' strncmp
arm64: Import latest optimization of memcpy
arch/arm64/include/asm/alternative.h | 36 ---
arch/arm64/include/asm/assembler.h | 13 +
arch/arm64/include
On Wed, Sep 09, 2020 at 08:04:15PM +0100, Alex Dewar wrote:
> On 24/08/2020 22:17, Alex Dewar wrote:
> > Issue identified with Coccinelle.
> Gentle ping?
> >
> > Signed-off-by: Alex Dewar
Acked-by: Bob Copeland
However, I don't have a git tree for OMFS so you'll need to send it
through vfs tre
On Mon 2020-09-14 11:54:03, John Ogness wrote:
> @state_var is copied as part of the descriptor copying via
> memcpy(). This is not allowed because @state_var is an atomic type,
> which in some implementations may contain a spinlock.
Great catch!
> Avoid using memcpy() with @
@state_var is copied as part of the descriptor copying via
memcpy(). This is not allowed because @state_var is an atomic type,
which in some implementations may contain a spinlock.
Avoid using memcpy() with @state_var by explicitly copying the other
fields of the descriptor. @state_var is set
On 09/09/2020 21:02, Alex Dewar wrote:
> kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
> this pattern.
>
> Issue identified with Coccinelle.
>
> Signed-off-by: Alex Dewar
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
>
t 09:12:49AM +0100, Oli Swede wrote:
Version 3 addressed this but I later found some issues with the fixup
correctness after further testing, and have partially re-written them
here, and addressed some other behaviours of the copy algorithm.
[...]
I am waiting on access to the relevant machine befo
them
> > > here, and addressed some other behaviours of the copy algorithm.
>
> [...]
>
> > I am waiting on access to the relevant machine before posting the benchmark
> > results for this optimized memcpy, but Sam reported the following with the
> >
Use structure assignment instead of memcpy.
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/dir.c | 7 ++-
fs/exfat/inode.c | 2 +-
fs/exfat/namei.c | 15 +++
3 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index fa5bb72aa295
);
- if (!nentry)
- return NULL;
-
/*
* Immutable elements are copied over as pointers and data; only
* lsm rules can change
*/
- memcpy(nentry, entry, sizeof(*nentry));
+ nentry = kmemdup(entry, sizeof(*nentry), GFP_KERNEL);
+ if
ptr = kmemdup(bh->b_data, sb->s_blocksize, GFP_KERNEL);
if (!*ptr) {
brelse(bh);
goto nomem_free;
}
- memcpy(*ptr, bh->b_data, sb->s_blocksize);
if (count &l
kmemdup can be used instead of kmalloc+memcpy. Replace an occurrence of
this pattern.
Issue identified with Coccinelle.
Signed-off-by: Alex Dewar
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge
On Sun, 06 Sep 2020 22:58:22 PDT (-0700), Christoph Hellwig wrote:
This reverts commit adccfb1a805ea84d2db38eb53032533279bdaa97.
Now that the generic uaccess by mempcy code handles unaligned addresses
the generic code can be used for all RISC-V CPUs.
Signed-off-by: Christoph Hellwig
---
arch/
ere, and addressed some other behaviours of the copy algorithm.
[...]
> I am waiting on access to the relevant machine before posting the benchmark
> results for this optimized memcpy, but Sam reported the following with the
> similar (but now slightly older) cortex-strings version:
This reverts commit adccfb1a805ea84d2db38eb53032533279bdaa97.
Now that the generic uaccess by mempcy code handles unaligned addresses
the generic code can be used for all RISC-V CPUs.
Signed-off-by: Christoph Hellwig
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/uaccess.h
This reverts commit adccfb1a805ea84d2db38eb53032533279bdaa97.
Now that the generic uaccess by mempcy code handles unaligned addresses
the generic code can be used for all RISC-V CPUs.
Signed-off-by: Christoph Hellwig
---
arch/riscv/Kconfig | 1 +
arch/riscv/include/asm/uaccess.h
> GFP_KERNEL);
> + pptable_information->smc_pptable =
> kmemdup(&(powerplay_table->smcPPTable),
> + sizeof(PPTable_t),
> + GFP_KERNEL);
> if (pptable_information->smc_p
change
*/
- memcpy(nentry, entry, sizeof(*nentry));
memset(nentry->lsm, 0, sizeof_field(struct ima_rule_entry, lsm));
for (i = 0; i < MAX_LSM_RULES; i++) {
--
2.28.0
FP_KERNEL);
if (!*ptr) {
brelse(bh);
goto nomem_free;
}
- memcpy(*ptr, bh->b_data, sb->s_blocksize);
if (count < sb->s_blocksize)
memset((void
eof(PPTable_t),
+ GFP_KERNEL);
if (pptable_information->smc_pptable == NULL)
return -ENOMEM;
- memcpy(pptable_information->smc_pptable,
- &(powerplay_table->smcPPTable),
-
From: Vincent Whitchurch
[ Upstream commit 1beaef29c34154ccdcb3f1ae557f6883eda18840 ]
For memcpy, the source pages are memset to zero only when --cycles is
used. This leads to wildly different results with or without --cycles,
since all sources pages are likely to be mapped to the same zero
From: Vincent Whitchurch
[ Upstream commit 1beaef29c34154ccdcb3f1ae557f6883eda18840 ]
For memcpy, the source pages are memset to zero only when --cycles is
used. This leads to wildly different results with or without --cycles,
since all sources pages are likely to be mapped to the same zero
From: Vincent Whitchurch
[ Upstream commit 1beaef29c34154ccdcb3f1ae557f6883eda18840 ]
For memcpy, the source pages are memset to zero only when --cycles is
used. This leads to wildly different results with or without --cycles,
since all sources pages are likely to be mapped to the same zero
From: Vincent Whitchurch
[ Upstream commit 1beaef29c34154ccdcb3f1ae557f6883eda18840 ]
For memcpy, the source pages are memset to zero only when --cycles is
used. This leads to wildly different results with or without --cycles,
since all sources pages are likely to be mapped to the same zero
From: Vincent Whitchurch
[ Upstream commit 1beaef29c34154ccdcb3f1ae557f6883eda18840 ]
For memcpy, the source pages are memset to zero only when --cycles is
used. This leads to wildly different results with or without --cycles,
since all sources pages are likely to be mapped to the same zero
From: Miaohe Lin
Date: Sat, 15 Aug 2020 04:48:53 -0400
> The frags of skb_shared_info of the data is assigned in following loop. It
> is meaningless to do a memcpy of frags here.
>
> Signed-off-by: Miaohe Lin
Applied, thank you.
The frags of skb_shared_info of the data is assigned in following loop. It
is meaningless to do a memcpy of frags here.
Signed-off-by: Miaohe Lin
---
net/core/skbuff.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index afbc1a79dc8a
[ 1083.857771] EIP: memcpy+0xf/0x20
[ 1083.857771] Code: 68 d0 7d ee d6 e8 11 1c c7 ff 0f 31 31 c3 59 58
eb 80 cc cc cc cc cc cc cc cc cc 55 89 e5 57 89 c7 56 89 d6 53 89 cb
c1 e9 02 a5 89 d9 83 e1 03 74 02 f3 a4 5b 5e 5f 5d c3 90 55 89 e5
57 89
[ 1083.860096] EAX: fe80c000 EBX: 0001 ECX: 4000 EDX
Em Mon, Aug 10, 2020 at 03:34:04PM +0200, Vincent Whitchurch escreveu:
> For memcpy, the source pages are memset to zero only when --cycles is
> used. This leads to wildly different results with or without --cycles,
> since all sources pages are likely to be mapped to the same zero page
On 8/11/20 5:10 AM, linmiaohe wrote:
> Eric Dumazet wrote:
>> On 8/10/20 5:28 AM, Miaohe Lin wrote:
>>> The skb_shared_info part of the data is assigned in the following
>>> loop. It is meaningless to do a memcpy here.
>>>
>>
>> Reminder : net-n
Eric Dumazet wrote:
> On 8/10/20 5:28 AM, Miaohe Lin wrote:
>> The skb_shared_info part of the data is assigned in the following
>> loop. It is meaningless to do a memcpy here.
>>
>
>Reminder : net-next is CLOSED.
>
Thanks for your remind. I would wait for it o
Florian Westphal wrote:
>Miaohe Lin wrote:
>> The skb_shared_info part of the data is assigned in the following loop.
>
>Where?
>
It's at the below for (i = 0; i < nfrags; i++) loop. But I missed something as
Eric Dumazet pointed out.
Sorry about it.
On 8/10/20 5:28 AM, Miaohe Lin wrote:
> The skb_shared_info part of the data is assigned in the following loop. It
> is meaningless to do a memcpy here.
>
> Signed-off-by: Miaohe Lin
> ---
> net/core/skbuff.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --gi
Miaohe Lin wrote:
> The skb_shared_info part of the data is assigned in the following loop.
Where?
For memcpy, the source pages are memset to zero only when --cycles is
used. This leads to wildly different results with or without --cycles,
since all sources pages are likely to be mapped to the same zero page
without explicit writes.
Before this fix:
$ export cmd="./perf stat -e LLC-
The skb_shared_info part of the data is assigned in the following loop. It
is meaningless to do a memcpy here.
Signed-off-by: Miaohe Lin
---
net/core/skbuff.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7e2e502ef519..5b983c9472f5 100644
(struct
> mem_cgroup *memcg,
> new->size = size;
>
> /* Copy thresholds (if any) to new array */
> - if (thresholds->primary) {
> - memcpy(new->entries, thresholds->primary->entries, (size - 1) *
> - sizeof(struct mem
@@ static int __mem_cgroup_usage_register_event(struct
mem_cgroup *memcg,
new->size = size;
/* Copy thresholds (if any) to new array */
- if (thresholds->primary) {
- memcpy(new->entries, thresholds->primary->ent
Hi,
This small series aims to:
1. Make use of the flexible_array_size() helper in a call to memcpy()
2. While there, use the preferred form for passing the size of a structure type
Thanks
Gustavo A. R. Silva (2):
mm: memcontrol: Use flex_array_size() helper in memcpy()
mm: memcontrol: Use
From: "Gustavo A. R. Silva"
Date: Wed, 29 Jul 2020 17:58:03 -0500
> Make use of the flex_array_size() helper to calculate the size of a
> flexible array member within an enclosing structure.
>
> This helper offers defense-in-depth against potential integer
> overflows, while at the same time mak
From: "Gustavo A. R. Silva"
Date: Wed, 29 Jul 2020 22:17:00 -0500
> Make use of the flex_array_size() helper to calculate the size of a
> flexible array member within an enclosing structure.
>
> This helper offers defense-in-depth against potential integer
> overflows, while at the same time mak
e4082cb5f 100644
> >> --- a/sound/core/vmaster.c
> >> +++ b/sound/core/vmaster.c
> >> @@ -262,7 +262,8 @@ int _snd_ctl_add_follower(struct snd_kcontrol *master,
> >> return -ENOMEM;
> >>srec->kctl = follower;
> >>
On 7/30/20 04:21, Ido Schimmel wrote:
> On Wed, Jul 29, 2020 at 05:58:03PM -0500, Gustavo A. R. Silva wrote:
>> Make use of the flex_array_size() helper to calculate the size of a
>> flexible array member within an enclosing structure.
>>
>> This helper offers defense-in-depth against potential
, 1 deletion(-)
>>
>> diff --git a/sound/core/vmaster.c b/sound/core/vmaster.c
>> index ab36f9898711..21ce4082cb5f 100644
>> --- a/sound/core/vmaster.c
>> +++ b/sound/core/vmaster.c
>> @@ -262,7 +262,8 @@ int _snd_ctl_add_follower(struct snd_kcontrol *master,
>
On Wed, Jul 29, 2020 at 05:58:03PM -0500, Gustavo A. R. Silva wrote:
> Make use of the flex_array_size() helper to calculate the size of a
> flexible array member within an enclosing structure.
>
> This helper offers defense-in-depth against potential integer
> overflows, while at the same time ma
36f9898711..21ce4082cb5f 100644
> --- a/sound/core/vmaster.c
> +++ b/sound/core/vmaster.c
> @@ -262,7 +262,8 @@ int _snd_ctl_add_follower(struct snd_kcontrol *master,
> return -ENOMEM;
> srec->kctl = follower;
> srec->follower = *follower;
> -
int tcf_pedit_dump(struct sk_buff *skb, struct
tc_action *a,
return -ENOBUFS;
spin_lock_bh(&p->tcf_lock);
- memcpy(opt->keys, p->tcfp_keys,
- p->tcfp_nkeys * sizeof(struct tc_pedit_key));
+ memcpy(opt->keys, p->tcfp_keys, fle
/staging/wfx/hif_tx_mib.c
@@ -113,7 +113,7 @@ int hif_set_beacon_filter_table(struct wfx_vif *wvif, int
tbl_len,
if (!val)
return -ENOMEM;
val->num_of_info_elmts = cpu_to_le32(tbl_len);
- memcpy(val->ie_table, tbl, tbl_len * sizeof(*tbl));
+ memc
nit(struct mlxsw_sp *mlxsw_sp)
if (!pool)
return -ENOMEM;
mlxsw_sp->counter_pool = pool;
- memcpy(pool->sub_pools, mlxsw_sp_counter_sub_pools,
- sub_pools_count * sizeof(*sub_pool));
pool->sub_pools_count = sub_pools_count;
+
add_conn_list(struct hda_codec *codec, hda_nid_t
nid, int len,
return -ENOMEM;
p->len = len;
p->nid = nid;
- memcpy(p->conns, list, len * sizeof(hda_nid_t));
+ memcpy(p->conns, list, flex_array_size(p, conns, len));
list_add(&
snd_kcontrol *master,
return -ENOMEM;
srec->kctl = follower;
srec->follower = *follower;
- memcpy(srec->follower.vd, follower->vd, follower->count *
sizeof(*follower->vd));
+ memcpy(srec->follower.vd, follower->vd, flex_array
/drivers/scsi/ips.c
index ec85ccce96647..2e6077c502fc7 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -2239,7 +2239,7 @@ ips_get_bios_version(ips_ha_t * ha, int intr)
major = 0;
minor = 0;
- strncpy(ha->bios_version, " ?", 8);
+ memcpy(ha-
g the
benchmark results for this optimized memcpy, but Sam reported the
following with the similar (but now slightly older) cortex-strings version:
* copy_from_user: 13.17%
* copy_to_user: 4.8%
* memcpy: 27.88%
* copy_in_user: Didn't appear in the test results.
This machine will also be us
The Arm-provided memcpy routine has been updated with more recent
optimizations. The kernel's helper functions for copying to/from
user space memory, which import this algorithm and create
exception table entries for instructions that reference user
space, require new recovery code to accur
From: Sam Tebbs
Import the latest memcpy implementation into memcpy,
copy_{from, to and in}_user.
The implementation of the user routines is separated into two forms:
one for when UAO is enabled and one for when UAO is disabled, with
the two being chosen between with a runtime patch.
This avoids
byes - is an extension to the
original intention of fixing an issue reported by an LTP run last
year, where the fixup routine in v2 of this patchset (which was
importing the cortex-strings memcpy implementation) would over-report
the number of bytes that successfully copied.
Version 3 addressed
1 - 100 of 1147 matches
Mail list logo
