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

[Rusty Russell]

"Luis R. Rodriguez"  writes:
> On Dec 16, 2016 9:54 PM, "Rusty Russell"  wrote:
> > AFAICT the mistake here is that kmod is returning "done, OK" when the
> > module it is trying to load is already loading (but not finished
> > loading).  That's the root problem; it's an attempt at optimization by
> > kmod which goes awry.
>
> This is true! To be precise though the truth of the matter is that kmod'd
> respective usermode helper: modprobe can be buggy and may lie to us. It may
> allow request_module() to return 0 but since we don't validate it, any
> assumption we make can be deadly. In the case of get_fs_type() its a null
> dereference.

Wait, what??  I can't see that in get_fs_type, which hasn't changed
since 2013.  If a caller is assuming get_fs_type() doesn't return NULL,
they're broken and need fixing of course:

struct file_system_type *get_fs_type(const char *name)
{
struct file_system_type *fs;
const char *dot = strchr(name, '.');
int len = dot ? dot - name : strlen(name);

fs = __get_fs_type(name, len);
if (!fs && (request_module("fs-%.*s", len, name) == 0))
fs = __get_fs_type(name, len);

if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {
put_filesystem(fs);
fs = NULL;
}
return fs;
}

Where does this NULL-deref is the module isn't correctly loaded?

> *Iff* we want a sanity check to verify kmod's umh is not lying to us we
> need to verify after 0 was returned that it was not lying to us. Since kmod
> accepts aliases but find_modules_all() only works on the real module name a
> validation check cannot happen when all you have are aliases.

request_module() should block until resolution, but that's fundamentally
a userspace problem.  Let's not paper over it in kernelspace.

> *Iff* we are sure we don't want a validation (or another earlier
> optimization to avoid calling out to modrobe if the alias requested is
> already present, which does the time shaving I mentioned on the tests) then
> naturally no request_module() calls returning 0 can assert information
> about the requested module. I think we might need to change more code if we
> accept we cannot trust request_module() calls, or we accept userspace
> telling the kernel something may mean we sometimes crash. This later
> predicament seems rather odd so hence the patch.
>
> Perhaps in some cases validation of work from a umh is not critical in
> kernel but for request_module() I can tell you that today get_fs_type code
> currently asserts the module found can never be NULL.

OK, what am I missing in the code above?  

> > Looking at the code in the kernel, we *already* get this right: block if
> > a module is still loading anyway.  Once it succeeds we return -EBUSY if
> >
> > it fails we'll proceed to try to load it again.
> >
> > I don't understand what you're trying to fix with adding aliases
> > in-kernel?
>
> Two fold now:
>
> a) validation on request_module() work when an alias is used

But why?

> b) since kmod accepts aliaes, if we get aliases support, it means we could
> *also* preemptively avoid calling out to userspace for modules already
> present.

No, because once we have a module we don't request it: requesting is the
fallback case.

> >> FWIW a few things did occur to me:
> >>
> >> a) list_add_rcu() is used so new modules get added first
> >
> > Only after we're sure that there are no duplicates.
> >
> >
> OK! This is a very critical assertion. I should be able to add a debug
> WARN_ON() should two modules be on the modules list for the same module
> then ?

Yes, names must be unique.

>> b) find_module_all() returns the last module which was added as it
> traverses
>>the module list
>
>> BTW should find_module_all() use rcu to traverse?
>
> Yes; the kallsyms code does this on Oops.  Not really a big issue in
> practice, but a nice fix.
>
> Ok, will bundle into my queue.

Please submit to Jessica for her module queue, as it's orthogonal
AFAICT.

> I will note though that I still think there's a bug in this code --
> upon a failure other "spinning" requests can fail, I believe this may
> be due to not having another state or informing pending modules too
> early of a failure but I haven't been able to prove this conjecture
> yet.

That's possible, but I can't see it from quickly re-checking the code.

