Re: [PATCH v4 2/4] zram: implement deduplication in zram

On Wed, Apr 26, 2017 at 11:14:52AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (04/26/17 09:52), js1...@gmail.com wrote: > [..] > > ret = scnprintf(buf, PAGE_SIZE, > > - "%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n", > > + "%8llu %8llu %8llu %8lu %8ld

Re: [PATCH v4 2/4] zram: implement deduplication in zram

On Wed, Apr 26, 2017 at 11:14:52AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (04/26/17 09:52), js1...@gmail.com wrote: > [..] > > ret = scnprintf(buf, PAGE_SIZE, > > - "%8llu %8llu %8llu %8lu %8ld %8llu %8lu\n", > > + "%8llu %8llu %8llu %8lu %8ld

Re: [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window

On 24/04/17 12:02, Lee Jones wrote: > On Fri, 14 Apr 2017, Jonathan Cameron wrote: > >> On 11/04/17 11:05, Lee Jones wrote: >>> Enjoy! >>> >>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: >>> >>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) >>> >>> are available in

Re: [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window

On 24/04/17 12:02, Lee Jones wrote: > On Fri, 14 Apr 2017, Jonathan Cameron wrote: > >> On 11/04/17 11:05, Lee Jones wrote: >>> Enjoy! >>> >>> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: >>> >>> Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) >>> >>> are available in

Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote: > On 24/04/17 03:25 PM, Gerd Hoffmann wrote: > > Return correct fourcc codes on bigendian. Drivers must be adapted to > > this change. > > > > Signed-off-by: Gerd Hoffmann > > Just to reiterate, this won't work for the

Re: [PATCH 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format

On Di, 2017-04-25 at 12:18 +0900, Michel Dänzer wrote: > On 24/04/17 03:25 PM, Gerd Hoffmann wrote: > > Return correct fourcc codes on bigendian. Drivers must be adapted to > > this change. > > > > Signed-off-by: Gerd Hoffmann > > Just to reiterate, this won't work for the radeon driver, which

Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

On 2017-04-25 09:31, Peter Meerwald-Stadler wrote: > >> This is an upstream port of an IIO driver for the TI ADC108S102 and >> ADC128S102. The former can be found on the Intel Galileo Gen2 and the >> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is >> included. > > comments

Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

On 2017-04-25 09:31, Peter Meerwald-Stadler wrote: > >> This is an upstream port of an IIO driver for the TI ADC108S102 and >> ADC128S102. The former can be found on the Intel Galileo Gen2 and the >> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is >> included. > > comments

Re: [PATCH v3 2/2] staging: iio: isl29028: move out of staging

On Wed, 2017-04-26 at 06:30 +0100, Jonathan Cameron wrote: > On 25/04/17 02:34, Brian Masney wrote: > > Move ISL29028 ALS / Proximity Sensor out of staging and into mainline. > > > > Signed-off-by: Brian Masney Hey Brian. Next time it's better to use git format-patch -M

Re: [PATCH v3 2/2] staging: iio: isl29028: move out of staging

On Wed, 2017-04-26 at 06:30 +0100, Jonathan Cameron wrote: > On 25/04/17 02:34, Brian Masney wrote: > > Move ISL29028 ALS / Proximity Sensor out of staging and into mainline. > > > > Signed-off-by: Brian Masney Hey Brian. Next time it's better to use git format-patch -M to reduce the patch

linux-next: manual merge of the scsi-mkp tree with the block tree

Hi all, Today's linux-next merge of the scsi-mkp tree got a conflict in: drivers/scsi/sd.c between commit: 81d926e8b552 ("sd: split sd_setup_discard_cmnd") from the block tree and commit: 7529fbb0080d ("scsi: sd: Fix function descriptions") from the scsi-mkp tree. I fixed it up (I

linux-next: manual merge of the scsi-mkp tree with the block tree

Hi all, Today's linux-next merge of the scsi-mkp tree got a conflict in: drivers/scsi/sd.c between commit: 81d926e8b552 ("sd: split sd_setup_discard_cmnd") from the block tree and commit: 7529fbb0080d ("scsi: sd: Fix function descriptions") from the scsi-mkp tree. I fixed it up (I

Re: Revised statx(2) man page for review

On 04/25/2017 10:06 PM, Dmitry V. Levin wrote: > On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: > [...] >>The file timestamps are structures of the following type: >> >>struct statx_timestamp { >>__s64 tv_sec;/* Seconds since

Re: Revised statx(2) man page for review

On 04/25/2017 10:06 PM, Dmitry V. Levin wrote: > On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote: > [...] >>The file timestamps are structures of the following type: >> >>struct statx_timestamp { >>__s64 tv_sec;/* Seconds since

Re: [GIT PULL rcu/urgent] Make SRCU be built by default

* Paul E. McKenney wrote: > Hello, Ingo, > > This commit causes SRCU to be built by default. This handles the > surprisingly common case where include/linux/srcu.h is included > into files being built with CONFIG_SRCU=n. The fact that there is > now a Tiny SRCU

Re: [GIT PULL rcu/urgent] Make SRCU be built by default

* Paul E. McKenney wrote: > Hello, Ingo, > > This commit causes SRCU to be built by default. This handles the > surprisingly common case where include/linux/srcu.h is included > into files being built with CONFIG_SRCU=n. The fact that there is > now a Tiny SRCU means that this should be OK

RE: [PATCH -next] ASoC: Intel: Skylake: Fix to use list_for_each_safe() when delete items

> -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Wednesday, April 26, 2017 1:38 PM > To: weiyongjun (A) > Cc: Wei Yongjun ; Liam Girdwood > ; Mark Brown ; Jaroslav > Kysela

RE: [PATCH -next] ASoC: Intel: Skylake: Fix to use list_for_each_safe() when delete items

> -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Wednesday, April 26, 2017 1:38 PM > To: weiyongjun (A) > Cc: Wei Yongjun ; Liam Girdwood > ; Mark Brown ; Jaroslav > Kysela ; Takashi Iwai ; Pardha Saradhi K > ; G Kranthi > ; Hardik T Shah > ; Jeeja KP ;

Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

On 19/04/17 15:05, Shrirang Bagul wrote: > This patch fixes the sensor platform data initialisation for st_pressure > and st_accel device drivers. Without this patch, the driver fails to > register the sensors when the user removes and re-loads the driver. > > 1. Unload the kernel modules for

Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

On 19/04/17 15:05, Shrirang Bagul wrote: > This patch fixes the sensor platform data initialisation for st_pressure > and st_accel device drivers. Without this patch, the driver fails to > register the sensors when the user removes and re-loads the driver. > > 1. Unload the kernel modules for

Re: [PATCH -next] ASoC: Intel: Skylake: Fix to use list_for_each_safe() when delete items

On Tue, Apr 25, 2017 at 07:57:57AM +, weiyongjun (A) wrote: > > > > > > Since we will remove items off the list using list_del() we need > > > to use a safe version of the list_for_each() macro aptly named > > > list_for_each_safe(). > > > > ah yes, god catch > > > > > This is detected by

Re: [PATCH -next] ASoC: Intel: Skylake: Fix to use list_for_each_safe() when delete items

On Tue, Apr 25, 2017 at 07:57:57AM +, weiyongjun (A) wrote: > > > > > > Since we will remove items off the list using list_del() we need > > > to use a safe version of the list_for_each() macro aptly named > > > list_for_each_safe(). > > > > ah yes, god catch > > > > > This is detected by

Re: [PATCH v3 1/2] staging: iio: isl29028: correct proximity sleep times

On 25/04/17 02:34, Brian Masney wrote: > The sysfs attribute in_proximity_sampling_frequency_available currently > shows the values 1 3 5 10 13 20 83 100. These values are supposed to > correspond to the sleep values 800 400 200 100 75 50 12.5 0 (all in ms). > When passing in a sampling frequency

Re: [PATCH v3 2/2] staging: iio: isl29028: move out of staging

On 25/04/17 02:34, Brian Masney wrote: > Move ISL29028 ALS / Proximity Sensor out of staging and into mainline. > > Signed-off-by: Brian Masney Applied to the togreg branch of iio.git. Thanks, Jonathan > --- > drivers/iio/light/Kconfig| 10 + >

Re: [PATCH v3 1/2] staging: iio: isl29028: correct proximity sleep times

On 25/04/17 02:34, Brian Masney wrote: > The sysfs attribute in_proximity_sampling_frequency_available currently > shows the values 1 3 5 10 13 20 83 100. These values are supposed to > correspond to the sleep values 800 400 200 100 75 50 12.5 0 (all in ms). > When passing in a sampling frequency

Re: [PATCH v3 2/2] staging: iio: isl29028: move out of staging

On 25/04/17 02:34, Brian Masney wrote: > Move ISL29028 ALS / Proximity Sensor out of staging and into mainline. > > Signed-off-by: Brian Masney Applied to the togreg branch of iio.git. Thanks, Jonathan > --- > drivers/iio/light/Kconfig| 10 + > drivers/iio/light/Makefile

Re: [PATCH] Coccinelle: api: Add offset_in_page.cocci

On Wed, 26 Apr 2017, Vaishali Thakkar wrote: > Use of offset_in_page is preferable instead of open coding. > This patch adds coccinelle script for suggesting the use of > macro offset_in_page. There are a lot of cases like the following where there were parentheses around the original code and

Re: [PATCH] Coccinelle: api: Add offset_in_page.cocci

On Wed, 26 Apr 2017, Vaishali Thakkar wrote: > Use of offset_in_page is preferable instead of open coding. > This patch adds coccinelle script for suggesting the use of > macro offset_in_page. There are a lot of cases like the following where there were parentheses around the original code and

Re: [PATCH v3 0/2] staging: iio: isl29028: move out of staging

On 25/04/17 02:34, Brian Masney wrote: > Minor cleanup to the proximity sampling to move this driver out of > staging. > > Datasheet: > http://www.intersil.com/content/dam/Intersil/documents/isl2/isl29028.pdf > > Changes since v2: > - Reject any value that is not in the >

Re: [PATCH v3 0/2] staging: iio: isl29028: move out of staging

On 25/04/17 02:34, Brian Masney wrote: > Minor cleanup to the proximity sampling to move this driver out of > staging. > > Datasheet: > http://www.intersil.com/content/dam/Intersil/documents/isl2/isl29028.pdf > > Changes since v2: > - Reject any value that is not in the >

заявка на отримання позики

Здравствуйте Вам потрібен кредит, щоб почати свій бізнес? Чи потрібно мені кредит платити Ваші рахунки? В даний час ми пропонуємо освітні кредити, комерційні кредити, позики, Кредити для сільського господарства, споживчих кредитів, автокредитів і т.д. В низькою ставкою 2%, якщо ви зацікавлені

заявка на отримання позики

Здравствуйте Вам потрібен кредит, щоб почати свій бізнес? Чи потрібно мені кредит платити Ваші рахунки? В даний час ми пропонуємо освітні кредити, комерційні кредити, позики, Кредити для сільського господарства, споживчих кредитів, автокредитів і т.д. В низькою ставкою 2%, якщо ви зацікавлені

[PATCH] fix semicolon.cocci warnings

Remove unneeded semicolons. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- mount.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/nfs/mount.c +++

[PATCH] fix semicolon.cocci warnings

Remove unneeded semicolons. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Julia Lawall Signed-off-by: Fengguang Wu --- mount.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/nfs/mount.c +++ b/fs/nfs/mount.c @@ -1134,7 +1134,7 @@ static int

Re: [PATCH] iio: tsl2583: add runtime power management support

On 25/04/17 09:06, Brian Masney wrote: > This patch adds runtime power management support to the tsl2583 driver. > The device is powered off after two seconds of inactivity. Verified that > the driver still functions correctly using a TSL2581 hooked up to a > Raspberry Pi 2. > > Signed-off-by:

Re: [PATCH] iio: tsl2583: add runtime power management support

On 25/04/17 09:06, Brian Masney wrote: > This patch adds runtime power management support to the tsl2583 driver. > The device is powered off after two seconds of inactivity. Verified that > the driver still functions correctly using a TSL2581 hooked up to a > Raspberry Pi 2. > > Signed-off-by:

RE: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

Hi, > From: Dan Williams [mailto:dan.j.willi...@intel.com] > Subject: Re: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too > early mechanism enabling > > On Tue, Apr 25, 2017 at 6:49 PM, Lv Zheng wrote: > > In the Linux kernel side, acpi_get_table() hasn't

RE: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

Hi, > From: Dan Williams [mailto:dan.j.willi...@intel.com] > Subject: Re: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too > early mechanism enabling > > On Tue, Apr 25, 2017 at 6:49 PM, Lv Zheng wrote: > > In the Linux kernel side, acpi_get_table() hasn't been fully balanced by

Re: [PATCH] iio: inkern: fix a static checker error

On 24/04/17 10:32, Peter Rosin wrote: > On 2017-04-20 23:13, Peter Rosin wrote: >> On 2017-04-20 23:12, Lars-Peter Clausen wrote: >>> On 04/20/2017 11:01 PM, Peter Rosin wrote: Avoid this smatch error: drivers/iio/inkern.c:751 iio_read_avail_channel_raw() error: double unlock

Re: [PATCH] iio: inkern: fix a static checker error

On 24/04/17 10:32, Peter Rosin wrote: > On 2017-04-20 23:13, Peter Rosin wrote: >> On 2017-04-20 23:12, Lars-Peter Clausen wrote: >>> On 04/20/2017 11:01 PM, Peter Rosin wrote: Avoid this smatch error: drivers/iio/inkern.c:751 iio_read_avail_channel_raw() error: double unlock

Re: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

On Tue, Apr 25, 2017 at 6:49 PM, Lv Zheng wrote: > In the Linux kernel side, acpi_get_table() hasn't been fully balanced by > acpi_put_table() invocations. So it is not a good timing to report errors. > The strict balanced validation count check should only be enabled after >

Re: [RFC PATCH] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

On Tue, Apr 25, 2017 at 6:49 PM, Lv Zheng wrote: > In the Linux kernel side, acpi_get_table() hasn't been fully balanced by > acpi_put_table() invocations. So it is not a good timing to report errors. > The strict balanced validation count check should only be enabled after > confirming that all

Re: linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, On Wed, 12 Apr 2017 14:30:21 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the xen-tip tree got a conflict in: > > arch/x86/xen/enlighten.c > > between commit: > > 687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820

Re: linux-next: manual merge of the xen-tip tree with the tip tree

Hi all, On Wed, 12 Apr 2017 14:30:21 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the xen-tip tree got a conflict in: > > arch/x86/xen/enlighten.c > > between commit: > > 687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 > code") > > from the

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Wed, Apr 26, 2017 at 01:45:00PM +1000, Balbir Singh wrote: > > > > static int delete_from_lru_cache(struct page *p) > > > > { > > > > + if (memcg_kmem_enabled()) > > > > + memcg_kmem_uncharge(p, 0); > > > > + > > > > > > The changelog is not quite clear, so we are

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Wed, Apr 26, 2017 at 01:45:00PM +1000, Balbir Singh wrote: > > > > static int delete_from_lru_cache(struct page *p) > > > > { > > > > + if (memcg_kmem_enabled()) > > > > + memcg_kmem_uncharge(p, 0); > > > > + > > > > > > The changelog is not quite clear, so we are

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 21:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > > So the whole thing we're doing right now

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 25/04/17 21:18, Borislav Petkov wrote: > On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote: >> And what happens when there is a scheduling event right here? >> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong >> path. > > So the whole thing we're doing right now

Re: [PATCH v2 0/2] module: Add module name to modinfo

On Tue, Apr 25, 2017 at 7:32 PM, Jessica Yu wrote: > +++ Kees Cook [21/04/17 15:35 -0700]: > >> The mod structure is accessed for the "name" field prior to validating >> sanity in check_modstruct_version(). This becomes very obvious once >> struct layout randomization is

Re: [PATCH v2 0/2] module: Add module name to modinfo

On Tue, Apr 25, 2017 at 7:32 PM, Jessica Yu wrote: > +++ Kees Cook [21/04/17 15:35 -0700]: > >> The mod structure is accessed for the "name" field prior to validating >> sanity in check_modstruct_version(). This becomes very obvious once >> struct layout randomization is happening, so instead add

[PATCH V1] i2c: xgene: Add support for I2C_FUNC_I2C functionality

From: Tin Huynh Certain I2C slave drivers, such as the pca95xx, require only I2C operations instead of SMBus extensions. This patch adds I2C_FUNC_I2C functionally to support those drivers. --- drivers/i2c/busses/i2c-xgene-slimpro.c |3 ++- 1 files changed, 2 insertions(+),

[PATCH V1] i2c: xgene: Add support for I2C_FUNC_I2C functionality

From: Tin Huynh Certain I2C slave drivers, such as the pca95xx, require only I2C operations instead of SMBus extensions. This patch adds I2C_FUNC_I2C functionally to support those drivers. --- drivers/i2c/busses/i2c-xgene-slimpro.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 7:14 PM, PaX Team wrote: > On 25 Apr 2017 at 9:39, Kees Cook wrote: > >> On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: >> > INT_MAX threads would be needed when the leaking path is locked so >> > that it can only be exercised

Re: [PATCH] x86/refcount: Implement fast refcount_t handling

On Tue, Apr 25, 2017 at 7:14 PM, PaX Team wrote: > On 25 Apr 2017 at 9:39, Kees Cook wrote: > >> On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote: >> > INT_MAX threads would be needed when the leaking path is locked so >> > that it can only be exercised once and you'll need to get normal >> >

Re: [PATCH] qla4xxx: fix spelling mistake: "Tempalate" -> "Template"

On 26/04/17 3:07 AM, "Colin King" wrote: >From: Colin Ian King > >trivial fix to spelling mistake in DEBUG2 debug message > >Signed-off-by: Colin Ian King >--- > drivers/scsi/qla4xxx/ql4_init.c | 2 +- > 1 file

Re: [PATCH] qla4xxx: fix spelling mistake: "Tempalate" -> "Template"

On 26/04/17 3:07 AM, "Colin King" wrote: >From: Colin Ian King > >trivial fix to spelling mistake in DEBUG2 debug message > >Signed-off-by: Colin Ian King >--- > drivers/scsi/qla4xxx/ql4_init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

> On 17/04/17 06:27, Viresh Kumar wrote: >> On 13-04-17, 14:42, Sudeep Holla wrote: >>> What I was referring is about power domain provider with multiple power >>> domains(simply #power-domain-cells=<1> case as explained in the >>> power-domain specification. >> >> I am not sure if we should be

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

> On 17/04/17 06:27, Viresh Kumar wrote: >> On 13-04-17, 14:42, Sudeep Holla wrote: >>> What I was referring is about power domain provider with multiple power >>> domains(simply #power-domain-cells=<1> case as explained in the >>> power-domain specification. >> >> I am not sure if we should be

Re: [PATCH v4 2/4] zram: implement deduplication in zram

On (04/26/17 09:52), js1...@gmail.com wrote: [..] > +struct zram_hash { > + spinlock_t lock; > + struct rb_root rb_root; > }; just a note. we can easily have N CPUs spinning on ->lock for __zram_dedup_get() lookup, which can invole a potentially slow zcomp_decompress() [zlib, for

Re: [PATCH v4 2/4] zram: implement deduplication in zram

On (04/26/17 09:52), js1...@gmail.com wrote: [..] > +struct zram_hash { > + spinlock_t lock; > + struct rb_root rb_root; > }; just a note. we can easily have N CPUs spinning on ->lock for __zram_dedup_get() lookup, which can invole a potentially slow zcomp_decompress() [zlib, for

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 06/03/2016 06:15 PM, Duc Dang wrote: > Do you have other suggestions? Otherwise, I will prepare a patch > following Lorenzo's approach. Duc has since left Applied for other pastures. I miss him, he's a great guy. He laid all the right groundwork for this, but the ACPI binding still needs to

Re: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 06/03/2016 06:15 PM, Duc Dang wrote: > Do you have other suggestions? Otherwise, I will prepare a patch > following Lorenzo's approach. Duc has since left Applied for other pastures. I miss him, he's a great guy. He laid all the right groundwork for this, but the ACPI binding still needs to

Re: [PATCH v4 2/4] zram: implement deduplication in zram

On (04/26/17 09:52), js1...@gmail.com wrote: [..] > > Elapsed time: out/host: 88 s > mm_stat: 8834420736 3658184579 3834208256 0 3834208256 32889 0 0 0 > > > Elapsed time: out/host: 100 s > mm_stat: 8832929792 3657329322 2832015360 0 2832015360 32609 0 952568877 > 80880336 > > It shows

Re: [PATCH v4 2/4] zram: implement deduplication in zram

On (04/26/17 09:52), js1...@gmail.com wrote: [..] > > Elapsed time: out/host: 88 s > mm_stat: 8834420736 3658184579 3834208256 0 3834208256 32889 0 0 0 > > > Elapsed time: out/host: 100 s > mm_stat: 8832929792 3657329322 2832015360 0 2832015360 32609 0 952568877 > 80880336 > > It shows

linux-next: manual merge of the tip tree with the powerpc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/kprobes.c between commits: 49e0b4658fe6 ("kprobes: Convert kprobe_lookup_name() to a function") 290e3070762a ("powerpc/kprobes: Fix handling of function offsets on ABIv2") from the powerpc tree and commit:

linux-next: manual merge of the tip tree with the powerpc tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/kprobes.c between commits: 49e0b4658fe6 ("kprobes: Convert kprobe_lookup_name() to a function") 290e3070762a ("powerpc/kprobes: Fix handling of function offsets on ABIv2") from the powerpc tree and commit:

Re: [PATCH v2 0/2] x86, refcount: Implement fast refcount overflow

On Tue, Apr 25, 2017 at 7:01 PM, PaX Team wrote: > On 25 Apr 2017 at 15:56, Kees Cook wrote: > >> This protection is a modified version of the x86 PAX_REFCOUNT >> implementation from PaX/grsecurity. This speeds up the refcount_t API by >> duplicating the existing atomic_t

Re: [PATCH v2 0/2] x86, refcount: Implement fast refcount overflow

On Tue, Apr 25, 2017 at 7:01 PM, PaX Team wrote: > On 25 Apr 2017 at 15:56, Kees Cook wrote: > >> This protection is a modified version of the x86 PAX_REFCOUNT >> implementation from PaX/grsecurity. This speeds up the refcount_t API by >> duplicating the existing atomic_t implementation with a

[PATCH V2] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

Though migrating gigantic HugeTLB pages does not sound much like real world use case, they can be affected by memory errors. Hence migration at the PGD level HugeTLB pages should be supported just to enable soft and hard offline use cases. While allocating the new gigantic HugeTLB page, it should

[PATCH V2] mm/madvise: Enable (soft|hard) offline of HugeTLB pages at PGD level

Though migrating gigantic HugeTLB pages does not sound much like real world use case, they can be affected by memory errors. Hence migration at the PGD level HugeTLB pages should be supported just to enable soft and hard offline use cases. While allocating the new gigantic HugeTLB page, it should

Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection

On Tue, Apr 25, 2017 at 5:25 PM, Jann Horn wrote: > On Wed, Apr 26, 2017 at 12:56 AM, Kees Cook wrote: >> This protection is a modified version of the x86 PAX_REFCOUNT >> implementation from PaX/grsecurity. This speeds up the refcount_t API by >>

Re: [PATCH v2 2/2] x86, refcount: Implement fast refcount overflow protection

On Tue, Apr 25, 2017 at 5:25 PM, Jann Horn wrote: > On Wed, Apr 26, 2017 at 12:56 AM, Kees Cook wrote: >> This protection is a modified version of the x86 PAX_REFCOUNT >> implementation from PaX/grsecurity. This speeds up the refcount_t API by >> duplicating the existing atomic_t implementation

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

> > > static int delete_from_lru_cache(struct page *p) > > > { > > > + if (memcg_kmem_enabled()) > > > + memcg_kmem_uncharge(p, 0); > > > + > > > > The changelog is not quite clear, so we are uncharging a page using > > memcg_kmem_uncharge for a page in swap cache/page cache? > > Hi

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

> > > static int delete_from_lru_cache(struct page *p) > > > { > > > + if (memcg_kmem_enabled()) > > > + memcg_kmem_uncharge(p, 0); > > > + > > > > The changelog is not quite clear, so we are uncharging a page using > > memcg_kmem_uncharge for a page in swap cache/page cache? > > Hi

Re: [PATCH] staging: ks7010: fix block comment style in ks_wlan_net.c

On Tue, Apr 25, 2017 at 10:59:25PM +0200, Ilia Sergachev wrote: > This is a patch to the ks_wlan_net.c file that fixes up the following warning > found by the checkpatch.pl tool: > WARNING: Block comments use a trailing */ on a separate line Good work resubmitting this following Greg's comments.

Re: [PATCH] staging: ks7010: fix block comment style in ks_wlan_net.c

On Tue, Apr 25, 2017 at 10:59:25PM +0200, Ilia Sergachev wrote: > This is a patch to the ks_wlan_net.c file that fixes up the following warning > found by the checkpatch.pl tool: > WARNING: Block comments use a trailing */ on a separate line Good work resubmitting this following Greg's comments.

[PATCH] mpt3sas_base:fix memory leak in _base_request_irq

Signed-off-by: Heloise In function _base_request_irq, variable reply_q applies for memory space 'reply_q=kzalloc()', but does not release it before the function returns, fix it. --- drivers/scsi/mpt3sas/mpt3sas_base.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] mpt3sas_base:fix memory leak in _base_request_irq

Signed-off-by: Heloise In function _base_request_irq, variable reply_q applies for memory space 'reply_q=kzalloc()', but does not release it before the function returns, fix it. --- drivers/scsi/mpt3sas/mpt3sas_base.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages

On Wed, Apr 26, 2017 at 12:10:15PM +1000, Balbir Singh wrote: > On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote: > > The commit b023f46813cd ("memory-hotplug: skip HWPoisoned page when > > offlining pages") skip the HWPoisoned pages when offlining pages, but > > this should be skipped when

Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages

On Wed, Apr 26, 2017 at 12:10:15PM +1000, Balbir Singh wrote: > On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote: > > The commit b023f46813cd ("memory-hotplug: skip HWPoisoned page when > > offlining pages") skip the HWPoisoned pages when offlining pages, but > > this should be skipped when

[PATCH] f2fs: release cp and dnode lock before IPU

From: Hou Pengyang We don't need to rewrite the page under dnode locks. Signed-off-by: Hou Pengyang Signed-off-by: Jaegeuk Kim --- fs/f2fs/data.c| 40 ++-- fs/f2fs/f2fs.h| 2 +-

[PATCH] f2fs: release cp and dnode lock before IPU

From: Hou Pengyang We don't need to rewrite the page under dnode locks. Signed-off-by: Hou Pengyang Signed-off-by: Jaegeuk Kim --- fs/f2fs/data.c| 40 ++-- fs/f2fs/f2fs.h| 2 +- fs/f2fs/gc.c | 1 + fs/f2fs/segment.c | 1 + 4 files changed,

Re: [PATCH] irqchip/mbigen: Fix the clear register offset

Hi Majun, On 2017/4/25 10:16, Majun wrote: From: MaJun Don't minus reserved interrupts (64) when get the clear register offset,because the clear register space includes the space of these 64 interrupts. Could you mention the background that there is a timeout mechanism

Re: [PATCH] irqchip/mbigen: Fix the clear register offset

Hi Majun, On 2017/4/25 10:16, Majun wrote: From: MaJun Don't minus reserved interrupts (64) when get the clear register offset,because the clear register space includes the space of these 64 interrupts. Could you mention the background that there is a timeout mechanism to clear the register

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Wed, Apr 26, 2017 at 11:54:58AM +1000, Balbir Singh wrote: > On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote: > > When page are poisoned, they should be uncharged from the root memory > > cgroup. > > > > This is required to avoid a BUG raised when the page is onlined back: > > BUG: Bad

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Wed, Apr 26, 2017 at 11:54:58AM +1000, Balbir Singh wrote: > On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote: > > When page are poisoned, they should be uncharged from the root memory > > cgroup. > > > > This is required to avoid a BUG raised when the page is onlined back: > > BUG: Bad

Re: [PATCH v4] mfd:rtsx: do retry when DMA transfer error

Hi lee.jones: I have just now resented the patch V4, please review it. steven feng Realsil Microelectronics CO. LTD. Mobile：181-6899-0403 Ext：57594 On 2017年04月26日 10:47, 冯伟linux wrote: > From: Steven Feng > > The request should be resent when DMA transfer error

Re: [PATCH v4] mfd:rtsx: do retry when DMA transfer error

Hi lee.jones: I have just now resented the patch V4, please review it. steven feng Realsil Microelectronics CO. LTD. Mobile：181-6899-0403 Ext：57594 On 2017年04月26日 10:47, 冯伟linux wrote: > From: Steven Feng > > The request should be resent when DMA transfer error occurred. > For rts5227,

Re: [PATCH v2 2/2] module: Add module name to modinfo

+++ Jon Masters [25/04/17 03:04 -0400]: Nevermind. Missread the patch as doing something different on first pass. It's good to give the kmod folks a heads up anyway (as name would be visible in modinfo), thanks Jon! On Apr 25, 2017, at 03:00, Jon Masters wrote: On

Re: [PATCH v2 2/2] module: Add module name to modinfo

+++ Jon Masters [25/04/17 03:04 -0400]: Nevermind. Missread the patch as doing something different on first pass. It's good to give the kmod folks a heads up anyway (as name would be visible in modinfo), thanks Jon! On Apr 25, 2017, at 03:00, Jon Masters wrote: On 04/21/2017 06:35 PM,

[PATCH] Coccinelle: api: Add offset_in_page.cocci

Use of offset_in_page is preferable instead of open coding. This patch adds coccinelle script for suggesting the use of macro offset_in_page. Signed-off-by: Vaishali Thakkar --- scripts/coccinelle/api/offset_in_page.cocci | 77 + 1 file

[PATCH] Coccinelle: api: Add offset_in_page.cocci

Use of offset_in_page is preferable instead of open coding. This patch adds coccinelle script for suggesting the use of macro offset_in_page. Signed-off-by: Vaishali Thakkar --- scripts/coccinelle/api/offset_in_page.cocci | 77 + 1 file changed, 77 insertions(+)

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

On Tue, 2017-04-25 at 19:28 -0700, Chandra Annamaneni wrote: > I assumed the email should be a reply to the previous email so it appears > in the thread. As to the leading spaces, it was a problem with my mail > client. > > Ill resend the patch. Did you read my suggestion to just delete these

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

On Tue, 2017-04-25 at 19:28 -0700, Chandra Annamaneni wrote: > I assumed the email should be a reply to the previous email so it appears > in the thread. As to the leading spaces, it was a problem with my mail > client. > > Ill resend the patch. Did you read my suggestion to just delete these

Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition

On Wed, Apr 26, 2017 at 4:15 AM, Jacek Anaszewski wrote: > Hi Alexandre, > > Thanks for the patch. > > On 04/25/2017 08:19 AM, Alexandre Courbot wrote: >> v4l2_m2m_job_finish(), which is called from the interrupt handler with >> slock acquired, can call the

Re: [PATCH] [media] s5p-jpeg: fix recursive spinlock acquisition

On Wed, Apr 26, 2017 at 4:15 AM, Jacek Anaszewski wrote: > Hi Alexandre, > > Thanks for the patch. > > On 04/25/2017 08:19 AM, Alexandre Courbot wrote: >> v4l2_m2m_job_finish(), which is called from the interrupt handler with >> slock acquired, can call the device_run() hook immediately if

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

On Tue, Apr 25, 2017 at 9:51 AM, Ryan Lee wrote: > ' > > On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote: >> The patch >> >>ASoC: Add support for Maxim Integrated MAX98927 Amplifier >> >> has been applied to the asoc tree at >> >>

Re: Applied "ASoC: Add support for Maxim Integrated MAX98927 Amplifier" to the asoc tree

On Tue, Apr 25, 2017 at 9:51 AM, Ryan Lee wrote: > ' > > On Thu, Apr 6, 2017 at 11:55 AM, Mark Brown wrote: >> The patch >> >>ASoC: Add support for Maxim Integrated MAX98927 Amplifier >> >> has been applied to the asoc tree at >> >>

[PATCH v4] mfd:rtsx: do retry when DMA transfer error

From: Steven Feng The request should be resent when DMA transfer error occurred. For rts5227, the clock rate needs to be reduced when error occurred. Signed-off-by: Steven Feng --- drivers/mfd/rtsx_pcr.c | 18 --

[PATCH v4] mfd:rtsx: do retry when DMA transfer error

From: Steven Feng The request should be resent when DMA transfer error occurred. For rts5227, the clock rate needs to be reduced when error occurred. Signed-off-by: Steven Feng --- drivers/mfd/rtsx_pcr.c | 18 -- include/linux/mfd/rtsx_pci.h | 5 + 2 files changed,

  1   2   3   4   5   6   7   8   9   10   >