Re: [PATCH] pci-error-recover: doc cleanup

[Linas Vepstas]

I suppose I'm confused, but I recall that link resets are non-fatal.
Fatal errors typically require that the the pci adapter be completely
reset, any adapter firmware to be reloaded from scratch, the device
driver has to kill all device state and start from scratch. Its huge.
If the fatal error is on pci device that is under a block device
holding a file system, then (usually) there is no way to recover,
because the block layer (and file system) cannot deal with a block
device that disappeared and then reappeared some few seconds later.
(maybe some future zfs or lvm or btrfs might be able to deal with
this, but not today)

By contrast, link resets are far more gentle: the device driver might
have to discard some half-full FIFO's, or cancel some in-flight
commands, but can otherwise gracefully recover without telling the
higher layers that there were any problems.

--linas

On Thu, Dec 8, 2016 at 10:13 PM, Cao jin  wrote:
>
>
> On 12/08/2016 10:05 PM, Jonathan Corbet wrote:
>> On Thu, 8 Dec 2016 16:16:14 +0800
>> Cao jin  wrote:
>>
>>>  The platform resets the link, and then calls the link_reset() callback
>>>  on all affected device drivers.  This is a PCI-Express specific state
>>> -and is done whenever a non-fatal error has been detected that can be
>>> +and is done whenever a fatal error has been detected that can be
>>>  "solved" by resetting the link. This call informs the driver of the
>>
>> As far as I can tell, the original text was correct here; why do you
>> think this change needs to be made?
>>
>
> See do_recovery() in aer core, reset_link() is called only seeing fatal
> error.
>
> --
> Sincerely,
> Cao jin
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] watchdog: nic7018_wdt: Add NIC7018 watchdog driver

[Hui Chun Ong]

