[PATCH 1/2] fstests: move expunge test into a helper

Move the expunge test into a helper. Signed-off-by: Luis R. Rodriguez --- check | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/check b/check index f8db3cd6dfab..0ba71d5d2005 100755 --- a/check +++ b/check @@ -485,6 +485,18 @@

[PATCH 1/2] fstests: move expunge test into a helper

Move the expunge test into a helper. Signed-off-by: Luis R. Rodriguez --- check | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/check b/check index f8db3cd6dfab..0ba71d5d2005 100755 --- a/check +++ b/check @@ -485,6 +485,18 @@ _check_filesystems()

[PATCH 2/2] fstests: expunge tests when doing a dry run

Running ./check with -n will not execute tests, however when exclude files are used we still show them as if they are run. Test the exclude file prior to assuming we can run a test on a dry run. Signed-off-by: Luis R. Rodriguez --- check | 4 1 file changed, 4

[PATCH 2/2] fstests: expunge tests when doing a dry run

Running ./check with -n will not execute tests, however when exclude files are used we still show them as if they are run. Test the exclude file prior to assuming we can run a test on a dry run. Signed-off-by: Luis R. Rodriguez --- check | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()

On Sat, Jan 20, 2018 at 05:37:52PM -0800, Joe Perches wrote: > While Markus' commit messages are nearly universally terrible, > is there really any signficant value in knowing when any > particular OOM condition occurs other than the subsystem that > became OOM? > > You're going to be hosed in

Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()

On Sat, Jan 20, 2018 at 05:37:52PM -0800, Joe Perches wrote: > While Markus' commit messages are nearly universally terrible, > is there really any signficant value in knowing when any > particular OOM condition occurs other than the subsystem that > became OOM? > > You're going to be hosed in

Re: [PATCH v2] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174

On Thu, Jan 18, 2018 at 10:58:20AM +0530, Ganapatrao Kulkarni wrote: > This erratum is observed on the ThunderX2 GICv3 ITS. When a > MOVI command is used to change affinity of a LPI to a collection/cpu > on another node, the LPI is not delivered to the cpu. > An additional INV command is required

Re: [PATCH v2] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174

On Thu, Jan 18, 2018 at 10:58:20AM +0530, Ganapatrao Kulkarni wrote: > This erratum is observed on the ThunderX2 GICv3 ITS. When a > MOVI command is used to change affinity of a LPI to a collection/cpu > on another node, the LPI is not delivered to the cpu. > An additional INV command is required

Re: [RFC] Per file OOM badness

Michel Dänzer writes: > On 2018-01-19 11:02 AM, Michel Dänzer wrote: >> On 2018-01-19 10:58 AM, Christian König wrote: >>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer: On 2018-01-19 09:39 AM, Christian König wrote: > Am 19.01.2018 um 09:20 schrieb Michal Hocko:

Re: [RFC] Per file OOM badness

Michel Dänzer writes: > On 2018-01-19 11:02 AM, Michel Dänzer wrote: >> On 2018-01-19 10:58 AM, Christian König wrote: >>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer: On 2018-01-19 09:39 AM, Christian König wrote: > Am 19.01.2018 um 09:20 schrieb Michal Hocko: >> OK, in that case

Never-ending Targeting/Bullying Campaigns at the Workplace in Singapore

Topic/Subject: Never-ending Targeting/Bullying Campaigns at the Workplace in Singapore Author: Mr. Turritopsis Dohrnii Teo En Ming Date: 21 January 2018 Sunday Singapore Government Linked Company (GLC) Keppel Corporation Bribed Brazilian Government Officials I am no stranger to

Never-ending Targeting/Bullying Campaigns at the Workplace in Singapore

Topic/Subject: Never-ending Targeting/Bullying Campaigns at the Workplace in Singapore Author: Mr. Turritopsis Dohrnii Teo En Ming Date: 21 January 2018 Sunday Singapore Government Linked Company (GLC) Keppel Corporation Bribed Brazilian Government Officials I am no stranger to

Re: [RFC v8 4/7] platform: x86: Add generic Intel IPC driver

