Re: [net-next v2] ipv6: sr: Add documentation for seg_flowlabel sysctl

[David Miller]

From: Ahmed Abdelsalam 
Date: Fri, 27 Apr 2018 17:51:48 +0200

> This patch adds a documentation for seg_flowlabel sysctl into
> Documentation/networking/ip-sysctl.txt
> 
> Signed-off-by: Ahmed Abdelsalam 

Applied, thank you.
--
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] filter.txt: update 'tools/net/' to 'tools/bpf/'

[David Miller]

From: Wang Sheng-Hui 
Date: Sun, 15 Apr 2018 16:07:12 +0800

> The tools are located at tootls/bpf/ instead of tools/net/.
> Update the filter.txt doc.
> 
> Signed-off-by: Wang Sheng-Hui 

Applied, thank you.
--
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 v12 10/11] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Fri, 23 Feb 2018 11:51:25 -0700

> On 02/22/2018 07:50 PM, kbuild test robot wrote:
>> Hi Khalid,
>> I love your patch! Yet something to improve:
>> [auto build test ERROR on sparc-next/master]
>> [also build test ERROR on v4.16-rc2]
>> [cannot apply to next-20180222]
>> [if your patch is applied to the wrong git tree, please drop us a note
>> to help improve the system]
>> url:
>> https://github.com/0day-ci/linux/commits/Khalid-Aziz/Application-Data-Integrity-feature-introduced-by-SPARC-M7/20180223-071725
>> base:
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next.git
>> master
>> config: sparc64-allyesconfig (attached as .config)
>> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>>  wget
>>  
>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>  -O ~/bin/make.cross
>>  chmod +x ~/bin/make.cross
>>  # save the attached .config to linux build tree
>>  make.cross ARCH=sparc64
>> All error/warnings (new ones prefixed by >>):
> 
> Hi Dave,
> 
> Including linux/sched.h in arch/sparc/include/asm/mmu_context.h should
> eliminate these build warnings. My gcc version 6.2.1 does not report
> these errors. Build bot is using 7.2.0.
> 
> I can add a patch 12 to add the include, revise patch 10 or you can
> add the include in your tree. Let me know how you would prefer to
> resolve this.

You need to update patch #10 so that your patch series is fully
bisectable.

Thank you.
--
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: [PATCHv2 0/5] pktgen: Behavior flags fixes

[David Miller]

From: Dmitry Safonov <d...@arista.com>
Date: Thu, 18 Jan 2018 18:31:32 +

> v2:
>   o fixed a nitpick from David Miller
> 
> There are a bunch of fixes/cleanups/Documentations.
> Diffstat says for itself, regardless added docs and missed flag
> parameters.

Series applied to net-next, thank you.
--
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] docs-rst: networking: wire up msg_zerocopy

[David Miller]

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 

Applied.
--
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] docs-rst: networking: wire up msg_zerocopy

[David Miller]

From: Jonathan Corbet <cor...@lwn.net>
Date: Tue, 9 Jan 2018 09:55:27 -0700

> On Tue, 09 Jan 2018 11:50:49 -0500 (EST)
> David Miller <da...@davemloft.net> wrote:
> 
>> From: Mike Rapoport <r...@linux.vnet.ibm.com>
>> 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 <r...@linux.vnet.ibm.com>  
>> 
>> 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.

Oh then I'll take it.

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

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

[David Miller]

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.
--
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 net] ipv6: fix net.ipv6.conf.all interface DAD handlers

[David Miller]

From: Matteo Croce 
Date: Tue, 12 Sep 2017 17:46:37 +0200

> Currently, writing into
> net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
> Fix handling of these flags by:
> 
> - using the maximum of global and per-interface values for the
>   accept_dad flag. That is, if at least one of the two values is
>   non-zero, enable DAD on the interface. If at least one value is
>   set to 2, enable DAD and disable IPv6 operation on the interface if
>   MAC-based link-local address was found
> 
> - using the logical OR of global and per-interface values for the
>   optimistic_dad flag. If at least one of them is set to one, optimistic
>   duplicate address detection (RFC 4429) is enabled on the interface
> 
> - using the logical OR of global and per-interface values for the
>   use_optimistic flag. If at least one of them is set to one,
>   optimistic addresses won't be marked as deprecated during source address
>   selection on the interface.
> 
> While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
> drop inline, and let the compiler decide.
> 
> Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses 
> useful candidates")
> Signed-off-by: Matteo Croce 

Applied, thank you.
--
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: link in networking docs

[David Miller]

From: Pavel Machek 
Date: Sat, 16 Sep 2017 16:28:02 +0200

> Fix link in filter.txt.
> 
> Acked-by: Pavel Machek 