On Thu, 2016-12-08 at 06:15 -0800, Guenter Roeck wrote:
> On 12/08/2016 01:19 AM, Hui Chun Ong wrote:
> > 
> > On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:
> > > 
> > > On 11/15/2016 07:21 PM, Hui Chun Ong wrote:
> > > > 
> > > > 
> > > > Add support for the watchdog timer on PXI Embedded Controller.
> > > > 
> > > > Signed-off-by: Hui Chun Ong 
> > > > ---
> > > > v1: Remove non-standard attributes.
> > > > Change from acpi_driver to platform_driver.
> > > > Rename driver from ni7018_wdt to nic7018_wdt.
> > > > ---
> > > >  Documentation/watchdog/watchdog-parameters.txt |   5 +
> > > >  drivers/watchdog/Kconfig   |  10 +
> > > >  drivers/watchdog/Makefile  |   1 +
> > > >  drivers/watchdog/nic7018_wdt.c | 303 
> > > > +
> > > >  4 files changed, 319 insertions(+)
> > > >  create mode 100644 drivers/watchdog/nic7018_wdt.c
> > > > 
> > > > diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> > > > b/Documentation/watchdog/watchdog-parameters.txt
> > > > index a8d3642..bd142fa 100644
> > > > --- a/Documentation/watchdog/watchdog-parameters.txt
> > > > +++ b/Documentation/watchdog/watchdog-parameters.txt
> > > > @@ -209,6 +209,11 @@ timeout: Initial watchdog timeout in seconds (0
> > > >  nowayout: Watchdog cannot be stopped once started
> > > >     (default=kernel config parameter)
> > > >  -
> > > > +nic7018_wdt:
> > > > +timeout: Initial watchdog timeout in seconds (0
> > > > +nowayout: Watchdog cannot be stopped once started
> > > > +   (default=kernel config parameter)
> > > > +-
> > > >  nuc900_wdt:
> > > >  heartbeat: Watchdog heartbeats in seconds.
> > > >     (default = 15)
> > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > > > index fdd3228..79fb224 100644
> > > > --- a/drivers/watchdog/Kconfig
> > > > +++ b/drivers/watchdog/Kconfig
> > > > @@ -1325,6 +1325,16 @@ config NI903X_WDT
> > > >       To compile this driver as a module, choose M here: the module 
> > > > will be
> > > >       called ni903x_wdt.
> > > > 
> > > > +config NIC7018_WDT
> > > > +   tristate "NIC7018 Watchdog"
> > > > +   depends on X86 && ACPI
> > > > +   select WATCHDOG_CORE
> > > > +   ---help---
> > > > +     This is the device driver for National Instruments NIC7018 
> > > > Watchdog.
> > > > +
> > > This should describe what the watchdog is for.
> > > 
> > > "Support for National Instruments NIC7018 Watchdog".
> > > 
> > > > 
> > > > 
> > > > +     To compile this driver as a module, choose M here: the module 
> > > > will be
> > > > +     called nic7018_wdt.
> > > > +
> > > >  # M32R Architecture
> > > > 
> > > >  # M68K Architecture
> > > > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > > > index caa9f4a..bd88e2e 100644
> > > > --- a/drivers/watchdog/Makefile
> > > > +++ b/drivers/watchdog/Makefile
> > > > @@ -139,6 +139,7 @@ obj-$(CONFIG_INTEL_SCU_WATCHDOG) += 
> > > > intel_scu_watchdog.o
> > > >  obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
> > > >  obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
> > > >  obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> > > > +obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> > > > 
> > > >  # M32R Architecture
> > > > 
> > > > diff --git a/drivers/watchdog/nic7018_wdt.c 
> > > > b/drivers/watchdog/nic7018_wdt.c
> > > > new file mode 100644
> > > > index 000..780edc6
> > > > --- /dev/null
> > > > +++ b/drivers/watchdog/nic7018_wdt.c
> > > > @@ -0,0 +1,303 @@
> > > > +/*
> > > > + * Copyright (C) 2016 National Instruments Corp.
> > > > + *
> > > > + * This program is free software; you can redistribute it and/or modify
> > > > + * it under the terms of the GNU General Public License as published by
> > > > + * the Free Software Foundation; either version 2 of the License, or
> > > > + * (at your option) any later version.
> > > > + *
> > > > + * This program is distributed in the hope that it will be useful,
> > > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > > + * GNU General Public License for more details.
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#define LOCK   0xA5
> > > > +#define UNLOCK 0x5A
> > > > +
> > > > +#define WDT_CTRL_RESET_EN  BIT(7)
> > > > +#define WDT_RELOAD_PORT_EN BIT(7)
> > > > +
> > > Should include linux/bitops.h
> > > 
> > > > 
> > > > 
> > > > +#define WDT_CTRL   1
> > > > +#define WDT_RELOAD_CTRL2
> > > > +#define WDT_PRESET_PRESCALE4
> > > > +#define WDT_REG_LOCK   5
> > > > +#define WDT_COUNT  6
> > > > +#define WDT_RELOAD_PORT

Re: [PATCH] doc: Explain light-handed markup preference a bit better

[Daniel Vetter]

On Thu, Dec 8, 2016 at 10:10 AM, Mauro Carvalho Chehab
 wrote:
> Em Wed, 7 Dec 2016 12:39:24 -0700
> Jonathan Corbet  escreveu:
>
>> On Wed,  7 Dec 2016 16:42:58 +0100
>> Daniel Vetter  wrote:
>>
>> > We already had a super-short blurb, but worth extending it I think:
>> > We're still pretty far away from anything like a consensus, but
>> > there's clearly a lot of people who prefer an as-light as possible
>> > approach to converting existing .txt files to .rst. Make sure this is
>> > properly taken into account and clear.
>> >
>> > Motivated by discussions with Peter and Christoph and others.
>>
>> I do think we should put something in to guide people in the right
>> direction.  And yes, it should, itself, be light-handed and minimal.
>>
>> [...]
>>
>> >  Documentation/kernel-documentation.rst | 28 ++--
>> >  1 file changed, 26 insertions(+), 2 deletions(-)
>>
>> I do, however, also believe that it should apply to relatively recent
>> docs-next :)
>>
>> > diff --git a/Documentation/kernel-documentation.rst 
>> > b/Documentation/kernel-documentation.rst
>> > index 0dd17069bc0b..5bffe5a418aa 100644
>> > --- a/Documentation/kernel-documentation.rst
>> > +++ b/Documentation/kernel-documentation.rst
>> > @@ -77,9 +77,27 @@ Specific guidelines for the kernel documentation
>> >
>> >  Here are some specific guidelines for the kernel documentation:
>> >
>> > -* Please don't go overboard with reStructuredText markup. Keep it simple.
>> > +* Please don't go overboard with reStructuredText markup. Keep it simple. 
>> > A lot
>> > +  of core kernel developers prefer plain text, with a big emphasis on 
>> > plain. In
>> > +  the end if we have pretty generated docs which the subject experts don't
>> > +  like to edit and keep up-to-date everyone loses.
>> >
>> > -* Please stick to this order of heading adornments:
>> > +  Be especially considerate when converting existing documentation. 
>> > There's a
>> > +  wide scale from annotating every little bit with in-line styles to only
>> > +  touching up the bare minimum needed to integrate an existing file into 
>> > the
>> > +  larger documentation. Please align with the wishes of the maintainer to 
>> > make
>> > +  sure that documentations stays useful for everyone.
>>
>> I think this is about where I figured out why I'm not 100% ready to jump on
>> this.  What we're doing here is mixing two things: information on how to
>> write documents, and information on how to convert existing documents.
>>
>> I'm not really opposed to applying the patch as-is, but I do wonder if what
>> we really need is a new section aimed specifically at people doing
>> conversions?  The concerns *are* a bit different, and there's more
>> information we could put into a conversion section that isn't relevant to
>> others.  Plus we could remove it some day far in the future when
>> everything's converted :)
>
> Yeah, a "conversion guide" section seems interesting. In the case of
> media, for example, we prefer to use as much as ReST provides, as nobody
> cares that the doc source would be as readable as the html/pdf output.
> So, we want to be sure that the enriched text output would look better
> to the ones using the documentation.
>
> In that case, I would go for something close to the text I wrote to Peter
> sometime ago:

Hm yeah, separate conversion section makes sense. In that case I'll
adopt Jani's suggestion for more terseness in overview document, and
we can merge Mauro's proposal (or something like it) on top. And I'll
try to rebase onto latest doc-next too ;-)

Does that sound like a plan, before I head of and respin v4?

Cheers, Daniel

>
> 
> Conversion guide
> 
>
> Be especially considerate when converting existing documentation. There's a
> wide scale from annotating every little bit with in-line styles to only
> touching up the bare minimum needed to integrate an existing file into the
> larger documentation. Please align with the wishes of the maintainer to make
> sure that documentations stays useful for everyone.
>
> Usually, all it takes to convert a text document to ReST is:
>
> - adjust the chapter/section headers, as they all start on column 1,
>   and all have a line below with a symbol (like "=", "-", "~", ...), E. g::
>
> Foo chapter
> ===
>
> bar section
> ---
>
>   It will automatically assign the first symbol to chapter, the
>   next one to section and so on. Avoid touch the symbols used on
>   the text, if possible
>
> - use *foo* (for italics) instead of _foo_;
>
> - if you need to use cross-references, use :ref:`path `, e. g::
>
> :ref:`Documentation/admin-guide/serial-console.rst `
>
> - if it contains source examples or ascii artwork diagrams, use "::"
>   on the previous line to create a literal block, e. g.::
>
> this is an example::
>
> // whatever I do here, Sphinx will 

Re: [RFC 02/10] module: fix memory leak on early load_module() failures

[Kees Cook]

On Thu, Dec 8, 2016 at 1:10 PM, Luis R. Rodriguez  wrote:
> On Thu, Dec 8, 2016 at 2:30 PM, Kees Cook  wrote:
>> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez  wrote:
>>> While looking for early possible module loading failures I was
>>> able to reproduce a memory leak possible with kmemleak. There
>>> are a few rare ways to trigger a failure:
>>>
>>>   o we've run into a failure while processing kernel parameters
>>> (parse_args() returns an error)
>>>   o mod_sysfs_setup() fails
>>>   o we're a live patch module and copy_module_elf() fails
>>>
>>> Chances of running into this issue is really low.
>>>
>>> kmemleak splat:
>>>
>>> unreferenced object 0x9f2c4ada1b00 (size 32):
>>>   comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s)
>>>   hex dump (first 32 bytes):
>>> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00  memstick0...
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>>>   backtrace:
>>> [] kmemleak_alloc+0x4a/0xa0
>>> [] __kmalloc_track_caller+0x126/0x230
>>> [] kstrdup+0x31/0x60
>>> [] kstrdup_const+0x24/0x30
>>> [] kvasprintf_const+0x7a/0x90
>>> [] kobject_set_name_vargs+0x21/0x90
>>> [] dev_set_name+0x47/0x50
>>> [] memstick_check+0x95/0x33c [memstick]
>>> [] process_one_work+0x1f3/0x4b0
>>> [] worker_thread+0x48/0x4e0
>>> [] kthread+0xc9/0xe0
>>> [] ret_from_fork+0x1f/0x40
>>> [] 0x
>>>
>>> Signed-off-by: Luis R. Rodriguez 
>>
>> Acked-by: Kees Cook 
>>
>> Is this worth sending through -stable too?
>
> Yes, for some reason git-send e-mail complained to me about
> sta...@kernel.org not being a valid local address, so I had to remove
> it, but indeed. I'll try to fix this e-mail issue later and add your
> tag.

Yup, you want sta...@vger.kernel.org. :)

-Kees

-- 
Kees Cook
Nexus Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 03/10] kmod: add dynamic max concurrent thread count

[Luis R. Rodriguez]

On Thu, Dec 08, 2016 at 12:28:07PM -0800, Kees Cook wrote:
> On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez  wrote:
> > diff --git a/kernel/kmod.c b/kernel/kmod.c
> > index 0277d1216f80..cb6f7ca7b8a5 100644
> > --- a/kernel/kmod.c
> > +++ b/kernel/kmod.c
> > @@ -44,6 +44,9 @@
> > @@ -186,6 +174,31 @@ int __request_module(bool wait, const char *fmt, ...)
> > return ret;
> >  }
> >  EXPORT_SYMBOL(__request_module);
> > +
> > +/*
> > + * If modprobe needs a service that is in a module, we get a recursive
> > + * loop.  Limit the number of running kmod threads to max_threads/2 or
> > + * CONFIG_MAX_KMOD_CONCURRENT, whichever is the smaller.  A cleaner method
> > + * would be to run the parents of this process, counting how many times
> > + * kmod was invoked.  That would mean accessing the internals of the
> > + * process tables to get the command line, proc_pid_cmdline is static
> > + * and it is not worth changing the proc code just to handle this case.
> > + *
> > + * "trace the ppid" is simple, but will fail if someone's
> > + * parent exits.  I think this is as good as it gets.
> > + *
> > + * You can override with with a kernel parameter, for instance to allow
> > + * 4096 concurrent modprobe instances:
> > + *
> > + * kmod.max_modprobes=4096
> > + */
> > +void __init init_kmod_umh(void)
> 
> What does umh mean?

umh is user mode helper. kmod.c actually implements the kernel's umh code.
A subsequent series I will want to move all that to umh.c and keep module
loading separate in kmod.c But that's for later as a cleanup.

BTW any chance I can have you trim replies to file name and hunk for changes
you reply to ? As an example I did that here :)

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 04/10] kmod: provide wrappers for kmod_concurrent inc/dec

