Re: [PATCH] Documentation: Add HOWTO Korean translation into BPF and XDP Reference Guide.

[Jonathan Corbet]

On Wed, 26 Sep 2018 18:11:42 +0900
Chang-an Song  wrote:

> >  - The original document has a copyright assertion but no associated
> >license.  Do we know what the license is?  I assume it's something
> >that is free and GPL-compatible, but that would be good to know for
> >sure.  
> 
> 3. I asked to main author Daniel that apache 2.0 license for this document.

That is a bit of a problem, since Apache v2 is not compatible with GPLv2.
If the license of the document cannot be changed, I don't think we can
accept it into the kernel tree.

Thanks,

jon

Re: [PATCH] Documentation: Add HOWTO Korean translation into BPF and XDP Reference Guide.

[Jonathan Corbet]

On Fri, 21 Sep 2018 13:22:38 +0900
Changan Song  wrote:

> Signed-off-by: Changan Song 
> ---
>  Documentation/translations/ko_KR/bpf-xdp.txt | 3511 ++
>  1 file changed, 3511 insertions(+)
>  create mode 100644 Documentation/translations/ko_KR/bpf-xdp.txt

I can't judge the quality of the translation, of course, but I do have a
couple of related questions:

 - Since you're adding a new document, could you please format it as RST
   and add it to index.rst with the other Korean translations?  The
   original will have been in RST, so this should be relatively easy to
   do.

 - The original document has a copyright assertion but no associated
   license.  Do we know what the license is?  I assume it's something
   that is free and GPL-compatible, but that would be good to know for
   sure.

Thanks for doing this work,

jon

Re: [PATCH net-next 0/2] docs: net: Convert netdev-FAQ to RST

[Jonathan Corbet]

On Wed, 25 Jul 2018 13:28:10 +1000
"Tobin C. Harding"  wrote:

> Since I've already botched it can I ask for guidance here.  The problem
> is updating the links means making changes that will cause merge
> conflicts if they go through net-dev tree (since most references are in
> Documentation/*.rst).  But we can't go through docs tree either since
> that could lead to merge conflicts later as well.

Merge conflicts are a way of life in Documentation/ - everybody messes
with it.  They are usually pretty easy to resolve.

I only see a handful of references to netdev-FAQ.txt in the tree; I would
suggest just making the change and being done with it.  There shouldn't be
any need to do a more complicated dance than that.

And to answer your other question, yes of course it's fine (and expected)
for this to go through Dave's tree.

Thanks,

jon

Re: [PATCH net-next 4/5] tcp: implement mmap() for zero copy receive

[Jonathan Corbet]

On Thu, 19 Apr 2018 18:01:32 -0700
Eric Dumazet  wrote:

> We can keep mmap() nice interface, granted we can add one hook like in 
> following patch.
> 
> David, do you think such patch would be acceptable by lkml and mm/fs 
> maintainers ?
> 
> Alternative would be implementing an ioctl() or getsockopt() operation,
> but it seems less natural...

So I have little standing here, but what the heck, not letting that bother
me has earned me a living for the last 20 years or so...:)

I think you should consider switching over to an interface where you
mmap() the region once, and use ioctl() to move the data into that region,
for a couple of reasons beyond the locking issues you've already found:

 - The "mmap() consumes data" semantics are a bit ... strange, IMO.
   That's not what mmap() normally does.  People expect ioctl() to do
   magic things, instead.

 - I would expect it to be a tiny bit faster, since you wouldn't be doing
   the VMA setup and teardown each time.

Thanks,

jon

[PATCH net-next] MAINTAINERS: Direct networking documentation changes to netdev

[Jonathan Corbet]

Networking docs changes go through the networking tree, so patch the
MAINTAINERS file to direct authors to the right place.

Signed-off-by: Jonathan Corbet <cor...@lwn.net>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..bf4be491d4d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9765,6 +9765,7 @@ F:include/uapi/linux/net_namespace.h
 F: tools/testing/selftests/net/
 F: lib/net_utils.c
 F: lib/random32.c
+F: Documentation/networking/
 
 NETWORKING [IPSEC]
 M: Steffen Klassert <steffen.klass...@secunet.com>
-- 
2.14.3

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Jonathan Corbet]

On Thu, 29 Mar 2018 05:01:32 -0400
Richard Guy Briggs  wrote:

> > A little detail, but still...  
> 
> I am understanding that you would prefer more context (as opposed to
> operational detail) in the description, laying out the use case for this
> patch(set)?

No, sorry, "a little detail" was referring to my comment.  The use case,
I believe, has been well described.

Thanks,

jon

Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

[Jonathan Corbet]

On Fri, 16 Mar 2018 05:00:28 -0400
Richard Guy Briggs  wrote:

> Implement the proc fs write to set the audit container ID of a process,
> emitting an AUDIT_CONTAINER record to document the event.

A little detail, but still...

> +static int audit_set_containerid_perm(struct task_struct *task, u64 
> containerid)
> +{
> + struct task_struct *parent;
> + u64 pcontainerid, ccontainerid;
> +
> + /* Don't allow to set our own containerid */
> + if (current == task)
> + return -EPERM;
> + /* Don't allow the containerid to be unset */
> + if (!cid_valid(containerid))
> + return -EINVAL;

I went looking for cid_valid(), but it turns out you don't add it until
patch 5.  That, I expect, will not be good for bisectability (or patch
review).

Thanks,

jon

Re: [PATCH] docs-rst: networking: wire up msg_zerocopy

[Jonathan Corbet]

On Tue, 09 Jan 2018 11:50:49 -0500 (EST)
David Miller  wrote:

> From: Mike Rapoport 
> Date: Mon,  8 Jan 2018 08:50:17 +0200
> 
> > Fix the following 'make htmldocs' complaint:
> > 
> > Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't 
> > included in any toctree.
> > 
> > Signed-off-by: Mike Rapoport   
> 
> Does someone else want to take this?
> 
> Otherwise I can.

I can certainly take it (or the equivalent patch posted by Tobin a few
days earlier) through the docs tree.  I've been holding off, though,
under the impression that you'd rather take networking docs patches
yourself.  Either is fine.  Unless you say you've grabbed it, I'll do so
in the near future.

Thanks,

jon

Re: [PATCH 02/18] Documentation: document nospec helpers

[Jonathan Corbet]

On Mon, 8 Jan 2018 17:09:59 +
Mark Rutland  wrote:

> > I have just a couple of overall comments.
> > 
> >  - It would be nice if the document were done in RST and placed in the
> >core-API manual, perhaps using kerneldoc comments for the macros
> >themselves.  It's already 99.9% RST now, so the changes required would
> >be minimal.  
> 
> Is there any quickstart guide to RST that you can recommend?

http://docutils.sourceforge.net/docs/user/rst/quickref.html works
reasonably well.  We have some info in the kernel documentation as well,
see http://static.lwn.net/kerneldoc/doc-guide/sphinx.html

Thanks,

jon

Re: [PATCH 02/18] Documentation: document nospec helpers

[Jonathan Corbet]

On Fri, 05 Jan 2018 17:10:03 -0800
Dan Williams  wrote:

> Document the rationale and usage of the new nospec*() helpers.

I have just a couple of overall comments.

 - It would be nice if the document were done in RST and placed in the
   core-API manual, perhaps using kerneldoc comments for the macros
   themselves.  It's already 99.9% RST now, so the changes required would
   be minimal.

 - More importantly: is there any way at all to give guidance to
   developers wondering *when* they should use these primitives?  I think
   it would be easy to create a situation where they don't get used where
   they are really needed; meanwhile, there may well be a flood of
   "helpful" patches adding them where they make no sense at all.

Thanks,

jon

Re: [PATCH v7 1/5] add infrastructure for tagging functions as error injectable

[Jonathan Corbet]

On Wed, 22 Nov 2017 16:23:30 -0500
Josef Bacik  wrote:

> From: Josef Bacik 
> 
> Using BPF we can override kprob'ed functions and return arbitrary
> values.  Obviously this can be a bit unsafe, so make this feature opt-in
> for functions.  Simply tag a function with KPROBE_ERROR_INJECT_SYMBOL in
> order to give BPF access to that function for error injection purposes.
> 
> Signed-off-by: Josef Bacik 
> Acked-by: Ingo Molnar 
> ---
>  arch/x86/include/asm/asm.h|   6 ++
>  include/asm-generic/vmlinux.lds.h |  10 +++
>  include/linux/bpf.h   |  11 +++
>  include/linux/kprobes.h   |   1 +
>  include/linux/module.h|   5 ++
>  kernel/kprobes.c  | 163 
> ++
>  kernel/module.c   |   6 +-
>  7 files changed, 201 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> index b0dc91f4bedc..340f4cc43255 100644
> --- a/arch/x86/include/asm/asm.h
> +++ b/arch/x86/include/asm/asm.h
> @@ -85,6 +85,12 @@
>   _ASM_PTR (entry);   \
>   .popsection
>  
> +# define _ASM_KPROBE_ERROR_INJECT(entry) \
> + .pushsection "_kprobe_error_inject_list","aw" ; \
> + _ASM_ALIGN ;\
> + _ASM_PTR (entry);   \
> + .popseciton

So this stuff is not my area of greatest expertise, but I do have to wonder
how ".popseciton" can work ... ?

Thanks,

jon

Re: [PATCH] New Chapter on CodingStyle .

[Jonathan Corbet]

On Sat, 12 Aug 2017 14:23:18 +0300
Corcodel Marian  wrote:

> ---
>  Documentation/CodingStyle | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> index 9a70ddd..864dd8b 100644
> --- a/Documentation/CodingStyle
> +++ b/Documentation/CodingStyle
> @@ -922,6 +922,34 @@ expression used.  For instance:
>   ...
>   #endif /* CONFIG_SOMETHING */
>  
> + Chapter 20: Put values on initialisers without exception
> +
> +When declaring variables on functions must put values:

Thanks for sending a patch for the kernel's documentation.
Unfortunately, I can't accept this patch for a couple of reasons:

- Kernel patches must include a changelog describing *why* the change is
  being made and a proper signoff line.  See
  Documentation/process/submitting-patches.rst for details.

- The coding style document is there to describe the community's
  standards for kernel code.  It is *not* a mechanism for imposing new
  standards.  If you really think that the kernel community should adopt
  this rule, you will need to argue for it on the mailing lists.  I will
  say, though, that I do not expect that this effort would be successful.

Can I make a suggestion?  If you have found kernel functions with bugs
related to use of uninitialized variables, please submit fixes for those
specific bugs, along with a clear description of how the bug happens and
what its effects are.

Thanks,

jon

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

[Jonathan Corbet]

On Thu, 01 Jun 2017 09:05:07 +0800
Jia-Ju Bai  wrote:

> I admit my patches are not well tested, and they may not well fix the bugs.
> I am looking forward to opinions and suggestions :)

