Re: seqcount usage in xt_replace_table()

Hello On Tue, Jan 8, 2019 at 4:02 PM Andrea Parri wrote: > > Hi Anatol, > > On Tue, Jan 08, 2019 at 11:33:39AM -0800, Anatol Pomozov wrote: > > Hello folks, > > > > A bit of context what I am doing. I am trying to port KTSAN (Kernel > > Thread Sanitizer) to

seqcount usage in xt_replace_table()

Hello folks, A bit of context what I am doing. I am trying to port KTSAN (Kernel Thread Sanitizer) tool to v4.20. That tool tracks shared data usage and makes sure it is accessed in a thread-safe manner. seqlock is a synchronization primitive used by Linux kernel. KTSAN annotates

[PATCH] hwmon: ina2xx: Add per-sensor label

From: Anatol Pomazau <ana...@google.com> Some systems have a lot of power sensors and having an way to label sensor makes easier to use sensor information. Add dts property 'label' that is readable via device sysfs file 'label'. Signed-off-by: Anatol Pomozov <anatol.pomo...@

[PATCH] hwmon: ina2xx: Add per-sensor label

From: Anatol Pomazau Some systems have a lot of power sensors and having an way to label sensor makes easier to use sensor information. Add dts property 'label' that is readable via device sysfs file 'label'. Signed-off-by: Anatol Pomozov --- Documentation/devicetree/bindings/hwmon

Re: [PATCH] regmap: Add a config option for making regmap debugfs writable

Hi On Tue, Oct 13, 2015 at 10:55 AM, Mark Brown wrote: > This is deliberately not a Kconfig option because it is a terrible idea > to do this in production and making it either selectable or the default > is an invitation to abuse. What kind of abuse are you talking about? Having an easy way

[PATCH] regmap: Add a config option for making regmap debugfs writable

Instead of modifiying source code directly one should use config files. It is the standard way to set compile-time options. Signed-off-by: Anatol Pomozov --- drivers/base/regmap/Kconfig | 6 ++ drivers/base/regmap/regmap-debugfs.c | 5 ++--- 2 files changed, 8 insertions(+), 3

[PATCH] regmap: Add a config option for making regmap debugfs writable

Instead of modifiying source code directly one should use config files. It is the standard way to set compile-time options. Signed-off-by: Anatol Pomozov <anatol.pomo...@gmail.com> --- drivers/base/regmap/Kconfig | 6 ++ drivers/base/regmap/regmap-debugfs.c | 5 ++--- 2

Re: [PATCH] regmap: Add a config option for making regmap debugfs writable

Hi On Tue, Oct 13, 2015 at 10:55 AM, Mark Brown wrote: > This is deliberately not a Kconfig option because it is a terrible idea > to do this in production and making it either selectable or the default > is an invitation to abuse. What kind of abuse are you talking about?

Re: [alsa-devel] [PATCH v3] ASoC: Add support for NAU8825 codec to ASoC

t your driver > to our test platform, and then give the feedback to you. > > On 2015/7/23 上午 01:57, Anatol Pomozov wrote: >> Hi Chih-Chiang >> >> On Mon, Jul 13, 2015 at 12:33 AM, Chih-Chiang Chang >> wrote: >>> The NAU88L25 is an ultra-low power high performance a

Re: [alsa-devel] [PATCH v3] ASoC: Add support for NAU8825 codec to ASoC

the feedback to you. On 2015/7/23 上午 01:57, Anatol Pomozov wrote: Hi Chih-Chiang On Mon, Jul 13, 2015 at 12:33 AM, Chih-Chiang Chang ccchan...@nuvoton.com wrote: The NAU88L25 is an ultra-low power high performance audio codec designed for smartphone, tablet PC, and other portable devices

Re: [alsa-devel] [PATCH v3] ASoC: Add support for NAU8825 codec to ASoC

Hi Chih-Chiang On Mon, Jul 13, 2015 at 12:33 AM, Chih-Chiang Chang wrote: > The NAU88L25 is an ultra-low power high performance audio codec designed > for smartphone, tablet PC, and other portable devices by Nuvoton, now > add linux driver support for it. At ChromeOS we work with Nuvoton hw

Re: [alsa-devel] [PATCH v3] ASoC: Add support for NAU8825 codec to ASoC