[Kees Cook]

On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez  wrote:
> kmod_concurrent is used as an atomic counter for enabling
> the allowed limit of modprobe calls, provide wrappers for it
> to enable this to be expanded on more easily. This will be done
> later.
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  kernel/kmod.c | 27 +--
>  1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index cb6f7ca7b8a5..049d7eabda38 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -44,6 +44,9 @@
>  #include 
>
>  extern int max_threads;
> +
> +static atomic_t kmod_concurrent = ATOMIC_INIT(0);
> +
>  unsigned int max_modprobes;
>  module_param(max_modprobes, uint, 0644);
>  MODULE_PARM_DESC(max_modprobes, "Max number of allowed concurrent 
> modprobes");
> @@ -108,6 +111,20 @@ static int call_modprobe(char *module_name, int wait)
> return -ENOMEM;
>  }
>
> +static int kmod_umh_threads_get(void)
> +{
> +   atomic_inc(_concurrent);
> +   if (atomic_read(_concurrent) < max_modprobes)
> +   return 0;
> +   atomic_dec(_concurrent);
> +   return -ENOMEM;
> +}
> +
> +static void kmod_umh_threads_put(void)
> +{
> +   atomic_dec(_concurrent);
> +}

Can you use a kref here instead? We're trying to kill raw use of
atomic_t for reference counting...

> +
>  /**
>   * __request_module - try to load a kernel module
>   * @wait: wait (or not) for the operation to complete
> @@ -129,7 +146,6 @@ int __request_module(bool wait, const char *fmt, ...)
> va_list args;
> char module_name[MODULE_NAME_LEN];
> int ret;
> -   static atomic_t kmod_concurrent = ATOMIC_INIT(0);
> static int kmod_loop_msg;
>
> /*
> @@ -153,8 +169,8 @@ int __request_module(bool wait, const char *fmt, ...)
> if (ret)
> return ret;
>
> -   atomic_inc(_concurrent);
> -   if (atomic_read(_concurrent) > max_modprobes) {
> +   ret = kmod_umh_threads_get();
> +   if (ret) {
> /* We may be blaming an innocent here, but unlikely */
> if (kmod_loop_msg < 5) {
> printk(KERN_ERR
> @@ -162,15 +178,14 @@ int __request_module(bool wait, const char *fmt, ...)
>module_name);
> kmod_loop_msg++;
> }
> -   atomic_dec(_concurrent);
> -   return -ENOMEM;
> +   return ret;
> }
>
> trace_module_request(module_name, wait, _RET_IP_);
>
> ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : 
> UMH_WAIT_EXEC);
>
> -   atomic_dec(_concurrent);
> +   kmod_umh_threads_put();
> return ret;
>  }
>  EXPORT_SYMBOL(__request_module);
> --
> 2.10.1
>



-- 
Kees Cook
Nexus Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 03/10] kmod: add dynamic max concurrent thread count

[Kees Cook]

On Thu, Dec 8, 2016 at 11:48 AM, Luis R. Rodriguez  wrote:
> We currently statically limit the number of modprobe threads which
> we allow to run concurrently to 50. As per Keith Owens, this was a
> completely arbitrary value, and it was set in the 2.3.38 days [0]
> over 16 years ago in year 2000.
>
> Although we haven't yet hit our lower limits, experimentation [1]
> shows that when and if we hit this limit in the worst case, will be
> fatal -- consider get_fs_type() failures upon mount on a system which
> has many partitions, some of which might even be with the same
> filesystem. Its best to be prudent and increase and set this
> value to something more sensible which ensures we're far from hitting
> the limit and also allows default build/user run time override.
>
> The worst case is fatal given that once a module fails to load there
> is a period of time during which subsequent request for the same module
> will fail, so in the case of partitions its not just one request that
> could fail, but whole series of partitions. This later issue of a
> module request failure domino effect can be addressed later, but
> increasing the limit to something more meaninful should at least give us
> enough cushion to avoid this for a while.
>
> Set this value up with a bit more meaninful modern limits:
>
> Bump this up to 64  max for small systems (CONFIG_BASE_SMALL)
> Bump this up to 128 max for larger systems (!CONFIG_BASE_SMALL)
>
> Also allow the default max limit to be further fine tuned at compile
> time and at initialization at run time at boot up using the kernel
> parameter: max_modprobes.
>
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/?id=ab1c4ec7410f6ec64e1511d1a7d850fc99c09b44
> [1] https://github.com/mcgrof/test_request_module
>
> Signed-off-by: Luis R. Rodriguez 
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  7 
>  include/linux/kmod.h|  3 +-
>  init/Kconfig| 23 +
>  init/main.c |  1 +
>  kernel/kmod.c   | 43 
> -
>  5 files changed, 61 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index be2d6d0a03a4..92b65ea4 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1700,6 +1700,13 @@
>
> keepinitrd  [HW,ARM]
>
> +   kmod.max_modprobes [KNL]
> +   This lets you set the max allowed of concurrent
> +   modprobes threads possible on a system overriding the
> +   default heuristic of:
> +
> +   min(max_threads/2, 2 << 
> CONFIG_MAX_KMOD_CONCURRENT)
> +
> kernelcore= [KNL,X86,IA-64,PPC]
> Format: nn[KMGTPE] | "mirror"
> This parameter
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index fcfd2bf14d3f..15783cd7f056 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -38,13 +38,14 @@ int __request_module(bool wait, const char *name, ...);
>  #define request_module_nowait(mod...) __request_module(false, mod)
>  #define try_then_request_module(x, mod...) \
> ((x) ?: (__request_module(true, mod), (x)))
> +void init_kmod_umh(void);
>  #else
>  static inline int request_module(const char *name, ...) { return -ENOSYS; }
>  static inline int request_module_nowait(const char *name, ...) { return 
> -ENOSYS; }
> +static inline void init_kmod_umh(void) { }
>  #define try_then_request_module(x, mod...) (x)
>  #endif
>
> -
>  struct cred;
>  struct file;
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 271692a352f1..da2c25746937 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -2111,6 +2111,29 @@ config TRIM_UNUSED_KSYMS
>
>   If unsure, or if you need to build out-of-tree modules, say N.
>
> +config MAX_KMOD_CONCURRENT
> +   int "Max allowed concurrent request_module() calls (6=>64, 10=>1024)"
> +   range 0 14
> +   default 6 if !BASE_SMALL
> +   default 7 if BASE_SMALL
> +   help
> + The kernel restricts the number of possible concurrent calls to
> + request_module() to help avoid a recursive loop possible with
> + modules. The default maximum number of concurrent threads allowed
> + to run request_module() will be:
> +
> +   max_modprobes = min(max_threads/2, 2 << 
> CONFIG_MAX_KMOD_CONCURRENT);
> +
> + The value set in CONFIG_MAX_KMOD_CONCURRENT represents then the 
> power
> + of 2 value used at boot time for the above computation. You can
> + override the default built value using the kernel parameter:
> +
> +   kmod.max_modprobes=4096
> +
> + We set this to default to 

