[PATCH 3/6] cifs: quit playing games with draining iovecs

... and use ITER_BVEC for the page part of request to send Signed-off-by: Al Viro --- fs/cifs/cifsproto.h | 2 - fs/cifs/transport.c | 141 +++- 2 files changed, 41 insertions(+), 102 deletions(-) diff --git a/fs/cifs/cifsproto.h

[PATCH 4/6] cifs: no need to wank with copying and advancing iovec on recvmsg side either

Signed-off-by: Al Viro --- fs/cifs/cifsglob.h | 2 -- fs/cifs/connect.c | 72 -- 2 files changed, 5 insertions(+), 69 deletions(-) diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index d21da9f..df03c5e 100644 --- a/fs/cifs/cifsglob.h

[PATCH 2/6] cifs: merge the hash calculation helpers

three practically identical copies... Signed-off-by: Al Viro --- fs/cifs/cifsencrypt.c | 97 --- fs/cifs/cifsproto.h | 3 ++ fs/cifs/smb2transport.c | 107 +--- 3 files changed,

[PATCH 1/6] [net] drop 'size' argument of sock_recvmsg()

all callers have it equal to msg_data_left(msg). Signed-off-by: Al Viro --- drivers/target/iscsi/iscsi_target_util.c | 5 ++--- include/linux/net.h | 3 +-- net/socket.c | 23 ++- 3 files changed, 13

[PATCH 2/6] cifs: merge the hash calculation helpers

three practically identical copies... Signed-off-by: Al Viro --- fs/cifs/cifsencrypt.c | 97 --- fs/cifs/cifsproto.h | 3 ++ fs/cifs/smb2transport.c | 107 +--- 3 files changed, 67 insertions(+), 140

[PATCH 1/6] [net] drop 'size' argument of sock_recvmsg()

all callers have it equal to msg_data_left(msg). Signed-off-by: Al Viro --- drivers/target/iscsi/iscsi_target_util.c | 5 ++--- include/linux/net.h | 3 +-- net/socket.c | 23 ++- 3 files changed, 13 insertions(+), 18

[RFC][PATCHSET] reduce messing with iovecs in cifs

Now that sendmsg/recvmsg do not mangle iovecs and are capable of handling bvec-based ->msg_iter, we can seriously reduce the amount of PITA in cifs. The series below is completely untested, and I would appreciate comments/review/testing/etc. I'll post the individual patches in followups;

[RFC][PATCHSET] reduce messing with iovecs in cifs

Now that sendmsg/recvmsg do not mangle iovecs and are capable of handling bvec-based ->msg_iter, we can seriously reduce the amount of PITA in cifs. The series below is completely untested, and I would appreciate comments/review/testing/etc. I'll post the individual patches in followups;

Re: [PATCH] drivers/virtio/virtio_ring.c: Deinline virtqueue_add, save 1016 bytes

On Fri, Apr 08, 2016 at 08:58:44PM +0200, Denys Vlasenko wrote: > This function compiles to 839 bytes of machine code. > In C, it is ~150 lines long. > > This function has 3 callsites. > > Signed-off-by: Denys Vlasenko > CC: "Michael S. Tsirkin" > CC:

Re: [PATCH] drivers/virtio/virtio_ring.c: Deinline virtqueue_add, save 1016 bytes

On Fri, Apr 08, 2016 at 08:58:44PM +0200, Denys Vlasenko wrote: > This function compiles to 839 bytes of machine code. > In C, it is ~150 lines long. > > This function has 3 callsites. > > Signed-off-by: Denys Vlasenko > CC: "Michael S. Tsirkin" > CC: virtualizat...@lists.linux-foundation.org

Re: Kernel stability on baytrail machines

> > I do feel that the importance of the mentioned bug is currently > > underestimated. Can anyone here give a note, how much current linux > > kernel is supposed to be stable on general baytrail machines? > > If you did not get any replies... you might want to check MAINTAINERS file, > and >

Re: Kernel stability on baytrail machines

> > I do feel that the importance of the mentioned bug is currently > > underestimated. Can anyone here give a note, how much current linux > > kernel is supposed to be stable on general baytrail machines? > > If you did not get any replies... you might want to check MAINTAINERS file, > and >

[PATCH] staging: wilc1000: rework comments in wilc_sdio.c