The module should be fully usable at this point; the module's init has
been called successfully, so in the case of __get_fs_type() it should
now succeed.  The module cleans up its init section, but that should be
independent.

If there is a race, it's likely to be when some other caller wakes the
queue.  Moving the wakeup as soon as possible should make it easier to
trigger:

diff --git a/kernel/module.c b/kernel/module.c
index f57dd63186e6..78bd89d41a22 100644
--- 

[PULL] One last documentation fix

[Jonathan Corbet]

The following changes since commit
3fa71d0f58a9b9df84e8e79196f961bcfbf01b2e:

  crypto: doc - optimize compilation (2016-12-13 16:38:07 -0700)

are available in the git repository at:

  git://git.lwn.net/linux.git tags/doc-4.10-3

for you to fetch changes up to 217e2bfab22e740227df09f22165e834cddd8a3b:

  docs: sphinx-extensions: make rstFlatTable work with docutils 0.13 
(2016-12-18 13:30:29 -0700)


A single fix for the build system.  It would appear that the docutils
developers, in their wisdom, broke the API in the 0.13 release.  This fix
detects the breakage and allows the docs to be built with both the old and
new versions.


Dmitry Shachnev (1):
  docs: sphinx-extensions: make rstFlatTable work with docutils 0.13

 Documentation/sphinx/rstFlatTable.py | 5 +
 1 file changed, 5 insertions(+)
--
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: Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Cihangir Akturk]

On Sun, Dec 18, 2016 at 12:52:12AM +0200, Ozgur Karatas wrote:
> 17.12.2016, 19:43, "Cihangir Akturk" :
> > In the actual implementation ether_addr_equal function tests for equality 
> > to 0
> > when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> > this operator to reflect the actual function.
> 
> why this "return" function need to be ==0? I think, u16 functions read memory 
> but "0" is should not be equalty.

XOR is true only when inputs differ. That means if inputs are the
same, then it outputs false (0) or whatever you call it. Then we
perform OR operation between those outputs. So if the result is 0 then
addr1 and addr2 is equal.

> This way, -for the code to work- memory should be everytime unaligned !=0.

Sorry I didn't quite get the point.
--
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] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Cihangir Akturk]

On Mon, Dec 19, 2016 at 04:13:13PM -0700, Jonathan Corbet wrote:
> On Mon, 19 Dec 2016 23:53:40 +0200
> Cihangir Akturk  wrote:
> 
> > In the actual implementation ether_addr_equal function tests for equality 
> > to 0
> > when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> > this operator to reflect the actual function.

I realized that I generated the patch with the -k flag to git
format-patch. And think that it'd be better to resend it without this
flag. Besides that nothing is changed in the patch itself. Sorry for
the noise.

> 
> I received this patch two days ago; has something changed that you're
> sending it again?
> 
> Meanwhile, there was a question from Ozgur Karatas on the patch, but I've
> not yet seen your response.

Ok, I'll try to answer his question.

> 
> Thanks,
> 
> jon

Cihangir
--
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] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Jonathan Corbet]

On Mon, 19 Dec 2016 23:53:40 +0200
Cihangir Akturk  wrote:

> In the actual implementation ether_addr_equal function tests for equality to 0
> when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> this operator to reflect the actual function.

I received this patch two days ago; has something changed that you're
sending it again?

Meanwhile, there was a question from Ozgur Karatas on the patch, but I've
not yet seen your response.

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

[PATCH] Documentation/unaligned-memory-access.txt: fix incorrect comparison operator

[Cihangir Akturk]

In the actual implementation ether_addr_equal function tests for equality to 0
when returning. It seems in commit 0d74c4 it is somehow overlooked to change
this operator to reflect the actual function.

Signed-off-by: Cihangir Akturk 
---
 Documentation/unaligned-memory-access.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/unaligned-memory-access.txt 
