Re: [PATCH v4 5/5] staging/android: add flags member to sync ioctl structs

On 27 February 2016 at 15:27, Gustavo Padovan wrote: > Hi Emil, > > 2016-02-27 Emil Velikov : > >> Hi Gustavo, >> >> On 26 February 2016 at 18:31, Gustavo Padovan wrote: >> > From: Gustavo Padovan

Re: [PATCH v4 5/5] staging/android: add flags member to sync ioctl structs

On 27 February 2016 at 15:27, Gustavo Padovan wrote: > Hi Emil, > > 2016-02-27 Emil Velikov : > >> Hi Gustavo, >> >> On 26 February 2016 at 18:31, Gustavo Padovan wrote: >> > From: Gustavo Padovan >> > >> > Play safe and add flags member to all structs. So we don't need to >> > break API or

Re: [PATCH v2] signals, pkeys: make si_pkey 32 bits

* Stephen Rothwell wrote: > In order to prevent a change of alignment of the _sifields union in the > siginfo structure on (some) 32 bit platforms and an ABI breakage, we > change the type of _pkey to unsigned int. If more bits are needed in > the future, a second

Re: [PATCH v2] signals, pkeys: make si_pkey 32 bits

* Stephen Rothwell wrote: > In order to prevent a change of alignment of the _sifields union in the > siginfo structure on (some) 32 bit platforms and an ABI breakage, we > change the type of _pkey to unsigned int. If more bits are needed in > the future, a second unsigned int could be added.

Re: linux-next: manual merge of the iommu tree with the samsung-krzk tree

Hi Stephen, On Mon, Feb 29, 2016 at 03:20:55PM +1100, Stephen Rothwell wrote: > Hi Joerg, > > Today's linux-next merge of the iommu tree got a conflict in: > > drivers/memory/Kconfig > > between commit: > > 78fbb9361ca3 ("memory: Add support for Exynos SROM driver") > > from the

Re: linux-next: manual merge of the iommu tree with the samsung-krzk tree

Hi Stephen, On Mon, Feb 29, 2016 at 03:20:55PM +1100, Stephen Rothwell wrote: > Hi Joerg, > > Today's linux-next merge of the iommu tree got a conflict in: > > drivers/memory/Kconfig > > between commit: > > 78fbb9361ca3 ("memory: Add support for Exynos SROM driver") > > from the

Re: [PATCH] mm: __delete_from_page_cache WARN_ON(page_mapped)

2016-02-29 13:49 GMT+09:00 Hugh Dickins : > Commit e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() > for compound pages") changed the famous BUG_ON(page_mapped(page)) in > __delete_from_page_cache() to VM_BUG_ON_PAGE(page_mapped(page)): which > gives us more

Re: [PATCH] mm: __delete_from_page_cache WARN_ON(page_mapped)

2016-02-29 13:49 GMT+09:00 Hugh Dickins : > Commit e1534ae95004 ("mm: differentiate page_mapped() from page_mapcount() > for compound pages") changed the famous BUG_ON(page_mapped(page)) in > __delete_from_page_cache() to VM_BUG_ON_PAGE(page_mapped(page)): which > gives us more info when

Re: log spammed with "loading xx failed with error -2" since commit e40ba6d56b [replace call to fw_read_file_contents() with kernel version]

On Sun, 28 Feb 2016, Luis R. Rodriguez wrote: > >From e63d19975787c0e237a47c17efd01e41b2a8e2fa Mon Sep 17 00:00:00 2001 > From: "Luis R. Rodriguez" > Date: Sat, 27 Feb 2016 14:58:08 -0800 > Subject: [PATCH] firmware: change kernel read fail to dev_dbg() > Applied to

Re: log spammed with "loading xx failed with error -2" since commit e40ba6d56b [replace call to fw_read_file_contents() with kernel version]

On Sun, 28 Feb 2016, Luis R. Rodriguez wrote: > >From e63d19975787c0e237a47c17efd01e41b2a8e2fa Mon Sep 17 00:00:00 2001 > From: "Luis R. Rodriguez" > Date: Sat, 27 Feb 2016 14:58:08 -0800 > Subject: [PATCH] firmware: change kernel read fail to dev_dbg() > Applied to

Re: [PATCH] [RFC] mm/page_ref, crypto/async_pq: don't put_page from __exit