Hi Chih-Chiang On Mon, Jul 13, 2015 at 12:33 AM, Chih-Chiang Chang ccchan...@nuvoton.com wrote: The NAU88L25 is an ultra-low power high performance audio codec designed for smartphone, tablet PC, and other portable devices by Nuvoton, now add linux driver support for it. At ChromeOS we work

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

Hi On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner wrote: > On Fri, 14 Nov 2014, Anatol Pomozov wrote: >> On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner wrote: >> > On Mon, 10 Nov 2014, Anatol Pomozov wrote: >> >> On Mon, Nov 10, 2014 at 1:53 AM, Thierry Redin

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

Hi On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner wrote: > On Mon, 10 Nov 2014, Anatol Pomozov wrote: >> On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding >> wrote: >> > On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote: >> >> ARM timekeep

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

Hi On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 10 Nov 2014, Anatol Pomozov wrote: On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote: ARM timekeeping

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

Hi On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner t...@linutronix.de wrote: On Fri, 14 Nov 2014, Anatol Pomozov wrote: On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 10 Nov 2014, Anatol Pomozov wrote: On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

Hi On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding wrote: > On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote: >> ARM timekeeping functionality allows to register persistent/boot clock >> dynamically. >> This code is arch-independent and can be useful on o

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

Hi On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote: ARM timekeeping functionality allows to register persistent/boot clock dynamically. This code is arch-independent and can be useful on other

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

code nicer if architecture called register_persistent_clock(_persistent_clock); and then users check if persistent_clock variable is non-NULL. On Fri, Nov 7, 2014 at 11:34 AM, Anatol Pomozov wrote: > ARM timekeeping functionality allows to register persistent/boot clock > dynamically. >

[PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

on tegra 64bit board, made sure high-resolution clock works. Signed-off-by: Anatol Pomozov --- arch/arm/include/asm/mach/time.h| 5 - arch/arm/kernel/time.c | 36 --- arch/arm/plat-omap/counter_32k.c| 9 +--- drivers/clocksource/tegra20_timer.c

Re: [PATCH] arm64: kernel: Copy register_persistent_clock() to arm64 source subtree

Hi On Fri, Nov 7, 2014 at 2:40 AM, Mark Rutland wrote: > On Fri, Nov 07, 2014 at 04:16:03AM +, Stephen Warren wrote: >> On 11/06/2014 05:25 PM, Anatol Pomozov wrote: >> > +Stephen >> > >> > This patch is for tegra20_timer that uses register_persistent_

Re: [PATCH] arm64: kernel: Copy register_persistent_clock() to arm64 source subtree

Hi On Fri, Nov 7, 2014 at 2:40 AM, Mark Rutland mark.rutl...@arm.com wrote: On Fri, Nov 07, 2014 at 04:16:03AM +, Stephen Warren wrote: On 11/06/2014 05:25 PM, Anatol Pomozov wrote: +Stephen This patch is for tegra20_timer that uses register_persistent_clock(). I did not find any

[PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

on tegra 64bit board, made sure high-resolution clock works. Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- arch/arm/include/asm/mach/time.h| 5 - arch/arm/kernel/time.c | 36 --- arch/arm/plat-omap/counter_32k.c| 9 +--- drivers

Re: [PATCH] timekeeping: Move persistent clock registration code from ARM to kernel

code nicer if architecture called register_persistent_clock(my_persistent_clock); and then users check if persistent_clock variable is non-NULL. On Fri, Nov 7, 2014 at 11:34 AM, Anatol Pomozov anatol.pomo...@gmail.com wrote: ARM timekeeping functionality allows to register persistent/boot clock

Re: [PATCH] clocksource: tegra: Port tegra20 clocksource to arm64

Hi On Thu, Nov 6, 2014 at 8:17 PM, Stephen Warren wrote: > On 11/06/2014 05:21 PM, Anatol Pomozov wrote: >> register_persistent_clock() are in different headers in arm/arm64 >> >> Tested: Compiled the driver on 64bit platform and make sure that >> it works >

[PATCH] clocksource: tegra: Port tegra20 clocksource to arm64

register_persistent_clock() are in different headers in arm/arm64 Tested: Compiled the driver on 64bit platform and make sure that it works Signed-off-by: Anatol Pomozov --- drivers/clocksource/tegra20_timer.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/clocksource

Re: [PATCH] arm64: kernel: Copy register_persistent_clock() to arm64 source subtree

, 2014 at 4:21 PM, Anatol Pomozov wrote: > This allows to port code that needs register_persistent_clock() to arm64 > > Signed-off-by: Anatol Pomozov > --- > arch/arm64/include/asm/time.h | 17 + > arch/arm64/kernel/time.c | 37 ++

[PATCH] arm64: kernel: Copy register_persistent_clock() to arm64 source subtree

This allows to port code that needs register_persistent_clock() to arm64 Signed-off-by: Anatol Pomozov --- arch/arm64/include/asm/time.h | 17 + arch/arm64/kernel/time.c | 37 + 2 files changed, 54 insertions(+) create mode 100644 arch

Re: [PATCH] clocksource: arch_timer: Mark ARMv8 system timer as 'always-on'

Hi On Thu, Nov 6, 2014 at 10:23 AM, Lorenzo Pieralisi wrote: > On Thu, Nov 06, 2014 at 05:57:19PM +0000, Anatol Pomozov wrote: >> Quoting ARMv8 Reference Manual section D6.1: >> "The system counter must be implemented in an always-on power domain." > > Do not mix

Re: [PATCH] clocksource: arch_timer: Mark ARMv8 system timer as 'always-on'

Hi On Thu, Nov 6, 2014 at 10:09 AM, Marc Zyngier wrote: > Hi Anatol, > > On 2014-11-06 17:57, Anatol Pomozov wrote: >> >> Quoting ARMv8 Reference Manual section D6.1: >> "The system counter must be implemented in an always-on power domain." > > > Y

[PATCH] clocksource: arch_timer: Mark ARMv8 system timer as 'always-on'

g on ARMv8 board with only one timer (arm arch timer). If 'always-on' is false then it disables high-resolution timer functionality. Signed-off-by: Anatol Pomozov --- .../devicetree/bindings/arm/arch_timer.txt | 8 ++-- drivers/clocksource/arm_arch_timer.c

[PATCH] clocksource: arch_timer: Mark ARMv8 system timer as 'always-on'

board with only one timer (arm arch timer). If 'always-on' is false then it disables high-resolution timer functionality. Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- .../devicetree/bindings/arm/arch_timer.txt | 8 ++-- drivers/clocksource/arm_arch_timer.c

Re: [PATCH] clocksource: arch_timer: Mark ARMv8 system timer as 'always-on'

Hi On Thu, Nov 6, 2014 at 10:09 AM, Marc Zyngier marc.zyng...@arm.com wrote: Hi Anatol, On 2014-11-06 17:57, Anatol Pomozov wrote: Quoting ARMv8 Reference Manual section D6.1: The system counter must be implemented in an always-on power domain. Yes. And the key words here are system

Re: [PATCH] clocksource: arch_timer: Mark ARMv8 system timer as 'always-on'

Hi On Thu, Nov 6, 2014 at 10:23 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com wrote: On Thu, Nov 06, 2014 at 05:57:19PM +, Anatol Pomozov wrote: Quoting ARMv8 Reference Manual section D6.1: The system counter must be implemented in an always-on power domain. Do not mix up the system

[PATCH] arm64: kernel: Copy register_persistent_clock() to arm64 source subtree

This allows to port code that needs register_persistent_clock() to arm64 Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- arch/arm64/include/asm/time.h | 17 + arch/arm64/kernel/time.c | 37 + 2 files changed, 54 insertions

Re: [PATCH] arm64: kernel: Copy register_persistent_clock() to arm64 source subtree

, 2014 at 4:21 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: This allows to port code that needs register_persistent_clock() to arm64 Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- arch/arm64/include/asm/time.h | 17 + arch/arm64/kernel/time.c | 37

[PATCH] clocksource: tegra: Port tegra20 clocksource to arm64

register_persistent_clock() are in different headers in arm/arm64 Tested: Compiled the driver on 64bit platform and make sure that it works Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- drivers/clocksource/tegra20_timer.c | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH] clocksource: tegra: Port tegra20 clocksource to arm64

Hi On Thu, Nov 6, 2014 at 8:17 PM, Stephen Warren swar...@nvidia.com wrote: On 11/06/2014 05:21 PM, Anatol Pomozov wrote: register_persistent_clock() are in different headers in arm/arm64 Tested: Compiled the driver on 64bit platform and make sure that it works I assume it works refers

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

Hi On Fri, Oct 10, 2014 at 3:45 PM, Tom Gundersen wrote: > On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov > wrote: >> 1) Why not to make the timeout configurable through config file? There >> is already udev.conf you can put config option there. Thus people with >> mo

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

