On Mon, Jul 17, 2017 at 03:00:47PM -0600, Jonathan Corbet wrote:
> Commit 8f2e045ec878 (drm/color: un-inline drm_color_lut_extract()) moved
> the only kerneldoc comment out of include/drm/drm_color_mgmt.h, leading to
> this warning:
>
> ./include/drm/drm_color_mgmt.h:1: warning: no structured
Em Mon, 17 Jul 2017 15:26:33 -0600
Jonathan Corbet escreveu:
> On Mon, 17 Jul 2017 18:23:05 -0300
> Mauro Carvalho Chehab wrote:
>
> > Btw, I'm submitting in a few a second version of the patches with
> > add a script to check Sphinx dependencies.
>
> I figured I wasn't going to look at that
Detect if the script runs after creating the virtualenv,
printing the command line commands to enable the virtualenv.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/sphinx-pre-install | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/scripts/sphinx
Sphinx installation is not trivial, as not all versions are supported,
and it requires a lot of stuff for math, images and PDF/LaTeX output
to work.
So, add a script that checks if everything is fine, providing
distro-specific hints about what's needed for it to work.
I posted already RFC patches
On newer versions of graphviz packaging on Fedora, it is needed to
install a separate package for PDF support.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/sphinx-pre-install | 9 +
1 file changed, 9 insertions(+)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
Now that we have a script to check for Sphinx dependencies,
document it.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/doc-guide/sphinx.rst | 48 ++
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/Documentation/doc-guide/sphinx.rst
b/D
Instead of using 3 commands to install a virtualenv, use
a single one, reading the requirements from this file:
Documentation/sphinx/requirements.txt
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/sphinx/requirements.txt | 3 +++
scripts/sphinx-pre-install| 5 ++---
Solving Sphinx dependencies can be painful. Add a script to
check if everything is ok.
Tested on:
- Fedora 25 and 26;
- Ubuntu 17.04;
- OpenSuse Tumbleweed;
- Arch Linux;
- Gentoo.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/sphinx-pre-install | 517
ImageMagick actually uses librsvg for conversions when converiting
from SVG (actually, it uses rsvg-convert). That causes the build to
fail with:
WARNING: Error #1 when calling: /usr/bin/convert
/home/mchehab/docs/Documentation/media/uapi/v4l/selection.svg
/home/mchehab/docs/Documentatio
After removal of DocBook, those targets are bogus.
Reported-by: Jim Davis
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/Makefile | 10 --
Documentation/translations/zh_CN/HOWTO | 2 --
Makefile | 2 +-
3 files changed, 1 insertion
Gentoo need some USE for GraphViz and ImageMagick to have
the features required by kfigure.py.
Output that when providing instructions for Gentoo.
Signed-off-by: Mauro Carvalho Chehab
---
scripts/sphinx-pre-install | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/script
Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it is, then phys_to_virt() is used to
perform the mapping. When SME is active, the default is to add pagetable
mappings with the encryption bit set unless specifically overridden. The
resulting paget
When System Memory Encryption (SME) is enabled, the physical address
space is reduced. Adjust the x86_phys_bits value to reflect this
reduction.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/cpu/amd.c | 24 +---
1 file changed, 13 insertions(+)
On Fri, Jul 14, 2017 at 3:16 AM, Robert P. J. Day wrote:
>
> just noticed that distclean doesn't remove the generated executable
> scripts/docproc, whose responsibility is that?
It looks like that's been cleaned up now in v4.13-rc1, though
scripts/basic/{fixdep,.fixdep.cmd} are still loitering
Create a Documentation entry to describe the AMD Secure Memory
Encryption (SME) feature and add documentation for the mem_encrypt=
kernel parameter.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
Documentation/admin-guide/kernel-parameters.txt | 11
Documentation/x86/amd-memo
For processors that support PAT, set the write-protect cache mode
(_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
Acked-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/mm/pat.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/m
This patch series provides support for AMD's new Secure Memory Encryption (SME)
feature.
SME can be used to mark individual pages of memory as encrypted through the
page tables. A page of memory that is marked encrypted will be automatically
decrypted when read from DRAM and will be automatically
On Mon, 17 Jul 2017 18:23:05 -0300
Mauro Carvalho Chehab wrote:
> Btw, I'm submitting in a few a second version of the patches with
> add a script to check Sphinx dependencies.
I figured I wasn't going to look at that until you get up to v42 or so -
maybe another day or two...? :)
jon
--
To uns
The ioremap() function is intended for mapping MMIO. For RAM, the
memremap() function should be used. Convert calls from ioremap() to
memremap() when re-mapping RAM.
This will be used later by SME to control how the encryption mask is
applied to memory mappings, with certain memory locations being
Update the CPU features to include identifying and reporting on the
Secure Memory Encryption (SME) feature. SME is identified by CPUID
0x801f, but requires BIOS support to enable it (set bit 23 of
MSR_K8_SYSCFG). Only show the SME feature as available if reported by
CPUID, enabled by BIOS and
Add support to the early boot code to use Secure Memory Encryption (SME).
Since the kernel has been loaded into memory in a decrypted state, encrypt
the kernel in place and update the early pagetables with the memory
encryption mask so that new pagetable entries will use memory encryption.
The rou
Add support for Secure Memory Encryption (SME). This initial support
provides a Kconfig entry to build the SME support into the kernel and
defines the memory encryption mask that will be used in subsequent
patches to mark pages as encrypted.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendack
The boot data and command line data are present in memory in a decrypted
state and are copied early in the boot process. The early page fault
support will map these areas as encrypted, so before attempting to copy
them, add decrypted mappings so the data is accessed properly when copied.
For the
Changes to the existing page table macros will allow the SME support to
be enabled in a simple fashion with minimal changes to files that use these
macros. Since the memory encryption mask will now be part of the regular
pagetable macros, we introduce two new macros (_PAGE_TABLE_NOENC and
_KERNPG_
Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/pgtable.h | 16 +---
1 file changed, 9
Em Mon, 17 Jul 2017 13:40:51 -0600
Jonathan Corbet escreveu:
> On Fri, 14 Jul 2017 13:41:15 -0300
> Mauro Carvalho Chehab wrote:
>
> > The Sphinx build chain is fragile: any upgrades can cause it to break.
> >
> > That's what happened this week, when I upgraded my machines to
> > Fedora 26.
>
The cr3 register entry can contain the SME encryption mask that indicates
the PGD is encrypted. The encryption mask should not be used when
creating a virtual address from the cr3 register, so remove the SME
encryption mask in the read_cr3_pa() function.
During early boot SME will need to use a n
Add support to be able to either encrypt or decrypt data in place during
the early stages of booting the kernel. This does not change the memory
encryption attribute - it is used for ensuring that data present in either
an encrypted or decrypted memory area is in the proper state (for example
the i
When SME is active, pagetable entries created for EFI need to have the
encryption mask set as necessary.
When the new pagetable pages are allocated they are mapped encrypted. So,
update the efi_pgt value that will be used in cr3 to include the encryption
mask so that the PGD table can be read succ
The efi_mem_type() function currently returns a 0, which maps to
EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for
the supplied physical address. Returning EFI_RESERVED_TYPE implies that
a memmap entry exists, when it doesn't. Instead of returning 0, change
the function to re
Add a function that will return the E820 type associated with an address
range.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/e820/api.h | 2 ++
arch/x86/kernel/e820.c | 26 +++---
2 files changed, 25 insertions(+), 3 deletions(-
Boot data (such as EFI related data) is not encrypted when the system is
booted because UEFI/BIOS does not run with SME active. In order to access
this data properly it needs to be mapped decrypted.
Update early_memremap() to provide an arch specific routine to modify the
pagetable protection attr
Add a function that will determine if a supplied physical address matches
the address of an EFI table.
Reviewed-by: Matt Fleming
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
drivers/firmware/efi/efi.c | 33 +
include/linux/efi.h| 7 +
On Mon, Jul 17, 2017 at 01:44:45PM -0600, Jonathan Corbet wrote:
> On Mon, 17 Jul 2017 15:39:28 +0200
> Geert Uytterhoeven wrote:
>
> > All low-level PM/SMP code using virt_to_phys() should actually use
> > __pa_symbol() against kernel symbols. Update the documentation to move
> > away from virt
Add support for changing the memory encryption attribute for one or more
memory pages. This will be useful when we have to change the AP trampoline
area to not be encrypted. Or when we need to change the SWIOTLB area to
not be encrypted in support of devices that can't support the encryption
mask r
Persistent memory is expected to persist across reboots. The encryption
key used by SME will change across reboots which will result in corrupted
persistent memory. Persistent memory is handed out by block devices
through memory remapping functions, so be sure not to map this memory as
encrypted.
The SMP MP-table is built by UEFI and placed in memory in a decrypted
state. These tables are accessed using a mix of early_memremap(),
early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses
to use early_memremap()/early_memunmap(). This allows for proper setting
of the encryption
When Secure Memory Encryption is enabled, the trampoline area must not
be encrypted. A CPU running in real mode will not be able to decrypt
memory that has been encrypted because it will not be able to use addresses
with the memory encryption mask.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom
On Mon, 17 Jul 2017 23:13:48 +0200
Sven Eckelmann wrote:
> The usual approach is to get batman-adv related patches first in the
> batman-adv tree before submitting it to netdev. Should this approach be
> changed for documentation related patches?
No, just carry on as usual, that's fine.
Thank
Move the setting of the cpuinfo_x86.microcode field from amd_init() to
early_amd_init() so that it is available earlier in the boot process. This
avoids having to read MSR_AMD64_PATCH_LEVEL directly during early boot.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/kernel/
The IOMMU is programmed with physical addresses for the various tables
and buffers that are used to communicate between the device and the
driver. When the driver allocates this memory it is encrypted. In order
for the IOMMU to access the memory as encrypted the encryption mask needs
to be included
Add warnings to let the user know when bounce buffers are being used for
DMA when SME is active. Since the bounce buffers are not in encrypted
memory, these notifications are to allow the user to determine some
appropriate action - if necessary. Actions can range from utilizing an
IOMMU, replacin
Since video memory needs to be accessed decrypted, be sure that the
memory encryption mask is not set for the video ranges.
Reviewed-by: Borislav Petkov
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/vga.h | 14 +-
arch/x86/mm/pageattr.c | 2 ++
drivers/gpu/dr
Update the KVM support to work with SME. The VMCB has a number of fields
where physical addresses are used and these addresses must contain the
memory encryption mask in order to properly access the encrypted memory.
Also, use the memory encryption mask when creating and using the nested
page table
Add the support to encrypt the kernel in-place. This is done by creating
new page mappings for the kernel - a decrypted write-protected mapping
and an encrypted mapping. The kernel is encrypted by copying it through
a temporary buffer.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/mem_enc
Provide support so that kexec can be used to boot a kernel when SME is
enabled.
Support is needed to allocate pages for kexec without encryption. This
is needed in order to be able to reboot in the kernel in the same manner
as originally booted.
Additionally, when shutting down all of the CPUs w
When accessing memory using /dev/mem (or /dev/kmem) use the proper
encryption attributes when mapping the memory.
To insure the proper attributes are applied when reading or writing
/dev/mem, update the xlate_dev_mem_ptr() function to use memremap()
which will essentially perform the same steps of
Add a cmdline_find_option() function to look for cmdline options that
take arguments. The argument is returned in a supplied buffer and the
argument length (regardless of whether it fits in the supplied buffer)
is returned, with -1 indicating not found.
Signed-off-by: Tom Lendacky
---
arch/x86/i
Currently, native_make_p4d() is only defined when CONFIG_PGTABLE_LEVELS
is greater than 4. Create a macro that will allow for defining and using
native_make_p4d() when CONFIG_PGTABLES_LEVELS is not greater than 4.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/pgtable_types.h | 5 +
1
Xen does not currently support SME for PV guests. Clear the SME CPU
capability in order to avoid any ambiguity.
Cc:
Cc: Boris Ostrovsky
Cc: Juergen Gross
Reviewed-by: Borislav Petkov
Reviewed-by: Juergen Gross
Signed-off-by: Tom Lendacky
---
arch/x86/xen/enlighten_pv.c | 1 +
1 file changed
Add support to check if SME has been enabled and if memory encryption
should be activated (checking of command line option based on the
configuration of the default state). If memory encryption is to be
activated, then the encryption mask is set and the kernel is encrypted
"in place."
Signed-off-
On Montag, 17. Juli 2017 15:05:08 CEST Jonathan Corbet wrote:
[...]
> From a quick look-through this looks good. However, davem likes to take
> networking documentation work through his tree; may I suggest a repost
> with netdev included?
The usual approach is to get batman-adv related patches fi
Create a new function attribute, __nostackp, that can used to turn off
stack protection on a per function basis.
Signed-off-by: Tom Lendacky
---
include/linux/compiler-gcc.h | 2 ++
include/linux/compiler.h | 4
2 files changed, 6 insertions(+)
diff --git a/include/linux/compiler-gcc.h
Since DMA addresses will effectively look like 48-bit addresses when the
memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
device performing the DMA does not support 48-bits. SWIOTLB will be
initialized to create decrypted bounce buffers for use by these devices.
Signed-off-b
Add support to check if memory encryption is active in the kernel and that
it has been enabled on the AP. If memory encryption is active in the kernel
but has not been enabled on the AP, then set the memory encryption bit (bit
23) of MSR_K8_SYSCFG to enable memory encryption on that AP and allow th
Add early_memremap() support to be able to specify encrypted and
decrypted mappings with and without write-protection. The use of
write-protection is necessary when encrypting data "in place". The
write-protect attribute is considered cacheable for loads, but not
stores. This implies that the hardw
On Wed, 12 Jul 2017 13:14:48 +0200
Sven Eckelmann wrote:
> Converting the freeform text to parsable reStructuredText, allows the
> integration in the sphinx based documentation system of the kernel. It will
> therefore be accessible as hypertext under
> https://www.kernel.org/doc/html/latest/
>F
The docs build complains:
./include/linux/init.h:1: warning: no structured comments found
The problem is that the comments in question were moved to module.h in
commit 0fd972a7d91d (module: relocate module_init from init.h to
module.h). Fix basics.rst to match.
Signed-off-by: Jonathan Corbe
There are no kerneldoc comments in drivers/dma-buf/seqno-fence.c, and it
appears there never have been. Stop looking for comments there to
eliminate this warning:
./drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
Signed-off-by: Jonathan Corbet
---
Documentation/drive
Documentation/gpu/drm-mm.rst includes from include/drm/drm_syncobj.h with
:export:, but this is a header file without export directives. That
results in this warning:
./include/drm/drm_syncobj.h:1: warning: no structured comments found
...and a failure to obtain the documentation from that f
...because there are none there, and I cannot figure out what would ever
have been of interest there. This eliminates this warning:
./kernel/sys.c:1: warning: no structured comments found
from the build.
Signed-off-by: Jonathan Corbet
---
Documentation/driver-api/basics.rst | 3 ---
1 fil
Back in 2012, commit 9807f75955ea (UAPI: (Scripted) Disintegrate
arch/s390/include/asm) moved struct cmbdata (and its kerneldoc comments) to
another file, but did not update the docs to match. The result is this
warning:
./arch/s390/include/asm/cmb.h:1: warning: no structured comments found
Commit 8f2e045ec878 (drm/color: un-inline drm_color_lut_extract()) moved
the only kerneldoc comment out of include/drm/drm_color_mgmt.h, leading to
this warning:
./include/drm/drm_color_mgmt.h:1: warning: no structured comments found
That comment is already picked up in drm_color_mgmt.c, so j
The only function of interest in that file was scsi_print_status(). That
function was removed in commit 7ac7076344d9 (scsi: remove
scsi_print_status()) but the docs were not changed to match, yielding this
warning:
./drivers/scsi/constants.c:1: warning: no structured comments found
There's n
I've come to the conclusion that we really need to make the docs build
quieter. Here's a small step in that direction: getting rid of all of the
"no structured comments found" warnings. Such warnings are usually the
result of kerneldoc comments being moved elsewhere, so this took a bit of
git arc
On Fri, 7 Jul 2017 15:11:46 +0800
Zhouyi Zhou wrote:
> commit 6807c84652b0 ("x86: Enable KASLR by default") enables KASLR
> by default on x86. While KASLR will confuse gdb which resolve kernel
> symbol address from symbol table of vmlinux. We should turn off KASLR for
> kernel debugging.
Thes
On Sat, 17 Jun 2017 10:17:20 +0200
Markus Heiser wrote:
> List items with two ore more blocks are not well rendered. E.g. the gap
> between last block (l1-b2) of the first list item and the following list
> item (L2) is to small::
I've applied these two, thanks.
jon
--
To unsubscribe from this
On Mon, 17 Jul 2017 15:39:28 +0200
Geert Uytterhoeven wrote:
> All low-level PM/SMP code using virt_to_phys() should actually use
> __pa_symbol() against kernel symbols. Update the documentation to move
> away from virt_to_phys().
>
> Cfr. commit 6996cbb2372189f7 ("ARM: 8641/1: treewide: Replac
On Fri, 14 Jul 2017 13:41:15 -0300
Mauro Carvalho Chehab wrote:
> The Sphinx build chain is fragile: any upgrades can cause it to break.
>
> That's what happened this week, when I upgraded my machines to
> Fedora 26.
>
> So, add a separate chapter at sphinx.rst with Sphinx install instructions,
On 07/17/2017 01:49 PM, Matthew Wilcox wrote:
> On Mon, Jul 17, 2017 at 09:39:30AM -0400, Waiman Long wrote:
>> The number of positive dentries is limited by the number of files
>> in the filesystems. The number of negative dentries, however,
>> has no limit other than the total amount of memory av
On Mon, Jul 17, 2017 at 09:39:30AM -0400, Waiman Long wrote:
> The number of positive dentries is limited by the number of files
> in the filesystems. The number of negative dentries, however,
> has no limit other than the total amount of memory available in
> the system. So a rogue application tha
On Mon, Jul 17, 2017 at 04:57:02PM +0200, Andreas Schwab wrote:
> On Jun 19 2017, Yury Norov wrote:
>
> > diff --git a/include/linux/thread_bits.h b/include/linux/thread_bits.h
> > new file mode 100644
> > index ..87354331bc7b
> > --- /dev/null
> > +++ b/include/linux/thread_bits.h
>
On 07/17/2017 10:09 AM, Matthew Wilcox wrote:
> On Mon, Jul 17, 2017 at 09:39:31AM -0400, Waiman Long wrote:
>> @@ -63,9 +63,10 @@ struct qstr {
>> struct dentry_stat_t {
>> long nr_dentry;
>> long nr_unused;
>> -long age_limit; /* age in seconds */
>> -long want_pages;
On Mon, Jul 17, 2017 at 09:39:31AM -0400, Waiman Long wrote:
> @@ -63,9 +63,10 @@ struct qstr {
> struct dentry_stat_t {
> long nr_dentry;
> long nr_unused;
> - long age_limit; /* age in seconds */
> - long want_pages; /* pages requested by system */
> - lo
The number of positive dentries is limited by the number of files
in the filesystems. The number of negative dentries, however,
has no limit other than the total amount of memory available in
the system. So a rogue application that generates a lot of negative
dentries can potentially exhaust most o
A rogue application can potentially create a large number of negative
dentries in the system consuming most of the memory available. This
can impact performance of other applications running on the system.
This patchset introduces changes to the dcache subsystem to limit
the number of negative den
The number of negative dentries currently in the system is now reported
in the /proc/sys/fs/dentry-state file.
Signed-off-by: Waiman Long
---
fs/dcache.c| 16 +++-
include/linux/dcache.h | 7 ---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/fs/dcac
Having a limit for the number of negative dentries does have an
undesirable side effect that no new negative dentries will be allowed
when the limit is reached. This will have performance implication
for some types of workloads.
So we need a way to prune the negative dentries so that new ones can
The negative dentry pruning is done on a specific super_block set
in the ndblk.prune_sb variable. If the super_block is also being
un-mounted concurrently, the content of the super_block may no longer
be valid.
To protect against such racing condition, a new lock is added to
the ndblk structure to
All low-level PM/SMP code using virt_to_phys() should actually use
__pa_symbol() against kernel symbols. Update the documentation to move
away from virt_to_phys().
Cfr. commit 6996cbb2372189f7 ("ARM: 8641/1: treewide: Replace uses of
virt_to_phys with __pa_symbol")
Signed-off-by: Geert Uytterhoe
On 2017/7/17 17:54, Alexander Graf wrote:
On 17.07.17 11:26, Yang Zhang wrote:
On 2017/7/14 17:37, Alexander Graf wrote:
On 13.07.17 13:49, Yang Zhang wrote:
On 2017/7/4 22:13, Radim Krčmář wrote:
2017-07-03 17:28+0800, Yang Zhang:
The background is that we(Alibaba Cloud) do get more and
On newer versions of graphviz, it is needed to install a separate
package for PDF support.
Signed-off-by: Mauro Carvalho Chehab
---
This patch depends on a previous patch series I sent yesterday. This,
together with the other pending patches are available at:
https://git.linuxtv.org/mc
Em Mon, 17 Jul 2017 07:09:46 -0300
Mauro Carvalho Chehab escreveu:
> Em Mon, 17 Jul 2017 06:33:03 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Em Mon, 17 Jul 2017 10:15:26 +0200
> > Markus Heiser escreveu:
> >
> > > > Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab
> > > > :
> > > >
On Wed, Jul 12, 2017 at 10:35:04AM -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different format. Some
> doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - adjus
> Am 17.07.2017 um 12:09 schrieb Mauro Carvalho Chehab
> :
>
>>
>> Anyway, I guess we should modify kfigure.py to check if PDF is
>> available, falling back to SVG, using ImageMagick to convert
>> from SVG to PDF.
>
> Ok, I discovered that, on Fedora, support for pdf, png and some other
> form
Em Mon, 17 Jul 2017 06:33:03 -0300
Mauro Carvalho Chehab escreveu:
> Em Mon, 17 Jul 2017 10:15:26 +0200
> Markus Heiser escreveu:
>
> > > Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab
> > > :
> > >
> > > [1] There's an unrelated bug with the Kernel's sphinx extension
> > > kimage: when
On 17.07.17 11:26, Yang Zhang wrote:
On 2017/7/14 17:37, Alexander Graf wrote:
On 13.07.17 13:49, Yang Zhang wrote:
On 2017/7/4 22:13, Radim Krčmář wrote:
2017-07-03 17:28+0800, Yang Zhang:
The background is that we(Alibaba Cloud) do get more and more
complaints
from our customers in both
Em Mon, 17 Jul 2017 08:00:07 +0200
Markus Heiser escreveu:
> > Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab
> > :
> >
> > Instead of using 3 commands to install a virtualenv, use
> > a single one, reading the requirements from this file:
> >
> > Documentation/sphinx/requirements.tx
Em Mon, 17 Jul 2017 10:15:26 +0200
Markus Heiser escreveu:
> > Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab
> > :
> >
> > [1] There's an unrelated bug with the Kernel's sphinx extension
> > kimage: when parsing GraphViz graphs, it uses "-Tpdf" argument,
> > in order to generate a PDF im
On 2017/7/14 17:37, Alexander Graf wrote:
On 13.07.17 13:49, Yang Zhang wrote:
On 2017/7/4 22:13, Radim Krčmář wrote:
2017-07-03 17:28+0800, Yang Zhang:
The background is that we(Alibaba Cloud) do get more and more
complaints
from our customers in both KVM and Xen compare to bare-mental.Afte
>From b798b9b631e237d285aa8699da00bfb8ced33bea Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Mon, 17 Jul 2017 16:25:33 +0900
Subject: [PATCH] documentation: Fix two-CPU control-dependency example
In commit 5646f7acc95f ("memory-barriers: Fix control-ordering
no-transitivity example"), the o
> Am 17.07.2017 um 00:08 schrieb Mauro Carvalho Chehab
> :
>
> [1] There's an unrelated bug with the Kernel's sphinx extension
> kimage: when parsing GraphViz graphs, it uses "-Tpdf" argument,
> in order to generate a PDF image. That doesn't work on some
> distros, as GraphViz doesn't support PD
92 matches
Mail list logo