May I politely suggest that sending out untested locking changes is a
dangerous thing to do?  You really should not be changing the locking in a
piece of kernel code without understanding very well what the lock is
protecting and being able to say why your changes are safe.  Without that,
the risk of introducing subtle bugs is very high.

It looks like you have written a useful tool that could help us to make
the kernel more robust.  If you are interested in my suggestion, I would
recommend that you post the sleep-in-atomic scenarios that you are
finding, but refrain from "fixing" them in any case where you cannot offer
a strong explanation of why your fix is correct.

Thanks for working to find bugs in the kernel!

jon

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

[Jonathan Corbet]

On Tue, 7 Feb 2017 21:51:49 +0100
Jesper Dangaard Brouer  wrote:

> I sounds like Daniel (see other email) have bigger plans for what
> Documentation/BPF/ should contain.  E.g. consolidating
> Documentation/networking/filter.txt which covers the cBPF/eBPF internals.
> If that is the case (and I like the idea), then it goes beyond a
> "userspace-guide".  And perhaps "BPF" is a "book" of its own?

One of the real problems with the kernel's documentation is that there is
really almost no thought given to who the audience is.  We have docs for
kernel developers, for system admins, for user-space developers, etc., and
it's all mixed up into one big jumble.

An objective of mine in launching into this whole project is to try to fix
that, so that people can readily find the documentation they need.  So I
don't think a single top-level directory, with a mix of user-space API
info and "internals", is the right direction to go.  The internals docs
should, IMO, go elsewhere, probably in the core-api manual.

See what I'm getting at here?

> And it seems Daniel is proposing capital-letters BPF for the directory
> name "Documentation/BPF/"?  Any opinions on that? (I'm neutral)

I think we should paint it green; otherwise I'm not too concerned about
this particular point...:)

Thanks,

jon

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

[Jonathan Corbet]

On Tue, 7 Feb 2017 17:09:08 +0100
Jesper Dangaard Brouer <bro...@redhat.com> wrote:

> > > Question: What kernel tree should this go into???
> > > 
> > > If going through Jonathan Corbet, will it appear sooner here???
> > >  https://www.kernel.org/doc/html/latest/  
> 
> What about this question?  Or let me ask in another way, what tree is
> https://www.kernel.org/doc/html/latest/ based on?