From: Mohammed Billoo Remove unnecessary comments (highlighting sections of functions), make multiline comments into single line comments, and ensure that multiline comments adhere to coding style. --- drivers/staging/wilc1000/wilc_sdio.c | 136

[PATCH] staging: wilc1000: rework comments in wilc_sdio.c

From: Mohammed Billoo Remove unnecessary comments (highlighting sections of functions), make multiline comments into single line comments, and ensure that multiline comments adhere to coding style. --- drivers/staging/wilc1000/wilc_sdio.c | 136 --- 1 file

sched: tweak select_idle_sibling to look for idle threads

select_task_rq_fair() can leave cpu utilization a little lumpy, especially as the workload ramps up to the maximum capacity of the machine. The end result can be high p99 response times as apps wait to get scheduled, even when boxes are mostly idle. I wrote schbench to try and measure this:

sched: tweak select_idle_sibling to look for idle threads

select_task_rq_fair() can leave cpu utilization a little lumpy, especially as the workload ramps up to the maximum capacity of the machine. The end result can be high p99 response times as apps wait to get scheduled, even when boxes are mostly idle. I wrote schbench to try and measure this:

[PATCH] of: Add vendor prefix for Shenzhen Embest Technology

Signed-off-by: Sergio Prado --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index

[PATCH] of: Add vendor prefix for Shenzhen Embest Technology

Signed-off-by: Sergio Prado --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index e52cc8a6b2ae..3d08bafd5669 100644 ---