2016-02-29 6:57 GMT+09:00 Arnd Bergmann : > The addition of tracepoints to the page reference tracking had an > unfortunate side-effect in at least one driver that calls put_page > from its exit function, resulting in a link error: > > `.exit.text' referenced in section

Re: [PATCH] [RFC] mm/page_ref, crypto/async_pq: don't put_page from __exit

2016-02-29 6:57 GMT+09:00 Arnd Bergmann : > The addition of tracepoints to the page reference tracking had an > unfortunate side-effect in at least one driver that calls put_page > from its exit function, resulting in a link error: > > `.exit.text' referenced in section `__jump_table' of

Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2]

On 02/26/2016, 08:59 PM, Robert Święcki wrote: > It happens only with 0x6000832 ucode, and Piledriver-based CPUs: i.e. > newer AMD FX, and Opteron 300 series (4300, 6300 etc.). Ok, I can confirm this is: AMD Opteron(tm) Processor 6348 And: microcode: CPU0: patch_level=0x06000836 Thank all the

Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2]

On 02/26/2016, 08:59 PM, Robert Święcki wrote: > It happens only with 0x6000832 ucode, and Piledriver-based CPUs: i.e. > newer AMD FX, and Opteron 300 series (4300, 6300 etc.). Ok, I can confirm this is: AMD Opteron(tm) Processor 6348 And: microcode: CPU0: patch_level=0x06000836 Thank all the

Re: [PATCH v5] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Fri, Feb 26, 2016 at 11:29:52AM +0100, Borislav Petkov wrote: > On Fri, Feb 26, 2016 at 11:18:28AM +0100, Thomas Gleixner wrote: > > On Fri, 26 Feb 2016, Huang Rui wrote: > > > +/* Event code: LSB 8 bits, passed in attr->config any other bit is > > > reserved. */ > > > +#define

Re: [PATCH v5] perf/x86/amd/power: Add AMD accumulated power reporting mechanism

On Fri, Feb 26, 2016 at 11:29:52AM +0100, Borislav Petkov wrote: > On Fri, Feb 26, 2016 at 11:18:28AM +0100, Thomas Gleixner wrote: > > On Fri, 26 Feb 2016, Huang Rui wrote: > > > +/* Event code: LSB 8 bits, passed in attr->config any other bit is > > > reserved. */ > > > +#define

[PATCH] PCI: PTM preliminary implementation

Simplified Precision Time Measurement driver, activates PTM feature if a PCIe PTM requester (as per PCI Express 3.1 Base Specification section 7.32)is found, but not before checking if the rest of the PCI hierarchy can support it. The driver does not take part in facilitating PTM conversations,

[RFC] PCI: PTM Driver

Hello LKML, This is a preliminary implementation of the PTM[1] support driver, the code is obviously hacked together and in need of refactoring. This driver has only been tested against a virtual PCI bus. The drivers job is to get to every PTM capable device, set some PCI config space bits, then

[PATCH] PCI: PTM preliminary implementation

Simplified Precision Time Measurement driver, activates PTM feature if a PCIe PTM requester (as per PCI Express 3.1 Base Specification section 7.32)is found, but not before checking if the rest of the PCI hierarchy can support it. The driver does not take part in facilitating PTM conversations,

[RFC] PCI: PTM Driver

Hello LKML, This is a preliminary implementation of the PTM[1] support driver, the code is obviously hacked together and in need of refactoring. This driver has only been tested against a virtual PCI bus. The drivers job is to get to every PTM capable device, set some PCI config space bits, then

Re: [GIT PULL] tpmdd fix

On Fri, 26 Feb 2016, Jarkko Sakkinen wrote: > Hi James, > > this is the fix for the build warning. > > /Jarkko > > The following changes since commit 481873d06f2bf2ad732450a3a5fa5b8c2a07ef88: > > Merge branch 'next' of > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

[RFC] PCI: PTM Driver

Hello LKML, This is a preliminary implementation of the PTM[1] support driver, the code is obviously hacked together and in need of refactoring. This driver has only been tested against a virtual PCI bus. The drivers job is to get to every PTM capable device, set some PCI config space bits, then

Re: [GIT PULL] tpmdd fix

On Fri, 26 Feb 2016, Jarkko Sakkinen wrote: > Hi James, > > this is the fix for the build warning. > > /Jarkko > > The following changes since commit 481873d06f2bf2ad732450a3a5fa5b8c2a07ef88: > > Merge branch 'next' of > git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity

[RFC] PCI: PTM Driver