Hi Heikki, On 11/23/2017 05:29 AM, Heikki Krogerus wrote: Hi, On Sun, Oct 29, 2017 at 02:49:57AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: +/** + * devm_intel_ipc_dev_create() - Create IPC device + * @dev: IPC parent device. + * @devname: Name of the IPC

Re: [RFC v8 4/7] platform: x86: Add generic Intel IPC driver

Hi Heikki, On 11/23/2017 05:29 AM, Heikki Krogerus wrote: Hi, On Sun, Oct 29, 2017 at 02:49:57AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: +/** + * devm_intel_ipc_dev_create() - Create IPC device + * @dev: IPC parent device. + * @devname: Name of the IPC

[PATCH] soundwire: Fix a signedness bug

From: Dan Carpenter "ret" is an int and "buf" is a u8. sdw_read() returns negative error codes which are truncated to the u8, 0-255 range before being stored as an int. It means that "ret" can't be less than zero. Fixes: b0a9c37b0178 ("soundwire: Add slave status

[PATCH] soundwire: Fix a signedness bug

From: Dan Carpenter "ret" is an int and "buf" is a u8. sdw_read() returns negative error codes which are truncated to the u8, 0-255 range before being stored as an int. It means that "ret" can't be less than zero. Fixes: b0a9c37b0178 ("soundwire: Add slave status handling") Signed-off-by: Dan

Re: [RFC v8 2/7] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi Heikki, Thanks for the review. On 11/23/2017 03:49 AM, Heikki Krogerus wrote: Hi, On Sun, Oct 29, 2017 at 02:49:55AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Currently, we have lot of

Re: [RFC v8 2/7] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi Heikki, Thanks for the review. On 11/23/2017 03:49 AM, Heikki Krogerus wrote: Hi, On Sun, Oct 29, 2017 at 02:49:55AM -0700, sathyanarayanan.kuppusw...@linux.intel.com wrote: From: Kuppuswamy Sathyanarayanan Currently, we have lot of repetitive code in dependent device resource

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

On Sat, Jan 20, 2018 at 5:49 PM, Gabriel C wrote: > > Added stable to CC since the patch series this patch fixes > is in stable-queue. Oh, it wasn't clear from the commit message. But I guess the "Fixes:" tag would have caught Greg's eye regardless. Anyway, Laura's fix is

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

On Sat, Jan 20, 2018 at 5:49 PM, Gabriel C wrote: > > Added stable to CC since the patch series this patch fixes > is in stable-queue. Oh, it wasn't clear from the commit message. But I guess the "Fixes:" tag would have caught Greg's eye regardless. Anyway, Laura's fix is commit 91cfc88c66bf

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

2018-01-15 16:33 GMT+08:00 Christoffer Dall : > On Fri, Jan 12, 2018 at 06:05:23PM +, James Morse wrote: >> On 15/12/17 03:30, gengdongjiu wrote: >> > On 2017/12/7 14:37, gengdongjiu wrote: > > [...] > >> >> (I recall someone saying migration is needed for any new

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

2018-01-15 16:33 GMT+08:00 Christoffer Dall : > On Fri, Jan 12, 2018 at 06:05:23PM +, James Morse wrote: >> On 15/12/17 03:30, gengdongjiu wrote: >> > On 2017/12/7 14:37, gengdongjiu wrote: > > [...] > >> >> (I recall someone saying migration is needed for any new KVM/cpu features, >> but I

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

2018-01-13 2:05 GMT+08:00 James Morse : > Hi gengdongjiu, > > On 16/12/17 04:47, gengdongjiu wrote: >> [...] >>> + case ESR_ELx_AET_UER: /* The error has not been propagated */ + /* + * Userspace only handle the guest SError

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

2018-01-13 2:05 GMT+08:00 James Morse : > Hi gengdongjiu, > > On 16/12/17 04:47, gengdongjiu wrote: >> [...] >>> + case ESR_ELx_AET_UER: /* The error has not been propagated */ + /* + * Userspace only handle the guest SError Interrupt(SEI) if the

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi James, Sorry for my late response due to out of office recently. 2018-01-13 2:05 GMT+08:00 James Morse : > Hi gengdongjiu, > > On 15/12/17 03:30, gengdongjiu wrote: >> On 2017/12/7 14:37, gengdongjiu wrote: We need to tackle (1) and (3) separately. For (3) we need

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi James, Sorry for my late response due to out of office recently. 2018-01-13 2:05 GMT+08:00 James Morse : > Hi gengdongjiu, > > On 15/12/17 03:30, gengdongjiu wrote: >> On 2017/12/7 14:37, gengdongjiu wrote: We need to tackle (1) and (3) separately. For (3) we need some API that

Re: [f2fs-dev] [PATCH 2/2 v2] f2fs: recover some i_inline flags

On 2018/1/21 6:06, Jaegeuk Kim wrote: > This fixes lost i_inline flags during roll-forward. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

Re: [f2fs-dev] [PATCH 2/2 v2] f2fs: recover some i_inline flags

On 2018/1/21 6:06, Jaegeuk Kim wrote: > This fixes lost i_inline flags during roll-forward. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

Re: [f2fs-dev] [PATCH 1/2 v2] f2fs: allow to recover node blocks given updated checkpoint

On 2018/1/21 6:05, Jaegeuk Kim wrote: > If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll- > forward recovery. Let's relax the condition to recover them. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

Re: [f2fs-dev] [PATCH 1/2 v2] f2fs: allow to recover node blocks given updated checkpoint

On 2018/1/21 6:05, Jaegeuk Kim wrote: > If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll- > forward recovery. Let's relax the condition to recover them. > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,

[PULL] alpha.git

Hi Linus, Please pull my alpha git tree. It contains a build fix and a regression fix. Hopefully still in time for 4.15 :) Thanks, Matt The following changes since commit 8cbab92dff778e516064c13113ca15d4869ec883: Merge tag 'for-linus' of

[PULL] alpha.git

Hi Linus, Please pull my alpha git tree. It contains a build fix and a regression fix. Hopefully still in time for 4.15 :) Thanks, Matt The following changes since commit 8cbab92dff778e516064c13113ca15d4869ec883: Merge tag 'for-linus' of

[GIT PULL] PNP updates for v4.16-rc1

Hi Linus, This goes early because of my LCA travel. In case you decide to open the 4.16 merge window any time soon, please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pnp-4.16-rc1 with top-most commit 846583ce151644b8538ca6cdf3f0857a80787649 PNP:

[GIT PULL] PNP updates for v4.16-rc1

Hi Linus, This goes early because of my LCA travel. In case you decide to open the 4.16 merge window any time soon, please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pnp-4.16-rc1 with top-most commit 846583ce151644b8538ca6cdf3f0857a80787649 PNP:

[GIT PULL] ACPI updates for v4.16-rc1

Hi Linus, This goes early because of my LCA travel. In case you decide to open the 4.16 merge window any time soon, please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.16-rc1 with top-most commit a7f2766ac7c359216da4e714dc117c881e39a74a Merge

[GIT PULL] ACPI updates for v4.16-rc1

Hi Linus, This goes early because of my LCA travel. In case you decide to open the 4.16 merge window any time soon, please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.16-rc1 with top-most commit a7f2766ac7c359216da4e714dc117c881e39a74a Merge

[GIT PULL] Power management updates for v4.16-rc1

Hi Linus, This goes early, because I'm attending the LCA next week and I may be sparsely available and generally time-constrained during the next several days. In case you decide to open the 4.16 merge window any time soon, please pull from the tag

[GIT PULL] Power management updates for v4.16-rc1

Hi Linus, This goes early, because I'm attending the LCA next week and I may be sparsely available and generally time-constrained during the next several days. In case you decide to open the 4.16 merge window any time soon, please pull from the tag

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

On 21.01.2018 02:23, Linus Torvalds wrote: On Sat, Jan 20, 2018 at 5:14 PM, Laura Abbott wrote: I hadn't seen this picked up yet so sending explicitly Ingo, I just took this directly as a patch. Added stable to CC since the patch series this patch fixes is in

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

On 21.01.2018 02:23, Linus Torvalds wrote: On Sat, Jan 20, 2018 at 5:14 PM, Laura Abbott wrote: I hadn't seen this picked up yet so sending explicitly Ingo, I just took this directly as a patch. Added stable to CC since the patch series this patch fixes is in stable-queue. Regards,

Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()

On Sat, 2018-01-20 at 20:40 +0100, Jörg Rödel wrote: > On Sat, Jan 20, 2018 at 03:55:37PM +0100, SF Markus Elfring wrote: > > Do you need any more background information for this general > > transformation pattern? > > No. > > > Do you find the Linux allocation failure report insufficient for

Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()

On Sat, 2018-01-20 at 20:40 +0100, Jörg Rödel wrote: > On Sat, Jan 20, 2018 at 03:55:37PM +0100, SF Markus Elfring wrote: > > Do you need any more background information for this general > > transformation pattern? > > No. > > > Do you find the Linux allocation failure report insufficient for

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

On Sat, Jan 20, 2018 at 5:14 PM, Laura Abbott wrote: > > I hadn't seen this picked up yet so sending explicitly Ingo, I just took this directly as a patch. Linus

Re: [PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

On Sat, Jan 20, 2018 at 5:14 PM, Laura Abbott wrote: > > I hadn't seen this picked up yet so sending explicitly Ingo, I just took this directly as a patch. Linus

Re: [kernel-hardening] Re: [PATCH 0/3] exec: Pin stack limit during exec

On Fri, Jan 19, 2018 at 5:12 PM, David Windsor wrote: > I have some spare cycles; is there any more relevant information outside of > this thread? Awesome, thanks! Context is in the other commits, but mainly I want to double-check that nothing breaks with these changes, and

Re: [kernel-hardening] Re: [PATCH 0/3] exec: Pin stack limit during exec

On Fri, Jan 19, 2018 at 5:12 PM, David Windsor wrote: > I have some spare cycles; is there any more relevant information outside of > this thread? Awesome, thanks! Context is in the other commits, but mainly I want to double-check that nothing breaks with these changes, and that all the races

[PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

Commit bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") moved some parameters into a structure. The structure was large enough to trigger the stack protection canary in sme_encrypt_kernel which doesn't work this early, causing reboots. Mark sme_encrypt_kernel

[PATCH] x86: Use __nostackprotect for sme_encrypt_kernel

Commit bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") moved some parameters into a structure. The structure was large enough to trigger the stack protection canary in sme_encrypt_kernel which doesn't work this early, causing reboots. Mark sme_encrypt_kernel

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

> I'm not familiar with MDIO bus but an alternative to GeneriSerialBus > would be to follow what SDIO is doing, e.g have the PHY devices listed > below the MDIO controller and use _ADR to describe their "address" on > that bus. You can see how _ADR applies to SDIO bus from ACPI spec. Hi Mika

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

> I'm not familiar with MDIO bus but an alternative to GeneriSerialBus > would be to follow what SDIO is doing, e.g have the PHY devices listed > below the MDIO controller and use _ADR to describe their "address" on > that bus. You can see how _ADR applies to SDIO bus from ACPI spec. Hi Mika

ecryptfs problems with encrypted/ unencrypted file names

Hi, Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name") was supposed to fix a situation where two files with the same name and same inode could be created in ecryptfs. One of those files had an encrypted file name, the other file name was unencrypted. The

ecryptfs problems with encrypted/ unencrypted file names

Hi, Commit 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name") was supposed to fix a situation where two files with the same name and same inode could be created in ecryptfs. One of those files had an encrypted file name, the other file name was unencrypted. The

Re: Panic with ext4,nbd,qemu-img,block

On Sat, Jan 20, 2018 at 04:41:00PM +0800, Hongzhi, Song wrote: > > 329.11 EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: > (null) > 329.12 block nbd0: Connection timed out > 329.13 block nbd0: shutting down sockets That's your problem. I'm guessing qemu-nbd is dying for some

Re: Panic with ext4,nbd,qemu-img,block

On Sat, Jan 20, 2018 at 04:41:00PM +0800, Hongzhi, Song wrote: > > 329.11 EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: > (null) > 329.12 block nbd0: Connection timed out > 329.13 block nbd0: shutting down sockets That's your problem. I'm guessing qemu-nbd is dying for some

Re: [PATCH] Staging: netlogic: platform_net: Fixed '(' at the EOL

On Tue, Jan 16, 2018 at 07:33:03PM +0530, Naveen Panwar wrote: > Hi Guys, > > I submitted a new patch with the suggestions from Al Viro, did you guys > check it? > The list seems to reject your patches. It rejected the first one as well. regards, dan carpenter

Re: [PATCH] Staging: netlogic: platform_net: Fixed '(' at the EOL

On Tue, Jan 16, 2018 at 07:33:03PM +0530, Naveen Panwar wrote: > Hi Guys, > > I submitted a new patch with the suggestions from Al Viro, did you guys > check it? > The list seems to reject your patches. It rejected the first one as well. regards, dan carpenter

[PATCH] staging: rtl8712: remove redundant initialization to 'rfPath'

From: Colin Ian King The value stored to rfPath during initialization is never read, the following switch statement re-assigns it a new value on all the case and default paths. Hence the initialization is redundant and can be removed. Cleans up clang warning:

[PATCH] staging: rtl8712: remove redundant initialization to 'rfPath'

From: Colin Ian King The value stored to rfPath during initialization is never read, the following switch statement re-assigns it a new value on all the case and default paths. Hence the initialization is redundant and can be removed. Cleans up clang warning:

Re: [PATCH 4.9 85/96] x86/retpoline: Add initial retpoline support

On Wed, 17 Jan 2018, gre...@linuxfoundation.org wrote: > > http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.4.y > > And I've now queued up all of these patches, thanks very much for doing > this work! The patch below is needed on top of it, otherwise if

Re: [PATCH 4.9 85/96] x86/retpoline: Add initial retpoline support

On Wed, 17 Jan 2018, gre...@linuxfoundation.org wrote: > > http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.4.y > > And I've now queued up all of these patches, thanks very much for doing > this work! The patch below is needed on top of it, otherwise if

[PATCH] staging: rtl8192e: remove two redundant assignments

From: Colin Ian King Clang detected two redundant assignments that can be safely removed. The first is the removal of the duplicated assignment to pointer 'hdr', this has already been initialized with the same value. The second is the removal of the redundant

[PATCH] staging: rtl8192e: remove two redundant assignments

From: Colin Ian King Clang detected two redundant assignments that can be safely removed. The first is the removal of the duplicated assignment to pointer 'hdr', this has already been initialized with the same value. The second is the removal of the redundant initialization of variable

[PATCH] mtd: block2mtd: remove redundant initialization of 'bdev'

From: Colin Ian King Pointer bdev is being initialized however this value is never read as bdev is assigned an updated value from the returned call to blkdev_get_by_path. Remove the redundant assignment. Cleans up clang warning: drivers/mtd/devices/block2mtd.c:228:23:

[PATCH] mtd: block2mtd: remove redundant initialization of 'bdev'

From: Colin Ian King Pointer bdev is being initialized however this value is never read as bdev is assigned an updated value from the returned call to blkdev_get_by_path. Remove the redundant assignment. Cleans up clang warning: drivers/mtd/devices/block2mtd.c:228:23: warning: Value stored to

Re: [PATCH 2/2 v2] f2fs: recover some i_inline flags

This fixes lost i_inline flags during roll-forward. Signed-off-by: Jaegeuk Kim --- Change log from v1: - add a new function to recover the flag - fix missing pin_file unset fs/f2fs/recovery.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-)

Re: [PATCH 2/2 v2] f2fs: recover some i_inline flags

This fixes lost i_inline flags during roll-forward. Signed-off-by: Jaegeuk Kim --- Change log from v1: - add a new function to recover the flag - fix missing pin_file unset fs/f2fs/recovery.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 1/2 v2] f2fs: allow to recover node blocks given updated checkpoint

If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll- forward recovery. Let's relax the condition to recover them. Signed-off-by: Jaegeuk Kim --- Change log from v1: - add a new checkpoint flag to handle this fs/f2fs/checkpoint.c| 1 +

Re: [PATCH 1/2 v2] f2fs: allow to recover node blocks given updated checkpoint

If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll- forward recovery. Let's relax the condition to recover them. Signed-off-by: Jaegeuk Kim --- Change log from v1: - add a new checkpoint flag to handle this fs/f2fs/checkpoint.c| 1 + fs/f2fs/node.h | 4

Re: [PATCH] f2fs: correct removexattr behavior for null valued extended attribute

Thanks, On 01/20, Chao Yu wrote: > From: Daeho Jeong > > __vfs_removexattr() transfers "NULL" value to the setxattr handler of > the f2fs filesystem in order to remove the extended attribute. But, > __f2fs_setxattr() just ignores the removal request when the value of >

Re: [PATCH] f2fs: correct removexattr behavior for null valued extended attribute

Thanks, On 01/20, Chao Yu wrote: > From: Daeho Jeong > > __vfs_removexattr() transfers "NULL" value to the setxattr handler of > the f2fs filesystem in order to remove the extended attribute. But, > __f2fs_setxattr() just ignores the removal request when the value of > the extended attribute is

Re: [PATCH 1/4] x86/cpufeatures: Add Intel feature bits for Speculation Control

On Sat, 2018-01-20 at 13:51 -0800, Steven Noonan wrote: > > > +#define X86_FEATURE_STIPB  (18*32+27) /* Speculation > Control with STIPB (Intel) */ > > Is this correct? I thought the acronym was "STIBP", i.e. > "Single-Thread Indrect Branch Prediction"? If so, then you've got the > B