b/Documentation/unaligned-memory-access.txt
index a445da0..3f76c0c 100644
--- a/Documentation/unaligned-memory-access.txt
+++ b/Documentation/unaligned-memory-access.txt
@@ -151,7 +151,7 @@ bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
 #else
const u16 *a = (const u16 *)addr1;
const u16 *b = (const u16 *)addr2;
-   return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
+   return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) == 0;
 #endif
 }
 
-- 
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

[PATCH 0/2] PM / docs: linux/pm.h kerneldocs update and power/devices.txt conversion

[Rafael J. Wysocki]

Hi Everyone,

These two patches update kerneldoc comments in include/linux/pm.h ([1/2]) and
convert Documentation/power/devices.txt to reST ([2/2], RFC).

Please have a look, especially at patch [2/2], and let me know what can be done
in a better way.

Thanks,
Rafael

--
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 1/2] PM / core: Clean up kerneldoc comments in pm.h

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Refresh the struct dev_pm_ops kerneldoc comment, so that it looks
better and is more readable after processing by Sphinx, and drop
the kerneldoc marker from the "PM_EVENT_ messages" comment which
is not a proper kerneldoc and causes Sphinx to generate confusing
mess.

Signed-off-by: Rafael J. Wysocki 
---
 include/linux/pm.h |   98 +
 1 file changed, 48 insertions(+), 50 deletions(-)

Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -64,24 +64,7 @@ typedef struct pm_message {
 } pm_message_t;
 
 /**
- * struct dev_pm_ops - device PM callbacks
- *
- * Several device power state transitions are externally visible, affecting
- * the state of pending I/O queues and (for drivers that touch hardware)
- * interrupts, wakeups, DMA, and other hardware state.  There may also be
- * internal transitions to various low-power modes which are transparent
- * to the rest of the driver stack (such as a driver that's ON gating off
- * clocks which are not in active use).
- *
- * The externally visible transitions are handled with the help of callbacks
- * included in this structure in such a way that two levels of callbacks are
- * involved.  First, the PM core executes callbacks provided by PM domains,
- * device types, classes and bus types.  They are the subsystem-level callbacks
- * supposed to execute callbacks provided by device drivers, although they may
- * choose not to do that.  If the driver callbacks are executed, they have to
- * collaborate with the subsystem-level callbacks to achieve the goals
- * appropriate for the given system transition, given transition phase and the
- * subsystem the device belongs to.
+ * struct dev_pm_ops - device PM callbacks.
  *
  * @prepare: The principal role of this callback is to prevent new children of
  * the device from being registered after it has returned (the driver's
@@ -240,34 +223,6 @@ typedef struct pm_message {
  * driver's interrupt handler, which is guaranteed not to run while
  * @restore_noirq() is being executed.  Analogous to @resume_noirq().
  *
- * All of the above callbacks, except for @complete(), return error codes.
- * However, the error codes returned by the resume operations, @resume(),
- * @thaw(), @restore(), @resume_noirq(), @thaw_noirq(), and @restore_noirq(), 
do
- * not cause the PM core to abort the resume transition during which they are
- * returned.  The error codes returned in those cases are only printed by the 
PM
- * core to the system logs for debugging purposes.  Still, it is recommended
- * that drivers only return error codes from their resume methods in case of an
- * unrecoverable failure (i.e. when the device being handled refuses to resume
- * and becomes unusable) to allow us to modify the PM core in the future, so
- * that it can avoid attempting to handle devices that failed to resume and
- * their children.
- *
- * It is allowed to unregister devices while the above callbacks are being
- * executed.  However, a callback routine must NOT try to unregister the device
- * it was called for, although it may unregister children of that device (for
- * example, if it detects that a child was unplugged while the system was
- * asleep).
- *
- * Refer to Documentation/power/admin-guide/devices.rst for more information 
about the role
- * of the above callbacks in the system suspend process.
- *
- * There also are callbacks related to runtime power management of devices.
- * Again, these callbacks are executed by the PM core only for subsystems
- * (PM domains, device types, classes and bus types) and the subsystem-level
- * callbacks are supposed to invoke the driver callbacks.  Moreover, the exact
- * actions to be performed by a device driver's callbacks generally depend on
- * the platform and subsystem the device belongs to.
- *
  * @runtime_suspend: Prepare the device for a condition in which it won't be
  * able to communicate with the CPU(s) and RAM due to power management.
  * This need not mean that the device should be put into a low-power state.
@@ -287,11 +242,54 @@ typedef struct pm_message {
  * Check these conditions, and return 0 if it's appropriate to let the PM
  * core queue a suspend request for the device.
  *
- * Refer to Documentation/power/runtime_pm.txt for more information about the
- * role of the above callbacks in device runtime power management.
+ * Several device power state transitions are externally visible, affecting
+ * the state of pending I/O queues and (for drivers that touch hardware)
+ * interrupts, wakeups, DMA, and other hardware state.  There may also be
+ * internal transitions to various low-power modes which are transparent
+ * to the rest of the driver stack (such as a driver that's ON gating off
+ * 

Re: [RFC 1/1] MicroSemi Switchtec management interface driver

[Logan Gunthorpe]

On 19/12/16 10:02 AM, Keith Busch wrote:
> Some of this would be simplified if you use the managed device API's:
> devm_request_irq, pcim_enable_device, pcim_iomap, etc...

Thanks Keith, I'll look into using those.

Logan

--
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 1/1] MicroSemi Switchtec management interface driver

[Keith Busch]

On Sat, Dec 17, 2016 at 10:09:22AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint which
> enables some additional functionality. This includes:
> 
>  * Packet and Byte Counters
>  * Firmware Upgrades
>  * Event and Error logs
>  * Querying port link status
>  * Custom user firmware commands
> 
> This patch introduces the switchtec kernel module which provides
> pci driver that exposes a char device. The char device provides
> userspace access to this interface through read, write and (optionally)
> poll calls. Currently no ioctls have been implemented but a couple
> may be added in a later revision.
> 
> A short text file is provided which documents the switchtec driver
> and outlines the semantics of using the char device.

Some of this would be simplified if you use the managed device API's:
devm_request_irq, pcim_enable_device, pcim_iomap, etc...
--
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 0/1] New PCI Switch Management Driver

[Myron Stowe]

I guess the obvious questions is: why is a driver for a PCI switch
necessary?  The core works with all compliant switches today and there
are no specifics for a particular design or such.

So I guess I'd like to hear the reasoning and justifications for why a
driver for a common device that should conform to the specifications
and not seem to need any special considerations is required or desired
here.

On Sat, Dec 17, 2016 at 10:09 AM, Logan Gunthorpe  wrote:
> Hi,
>
> [Appologies: this is a resend for some people. Due to a configuration
> error the original email was rejected by the mailing lists. I hope
> this one makes it!]
>
> We're looking to get some initial feedback on a new driver for
> a line of PCIe switches produced and produced and sold by Microsemi.
> The goal is to get the process moving to get this code included in
> upstream hopefully for 4.11. Facebook is currently gearing up to
> use this hardware in its Open Compute Platform and is pushing to
> have this driver in the upstream kernel.
>
> The following patch briefly describes the hardware and provides
> the first draft of driver code. Currently, the driver works and
> has been tested but is not feature complete. Thus, we are not looking
> to get it merged immediately. However we would like some early review,
> specifically on the interfaces and core concepts so that we don't
> do a lot of work down a path the community would reject. Barring any
> objections to this RFC, we will flesh out all the features
> and provide a completed patch for inclusion in the coming weeks.
>
> Work on a userspace tool, that utilizes this driver, is also being
> done at [1]. The tool is currently also a bit of a skeleton and
> will be fleshed out assuming there are no serious objections to our
> userspace interface. In the end, the tool will be released with a
> GPL license.
>
> The patch is based off of the v4.9 release.
>
> Thanks for your review,
>
> Logan
>
> [1] https://github.com/sbates130272/switchtec-user
>
> Logan Gunthorpe (1):
>   MicroSemi Switchtec management interface driver
>
>  Documentation/switchtec.txt|  54 +++
>  MAINTAINERS|   9 +
>  drivers/pci/Kconfig|   1 +
>  drivers/pci/Makefile   |   1 +
>  drivers/pci/switch/Kconfig |  13 +
>  drivers/pci/switch/Makefile|   1 +
>  drivers/pci/switch/switchtec.c | 824 
> +
>  drivers/pci/switch/switchtec.h | 119 ++
>  8 files changed, 1022 insertions(+)
>  create mode 100644 Documentation/switchtec.txt
>  create mode 100644 drivers/pci/switch/Kconfig
>  create mode 100644 drivers/pci/switch/Makefile
>  create mode 100644 drivers/pci/switch/switchtec.c
>  create mode 100644 drivers/pci/switch/switchtec.h
>
> --
> 2.1.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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] Documentation: Fix a typo in IPMI.txt.

[Corey Minyard]

On 12/18/2016 01:11 PM, Rami Rosen wrote:

This patch fixes a trivial type in IPMI.txt.


Thanks, queued for next release.

-corey


Signed-off-by: Rami Rosen 
---
  Documentation/IPMI.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt
index 7229230..6962cab 100644
--- a/Documentation/IPMI.txt
+++ b/Documentation/IPMI.txt
@@ -257,7 +257,7 @@ and tell you when they come and go.
  
  Creating the User
  
-To user the message handler, you must first create a user using

+To use the message handler, you must first create a user using
  ipmi_create_user.  The interface number specifies which SMI you want
  to connect to, and you must supply callback functions to be called
  when data comes in.  The callback function can run at interrupt level,



--
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 v8 3/8] thunderbolt: Communication with the ICM (firmware)

[Mika Westerberg]

On Thu, Dec 01, 2016 at 05:21:01PM -0800, Andy Lutomirski wrote:
> On 09/28/2016 07:44 AM, Amir Levy wrote:
> > This patch provides the communication protocol between the
> > Intel Connection Manager(ICM) firmware that is operational in the
> > Thunderbolt controller in non-Apple hardware.
> > The ICM firmware-based controller is used for establishing and maintaining
> > the Thunderbolt Networking connection - we need to be able to communicate
> > with it.
> 
> I'm a bit late to the party, but here goes.  I have two big questions:
>
> 1. Why is this using netlink at all?  A system has zero or more Thunderbolt
> controllers, they're probed just like any other PCI devices (by nhi_probe()
> if I'm understanding correctly), they'll have nodes in sysfs, etc.
> Shouldn't there be a simple char device per Thunderbolt controller that a
> daemon can connect to?  This will clean up lots of things:
> 
> a) You can actually enforce one-daemon-at-a-time in a very natural way. Your
> current code seems to try, but it's rather buggy.  Your subscription count
> is a guess, your unsubscribe is entirely unchecked, and you are entirely
> unable to detect if a daemon crashes AFAICT.
> 
> b) You won't need all of the complexity that's currently there to figure out
> *which* Thunderbolt device a daemon is talking to.
> 
> c) You can use regular ioctl passing *structs* instead of netlink attrs.
> There's nothing wrong with netlink attrs, except that your driver seems to
> have a whole lot of boilerplate that just converts back and forth to regular
> structures.
> 
> d) The userspace code that does stuff like "send message, wait 150ms,
> receive reply, complain if no reply" goes away because ioctl is synchronous.
> (Or you can use read and write, but it's still simpler.)
> 
> e) You could have one daemon per Thunderbolt device if you were so inclined.
> 
> f) You get privilege separation in userspace.  Creating a netlink socket and
> dropping privilege is busted^Winteresting.  Opening a device node and
> dropping privilege works quite nicely.

I agree with your points. Using a char device here instead seems to be
the right way to go forward.

There is small problem, though. On non-Apple systems the host controller
only appears when something is connected to thunderbolt ports. So the
char device would not be there all the time. However, I think we can
still notify the userspace by sending an extra uevent when we detect
there is a PCIe device or inter-domain connection plugged in.

> 2. Why do you need a daemon anyway.  Functionally, what exactly does it do?
> (Okay, I get that it seems to talk to a giant pile of code running in SMM,
> and I get that Intel, for some bizarre reason, wants everyone except Apple
> to use this code in SMM, and that Apple (for entirely understandable
> reasons) turned it off, but that's beside the point. What does the user code
> do that's useful and that the kernel can't do all by itself?  The only
> really interesting bit I can see is the part that approves PCI devices.

As far as I can tell it is used to notify user (via dbus, I guess) that
there is a new PCIe device or inter-domain connection (networking)
available and it needs to be approved before it can be used.

I don't think anything prevents the kernel to do all this (Amir, Michael
can correct me if I'm mistaken).

In fact we could provide a simple "tbtadm" tool, built on top of the
char device that can be used to list and approve devices from shell
command line. That could also allow user to turn on "auto-approve" mode
or similar where the kernel approves all connected devices automatically
(if such functionality is wanted).

The daemon can still be useful for listening uevents generated by the
driver and forwarding approval requests to user.

> I'm not going to review this in detail, but here's a tiny bit:
> 
> > +static int nhi_genl_unsubscribe(__always_unused struct sk_buff *u_skb,
> > +   __always_unused struct genl_info *info)
> > +{
> > +   atomic_dec_if_positive();
> > +
> > +   return 0;
> > +}
> > +
> 
> This, for example, is really quite buggy.

OK.

> This entire function here:
> 
> > +static int nhi_genl_query_information(__always_unused struct sk_buff 
> > *u_skb,
> > + struct genl_info *info)
> > +{
> > +   struct tbt_nhi_ctxt *nhi_ctxt;
> > +   struct sk_buff *skb;
> > +   bool msg_too_long;
> > +   int res = -ENODEV;
> > +   u32 *msg_head;
> > +
> > +   if (!info || !info->userhdr)
> > +   return -EINVAL;
> > +
> > +   skb = genlmsg_new(NLMSG_ALIGN(nhi_genl_family.hdrsize) +
> > + nla_total_size(sizeof(DRV_VERSION)) +
> > + nla_total_size(sizeof(nhi_ctxt->nvm_ver_offset)) +
> > + nla_total_size(sizeof(nhi_ctxt->num_ports)) +
> > + nla_total_size(sizeof(nhi_ctxt->dma_port)) +
> > + nla_total_size(0),/* nhi_ctxt->support_full_e2e */
> > + 