Hello LKML, This is a preliminary implementation of the PTM[1] support driver, the code is obviously hacked together and in need of refactoring. This driver has only been tested against a virtual PCI bus. The drivers job is to get to every PTM capable device, set some PCI config space bits, then

Re: [PATCH 8/9] powerpc: simplify csum_add(a, b) in case a or b is constant 0

Le 23/10/2015 05:33, Scott Wood a écrit : On Tue, 2015-09-22 at 16:34 +0200, Christophe Leroy wrote: Simplify csum_add(a, b) in case a or b is constant 0 Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/checksum.h | 6 ++ 1 file changed, 6

Re: [PATCH 8/9] powerpc: simplify csum_add(a, b) in case a or b is constant 0

Le 23/10/2015 05:33, Scott Wood a écrit : On Tue, 2015-09-22 at 16:34 +0200, Christophe Leroy wrote: Simplify csum_add(a, b) in case a or b is constant 0 Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/checksum.h | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [PATCH 4/9] powerpc: inline ip_fast_csum()

Le 23/09/2015 07:43, Denis Kirjanov a écrit : On 9/22/15, Christophe Leroy wrote: In several architectures, ip_fast_csum() is inlined There are functions like ip_send_check() which do nothing much more than calling ip_fast_csum(). Inlining ip_fast_csum() allows the

Re: [PATCH 4/9] powerpc: inline ip_fast_csum()

Le 23/09/2015 07:43, Denis Kirjanov a écrit : On 9/22/15, Christophe Leroy wrote: In several architectures, ip_fast_csum() is inlined There are functions like ip_send_check() which do nothing much more than calling ip_fast_csum(). Inlining ip_fast_csum() allows the compiler to optimise

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Mon, Feb 29, 2016 at 3:03 AM, Hugh Dickins wrote: > On Fri, 19 Feb 2016, Andrew Morton wrote: >> On Fri, 19 Feb 2016 09:40:45 +0300 Konstantin Khlebnikov >> wrote: >> >> > >> What are your thoughts on this? >> > > >> > > My thoughts are NAK. A misleading

Re: [RFC PATCH] proc: do not include shmem and driver pages in /proc/meminfo::Cached

On Mon, Feb 29, 2016 at 3:03 AM, Hugh Dickins wrote: > On Fri, 19 Feb 2016, Andrew Morton wrote: >> On Fri, 19 Feb 2016 09:40:45 +0300 Konstantin Khlebnikov >> wrote: >> >> > >> What are your thoughts on this? >> > > >> > > My thoughts are NAK. A misleading stat is not so bad as a >> > >

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

29.02.2016 00:13, Stas Sergeev пишет: 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

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

29.02.2016 00:13, Stas Sergeev пишет: 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

Re: [PATCH v10 2/2] cpufreq: powernv: Add sysfs attributes to show throttle stats

