Re: [PATCH 2/7] docs: generic-counter.rst: fix broken references for ABI file

2019-07-27 Thread Jonathan Cameron
On Fri, 26 Jul 2019 08:47:22 -0300
Mauro Carvalho Chehab  wrote:

> There are two references to the generic counter ABI, with was added
> on a separate patch. Both point to a non-existing file.
> 
> Fix them.
> 
> Fixes: ea2b23b89579 ("counter: Documentation: Add Generic Counter sysfs 
> documentation")
> Fixes: 09e7d4ed8991 ("docs: Add Generic Counter interface documentation")
> Signed-off-by: Mauro Carvalho Chehab 

Applied to the fixes-togreg branch of iio.git.

Thanks,

Jonathan

> ---
>  Documentation/driver-api/generic-counter.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/driver-api/generic-counter.rst 
> b/Documentation/driver-api/generic-counter.rst
> index 0c161b1a3be6..8382f01a53e3 100644
> --- a/Documentation/driver-api/generic-counter.rst
> +++ b/Documentation/driver-api/generic-counter.rst
> @@ -233,7 +233,7 @@ Userspace Interface
>  Several sysfs attributes are generated by the Generic Counter interface,
>  and reside under the /sys/bus/counter/devices/counterX directory, where
>  counterX refers to the respective counter device. Please see
> -Documentation/ABI/testing/sys-bus-counter-generic-sysfs for detailed
> +Documentation/ABI/testing/sysfs-bus-counter for detailed
>  information on each Generic Counter interface sysfs attribute.
>  
>  Through these sysfs attributes, programs and scripts may interact with
> @@ -325,7 +325,7 @@ sysfs attributes, where Y is the unique ID of the 
> respective Count:
>  
>  For a more detailed breakdown of the available Generic Counter interface
>  sysfs attributes, please refer to the
> -Documentation/ABI/testing/sys-bus-counter file.
> +Documentation/ABI/testing/sysfs-bus-counter file.
>  
>  The Signals and Counts associated with the Counter device are registered
>  to the system as well by the counter_register function. The



Re: [PATCH] tools: memory-model: add it to the Documentation body

2019-07-27 Thread Joel Fernandes
On Fri, Jul 26, 2019 at 04:01:37PM -0300, Mauro Carvalho Chehab wrote:
> The books at tools/memory-model/Documentation are very well
> formatted. Congrats to the ones that wrote them!
> 
> The manual conversion to ReST is really trivial:
> 
>   - Add document titles;
>   - change the bullets on some lists;
>   - mark code blocks.

Thanks so much, some feedback:
> 
> Signed-off-by: Mauro Carvalho Chehab 

(1)
I could not find the table of contents appear in the HTML output for this.
Basically this list in the beginning doesn't render:
  1. INTRODUCTION
  2. BACKGROUND
  3. A SIMPLE EXAMPLE
  4. A SELECTION OF MEMORY MODELS
  5. ORDERING AND CYCLES
 
Could we add a proper TOC with sections? My motivation for ReST here would be
to make the sections jumpable since it is a large document.

Also could we make the different sections appear as a tree in the left
sidebar?

(2) Arguably several function names in the document HTML output should appear
in monospace fonting and/or referring to the documentation for real function
names, but these can be fixed as we go, I guess.

(3) Things like smp_load_acquire() and spin_lock() should probably refer to
the documentation for those elsewhere..

(4) I would argue that every occurence of
A ->(some dependency) B should be replaced with fixed size font in the HTML
results.

Arguably it is better IMO if the whole document is fixed size font in the
HTML output because so many things need to be fixed size, but that my just be
my opinion.

thanks,

 - Joel


> ---
>  Documentation/core-api/refcount-vs-atomic.rst |   2 +-
>  Documentation/index.rst   |   1 +
>  Documentation/tools/memory-model  |   1 +
>  .../memory-model/Documentation/cheatsheet.rst |  36 +
>  .../memory-model/Documentation/cheatsheet.txt |  30 
>  .../{explanation.txt => explanation.rst}  | 151 ++
>  tools/memory-model/Documentation/index.rst|  20 +++
>  .../{recipes.txt => recipes.rst}  |  41 ++---
>  .../{references.txt => references.rst}|  46 +++---
>  tools/memory-model/README |  10 +-
>  10 files changed, 192 insertions(+), 146 deletions(-)
>  create mode 12 Documentation/tools/memory-model
>  create mode 100644 tools/memory-model/Documentation/cheatsheet.rst
>  delete mode 100644 tools/memory-model/Documentation/cheatsheet.txt
>  rename tools/memory-model/Documentation/{explanation.txt => explanation.rst} 
> (97%)
>  create mode 100644 tools/memory-model/Documentation/index.rst
>  rename tools/memory-model/Documentation/{recipes.txt => recipes.rst} (96%)
>  rename tools/memory-model/Documentation/{references.txt => references.rst} 
> (71%)
 


Re: [PATCH] tools: memory-model: add it to the Documentation body

2019-07-27 Thread Mauro Carvalho Chehab
Em Sat, 27 Jul 2019 14:14:53 +
Joel Fernandes  escreveu:

> On Fri, Jul 26, 2019 at 04:01:37PM -0300, Mauro Carvalho Chehab wrote:
> > The books at tools/memory-model/Documentation are very well
> > formatted. Congrats to the ones that wrote them!
> > 
> > The manual conversion to ReST is really trivial:
> > 
> > - Add document titles;
> > - change the bullets on some lists;
> > - mark code blocks.  
> 
> Thanks so much, some feedback:
> > 
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> (1)
> I could not find the table of contents appear in the HTML output for this.
> Basically this list in the beginning doesn't render:
>   1. INTRODUCTION
>   2. BACKGROUND
>   3. A SIMPLE EXAMPLE
>   4. A SELECTION OF MEMORY MODELS
>   5. ORDERING AND CYCLES

Yes. It is written as a comment, like:

.. foo  This is a comment block

   Everything on this block

   won't be parsed.

So it won't be parsed, but having a TOC like this isn't need, as
Sphinx generates it automatically via "toctree" markup. 

> Could we add a proper TOC with sections? My motivation for ReST here would be
> to make the sections jumpable since it is a large document.

Just change the toctree depth at index.rst to 2 and you'll see an index
produced by Sphinx with both levels 1 (doc name) and level 2 (chapters):

.. toctree::
   :maxdepth: 2

> Also could we make the different sections appear as a tree in the left
> sidebar?

The sidebar follows the maxdepth too.

> 
> (2) Arguably several function names in the document HTML output should appear
> in monospace fonting and/or referring to the documentation for real function
> names, but these can be fixed as we go, I guess.

If you want monospaced fonts, just use: ``monospaced_symbol_foo`` within
any paragraph, or place the monospaced data inside a code-block:

::

This will be monospaced.

> 
> (3) Things like smp_load_acquire() and spin_lock() should probably refer to
> the documentation for those elsewhere..

Jon added an automarkup extension on Kernel 5.2. So, all functions that
are defined elsewhere will automatically generate an hyperlink. For that to
happen, you need to add the kernel-doc markup at the *.h or *.c file where
the function is declared and use the kernel-doc markup somewhere within the
Kernel Documentation/.

> 
> (4) I would argue that every occurence of
> A ->(some dependency) B should be replaced with fixed size font in the HTML
> results.

Just place those with ``A -> (some dependency)``. This will make them use
a fixed size font.

> Arguably it is better IMO if the whole document is fixed size font in the
> HTML output because so many things need to be fixed size, but that my just be
> my opinion.

Just my 2 cents here, but having the entire document using a fixed size
font makes it more boring to read. Having just the symbols with a fixed size
is a common convention used on technical books, and helps to make easier
to identify the symbols while reading the docs.

That's said, Sphinx doesn't have any tag to switch the font for the entire
document. All it can be done is to define a CSS and apply it for the
doc - or to place everything within a code-block, with will suppress all
markup tags, including cross-references for functions.

The problem with CSS is that you need to write both an html CSS file
and add LaTeX macros associated to this "CSS style" (technically, LaTeX
doesn't have a CSS concept, but Sphinx emulates it).

Thanks,
Mauro


[PATCH v2] docs: admin-guide: Adjust title underline length

2019-07-27 Thread Fabio Estevam
The following warning is seen when building 'make htmldocs':

Documentation/admin-guide/sysctl/kernel.rst:397: WARNING: Title underline too 
short.

Fix it by adjusting the title underline length appropriately.

Fixes: 725d8c9a2cc5 ("hung_task: allow printing warnings every check interval")
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Added Fixes tag
- Sent to Andrew as the commit that generates the warning comes
from his tree (Jonathan)

 Documentation/admin-guide/sysctl/kernel.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst 
b/Documentation/admin-guide/sysctl/kernel.rst
index 2e36620ec1e4..8af424dd0364 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -394,7 +394,7 @@ This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
 
 
 hung_task_interval_warnings:
-===
+
 
 The same as hung_task_warnings, but set the number of interval
 warnings to be issued about detected hung tasks during check
-- 
2.17.1



Re: [f2fs-dev] [PATCH v4 1/3] fs: Reserve flag for casefolding

2019-07-27 Thread Chao Yu
On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
> In preparation for including the casefold feature within f2fs, elevate
> the EXT4_CASEFOLD_FL flag to FS_CASEFOLD_FL.
> 
> Signed-off-by: Daniel Rosenberg 

Reviewed-by: Chao Yu 

Thanks,


Re: [f2fs-dev] [PATCH v4 2/3] f2fs: include charset encoding information in the superblock

2019-07-27 Thread Chao Yu
On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
> Add charset encoding to f2fs to support casefolding. It is modeled after
> the same feature introduced in commit c83ad55eaa91 ("ext4: include charset
> encoding information in the superblock")
> 
> Currently this is not compatible with encryption, similar to the current
> ext4 imlpementation. This will change in the future.
> 
> From the ext4 patch:
> """
> The s_encoding field stores a magic number indicating the encoding
> format and version used globally by file and directory names in the
> filesystem.  The s_encoding_flags defines policies for using the charset
> encoding, like how to handle invalid sequences.  The magic number is
> mapped to the exact charset table, but the mapping is specific to ext4.
> Since we don't have any commitment to support old encodings, the only
> encoding I am supporting right now is utf8-12.1.0.
> 
> The current implementation prevents the user from enabling encoding and
> per-directory encryption on the same filesystem at the same time.  The
> incompatibility between these features lies in how we do efficient
> directory searches when we cannot be sure the encryption of the user
> provided fname will match the actual hash stored in the disk without
> decrypting every directory entry, because of normalization cases.  My
> quickest solution is to simply block the concurrent use of these
> features for now, and enable it later, once we have a better solution.
> """
> 
> Signed-off-by: Daniel Rosenberg 

Reviewed-by: Chao Yu 

Thanks,


Re: [f2fs-dev] [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups

2019-07-27 Thread Chao Yu
On 2019-7-24 7:05, Daniel Rosenberg via Linux-f2fs-devel wrote:
>  /* Flags that are appropriate for regular files (all but dir-specific ones). 
> */
>  #define F2FS_REG_FLMASK  (~(F2FS_DIRSYNC_FL | 
> F2FS_PROJINHERIT_FL))

We missed to add F2FS_CASEFOLD_FL here to exclude it in F2FS_REG_FLMASK.

> @@ -1660,7 +1660,16 @@ static int f2fs_setflags_common(struct inode *inode, 
> u32 iflags, u32 mask)
>   return -EPERM;
>  
>   oldflags = fi->i_flags;
> + if ((iflags ^ oldflags) & F2FS_CASEFOLD_FL) {
> + if (!f2fs_sb_has_casefold(F2FS_I_SB(inode)))
> + return -EOPNOTSUPP;
> +
> + if (!S_ISDIR(inode->i_mode))
> + return -ENOTDIR;
>  
> + if (!f2fs_empty_dir(inode))
> + return -ENOTEMPTY;
> + }

I applied the patches based on last Jaegeuk's dev branch, it seems we needs to
adjust above code a bit. Otherwise it looks good to me.

BTW, it looks the patchset works fine with generic/556 testcase.

Thanks,


Re: general protection fault in tls_trim_both_msgs

2019-07-27 Thread syzbot

syzbot has bisected this bug to:

commit 32857cf57f920cdc03b5095f08febec94cf9c36b
Author: John Fastabend 
Date:   Fri Jul 19 17:29:18 2019 +

net/tls: fix transition through disconnect with close

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=155064d860
start commit:   fde50b96 Add linux-next specific files for 20190726
git tree:   linux-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=175064d860
console output: https://syzkaller.appspot.com/x/log.txt?x=135064d860
kernel config:  https://syzkaller.appspot.com/x/.config?x=4b58274564b354c1
dashboard link: https://syzkaller.appspot.com/bug?extid=0e0fedcad708d12d3032
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=14779d6460
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1587c84260

Reported-by: syzbot+0e0fedcad708d12d3...@syzkaller.appspotmail.com
Fixes: 32857cf57f92 ("net/tls: fix transition through disconnect with  
close")


For information about bisection process see: https://goo.gl/tpsmEJ#bisection