Re: [PATCH 1/4] x86/cpufeatures: Add Intel feature bits for Speculation Control

On Sat, 2018-01-20 at 13:51 -0800, Steven Noonan wrote: > > > +#define X86_FEATURE_STIPB  (18*32+27) /* Speculation > Control with STIPB (Intel) */ > > Is this correct? I thought the acronym was "STIBP", i.e. > "Single-Thread Indrect Branch Prediction"? If so, then you've got the > B

Re: [PATCH 1/4] x86/cpufeatures: Add Intel feature bits for Speculation Control

On Sat, Jan 20, 2018 at 4:03 AM, David Woodhouse wrote: > Add three feature bits exposed by new microcode on Intel CPUs for > speculation control. We would now be up to five bits in CPUID(7).RDX > so take them out of the 'scattered' features and make a proper word > for them

Re: [PATCH 1/4] x86/cpufeatures: Add Intel feature bits for Speculation Control

On Sat, Jan 20, 2018 at 4:03 AM, David Woodhouse wrote: > Add three feature bits exposed by new microcode on Intel CPUs for > speculation control. We would now be up to five bits in CPUID(7).RDX > so take them out of the 'scattered' features and make a proper word > for them instead. > >

[PATCH 1/2] input: synaptics_usb: fix deadlock in autosuspend