On 26-02-16, 16:06, Shilpasri G Bhat wrote: > +static int powernv_cpufreq_policy_notifier(struct notifier_block *nb, > +unsigned long action, void *data) > +{ > + struct cpufreq_policy *policy = data; > + int ret; > + > + if (action ==

linux-next: manual merge of the target-merge tree with the net-next tree

Hi Nicholas, Today's linux-next merge of the target-merge tree got a conflict in: drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h between commit: ba9cee6aa67d ("cxgb4/iw_cxgb4: TOS support") from the net-next tree and commit: c973e2a3ff1b ("cxgb4: add definitions for iSCSI target ULD")

Re: [PATCH v10 2/2] cpufreq: powernv: Add sysfs attributes to show throttle stats

On 26-02-16, 16:06, Shilpasri G Bhat wrote: > +static int powernv_cpufreq_policy_notifier(struct notifier_block *nb, > +unsigned long action, void *data) > +{ > + struct cpufreq_policy *policy = data; > + int ret; > + > + if (action ==

linux-next: manual merge of the target-merge tree with the net-next tree

Hi Nicholas, Today's linux-next merge of the target-merge tree got a conflict in: drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h between commit: ba9cee6aa67d ("cxgb4/iw_cxgb4: TOS support") from the net-next tree and commit: c973e2a3ff1b ("cxgb4: add definitions for iSCSI target ULD")

Re: [PATCH] mm/zsmalloc: add compact column to pool stat

Hello, On (02/29/16 15:02), Minchan Kim wrote: > On Sat, Feb 27, 2016 at 03:23:53PM +0900, Sergey Senozhatsky wrote: > > Add a new column to pool stats, which will tell us class' zs_can_compact() > > number, so it will be easier to analyze zsmalloc fragmentation. > > Just nitpick: > > Strictly

Re: [PATCH] mm/zsmalloc: add compact column to pool stat

Hello, On (02/29/16 15:02), Minchan Kim wrote: > On Sat, Feb 27, 2016 at 03:23:53PM +0900, Sergey Senozhatsky wrote: > > Add a new column to pool stats, which will tell us class' zs_can_compact() > > number, so it will be easier to analyze zsmalloc fragmentation. > > Just nitpick: > > Strictly

Re: [PATCH] mm/zsmalloc: add compact column to pool stat

On Sat, Feb 27, 2016 at 03:23:53PM +0900, Sergey Senozhatsky wrote: > Add a new column to pool stats, which will tell us class' zs_can_compact() > number, so it will be easier to analyze zsmalloc fragmentation. Just nitpick: Strictly speaking, zs_can_compact number is number of "ideal freeable

Re: [PATCH] mm/zsmalloc: add compact column to pool stat

On Sat, Feb 27, 2016 at 03:23:53PM +0900, Sergey Senozhatsky wrote: > Add a new column to pool stats, which will tell us class' zs_can_compact() > number, so it will be easier to analyze zsmalloc fragmentation. Just nitpick: Strictly speaking, zs_can_compact number is number of "ideal freeable

Re: [PATCH] asm-generic: remove old nonatomic-io wrapper files

On Fri, Feb 26, 2016 at 03:29:05PM +0100, Arnd Bergmann wrote: > The two header files got moved to include/linux, and most > users were already converted, this changes the remaining drivers > and removes the files. > > Signed-off-by: Arnd Bergmann > --- > drivers/dma/idma64.h

Re: [PATCH] asm-generic: remove old nonatomic-io wrapper files

On Fri, Feb 26, 2016 at 03:29:05PM +0100, Arnd Bergmann wrote: > The two header files got moved to include/linux, and most > users were already converted, this changes the remaining drivers > and removes the files. > > Signed-off-by: Arnd Bergmann > --- > drivers/dma/idma64.h

Re: [PATCH v3 22/22] sound/usb: Use Media Controller API to share media resources

On 02/27/2016 12:48 AM, Takashi Iwai wrote: > On Sat, 27 Feb 2016 03:55:39 +0100, > Shuah Khan wrote: >> >> On 02/26/2016 01:50 PM, Takashi Iwai wrote: >>> On Fri, 26 Feb 2016 21:08:43 +0100, >>> Shuah Khan wrote: On 02/26/2016 12:55 PM, Takashi Iwai wrote: > On Fri, 12 Feb 2016

Re: [PATCH v3 22/22] sound/usb: Use Media Controller API to share media resources

On 02/27/2016 12:48 AM, Takashi Iwai wrote: > On Sat, 27 Feb 2016 03:55:39 +0100, > Shuah Khan wrote: >> >> On 02/26/2016 01:50 PM, Takashi Iwai wrote: >>> On Fri, 26 Feb 2016 21:08:43 +0100, >>> Shuah Khan wrote: On 02/26/2016 12:55 PM, Takashi Iwai wrote: > On Fri, 12 Feb 2016

[PATCH v4 22/22] sound/usb: Use Media Controller API to share media resources

Change ALSA driver to use Media Controller API to share media resources with DVB and V4L2 drivers on a AU0828 media device. Media Controller specific initialization is done after sound card is registered. ALSA creates Media interface and entity function graph nodes for Control, Mixer, PCM

[PATCH v4 22/22] sound/usb: Use Media Controller API to share media resources

Change ALSA driver to use Media Controller API to share media resources with DVB and V4L2 drivers on a AU0828 media device. Media Controller specific initialization is done after sound card is registered. ALSA creates Media interface and entity function graph nodes for Control, Mixer, PCM

[PATCH] phy: Fix armada375 compile test build on UM

The phy-armada375-usb2 driver uses IOMEM functions so COMPILE_TEST && OF build failed with: drivers/built-in.o: In function `armada375_usb_phy_probe': phy-armada375-usb2.c:(.text+0x121d): undefined reference to `devm_ioremap_resource' Signed-off-by: Krzysztof Kozlowski

[PATCH] phy: Fix armada375 compile test build on UM

The phy-armada375-usb2 driver uses IOMEM functions so COMPILE_TEST && OF build failed with: drivers/built-in.o: In function `armada375_usb_phy_probe': phy-armada375-usb2.c:(.text+0x121d): undefined reference to `devm_ioremap_resource' Signed-off-by: Krzysztof Kozlowski --- drivers/phy/Kconfig

[GIT PULL] extcon next for 4.6

Dear Greg, This is extcon-next pull request for v4.6. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24

[GIT PULL] extcon next for 4.6

Dear Greg, This is extcon-next pull request for v4.6. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24

Re: [PATCH v6 00/12] Add T210 support in Tegra soctherm

Hi, Does anyone have comments on this series? Thanks. Wei. On 2016年02月22日 16:05, Wei Ni wrote: > This patchset adds following functions for tegra_soctherm driver: > 1. add T210 support. > 2. export debugfs to show some registers. > 3. add thermtrip funciton. > 4. add suspend/resume function. >

Re: [PATCH v6 00/12] Add T210 support in Tegra soctherm

Hi, Does anyone have comments on this series? Thanks. Wei. On 2016年02月22日 16:05, Wei Ni wrote: > This patchset adds following functions for tegra_soctherm driver: > 1. add T210 support. > 2. export debugfs to show some registers. > 3. add thermtrip funciton. > 4. add suspend/resume function. >

Re: [PATCH 01/10] fs crypto: add basic definitions for per-file encryption

On 02/25/16 11:25, Jaegeuk Kim wrote: > This patch adds definitions for per-file encryption used by ext4 and f2fs. > > Signed-off-by: Jaegeuk Kim > --- > include/linux/fs.h | 8 ++ > include/linux/fscrypto.h | 239 > +++ >

Re: [PATCH 01/10] fs crypto: add basic definitions for per-file encryption

On 02/25/16 11:25, Jaegeuk Kim wrote: > This patch adds definitions for per-file encryption used by ext4 and f2fs. > > Signed-off-by: Jaegeuk Kim > --- > include/linux/fs.h | 8 ++ > include/linux/fscrypto.h | 239 > +++ >

Re: [PATCH 06/10] fs crypto: add Makefile and Kconfig

On 02/25/16 11:26, Jaegeuk Kim wrote: > This patch adds a facility to enable per-file encryption. > > Arnd fixes a missing CONFIG_BLOCK check in the original patch. > "The newly added generic crypto abstraction for file systems operates > on 'struct bio' objects, which do not exist when

Re: [PATCH 06/10] fs crypto: add Makefile and Kconfig

On 02/25/16 11:26, Jaegeuk Kim wrote: > This patch adds a facility to enable per-file encryption. > > Arnd fixes a missing CONFIG_BLOCK check in the original patch. > "The newly added generic crypto abstraction for file systems operates > on 'struct bio' objects, which do not exist when

[PATCH 01/10] selftests/x86: In syscall_nt, test NT|TF as well

Setting TF prevents fastpath returns in most cases, which causes the test to fail on 32-bit kernels because 32-bit kernels do not, in fact, handle NT correctly on SYSENTER entries. The next patch will fix 32-bit kernels. Signed-off-by: Andy Lutomirski ---

[PATCH 01/10] selftests/x86: In syscall_nt, test NT|TF as well

Setting TF prevents fastpath returns in most cases, which causes the test to fail on 32-bit kernels because 32-bit kernels do not, in fact, handle NT correctly on SYSENTER entries. The next patch will fix 32-bit kernels. Signed-off-by: Andy Lutomirski ---

[PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups

hpa asked me to get rid of the ASM_CLAC at the beginning of the SYSENTER path. Little did he know... This series makes the observed behavior of SYSENTER wrt flags the same for all sane flags and kernel bitnesses. That is, SYSENTER preserves flags now unless you do a syscall that explicitly

[PATCH 02/10] x86/entry/compat: In SYSENTER, sink AC clearing below the existing FLAGS test

CLAC is slow, and the SYSENTER code already has an unlikely path that runs if unusual flags are set. Drop the CLAC and instead rely on the unlikely path to clear AC. This seems to save ~24 cycles on my Skylake laptop. (Hey, Intel, make this faster please!) Signed-off-by: Andy Lutomirski

[PATCH 00/10] x86: Various SYSENTER/SYSEXIT/#DB fixes and cleanups

hpa asked me to get rid of the ASM_CLAC at the beginning of the SYSENTER path. Little did he know... This series makes the observed behavior of SYSENTER wrt flags the same for all sane flags and kernel bitnesses. That is, SYSENTER preserves flags now unless you do a syscall that explicitly

[PATCH 02/10] x86/entry/compat: In SYSENTER, sink AC clearing below the existing FLAGS test

CLAC is slow, and the SYSENTER code already has an unlikely path that runs if unusual flags are set. Drop the CLAC and instead rely on the unlikely path to clear AC. This seems to save ~24 cycles on my Skylake laptop. (Hey, Intel, make this faster please!) Signed-off-by: Andy Lutomirski ---

[PATCH 06/10] x86/traps: Clear DR6 early in do_debug and improve the comment

Leaving any bits set in DR6 on return from a debug exception is asking for trouble. Prevent it by writing zero right away and clarify the comment. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/traps.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-)

[PATCH 06/10] x86/traps: Clear DR6 early in do_debug and improve the comment

Leaving any bits set in DR6 on return from a debug exception is asking for trouble. Prevent it by writing zero right away and clarify the comment. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/traps.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git

[PATCH 07/10] x86/entry: Vastly simplify SYSENTER TF handling

Due to a blatant design error, SYSENTER doesn't clear TF. As a result, if a user does SYSENTER with TF set, we will single-step through the kernel until something clears TF. There is absolutely nothing we can do to prevent this short of turning off SYSENTER [1]. Simplify the handling

[PATCH 07/10] x86/entry: Vastly simplify SYSENTER TF handling

Due to a blatant design error, SYSENTER doesn't clear TF. As a result, if a user does SYSENTER with TF set, we will single-step through the kernel until something clears TF. There is absolutely nothing we can do to prevent this short of turning off SYSENTER [1]. Simplify the handling

[PATCH 08/10] x86/entry: Only allocate space for SYSENTER_stack if needed

The SYSENTER stack is only used on 32-bit kernels. Remove it in 64-bit kernels. (We may end up using it down the road on 64-bit kernels. If so, we'll re-enable it for CONFIG_IA32_EMULATION.) Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 2 ++ 1 file

[PATCH 08/10] x86/entry: Only allocate space for SYSENTER_stack if needed

The SYSENTER stack is only used on 32-bit kernels. Remove it in 64-bit kernels. (We may end up using it down the road on 64-bit kernels. If so, we'll re-enable it for CONFIG_IA32_EMULATION.) Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 2 ++ 1 file changed, 2

[PATCH 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 3 ++- arch/x86/kernel/process.c| 3 +++ arch/x86/kernel/traps.c | 8 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/processor.h

[PATCH 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/processor.h | 3 ++- arch/x86/kernel/process.c| 3 +++ arch/x86/kernel/traps.c | 8 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h

[PATCH 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

Right after SYSENTER, we can get a #DB or NMI. On x86_32, there's no IST, so the exception handler is invoked on the temporary SYSENTER stack. Because the SYSENTER stack is very small, we have a fixup to switch off the stack quickly when this happens. The old fixup had several issues: 1. It

[PATCH 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

Right after SYSENTER, we can get a #DB or NMI. On x86_32, there's no IST, so the exception handler is invoked on the temporary SYSENTER stack. Because the SYSENTER stack is very small, we have a fixup to switch off the stack quickly when this happens. The old fixup had several issues: 1. It

[PATCH 05/10] x86/traps: Clear TIF_BLOCKSTEP on all debug exceptions

The SDM says that debug exceptions clear BTF, and we need to keep TIF_BLOCKSTEP in sync with BTF. Clear it unconditionally and improve the comment. I suspect that the fact that kmemcheck could cause TIF_BLOCKSTEP not to be cleared was just an oversight. Signed-off-by: Andy Lutomirski

[PATCH 04/10] x86/entry/32: Restore FLAGS on SYSEXIT

We weren't restoring FLAGS at all on SYSEXIT. Apparently no one cared. With this patch applied, native kernels should always honor task_pt_regs()->flags, which opens the door for some sys_iopl cleanups. I'll do those as a separate series, though, since getting it right will involve tweaking

[PATCH 03/10] x86/entry/32: Filter NT and speed up AC filtering in SYSENTER

This makes the 32-bit code work just like the 64-bit code. It should speed up syscalls on 32-bit kernels on Skylake by something like 20 cycles (by analogy to the 64-bit compat case). It also cleans up NT just like we do for the 64-bit case. Signed-off-by: Andy Lutomirski ---

[PATCH 05/10] x86/traps: Clear TIF_BLOCKSTEP on all debug exceptions

The SDM says that debug exceptions clear BTF, and we need to keep TIF_BLOCKSTEP in sync with BTF. Clear it unconditionally and improve the comment. I suspect that the fact that kmemcheck could cause TIF_BLOCKSTEP not to be cleared was just an oversight. Signed-off-by: Andy Lutomirski ---

[PATCH 04/10] x86/entry/32: Restore FLAGS on SYSEXIT

We weren't restoring FLAGS at all on SYSEXIT. Apparently no one cared. With this patch applied, native kernels should always honor task_pt_regs()->flags, which opens the door for some sys_iopl cleanups. I'll do those as a separate series, though, since getting it right will involve tweaking

[PATCH 03/10] x86/entry/32: Filter NT and speed up AC filtering in SYSENTER

This makes the 32-bit code work just like the 64-bit code. It should speed up syscalls on 32-bit kernels on Skylake by something like 20 cycles (by analogy to the 64-bit compat case). It also cleans up NT just like we do for the 64-bit case. Signed-off-by: Andy Lutomirski ---

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >> >> The exception handlers which use the IST stacks don't necessarily >> set irq count. Maybe they should. > > Hmm. I think they

Re: [PATCH v3 3/3] sched, x86: Check that we're on the right stack in schedule and __might_sleep

On Wed, Nov 19, 2014 at 11:44 AM, Linus Torvalds wrote: > On Wed, Nov 19, 2014 at 11:29 AM, Andi Kleen wrote: >> >> The exception handlers which use the IST stacks don't necessarily >> set irq count. Maybe they should. > > Hmm. I think they should. Since they clearly must not schedule, as > they

[PATCH v4 3/5] ocfs2: create/remove sysfile for online file check

Create online file check sysfile when ocfs2 mount, remove the related sysfile when ocfs2 umount. Signed-off-by: Gang He Reviewed-by: Mark Fasheh --- fs/ocfs2/super.c | 5 + 1 file changed, 5 insertions(+) diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c

[PATCH v4 4/5] ocfs2: check/fix inode block for online file check

Implement online check or fix inode block during reading a inode block to memory. Signed-off-by: Gang He --- fs/ocfs2/inode.c | 225 +++-- fs/ocfs2/ocfs2_trace.h | 2 + 2 files changed, 218 insertions(+), 9 deletions(-) diff

[PATCH v4 1/5] ocfs2: export ocfs2_kset for online file check

Export ocfs2_kset object from ocfs2_stackglue kernel module, then online file check code will create the related sysfiles under ocfs2_kset object. Signed-off-by: Gang He Reviewed-by: Mark Fasheh --- fs/ocfs2/stackglue.c | 3 ++- fs/ocfs2/stackglue.h | 2 ++ 2

[PATCH v4 3/5] ocfs2: create/remove sysfile for online file check

Create online file check sysfile when ocfs2 mount, remove the related sysfile when ocfs2 umount. Signed-off-by: Gang He Reviewed-by: Mark Fasheh --- fs/ocfs2/super.c | 5 + 1 file changed, 5 insertions(+) diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c index 2de4c8a..5ef88b8 100644 ---

[PATCH v4 4/5] ocfs2: check/fix inode block for online file check

Implement online check or fix inode block during reading a inode block to memory. Signed-off-by: Gang He --- fs/ocfs2/inode.c | 225 +++-- fs/ocfs2/ocfs2_trace.h | 2 + 2 files changed, 218 insertions(+), 9 deletions(-) diff --git

[PATCH v4 1/5] ocfs2: export ocfs2_kset for online file check

Export ocfs2_kset object from ocfs2_stackglue kernel module, then online file check code will create the related sysfiles under ocfs2_kset object. Signed-off-by: Gang He Reviewed-by: Mark Fasheh --- fs/ocfs2/stackglue.c | 3 ++- fs/ocfs2/stackglue.h | 2 ++ 2 files changed, 4 insertions(+), 1

[PATCH v4 5/5] ocfs2: add feature document for online file check

This document will describe OCFS2 online file check feature. OCFS2 is often used in high-availaibility systems. However, OCFS2 usually converts the filesystem to read-only when encounters an error. This may not be necessary, since turning the filesystem read-only would affect other running

[PATCH v4 2/5] ocfs2: sysfile interfaces for online file check

Implement online file check sysfile interfaces, e.g. how to create the related sysfile according to device name, how to display/handle file check request from the sysfile. Signed-off-by: Gang He --- fs/ocfs2/Makefile| 3 +- fs/ocfs2/filecheck.c | 606

[PATCH v4 5/5] ocfs2: add feature document for online file check

This document will describe OCFS2 online file check feature. OCFS2 is often used in high-availaibility systems. However, OCFS2 usually converts the filesystem to read-only when encounters an error. This may not be necessary, since turning the filesystem read-only would affect other running

[PATCH v4 2/5] ocfs2: sysfile interfaces for online file check

Implement online file check sysfile interfaces, e.g. how to create the related sysfile according to device name, how to display/handle file check request from the sysfile. Signed-off-by: Gang He --- fs/ocfs2/Makefile| 3 +- fs/ocfs2/filecheck.c | 606

[PATCH v4 0/5] Add online file check feature

When there are errors in the ocfs2 filesystem, they are usually accompanied by the inode number which caused the error. This inode number would be the input to fixing the file. One of these options could be considered: A file in the sys filesytem which would accept inode numbers. This could be

linux-next: manual merge of the kvm-arm tree with the arm64 tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: arch/arm64/include/asm/cpufeature.h between commit: 104a0c02e8b1 ("arm64: Add workaround for Cavium erratum 27456") from the arm64 tree and commit: d0be74f771d5 ("arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature") from

[PATCH v4 0/5] Add online file check feature

When there are errors in the ocfs2 filesystem, they are usually accompanied by the inode number which caused the error. This inode number would be the input to fixing the file. One of these options could be considered: A file in the sys filesytem which would accept inode numbers. This could be

linux-next: manual merge of the kvm-arm tree with the arm64 tree

Hi all, Today's linux-next merge of the kvm-arm tree got a conflict in: arch/arm64/include/asm/cpufeature.h between commit: 104a0c02e8b1 ("arm64: Add workaround for Cavium erratum 27456") from the arm64 tree and commit: d0be74f771d5 ("arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature") from

Re: [PATCH V3 3/3] vhost_net: basic polling support

On 02/29/2016 05:56 AM, Christian Borntraeger wrote: > On 02/26/2016 09:42 AM, Jason Wang wrote: >> > This patch tries to poll for new added tx buffer or socket receive >> > queue for a while at the end of tx/rx processing. The maximum time >> > spent on polling were specified through a new kind

Re: [PATCH V3 3/3] vhost_net: basic polling support

On 02/29/2016 05:56 AM, Christian Borntraeger wrote: > On 02/26/2016 09:42 AM, Jason Wang wrote: >> > This patch tries to poll for new added tx buffer or socket receive >> > queue for a while at the end of tx/rx processing. The maximum time >> > spent on polling were specified through a new kind

Re: [PATCH V3 3/3] vhost_net: basic polling support

On 02/28/2016 10:09 PM, Michael S. Tsirkin wrote: > On Fri, Feb 26, 2016 at 04:42:44PM +0800, Jason Wang wrote: >> > This patch tries to poll for new added tx buffer or socket receive >> > queue for a while at the end of tx/rx processing. The maximum time >> > spent on polling were specified

Re: [PATCH V3 3/3] vhost_net: basic polling support

On 02/28/2016 10:09 PM, Michael S. Tsirkin wrote: > On Fri, Feb 26, 2016 at 04:42:44PM +0800, Jason Wang wrote: >> > This patch tries to poll for new added tx buffer or socket receive >> > queue for a while at the end of tx/rx processing. The maximum time >> > spent on polling were specified

[lkp] [n_tty] dd9a6fee68: INFO: possible circular locking dependency detected ]

FYI, we noticed the below changes on https://github.com/0day-ci/linux Brian-Bloniarz/Re-n_tty-Check-the-other-end-of-pty-pair-before-returning-EAGAIN-on-a-read/20160229-070452 commit dd9a6fee6830f16f602b1aa2e85d6307acd04945 ("n_tty: Check the other end of pty pair before returning EAGAIN on a

[lkp] [n_tty] dd9a6fee68: INFO: possible circular locking dependency detected ]

FYI, we noticed the below changes on https://github.com/0day-ci/linux Brian-Bloniarz/Re-n_tty-Check-the-other-end-of-pty-pair-before-returning-EAGAIN-on-a-read/20160229-070452 commit dd9a6fee6830f16f602b1aa2e85d6307acd04945 ("n_tty: Check the other end of pty pair before returning EAGAIN on a

  1   2   3   4   5   6   7   8   >