Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit
On Thu, Dec 15, 2016 at 05:56:19PM +0100, Petr Mladek wrote: > On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote: > > This adds helpers for getting access to the kmod count and limit from > > userspace. While at it, this also lets userspace fine tune the kmod > > limit after boot, it uses the shiny new proc_douintvec_minmax(). > > > > These knobs should help userspace more gracefully and deterministically > > handle module loading. > > > > Signed-off-by: Luis R. Rodriguez > > --- > > include/linux/kmod.h | 8 + > > kernel/kmod.c| 83 > > ++-- > > kernel/sysctl.c | 14 + > > 3 files changed, 103 insertions(+), 2 deletions(-) > > I am not sure if it is worth it. As you say in the 3rd patch, > there was rather low limit for 16 years and nobody probably had > problems with it. Note, *probably* - ie, this could have gone unreported for a while, and to be frank how can we know for sure a pesky module just did not load due to this? In the case of get_fs_type() issue this can be fatal for a partition mount, not a good example to wait to look forward to before we take this serious. I added the sysctl value mostly for read purposes, the count is probably useless for any accounting to be done in userspace due to delays this reading and making this value useful in userspace can have, I can nuke that. The kmod-limit however seems very useful so that userspace knows how to properly thread *safely* modprobe calls more deterministically. Adding write support to let one bump the limit was just an easy convenience possible given the read support was being added, but its use should really only be useful for testing purposes post bootup given that the real value in the limit will be important at boot time prior to the sysctl parsing. The real know tweak which should be used in case of issues is the module parameter added earlier. So I could drop the kmod-count, and just make the kmod-limit read-only. Thoughts? > Anyway, it seems that such know should also get documented in > Documentation/sysctl/kernel.txt Will do if we keep them, thanks. 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 01/10] kmod: add test driver to stress test the module loader
On Tue, Dec 13, 2016 at 10:10:41PM +0100, Luis R. Rodriguez wrote: > On Thu, Dec 08, 2016 at 12:24:35PM -0800, Kees Cook wrote: > > On Thu, Dec 8, 2016 at 10:47 AM, Luis R. Rodriguez > > wrote: > > > 3) finit_module() consumes quite a bit of memory. > > > > Is this due to reading the module into kernel memory or something else? > > Very likely yes, but to be honest I have not had chance to instrument too > carefully, its TODO work :) I've checked and the issue is since get_fs_type() does not check for aliases we end up hammering tons of module requests, this in turn is an analysis on load_module(). Within there layout_and_allocate() uses first a local copy of the passed user data and mapping it into a struct module, after a bit of sanity checks it finally allocates a copy for us, so its struct module size * however many requests were allowed to get in for load_module(). We could simply avoid an allocation if the module is already present. I have this as another optimization now but am running many other tests to compare performance. > > > +# Once tese are enabled please leave them as-is. Write your own test, > > > +# we have tons of space. > > > +kmod_test_0001 > > > +kmod_test_0002 > > > +kmod_test_0003 > > > +kmod_test_0004 > > > +kmod_test_0005 > > > +kmod_test_0006 > > > +kmod_test_0007 > > > + > > > +#kmod_test_0008 > > > +#kmod_test_0009 > > > > While it's documented in the commit log, I think a short note for each > > disabled test should be added here too. > > Will do, thanks so much for the review! As I added test 0008's reason for why I think it fails I realized that the reason the test can sometimes fail is very different than test 0009 which is for get_fs_type(). You see get_fs_type() hammers kmod concurrent since we don't have an alias check and moprobe calling fs-xfs for instance does not catch that the module is already loaded so it delays the get_fs_type() call and so the __request_module() call, hogging up its kmod concurrent increment. For direct request_module() calls we don't have the alias issue, but since we don't check if a module is loaded prior to calling userspace (I now have a fix for this, reducing this latency does help) it means there are often times the chances we will pour in tons of requests without them getting processed and go over the concurrent limit. I've added a clutch into __request_module() then so instead of just failing we first check if we're at a threshold (say about 1/4 away from limit) and if so we let a few threads breath, until they are done. This fixes *both* test cases without much code changes, however as I've noted in other threads, this is not the only issue to address. 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: [PATCH] ovl: fix reStructuredText syntax errors in documentation
On Thu, Dec 15 2016, Amir Goldstein wrote: > On Thu, Dec 8, 2016 at 9:49 AM, Amir Goldstein wrote: >> - Fix broken long line block quote >> - Fix missing newline before bullets list >> - Use correct numbered list syntax >> > > Ping. > > Neil, > I found these syntax errors when I posted your page on my wiki: > https://github.com/amir73il/overlayfs/wiki/Overlayfs-overview > > Not sure if this patch should go through Miklos's tree or John's tree, > but is surely needs the ACK from you. Does it? It is purely format changes which don't change the meaning in any way, so I felt it had little relevant to me. However I'm happy to provide an: Acked-by: NeilBrown if you find that useful. NeilBrown > > Thanks, > Amir. > >> Signed-off-by: Amir Goldstein >> --- >> Documentation/filesystems/overlayfs.txt | 7 --- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/filesystems/overlayfs.txt >> b/Documentation/filesystems/overlayfs.txt >> index fb6f307..634d03e 100644 >> --- a/Documentation/filesystems/overlayfs.txt >> +++ b/Documentation/filesystems/overlayfs.txt >> @@ -66,7 +66,7 @@ At mount time, the two directories given as mount options >> "lowerdir" and >> "upperdir" are combined into a merged directory: >> >>mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\ >> -workdir=/work /merged >> + workdir=/work /merged >> >> The "workdir" needs to be an empty directory on the same filesystem >> as upperdir. >> @@ -118,6 +118,7 @@ programs. >> >> seek offsets are assigned sequentially when the directories are read. >> Thus if >> + >>- read part of a directory >>- remember an offset, and close the directory >>- re-open the directory some time later >> @@ -137,12 +138,12 @@ When renaming a directory that is on the lower layer >> or merged (i.e. the >> directory was not created on the upper layer to start with) overlayfs can >> handle it in two different ways: >> >> -1) return EXDEV error: this error is returned by rename(2) when trying to >> +1. return EXDEV error: this error is returned by rename(2) when trying to >> move a file or directory across filesystem boundaries. Hence >> applications are usually prepared to hande this error (mv(1) for example >> recursively copies the directory tree). This is the default behavior. >> >> -2) If the "redirect_dir" feature is enabled, then the directory will be >> +2. If the "redirect_dir" feature is enabled, then the directory will be >> copied up (but not the contents). Then the "trusted.overlay.redirect" >> extended attribute is set to the path of the original location from the >> root of the overlay. Finally the directory is moved to the new >> -- >> 2.7.4 >> signature.asc Description: PGP signature
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu 2016-12-08 11:48 -0800, 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 > --- > kernel/module.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Aaron Tomlin -- Aaron Tomlin signature.asc Description: PGP signature
Re: [RFC 10/10] kmod: add a sanity check on module loading
On Fri, Dec 09, 2016 at 12:56:21PM -0800, Linus Torvalds wrote:
> On Fri, Dec 9, 2016 at 12:03 PM, Martin Wilck wrote:
> > On Thu, 2016-12-08 at 11:49 -0800, Luis R. Rodriguez wrote:
> >>
> >> Although this does get us in the business of keeping alias maps in
> >> kernel, the the work to support and maintain this is trivial.
> >
> > You've implemented a special treatment for request_module("fs-$X")in
> > finished_kmod_load(), but there are many more aliases defined (and
> > used) in the kernel. Do you plan to implement special code for "char-
> > major-$X", "crypto-$X", "binfmt-$X" etc. later?
>
> Yeah, no, that is just complete garbage.
>
> Those module aliases already exist in the module info section. We just
> don't parse the alias tags in the kernel.
>
> So the real fix is to make find_module_all() just do that.
Ah yes, that is much sexier, this is now done and it works nicely, thanks
for the suggestion.
> Doing random ad-hoc "let's prefix with 'fs-xyz'" games are completely
> unacceptable. That's just pure shit. Stop this idiocy.
Look at that fin DNA in action :)
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 PATCH v3 1/1] docs-rst: automatically convert Graphviz and SVG images
On Thu, Dec 15, 2016 at 06:01:42PM +0100, Daniel Vetter wrote:
> On Wed, Dec 07, 2016 at 09:49:44AM +0100, Markus Heiser wrote:
> > This patch brings scalable figure, image handling and a concept to
> > embed *render* markups:
> >
> > * DOT (http://www.graphviz.org)
> > * SVG
> >
> > For image handling use the 'image' replacement::
> >
> > .. kernel-image:: svg_image.svg
> >:alt:simple SVG image
> >
> > For figure handling use the 'figure' replacement::
> >
> > .. kernel-figure:: svg_image.svg
> >:alt:simple SVG image
> >
> >SVG image example
> >
> > Embed *render* markups (or languages) like Graphviz's **DOC** is
> > provided by the *render* directive.::
> >
> > .. kernel-render:: DOT
> > :alt: foobar digraph
> > :caption: Embedded **DOT** (Graphviz) code.
> >
> > digraph foo {
> > "bar" -> "baz";
> > }
> >
> > The *render* directive is a concept to integrate *render* markups and
> > languages, yet supported markups:
> >
> > * DOT: render embedded Graphviz's **DOC**
> > * SVG: render embedded Scalable Vector Graphics (**SVG**)
> >
> > Signed-off-by: Markus Heiser
>
> I started playing around with this.
Another thing I've noticed after adding my hack, and I don't even know how
that works in your code so top comment: The auto-generated .dot file for
in-line kernel-render directives seems to depend upon the content and
doesn't get auto-removed. Which means when I change back to an old version
of an inline dot it's not regenerated. Which also means I don't get to see
the stderr output again. For the kernel-render directive I think it'd be
better to pass the graph to dot via stdin.
-Daniel
>
> > ---
> > Documentation/conf.py | 2 +-
> > Documentation/doc-guide/hello.dot | 3 +
> > Documentation/doc-guide/sphinx.rst| 90 +-
> > Documentation/doc-guide/svg_image.svg | 10 +
> > Documentation/process/changes.rst | 8 +-
> > Documentation/sphinx/kfigure.py | 505
> > ++
> > 6 files changed, 612 insertions(+), 6 deletions(-)
> > create mode 100644 Documentation/doc-guide/hello.dot
> > create mode 100644 Documentation/doc-guide/svg_image.svg
> > create mode 100644 Documentation/sphinx/kfigure.py
> >
> > diff --git a/Documentation/conf.py b/Documentation/conf.py
> > index 1ac958c..19ea030 100644
> > --- a/Documentation/conf.py
> > +++ b/Documentation/conf.py
> > @@ -34,7 +34,7 @@ from load_config import loadConfig
> > # Add any Sphinx extension module names here, as strings. They can be
> > # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> > # ones.
> > -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
> > +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
> > 'kfigure']
> >
> > # The name of the math extension changed on Sphinx 1.4
> > if major == 1 and minor > 3:
> > diff --git a/Documentation/doc-guide/hello.dot
> > b/Documentation/doc-guide/hello.dot
> > new file mode 100644
> > index 000..504621d
> > --- /dev/null
> > +++ b/Documentation/doc-guide/hello.dot
> > @@ -0,0 +1,3 @@
> > +graph G {
> > + Hello -- World
> > +}
> > diff --git a/Documentation/doc-guide/sphinx.rst
> > b/Documentation/doc-guide/sphinx.rst
> > index 96fe7ccb..c7c7876 100644
> > --- a/Documentation/doc-guide/sphinx.rst
> > +++ b/Documentation/doc-guide/sphinx.rst
> > @@ -34,8 +34,10 @@ format-specific subdirectories under
> > ``Documentation/output``.
> >
> > To generate documentation, Sphinx (``sphinx-build``) must obviously be
> > installed. For prettier HTML output, the Read the Docs Sphinx theme
> > -(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf``
> > is also
> > -needed. All of these are widely available and packaged in distributions.
> > +(``sphinx_rtd_theme``) is used if available. For PDF output you'll also
> > need
> > +``XeLaTeX`` and CairoSVG (http://cairosvg.org) or alternatively
> > ``convert(1)``
> > +from ImageMagick (https://www.imagemagick.org). All of these are widely
> > +available and packaged in distributions.
> >
> > To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
> > variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more
> > verbose
> > @@ -217,3 +219,87 @@ Rendered as:
> >* .. _`last row`:
> >
> > - column 3
> > +
> > +
> > +Figures & Images
> > +
> > +
> > +If you want to add an image, you should use the ``kernel-figure`` and
> > +``kernel-image`` directives. E.g. to insert a figure with a scalable
> > +image format use SVG::
> > +
> > +.. kernel-figure:: svg_image.svg
> > + :alt:simple SVG image
> > +
> > + SVG image example
> > +
> > +.. kernel-figure:: svg_image.svg
> > + :alt:simple SVG image
> > +
> > + SVG image example
> > +
> > +The kernel figure (and image) directive support **DOT** formated files, see
> > +
> > +* DOT:
Re: [RFC PATCH v3 1/1] docs-rst: automatically convert Graphviz and SVG images
On Wed, Dec 07, 2016 at 09:49:44AM +0100, Markus Heiser wrote:
> This patch brings scalable figure, image handling and a concept to
> embed *render* markups:
>
> * DOT (http://www.graphviz.org)
> * SVG
>
> For image handling use the 'image' replacement::
>
> .. kernel-image:: svg_image.svg
>:alt:simple SVG image
>
> For figure handling use the 'figure' replacement::
>
> .. kernel-figure:: svg_image.svg
>:alt:simple SVG image
>
>SVG image example
>
> Embed *render* markups (or languages) like Graphviz's **DOC** is
> provided by the *render* directive.::
>
> .. kernel-render:: DOT
> :alt: foobar digraph
> :caption: Embedded **DOT** (Graphviz) code.
>
> digraph foo {
> "bar" -> "baz";
> }
>
> The *render* directive is a concept to integrate *render* markups and
> languages, yet supported markups:
>
> * DOT: render embedded Graphviz's **DOC**
> * SVG: render embedded Scalable Vector Graphics (**SVG**)
>
> Signed-off-by: Markus Heiser
I started playing around with this.
> ---
> Documentation/conf.py | 2 +-
> Documentation/doc-guide/hello.dot | 3 +
> Documentation/doc-guide/sphinx.rst| 90 +-
> Documentation/doc-guide/svg_image.svg | 10 +
> Documentation/process/changes.rst | 8 +-
> Documentation/sphinx/kfigure.py | 505
> ++
> 6 files changed, 612 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/doc-guide/hello.dot
> create mode 100644 Documentation/doc-guide/svg_image.svg
> create mode 100644 Documentation/sphinx/kfigure.py
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 1ac958c..19ea030 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,7 @@ from load_config import loadConfig
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
> 'kfigure']
>
> # The name of the math extension changed on Sphinx 1.4
> if major == 1 and minor > 3:
> diff --git a/Documentation/doc-guide/hello.dot
> b/Documentation/doc-guide/hello.dot
> new file mode 100644
> index 000..504621d
> --- /dev/null
> +++ b/Documentation/doc-guide/hello.dot
> @@ -0,0 +1,3 @@
> +graph G {
> + Hello -- World
> +}
> diff --git a/Documentation/doc-guide/sphinx.rst
> b/Documentation/doc-guide/sphinx.rst
> index 96fe7ccb..c7c7876 100644
> --- a/Documentation/doc-guide/sphinx.rst
> +++ b/Documentation/doc-guide/sphinx.rst
> @@ -34,8 +34,10 @@ format-specific subdirectories under
> ``Documentation/output``.
>
> To generate documentation, Sphinx (``sphinx-build``) must obviously be
> installed. For prettier HTML output, the Read the Docs Sphinx theme
> -(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf`` is
> also
> -needed. All of these are widely available and packaged in distributions.
> +(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
> +``XeLaTeX`` and CairoSVG (http://cairosvg.org) or alternatively
> ``convert(1)``
> +from ImageMagick (https://www.imagemagick.org). All of these are widely
> +available and packaged in distributions.
>
> To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
> variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more
> verbose
> @@ -217,3 +219,87 @@ Rendered as:
>* .. _`last row`:
>
> - column 3
> +
> +
> +Figures & Images
> +
> +
> +If you want to add an image, you should use the ``kernel-figure`` and
> +``kernel-image`` directives. E.g. to insert a figure with a scalable
> +image format use SVG::
> +
> +.. kernel-figure:: svg_image.svg
> + :alt:simple SVG image
> +
> + SVG image example
> +
> +.. kernel-figure:: svg_image.svg
> + :alt:simple SVG image
> +
> + SVG image example
> +
> +The kernel figure (and image) directive support **DOT** formated files, see
> +
> +* DOT: http://graphviz.org/pdf/dotguide.pdf
> +* Graphviz: http://www.graphviz.org/content/dot-language
> +
> +A simple example::
> +
> + .. kernel-figure:: hello.dot
> + :alt:hello world
> +
> + DOT's hello world example
> +
> +.. kernel-figure:: hello.dot
> + :alt:hello world
> +
> + DOT's hello world example
> +
> +Embed *render* markups (or languages) like Graphviz's **DOC** is provided by
> the
s/DOC/DOT/ I think? Same in the commit message.
> +``kernel-render`` directives.::
> +
> + .. kernel-render:: DOT
> + :alt: foobar digraph
> + :caption: Embedded **DOT** (Graphviz) code.
> +
> + digraph foo {
> + "bar" -> "baz";
> + }
> +
> +How this will be rendered depends on the installed tools. If Graphviz is
> +installed, you will see an vector image. If not t
Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit
On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote: > This adds helpers for getting access to the kmod count and limit from > userspace. While at it, this also lets userspace fine tune the kmod > limit after boot, it uses the shiny new proc_douintvec_minmax(). > > These knobs should help userspace more gracefully and deterministically > handle module loading. > > Signed-off-by: Luis R. Rodriguez > --- > include/linux/kmod.h | 8 + > kernel/kmod.c| 83 > ++-- > kernel/sysctl.c | 14 + > 3 files changed, 103 insertions(+), 2 deletions(-) I am not sure if it is worth it. As you say in the 3rd patch, there was rather low limit for 16 years and nobody probably had problems with it. Anyway, it seems that such know should also get documented in Documentation/sysctl/kernel.txt Best Regards, Petr -- 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 v4] watchdog: nic7018_wdt: Add NIC7018 watchdog driver
Hi,
On 12/15/2016 02:05 AM, Hui Chun Ong wrote:
Add support for the watchdog timer on PXI Embedded Controller.
Signed-off-by: Hui Chun Ong
---
v3: Update timeout calculation from miliseconds to seconds.
Reorder watchdog_regiser_device() call to prevent potential race condition.
v2: Remove mutex lock and platform_device *pdev fields from struct nic7018_wdt.
Update config NIC7018_WDT description.
Update nic7018_get_config() to never return error.
Remove checking for IO resource size in nic7018_probe().
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 | 265 +
4 files changed, 281 insertions(+)
create mode 100644 drivers/watchdog/nic7018_wdt.c
[ ... ]
+
+static int nic7018_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct watchdog_device *wdd;
+ struct nic7018_wdt *wdt;
+ struct resource *io_rc;
+ int ret;
+
+ wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
+ if (!wdt)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, wdt);
+
+ io_rc = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (!io_rc) {
+ dev_err(dev, "missing IO resources\n");
+ return -EINVAL;
+ }
+
+ if (!devm_request_region(dev, io_rc->start, resource_size(io_rc),
+KBUILD_MODNAME)) {
+ dev_err(dev, "failed to get IO region\n");
+ return -EBUSY;
+ }
+
+ wdt->io_base = io_rc->start;
+ wdd = &wdt->wdd;
+ wdd->info = &nic7018_wdd_info;
+ wdd->ops = &nic7018_wdd_ops;
+ wdd->min_timeout = WDT_MIN_TIMEOUT;
+ wdd->max_timeout = WDT_MAX_TIMEOUT;
+ wdd->timeout = WDT_DEFAULT_TIMEOUT;
+ wdd->parent = dev;
+
+ watchdog_set_drvdata(wdd, wdt);
+ watchdog_set_nowayout(wdd, nowayout);
+
+ ret = watchdog_init_timeout(wdd, timeout, dev);
+ if (ret)
+ dev_warn(dev, "unable to set timeout value, using default\n");
+
+ /* Unlock WDT register */
+ outb(UNLOCK, wdt->io_base + WDT_REG_LOCK);
+
+ ret = watchdog_register_device(wdd);
+ if (ret) {
+ dev_err(dev, "failed to register watchdog\n");
I don't want to be annoying, but for consistency you'll need to lock the device
here.
+ return ret;
+ }
+
+ dev_dbg(dev, "io_base=0x%04X, timeout=%d, nowayout=%d\n",
+ wdt->io_base, timeout, nowayout);
+ return 0;
+}
+
+static int nic7018_remove(struct platform_device *pdev)
+{
+ struct nic7018_wdt *wdt = platform_get_drvdata(pdev);
+
+ nic7018_stop(&wdt->wdd);
This always bothers me. I _think_ the core will prevent a driver from unloading
while the watchdog is running open (and thus might be running), which would make
this unnecessary. But I am never really sure and will have to look it up.
Guenter
+ watchdog_unregister_device(&wdt->wdd);
+
+ /* Lock WDT register */
+ outb(LOCK, wdt->io_base + WDT_REG_LOCK);
+
+ return 0;
+}
+
+static const struct acpi_device_id nic7018_device_ids[] = {
+ {"NIC7018", 0},
+ {"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, nic7018_device_ids);
+
+static struct platform_driver watchdog_driver = {
+ .probe = nic7018_probe,
+ .remove = nic7018_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .acpi_match_table = ACPI_PTR(nic7018_device_ids),
+ },
+};
+
+module_platform_driver(watchdog_driver);
+
+MODULE_DESCRIPTION("National Instruments NIC7018 Watchdog driver");
+MODULE_AUTHOR("Hui Chun Ong ");
+MODULE_LICENSE("GPL");
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] ovl: fix reStructuredText syntax errors in documentation
On Thu, 15 Dec 2016 09:58:31 +0200 Amir Goldstein wrote: > Ping. Patches that show up right before the merge window opens can get the back-burner treatment for a bit, sorry. > Neil, > I found these syntax errors when I posted your page on my wiki: > https://github.com/amir73il/overlayfs/wiki/Overlayfs-overview > The "errors" are unsurprising, given that this is not (yet) an RST file. What we would *really* like to do is integrate this into the growing body of Sphinx documentation. That involves thinking about where filesystem documentation goes in that world, either in the admin manual or into a new one. Meanwhile, though, the RST conversion on this file is a fine thing to do, and I'll be happy to apply the patch once I start working on 4.11 stuff. 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: [RFC 06/10] kmod: provide sanity check on kmod_concurrent access
On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote:
> Only decrement *iff* we're possitive. Warn if we've hit
> a situation where the counter is already 0 after we're done
> with a modprobe call, this would tell us we have an unaccounted
> counter access -- this in theory should not be possible as
> only one routine controls the counter, however preemption is
> one case that could trigger this situation. Avoid that situation
> by disabling preemptiong while we access the counter.
>
> Signed-off-by: Luis R. Rodriguez
> ---
> kernel/kmod.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index ab38539f7e91..09cf35a2075a 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -113,16 +113,28 @@ static int call_modprobe(char *module_name, int wait)
>
> static int kmod_umh_threads_get(void)
> {
> + int ret = 0;
> +
> + preempt_disable();
> atomic_inc(&kmod_concurrent);
> if (atomic_read(&kmod_concurrent) < max_modprobes)
> - return 0;
> - atomic_dec(&kmod_concurrent);
> - return -EBUSY;
> + goto out;
I though more about it and the disabled preemtion might make
sense here. It makes sure that we are not rescheduled here
and that kmod_concurrent is not increased by mistake for too long.
Well, it still would make sense to increment the value
only when it is under the limit and set the incremented
value using cmpxchg to avoid races.
I mean to use similar trick that is used by refcount_inc(), see
https://lkml.kernel.org/r/20161114174446.832175...@infradead.org
> + atomic_dec_if_positive(&kmod_concurrent);
> + ret = -EBUSY;
> +out:
> + preempt_enable();
> + return 0;
> }
>
> static void kmod_umh_threads_put(void)
> {
> - atomic_dec(&kmod_concurrent);
> + int ret;
> +
> + preempt_disable();
> + ret = atomic_dec_if_positive(&kmod_concurrent);
> + WARN_ON(ret < 0);
> + preempt_enable();
The disabled preemption does not make much sense here.
We do not need to tie the atomic operation and the WARN
together so tightly.
Best Regards,
Petr
--
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
On Thu 2016-12-08 22:08:59, Luis R. Rodriguez wrote:
> On Thu, Dec 08, 2016 at 12:29:42PM -0800, Kees Cook wrote:
> > 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
> > > @@ -108,6 +111,20 @@ static int call_modprobe(char *module_name, int wait)
> > > return -ENOMEM;
> > > }
> > >
> > > +static int kmod_umh_threads_get(void)
> > > +{
> > > + atomic_inc(&kmod_concurrent);
This approach might actually cause false failures. If we
are on the limit and more processes do this increment
in parallel, it makes the number bigger that it should be.
> > > + if (atomic_read(&kmod_concurrent) < max_modprobes)
> > > + return 0;
> > > + atomic_dec(&kmod_concurrent);
> > > + return -ENOMEM;
> > > +}
> > > +
> > > +static void kmod_umh_threads_put(void)
> > > +{
> > > + atomic_dec(&kmod_concurrent);
> > > +}
> >
> > Can you use a kref here instead? We're trying to kill raw use of
> > atomic_t for reference counting...
>
> That's a much broader functional change than I was looking for, but I am up
> for
> it. Can you describe the benefit of using kref you expect or why this is an
> ongoing crusade? Since its a larger functional change how about doing this
> change later, and we can test impact with the tress test driver. In theory if
> there are benefits can't we add a test case to prove the gains?
Kees probably refers to the kref improvements that Peter Zijlstra
is working on, see
https://lkml.kernel.org/r/20161114174446.832175...@infradead.org
The advantage is that the new refcount API handles over and
underflow.
Another advantage is that it increments/decrements the value
only when it is safe. It uses cmpxchg to make sure that
the checks are valid.
Best Regards,
Petr
--
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
[PATCH v4] watchdog: nic7018_wdt: Add NIC7018 watchdog driver
Add support for the watchdog timer on PXI Embedded Controller.
Signed-off-by: Hui Chun Ong
---
v3: Update timeout calculation from miliseconds to seconds.
Reorder watchdog_regiser_device() call to prevent potential race condition.
v2: Remove mutex lock and platform_device *pdev fields from struct nic7018_wdt.
Update config NIC7018_WDT description.
Update nic7018_get_config() to never return error.
Remove checking for IO resource size in nic7018_probe().
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 | 265 +
4 files changed, 281 insertions(+)
create mode 100644 drivers/watchdog/nic7018_wdt.c
diff --git a/Documentation/watchdog/watchdog-parameters.txt
b/Documentation/watchdog/watchdog-parameters.txt
index e21850e..4f7d86d 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -209,6 +209,11 @@ timeout: Initial watchdog timeout in seconds
(0
+#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)
+
+#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
+#define WDT_DEFAULT_TIMEOUT80
+
+#define WDT_MAX_COUNTER15
+
+static unsigned int timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout,
+"Watchdog timeout in seconds. (default="
+__MODULE_STRING(WDT_DEFAULT_TIMEOUT) ")");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+"Watchdog cannot be stopped once started. (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct nic7018_wdt {
+ u16 io_base;
+ u32 period;
+ struct watchdog_device wdd;
+};
+
+struct nic7018_config {
+ u32 period;
+ u8 divider;
+};
+
+static const struct nic7018_config nic7018_configs[] = {
+ { 2, 4 },
+ { 32, 5 },
+};
+
+static inline u32 nic7018_timeout(u32 period, u8 counter)
+{
+ return period * counter - period / 2;
+}
+
+static const struct nic7018_config *nic7018_get_config(u32 timeout,
+ u8 *counter)
+{
+ const struct nic7018_config *config;
+ u8 count;
+
+ if (timeout < 30 && timeout != 16) {
+ config = &nic7018_configs[0];
+ count = timeout / 2 + 1;
+ } else {
+ config = &nic7018_configs[1];
+ count = DIV_ROUND_UP(timeout + 16, 32);
+
+ if (count > WDT_MAX_COUNTER)
+ count = WDT_MAX_COUNTER;
+ }
+ *counter = count;
+ return config;
+}
+
+static int nic7018_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ struct nic7018_wdt *wdt = watchdog_get_drvdata(wdd);
+ const struct nic7018_config *config;
+ u8 counter;
+
+ config = nic7018_get_config(timeout, &counter);
+
+ outb(counter << 4 | config->divider,
+wdt->io_base + WDT_PRESET_PRESCALE);
+
+ wdd->timeout = nic7018_timeout(config->period, counter);
+ wdt->period = config->period;
+
+ return 0;
+}
+
+static int nic7018_start(struct watchdog_device *wdd)
+{
+ struct nic7018_wdt *wdt = watchdog_get_drvdata(wdd);
+ u8 control;
+
+ nic7018_set_timeout(wdd, wdd->timeout);
+
+ control = inb(wdt->io_base + WDT_RELOAD_CTRL);
+ outb(control | WDT_RELOAD_PORT_EN, wdt->io_base + WDT_RELOAD_CTRL);
+
+ outb(1, wdt->io_base + WDT_RELOAD_PORT);
+
+ control = inb(wdt->io_base + WDT_CTRL);
+ outb(control | WDT_CTRL_RESET_EN, wdt->io_base + WDT_CTRL);
+
+ return 0;
+}
+
+static int nic7018_stop(struct watchdog_device *wdd)
+{
+ struct nic7018_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ outb(0, wdt->io_base + WDT_CTRL);
+ outb(0, wdt->io_base + WDT_RELOAD_CTRL);
+ outb(0xF0, wdt->io_base + WDT_PRESET_PRESCALE);
+
+ return 0;
+}
+
+static int nic7018_ping(struct watchdog_device *wdd)
+{
+ struct nic7018_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ outb(1, wdt->io_base + WDT_RELOAD_PORT);
+
+ return 0;
+}
+
+static unsigned int nic7018_get_timeleft(struct watchdog_device *wdd)
+{
+ struct nic7018_wdt *wdt = watchdog_get_drvdata(wdd);
[PATCH] xtensa: update DMA-related Documentation/features entries
xtensa supports DMA API debug and contiguous DMA, mark it as such. Signed-off-by: Max Filippov --- Documentation/features/io/dma-api-debug/arch-support.txt | 2 +- Documentation/features/io/dma-contiguous/arch-support.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/features/io/dma-api-debug/arch-support.txt b/Documentation/features/io/dma-api-debug/arch-support.txt index 4f4a344..ffa522a 100644 --- a/Documentation/features/io/dma-api-debug/arch-support.txt +++ b/Documentation/features/io/dma-api-debug/arch-support.txt @@ -36,5 +36,5 @@ | um: | TODO | | unicore32: | TODO | | x86: | ok | -| xtensa: | TODO | +| xtensa: | ok | --- diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt index a97e8e3..83d2cf9 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -36,5 +36,5 @@ | um: | TODO | | unicore32: | TODO | | x86: | ok | -| xtensa: | TODO | +| xtensa: | ok | --- -- 2.1.4 -- 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: [f2fs-dev] [GIT PULL] f2fs update for 4.10
Em Wed, 14 Dec 2016 17:18:57 -0800
Greg Kroah-Hartman escreveu:
> On Wed, Dec 14, 2016 at 04:38:32PM -0800, Linus Torvalds wrote:
> > On Wed, Dec 14, 2016 at 11:18 AM, Jaegeuk Kim wrote:
> > >
> > > BTW, I just downloaded mainline, and tried to build a debian package but
> > > failed due to missing Documentation/Changes.
> > >
> > > I've found out that it was renamed by commit 186128f753
> > > ("docs-rst: add documents to development-process")
> > >
> > > And when taking a look at its description, it was supposed to do symlink
> > > for
> > > document files, but did rename all of them.
> >
> > Indeed.
> >
> > Tssk. I've added the one symlink. Maybe we should add the others too,
> > but for now let's keep it minimal.
>
> Crap, I missed that in the patch I acked, I should have noticed that.
>
> Thanks for the symlink, Mauro, want to make the rest of the files actual
> symlinks as well, instead of just the rename?
Hi Greg/Linus,
FYI, there was a discussion about that on lkml and linux-doc.
On that time, we considered 3 alternatives for those well-known
files:
1) just rename;
2) use symlink;
3) keep a short text telling that the file was moved, replacing
the previous contents.
After discussions, we end by using (3) for a short group of files:
README
Documentation/CodingStyle
Documentation/SubmittingPatches
>From my side, while I think all alternatives work fine, my personal
preference in short term[1] is for symlinks, just because it makes
easier to distinguish what files still need conversion.
[1] In long term, it probably makes more sense to get rid of those
symlinks at Documentation/* and use a different content at README file,
for example, adding references there to the main books at the Kernel
documentation, e. g. something like Documentation/00-INDEX.
So, if you prefer symlinks instead, feel free to merge the enclosed
patch. It is using soft symlinks, with I guess works better than
hard symlinks.
Thanks,
Mauro
[PATCH RFC] docs-rst: use symlinks for well-known renamed doc files
There was a discussion about that while reviewing commit 186128f75392
("docs-rst: add documents to development-process"), about what to do
with well-known documentation files.
On that time, we considered 3 alternatives:
1) just rename the files;
2) use symlink on the previous location;
3) keep a short text telling that the file was moved, replacing
the previous file contents.
We end by using (3) for a short group of files:
README
Documentation/CodingStyle
Documentation/SubmittingPatches
Commit 852d21ae1fcd ("docs: add back 'Documentation/Changes' file
(as symlink)") added another one (Documentation/Changes), but as a
symlink.
Let's standardize this by using the same logic on those
well-known renamed docs, replacing those files by symlinks.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
deleted file mode 100644
index 320983ca114e..
--- a/Documentation/CodingStyle
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to process/coding-style.rst
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
new file mode 12
index ..b4a9864269eb
--- /dev/null
+++ b/Documentation/CodingStyle
@@ -0,0 +1 @@
+process/coding-style.rst
\ No newline at end of file
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
deleted file mode 100644
index 81455705e4a6..
--- a/Documentation/SubmittingPatches
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to process/submitting-patches.rst
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 12
index ..4a70bb54
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1 @@
+process/submitting-patches.rst
\ No newline at end of file
diff --git a/README b/README
deleted file mode 100644
index b2ba4aaa3a71..
--- a/README
+++ /dev/null
@@ -1,18 +0,0 @@
-Linux kernel
-
-
-This file was moved to Documentation/admin-guide/README.rst
-
-Please notice that there are several guides for kernel developers and users.
-These guides can be rendered in a number of formats, like HTML and PDF.
-
-In order to build the documentation, use ``make htmldocs`` or
-``make pdfdocs``.
-
-There are various text files in the Documentation/ subdirectory,
-several of them using the Restructured Text markup notation.
-See Documentation/00-INDEX for a list of what is contained in each file.
-
-Please read the Documentation/process/changes.rst file, as it contains the
-requirements for building and running the kernel, and information about
-the problems which may result by upgrading your kernel.
diff --git a/README b/README
new file mode 12
index ..c382e2a2017b
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+Documentation/admin-guide/README.rst
\ No newline at end of file
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] ovl: fix reStructuredText syntax errors in documentation
On Thu, Dec 8, 2016 at 9:49 AM, Amir Goldstein wrote: > - Fix broken long line block quote > - Fix missing newline before bullets list > - Use correct numbered list syntax > Ping. Neil, I found these syntax errors when I posted your page on my wiki: https://github.com/amir73il/overlayfs/wiki/Overlayfs-overview Not sure if this patch should go through Miklos's tree or John's tree, but is surely needs the ACK from you. Thanks, Amir. > Signed-off-by: Amir Goldstein > --- > Documentation/filesystems/overlayfs.txt | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/filesystems/overlayfs.txt > b/Documentation/filesystems/overlayfs.txt > index fb6f307..634d03e 100644 > --- a/Documentation/filesystems/overlayfs.txt > +++ b/Documentation/filesystems/overlayfs.txt > @@ -66,7 +66,7 @@ At mount time, the two directories given as mount options > "lowerdir" and > "upperdir" are combined into a merged directory: > >mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\ > -workdir=/work /merged > + workdir=/work /merged > > The "workdir" needs to be an empty directory on the same filesystem > as upperdir. > @@ -118,6 +118,7 @@ programs. > > seek offsets are assigned sequentially when the directories are read. > Thus if > + >- read part of a directory >- remember an offset, and close the directory >- re-open the directory some time later > @@ -137,12 +138,12 @@ When renaming a directory that is on the lower layer or > merged (i.e. the > directory was not created on the upper layer to start with) overlayfs can > handle it in two different ways: > > -1) return EXDEV error: this error is returned by rename(2) when trying to > +1. return EXDEV error: this error is returned by rename(2) when trying to > move a file or directory across filesystem boundaries. Hence > applications are usually prepared to hande this error (mv(1) for example > recursively copies the directory tree). This is the default behavior. > > -2) If the "redirect_dir" feature is enabled, then the directory will be > +2. If the "redirect_dir" feature is enabled, then the directory will be > copied up (but not the contents). Then the "trusted.overlay.redirect" > extended attribute is set to the path of the original location from the > root of the overlay. Finally the directory is moved to the new > -- > 2.7.4 > -- 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
