search for: ceski

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c index b9703c0..adb1deb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs, struct work_struct *work; work =

On Wed 2018-05-23 12:54:05, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > > Signed-off-by: Thomas Garnier <thgarnie at google.com> Again, was this

On Wed 2018-05-23 12:54:05, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. > > Signed-off-by: Thomas Garnier <thgarnie at google.com> Again, was this

On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. What testing did this get? > diff --git a/arch/x86/kernel/acpi/wakeup_64.S

On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > Change the assembly code to use only relative references of symbols for the > kernel to be PIE compatible. > > Position Independent Executable (PIE) support will allow to extended the > KASLR randomization range below the -2G memory limit. What testing did this get? > diff --git a/arch/x86/kernel/acpi/wakeup_64.S

On Thu 2018-05-24 09:35:42, Thomas Garnier wrote: > On Thu, May 24, 2018 at 4:03 AM Pavel Machek <pavel at ucw.cz> wrote: > > > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > > > Change the assembly code to use only relative references of symbols for > the > > > kernel to be PIE compatible. > > > > > > Position Independent Executable

On Thu 2018-05-24 09:35:42, Thomas Garnier wrote: > On Thu, May 24, 2018 at 4:03 AM Pavel Machek <pavel at ucw.cz> wrote: > > > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > > > Change the assembly code to use only relative references of symbols for > the > > > kernel to be PIE compatible. > > > > > > Position Independent Executable

On Fri 2018-05-25 10:00:04, Thomas Garnier wrote: > On Fri, May 25, 2018 at 2:14 AM Pavel Machek <pavel at ucw.cz> wrote: > > > On Thu 2018-05-24 09:35:42, Thomas Garnier wrote: > > > On Thu, May 24, 2018 at 4:03 AM Pavel Machek <pavel at ucw.cz> wrote: > > > > > > > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote: > > > > >

BTW: You can pass also the float32 data directly to DirectSound instead of doing the conversion (float32->int16) yourself. Have a look at "WAVEFORMATEXTENSIBLE" in the Windows Platform SDK Tobias Waldvogel -----Ursprüngliche Nachricht----- Von: Martin Cesky [mailto:martin@scssoft.com] Gesendet: Dienstag, 2. April 2002 11:02 An: vorbis-dev@xiph.org Betreff: Re: [vorbis-dev] Ogg

On Tue 07-07-20 10:07:26, Pavel Machek wrote: > Hi! > > > > > > This patch adds logic to the kernel power code to zero out contents of > > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > > > known as S3. > > >

On Tue 07-07-20 10:07:26, Pavel Machek wrote: > Hi! > > > > > > This patch adds logic to the kernel power code to zero out contents of > > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > > > known as S3. > > >

Hi, when mounting an intentionally corrupted btrfs filesystem i get the following warning and bug message. The image can be found here www.cccmz.de/~snakebyte/btrfs.2.img.bck.bz2 [ 297.406152] device fsid e14cf01de423381a-4bd40b603870018a <6>devid 2147483649 transid 9 /dev/loop0 [ 297.411937] ------------[ cut here ]------------ [ 297.412207] WARNING: at fs/btrfs/disk-io.c:805

On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > This patch adds logic to the kernel power code to zero out contents of > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > to any suspend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can

On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > This patch adds logic to the kernel power code to zero out contents of > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > to any suspend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can

Hi! > Cryptographic libraries carry pseudo random number generators to > quickly provide randomness when needed. If such a random pool gets > cloned, secrets may get revealed, as the same random number may get > used multiple times. For fork, this was fixed using the WIPEONFORK > madvise flag [1]. > Unfortunately, the same problem surfaces when a virtual machine gets >

Hi! > Cryptographic libraries carry pseudo random number generators to > quickly provide randomness when needed. If such a random pool gets > cloned, secrets may get revealed, as the same random number may get > used multiple times. For fork, this was fixed using the WIPEONFORK > madvise flag [1]. > Unfortunately, the same problem surfaces when a virtual machine gets >

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have needed like the same amount of time to actual fix the problem. Anyway, for adding a printk:

Hi! Not only it is unneccessarily complex, it is also broken; GFP_ATOMIC allocation can fail.. and then you fail to shut down the machine. Someone please fix this. Thanks, Pavel --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c @@ -120,6 +120,11 @@ nvkm_therm_sensor_event(struct nvkm_therm *therm, enum nvkm_therm_thrs thrs,

Hi! > --- a/Documentation/ABI/testing/sysfs-kernel-slab > +++ b/Documentation/ABI/testing/sysfs-kernel-slab > @@ -347,7 +347,7 @@ Description: > because of fragmentation, SLUB will retry with the minimum order > possible depending on its characteristics. > When debug_guardpage_minorder=N (N > 0) parameter is specified > - (see

Hi! > > Dunno, but kernel-parameters.txt was already quite long... for a file > > that is referenced quite often. Adding admin-guide/ into the path does > > not really help. > > The big string name starts with Documentation/ :) There are some discussions > about changing it to doc/ (or docs/). Also, as you said, kernel-parameters > is already a big name. Perhaps we