I believe it's generated from the current -rc.  If this stuff goes into
4.11, it should show up there next week.

> Yes, I was also wondering hard where to put it... and a book for
> user-space developer documentation would likely be the right place, but
> it was not there, as you mention ;-) 
> 
> I'm fine with moving it later under another "book". Linking to it as
> HTML would still be the same right? 
> (https://www.kernel.org/doc/html/latest/bpf/index.html)
> And is the Documentation/bpf/ directory the correct place?

Moving it would change the URL, of course.  If we want to avoid that, we
should try to come up with the proper placement from the outset.  And we
would want to move it; I really want to clean up the mess that is the
top-level directory.

How about if it goes into Documentation/userspace-guide/bpf ?  The
intermediate directory could just be empty for now, I'll put the book
structure into place later on.  Then the URL for the BPF guide itself
wouldn't change.

jon

Re: [net-next PATCH 0/4] Documenting eBPF - extended Berkeley Packet Filter

[Jonathan Corbet]

On Tue, 07 Feb 2017 15:30:11 +0100
Jesper Dangaard Brouer <bro...@redhat.com> wrote:

> Question: What kernel tree should this go into???
> 
> If going through Jonathan Corbet, will it appear sooner here???
>  https://www.kernel.org/doc/html/latest/
> If it will not appear sooner that way, then it's likely best to keep
> it in sync with the tree that takes eBPF code changes.

I've developed a fairly strong preference for carrying patches touching
index.rst; otherwise I spend a lot of time explaining merge conflicts to
Linus.

If the consensus is that this is ready to go, I expect I can squeeze it in
for 4.11.  I'm not too worried about regressions...:)

I haven't actually built it yet, but from a first look it seems like an
awfully good start.  The one thing that comes to mind is that I'm likely
to want to move it at some point.  I'd really like to start a separate
book for user-space developer documentation, and this would certainly
belong there.  That book doesn't exist yet, though, so I can't quite blame
you, hard as I might try, for not putting this document there.

Thanks,

jon

Re: [PATCH v9 7/8] thunderbolt: Networking doc

[Jonathan Corbet]

On Wed, 9 Nov 2016 17:00:02 +0100
Greg KH  wrote:

> >  Documentation/00-INDEX   |   2 +
> >  Documentation/thunderbolt/networking.txt | 132 
> > +++  
> 
> Note, new files should be in .rst format, and live in the new
> subdirectory for them (somewhere in Documentation, don't know off the
> top of my head...)

This one's almost in RST already, happily.

We haven't really figured out a hierarchy for device-specific docs like
this yet; I should get on that, I guess.

I do believe that we should separate documents for end users from those
aimed at kernel developers; those are two very different audiences
looking for different kinds of information.

Thanks,

jon

Re: [PATCH v2 0/6] Move runnable code (tests) from Documentation to selftests

[Jonathan Corbet]

On Tue, 13 Sep 2016 14:18:39 -0600
Shuah Khan <shua...@osg.samsung.com> wrote:

> Move runnable code (tests) from Documentation to selftests and update
> Makefiles to work under selftests.

This all seems good to me.

Acked-by: Jonathan Corbet <cor...@lwn.net>

jon

Re: [PATCH 0/9] Move runnable code (tests) from Documentation to selftests

[Jonathan Corbet]

On Fri,  9 Sep 2016 16:22:41 -0600
Shuah Khan  wrote:

> Move runnable code (tests) from Documentation to selftests and update
> Makefiles to work under selftests.
> 
> Jon Corbet and I discussed this in an email thread and as per that
> discussion, this patch series moves all the tests that are under the
> Documentation directory to selftests. There is more runnable code in
> the form of examples and utils and that is going to be another patch
> series. I moved just the tests and left the documentation files as is.

I'm fine with the idea, but it looks like a couple of tweaks are needed,
in particular to avoid leaving behind dangling references in
Documentation/Makefile that cause build errors.

I think the individual patches probably need a wider CC list as well.
I'd use the get_maintainer script (or git) to see who has taken an
interest in the individual tests and make sure they are aware of the
move.

Thanks,

jon

Re: possible patch

[Jonathan Corbet]

On Wed, 10 Feb 2016 19:49:11 -0500
Justin Keller  wrote:

> I am new to submitting patches, so sorry if I am doing it wrong. My idea was
> to change line 147 in drivers/isdn/pcbit/callbacks.c from
> if (cbdata->data.setup.CallingPN == NULL) {
> 
> to
> 
> if (cbdata->data.setup.CallingPN == NULL ||
> sizeof(cbdata->data.setup.CallingPN)>sizeof(ictl.parm.setup.phone) {

If you want to patch the kernel, the best way to describe what you want to
do is to ... send a patch.

Before you do so, though:

- Please read the available documentation, including SubmittingPatches and
  development-process/*

- Prepare a proper changelog saying *why* you want to make this change.
  You are trying to change the ISDN subsystem, which is pretty static
  these days; what current problem are you running into that makes you
  think this change needs to be applied to the kernel?

Thanks,

jon

Re: [PATCH RESEND] net: Documentation: Fix default value tcp_limit_output_bytes

[Jonathan Corbet]

On Wed, 11 Nov 2015 11:57:24 -0500 (EST)
David Miller  wrote:

> > I left this last time because Dave usually likes to pick up networking
> > docs patches himself.  This wasn't sent to netdev, though, so that's
> > unlikely to happen.  I've gone ahead and applied it, since it seems
> > clearly correct.  
> 
> I already took this into my tree as per:
> 
>   http://marc.info/?l=linux-netdev=144708947814679=2
> 
> and patchwork entry:
> 
>   http://patchwork.ozlabs.org/patch/541786/
> 
> and since Linus pulled my tree in earlier today it's now in
> his tree as well.

Ah...I'm so behind the times...then I won't take it here after all.

Thanks,

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

Re: [PATCH RESEND] net: Documentation: Fix default value tcp_limit_output_bytes

[Jonathan Corbet]

On Mon, 9 Nov 2015 14:58:49 +0100
Niklas Cassel  wrote:

> Commit c39c4c6abb89 ("tcp: double default TSQ output bytes limit")
> updated default value for tcp_limit_output_bytes

I left this last time because Dave usually likes to pick up networking
docs patches himself.  This wasn't sent to netdev, though, so that's
unlikely to happen.  I've gone ahead and applied it, since it seems
clearly correct.

Thanks,

jon

> Signed-off-by: Niklas Cassel 
> ---
>  Documentation/networking/ip-sysctl.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/networking/ip-sysctl.txt 
> b/Documentation/networking/ip-sysctl.txt
> index 05915be..2ea4c45 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -709,7 +709,7 @@ tcp_limit_output_bytes - INTEGER
>   typical pfifo_fast qdiscs.
>   tcp_limit_output_bytes limits the number of bytes on qdisc
>   or device to reduce artificial RTT/cwnd and reduce bufferbloat.
> - Default: 131072
> + Default: 262144
>  
>  tcp_challenge_ack_limit - INTEGER
>   Limits number of Challenge ACK sent per second, as recommended
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: make mandocs build failure with next-20150407

[Jonathan Corbet]

On Thu, 16 Apr 2015 08:33:15 +0900
Masanari Iida standby2...@gmail.com wrote:

 On Wed, Apr 8, 2015 at 7:41 AM, Jim Davis jim.ep...@gmail.com wrote:
DOCPROC Documentation/DocBook/80211.xml
  Error(.//include/net/mac80211.h:329): Cannot parse enum!
  Error(.//include/net/mac80211.h:367): Cannot parse enum!
  Warning(.//include/net/mac80211.h:381): No description found for
  parameter 'type'
  --  
 
 This error start to appear on Linus's tree.
 make xmldocs stops after this error.
 Then run it again,  make xmldocs process rest of the files.
 
 Add TO:  netdev and patch authors for reporting the issue.

It's the result of some incomplete changes in the wireless tree; I sent a
fix to Johannes that he applied a couple of days ago.  Once that hits
mainline the problem should go away.

Thanks,

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

Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

[Jonathan Corbet]

Rusty said:

 Well, introduce an EXPORT_SYMBOL_INTERNAL().  It's a lot less code.  But 
 you'd 
 still need to show that people are having trouble knowing what APIs to use.

Might the recent discussion on the exporting of sys_open() and
sys_read() be an example here?  There would appear to be a consensus
that people should not have used those functions, but they are now
proving difficult to unexport.

Perhaps the best use of the namespace stuff might be for *future*
exports which are needed to help make the mainline kernel fully modular,
but which are not meant to be part of a more widely-used API?

jon
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html