Hi On Fri, Oct 10, 2014 at 3:45 PM, Tom Gundersen t...@jklm.no wrote: On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: 1) Why not to make the timeout configurable through config file? There is already udev.conf you can put config option there. Thus people

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

Hi On Fri, Sep 12, 2014 at 1:09 PM, Luis R. Rodriguez wrote: > On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen wrote: >> On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez >> wrote: >>> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote: How about simply introducing a new flag to

Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM

Hi On Fri, Sep 12, 2014 at 1:09 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen t...@jklm.no wrote: On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen

Re: hanging aio process

Hi On Wed, May 21, 2014 at 1:48 AM, Sebastian Ott wrote: > On Wed, 21 May 2014, Sebastian Ott wrote: >> On Tue, 20 May 2014, Anatol Pomozov wrote: >> > On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott >> > wrote: >> > > On Tue, 20 May 2014, Anatol Pomozov w

Re: hanging aio process

Hi On Wed, May 21, 2014 at 1:48 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Wed, 21 May 2014, Sebastian Ott wrote: On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Anatol Pomozov

Re: hanging aio process

Hi On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott wrote: > Hi, > > On Tue, 20 May 2014, Anatol Pomozov wrote: >> On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott >> wrote: >> > On Tue, 20 May 2014, Sebastian Ott wrote: >> >> On Mon, 19 May 2014, Benj

Re: hanging aio process

Hi On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott wrote: > On Tue, 20 May 2014, Sebastian Ott wrote: >> On Mon, 19 May 2014, Benjamin LaHaise wrote: >> > It is entirely possible the bug isn't >> > caused by the referenced commit, as the commit you're pointing to merely >> > makes io_destroy()

Re: hanging aio process

Hi On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Sebastian Ott wrote: On Mon, 19 May 2014, Benjamin LaHaise wrote: It is entirely possible the bug isn't caused by the referenced commit, as the commit you're pointing to merely makes

Re: hanging aio process

Hi On Tue, May 20, 2014 at 11:09 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: Hi, On Tue, 20 May 2014, Anatol Pomozov wrote: On Tue, May 20, 2014 at 6:16 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: On Tue, 20 May 2014, Sebastian Ott wrote: On Mon, 19 May 2014, Benjamin

Re: hanging aio process

Hi On Mon, May 19, 2014 at 10:38 AM, Sebastian Ott wrote: > Hello, > > on the latest kernel a fio job with 4 workers using libaio hangs. > > git bisect points to: > commit e02ba72aabfade4c9cd6e3263e9b57bf890ad25c > Author: Anatol Pomozov > Dat

Re: hanging aio process

Hi On Mon, May 19, 2014 at 10:38 AM, Sebastian Ott seb...@linux.vnet.ibm.com wrote: Hello, on the latest kernel a fio job with 4 workers using libaio hangs. git bisect points to: commit e02ba72aabfade4c9cd6e3263e9b57bf890ad25c Author: Anatol Pomozov anatol.pomo...@gmail.com

Re: [PATCH net 1/3] kref: add kref_sub_return

Hi On Wed, Feb 12, 2014 at 9:35 AM, Michael S. Tsirkin wrote: > On Wed, Feb 12, 2014 at 08:56:30AM -0800, Greg Kroah-Hartman wrote: >> On Wed, Feb 12, 2014 at 06:38:21PM +0200, Michael S. Tsirkin wrote: >> > It is sometimes useful to get the value of the reference count after >> > decrement. >>

Re: [PATCH net 1/3] kref: add kref_sub_return

Hi On Wed, Feb 12, 2014 at 9:35 AM, Michael S. Tsirkin m...@redhat.com wrote: On Wed, Feb 12, 2014 at 08:56:30AM -0800, Greg Kroah-Hartman wrote: On Wed, Feb 12, 2014 at 06:38:21PM +0200, Michael S. Tsirkin wrote: It is sometimes useful to get the value of the reference count after