[RFC 07/10] kmod: use simplified rate limit printk

[Luis R. Rodriguez]

Just use the simplified rate limit printk when the max modprobe
limit is reached, while at it throw out a bone should the error
be triggered.

Signed-off-by: Luis R. Rodriguez 
---
 kernel/kmod.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 09cf35a2075a..ef65f4c3578a 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -158,7 +158,6 @@ int __request_module(bool wait, const char *fmt, ...)
va_list args;
char module_name[MODULE_NAME_LEN];
int ret;
-   static int kmod_loop_msg;
 
/*
 * We don't allow synchronous module loading from async.  Module
@@ -183,13 +182,8 @@ int __request_module(bool wait, const char *fmt, ...)
 
ret = kmod_umh_threads_get();
if (ret) {
-   /* We may be blaming an innocent here, but unlikely */
-   if (kmod_loop_msg < 5) {
-   printk(KERN_ERR
-  "request_module: runaway loop modprobe %s\n",
-  module_name);
-   kmod_loop_msg++;
-   }
+   pr_err_ratelimited("request_module: modprobe limit (%u) reached 
with module %s\n",
+  max_modprobes, module_name);
return ret;
}
 
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 10/10] kmod: add a sanity check on module loading

[Luis R. Rodriguez]

kmod has an optimization in place whereby if a some kernel code
uses request_module() on a module already loaded we never bother
userspace as the module already is loaded. This is not true for
get_fs_type() though as it uses aliases.

Additionally kmod <= v19 was broken -- it returns 0 to modprobe calls,
assuming the kernel module is built-in, where really we have a race as
the module starts forming. kmod <= v19 has incorrect userspace heuristics,
a userspace kmod fix is available for it:

http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/libkmod/libkmod-module.c?id=fd44a98ae2eb5eb32161088954ab21e58e19dfc4

This changes kmod to address both:

 o Provides the alias optimization for get_fs_type() so modules already
   loaded do not get re-requested.

 o Provides a sanity test to verify modprobe's work

This is important given how any get_fs_type() users assert success
means we're ready to go, and tests with the new test_kmod stress driver
reveal that request_module() and get_fs_type() might fail for a few
other reasons. You don't need old kmod to fail on request_module() or
get_fs_type(), with the right system setup, these calls *can* fail
today.

Although this does get us in the business of keeping alias maps in
kernel, the the work to support and maintain this is trivial.
Aditionally, since it may be important get_fs_type() should not fail on
certain systems, this tightens things up a bit more.

The TL;DR:

kmod <= v19 will return 0 on modprobe calls if you are built-in,
however its heuristics for checking if you are built-in were broken.

It assumed that having the directory /sys/module/module-name
but not having the file /sys/module/module-name/initstate
is sufficient to assume a module is built-in.

The kernel loads the inittstate attribute *after* it creates the
directory. This is an issue when modprobe returns 0 for kernel calls
which assumes a return of 0 on request_module() can give you the
right to assert the module is loaded and live.

We cannot trust returns of modprobe as 0 in the kernel, we need to
verify that modules are live if modprobe return 0 but only if modules
*are* modules. The kernel heuristic we use to determine if a module is
built-in is that if modprobe returns 0 we know we must be built-in or
a module, but if we are a module clearly we must have a lingering kmod
dangling on our linked list. If there is no modules there we are *somewhat*
certain the module must be built in.

This is not enough though... we cannot easily work around this since the
kernel can use aliases to userspace for modules calls. For instance
fs/namespace.c uses fs-modulename for filesystesms on get_fs_type(), so
these need to be taken into consideration as well.

Using kmod <= 19 will give you a NULL get_fs_type() return even though
the module was loaded... That is a corner case, there are other failures
for request_module() though -- the other failures are not easy to
reproduce though but fortunately we have a stress test driver to help
with that now. Use the following tests:

 # tools/testing/selftests/kmod/kmod.sh -t 0008
 # tools/testing/selftests/kmod/kmod.sh -t 0009

You can more easily see this error if you have kmod <= v19 installed.

You will need to install kmod <= v19, be sure to install its modprobe
into /sbin/ as by default the 'make install' target does not replace
your own.

This test helps cure test_kmod cases 0008 0009 so enable them.

Reported-by: Martin Wilck 
Reported-by: Randy Wright 
Signed-off-by: Luis R. Rodriguez 
---
 kernel/kmod.c| 73 
 kernel/module.c  | 11 --
 tools/testing/selftests/kmod/kmod.sh |  9 ++---
 3 files changed, 85 insertions(+), 8 deletions(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index a0f449f77ed7..6bf0feab41d1 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -61,6 +61,11 @@ static DECLARE_RWSEM(umhelper_sem);
 
 #ifdef CONFIG_MODULES
 
+bool finished_loading(const char *name);
+int module_wait_until_finished(const char *name);
+struct module *find_module_all(const char *name, size_t len,
+  bool even_unformed);
+
 /*
modprobe_path is set via /proc/sys.
 */
@@ -158,6 +163,72 @@ int get_kmod_umh_count(void)
return atomic_read(_concurrent);
 }
 
+static bool kmod_exists(char *name)
+{
+   struct module *mod;
+
+   mutex_lock(_mutex);
+   mod = find_module_all(name, strlen(name), true);
+   mutex_unlock(_mutex);
+
+   if (mod)
+   return true;
+
+   return false;
+}
+
+/*
+ * The assumption is this must be a module, it could still not be live though
+ * since kmod <= 19 returns 0 even if it was not ready yet.  Allow for force
+ * wait check in case you are stuck on old userspace.
+ */
+static int wait_for_kmod(char *name)
+{
+   int ret = 0;
+
+   if (!finished_loading(name))
+   ret = 

[RFC 05/10] kmod: return -EBUSY if modprobe limit is reached

[Luis R. Rodriguez]

Running out of our modprobe limit is not a memory limit but
a system specific established limitation set to avoid a possible
recursive issue with modprobe. This gives userspace a better idea
of what happened if we can't load a module, it could use this to
wait and try again.

Signed-off-by: Luis R. Rodriguez 
---
 kernel/kmod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 049d7eabda38..ab38539f7e91 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -117,7 +117,7 @@ static int kmod_umh_threads_get(void)
if (atomic_read(_concurrent) < max_modprobes)
return 0;
atomic_dec(_concurrent);
-   return -ENOMEM;
+   return -EBUSY;
 }
 
 static void kmod_umh_threads_put(void)
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 04/10] kmod: provide wrappers for kmod_concurrent inc/dec

[Luis R. Rodriguez]

kmod_concurrent is used as an atomic counter for enabling
the allowed limit of modprobe calls, provide wrappers for it
to enable this to be expanded on more easily. This will be done
later.

Signed-off-by: Luis R. Rodriguez 
---
 kernel/kmod.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/kernel/kmod.c b/kernel/kmod.c
index cb6f7ca7b8a5..049d7eabda38 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -44,6 +44,9 @@
 #include 
 
 extern int max_threads;
+
+static atomic_t kmod_concurrent = ATOMIC_INIT(0);
+
 unsigned int max_modprobes;
 module_param(max_modprobes, uint, 0644);
 MODULE_PARM_DESC(max_modprobes, "Max number of allowed concurrent modprobes");