usb_autopm_get_interface() that is called in synusb_open() does an autoresume if the device is suspended. input_dev->mutex used in synusb_resume() is in this case already taken by the input subsystem and will cause a deadlock. Signed-off-by: Marcus Folkesson ---

[PATCH 2/2] input: synaptics_usb: do not rely on input_dev->users

If the device is unused and suspended, a call to open will cause the device to autoresume through the call to usb_autopm_get_interface(). input_dev->users is already incremented by the input subsystem, therefore this expression will always be evaluated to true: if ((input_dev->users ||

[PATCH 1/2] input: synaptics_usb: fix deadlock in autosuspend

usb_autopm_get_interface() that is called in synusb_open() does an autoresume if the device is suspended. input_dev->mutex used in synusb_resume() is in this case already taken by the input subsystem and will cause a deadlock. Signed-off-by: Marcus Folkesson ---

[PATCH 2/2] input: synaptics_usb: do not rely on input_dev->users

If the device is unused and suspended, a call to open will cause the device to autoresume through the call to usb_autopm_get_interface(). input_dev->users is already incremented by the input subsystem, therefore this expression will always be evaluated to true: if ((input_dev->users ||

[PATCH 2/2] Input: sur40: Improve a size determination in sur40_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 22:16:14 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/2] Input: sur40: Improve a size determination in sur40_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 22:16:14 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/2] Input: sur40: Delete an error message for a failed memory allocation in sur40_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 22:11:24 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] Input: sur40: Delete an error message for a failed memory allocation in sur40_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 22:11:24 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/input/touchscreen/sur40.c | 1 - 1 file changed, 1

[PATCH 0/2] Input-sur40: Adjustments for sur40_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 22:20:10 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination

[PATCH 0/2] Input-sur40: Adjustments for sur40_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 22:20:10 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/input/touchscreen/sur40.c | 3 +-- 1

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote: > From: Tim Chen I think this is probably From: Andi now rather than From: Tim? We do need the series this far in order to have a full retpoline-based mitigation, and I'd like to see that go in sooner rather

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote: > From: Tim Chen I think this is probably From: Andi now rather than From: Tim? We do need the series this far in order to have a full retpoline-based mitigation, and I'd like to see that go in sooner rather than later. There's a little

Re: [PATCH v3] input: pxrc: new driver for PhoenixRC Flight Controller Adapter

Hello Dmitry, On Fri, Jan 19, 2018 at 03:24:32PM -0800, Dmitry Torokhov wrote: > On Wed, Jan 17, 2018 at 02:58:40PM +0100, Marcus Folkesson wrote: > > Hello Dmitry, > > > > On Tue, Jan 16, 2018 at 03:16:25PM -0800, Dmitry Torokhov wrote: > > > Hi Marcus, > > > > > > On Sat, Jan 13, 2018 at

Re: [PATCH v3] input: pxrc: new driver for PhoenixRC Flight Controller Adapter

Hello Dmitry, On Fri, Jan 19, 2018 at 03:24:32PM -0800, Dmitry Torokhov wrote: > On Wed, Jan 17, 2018 at 02:58:40PM +0100, Marcus Folkesson wrote: > > Hello Dmitry, > > > > On Tue, Jan 16, 2018 at 03:16:25PM -0800, Dmitry Torokhov wrote: > > > Hi Marcus, > > > > > > On Sat, Jan 13, 2018 at

[PATCH 2/2] Input: tps6507x-ts: Improve a size determination in tps6507x_ts_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 21:47:16 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/2] Input: tps6507x-ts: Improve a size determination in tps6507x_ts_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 21:47:16 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/2] Input: tps6507x-ts: Delete an error message for a failed memory allocation in tps6507x_ts_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 21:43:54 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] Input: tps6507x-ts: Delete an error message for a failed memory allocation in tps6507x_ts_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 21:43:54 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/input/touchscreen/tps6507x-ts.c | 4 +--- 1 file changed, 1