Re: Solving M produces N consumers scalability problem

Hi Thanks for your reply On Mon, Nov 4, 2013 at 10:53 AM, Andi Kleen wrote: > Anatol Pomozov writes: >> >> One idea is not to use the spin_lock. It is the 'fair spin_lock' that >> has scalability problems >> http://pdos.csail.mit.edu/papers/linux:lock.pdf Maybe loc

Re: Solving M produces N consumers scalability problem

Hi Thanks for your reply On Mon, Nov 4, 2013 at 10:53 AM, Andi Kleen a...@firstfloor.org wrote: Anatol Pomozov anatol.pomo...@gmail.com writes: One idea is not to use the spin_lock. It is the 'fair spin_lock' that has scalability problems http://pdos.csail.mit.edu/papers/linux:lock.pdf

Solving M produces N consumers scalability problem

Hi, I am looking at fuse scalabily issue that I hit recently on my multi-socket server machines http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/13490 The short description is that we have several thousands threads that make filesystem access to a fuse fs. Fuse spawns several

Solving M produces N consumers scalability problem

Hi, I am looking at fuse scalabily issue that I hit recently on my multi-socket server machines http://permalink.gmane.org/gmane.comp.file-systems.fuse.devel/13490 The short description is that we have several thousands threads that make filesystem access to a fuse fs. Fuse spawns several

Re: mm: Export 'pageflag_names' array

Hi On Tue, Oct 8, 2013 at 5:40 AM, Dave Anderson wrote: > > > - Original Message - >> Hi Anatol, >> >> On Mon, Oct 07, 2013 at 10:53:32AM -0700, Anatol Pomozov wrote: >> > Hi Wu >> > >> > I have a request wrt your old commit 718a3

Re: [PATCH] core: Catch overflows in do_div() function

Hi On Tue, Oct 8, 2013 at 10:28 AM, Anatol Pomozov wrote: > Hi > > On Tue, Oct 8, 2013 at 9:45 AM, Richard Weinberger > wrote: >> On Tue, Oct 8, 2013 at 6:18 PM, Joe Perches wrote: >>> On Tue, 2013-10-08 at 09:10 -0700, Anatol Pomozov wrote: >>>> If s

Re: [PATCH] core: Catch overflows in do_div() function

Hi On Tue, Oct 8, 2013 at 9:45 AM, Richard Weinberger wrote: > On Tue, Oct 8, 2013 at 6:18 PM, Joe Perches wrote: >> On Tue, 2013-10-08 at 09:10 -0700, Anatol Pomozov wrote: >>> If second parameter passed to this function was 64 then it silently >>> truncates to 32

[PATCH] core: Catch overflows in do_div() function

If second parameter passed to this function was 64 then it silently truncates to 32 bits. Catch such situation. Signed-off-by: Anatol Pomozov --- include/asm-generic/div64.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h index

[PATCH] core: Catch overflows in do_div() function

If second parameter passed to this function was 64 then it silently truncates to 32 bits. Catch such situation. Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- include/asm-generic/div64.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/asm-generic/div64.h b/include/asm

Re: [PATCH] core: Catch overflows in do_div() function

Hi On Tue, Oct 8, 2013 at 9:45 AM, Richard Weinberger richard.weinber...@gmail.com wrote: On Tue, Oct 8, 2013 at 6:18 PM, Joe Perches j...@perches.com wrote: On Tue, 2013-10-08 at 09:10 -0700, Anatol Pomozov wrote: If second parameter passed to this function was 64 then it silently truncates

Re: [PATCH] core: Catch overflows in do_div() function

Hi On Tue, Oct 8, 2013 at 10:28 AM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Hi On Tue, Oct 8, 2013 at 9:45 AM, Richard Weinberger richard.weinber...@gmail.com wrote: On Tue, Oct 8, 2013 at 6:18 PM, Joe Perches j...@perches.com wrote: On Tue, 2013-10-08 at 09:10 -0700, Anatol Pomozov

Re: mm: Export 'pageflag_names' array