Клиентские базы тел +79139393506 (tеlеgгam_whatsaрр_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru

Клиентские базы тел +79139393506 (tеlеgгam_whatsapp_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru

Клиентские базы тел +79139393506 (tеlеgгam_whatsaрр_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru

Клиентские базы тел +79139393506 (tеlеgгam_whatsapp_vibег) Skype: prodawez389 Email: prodawez...@yandex.ru

[GIT PULL] libnvdimm fixes for 4.6-rc3

Hi Linus, please pull from:   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive 3 fixes, the first 2 are tagged for -stable. 1/ The ndctl utility/library gained expanded unit tests illuminating a long standing bug in the libnvdimm SMART data retrieval

[GIT PULL] libnvdimm fixes for 4.6-rc3

Hi Linus, please pull from:   git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive 3 fixes, the first 2 are tagged for -stable. 1/ The ndctl utility/library gained expanded unit tests illuminating a long standing bug in the libnvdimm SMART data retrieval

Re: [PATCH v1 00/12] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Sat, Apr 9, 2016 at 7:53 PM, Bryan O'Donoghue wrote: > On Thu, 2016-04-07 at 23:37 +0300, Andy Shevchenko wrote: >> This is combined series of two things: >> - split out the Intel LPSS specific driver from 8250_pci into >> 8250_lpss >> - enable DMA support on

Re: [PATCH v1 00/12] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Sat, Apr 9, 2016 at 7:53 PM, Bryan O'Donoghue wrote: > On Thu, 2016-04-07 at 23:37 +0300, Andy Shevchenko wrote: >> This is combined series of two things: >> - split out the Intel LPSS specific driver from 8250_pci into >> 8250_lpss >> - enable DMA support on Intel Quark UART >> >> The patch

[PATCH] ARM: dts: imx6: Add dts for Embest MarS Board

Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC and with a 4MB SPI flash. [1] http://www.embest-tech.com/shop/star/marsboard.html Signed-off-by: Sergio Prado ---

[PATCH] ARM: dts: imx6: Add dts for Embest MarS Board

Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC and with a 4MB SPI flash. [1] http://www.embest-tech.com/shop/star/marsboard.html Signed-off-by: Sergio Prado --- arch/arm/boot/dts/imx6q-marsboard.dts

Re: [PATCH RFC] select_idle_sibling experiments

On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote: > > On Tue, 2016-04-05 at 14:08 -0400, Chris Mason wrote: > > > Now, on to the patch. I pushed some code around and narrowed the > > problem down to select_idle_sibling() We have cores going into and out > > of idle fast enough

Re: [PATCH RFC] select_idle_sibling experiments

On Wed, Apr 06, 2016 at 09:27:24AM +0200, Mike Galbraith wrote: > > On Tue, 2016-04-05 at 14:08 -0400, Chris Mason wrote: > > > Now, on to the patch. I pushed some code around and narrowed the > > problem down to select_idle_sibling() We have cores going into and out > > of idle fast enough

[GIT PULL] TTY/Serial fixes for 4.6-rc3

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.6-rc3 for you to fetch changes up to

[GIT PULL] TTY/Serial fixes for 4.6-rc3

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-4.6-rc3 for you to fetch changes up to

[GIT PULL] Staging driver fixes for 4.6-rc3

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.6-rc3 for you to fetch changes up to

[GIT PULL] Staging driver fixes for 4.6-rc3

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca: Linux 4.6-rc1 (2016-03-26 16:03:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.6-rc3 for you to fetch changes up to

[GIT PULL] USB driver fixes for 4.6-rc3

The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.6-rc3 for you to fetch changes up to

[GIT PULL] USB driver fixes for 4.6-rc3

The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.6-rc3 for you to fetch changes up to

Re: HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 06, 2016 at 01:11:30PM +0200, Daniel Kiper wrote: > On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote: > > Boris sent out the first HVMLite series of patches to add a new Xen guest > > type > > February 1, 2016 [0]. We've been talking off list with a few folks now over

Re: HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 06, 2016 at 01:11:30PM +0200, Daniel Kiper wrote: > On Wed, Apr 06, 2016 at 04:40:27AM +0200, Luis R. Rodriguez wrote: > > Boris sent out the first HVMLite series of patches to add a new Xen guest > > type > > February 1, 2016 [0]. We've been talking off list with a few folks now over

Re: Kernel crash on startup - bisected to commit 3b24d854cb35

On 04/09/2016 12:33 AM, Eric Dumazet wrote: On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger wrote: Following a recent pull of the wireless-drivers-next repo. my system got a kernel panic on startup at native_apic_msr_write+0x27. The problem was bisected to commit

Re: Kernel crash on startup - bisected to commit 3b24d854cb35

On 04/09/2016 12:33 AM, Eric Dumazet wrote: On Fri, Apr 8, 2016 at 10:28 PM, Larry Finger wrote: Following a recent pull of the wireless-drivers-next repo. my system got a kernel panic on startup at native_apic_msr_write+0x27. The problem was bisected to commit 3b24d854cb35 ("tcp/dccp: do not

Re: [PATCH v1 00/12] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Thu, 2016-04-07 at 23:37 +0300, Andy Shevchenko wrote: > This is combined series of two things: > - split out the Intel LPSS specific driver from 8250_pci into > 8250_lpss > - enable DMA support on Intel Quark UART > > The patch has been tested on few Intel SoCs / platforms. > > This is

Re: [PATCH v1 00/12] serial: 8250: split LPSS to 8250_lpss, enable DMA on Quark

On Thu, 2016-04-07 at 23:37 +0300, Andy Shevchenko wrote: > This is combined series of two things: > - split out the Intel LPSS specific driver from 8250_pci into > 8250_lpss > - enable DMA support on Intel Quark UART > > The patch has been tested on few Intel SoCs / platforms. > > This is

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

Hm, setting gov=performance, and taking the average of 3 30 second interval PkgWatt samples as pipe-test runs.. 714KHz/28.03Ws = 25.46 877KHz/30.28Ws = 28.96 ..for pipe-test, the tradeoff look a bit more like red than green. -Mike

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

Hm, setting gov=performance, and taking the average of 3 30 second interval PkgWatt samples as pipe-test runs.. 714KHz/28.03Ws = 25.46 877KHz/30.28Ws = 28.96 ..for pipe-test, the tradeoff look a bit more like red than green. -Mike

begger help for this comment about intel_cacheinfo.c

in this commit https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/kernel/cpu/intel_cacheinfo.c?id=b2bb85549134c005e997e5a7ed303bda6a1ae738 Mike wrote: > We should not try to save and restore cpus_allowed on current. We can't use > work_on_cpu() here, > since

begger help for this comment about intel_cacheinfo.c

in this commit https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/kernel/cpu/intel_cacheinfo.c?id=b2bb85549134c005e997e5a7ed303bda6a1ae738 Mike wrote: > We should not try to save and restore cpus_allowed on current. We can't use > work_on_cpu() here, > since

Hello....!!

PEASE URGENT RESPONSE, I am Dr Paul Lukas,the Audit and Account Manager (A.D.B)Bank in Ouagadougou Burkina Faso,west africa I have a business transaction for you.In my department i discovered an abandoned Sum of US$10.2 Million Dollars.In an account that belongs to one of our late foreign

Hello....!!

PEASE URGENT RESPONSE, I am Dr Paul Lukas,the Audit and Account Manager (A.D.B)Bank in Ouagadougou Burkina Faso,west africa I have a business transaction for you.In my department i discovered an abandoned Sum of US$10.2 Million Dollars.In an account that belongs to one of our late foreign

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote: > > Yes, I'm familiar with the problem; but simply mandating leaf only nodes > > is not a solution, for the very simple fact that there are tasks in the > > root cgroup that cannot ever be moved out, so we _must_ be able to deal > > with

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote: > > Yes, I'm familiar with the problem; but simply mandating leaf only nodes > > is not a solution, for the very simple fact that there are tasks in the > > root cgroup that cannot ever be moved out, so we _must_ be able to deal > > with

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

Hi! > >> Also, because soon enough we will have to support USB Power Delivery > >> with Type C connector, this is bound to change in the coming months. > >> > >> Frankly, I wanted all of this to be decided in userland with the > >> kernel just providing notification and basic safety checks (we

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

Hi! > >> Also, because soon enough we will have to support USB Power Delivery > >> with Type C connector, this is bound to change in the coming months. > >> > >> Frankly, I wanted all of this to be decided in userland with the > >> kernel just providing notification and basic safety checks (we

Re: Kernel stability on baytrail machines

Hi! > aprox. 6 months ago I started facing random freezes on my baytrail > based computers I manage. It took me a while before I found a bug > report in freedesktop bugzilla named "complete freeze after: > drm/i915/vlv: WA for Turbo and RC6 to work together" - >

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>>What's tricky about patterns is that you need to control 3 (or more) > >>>leds at a time. Problem you are trying to solve here is ... control of > >>>3 leds, at the same time. > >>> > >>>So let's solve them together. > >> > >>OK, now I've got your point. So we'd need to have a means for

Re: Kernel stability on baytrail machines

Hi! > aprox. 6 months ago I started facing random freezes on my baytrail > based computers I manage. It took me a while before I found a bug > report in freedesktop bugzilla named "complete freeze after: > drm/i915/vlv: WA for Turbo and RC6 to work together" - >

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

Hi! > >>>What's tricky about patterns is that you need to control 3 (or more) > >>>leds at a time. Problem you are trying to solve here is ... control of > >>>3 leds, at the same time. > >>> > >>>So let's solve them together. > >> > >>OK, now I've got your point. So we'd need to have a means for

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

> It looks like I'm in quite a pickle. Even if the patch for the PnPBIOS > driver removes the errors and warnings, there may be runtime bugs in > other drivers expecting X86_32. The only way I can see to prevent that > is to audit all the drivers which depend on the ISA option -- a behemoth >

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

> It looks like I'm in quite a pickle. Even if the patch for the PnPBIOS > driver removes the errors and warnings, there may be runtime bugs in > other drivers expecting X86_32. The only way I can see to prevent that > is to audit all the drivers which depend on the ISA option -- a behemoth >

По поводу изготовления наружной рекламы

Здравствуйте! Не так давно я проходил мимо Вашего здания, и заметил, что на фасаде здания нет вывески Вашей организации. Я профессионально занимаюсь производством и установкой вывесок (у нас своя мастерская). Размещение рекламных вывесок в Вашем здании разрешено. Поток привлеченных клиентов

По поводу изготовления наружной рекламы

Здравствуйте! Не так давно я проходил мимо Вашего здания, и заметил, что на фасаде здания нет вывески Вашей организации. Я профессионально занимаюсь производством и установкой вывесок (у нас своя мастерская). Размещение рекламных вывесок в Вашем здании разрешено. Поток привлеченных клиентов

Re: [Intel-gfx] [PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

There's already a patch in the works for this: https://patchwork.freedesktop.org/patch/80078/ Regards, Matt

Re: [Intel-gfx] [PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

There's already a patch in the works for this: https://patchwork.freedesktop.org/patch/80078/ Regards, Matt

[PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

From: Andi Kleen When I run chrome on my opensuse system every time I open a new tab the system log is spammed with: audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e syscall=273 compat=0

[PATCH] Don't audit SECCOMP_KILL/RET_ERRNO when syscall auditing is disabled

From: Andi Kleen When I run chrome on my opensuse system every time I open a new tab the system log is spammed with: audit[16857]: SECCOMP auid=1000 uid=1000 gid=100 ses=1 pid=16857 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 arch=c03e syscall=273 compat=0 ip=0x7fe27c11a444

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

On Sat, 2016-04-09 at 14:33 +0200, Rafael J. Wysocki wrote: > On Sat, Apr 9, 2016 at 8:40 AM, Mike Galbraith > wrote: > > On Fri, 2016-04-08 at 22:59 +0200, Rafael J. Wysocki wrote: > > > On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote: > > > > On Fri,

Re: [regression] cross core scheduling frequency drop bisected to 0c313cb20732

On Sat, 2016-04-09 at 14:33 +0200, Rafael J. Wysocki wrote: > On Sat, Apr 9, 2016 at 8:40 AM, Mike Galbraith > wrote: > > On Fri, 2016-04-08 at 22:59 +0200, Rafael J. Wysocki wrote: > > > On Friday, April 08, 2016 08:50:54 AM Mike Galbraith wrote: > > > > On Fri, 2016-04-08 at 08:45 +0200, Peter

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

On 04/08/2016 06:12 PM, Jose Abreu wrote: [...] >> >> [...] >>> +- adi,enable-audio: If set the ADV7511 driver will register a codec >>> interface >>> + into ALSA SoC. >> This is not a description of the hardware. > > Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511 >

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

On 04/08/2016 06:12 PM, Jose Abreu wrote: [...] >> >> [...] >>> +- adi,enable-audio: If set the ADV7511 driver will register a codec >>> interface >>> + into ALSA SoC. >> This is not a description of the hardware. > > Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511 >

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

"H. Peter Anvin" writes: > On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes > wrote: >> >>> If anyone has a better idea on how userspace should connect the >>master >>> pty file descriptor the slave file descriptor, I would be willing to >>>

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

"H. Peter Anvin" writes: > On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes > wrote: >> >>> If anyone has a better idea on how userspace should connect the >>master >>> pty file descriptor the slave file descriptor, I would be willing to >>> implement that instead. >> >>If we are willing

Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

On 04/08/2016 06:08 PM, Jose Abreu wrote: > Hi Lars, > > > On 08-04-2016 16:52, Lars-Peter Clausen wrote: >> On 04/08/2016 12:06 PM, Jose Abreu wrote: >>> Hi Mark, >>> >>> >>> On 07-04-2016 18:53, Mark Brown wrote: On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote: > +

Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

On 04/08/2016 06:08 PM, Jose Abreu wrote: > Hi Lars, > > > On 08-04-2016 16:52, Lars-Peter Clausen wrote: >> On 04/08/2016 12:06 PM, Jose Abreu wrote: >>> Hi Mark, >>> >>> >>> On 07-04-2016 18:53, Mark Brown wrote: On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote: > +

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes wrote: > >> If anyone has a better idea on how userspace should connect the >master >> pty file descriptor the slave file descriptor, I would be willing to >> implement that instead. > >If we are willing to go away

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes wrote: > >> If anyone has a better idea on how userspace should connect the >master >> pty file descriptor the slave file descriptor, I would be willing to >> implement that instead. > >If we are willing to go away from the existing mess of a

Re: [PATCH] leftpad.2: Document new syscall

Am 08.04.2016 um 20:10 schrieb Heinrich Schuchardt: > On 04/01/2016 12:33 AM, Richard Weinberger wrote: >> From: Daniel Walter >> >> Signed-off-by: Daniel Walter >> Signed-off-by: Richard Weinberger >> --- >> man2/leftpad.2 | 55

Re: [PATCH] leftpad.2: Document new syscall

Am 08.04.2016 um 20:10 schrieb Heinrich Schuchardt: > On 04/01/2016 12:33 AM, Richard Weinberger wrote: >> From: Daniel Walter >> >> Signed-off-by: Daniel Walter >> Signed-off-by: Richard Weinberger >> --- >> man2/leftpad.2 | 55 +++ >> 1

Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

Tetsuo Handa wrote: > There is no reason to add this patch which handles the slowpath right now. Oops. There is no reason _not_ to add this patch which handles the slowpath right now.

Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

Tetsuo Handa wrote: > There is no reason to add this patch which handles the slowpath right now. Oops. There is no reason _not_ to add this patch which handles the slowpath right now.

Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

Michal Hocko wrote: > On Wed 17-02-16 19:34:46, Tetsuo Handa wrote: > > >From 6f07b71c97766ec111d26c3424bded465ca48195 Mon Sep 17 00:00:00 2001 > > From: Tetsuo Handa > > Date: Wed, 17 Feb 2016 16:37:01 +0900 > > Subject: [PATCH 5/6] mm,oom: Re-enable OOM

Re: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers.

Michal Hocko wrote: > On Wed 17-02-16 19:34:46, Tetsuo Handa wrote: > > >From 6f07b71c97766ec111d26c3424bded465ca48195 Mon Sep 17 00:00:00 2001 > > From: Tetsuo Handa > > Date: Wed, 17 Feb 2016 16:37:01 +0900 > > Subject: [PATCH 5/6] mm,oom: Re-enable OOM killer using timers. > > > > We are

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

On Sat, Apr 09, 2016 at 01:58:14PM +0100, One Thousand Gnomes wrote: >> I believe this is the source of the issues I encountered on my initial >> attempt to decouple the X86_32 dependency from the ISA option. I suspect >> if I add an explicit X86_32 dependency to the PNPBIOS driver, I will be >>

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

On Sat, Apr 09, 2016 at 01:58:14PM +0100, One Thousand Gnomes wrote: >> I believe this is the source of the issues I encountered on my initial >> attempt to decouple the X86_32 dependency from the ISA option. I suspect >> if I add an explicit X86_32 dependency to the PNPBIOS driver, I will be >>

Re: [PATCH 0/2] perf probe fixes for ppc64le

On 2016/04/08 04:57PM, Balbir Singh wrote: > On Thu, 2016-04-07 at 14:56 +0530, Naveen N. Rao wrote: > > On 2016/04/07 06:19PM, Balbir Singh wrote: > > >  > > >  > > > On 06/04/16 22:32, Naveen N. Rao wrote: > > > >  > > > > This patchset fixes three issues found with perf probe on ppc64le: > > >

Re: [PATCH 0/2] perf probe fixes for ppc64le

On 2016/04/08 04:57PM, Balbir Singh wrote: > On Thu, 2016-04-07 at 14:56 +0530, Naveen N. Rao wrote: > > On 2016/04/07 06:19PM, Balbir Singh wrote: > > >  > > >  > > > On 06/04/16 22:32, Naveen N. Rao wrote: > > > >  > > > > This patchset fixes three issues found with perf probe on ppc64le: > > >

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote: > > > Widely diverging from > > > CPU's behavior, IO grouped all internal tasks into an internal leaf > > > node and used to assign a fixed weight to it. > > > > That's just plain broken... That is not how a proportional weight based > >

Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP

On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote: > > > Widely diverging from > > > CPU's behavior, IO grouped all internal tasks into an internal leaf > > > node and used to assign a fixed weight to it. > > > > That's just plain broken... That is not how a proportional weight based > >

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote: > > In any case, I just realized we do not in fact provide this guarantee > > (of pointing to a blocked task) that needs a bit more work. > > Current patch calls rt_mutex_adjust_prio() before wake_up_q() the > wakee, at that moment the

Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

On Sat, Apr 09, 2016 at 11:25:39AM +0800, Xunlei Pang wrote: > > In any case, I just realized we do not in fact provide this guarantee > > (of pointing to a blocked task) that needs a bit more work. > > Current patch calls rt_mutex_adjust_prio() before wake_up_q() the > wakee, at that moment the

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

> If anyone has a better idea on how userspace should connect the master > pty file descriptor the slave file descriptor, I would be willing to > implement that instead. If we are willing to go away from the existing mess of a tty interface inflicted on us by BSD and then mashed up by POSIX then

Re: [PATCH 01/13] devpts: Teach /dev/ptmx to find the associated devpts via path lookup

> If anyone has a better idea on how userspace should connect the master > pty file descriptor the slave file descriptor, I would be willing to > implement that instead. If we are willing to go away from the existing mess of a tty interface inflicted on us by BSD and then mashed up by POSIX then

[PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

From: Enpeng Xu Signed-off-by: Enpeng Xu --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 49e4f26..527eca7 100644

[PATCH] fix bug in function gen8_ppgtt_clear_range, passed wrong ptr to kunmap_px.

From: Enpeng Xu Signed-off-by: Enpeng Xu --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 49e4f26..527eca7 100644 ---

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

> I believe this is the source of the issues I encountered on my initial > attempt to decouple the X86_32 dependency from the ISA option. I suspect > if I add an explicit X86_32 dependency to the PNPBIOS driver, I will be > able to remove the X86_32 dependency from the ISA option without >

Re: [PATCH 04/10] iio: stx104: Change STX104 dependency to ISA_BUS

> I believe this is the source of the issues I encountered on my initial > attempt to decouple the X86_32 dependency from the ISA option. I suspect > if I add an explicit X86_32 dependency to the PNPBIOS driver, I will be > able to remove the X86_32 dependency from the ISA option without >

[PATCH 2/4] sigaltstack: preparations for adding new SS_xxx flags

This patch adds SS_FLAG_BITS - the mask that splits sigaltstack mode values and bit-flags. Since there is no bit-flags yet, the mask is defined to 0. The flags are added by subsequent patches. With every new flag, the mask should have the appropriate bit cleared. This makes sure if some flag is

[PATCH 1/4] [Cleanup] x86: signal: unify the sigaltstack check with other arches

Currently x86's get_sigframe() checks for "current->sas_ss_size" to determine whether there is a need to switch to sigaltstack. The common practice used by all other arches is to check for sas_ss_flags(sp) == 0 This patch makes the code consistent with other arches. The slight complexity of the

[PATCH 2/4] sigaltstack: preparations for adding new SS_xxx flags

This patch adds SS_FLAG_BITS - the mask that splits sigaltstack mode values and bit-flags. Since there is no bit-flags yet, the mask is defined to 0. The flags are added by subsequent patches. With every new flag, the mask should have the appropriate bit cleared. This makes sure if some flag is

[PATCH 1/4] [Cleanup] x86: signal: unify the sigaltstack check with other arches

Currently x86's get_sigframe() checks for "current->sas_ss_size" to determine whether there is a need to switch to sigaltstack. The common practice used by all other arches is to check for sas_ss_flags(sp) == 0 This patch makes the code consistent with other arches. The slight complexity of the

[PATCH 4/4] selftests: Add test for sigaltstack(SS_ONSTACK|SS_AUTODISARM)

This patch adds the test case for SS_AUTODISARM flag. The test-case tries to set SS_AUTODISARM flag and checks if the nested signal corrupts the stack after swapcontext(). CC: Shuah Khan CC: linux-kernel@vger.kernel.org CC: linux-...@vger.kernel.org CC: Andy Lutomirski

[PATCH v6(RESEND) 0/4] make sigaltstack() compatible with swapcontext()

It is absolutely unclear what happened with my patch series, but it is neither applied nor rejected. So here's the re-send. The following patches make it possible to use swapcontext() in a sighandler that works on sigaltstack. The approach is inspired by Andy Lutomirski's suggestion that

[PATCH 3/4] sigaltstack: implement SS_AUTODISARM flag

This patch implements the SS_AUTODISARM flag that can be ORed with SS_ONSTACK when forming ss_flags. When this flag is set, sigaltstack will be disabled when entering the signal handler; more precisely, after saving sas to uc_stack. When leaving the signal handler, the sigaltstack is restored by

[PATCH 4/4] selftests: Add test for sigaltstack(SS_ONSTACK|SS_AUTODISARM)

This patch adds the test case for SS_AUTODISARM flag. The test-case tries to set SS_AUTODISARM flag and checks if the nested signal corrupts the stack after swapcontext(). CC: Shuah Khan CC: linux-kernel@vger.kernel.org CC: linux-...@vger.kernel.org CC: Andy Lutomirski Signed-off-by: Stas

<    1   2   3   >