@@ -108,6 +111,20 @@ static int call_modprobe(char *module_name, int wait)
return -ENOMEM;
 }
 
+static int kmod_umh_threads_get(void)
+{
+   atomic_inc(_concurrent);
+   if (atomic_read(_concurrent) < max_modprobes)
+   return 0;
+   atomic_dec(_concurrent);
+   return -ENOMEM;
+}
+
+static void kmod_umh_threads_put(void)
+{
+   atomic_dec(_concurrent);
+}
+
 /**
  * __request_module - try to load a kernel module
  * @wait: wait (or not) for the operation to complete
@@ -129,7 +146,6 @@ int __request_module(bool wait, const char *fmt, ...)
va_list args;
char module_name[MODULE_NAME_LEN];
int ret;
-   static atomic_t kmod_concurrent = ATOMIC_INIT(0);
static int kmod_loop_msg;
 
/*
@@ -153,8 +169,8 @@ int __request_module(bool wait, const char *fmt, ...)
if (ret)
return ret;
 
-   atomic_inc(_concurrent);
-   if (atomic_read(_concurrent) > max_modprobes) {
+   ret = kmod_umh_threads_get();
+   if (ret) {
/* We may be blaming an innocent here, but unlikely */
if (kmod_loop_msg < 5) {
printk(KERN_ERR
@@ -162,15 +178,14 @@ int __request_module(bool wait, const char *fmt, ...)
   module_name);
kmod_loop_msg++;
}
-   atomic_dec(_concurrent);
-   return -ENOMEM;
+   return ret;
}
 
trace_module_request(module_name, wait, _RET_IP_);
 
ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC);
 
-   atomic_dec(_concurrent);
+   kmod_umh_threads_put();
return ret;
 }
 EXPORT_SYMBOL(__request_module);
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 00/10] kmod: stress test driver, few fixes and enhancements

[Luis R. Rodriguez]

Upon running into an old kmod v19 issue with mount (get_fs_type()) a few of us
hunted for the cause of the issue. Although the issue ended up being a
userspace issue, a stress test driver was written to help reproduce the issue,
and along the way a few other fixes and sanity checks were implemented.

I've taken the time to generalize the stress test driver as a kselftest driver
with a 9 test cases. The last two test cases reveal an existing issue which
is not yet addressed upstream, even if you have kmod v19 present. A fix is
proposed in the last patch. Orignally we had discarded this patch as too
complex due to the alias handling, but upon further analysis of test cases
and memory pressure issues, it seems worth considering. Other than the
last patch I don't think much of the other patches are controversial, but
sending as RFC first just in case.

If its not clear, an end goal here is to make module loading a bit more
deterministic with stronger sanity checks and stress tests. Please note,
the stress test diver requires 4 GiB of RAM to run all tests without running
out of memory. A lot of this has to do with the memory requirements needed
for a dynamic test for multiple threads, but note that the final memory
pressure and OOMs actually don't come from this allocation, but instead
from many finit_module() calls, this consumes quite a bit of memory, specially
if you have a lot of dependencies which also need to be loaded prior to
your needed module -- as is the case for filesystem drivers.

These patches are available on my linux-next git-tree on my branch
20161208-kmod-test-driver-try2 [0], which is based on linux-next tag
next-20161208. Patches are also available based on v4.9-rc8 [1] for
those looking for a bit more stable tree given x86_64 on linux-next is
hosed at the moment.

Since kmod.c doesn't seem to get much love, and since I've been digging
quite a bit into it for other users (firmware) I suppose I could volunteer
myself to maintain this code as well, unless there are oppositions to this.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20161208-kmod-test-driver-try2
[1] 
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux.git/log/?h=20161208-kmod-test-driver

Luis R. Rodriguez (10):
  kmod: add test driver to stress test the module loader
  module: fix memory leak on early load_module() failures
  kmod: add dynamic max concurrent thread count
  kmod: provide wrappers for kmod_concurrent inc/dec
  kmod: return -EBUSY if modprobe limit is reached
  kmod: provide sanity check on kmod_concurrent access
  kmod: use simplified rate limit printk
  sysctl: add support for unsigned int properly
  kmod: add helpers for getting kmod count and limit
  kmod: add a sanity check on module loading

 Documentation/admin-guide/kernel-parameters.txt |7 +
 include/linux/kmod.h|9 +
 include/linux/sysctl.h  |3 +
 init/Kconfig|   23 +
 init/main.c |1 +
 kernel/kmod.c   |  244 -
 kernel/module.c |   12 +-
 kernel/sysctl.c |  198 +++-
 lib/Kconfig.debug   |   25 +
 lib/Makefile|1 +
 lib/test_kmod.c | 1248 +++
 tools/testing/selftests/kmod/Makefile   |   11 +
 tools/testing/selftests/kmod/config |7 +
 tools/testing/selftests/kmod/kmod.sh|  448 
 14 files changed, 2199 insertions(+), 38 deletions(-)
 create mode 100644 lib/test_kmod.c
 create mode 100644 tools/testing/selftests/kmod/Makefile
 create mode 100644 tools/testing/selftests/kmod/config
 create mode 100755 tools/testing/selftests/kmod/kmod.sh

-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 01/10] kmod: add test driver to stress test the module loader

[Luis R. Rodriguez]

This adds a new stress test driver for kmod: the kernel module loader.
The new stress test driver, test_kmod, is only enabled as a module right
now. It should be possible to load this as built-in and load tests early
(refer to the force_init_test module parameter), however since a lot of
test can get a system out of memory fast we leave this disabled for now.

Using a system with 1024 MiB of RAM can *easily* get your kernel
OOM fast with this test driver.

The test_kmod driver exposes API knobs for us to fine tune simple
request_module() and get_fs_type() calls. Since these API calls
only allow each one parameter a test driver for these is rather
simple. Other factors that can help out test driver though are
the number of calls we issue and knowing current limitations of
each. This exposes configuration as much as possible through
userspace to be able to build tests directly from userspace.

Since it allows multiple misc devices its will eventually (once we
add a knob to let us create new devices at will) also be possible to
perform more tests in parallel, provided you have enough memory.

We only enable tests we know work as of right now.

Demo screenshots:

 # tools/testing/selftests/kmod/kmod.sh
kmod_test_0001_driver: OK! - loading kmod test
kmod_test_0001_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected 
MODULE_NOT_FOUND
kmod_test_0001_fs: OK! - loading kmod test
kmod_test_0001_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
kmod_test_0002_driver: OK! - loading kmod test
kmod_test_0002_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected 
MODULE_NOT_FOUND
kmod_test_0002_fs: OK! - loading kmod test
kmod_test_0002_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
kmod_test_0003: OK! - loading kmod test
kmod_test_0003: OK! - Return value: 0 (SUCCESS), expected SUCCESS
kmod_test_0004: OK! - loading kmod test
kmod_test_0004: OK! - Return value: 0 (SUCCESS), expected SUCCESS
kmod_test_0005: OK! - loading kmod test
kmod_test_0005: OK! - Return value: 0 (SUCCESS), expected SUCCESS
kmod_test_0006: OK! - loading kmod test
kmod_test_0006: OK! - Return value: 0 (SUCCESS), expected SUCCESS
kmod_test_0005: OK! - loading kmod test
kmod_test_0005: OK! - Return value: 0 (SUCCESS), expected SUCCESS
kmod_test_0006: OK! - loading kmod test
kmod_test_0006: OK! - Return value: 0 (SUCCESS), expected SUCCESS
Test completed