Hi On Tue, Oct 8, 2013 at 5:40 AM, Dave Anderson ander...@redhat.com wrote: - Original Message - Hi Anatol, On Mon, Oct 07, 2013 at 10:53:32AM -0700, Anatol Pomozov wrote: Hi Wu I have a request wrt your old commit 718a38211. I think it makes sense to export array

mm: Export 'pageflag_names' array

Hi Wu I have a request wrt your old commit 718a38211. I think it makes sense to export array pageflag_names so kernel dump debug tools (like 'crash') can use it as well. Currently the tool hard-codes flag names but it is suboptimal as flags are different for different configs. What do you

mm: Export 'pageflag_names' array

Hi Wu I have a request wrt your old commit 718a38211. I think it makes sense to export array pageflag_names so kernel dump debug tools (like 'crash') can use it as well. Currently the tool hard-codes flag names but it is suboptimal as flags are different for different configs. What do you

Re: [PATCH 1/2] Revert "Revert "math64: New div64_u64_rem helper""

Hi, On Fri, Aug 9, 2013 at 12:56 PM, Mike Snitzer wrote: > This reverts commit f3002134158092178be81339ec5a22ff80e6c308. > > div64_u64_rem was removed because there were no other users. In the light of this discussion https://lkml.org/lkml/2013/8/30/417 we will have more users of div64_u64_rem

Re: do_div() silently truncates "base" to 32bit

Hi On Fri, Aug 30, 2013 at 5:50 PM, Anatol Pomozov wrote: > Hi, Joe > > On Fri, Aug 30, 2013 at 4:28 PM, Joe Perches wrote: >> On Fri, 2013-08-30 at 15:48 -0700, Randy Dunlap wrote: >>> On 08/30/13 15:14, Anatol Pomozov wrote: >>> > But another question still

Re: do_div() silently truncates base to 32bit

Hi On Fri, Aug 30, 2013 at 5:50 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Hi, Joe On Fri, Aug 30, 2013 at 4:28 PM, Joe Perches j...@perches.com wrote: On Fri, 2013-08-30 at 15:48 -0700, Randy Dunlap wrote: On 08/30/13 15:14, Anatol Pomozov wrote: But another question still remains

Re: [PATCH 1/2] Revert Revert math64: New div64_u64_rem helper

Hi, On Fri, Aug 9, 2013 at 12:56 PM, Mike Snitzer snit...@redhat.com wrote: This reverts commit f3002134158092178be81339ec5a22ff80e6c308. div64_u64_rem was removed because there were no other users. In the light of this discussion https://lkml.org/lkml/2013/8/30/417 we will have more users of

Re: do_div() silently truncates "base" to 32bit

Hi, Joe On Fri, Aug 30, 2013 at 4:28 PM, Joe Perches wrote: > On Fri, 2013-08-30 at 15:48 -0700, Randy Dunlap wrote: >> On 08/30/13 15:14, Anatol Pomozov wrote: >> > But another question still remains: why compiler does not warn that >> > size truncation happens? How t

Re: do_div() silently truncates "base" to 32bit

