Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

2017-05-10 23:09 GMT+03:00 Guenter Roeck : > On Wed, May 10, 2017 at 10:16:33PM +0300, Tommi Rantala wrote: >> 2017-05-10 17:30 GMT+03:00 Thomas Gleixner : >> > The recent conversion to the hotplug state machine missed that the original >> > hotplug

Re: [PATCH] hwmon: (coretemp) Handle frozen hotplug state correctly

2017-05-10 23:09 GMT+03:00 Guenter Roeck : > On Wed, May 10, 2017 at 10:16:33PM +0300, Tommi Rantala wrote: >> 2017-05-10 17:30 GMT+03:00 Thomas Gleixner : >> > The recent conversion to the hotplug state machine missed that the original >> > hotplug notifiers did not execute in the frozen state,

[PATCH] staging: typec: Fix sparse warnings about incorrect types

Fix the following sparse warnings about incorrect type usage: fusb302.c:1028:32: warning: incorrect type in argument 1 (different base types) fusb302.c:1028:32:expected unsigned short [unsigned] [usertype] header fusb302.c:1028:32:got restricted __le16 const [usertype] header

[PATCH] staging: typec: Fix sparse warnings about incorrect types

Fix the following sparse warnings about incorrect type usage: fusb302.c:1028:32: warning: incorrect type in argument 1 (different base types) fusb302.c:1028:32:expected unsigned short [unsigned] [usertype] header fusb302.c:1028:32:got restricted __le16 const [usertype] header

Re: [patch V2 24/24] cpu/hotplug: Convert hotplug locking to percpu rwsem

