This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sun Jan 7 05:00:15 CET 2018
media-tree git hash:e3ee691dbf24096ea51b3200946b11d68ce75361
media_build
On Sat, 6 Jan 2018, Mauro Carvalho Chehab wrote:
> Hi Josef,
>
> Em Sat, 6 Jan 2018 16:04:16 +0100
> "Josef Griebichler" escreveu:
>
> > Hi,
> >
> > the causing commit has been identified.
> > After reverting commit
> >
Hi,
thanks for adding the people involved!
Yes arm and x86 are affected.
Bisecting was not done by me on a x86_64 machine on mainline kernel and not
raspbian kernel
(https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965).
In the mentioned
On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative
Hi Josef,
Em Sat, 6 Jan 2018 16:04:16 +0100
"Josef Griebichler" escreveu:
> Hi,
>
> the causing commit has been identified.
> After reverting commit
>
On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed
It sounds like Coverity was used to produce these patches? If so, is
there a plan to have smatch (hey Dan) or other open source static
analysis tool be possibly enhanced to do a similar type of work?
I'd love for that to happen; the tricky part is being able to have even a
sort of sensible
Le 01/05/18 à 17:09, Dan Williams a écrit :
> Quoting Mark's original RFC:
>
> "Recently, Google Project Zero discovered several classes of attack
> against speculative execution. One of these, known as variant-1, allows
> explicit bounds checks to be bypassed under speculation, providing an
>
Hi Guennadi,
On 04/01/18 18:25, Guennadi Liakhovetski wrote:
> Hi Kieran,
>
> On Wed, 3 Jan 2018, Kieran Bingham wrote:
>
>> From: Kieran Bingham
>>
>> The URB completion operation obtains the current buffer by reading
>> directly into the queue internal
Hi Guennadi,
Thanks for your review,
On 04/01/18 18:24, Guennadi Liakhovetski wrote:
> Hi Kieran,
>
> Just minor suggestions below:
>
> On Wed, 3 Jan 2018, Kieran Bingham wrote:
>
>> From: Kieran Bingham
>>
>> We currently store three separate arrays for each
Hi Guennadi,
Thank you for taking the time to review this series,
On 04/01/18 18:54, Guennadi Liakhovetski wrote:
> On Wed, 3 Jan 2018, Kieran Bingham wrote:
>
>> From: Kieran Bingham
>>
>> Newer high definition cameras, and cameras with multiple lenses such as
On Sat, Jan 6, 2018 at 1:40 AM, Greg KH wrote:
> On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
>> On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
>> > Static analysis reports that 'index' may be a user controlled value that
>> > is used as a
From: Colin Ian King
Don't populate the const read-only array 'cmd' on the stack but instead
make it static. Makes the object code smaller by 38 bytes:
Before:
textdata bss dec hex filename
4950 868 0581816ba fimc-is-regs.o
Am Thu, 21 Dec 2017 21:23:19 +0100
schrieb Daniel Scheller :
> From: Daniel Scheller
>
> As the DVB API is bumped to 5.11 for the next cycle.
>
> dddvb brings a few additional FEC rates (1/4 and 1/3), 64/128/256APSK
> modulations (DVB-S2X) and the
On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote:
> On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
> > Static analysis reports that 'index' may be a user controlled value that
> > is used as a data dependency to read 'pin' from the
> > 'selector->baSourceID' array. In order
On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote:
> Static analysis reports that 'index' may be a user controlled value that
> is used as a data dependency to read 'pin' from the
> 'selector->baSourceID' array. In order to avoid potential leaks of
> kernel memory values, block
16 matches
Mail list logo