Applied, thanks Pavel.
--
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 net] ipv6: fix net.ipv6.conf.all interface DAD handlers

[David Miller]

From: Matteo Croce 
Date: Tue, 12 Sep 2017 17:46:37 +0200

> Currently, writing into
> net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
> Fix handling of these flags by:
> 
> - using the maximum of global and per-interface values for the
>   accept_dad flag. That is, if at least one of the two values is
>   non-zero, enable DAD on the interface. If at least one value is
>   set to 2, enable DAD and disable IPv6 operation on the interface if
>   MAC-based link-local address was found
> 
> - using the logical OR of global and per-interface values for the
>   optimistic_dad flag. If at least one of them is set to one, optimistic
>   duplicate address detection (RFC 4429) is enabled on the interface
> 
> - using the logical OR of global and per-interface values for the
>   use_optimistic flag. If at least one of them is set to one,
>   optimistic addresses won't be marked as deprecated during source address
>   selection on the interface.
> 
> While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
> drop inline, and let the compiler decide.
> 
> Fixes: 7fd2561e4ebd ("net: ipv6: Add a sysctl to make optimistic addresses 
> useful candidates")
> Signed-off-by: Matteo Croce 

Erik, please review.
--
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 v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Pavel Machek 
Date: Mon, 4 Sep 2017 18:25:30 +0200

> Will gcc be able to compile code that uses these automatically? That
> does not sound easy to me. Can libc automatically use this in malloc()
> to prevent accessing freed data when buffers are overrun?
> 
> Is this for benefit of JITs?

Anything that can control mappings and the virtual address used to
access memory can use ADI.

malloc() is of course one such case.  It can map memory with ADI
enabled, and return buffer addresses to malloc() callers with the
proper virtual address bits set to satisfy the ADI key checks.

And by induction anything using malloc() for it's memory allocation
gets ADI protection as well.
--
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 v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 17:23:37 -0600

> That is an interesting idea. This would enable TSTATE_MCDE on all
> threads of a process as soon as one thread enables it. If we consider
> the case where the parent creates a shared memory area and spawns a
> bunch of threads. These threads access the shared memory without ADI
> enabled. Now one of the threads decides to enable ADI on the shared
> memory. As soon as it does that, we enable TSTATE_MCDE across all
> threads and since threads are all using the same TTE for the shared
> memory, every thread becomes subject to ADI verification. If one of
> the other threads was in the middle of accessing the shared memory, it
> will get a sigsegv. If we did not enable TSTATE_MCDE across all
> threads, it could have continued execution without fault. In other
> words, updating TSTATE_MCDE across all threads will eliminate the
> option of running some threads with ADI enabled and some not while
> accessing the same shared memory. This could be necessary at least for
> short periods of time before threads can communicate with each other
> and all switch to accessing shared memory with ADI enabled using same
> tag. Does that sound like a valid use case or am I off in the weeds
> here?

A threaded application needs to synchronize and properly orchestrate
access to shared memory.

When a change is made to a mappping, in this case setting ADI
attributes, it's being done for the address space not the thread.

And the address space is shared amongst threads.

Therefore ADI is not really a per-thread property but rather
a per-address-space property.
--
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 v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 30 Aug 2017 16:27:54 -0600

>>> +#define arch_calc_vm_prot_bits(prot, pkey)
>>> sparc_calc_vm_prot_bits(prot)
>>> +static inline unsigned long sparc_calc_vm_prot_bits(unsigned long
>>> prot)
>>> +{
>>> +   if (prot & PROT_ADI) {
>>> +   struct pt_regs *regs;
>>> +
>>> +   if (!current->mm->context.adi) {
>>> +   regs = task_pt_regs(current);
>>> +   regs->tstate |= TSTATE_MCDE;
>>> +   current->mm->context.adi = true;
>> If a process is multi-threaded when it enables ADI on some memory for
>> the first time, TSTATE_MCDE will only be set for the calling thread
>> and it will not be possible to enable it for the other threads.
>> One possible way to handle this is to enable TSTATE_MCDE for all user
>> threads when they are initialized if adi_capable() returns true.
>> 
> 
> Or set TSTATE_MCDE unconditionally here by removing "if
> (!current->mm->context.adi)"?

I think you have to make "ADI enabled" a property of the mm_struct.

Then you can broadcast to mm->cpu_vm_mask a per-cpu interrupt that
updates regs->tstate of a thread using 'mm' is currently executing.

And in the context switch code you set TSTATE_MCDE if it's not set
already.

That should cover all threaded case.
--
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] switchdev: documentation: minor typo fixes

[David Miller]

From: Chris Packham 
Date: Mon, 21 Aug 2017 08:52:54 +1200

> Two typos in switchdev.txt
> 
> Signed-off-by: Chris Packham 

Applied.
--
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 v7 9/9] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed,  9 Aug 2017 15:26:02 -0600

> +void adi_restore_tags(struct mm_struct *mm, struct vm_area_struct *vma,
> +   unsigned long addr, pte_t pte)
> +{
 ...
> + tag = tag_start(addr, tag_desc);
> + paddr = pte_val(pte) & _PAGE_PADDR_4V;
> + for (tmp = paddr; tmp < (paddr+PAGE_SIZE); tmp += adi_blksize()) {
> + version1 = (*tag) >> 4;
> + version2 = (*tag) & 0x0f;
> + *tag++ = 0;
> + asm volatile("stxa %0, [%1] %2\n\t"
> + :
> + : "r" (version1), "r" (tmp),
> +   "i" (ASI_MCD_REAL));
> + tmp += adi_blksize();
> + asm volatile("stxa %0, [%1] %2\n\t"
> + :
> + : "r" (version2), "r" (tmp),
> +   "i" (ASI_MCD_REAL));
> + }
> + asm volatile("membar #Sync\n\t");

You do a membar here.

> + for (i = pfrom; i < (pfrom + PAGE_SIZE); i += adi_blksize()) {
> + asm volatile("ldxa [%1] %2, %0\n\t"
> + : "=r" (adi_tag)
> + :  "r" (i), "i" (ASI_MCD_REAL));
> + asm volatile("stxa %0, [%1] %2\n\t"
> + :
> + : "r" (adi_tag), "r" (pto),
> +   "i" (ASI_MCD_REAL));

But not here.

Is this OK?  I suspect you need to add a membar this this second piece
of MCD tag storing code.
--
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 net-next v3 0/3] netvsc: transparent VF support

[David Miller]

From: Stephen Hemminger 
Date: Tue,  1 Aug 2017 19:58:52 -0700

> This patch set changes how SR-IOV Virtual Function devices are managed
> in the Hyper-V network driver. This version is rebased onto current net-next.
 ...

Series applied, thanks Stephen.
--
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 net-next v2 0/3] netvsc: transparent SR-IOV VF support

[David Miller]

From: Stephen Hemminger 
Date: Mon, 31 Jul 2017 16:45:21 -0700

> This patch set changes how SR-IOV Virtual Function devices are managed
> in the Hyper-V network driver. It was part of earlier bundle, but
> is now updated.

I think you need to do a rebase.  I just merged net into net-next and
this created some conflicts.
--
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 net-next v2 00/10] netvsc fixes and new features

[David Miller]

From: Stephen Hemminger 
Date: Wed, 26 Jul 2017 16:40:19 -0700

> The next group of patches aims to reduce the driver memory footprint
> by reducing the size of the per-device receive and send buffers, and
> the per-channel receive completion queue.

Sorry Stephen, I have to draw the line with those module parameters.

Search out alternate mechanism which can work at run time, such as
using devlink or similar.

Don't tell me it's "impossible" or "hard", simply do.

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

Re: [PATCH net-next v2 01/10] net: dsa: lan9303: Fixed MDIO interface

[David Miller]

From: Andrew Lunn 
Date: Wed, 26 Jul 2017 19:52:24 +0200

>> > So I really want to group the patches into only a few series in order
>> > to not spend months on the process.
> 
> I strongly agree with Vivien here. Good patches get accepted in about
> 3 days. You should expect feedback within a day or two. That allows
> you to have fast cycle times for getting patches in.

+1

Small simple patches will get everything in 10 times fast than if
you clump everything together into larger, harder to review ones.
--
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 00/13] net: dsa: lan9303: unicast offload, fdb,mdb,STP

