diff mbox series

[FFmpeg-devel] x86/yuv2rgb: fix crashes when storing data on unaligned buffers

Message ID 20200713003314.2279-1-jamrial@gmail.com
State Accepted
Commit ba3e771a42c29ee02c34e7769cfc1b2dbc5c760a
Headers show
Series [FFmpeg-devel] x86/yuv2rgb: fix crashes when storing data on unaligned buffers
Related show

Checks

Context Check Description
andriy/default pending
andriy/make success Make finished
andriy/make_fate success Make fate finished

Commit Message

James Almer July 13, 2020, 12:33 a.m. UTC
Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
CPUs.

Fixes ticket #8747

Signed-off-by: James Almer <jamrial@gmail.com>
---
 libswscale/x86/yuv_2_rgb.asm | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

Comments

Carl Eugen Hoyos July 13, 2020, 7:02 a.m. UTC | #1
> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>:
> 
> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
> CPUs.

FFmpeg does not require aligned output buffers on x86_64?

> Fixes ticket #8747

Another issue is described in this ticket that implies an overwrite: Can you reproduce?

Thank you, Carl Eugen
James Almer July 13, 2020, 1:19 p.m. UTC | #2
On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote:
> 
> 
>> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>:
>>
>> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
>> CPUs.
> 
> FFmpeg does not require aligned output buffers on x86_64?

There's no alignment requirement mentioned anywhere in swscale.h, which
explains why every other asm function also uses unaligned mov
instructions when handling src and dst buffers.

> 
>> Fixes ticket #8747
> 
> Another issue is described in this ticket that implies an overwrite: Can you reproduce?

No, I haven't tried that one under valgrind.

> 
> Thank you, Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
Ronald S. Bultje July 13, 2020, 4:55 p.m. UTC | #3
On Mon, Jul 13, 2020 at 3:10 AM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:

>
>
> > Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>:
> >
> > Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3
> enabled
> > CPUs.
>
> FFmpeg does not require aligned output buffers on x86_64?


Not in swscale/avfilter, only in avcodec.

Ronald
Michael Niedermayer July 13, 2020, 6:58 p.m. UTC | #4
On Mon, Jul 13, 2020 at 10:19:07AM -0300, James Almer wrote:
> On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote:
> > 
> > 
> >> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>:
> >>
> >> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
> >> CPUs.
> > 
> > FFmpeg does not require aligned output buffers on x86_64?
> 
> There's no alignment requirement mentioned anywhere in swscale.h, which
> explains why every other asm function also uses unaligned mov
> instructions when handling src and dst buffers.

swscale will print a warning though if its provided with unaligned
buffers or strides
So i would assume that most library users attempt to supply it with
aligned buffers.
Thats something new optimized code could take advantage of

thx

[...]
Carl Eugen Hoyos July 14, 2020, 4:55 p.m. UTC | #5
Am Mo., 13. Juli 2020 um 15:19 Uhr schrieb James Almer <jamrial@gmail.com>:
>
> On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote:
> >
> >
> >> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>:
> >>
> >> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled
> >> CPUs.
> >
> > FFmpeg does not require aligned output buffers on x86_64?
>
> There's no alignment requirement mentioned anywhere in swscale.h, which
> explains why every other asm function also uses unaligned mov
> instructions when handling src and dst buffers.

Thank you both for the explanation, I misremembered.

> >> Fixes ticket #8747
> >
> > Another issue is described in this ticket that implies an overwrite: Can you reproduce?
>
> No, I haven't tried that one under valgrind.

Given that I was unable to produce unaligned buffers for above issue,
this part of the report looked more important to me.

Carl Eugen
diff mbox series

Patch

diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index 575a84d921..003dff1f25 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@ -268,9 +268,9 @@  cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
     por    m2, m7
     por    m1, m6          ; g5  b5  r6  g6  b6  r7  g7  b7  r8  g8  b8  r9  g9  b9  r10 g10
     por    m2, m3          ; b10 r11 g11 b11 r12 g12 b12 r13 g13 b13 r14 g14 b14 r15 g15 b15
-    mova [imageq], m0
-    mova [imageq + 16], m1
-    mova [imageq + 32], m2
+    movu [imageq], m0
+    movu [imageq + 16], m1
+    movu [imageq + 32], m2
 %endif ; mmsize = 16
 %else ; PACK RGB15/16/32
     packuswb m0, m1
@@ -300,10 +300,10 @@  cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
     punpckhwd m_green, m_red
     punpcklwd m5, m6
     punpckhwd m_alpha, m6
-    mova [imageq + 0], m_blue
-    mova [imageq + 8  * time_num], m_green
-    mova [imageq + 16 * time_num], m5
-    mova [imageq + 24 * time_num], m_alpha
+    movu [imageq + 0], m_blue
+    movu [imageq + 8  * time_num], m_green
+    movu [imageq + 16 * time_num], m5
+    movu [imageq + 24 * time_num], m_alpha
 %else ; PACK RGB15/16
 %define depth 2
 %if cpuflag(ssse3)
@@ -342,8 +342,8 @@  cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
     mova m2, m0
     punpcklbw m0, m1
     punpckhbw m2, m1
-    mova [imageq], m0
-    mova [imageq + 8 * time_num], m2
+    movu [imageq], m0
+    movu [imageq + 8 * time_num], m2
 %endif ; PACK RGB15/16
 %endif ; PACK RGB15/16/32