You can also request for specific tests:

 # tools/testing/selftests/kmod/kmod.sh -t 0001
kmod_test_0001_driver: OK! - loading kmod test
kmod_test_0001_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected 
MODULE_NOT_FOUND
kmod_test_0001_fs: OK! - loading kmod test
kmod_test_0001_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
Test completed

Lastly, the current available number of tests:

 # tools/testing/selftests/kmod/kmod.sh --help
Usage: tools/testing/selftests/kmod/kmod.sh [ -t <4-number-digit> ]
Valid tests: 0001-0009

0001 - Simple test - 1 thread  for empty string
0002 - Simple test - 1 thread  for modules/filesystems that do not exist
0003 - Simple test - 1 thread  for get_fs_type() only
0004 - Simple test - 2 threads for get_fs_type() only
0005 - multithreaded tests with default setup - request_module() only
0006 - multithreaded tests with default setup - get_fs_type() only
0007 - multithreaded tests with default setup test request_module() and 
get_fs_type()
0008 - multithreaded - push kmod_concurrent over max_modprobes for 
request_module()
0009 - multithreaded - push kmod_concurrent over max_modprobes for get_fs_type()

The following test cases currently fail, as such they are not currently
enabled by default:

 # tools/testing/selftests/kmod/kmod.sh -t 0007
 # tools/testing/selftests/kmod/kmod.sh -t 0008
 # tools/testing/selftests/kmod/kmod.sh -t 0009
 # tools/testing/selftests/kmod/kmod.sh -t 0010
 # tools/testing/selftests/kmod/kmod.sh -t 0011

To be sure to run them as intended please unload both of the modules:

  o test_module
  o xfs

And ensure they are not loaded on your system prior to testing them.
If you use these paritions for your rootfs you can change the default
test driver used for get_fs_type() by exporting it into your
environment. For example of other test defaults you can override
refer to kmod.sh allow_user_defaults().

Behind the scenes this is how we fine tune at a test case prior to
hitting a trigger to run it:

cat /sys/devices/virtual/misc/test_kmod0/config
echo -n "2" > /sys/devices/virtual/misc/test_kmod0/config_test_case
echo -n "ext4" > /sys/devices/virtual/misc/test_kmod0/config_test_fs
echo -n "80" > /sys/devices/virtual/misc/test_kmod0/config_num_threads
cat /sys/devices/virtual/misc/test_kmod0/config
echo -n "1" > /sys/devices/virtual/misc/test_kmod0/config_num_threads

Finally to trigger:

echo -n "1" > /sys/devices/virtual/misc/test_kmod0/trigger_config

The kmod.sh script uses the above constructs to build differnt test cases.

A bit of interpretation of the current failures follows, first two
premises:

Re: [PATCH v3 0/6] net: stmmac: make DMA programmable burst length more configurable

[David Miller]

From: Niklas Cassel 
Date: Wed, 7 Dec 2016 15:20:02 +0100

> Make DMA programmable burst length more configurable in the stmmac driver.
> 
> This is done by adding support for independent pbl for tx/rx through DT.
> More fine grained tuning of pbl is possible thanks to a DT property saying
> that we should NOT multiply pbl values by x8/x4 in hardware.
> 
> All new DT properties are optional, and created in a way that it will not
> affect any existing DT configurations.

Series applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] watchdog: nic7018_wdt: Add NIC7018 watchdog driver

[Guenter Roeck]

On 12/08/2016 01:19 AM, Hui Chun Ong wrote:

On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:

On 11/15/2016 07:21 PM, Hui Chun Ong wrote:


Add support for the watchdog timer on PXI Embedded Controller.

Signed-off-by: Hui Chun Ong 
---
v1: Remove non-standard attributes.
Change from acpi_driver to platform_driver.
Rename driver from ni7018_wdt to nic7018_wdt.
---
 Documentation/watchdog/watchdog-parameters.txt |   5 +
 drivers/watchdog/Kconfig   |  10 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/nic7018_wdt.c | 303 +
 4 files changed, 319 insertions(+)
 create mode 100644 drivers/watchdog/nic7018_wdt.c