Thomas Gleixner writes: > On Wed, 10 May 2017, Michael Ellerman wrote: > >> Thomas Gleixner writes: >> >> > @@ -130,6 +130,7 @@ void __static_key_slow_inc(struct static >> > * the all CPUs, for that to be serialized against CPU hot-plug >> > * we

Re: [patch V2 24/24] cpu/hotplug: Convert hotplug locking to percpu rwsem

Thomas Gleixner writes: > On Wed, 10 May 2017, Michael Ellerman wrote: > >> Thomas Gleixner writes: >> >> > @@ -130,6 +130,7 @@ void __static_key_slow_inc(struct static >> > * the all CPUs, for that to be serialized against CPU hot-plug >> > * we need to avoid CPUs coming online. >> >

Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

> Sinclair Yeh hat am 10. Mai 2017 um 18:46 geschrieben: > > > Hi, Hi, > On Wed, May 10, 2017 at 12:31:39PM +0200, m.t wrote: > > > > > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben: > > > > > > Hi, > > > > > > Thanks for reporting. > > > > I would have reported earlier if it

Re: [Linux-graphics-maintainer] No mouse cursor since 36cc79bc9077319c04bd3b132edcacaa9a0d9f2b

> Sinclair Yeh hat am 10. Mai 2017 um 18:46 geschrieben: > > > Hi, Hi, > On Wed, May 10, 2017 at 12:31:39PM +0200, m.t wrote: > > > > > Thomas Hellstrom hat am 10. Mai 2017 um 10:35 geschrieben: > > > > > > Hi, > > > > > > Thanks for reporting. > > > > I would have reported earlier if it

Re: [PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

On 06/05/2017 18:48, Gabriel L. Somlo wrote: > So, in conclusion; it's not important to *me* that this old machine > keeps working, I'm just volunteering test data points. So please don't > feel obligated in any way to go out of your way on my account. OTOH, > I'm happy to provide feedback as

Re: [PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

On 06/05/2017 18:48, Gabriel L. Somlo wrote: > So, in conclusion; it's not important to *me* that this old machine > keeps working, I'm just volunteering test data points. So please don't > feel obligated in any way to go out of your way on my account. OTOH, > I'm happy to provide feedback as

Re: [PATCH] FS: Fixing return type of unsigned_offsets

If I remove '!!', sparse flags warning: fs/read_write.c:38:29: warning: incorrect type in return expression (different base types) fs/read_write.c:38:29:expected bool fs/read_write.c:38:29:got restricted fmode_t It means explicit conversion is needed. On Thu, May 11, 2017 at 10:25 AM,

Re: [PATCH] FS: Fixing return type of unsigned_offsets

If I remove '!!', sparse flags warning: fs/read_write.c:38:29: warning: incorrect type in return expression (different base types) fs/read_write.c:38:29:expected bool fs/read_write.c:38:29:got restricted fmode_t It means explicit conversion is needed. On Thu, May 11, 2017 at 10:25 AM,

[PATCH] kernel/power: Declare variables as static

Fixing sparse warnings: 'symbol not declared. Should it be static?' Variables need to be static since they have not used outside of the files. Signed-off-by: Pushkar Jambhlekar --- kernel/power/snapshot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH v2 0/3] nVMX: Emulated Page Modification Logging for Nested Virtualization

On 09/05/2017 18:03, Bandan Das wrote: >> I tested this with api/dirty-log-perf, and nested PML is more than 3 >> times faster than pml=0. I want to do a few more tests because I don't >> see any PML full exits in the L1 trace, but it seems to be a nice >> improvement! > > Thanks for testing!

Re: [PATCH v2 0/3] nVMX: Emulated Page Modification Logging for Nested Virtualization

On 09/05/2017 18:03, Bandan Das wrote: >> I tested this with api/dirty-log-perf, and nested PML is more than 3 >> times faster than pml=0. I want to do a few more tests because I don't >> see any PML full exits in the L1 trace, but it seems to be a nice >> improvement! > > Thanks for testing!

[PATCH] kernel/power: Declare variables as static

Fixing sparse warnings: 'symbol not declared. Should it be static?' Variables need to be static since they have not used outside of the files. Signed-off-by: Pushkar Jambhlekar --- kernel/power/snapshot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[GIT PULL] MTD updates for 4.12-rc1

Hi Linus, The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/for-linus-20170510 for you to fetch changes up

[GIT PULL] MTD updates for 4.12-rc1

Hi Linus, The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://git.infradead.org/linux-mtd.git tags/for-linus-20170510 for you to fetch changes up

Re: [PATCH] FS: Fixing return type of unsigned_offsets

On Thu, 2017-05-11 at 10:13 +0530, Pushkar Jambhlekar wrote: > Should I change my implementation, i.e. remove '!!'? That'd be up to Al. At least one implementation using similar bit comparisons in fs/*.c does not use !! fs/locks.c:static bool lease_breaking(struct file_lock *fl) fs/locks.c-{

Re: [PATCH] FS: Fixing return type of unsigned_offsets

On Thu, 2017-05-11 at 10:13 +0530, Pushkar Jambhlekar wrote: > Should I change my implementation, i.e. remove '!!'? That'd be up to Al. At least one implementation using similar bit comparisons in fs/*.c does not use !! fs/locks.c:static bool lease_breaking(struct file_lock *fl) fs/locks.c-{

Re: [PATCH 1/1] selftests: sync: add config fragment for testing sync framework

Fathi Boudra writes: > Unless the software synchronization objects (CONFIG_SW_SYNC) is enabled, > the sync test will fail: > > Additional Information: > Running tests in sync > > [RUN] Testing sync framework > [RUN] Executing

Re: [PATCH 1/1] selftests: sync: add config fragment for testing sync framework

Fathi Boudra writes: > Unless the software synchronization objects (CONFIG_SW_SYNC) is enabled, > the sync test will fail: > > Additional Information: > Running tests in sync > > [RUN] Testing sync framework > [RUN] Executing test_alloc_timeline >

RE: [PATCH] net: fec: select queue depending on VLAN priority

From: Stefan Agner Sent: Thursday, May 11, 2017 12:08 PM >To: Andy Duan >Cc: David Miller ; and...@lunn.ch; >feste...@gmail.com; net...@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: Re: [PATCH] net: fec: select queue

RE: [PATCH] net: fec: select queue depending on VLAN priority

From: Stefan Agner Sent: Thursday, May 11, 2017 12:08 PM >To: Andy Duan >Cc: David Miller ; and...@lunn.ch; >feste...@gmail.com; net...@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: Re: [PATCH] net: fec: select queue depending on VLAN priority > >On 2017-05-09 19:42, Andy Duan wrote:

Re: [PATCH] FS: Fixing return type of unsigned_offsets

Should I change my implementation, i.e. remove '!!'? On Thu, May 11, 2017 at 10:09 AM, Joe Perches wrote: > On Thu, 2017-05-11 at 09:57 +0530, Pushkar Jambhlekar wrote: >> Fixing Sparse warning. It should return bool, instead it returns >> int. > [] >> diff --git

Re: [PATCH] FS: Fixing return type of unsigned_offsets

Should I change my implementation, i.e. remove '!!'? On Thu, May 11, 2017 at 10:09 AM, Joe Perches wrote: > On Thu, 2017-05-11 at 09:57 +0530, Pushkar Jambhlekar wrote: >> Fixing Sparse warning. It should return bool, instead it returns >> int. > [] >> diff --git a/fs/read_write.c

Re: [PATCH] FS: Fixing return type of unsigned_offsets

On Thu, 2017-05-11 at 09:57 +0530, Pushkar Jambhlekar wrote: > Fixing Sparse warning. It should return bool, instead it returns > int. [] > diff --git a/fs/read_write.c b/fs/read_write.c [] > @@ -33,9 +33,9 @@ const struct file_operations generic_ro_fops = { > > EXPORT_SYMBOL(generic_ro_fops);

Re: [PATCH] FS: Fixing return type of unsigned_offsets

On Thu, 2017-05-11 at 09:57 +0530, Pushkar Jambhlekar wrote: > Fixing Sparse warning. It should return bool, instead it returns > int. [] > diff --git a/fs/read_write.c b/fs/read_write.c [] > @@ -33,9 +33,9 @@ const struct file_operations generic_ro_fops = { > > EXPORT_SYMBOL(generic_ro_fops);

Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out

On Thu, May 11, 2017 at 08:50:01AM +0800, Huang, Ying wrote: < snip > > >> > @@ -1125,8 +1125,28 @@ static unsigned long shrink_page_list(struct > >> > list_head *page_list, > >> > !PageSwapCache(page)) { > >> > if (!(sc->gfp_mask & __GFP_IO)) > >> >

Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out

On Thu, May 11, 2017 at 08:50:01AM +0800, Huang, Ying wrote: < snip > > >> > @@ -1125,8 +1125,28 @@ static unsigned long shrink_page_list(struct > >> > list_head *page_list, > >> > !PageSwapCache(page)) { > >> > if (!(sc->gfp_mask & __GFP_IO)) > >> >

[PATCH] FS: Fixing return type of unsigned_offsets

Fixing Sparse warning. It should return bool, instead it returns int. Signed-off-by: Pushkar Jambhlekar --- fs/read_write.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index 47c1d44..d672830 100644 ---

[PATCH] FS: Fixing return type of unsigned_offsets

Fixing Sparse warning. It should return bool, instead it returns int. Signed-off-by: Pushkar Jambhlekar --- fs/read_write.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/read_write.c b/fs/read_write.c index 47c1d44..d672830 100644 --- a/fs/read_write.c +++

[PATCH] staging: lustre: ptlrpc: remove unnecessary code

offset is an unsigned variable and, greater-than-or-equal-to-zero comparison of an unsigned variable is always true. Addresses-Coverity-ID: 1373919 Signed-off-by: Gustavo A. R. Silva --- drivers/staging/lustre/lustre/ptlrpc/layout.c | 2 +- 1 file changed, 1

[PATCH] staging: lustre: ptlrpc: remove unnecessary code

offset is an unsigned variable and, greater-than-or-equal-to-zero comparison of an unsigned variable is always true. Addresses-Coverity-ID: 1373919 Signed-off-by: Gustavo A. R. Silva --- drivers/staging/lustre/lustre/ptlrpc/layout.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH] FS: Making aproriate return type

On Thu, May 11, 2017 at 09:44:09AM +0530, Pushkar Jambhlekar wrote: > unsigned_offsets function returns fmode_t but function definition returns > int. sparse generate warning. > Updating proper return type You do realize that it's a predicate? This is actually one case where bool would be

Re: [PATCH] FS: Making aproriate return type

On Thu, May 11, 2017 at 09:44:09AM +0530, Pushkar Jambhlekar wrote: > unsigned_offsets function returns fmode_t but function definition returns > int. sparse generate warning. > Updating proper return type You do realize that it's a predicate? This is actually one case where bool would be

[PATCH] FS: Making aproriate return type

unsigned_offsets function returns fmode_t but function definition returns int. sparse generate warning. Updating proper return type Signed-off-by: Pushkar Jambhlekar --- fs/read_write.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/read_write.c

[PATCH] FS: Making aproriate return type

unsigned_offsets function returns fmode_t but function definition returns int. sparse generate warning. Updating proper return type Signed-off-by: Pushkar Jambhlekar --- fs/read_write.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/read_write.c b/fs/read_write.c index

Re: [PATCH] net: fec: select queue depending on VLAN priority

On 2017-05-09 19:42, Andy Duan wrote: > From: David Miller Sent: Tuesday, May 09, 2017 9:39 PM >>To: ste...@agner.ch >>Cc: Andy Duan ; and...@lunn.ch; >>feste...@gmail.com; net...@vger.kernel.org; linux- >>ker...@vger.kernel.org >>Subject: Re: [PATCH]

Re: [PATCH] net: fec: select queue depending on VLAN priority

On 2017-05-09 19:42, Andy Duan wrote: > From: David Miller Sent: Tuesday, May 09, 2017 9:39 PM >>To: ste...@agner.ch >>Cc: Andy Duan ; and...@lunn.ch; >>feste...@gmail.com; net...@vger.kernel.org; linux- >>ker...@vger.kernel.org >>Subject: Re: [PATCH] net: fec: select queue depending on VLAN

Re: [RFC 07/10] fscrypt: move to generic async completion

Hi Gilad, On Sat, May 06, 2017 at 03:59:56PM +0300, Gilad Ben-Yossef wrote: > int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw, > u64 lblk_num, struct page *src_page, > struct page *dest_page, unsigned int len, > @@

Re: [RFC 07/10] fscrypt: move to generic async completion

Hi Gilad, On Sat, May 06, 2017 at 03:59:56PM +0300, Gilad Ben-Yossef wrote: > int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw, > u64 lblk_num, struct page *src_page, > struct page *dest_page, unsigned int len, > @@

Re: [RFC 01/10] crypto: factor async completion for general use

Hi Gilad, On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote: > Invoking a possibly async. crypto op and waiting for completion > while correctly handling backlog processing is a common task > in the crypto API implementation and outside users of it. > > This patch re-factors one

Re: [RFC 01/10] crypto: factor async completion for general use

Hi Gilad, On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote: > Invoking a possibly async. crypto op and waiting for completion > while correctly handling backlog processing is a common task > in the crypto API implementation and outside users of it. > > This patch re-factors one

[PATCH] iommu: remove unnecessary code

did_old is an unsigned variable and, greater-than-or-equal-to-zero comparison of an unsigned variable is always true. Addresses-Coverity-ID: 1398477 Signed-off-by: Gustavo A. R. Silva --- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] iommu: remove unnecessary code

did_old is an unsigned variable and, greater-than-or-equal-to-zero comparison of an unsigned variable is always true. Addresses-Coverity-ID: 1398477 Signed-off-by: Gustavo A. R. Silva --- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 2/4] hwmon: (adt7475) fan stall prevention

By default adt7475 will stop the fans (pwm duty cycle 0%) when the temperature drops past Tmin - hysteresis. Some systems want to keep the fans moving even when the temperature drops so add new sysfs attributes that configure the enhanced acoustics min 1-3 which allows the fans to run at the

[PATCH v3 4/4] hwmon: (adt7475) add high frequency support

Systems using 4-wire fans usually require high frequency (22.5kHz) output on the pwm. Add 22500 as a valid option in the pwmfreq_table. In high frequency mode the low-order bit are ignored so they can safely be set to 0. Signed-off-by: Chris Packham --- Changes

[PATCH v3 2/4] hwmon: (adt7475) fan stall prevention

By default adt7475 will stop the fans (pwm duty cycle 0%) when the temperature drops past Tmin - hysteresis. Some systems want to keep the fans moving even when the temperature drops so add new sysfs attributes that configure the enhanced acoustics min 1-3 which allows the fans to run at the

[PATCH v3 4/4] hwmon: (adt7475) add high frequency support

Systems using 4-wire fans usually require high frequency (22.5kHz) output on the pwm. Add 22500 as a valid option in the pwmfreq_table. In high frequency mode the low-order bit are ignored so they can safely be set to 0. Signed-off-by: Chris Packham --- Changes in v3: - New

[PATCH v3 3/4] hwmon: (adt7475) temperature smoothing

When enabled temperature smoothing allows ramping the fan speed over a configurable period of time instead of jumping to the new speed instantaneously. Signed-off-by: Chris Packham --- Changes in v2: - use a single tempN_smoothing attribute Changes in v3: -

[PATCH v3 3/4] hwmon: (adt7475) temperature smoothing

When enabled temperature smoothing allows ramping the fan speed over a configurable period of time instead of jumping to the new speed instantaneously. Signed-off-by: Chris Packham --- Changes in v2: - use a single tempN_smoothing attribute Changes in v3: - change enh_acou to enh_acoustics -

Re: [PATCH] libertas: Avoid reading past end of buffer

Joe Perches writes: > unrelated trivia: > > lbs_deb_enter is used incorrectly here at > function exit as both enter and leave calls. > > That type of copy/paste defect may be common. > > $ git grep -w lbs_deb_enter | wc -l > 148 > $ git grep -w lbs_deb_leave | wc -l > 71 > >

Re: [PATCH] libertas: Avoid reading past end of buffer

Joe Perches writes: > unrelated trivia: > > lbs_deb_enter is used incorrectly here at > function exit as both enter and leave calls. > > That type of copy/paste defect may be common. > > $ git grep -w lbs_deb_enter | wc -l > 148 > $ git grep -w lbs_deb_leave | wc -l > 71 > > One would expect

[PATCH v3 1/4] hwmon: (adt7475) replace find_nearest() with find_closest()

The adt7475 has had find_nearest() since it's creation in 2009. Since then find_closest() has been introduced and several drivers have been updated to use it. Update the adt7475 to use find_closest() and remove the now unused find_nearest(). Signed-off-by: Chris Packham

[PATCH v3 1/4] hwmon: (adt7475) replace find_nearest() with find_closest()

The adt7475 has had find_nearest() since it's creation in 2009. Since then find_closest() has been introduced and several drivers have been updated to use it. Update the adt7475 to use find_closest() and remove the now unused find_nearest(). Signed-off-by: Chris Packham --- Changes in v3: - None

Re: [PATCH v7 20/26] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On Sat, 2017-05-06 at 11:04 +0200, Paolo Bonzini wrote: > > > On 05/05/2017 20:17, Ricardo Neri wrote: > > User-Mode Instruction Prevention is a security feature present in > new > > Intel processors that, when set, prevents the execution of a subset > of > > instructions if such instructions

Re: [f2fs-dev] [PATCH 1/3] f2fs: use f2fs_submit_page_bio for ra_meta_pages

On 2017/5/11 10:41, Jaegeuk Kim wrote: > On 05/11, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/5/11 7:48, Jaegeuk Kim wrote: >>> This patch avoids to use f2fs_submit_merged_bio for read, which was the only >>> read case. >> >> This makes f2fs losing the chance to merge multiple pages into one bio

Re: [PATCH v7 20/26] x86/cpufeature: Add User-Mode Instruction Prevention definitions

On Sat, 2017-05-06 at 11:04 +0200, Paolo Bonzini wrote: > > > On 05/05/2017 20:17, Ricardo Neri wrote: > > User-Mode Instruction Prevention is a security feature present in > new > > Intel processors that, when set, prevents the execution of a subset > of > > instructions if such instructions

Re: [f2fs-dev] [PATCH 1/3] f2fs: use f2fs_submit_page_bio for ra_meta_pages

On 2017/5/11 10:41, Jaegeuk Kim wrote: > On 05/11, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/5/11 7:48, Jaegeuk Kim wrote: >>> This patch avoids to use f2fs_submit_merged_bio for read, which was the only >>> read case. >> >> This makes f2fs losing the chance to merge multiple pages into one bio

Re: Lockdep splat involving all_q_mutex

On Wed, May 10, 2017 at 08:55:54PM -0600, Jens Axboe wrote: > On 05/10/2017 04:34 PM, Paul E. McKenney wrote: > > Hello! > > > > I got the lockdep splat shown below during some rcutorture testing (which > > does CPU hotplug operations) on mainline at commit dc9edaab90de ("Merge > > tag

Re: Lockdep splat involving all_q_mutex

On Wed, May 10, 2017 at 08:55:54PM -0600, Jens Axboe wrote: > On 05/10/2017 04:34 PM, Paul E. McKenney wrote: > > Hello! > > > > I got the lockdep splat shown below during some rcutorture testing (which > > does CPU hotplug operations) on mainline at commit dc9edaab90de ("Merge > > tag

Re: [RFC] adding of TGID to ftrace output

Hi Steven, Thanks for your quick reply. On Wed, May 10, 2017 at 6:28 PM, Steven Rostedt wrote: > On Wed, 10 May 2017 16:04:55 -0700 > Joel Fernandes wrote: > >> Hi Steven, >> >> Can we add TGID information along with PID to ftrace output? >> >> Something

Re: [RFC] adding of TGID to ftrace output

Hi Steven, Thanks for your quick reply. On Wed, May 10, 2017 at 6:28 PM, Steven Rostedt wrote: > On Wed, 10 May 2017 16:04:55 -0700 > Joel Fernandes wrote: > >> Hi Steven, >> >> Can we add TGID information along with PID to ftrace output? >> >> Something like: >> #

linux-next: Tree for May 11

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170510: The tpmdd tree lost its build failure. Non-merge commits (relative to Linus' tree): 697 763 files changed, 20547 insertions(+), 20505

linux-next: Tree for May 11

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170510: The tpmdd tree lost its build failure. Non-merge commits (relative to Linus' tree): 697 763 files changed, 20547 insertions(+), 20505

[PATCH] filesystem-dax: fix broken __dax_zero_page_range() conversion

The conversion of __dax_zero_page_range() to 'struct dax_operations' caused it to frequently fail. The mistake was treating the @size parameter as a dax mapping length rather than just a length of the clear_pmem() operation. The dax mapping length is assumed to be hard coded as PAGE_SIZE. Without

[PATCH] filesystem-dax: fix broken __dax_zero_page_range() conversion

The conversion of __dax_zero_page_range() to 'struct dax_operations' caused it to frequently fail. The mistake was treating the @size parameter as a dax mapping length rather than just a length of the clear_pmem() operation. The dax mapping length is assumed to be hard coded as PAGE_SIZE. Without

Re: Lockdep splat involving all_q_mutex

On 05/10/2017 04:34 PM, Paul E. McKenney wrote: > Hello! > > I got the lockdep splat shown below during some rcutorture testing (which > does CPU hotplug operations) on mainline at commit dc9edaab90de ("Merge > tag 'acpi-extra-4.12-rc1' of git://git.kernel.org/.../rafael/linux-pm"). > My kneejerk

Re: Lockdep splat involving all_q_mutex

On 05/10/2017 04:34 PM, Paul E. McKenney wrote: > Hello! > > I got the lockdep splat shown below during some rcutorture testing (which > does CPU hotplug operations) on mainline at commit dc9edaab90de ("Merge > tag 'acpi-extra-4.12-rc1' of git://git.kernel.org/.../rafael/linux-pm"). > My kneejerk

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

On 11/05/17 04:33 AM, Tommi Rantala wrote: > Hi, > > I just tested v4.11-12441-g56868a4 on HP xw6600 with radeon graphics, > and I'm seeing the following WARNING triggered constantly. > > I have not seen this earlier e.g. with the distro kernel > 4.10.13-200.fc25.x86_64 > > $ lspci|grep -i amd

Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)

On 11/05/17 04:33 AM, Tommi Rantala wrote: > Hi, > > I just tested v4.11-12441-g56868a4 on HP xw6600 with radeon graphics, > and I'm seeing the following WARNING triggered constantly. > > I have not seen this earlier e.g. with the distro kernel > 4.10.13-200.fc25.x86_64 > > $ lspci|grep -i amd

Re: [PATCH net-next V4 10/10] vhost_net: try batch dequing from skb array

On 2017年05月10日 20:34, Michael S. Tsirkin wrote: On Wed, May 10, 2017 at 11:36:22AM +0800, Jason Wang wrote: We used to dequeue one skb during recvmsg() from skb_array, this could be inefficient because of the bad cache utilization and spinlock touching for each packet. This patch tries to

Re: [PATCH net-next V4 10/10] vhost_net: try batch dequing from skb array

On 2017年05月10日 20:34, Michael S. Tsirkin wrote: On Wed, May 10, 2017 at 11:36:22AM +0800, Jason Wang wrote: We used to dequeue one skb during recvmsg() from skb_array, this could be inefficient because of the bad cache utilization and spinlock touching for each packet. This patch tries to

[RFC][Patch 0/3] securityfs: add the ability to support symlinks

Currently securityfs does not support the creation/use of symlinks. AppArmor would like to be able to use symlinks to map some policy relationships between profiles and the data set it was loaded from (patch 2), and to create a specialized magic policy tree that maps visible policy to the policy

[RFC][Patch 0/3] securityfs: add the ability to support symlinks

Currently securityfs does not support the creation/use of symlinks. AppArmor would like to be able to use symlinks to map some policy relationships between profiles and the data set it was loaded from (patch 2), and to create a specialized magic policy tree that maps visible policy to the policy

[PATCH 3/3] apparmor: virtualize the policy/ directory

virtualize the apparmor policy/ directory so that the current namespace affects what part of policy is seen. This is done by * creating a new apparmorfs filesystem * creating a magic symlink from securityfs to the correct apparmorfs file in the tree (similar to nsfs use). apparmor fs data

[PATCH 3/3] apparmor: virtualize the policy/ directory

virtualize the apparmor policy/ directory so that the current namespace affects what part of policy is seen. This is done by * creating a new apparmorfs filesystem * creating a magic symlink from securityfs to the correct apparmorfs file in the tree (similar to nsfs use). apparmor fs data

[PATCH 1/3] securityfs: add the ability to support symlinks

Signed-off-by: John Johansen Reviewed-by: Seth Arnold --- include/linux/security.h | 12 security/inode.c | 140 +-- 2 files changed, 134 insertions(+), 18 deletions(-) diff --git

[PATCH 2/3] apparmor: move to per loaddata files, instead of replicating in profiles

The loaddata sets cover more than just a single profile and should be tracked at the ns level. Move the load data files under the namespace and reference the files from the profiles via a symlink. Signed-off-by: John Johansen Reviewed-by: Seth Arnold

[PATCH 1/3] securityfs: add the ability to support symlinks

Signed-off-by: John Johansen Reviewed-by: Seth Arnold --- include/linux/security.h | 12 security/inode.c | 140 +-- 2 files changed, 134 insertions(+), 18 deletions(-) diff --git a/include/linux/security.h b/include/linux/security.h

[PATCH 2/3] apparmor: move to per loaddata files, instead of replicating in profiles

The loaddata sets cover more than just a single profile and should be tracked at the ns level. Move the load data files under the namespace and reference the files from the profiles via a symlink. Signed-off-by: John Johansen Reviewed-by: Seth Arnold --- security/apparmor/apparmorfs.c

Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote: > On Wed, May 10, 2017 at 11:31 AM, Ryder Lee wrote: > > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote: > >> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee wrote: > >> > >> > +- ranges: >

Re: [PATCH v3 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Wed, 2017-05-10 at 12:01 +0200, Arnd Bergmann wrote: > On Wed, May 10, 2017 at 11:31 AM, Ryder Lee wrote: > > On Wed, 2017-05-10 at 10:08 +0200, Arnd Bergmann wrote: > >> On Wed, May 10, 2017 at 4:07 AM, Ryder Lee wrote: > >> > >> > +- ranges: > >> > + - The first three entries are expected

Re: [f2fs-dev] [PATCH 1/3] f2fs: use f2fs_submit_page_bio for ra_meta_pages

On 05/11, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/5/11 7:48, Jaegeuk Kim wrote: > > This patch avoids to use f2fs_submit_merged_bio for read, which was the only > > read case. > > This makes f2fs losing the chance to merge multiple pages into one bio during > reading continuous physical blocks,

Re: [f2fs-dev] [PATCH 1/3] f2fs: use f2fs_submit_page_bio for ra_meta_pages

On 05/11, Chao Yu wrote: > On 2017/5/11 9:24, Chao Yu wrote: > > Hi Jaegeuk, > > > > On 2017/5/11 7:48, Jaegeuk Kim wrote: > >> This patch avoids to use f2fs_submit_merged_bio for read, which was the > >> only > >> read case. > > > > This makes f2fs losing the chance to merge multiple pages

Re: [f2fs-dev] [PATCH 1/3] f2fs: use f2fs_submit_page_bio for ra_meta_pages

On 05/11, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/5/11 7:48, Jaegeuk Kim wrote: > > This patch avoids to use f2fs_submit_merged_bio for read, which was the only > > read case. > > This makes f2fs losing the chance to merge multiple pages into one bio during > reading continuous physical blocks,

Re: [f2fs-dev] [PATCH 1/3] f2fs: use f2fs_submit_page_bio for ra_meta_pages

On 05/11, Chao Yu wrote: > On 2017/5/11 9:24, Chao Yu wrote: > > Hi Jaegeuk, > > > > On 2017/5/11 7:48, Jaegeuk Kim wrote: > >> This patch avoids to use f2fs_submit_merged_bio for read, which was the > >> only > >> read case. > > > > This makes f2fs losing the chance to merge multiple pages

Re: [PATCH 0/3] GPU-DRM-Radeon: Fine-tuning for three function implementations

On 10/05/17 08:30 PM, Christian König wrote: > Am 10.05.2017 um 02:23 schrieb Michel Dänzer: >> On 03/05/17 09:46 PM, Christian König wrote: >>> Am 02.05.2017 um 22:04 schrieb SF Markus Elfring: From: Markus Elfring Date: Tue, 2 May 2017 22:00:02 +0200

Re: [PATCH 0/3] GPU-DRM-Radeon: Fine-tuning for three function implementations

On 10/05/17 08:30 PM, Christian König wrote: > Am 10.05.2017 um 02:23 schrieb Michel Dänzer: >> On 03/05/17 09:46 PM, Christian König wrote: >>> Am 02.05.2017 um 22:04 schrieb SF Markus Elfring: From: Markus Elfring Date: Tue, 2 May 2017 22:00:02 +0200 Three update suggestions

Re: [PATCH] f2fs: split bio cache

On 05/11, Chao Yu wrote: > On 2017/5/11 7:50, Jaegeuk Kim wrote: > > On 05/09, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2017/5/9 5:23, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> I can't see a strong reason to split meta from data/node and rename the > >>> existing > >>> function names.

Re: [PATCH] f2fs: split bio cache

On 05/11, Chao Yu wrote: > On 2017/5/11 7:50, Jaegeuk Kim wrote: > > On 05/09, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2017/5/9 5:23, Jaegeuk Kim wrote: > >>> Hi Chao, > >>> > >>> I can't see a strong reason to split meta from data/node and rename the > >>> existing > >>> function names.

Re: [PATCH RT] futex/rtmutex: Cure RT double blocking issue

2017-05-09 23:11 GMT+08:00 Thomas Gleixner : > RT has a problem when the wait on a futex/rtmutex got interrupted by a > timeout or a signal. task->pi_blocked_on is still set when returning from > rt_mutex_wait_proxy_lock(). The task must acquire the hash bucket lock > after

Re: [PATCH RT] futex/rtmutex: Cure RT double blocking issue

2017-05-09 23:11 GMT+08:00 Thomas Gleixner : > RT has a problem when the wait on a futex/rtmutex got interrupted by a > timeout or a signal. task->pi_blocked_on is still set when returning from > rt_mutex_wait_proxy_lock(). The task must acquire the hash bucket lock > after this. > > If the hash

Re: [PATCH] f2fs: split bio cache

On 2017/5/11 7:50, Jaegeuk Kim wrote: > On 05/09, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/5/9 5:23, Jaegeuk Kim wrote: >>> Hi Chao, >>> >>> I can't see a strong reason to split meta from data/node and rename the >>> existing >>> function names. Instead, how about keeping the existing one

Re: [PATCH] f2fs: split bio cache

On 2017/5/11 7:50, Jaegeuk Kim wrote: > On 05/09, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2017/5/9 5:23, Jaegeuk Kim wrote: >>> Hi Chao, >>> >>> I can't see a strong reason to split meta from data/node and rename the >>> existing >>> function names. Instead, how about keeping the existing one

Re: [alsa-devel] [PATCH v2 3/3] ASoC: stm32: Add full duplex support to i2s (fwd)

org Cc: Julia Lawall <julia.law...@lip6.fr> Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: stm32: Add full duplex support to i2s Hi olivier, [auto build test WARNING on asoc/for-next] [also build test WARNING on next-20170510] [cannot apply to v4.11] [if your patch is applied to the wr

Re: [alsa-devel] [PATCH v2 3/3] ASoC: stm32: Add full duplex support to i2s (fwd)

: Re: [alsa-devel] [PATCH v2 3/3] ASoC: stm32: Add full duplex support to i2s Hi olivier, [auto build test WARNING on asoc/for-next] [also build test WARNING on next-20170510] [cannot apply to v4.11] [if your patch is applied to the wrong git tree, please drop us a note to help improve

Re: [PATCH v7 0/7] Introduce ZONE_CMA

Sorry for the late response. I was on a vacation. On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote: > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote: > > On Thu, Apr 27, 2017 at 05:06:36PM +0200, Michal Hocko wrote: > [...] > > > I see this point and I agree that using a specific zone

Re: [PATCH v7 0/7] Introduce ZONE_CMA

Sorry for the late response. I was on a vacation. On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote: > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote: > > On Thu, Apr 27, 2017 at 05:06:36PM +0200, Michal Hocko wrote: > [...] > > > I see this point and I agree that using a specific zone

  1   2   3   4   5   6   7   8   9   10   >