Hi On Fri, Aug 30, 2013 at 2:23 PM, Randy Dunlap wrote: > On 08/30/13 10:21, Anatol Pomozov wrote: >> Hi, >> >> >> I was debugging weird "zero divide" problem in CFQ code below >> >> >> static u64 cfqg_prfill_avg_queue_size(struct seq_

do_div() silently truncates "base" to 32bit

Hi, I was debugging weird "zero divide" problem in CFQ code below static u64 cfqg_prfill_avg_queue_size(struct seq_file *sf, struct blkg_policy_data *pd, int off) { struct cfq_group *cfqg = pd_to_cfqg(pd); u64 samples = blkg_stat_read(>stats.avg_queue_size_samples); u64 v =

do_div() silently truncates base to 32bit

Hi, I was debugging weird zero divide problem in CFQ code below static u64 cfqg_prfill_avg_queue_size(struct seq_file *sf, struct blkg_policy_data *pd, int off) { struct cfq_group *cfqg = pd_to_cfqg(pd); u64 samples = blkg_stat_read(cfqg-stats.avg_queue_size_samples); u64 v =

Re: do_div() silently truncates base to 32bit

Hi On Fri, Aug 30, 2013 at 2:23 PM, Randy Dunlap rdun...@infradead.org wrote: On 08/30/13 10:21, Anatol Pomozov wrote: Hi, I was debugging weird zero divide problem in CFQ code below static u64 cfqg_prfill_avg_queue_size(struct seq_file *sf, struct blkg_policy_data *pd, int off

Re: do_div() silently truncates base to 32bit

Hi, Joe On Fri, Aug 30, 2013 at 4:28 PM, Joe Perches j...@perches.com wrote: On Fri, 2013-08-30 at 15:48 -0700, Randy Dunlap wrote: On 08/30/13 15:14, Anatol Pomozov wrote: But another question still remains: why compiler does not warn that size truncation happens? How to prevent bugs like

[PATCH] kref: minor cleanup

* make warning smp-safe * result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error * minor stylistic fixes Link: https://lkml.org/lkml/2013/4/12/391 Tested: compile x86, boot machine and run xfstests Signed-off-by: Anatol Pomozov --- include/linux

[PATCH] kref: minor cleanup

* make warning smp-safe * result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error * minor stylistic fixes Link: https://lkml.org/lkml/2013/4/12/391 Tested: compile x86, boot machine and run xfstests Signed-off-by: Anatol Pomozov anatol.pomo

Re: [PATCH] kref: minor cleanup

Hi On Sat, Apr 20, 2013 at 3:34 PM, Greg KH wrote: > On Sat, Apr 20, 2013 at 09:15:10AM -0700, Anatol Pomozov wrote: >> Follow-up for https://lkml.org/lkml/2013/4/12/391 > > That's not needed in a changelog comment. > >> * make warning smp-safe >> * result of atomic

Re: [PATCH] kref: minor cleanup

Hi On Sat, Apr 20, 2013 at 3:34 PM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Apr 20, 2013 at 09:15:10AM -0700, Anatol Pomozov wrote: Follow-up for https://lkml.org/lkml/2013/4/12/391 That's not needed in a changelog comment. * make warning smp-safe * result of atomic _unless_zero

[PATCH] kref: minor cleanup

Follow-up for https://lkml.org/lkml/2013/4/12/391 * make warning smp-safe * result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error Signed-off-by: Anatol Pomozov --- include/linux/kobject.h | 1 + include/linux/kref.h| 9 ++--- lib

[PATCH] kref: minor cleanup

Follow-up for https://lkml.org/lkml/2013/4/12/391 * make warning smp-safe * result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- include/linux/kobject.h | 1 + include/linux/kref.h| 9

Re: [PATCH] kref: minor cleanup

Hi On Fri, Apr 19, 2013 at 7:24 PM, Greg KH wrote: > On Fri, Apr 19, 2013 at 06:33:54PM -0700, Anatol Pomozov wrote: >> Follow-up for https://lkml.org/lkml/2013/4/12/391 >> >> * make warning smp-safe >> * result of atomic _unless_zero functions should be checked by

[PATCH] kref: minor cleanup

Follow-up for https://lkml.org/lkml/2013/4/12/391 * make warning smp-safe * result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error Signed-off-by: Anatol Pomozov --- include/linux/kref.h | 9 ++--- lib/kobject.c| 3 ++- 2 files changed

[PATCH] kref: minor cleanup

Follow-up for https://lkml.org/lkml/2013/4/12/391 * make warning smp-safe * result of atomic _unless_zero functions should be checked by caller to avoid use-after-free error Signed-off-by: Anatol Pomozov anatol.pomo...@gmail.com --- include/linux/kref.h | 9 ++--- lib/kobject.c

Re: [PATCH] kref: minor cleanup

Hi On Fri, Apr 19, 2013 at 7:24 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Apr 19, 2013 at 06:33:54PM -0700, Anatol Pomozov wrote: Follow-up for https://lkml.org/lkml/2013/4/12/391 * make warning smp-safe * result of atomic _unless_zero functions should be checked by caller

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Sat, Apr 13, 2013 at 8:35 PM, Al Viro wrote: > On Fri, Apr 12, 2013 at 04:47:50PM -0700, Linus Torvalds wrote: >> This is a much more generic bug in kobjects, and I would hate to add >> some random workaround for just one case of this bug like you do. The >> more fundamental bug needs to

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Sat, Apr 13, 2013 at 10:53 AM, Linus Torvalds wrote: > On Sat, Apr 13, 2013 at 8:41 AM, Anatol Pomozov > wrote: >> >> Does it make sense to move it to a separate function in kref.h? >> >> /** Useful when kref_get is racing with kref_put and r

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Fri, Apr 12, 2013 at 4:47 PM, Linus Torvalds wrote: > On Fri, Apr 12, 2013 at 3:32 PM, Anatol Pomozov > wrote: >> >> Here is timeline for the crash in case if kset_find_obj() searches for >> an object tht nobody holds and other thread is doing kobject_put(

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Fri, Apr 12, 2013 at 4:47 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Fri, Apr 12, 2013 at 3:32 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Here is timeline for the crash in case if kset_find_obj() searches for an object tht nobody holds and other thread is doing

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Sat, Apr 13, 2013 at 10:53 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Sat, Apr 13, 2013 at 8:41 AM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Does it make sense to move it to a separate function in kref.h? /** Useful when kref_get is racing with kref_put

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Sat, Apr 13, 2013 at 8:35 PM, Al Viro v...@zeniv.linux.org.uk wrote: On Fri, Apr 12, 2013 at 04:47:50PM -0700, Linus Torvalds wrote: This is a much more generic bug in kobjects, and I would hate to add some random workaround for just one case of this bug like you do. The more

Re: [PATCH] module: Fix race condition between load and unload module

I ran the test case for ~30 minutes and no crash. Before the patch it took ~10 seconds for me to repro the crash. The only harmless warning I see is [ 1553.658421] [ cut here ] [ 1553.663211] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xbb/0xe0() [ 1553.669571]

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Fri, Apr 12, 2013 at 4:53 PM, Greg Kroah-Hartman wrote: > On Fri, Apr 12, 2013 at 04:47:50PM -0700, Linus Torvalds wrote: >> On Fri, Apr 12, 2013 at 3:32 PM, Anatol Pomozov >> wrote: >> > >> > Here is timeline for the crash in case if kset_find_obj() searc

[PATCH] module: Fix race condition between load and unload module

hat kset_find_obj() is not thread-safe with kobject_put() if no external refcounts are held. Other kset_find_obj() callers should be checked and made sure they do not race with kobject_put(). Signed-off-by: Anatol Pomozov --- include/linux/kobject.h | 1 + include/linux/kref.h| 8 +--- kernel/modu

[PATCH] module: Fix race condition between load and unload module

-by: Anatol Pomozov anatol.pomo...@gmail.com --- include/linux/kobject.h | 1 + include/linux/kref.h| 8 +--- kernel/module.c | 5 + lib/kobject.c | 48 +++- 4 files changed, 54 insertions(+), 8 deletions(-) diff --git

Re: [PATCH] module: Fix race condition between load and unload module

Hi On Fri, Apr 12, 2013 at 4:53 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Apr 12, 2013 at 04:47:50PM -0700, Linus Torvalds wrote: On Fri, Apr 12, 2013 at 3:32 PM, Anatol Pomozov anatol.pomo...@gmail.com wrote: Here is timeline for the crash in case if kset_find_obj

Re: [PATCH] module: Fix race condition between load and unload module

I ran the test case for ~30 minutes and no crash. Before the patch it took ~10 seconds for me to repro the crash. The only harmless warning I see is [ 1553.658421] [ cut here ] [ 1553.663211] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0xbb/0xe0() [ 1553.669571]

Re: [PATCH] loop: prevent bdev freeing while device in use

Hi On Mon, Apr 1, 2013 at 3:53 PM, Linus Torvalds wrote: > On Mon, Apr 1, 2013 at 10:00 AM, Anatol Pomozov > wrote: >> Hi >> >> On Mon, Apr 1, 2013 at 8:16 AM, Linus Torvalds >> wrote: >>> On Mon, Apr 1, 2013 at 4:58 AM, Anatol Pomozov >>> wr

Re: [PATCH] loop: prevent bdev freeing while device in use

Hi On Mon, Apr 1, 2013 at 8:16 AM, Linus Torvalds wrote: > On Mon, Apr 1, 2013 at 4:58 AM, Anatol Pomozov > wrote: >> >> To prevent use-after-free we need to hold device inode in loop_set_fd() >> and put it later in loop_clr_fd(). > > Is there something that gu

  1   2   >