[PATCH v5] input: pxrc: new driver for PhoenixRC Flight Controller Adapter

This driver let you plug in your RC controller to the adapter and use it as input device in various RC simulators. Signed-off-by: Marcus Folkesson --- v5: - Drop autosuspend support - Use pm_mutex instead of input_dev->mutex - Use

[PATCH v5] input: pxrc: new driver for PhoenixRC Flight Controller Adapter

This driver let you plug in your RC controller to the adapter and use it as input device in various RC simulators. Signed-off-by: Marcus Folkesson --- v5: - Drop autosuspend support - Use pm_mutex instead of input_dev->mutex - Use pxrc->is_open instead of

[PATCH 0/2] Input: tps6507x-ts: Adjustments for tps6507x_ts_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 21:53:21 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination

[PATCH 0/2] Input: tps6507x-ts: Adjustments for tps6507x_ts_probe()

From: Markus Elfring Date: Sat, 20 Jan 2018 21:53:21 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/input/touchscreen/tps6507x-ts.c | 6

Re: [RFC 02/10] x86/kvm: Add IBPB support

On Sat, 2018-01-20 at 12:28 -0800, Liran Alon wrote: > Isn't it cleaner to check for "boot_cpu_has(X86_FEATURE_IBPB)" both > in svm_vcpu_init_msrpm() and hardware_setup()? Strictly speaking that's a different check. That's checking if we're *using* IBPB, not if it exists. Now that's probably OK

Re: [RFC 02/10] x86/kvm: Add IBPB support

On Sat, 2018-01-20 at 12:28 -0800, Liran Alon wrote: > Isn't it cleaner to check for "boot_cpu_has(X86_FEATURE_IBPB)" both > in svm_vcpu_init_msrpm() and hardware_setup()? Strictly speaking that's a different check. That's checking if we're *using* IBPB, not if it exists. Now that's probably OK

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat, 2018-01-20 at 15:19 +, Jonathan Cameron wrote: > On Thu, 18 Jan 2018 23:40:26 +0100 > Pavel Machek wrote: > > > > > Hi! > > > > > > > > From an IIO sensor point of view A Gesture sensor: > > > Outputs > > > A pre defined activity type > > > WAKE > > >

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat, 2018-01-20 at 15:19 +, Jonathan Cameron wrote: > On Thu, 18 Jan 2018 23:40:26 +0100 > Pavel Machek wrote: > > > > > Hi! > > > > > > > > From an IIO sensor point of view A Gesture sensor: > > > Outputs > > > A pre defined activity type > > > WAKE > > > TILT >

  1   2   3   4   5   >