[David Miller]

From: Egil Hjelmeland 
Date: Mon, 24 Jul 2017 16:47:51 +0200

> This is my first patches submitted to the kernel, so I am looking
> forward to comments.

Please clean up how the dates are handled in your submission.

They are all over the place, over a period of 3 days.

Instead, they should be consequentive, near the moment the patch is
submitted.

We manage patches in patchwork, and there the patches are ordered in
my queue based upon date.  So instead of a nice clean order of changes
showing up recently at the top of my queue, your's got mixed in deep
near the bottom of the queue, intermixed with other unrelated changes.

This seriously makes things more difficult for me.

The best thing to do is to apply your series into a fresh tree (which
you pretty much _MUST_ do anyways, to make sure your changes apply,
build and work properly in my GIT tree, right?) and then extract those
commits for your patch series emails.

You must also say in your subject line which of my two GIT networking
trees ('net' or 'net-next') your changes are targetting.  If you don't
know, you need to figure that out before submitting.

I'm not applying this series until you fix your process up.

Thank you.
--
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 net 0/2] minor net kernel-doc fixes

[David Miller]

From: Stephen Hemminger 
Date: Wed, 12 Jul 2017 09:29:05 -0700

> Fix a couple of small errors in kernel-doc for networking

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

Re: [PATCH v2] Documentation: fix wrong example command