Re: Cloning the linux documentation repo (is there an http/https mirror ?)

[Jani Nikula]

On Sat, 17 Dec 2016, Kevin Wilson  wrote:
> Hi,
> I am trying to clone the linux documentation git repo, according to
> the URL in the Linux kernel Maintainers file,  by:
>
> git clone git://git.lwn.net/linux.git
> and I am getting an error as I am behind a company proxy.
>
> With other repos, which are hosted also via http, I can clone
> successfully when I am behind the same company proxy; for example,
> for the net-next git repo, the following command succeeds:
> git clone http://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> Is there any http/https based mirror for linux documentation git repo ?

Search for git proxying using netcat, socat or corkscrew; there are
plenty of solutions.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
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] Documentation/sphinx more portable version check

[Jani Nikula]

On Mon, 19 Dec 2016, Mauro Carvalho Chehab  wrote:
> It could be interesting to print some error message if someone tries 
> to build with an older version or if the version can't be detected,
> asking the user to upgrade Sphinx.

This will do it.

BR,
Jani.

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 1ac958c0333d..b763271e2035 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -29,7 +29,7 @@ from load_config import loadConfig
 # -- General configuration 
 
 # If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
+needs_sphinx = '1.2'
 
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom



-- 
Jani Nikula, Intel Open Source Technology Center
--
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] Documentation/sphinx more portable version check