diff --git a/Documentation/watchdog/watchdog-parameters.txt 
b/Documentation/watchdog/watchdog-parameters.txt
index a8d3642..bd142fa 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -209,6 +209,11 @@ timeout: Initial watchdog timeout in seconds (0
 nowayout: Watchdog cannot be stopped once started
(default=kernel config parameter)
 -
+nic7018_wdt:
+timeout: Initial watchdog timeout in seconds (0
+nowayout: Watchdog cannot be stopped once started
+   (default=kernel config parameter)
+-
 nuc900_wdt:
 heartbeat: Watchdog heartbeats in seconds.
(default = 15)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fdd3228..79fb224 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1325,6 +1325,16 @@ config NI903X_WDT
  To compile this driver as a module, choose M here: the module will be
  called ni903x_wdt.

+config NIC7018_WDT
+   tristate "NIC7018 Watchdog"
+   depends on X86 && ACPI
+   select WATCHDOG_CORE
+   ---help---
+ This is the device driver for National Instruments NIC7018 Watchdog.
+

This should describe what the watchdog is for.

"Support for National Instruments NIC7018 Watchdog".



+ To compile this driver as a module, choose M here: the module will be
+ called nic7018_wdt.
+
 # M32R Architecture

 # M68K Architecture
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index caa9f4a..bd88e2e 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -139,6 +139,7 @@ obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o
 obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
 obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
 obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
+obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o

 # M32R Architecture

diff --git a/drivers/watchdog/nic7018_wdt.c b/drivers/watchdog/nic7018_wdt.c
new file mode 100644
index 000..780edc6
--- /dev/null
+++ b/drivers/watchdog/nic7018_wdt.c
@@ -0,0 +1,303 @@
+/*
+ * Copyright (C) 2016 National Instruments Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LOCK   0xA5
+#define UNLOCK 0x5A
+
+#define WDT_CTRL_RESET_EN  BIT(7)
+#define WDT_RELOAD_PORT_EN BIT(7)
+

Should include linux/bitops.h



+#define WDT_CTRL   1
+#define WDT_RELOAD_CTRL2
+#define WDT_PRESET_PRESCALE4
+#define WDT_REG_LOCK   5
+#define WDT_COUNT  6
+#define WDT_RELOAD_PORT7
+
+#define WDT_MIN_TIMEOUT1
+#define WDT_MAX_TIMEOUT464

32 * 15 would be 480 ? I assume the limit above is because of the rounding down
by 16 in the driver, but that only shows that this rounding is maybe not the 
best
idea. After all, the maximum timeout _is_ 480 seconds, if I understand the code
correctly.


The formula for timeout calculation is = (period * counter) - (period / 2). So 
in this case, (32 * 15) - (32 / 2) = 464



I understand that this is the formula used here. But is it the real timeout ?
It appears unlikely for any hardware to use a subtract operation internally
to calculate a timeout.

Same for the default timeout. Question there is: If you set the default timeout 
as
set to 80 seconds, does the watchdog time out after 80 seconds, or after 96 
seconds ?

Similar, if one sets the timeout value to the minimum, which per your 
calculation
should be 16 seconds, does the watchdog really time out after 16 seconds, or 
does
it time out after 32 seconds ? This should be easy 

Re: [PATCH] pci-error-recover: doc cleanup

[Cao jin]

On 12/08/2016 10:05 PM, Jonathan Corbet wrote:
> On Thu, 8 Dec 2016 16:16:14 +0800
> Cao jin  wrote:
> 
>>  The platform resets the link, and then calls the link_reset() callback
>>  on all affected device drivers.  This is a PCI-Express specific state
>> -and is done whenever a non-fatal error has been detected that can be
>> +and is done whenever a fatal error has been detected that can be
>>  "solved" by resetting the link. This call informs the driver of the
> 
> As far as I can tell, the original text was correct here; why do you
> think this change needs to be made?
> 

See do_recovery() in aer core, reset_link() is called only seeing fatal
error.

-- 
Sincerely,
Cao jin


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pci-error-recover: doc cleanup

[Jonathan Corbet]

On Thu, 8 Dec 2016 16:16:14 +0800
Cao jin  wrote:

>  The platform resets the link, and then calls the link_reset() callback
>  on all affected device drivers.  This is a PCI-Express specific state
> -and is done whenever a non-fatal error has been detected that can be
> +and is done whenever a fatal error has been detected that can be
>  "solved" by resetting the link. This call informs the driver of the

As far as I can tell, the original text was correct here; why do you
think this change needs to be made?

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 6/6] net: smmac: allow configuring lower pbl values

[Andreas Färber]

Hi,

In subject: s/smmac/stmmac/

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

[Catalin Marinas]

On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote:
> On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > > On Mon, Dec 05, 2016 at 04:34:23PM +, Catalin Marinas wrote:
> > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > > detection of the task type.
> > > > 
> > > > What's wrong with the run-time detection? If it's just to avoid a
> > > > negligible overhead, I would rather keep the code simpler by avoiding
> > > > duplicating the generic compat_sys_ptrace().
> > > 
> > > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
> > 
> > Hmm, I completely forgot about this ;). There is still an advantage to
> > doing run-time checking if we avoid touching core code (less acks to
> > gather and less code duplication).
> > 
> > Let's see what Arnd says but the initial patch looked simpler.
> 
> I don't currently have either version of the patch in my inbox
> (the archive is on a different machine), but in general I'd still
> think it's best to avoid the runtime check for aarch64-ilp32
> altogether. I'd have to look at the overall kernel source to
> see if it's worth avoiding one or two instances though, or
> if there are an overwhelming number of other checks that we
> can't avoid at all.

Just in case you haven't found them already, current version:

https://marc.info/?l=linux-arm-kernel=147708276818318=2

Original version:

https://patchwork.kernel.org/patch/7980521/

The old one looks more readable and given that ptrace is not really a
fast path, I'm not two worried about run-time checks

> Regarding ptrace, I notice that arch/tile doesn't even use
> the compat entry point for its ilp32 user space on 64-bit
> kernels, it just calls the regular 64-bit one. Would that
> help here?

I don't know whether it would work, we have incompatible siginfo_t on
AArch64/ILP32.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] watchdog: nic7018_wdt: Add NIC7018 watchdog driver

[Hui Chun Ong]

On Thu, 2016-11-24 at 11:56 -0800, Guenter Roeck wrote:
> On 11/15/2016 07:21 PM, Hui Chun Ong wrote:
> > 
> > Add support for the watchdog timer on PXI Embedded Controller.
> > 
> > Signed-off-by: Hui Chun Ong 
> > ---
> > v1: Remove non-standard attributes.
> > Change from acpi_driver to platform_driver.
> > Rename driver from ni7018_wdt to nic7018_wdt.
> > ---
> >  Documentation/watchdog/watchdog-parameters.txt |   5 +
> >  drivers/watchdog/Kconfig   |  10 +
> >  drivers/watchdog/Makefile  |   1 +
> >  drivers/watchdog/nic7018_wdt.c | 303 
> > +
> >  4 files changed, 319 insertions(+)
> >  create mode 100644 drivers/watchdog/nic7018_wdt.c
> > 
> > diff --git a/Documentation/watchdog/watchdog-parameters.txt 
> > b/Documentation/watchdog/watchdog-parameters.txt
> > index a8d3642..bd142fa 100644
> > --- a/Documentation/watchdog/watchdog-parameters.txt
> > +++ b/Documentation/watchdog/watchdog-parameters.txt
> > @@ -209,6 +209,11 @@ timeout: Initial watchdog timeout in seconds (0
> >  nowayout: Watchdog cannot be stopped once started
> >     (default=kernel config parameter)
> >  -
> > +nic7018_wdt:
> > +timeout: Initial watchdog timeout in seconds (0
> > +nowayout: Watchdog cannot be stopped once started
> > +   (default=kernel config parameter)
> > +-
> >  nuc900_wdt:
> >  heartbeat: Watchdog heartbeats in seconds.
> >     (default = 15)
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index fdd3228..79fb224 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -1325,6 +1325,16 @@ config NI903X_WDT
> >       To compile this driver as a module, choose M here: the module will be
> >       called ni903x_wdt.
> > 
> > +config NIC7018_WDT
> > +   tristate "NIC7018 Watchdog"
> > +   depends on X86 && ACPI
> > +   select WATCHDOG_CORE
> > +   ---help---
> > +     This is the device driver for National Instruments NIC7018 Watchdog.
> > +
> This should describe what the watchdog is for.
> 
> "Support for National Instruments NIC7018 Watchdog".
> 
> > 
> > +     To compile this driver as a module, choose M here: the module will be
> > +     called nic7018_wdt.
> > +
> >  # M32R Architecture
> > 
> >  # M68K Architecture
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index caa9f4a..bd88e2e 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -139,6 +139,7 @@ obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o
> >  obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
> >  obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
> >  obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
> > +obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
> > 
> >  # M32R Architecture
> > 
> > diff --git a/drivers/watchdog/nic7018_wdt.c b/drivers/watchdog/nic7018_wdt.c
> > new file mode 100644
> > index 000..780edc6
> > --- /dev/null
> > +++ b/drivers/watchdog/nic7018_wdt.c
> > @@ -0,0 +1,303 @@
> > +/*
> > + * Copyright (C) 2016 National Instruments Corp.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define LOCK   0xA5
> > +#define UNLOCK 0x5A
> > +
> > +#define WDT_CTRL_RESET_EN  BIT(7)
> > +#define WDT_RELOAD_PORT_EN BIT(7)
> > +
> Should include linux/bitops.h
> 
> > 
> > +#define WDT_CTRL   1
> > +#define WDT_RELOAD_CTRL2
> > +#define WDT_PRESET_PRESCALE4
> > +#define WDT_REG_LOCK   5
> > +#define WDT_COUNT  6
> > +#define WDT_RELOAD_PORT7
> > +
> > +#define WDT_MIN_TIMEOUT1
> > +#define WDT_MAX_TIMEOUT464
> 32 * 15 would be 480 ? I assume the limit above is because of the rounding 
> down
> by 16 in the driver, but that only shows that this rounding is maybe not the 
> best
> idea. After all, the maximum timeout _is_ 480 seconds, if I understand the 
> code
> correctly.
> 
The formula for timeout calculation is = (period * counter) - (period / 2). So 
in this case, (32 * 15) - (32 / 2) = 464

> > 
> > +#define WDT_DEFAULT_TIMEOUT80
> > +
> Kind of an odd number, as it can not really be expressed by the hardware.
> The real timeout, if I understand the code correctly, would be 96 (32 

Re: [PATCH v3 6/6] net: smmac: allow configuring lower pbl values

[Alexandre Torgue]

Hi Niklas,

On 12/07/2016 03:20 PM, Niklas Cassel wrote:

From: Niklas Cassel 

The driver currently always sets the PBLx8/PBLx4 bit, which means that
the pbl values configured via the pbl/txpbl/rxpbl DT properties are
always multiplied by 8/4 in the hardware.

In order to allow the DT to configure lower pbl values, while at the
same time not changing behavior of any existing device trees using the
pbl/txpbl/rxpbl settings, add a property to disable the multiplication
of the pbl by 8/4 in the hardware.

Suggested-by: Rabin Vincent 
Signed-off-by: Niklas Cassel 


Thanks for this patch, you can add my Acked-by.

Thanks for the whole series.

Alex


---
 Documentation/devicetree/bindings/net/stmmac.txt  | 2 ++
 Documentation/networking/stmmac.txt   | 5 -
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c   | 3 ++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  | 3 ++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c  | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
 include/linux/stmmac.h| 1 +
 7 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index 8080038ff1b2..128da752fec9 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,8 @@ Optional properties:
If set, DMA tx will use this value rather than snps,pbl.
 - snps,rxpbl   Rx Programmable Burst Length. Only for GMAC and newer.
If set, DMA rx will use this value rather than snps,pbl.
+- snps,no-pbl-x8   Don't multiply the pbl/txpbl/rxpbl values by 8.
+   For core rev < 3.50, don't multiply the values by 4.
 - snps,aal Address-Aligned Beats
 - snps,fixed-burst Program the DMA to use the fixed burst mode
 - snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/Documentation/networking/stmmac.txt 
b/Documentation/networking/stmmac.txt
index 6add57374f70..2bb07078f535 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -152,8 +152,9 @@ Where:
  o dma_cfg: internal DMA parameters
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
-   GMAC also enables the 4xPBL by default.
+   GMAC also enables the 4xPBL by default. (8xPBL for GMAC 3.50 and newer)
o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx.
+   o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default.
o fixed_burst/mixed_burst/aal
  o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
@@ -208,6 +209,7 @@ struct stmmac_dma_cfg {
int pbl;
int txpbl;
int rxpbl;
+   bool pblx8;
int fixed_burst;
int mixed_burst;
bool aal;
@@ -219,6 +221,7 @@ Where:
 If set, DMA tx will use this value rather than pbl.
  o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer.
 If set, DMA rx will use this value rather than pbl.
+ o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default.
  o fixed_burst: program the DMA to use the fixed burst mode
  o mixed_burst: program the DMA to use the mixed burst mode
  o aal: Address-Aligned Beats
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 99b8040af592..612d3aaac9a4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -98,7 +98,8 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 * post 3.5 mode bit acts as 8*PBL.
 */
-   value |= DMA_BUS_MODE_MAXPBL;
+   if (dma_cfg->pblx8)
+   value |= DMA_BUS_MODE_MAXPBL;
value |= DMA_BUS_MODE_USP;
value &= ~(DMA_BUS_MODE_PBL_MASK | DMA_BUS_MODE_RPBL_MASK);
value |= (txpbl << DMA_BUS_MODE_PBL_SHIFT);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 2c3b2098f350..8196ab5fc33c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -84,7 +84,8 @@ static void dwmac4_dma_init_channel(void __iomem *ioaddr,
 * on each channel
 */
value = readl(ioaddr + DMA_CHAN_CONTROL(channel));
-   value = value | DMA_BUS_MODE_PBL;
+   if (dma_cfg->pblx8)
+   value = value | DMA_BUS_MODE_PBL;
writel(value, ioaddr + DMA_CHAN_CONTROL(channel));

value = readl(ioaddr + DMA_CHAN_TX_CONTROL(channel));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 

Re: [PATCH v3 5/6] net: stmmac: add support for independent DMA pbl for tx/rx

[Alexandre Torgue]

Hi Niklas

On 12/07/2016 03:20 PM, Niklas Cassel wrote:

From: Niklas Cassel 

GMAC and newer supports independent programmable burst lengths for
DMA tx/rx. Add new optional devicetree properties representing this.

To be backwards compatible, snps,pbl will still be valid, but
snps,txpbl/snps,rxpbl will override the value in snps,pbl if set.

If the IP is synthesized to use the AXI interface, there is a register
and a matching DT property inside the optional stmmac-axi-config DT node
for controlling burst lengths, named snps,blen.
However, using this register, it is not possible to control tx and rx
independently. Also, this register is not available if the IP was
synthesized with, e.g., the AHB interface.

Signed-off-by: Niklas Cassel 


Thanks, you can add my Acked-by.

Regards
Alex


---
 Documentation/devicetree/bindings/net/stmmac.txt  |  6 +-
 Documentation/networking/stmmac.txt   | 19 +--
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c   | 12 ++--
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  | 12 +++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
 include/linux/stmmac.h|  2 ++
 6 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index b95ff998ba73..8080038ff1b2 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -34,7 +34,11 @@ Optional properties:
   platforms.
 - tx-fifo-depth: See ethernet.txt file in the same directory
 - rx-fifo-depth: See ethernet.txt file in the same directory
-- snps,pbl Programmable Burst Length
+- snps,pbl Programmable Burst Length (tx and rx)
+- snps,txpbl   Tx Programmable Burst Length. Only for GMAC and newer.
+   If set, DMA tx will use this value rather than snps,pbl.
+- snps,rxpbl   Rx Programmable Burst Length. Only for GMAC and newer.
+   If set, DMA rx will use this value rather than snps,pbl.
 - snps,aal Address-Aligned Beats
 - snps,fixed-burst Program the DMA to use the fixed burst mode
 - snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/Documentation/networking/stmmac.txt 
b/Documentation/networking/stmmac.txt
index 014f4f756cb7..6add57374f70 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -153,7 +153,8 @@ Where:
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
GMAC also enables the 4xPBL by default.
-   o fixed_burst/mixed_burst/burst_len
+   o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx.
+   o fixed_burst/mixed_burst/aal
  o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
  o enh_desc: if sets the MAC will use the enhanced descriptor structure.
@@ -205,16 +206,22 @@ tuned according to the HW capabilities.

 struct stmmac_dma_cfg {
int pbl;
+   int txpbl;
+   int rxpbl;
int fixed_burst;
-   int burst_len_supported;
+   int mixed_burst;
+   bool aal;
 };

 Where:
- o pbl: Programmable Burst Length
+ o pbl: Programmable Burst Length (tx and rx)
+ o txpbl: Transmit Programmable Burst Length. Only for GMAC and newer.
+If set, DMA tx will use this value rather than pbl.
+ o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer.
+If set, DMA rx will use this value rather than pbl.
  o fixed_burst: program the DMA to use the fixed burst mode
- o burst_len: this is the value we put in the register
- supported values are provided as macros in
- linux/stmmac.h header file.
+ o mixed_burst: program the DMA to use the mixed burst mode
+ o aal: Address-Aligned Beats

 ---

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 318ae9f10104..99b8040af592 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -89,20 +89,20 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
   u32 dma_tx, u32 dma_rx, int atds)
 {
u32 value = readl(ioaddr + DMA_BUS_MODE);
+   int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
+   int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;

/*
 * Set the DMA PBL (Programmable Burst Length) mode.
 *
 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 * post 3.5 mode bit acts as 8*PBL.
-*
-* This configuration doesn't take care about the Separate PBL
-* so only the bits: 13-8 are programmed with the PBL passed from the
-* platform.
 */
value |=