[David Miller]

From: Matteo Croce 
Date: Fri, 30 Jun 2017 18:21:47 +0200

> In the IPVLAN documentation there is an example command line where the
> master and slave interface names are inverted.
> Fix the command line and also add the optional `name' keyword to better
> describe what the command is doing.
> 
> v2: added commit message
> 
> Signed-off-by: Matteo Croce 

Applied, thank you.
--
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 v1] net: phy: Delete unused function phy_ethtool_gset

[David Miller]

From: Yuval Shaia 
Date: Mon,  5 Jun 2017 10:18:40 +0300

> It's unused, so remove it.
> 
> Signed-off-by: Yuval Shaia 
> ---
> v0 -> v1:
>   * Add commit message
>   * Update Documentation/networking/phy.txt
>   * Modify commit header message

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

Re: [PATCH] net: Update TCP congestion control documentation

[David Miller]

From: Anmol Sarma 
Date: Sat,  3 Jun 2017 17:40:54 +0530

> Update tcp.txt to fix mandatory congestion control ops and default
> CCA selection. Also, fix comment in tcp.h for undo_cwnd.
> 
> Signed-off-by: Anmol Sarma 

Applied, thank you.
--
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 dead URLs to ftp.kernel.org

[David Miller]

From: Jonathan Corbet 
Date: Sun, 26 Mar 2017 13:11:15 -0600

> On Sun, 26 Mar 2017 23:25:50 +0900
> SeongJae Park  wrote:
> 
> CC += davem
> 
> If nobody objects, I'll just take this through the docs tree.

No objection from me:

Acked-by: David S. Miller 
--
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] cdrom: Make device operations read-only

[David Miller]

From: Kees Cook 
Date: Mon, 13 Feb 2017 16:25:26 -0800

> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 9cbd217bc0c9..ab9232e1e16f 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1166,7 +1166,7 @@ void ide_cdrom_update_speed(ide_drive_t *drive, u8 *buf)
>CDC_CD_RW | CDC_DVD | CDC_DVD_R | CDC_DVD_RAM | CDC_GENERIC_PACKET | \
>CDC_MO_DRIVE | CDC_MRW | CDC_MRW_W | CDC_RAM)
>  
> -static struct cdrom_device_ops ide_cdrom_dops = {
> +static const struct cdrom_device_ops ide_cdrom_dops = {
>   .open   = ide_cdrom_open_real,
>   .release= ide_cdrom_release_real,
>   .drive_status   = ide_cdrom_drive_status,

Acked-by: David S. Miller 
--
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 v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Tue, 31 Jan 2017 16:38:49 -0700

> Thanks for the feedback. This is very helpful. I checked and it indeed
> can cost 50+ cycles even on M7 processor for PSTATE accesses.

Consider how many bytes can be copied in 50+ cycles :-)

>> On etrap, you change ESTATE_PSTATE{1,2} to have the MCDE bit enabled.
>> Then the kernel always runs with ADI enabled.
> 
> Running the kernel with PSTATE.mcde=1 can possibly be problematic as
> we had discussed earlier in this thread where keeping PSTATE.mcde
> enabled might mean kernel having to keep track of which pages still
> have tags set on them or flush tags on every page on free. I will go
> through the code again to see if it PSTATE.mcde can be turned on in
> kernel all the time, which might be the case if we can ensure kernel
> accesses pages with TTE.mcd cleared.

If we can clear the tags properly on page release when the page was
used for ADI, it can work.

One way would be to track the state in the page struct somehow, and
in arch_alloc_page() clear the tags if necessary.
--
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 v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 25 Jan 2017 12:57:16 -0700

> +static inline void enable_adi(void)
> +{
 ...
> + __asm__ __volatile__(
> + "rdpr %%pstate, %%g1\n\t"
> + "or %%g1, %0, %%g1\n\t"
> + "wrpr %%g1, %%g0, %%pstate\n\t"
> + ".word 0x83438000\n\t"  /* rd %mcdper, %g1 */
> + ".word 0xaf91\n\t"  /* wrpr  %g0, %g1, %pmcdper */
> + :
> + : "i" (PSTATE_MCDE)
> + : "g1");
> +}

This is _crazy_ expensive.

This is 4 privileged register operations, every single one incurs a full
pipline flush and virtual cpu thread yield.

And we do this around _every_ single userspace access from the kernel
when the thread has ADI enabled.

I think if the kernel manages the ADI metadata properly, you can get rid
of all of this.

On etrap, you change ESTATE_PSTATE{1,2} to have the MCDE bit enabled.
Then the kernel always runs with ADI enabled.

Furthermore, since the %mcdper register should be set to whatever the
current task has asked for, you should be able to avoid touching it
as well assuming that traps do not change %mcdper's value.

Then you don't need to do anything special during userspace accesses
which seems to be the way this was designed to be used.
--
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 v5 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Rob Gardner 
Date: Wed, 25 Jan 2017 15:00:42 -0700

> Same comment here, and the various other places that employ this same
> code construct.

Please do not quote an entire huge patch just to comment on a small
part of it.

Quote only the minimum necessary context in order to provide your feedback.

Thank you.
--
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 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz <khalid.a...@oracle.com>
Date: Tue, 17 Jan 2017 12:32:46 -0700

> On 01/16/2017 09:39 PM, David Miller wrote:
>> From: Khalid Aziz <khalid.a...@oracle.com>
>> Date: Wed, 11 Jan 2017 09:12:54 -0700
>>
>>> +   __asm__ __volatile__(
>>> +   ".word 0xa1438000\n\t"  /* rd  %mcdper, %l0 */
>>
>> Just use "rd %%asr14, %0" this way you don't have to play all of these
>> fixed register games which kill the code generated by gcc.  If you
>> forcefully clobber a windowed register like %l0 it means the function
>> being emitted can never be a leaf function, tail calls are no longer
>> allowed, etc.
> 
> Hi David,
> 
> "rd %%asr14, %0" should work but does not due to bugs in assembler -
> <https://sourceware.org/ml/binutils/2016-03/msg00302.html>, and
> <https://sourceware.org/ml/binutils/2016-03/msg00303.html>. These bugs
> were fixed in binutils 2.27 but older assemblers will cause kernel
> build to fail. Using byte coded equivalent is the safest option.

Fair enough.

Then please at least use %g1 or another usable global register to
avoid at least some of the problems I mentioned.
--
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 0/4] Application Data Integrity feature introduced by SPARC M7

[David Miller]

From: Dave Hansen 
Date: Wed, 11 Jan 2017 08:33:30 -0800

> Is there a cost in the hardware associated with doing this "ADI
> checking"?  For instance, instead of having this new mprotect()
> interface, why not just always set TTE.mcd on all PTEs?

If we did this then for every page mapped into userspace we'd have
to explicitly set all of the tags to zero, otherwise we'd get TAG
mismatch exceptions.

That would be like clearing the every mapped anonymous page twice, or
worse.
--
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 0/4] Application Data Integrity feature introduced by SPARC M7

[David Miller]

From: Dave Hansen 
Date: Wed, 11 Jan 2017 10:13:54 -0800

> For memory shared by two different processes, do they have to agree on
> what the tags are, or can they differ?

Whoever allocates the memory (does the mmap()+mprotect() or whatever),
decides on the tag.  They set it, and this determines which virtual
address is valid to access that mapping.

It's like kmalloc() returns pointers with some weird bits set in the
upper bits of the address.  Behind the scenes kmalloc() sets the
TAG bits appropriately.

It doesn't, in that sense, matter where in the non-tagged virtual
address space the memory is mapped.  All that matters is that, for
a given page, the TAG bits in the virtual address used for loads
and stores to that mapping are set properly.

I think the fundamental thing being missed is that the TAG bits in the
virtual address are not interpreted by the TLB.  They are chopped off
before virtual address translation occurs.

The TAG bits of the virtual address serve only to indicate what ADI
value the load or store thinks is valid to use for access to that
piece of memory.

Or something like that... :-)
--
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 4/4] sparc64: Add support for ADI (Application Data Integrity)

[David Miller]

From: Khalid Aziz 
Date: Wed, 11 Jan 2017 09:12:54 -0700

> + __asm__ __volatile__(
> + ".word 0xa1438000\n\t"  /* rd  %mcdper, %l0 */

Just use "rd %%asr14, %0" this way you don't have to play all of these
fixed register games which kill the code generated by gcc.  If you
forcefully clobber a windowed register like %l0 it means the function
being emitted can never be a leaf function, tail calls are no longer
allowed, etc.

> + ".word 0x9d800011\n\t"  /* wr  %g0, %l1, %mcdper */

Likewise use "wr %%g0, %0, %%asr14"

> + ".word 0xaf91\n\t"  /* wrpr  %g0, %g1, %pmcdper */

Hmmm, which %asr encodes %pmcdper?

> diff --git a/arch/sparc/kernel/mdesc.c b/arch/sparc/kernel/mdesc.c
> index 8a6982d..68b03bf 100644
> --- a/arch/sparc/kernel/mdesc.c
> +++ b/arch/sparc/kernel/mdesc.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Unlike the OBP device tree, the machine description is a full-on
>   * DAG.  An arbitrary number of ARCs are possible from one
> @@ -1104,5 +1105,8 @@ void __init sun4v_mdesc_init(void)
>  
>   cur_mdesc = hp;
>  
> +#ifdef CONFIG_SPARC64

mdesc.c is only built on sparc64, this ifdef is superfluous.

> +/* Update the state of MCDPER register in current task's mm context before
> + * dup so the dup'd task will inherit flags in this register correctly.
> + * Current task may have updated flags since it started running.
> + */
> +int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
> +{
> + if (adi_capable() && src->mm) {
> + register unsigned long tmp_mcdper;
> +
> + __asm__ __volatile__(
> + ".word 0x83438000\n\t"  /* rd %mcdper, %g1 */
> + "mov %%g1, %0\n\t"
> + : "=r" (tmp_mcdper)
> + :
> + : "g1");
> + src->mm->context.mcdper = tmp_mcdper;

I don't like the idea of duplicating 'mm' state using the task struct
copy.  Why do not the MM handling interfaces handle this properly?

Maybe it means you've abstracted the ADI register handling in the
wrong place.  Maybe it's a thread property which is "pushed" from
the MM context.
--
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] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Dave Hansen 
Date: Fri, 6 Jan 2017 08:55:03 -0800

> Actually, that reminds me...  How does your code interface with ksm?  Or
> is there no interaction needed since you're always working on virtual
> addresses?

This reminds me, I consider this feature potentially extremely useful for
kernel debugging.  So I would like to make sure we don't implement anything
in a way which would preclude that in the long term.
--
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] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Khalid Aziz 
Date: Fri, 6 Jan 2017 09:22:13 -0700

> On 01/06/2017 08:36 AM, Dave Hansen wrote:
>> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>>> I agree with you on simplicity first. Subpage granularity is complex,
>>> but the architecture allows for subpage granularity. Maybe the right
>>> approach is to support this at page granularity first for swappable
>>> pages and then expand to subpage granularity in a subsequent patch?
>>> Pages locked in memory can already use subpage granularity with my
>>> patch.
>>
>> What do you mean by "locked in memory"?  mlock()'d memory can still be
>> migrated around and still requires "swap" ptes, for instance.
> 
> You are right. Page migration can invalidate subpage granularity even
> for locked pages. Is it possible to use cpusets to keep a task and its
> memory locked on a single node? Just wondering if there are limited
> cases where subpage granularity could work without supporting subpage
> granularity for tags in swap. It still sounds like the right thing to
> do is to get a reliable implementation in place with page size
> granularity and then add the complexity of subpage granularity.

It sounds to me, in all of this, that if the kernel manages the
movement of the pages, it thus must handle making sure the tags move
around with that page as well.

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

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

[David Miller]

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

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

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

Re: [PATCH net-next] Documentation/networking: update git urls to use https over http

[David Miller]

From: Alexander Alemayhu 
Date: Thu, 13 Oct 2016 17:09:51 +0200

> This fixes the following errors when trying to clone the urls:
> 
> Cloning into 'net'...
> fatal: repository 
> 'http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/' not found
> Cloning into 'net-next'...
> fatal: repository 
> 'http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/' not found
> Cloning into 'linux'...
> fatal: repository 
> 'http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/' not found
> Cloning into 'stable-queue'...
> fatal: repository 
> 'http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/' not 
> found
> 
> Signed-off-by: Alexander Alemayhu 

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

Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[David Miller]

From: Amir Levy 
Date: Wed, 28 Sep 2016 17:44:22 +0300

> This driver enables Thunderbolt Networking on non-Apple platforms
> running Linux.

Greg, any idea where this should get merged once fully vetted?  I can
take it through the net-next tree, but I'm fine with another more
appropriate tree taking it as well.

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

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

[David Miller]

From: SF Markus Elfring 
Date: Sun, 4 Sep 2016 09:20:55 +0200

> I guess that I will stumble on more software improvement opportunities
> you find harder to become comfortable with.

Improvement is a matter of opinion.  So your statement assumes that
your changes are an improvement, and everyone in this thread clearly
disagrees with that.

This is why everything you are doing here is so irritating.

It's not because I find improvements "uncomfortable", but rather it's
because your changes are not seen as improvements in the first place.
--
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: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

[David Miller]

From: SF Markus Elfring 
Date: Sun, 4 Sep 2016 08:50:20 +0200

>>> NAK, just noise.
>> 
>> And frankly I hate that leading space.
> 
> Would you like to comment the recent update of the document "CodingStyle" any 
> more?
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51

You seem to lack understanding of the difference between absolute
requirements and "advice".

As Sparc maintainer I can choose to not take this "advice", and I so
choose to do so.

If you want to be completely ignored by me, then keep arguing the way
you are right now.
--
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 v5 6/8] thunderbolt: Networking transmit and receive

[David Miller]

From: "Levy, Amir (Jer)" 
Date: Sun, 31 Jul 2016 10:15:52 +

> The network stack thinks it is Ethernet, it might not accept Runt
> frames, so the driver pads the frame in receive.

The network stack doesn't care about this at all.  It's wasted effort
on your part.

--
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 01/23] all: syscall wrappers: add documentation

[David Miller]

From: Arnd Bergmann <a...@arndb.de>
Date: Wed, 25 May 2016 23:01:06 +0200

> On Wednesday, May 25, 2016 1:50:39 PM CEST David Miller wrote:
>> From: Arnd Bergmann <a...@arndb.de>
>> Date: Wed, 25 May 2016 22:47:33 +0200
>> 
>> > If we use the normal calling conventions, we could remove these overrides
>> > along with the respective special-case handling in glibc. None of them
>> > look particularly performance-sensitive, but I could be wrong there.
>> 
>> You could set the lowest bit in the system call entry pointer to indicate
>> the upper-half clears should be elided.
> 
> Right, but that would introduce an extra conditional branch in the syscall
> hotpath, and likely eliminate the gains from passing the loff_t arguments
> in a single register instead of a pair.

Ok, then, how much are you really gaining from avoiding a 'shift' and
an 'or' to build the full 64-bit value?  3 cycles?  Maybe 4?

And the executing the wrappers, those have a non-trivial cost too.

Cost wise, this seems like it all cancels out in the end, but what
do I know?



--
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 01/23] all: syscall wrappers: add documentation

[David Miller]

From: Arnd Bergmann 
Date: Wed, 25 May 2016 22:47:33 +0200

> If we use the normal calling conventions, we could remove these overrides
> along with the respective special-case handling in glibc. None of them
> look particularly performance-sensitive, but I could be wrong there.

You could set the lowest bit in the system call entry pointer to indicate
the upper-half clears should be elided.
--
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 01/23] all: syscall wrappers: add documentation

[David Miller]

From: Yury Norov <yno...@caviumnetworks.com>
Date: Wed, 25 May 2016 23:03:27 +0300

> On Wed, May 25, 2016 at 12:30:17PM -0700, David Miller wrote:
>> From: Yury Norov <yno...@caviumnetworks.com>
>> Date: Tue, 24 May 2016 03:04:30 +0300
>> 
>> > +To clear that top halves, automatic wrappers are introduced. They clear 
>> > all
>> > +required registers before passing control to regular syscall handler.
>> 
>> Why have one of these for every single compat system call, rather than
>> simply clearing the top half of all of these registers unconditionally
>> in the 32-bit system call trap before the system call is invoked?
>> 
>> That's what we do on sparc64.
>> 
>> And with that, you only need wrappers for the case where there needs
>> to be proper sign extention of a 32-bit signed argument.
> 
> It was discussed as one of possible solutions. The downside of it is
> that we cannot pass 64-bit types (like off_t) in single register.

Wrappers can be added for the cases where you'd like to do that.

> The other downside is that we clear top halves for every single
> syscall, and it looks excessive. So, from spark64 and s390 approaches
> we choosed second.

It's like 4 cpu cycles even on crappy sparc64 cpus which only dual
issue. :)

And that's a pretty low cost for the benefits if you ask me.
--
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 0043/1529] Fix typo

[David Miller]

I'm not applying a ton of patches that all have the same Subject line.

How can anyone looking at the GIT shortlog figure out what might
be different amongst any of these 1529 patches?

You must prefix your Subject line with the subsystem or area that your
patch is changing, followed by a colon character, then a space
character.

For this specific patch an appropriate subject line would be
"[PATCH 0043/1529] hisax: Fix typo."
--
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] [linux-next] Doc: networking: Fix typo in dsa

[David Miller]

From: Masanari Iida 
Date: Sat,  9 Apr 2016 00:00:25 +0900

> This patch fix typos in Documentation/networking/dsa.
> 
> Signed-off-by: Masanari Iida 

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

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Khalid Aziz <khalid.a...@oracle.com>
Date: Tue, 8 Mar 2016 13:16:11 -0700

> On 03/08/2016 12:57 PM, David Miller wrote:
>> From: Khalid Aziz <khalid.a...@oracle.com>
>> Date: Mon, 7 Mar 2016 14:06:43 -0700
>>
>>> Good questions. Isn't set of valid VAs already constrained by VA_BITS
>>> (set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
>>> are already not using the top 4 bits. Please correct me if I am wrong.
>>
>> Another limiting constraint is the number of address bits coverable by
>> the 4-level page tables we use.  And this is sign extended so we have
>> a top-half and a bottom-half with a "hole" in the center of the VA
>> space.
>>
>> I want some clarification on the top bits during ADI accesses.
>>
>> If ADI is enabled, then the top bits of the virtual address are
>> intepreted as tag bits.  Once "verified" with the ADI settings, what
>> happense to these tag bits?  Are they dropped from the virtual address
>> before being passed down the TLB et al. for translations?
> 
> Bits 63-60 (tag bits) are dropped from the virtual address before
> being passed down the TLB for translation when PSTATE.mcde = 1.

Ok and you said that values 15 and 0 are special.

I'm just wondering if this means you can't really use ADI mappings in
the top half of the 64-bit address space.  If the bits are dropped, they
will be zero, but they need to be all 1's for the top-half of the VA
space since it's sign extended.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Andy Lutomirski 
Date: Mon, 7 Mar 2016 10:53:23 -0800

> x86 has an upcoming feature called protection keys.  A page of virtual
> memory has a protection key, which is a number from 0 through 16.  The
> master copy is in the PTE, i.e. page table entry, which is a
> software-managed data structure in memory and is exactly the thing
> that Linux calls "pte".  The processor can cache that value in the TLB
> (translation lookaside buffer), which is a hardware cache that caches
> PTEs.  On access to a page of virtual memory, the processor does a
> certain calculation involving a new register called PKRU and the
> protection key and may deny access.

ADI is similar, except the "keys" (or "tags") are stored externally
rather than in the PTEs.  A bit in the PTE is used to enable tag match
checking.

The tags live in an external table, which is populated by ASI store
instructions.  The location of the table is implementation specific,
it could be hypervisor or CPU managed, but if stored in memory it is
to a region of memory accessible only to the hypervisor at best.

Khalid, maybe you should share notes with the folks working on x86
protection keys.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Andy Lutomirski 
Date: Mon, 7 Mar 2016 10:49:57 -0800

> What data structure or structures changes when this stxa instruction happens?

An internal table, maintained by the CPU and/or hypervisor, and if in physical
addresses then in a region which is only accessible by the hypervisor.

The table is not accessible by the kernel at all via loads or stores.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Khalid Aziz 
Date: Mon, 7 Mar 2016 11:24:54 -0700

> Tags can be cleared by user by setting tag to 0. Tags are
> automatically cleared by the hardware when the mapping for a virtual
> address is removed from TSB (which is why swappable pages are a
> problem), so kernel does not have to do it as part of clean up.

You might be able to crib some bits for the Tag in the swp_entry_t, it's
64-bit and you can therefore steal bits from the offset field.

That way you'll have the ADI tag in the page tables, ready to re-install
at swapin time.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Dave Hansen 
Date: Mon, 7 Mar 2016 09:35:57 -0800

> On 03/02/2016 12:39 PM, Khalid Aziz wrote:
>> +long enable_sparc_adi(unsigned long addr, unsigned long len)
>> +{
>> +unsigned long end, pagemask;
>> +int error;
>> +struct vm_area_struct *vma, *vma2;
>> +struct mm_struct *mm;
>> +
>> +if (!ADI_CAPABLE())
>> +return -EINVAL;
> ...
> 
> This whole thing with the VMA splitting and so forth looks pretty darn
> arch-independent.  Are you sure you need that much arch-specific code
> for it, or can you share more of the generic VMA management code?

This is exactly what I have suggested to him, and he has agreed to pursue.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Khalid Aziz 
Date: Mon, 7 Mar 2016 08:07:53 -0700

> I can remove CONFIG_SPARC_ADI. It does mean this code will be built
> into 32-bit kernels as well but it will be inactive code.

The code should be built only into obj-$(CONFIG_SPARC64) just like the
rest of the 64-bit specific code.  I don't know why in the world you
would build it into the 32-bit kernel.
--
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 2/2] isdn: i4l: move active-isdn drivers to staging

[David Miller]

From: Arnd Bergmann 
Date: Wed,  2 Mar 2016 20:06:46 +0100

> The icn, act2000 and pcbit drivers are all for very old hardware,
> and it is highly unlikely that anyone is actually still using them
> on modern kernels, if at all.
> 
> All three drivers apparently are for hardware that predates PCI
> being the common connector, as they are ISA-only and active
> PCI ISDN cards were widely available in the 1990s.
> 
> Looking through the git logs, it I cannot find any indication of a
> patch to any of these drivers that has been tested on real hardware,
> only cleanups or global API changes.
> 
> Signed-off-by: Arnd Bergmann 

Greg, can you please take these two patches?

Thanks!

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