[Mauro Carvalho Chehab]

Em Mon, 19 Dec 2016 11:44:57 +0200
Jani Nikula  escreveu:

> On Fri, 16 Dec 2016, Robert Bragg  wrote:
> > The sphinx.__version__ string doesn't always include a patch version and
> > so the previous tuple decomposition failed with to few elements.
> >
> > Since I hit the case with no patch version ("1.5"), I guess it's
> > possible a major release might elide the minor version.
> >
> > Although there's an alternative sphinx.version_info tuple that looks
> > generally preferable to splitting the __version__ string, this opts to
> > continue using __version__ which existed prior to v 1.2.
> 
> IMO just go for sphinx.version_info for simplicity and per [1], and
> ignore Sphinx v1.1 and older. Even Debian stable has v1.2.

Agreed. I suspect that everything older than 1.2 won't work, anyway.

It could be interesting to print some error message if someone tries 
to build with an older version or if the version can't be detected,
asking the user to upgrade Sphinx.

Btw, I ended by installing a local instance on my Debian server with
a 1.4.x version, as it produces less warnings and produce a better
output. So, I don't test for a while if the current document builds
with 1.2.


Thanks,
Mauro
--
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] Documentation/sphinx more portable version check

[Jani Nikula]

On Fri, 16 Dec 2016, Robert Bragg  wrote:
> The sphinx.__version__ string doesn't always include a patch version and
> so the previous tuple decomposition failed with to few elements.
>
> Since I hit the case with no patch version ("1.5"), I guess it's
> possible a major release might elide the minor version.
>
> Although there's an alternative sphinx.version_info tuple that looks
> generally preferable to splitting the __version__ string, this opts to
> continue using __version__ which existed prior to v 1.2.

IMO just go for sphinx.version_info for simplicity and per [1], and
ignore Sphinx v1.1 and older. Even Debian stable has v1.2.

BR,
Jani.

[1] 
http://www.sphinx-doc.org/en/1.5.1/extdev/appapi.html#checking-the-sphinx-version


>
> Signed-off-by: Robert Bragg 
> Cc: Mauro Carvalho Chehab 
> Cc: Jonathan Corbet 
> ---
>  Documentation/conf.py   | 4 +++-
>  Documentation/sphinx/cdomain.py | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 1ac958c..6ecbd7b 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -17,7 +17,9 @@ import os
>  import sphinx
>  
>  # Get Sphinx version
> -major, minor, patch = map(int, sphinx.__version__.split("."))
> +# Note: sphinx.version_info only exists >= 1.2, and __version__ may not
> +# include patch version (unknown if minor may be elided too)
> +(major, minor, patch) = list(map(int, (sphinx.__version__ + 
> ".0.0").split(".")))[:3]
>  
>  
>  # If extensions (or modules to document with autodoc) are in another 
> directory,
> diff --git a/Documentation/sphinx/cdomain.py b/Documentation/sphinx/cdomain.py
> index df0419c..7ffcebd 100644
> --- a/Documentation/sphinx/cdomain.py
> +++ b/Documentation/sphinx/cdomain.py
> @@ -44,7 +44,9 @@ from sphinx.domains.c import CDomain as Base_CDomain
>  __version__  = '1.0'
>  
>  # Get Sphinx version
> -major, minor, patch = map(int, sphinx.__version__.split("."))
> +# Note: sphinx.version_info only exists >= 1.2, and __version__ may not
> +# include patch version (unknown if minor may be elided too)
> +(major, minor, patch) = list(map(int, (sphinx.__version__ + 
> ".0.0").split(".")))[:3]
>  
>  def setup(app):

-- 
Jani Nikula, Intel Open Source Technology Center
--
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