Hello,
Serge Semin wrote:
> It is useful to have the whole memblock memory space printed to console
> when basic memlock initializations are done. It can be performed by
> ready-to-use method memblock_dump_all(), which prints the available
> and reserved memory spaces if memblock=debug kernel
Nope, it doesn't work. It compiled (after correcting one more leftover
mapping), but panicked the same way.
I've came up with a set of changes that make it working in my setup,
see attached patch. There was a problem with passing already remapped
address to tpm2_calc_event_log_size(), which tried
On 03/10/2019 09:13 AM, Masahiro Yamada wrote:
The 'Save As' menu of xconfig is not working; it always saves the
kernel configuration into the default file irrespective of the file
chosen in the dialog box.
The 'Save' menu always writes into the default file, but it would
make more sense to
Add macros that generate glue functions for camellia crypto functions.
Remove GLUE_FUNC_CAST macros from function pointer assignement and use
the helper instead, making the prototypes compliant.
Signed-off-by: Joao Moreira
---
arch/x86/crypto/camellia_aesni_avx2_glue.c | 69
Add macros that generate glue functions for cast6 crypto functions.
Remove GLUE_FUNC_CAST macros from function pointer assignement and use
the helper instead, making the prototypes compliant.
Signed-off-by: Joao Moreira
---
arch/x86/crypto/cast6_avx_glue.c | 54
Hello,
Serge Semin wrote:
> memblock subsystem provides a method to optionally test the passed
> memory region in case if it was requested via special kernel boot
> argument. Lets add the function at the bottom of the arch_mem_init()
> method. Testing at this point in the boot sequence should be
It is possible to indirectly invoke functions with prototypes that do not
match those of the respectively used function pointers by using void types.
This feature is frequently used as a way of relaxing function invocation,
making it possible that different data structures are passed to different
Create a TI LMU common framework for TI LMU devices that share
common features.
Currently the runtime ramp and brightness setting have
been identified as common features with common register settings.
This work is derived from Milo Kims TI LMU MFD code.
Acked-by: Pavel Machek
Signed-off-by:
Introduce the lm3697 LED driver for backlighting and display.
Datasheet location:
http://www.ti.com/lit/ds/symlink/lm3697.pdf
Signed-off-by: Dan Murphy
---
v4 - Updated common header name -
https://lore.kernel.org/patchwork/patch/1068619/
v3 - Moved TI_COMMON_LMU flag above LM3697 flag for
Document the ramp-up and ramp-down property in the binding.
Removing the "sec" from the property definition as seconds is
implied.
Reviewed-by: Rob Herring
Signed-off-by: Dan Murphy
---
v4 - Change property->properties, changed ramp-up/down-ms to ramp-up/down-us -
Hello
With this series there was an offline discussion that the filename of the LED
portion of the driver did not adhere to the directory file naming convention so
the file name has been changed
ti-lmu-led-common.c->leds-ti-lmu-common.c
ti-lmu-led-common.h->leds-ti-lmu-common.h
Dan
Dan Murphy
Fix the lm3632 dt binding examples as the LCM enable GPIOs
are defined as enable GPIOs per the regulator/lm363x-regulator.txt
bindings document.
Reviewed-by: Rob Herring
Signed-off-by: Dan Murphy
---
v4 - No changes - https://lore.kernel.org/patchwork/patch/1068613/
v3 - No changes added
Remove support for the LM3697 from the ti-lmu driver in favor of a
dedicated LED driver.
Acked-for-MFD-by: Lee Jones
Signed-off-by: Dan Murphy
---
v4 - No changes - https://lore.kernel.org/patchwork/patch/1068620/
v3 - No changes - https://lore.kernel.org/patchwork/patch/1058760/
v2 - Fixed
The LM3697 is a single function LED driver. The single function LED
driver needs to reside in the LED directory as a dedicated LED driver
and not as a MFD device. The device does have common brightness and ramp
features and those can be accomodated by a TI LMU framework.
The LM3697 dt binding
Add ti,brightness-resolution to the TI LMU binding to define
whether the device uses 8-bit brightness or 11-bit brightness.
Reviewed-by: Rob Herring
Signed-off-by: Dan Murphy
---
v4 - No changes - https://lore.kernel.org/patchwork/patch/1068617/
v3 - No changes added Reviewed-by Rob -
Hi Serge,
On Fri, May 03, 2019 at 08:50:39PM +0300, Serge Semin wrote:
> It is useful at least for debugging to have the kernel virtual
> memory layout printed at boot time so to have the full information
> about the booted kernel. Make the printing optional and available
> only when DEBUG_KERNEL
Hello,
Serge Semin wrote:
> Since memblock-patchset was introduced the reserved-memory nodes are
> supported being declared in dt-files. So these nodes are actually parsed
> during the arch setup procedure when the early_init_fdt_scan_reserved_mem()
> method is called. But due to the
Hello,
Serge Semin wrote:
> There are situations when memory regions coming from dts may be
> too big for the platform physical address space. This especially
> concerns XPA-capable systems. Bootloader may determine more than 4GB
> memory available and pass it to the kernel over dts memory node,
!UML && SND [=y] && SND_SOC [=y] &&
SND_SOC_SOF_TOPLEVEL [=y] && (ACPI [=y] || COMPILE_TEST [=n]) && X86 [=y]
Signed-off-by: Randy Dunlap
Cc: Liam Girdwood
Cc: Mark Brown
Cc: alsa-de...@alsa-project.org
---
sound/soc/sof/Kconfig |2 +-
1 file changed, 1 i
On Mon 06-05-19 23:22:08, Zhiqiang Liu wrote:
[...]
> Does adding Cc: stable mean adding Cc:
> tag in the patch or Ccing sta...@vger.kernel.org when sending the new mail?
The former. See Documentation/process/stable-kernel-rules.rst for more.
Thanks!
--
Michal Hocko
SUSE Labs
Mark,
gmail once again hates your emails. Your email ends up as spam, due to
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org
but it has a DKIM signature for sirena.org.uk:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=sirena.org.uk; ...
Hmm?
On Mon, 6 May 2019 11:06:51 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 10:06 AM Steven Rostedt wrote:
> >
> > Can you try booting with:
> > [ snip snip ]
> >
> > And see if it boots?
>
> No it doesn't.
>
> Dang, I tried to figure out what's up, but now I really have to start
>
Andrew Lunn writes:
> On Sun, May 05, 2019 at 03:05:23PM -0700, Ruslan Babayev wrote:
>> Lookup I2C adapter using the "i2c-bus" device property on ACPI based
>> systems similar to how it's done with DT.
>>
>> An example DSD describing an SFP on an ACPI based system:
>>
>> Device (SFP0)
>> {
>>
The patch itself is fine but I think we have a bigger problem here:
3052 >---cinode->oplock = 0;
here we reset oplock level of the inode, so forcing all the IO go to the server.
3053 >---if (oplock & SMB2_LEASE_READ_CACHING_HE) {
3054 >--->---cinode->oplock |=
From: Kuppuswamy Sathyanarayanan
When IOMMU tries to enable PASID for VF device in
iommu_enable_dev_iotlb(), it always fails because PASID support for PCIe
VF device is currently broken in PCIE driver. Current implementation
expects the given PCIe device (PF & VF) to implement PASID capability
Folks,
after the initial SPDX sweep of the kernel, people have slowly started to
fixup the licensing mess. The current approach has some issues:
1) With the current rate of changes we are going to be finished in about
10+ years from now
2) The error rate with these cleanups is frightening
On Mon, 2019-05-06 at 20:12 +0200, Stefan Wahren wrote:
> Hi Nicolas,
>
> Am 06.05.19 um 16:40 schrieb Nicolas Saenz Julienne:
> > Hi,
> > ...
> >
> > Regards,
> > Nicolas
> >
> > [1] https://github.com/raspberrypi/linux/issues/2881
> > [2]
On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote:
> The need to be able to scope path resolution of interpreters became
> clear with one of the possible vectors used in CVE-2019-5736 (which
> most major container runtimes were vulnerable to).
>
> Naively, it might seem that openat(2) -- which
The eBPF based opensnoop tool fails to read the file path string passed
to the do_sys_open function. This is because it is a pointer to
userspace address and causes an -EFAULT when read with
probe_kernel_read. This is not an issue when running the tool on x86 but
is an issue on arm64. This patch
The uapi in tools/ needs an update after support for new bpf function
calls were added. This commit does the same.
Signed-off-by: Joel Fernandes (Google)
---
tools/include/uapi/linux/bpf.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git
bpf_probe_read is deprecated and ambiguous. Add a warning if programs
still use it, so that they may be moved to not use it. After sufficient
time, the warning can be removed.
Signed-off-by: Joel Fernandes (Google)
---
kernel/bpf/verifier.c | 4
1 file changed, 4 insertions(+)
diff --git
This series addresses some errors seen when using the loop
device directly backed by a block device. The first change plumbs
out the correct error message, and the second change prevents the
error from occurring in many cases.
The errors look like this:
[ 90.880875] print_req_error: I/O error,
On Sun, May 05, 2019 at 02:15:00AM +, Anson Huang wrote:
> i.MX system controller watchdog can support pretimeout IRQ
> via general SCU MU IRQ, it depends on IMX_SCU and driver MUST
> be probed after SCU IPC ready, then enable corresponding SCU
> IRQ group and register SCU IRQ notifier, when
On Thu, 02 May 2019 08:28:40 PDT (-0700), r...@linux.ibm.com wrote:
The only difference between the generic and RISC-V implementation of PTE
allocation is the usage of __GFP_RETRY_MAYFAIL for both kernel and user
PTEs and the absence of __GFP_ACCOUNT for the user PTEs.
The conversion to the
Hi,
some more words from the I2C world.
> +For instance, you can instantiate the ipmb-dev-int device from
> +user space at the 7 bit address 0x10 on bus 2:
> +
> + # echo ipmb-dev 0x10 > /sys/bus/i2c/devices/i2c-2/new_device
"0x1010" as described in Documentation/i2c/slave-interface
> +config
On Mon, May 6, 2019 at 2:04 PM Dave Hansen wrote:
>
> On 5/6/19 11:01 AM, Dan Williams wrote:
> >>> +void __remove_memory(int nid, u64 start, u64 size)
> >>> {
> >>> +
> >>> + /*
> >>> + * trigger BUG() is some memory is not offlined prior to calling
> >>> this
> >>> + * function
Hi Linus,
Please pull these arm64 updates for 5.2. As per usual, there are details
in the tag, but it's worth noting that we're including the core
"mitigations=" command-line code here from -tip so that we could develop
arm64 support on top of adding support for the "cpu/vulnerabilities"
This patch adds booti support for RISC-V Linux kernel. The existing
bootm method will also continue to work as it is.
It depends on the following kernel patch which adds the header to the
flat Image. Gzip compressed Image (Image.gz) support is not enabled with
this patch.
Hi Linus,
Here's the mmiowb() removal series ready for 5.2. The only relatively
recent changes have been addressing review comments on the documentation,
which is in a much better shape thanks to the efforts of Ben and Ingo.
I was initially planning to split this into two pull requests so that
Hi Nicolas,
Am 06.05.19 um 16:40 schrieb Nicolas Saenz Julienne:
> Hi,
> ...
>
> Regards,
> Nicolas
>
> [1] https://github.com/raspberrypi/linux/issues/2881
> [2] https://archlinuxarm.org/forum/viewtopic.php?f=65=13485
> [3]
>
On Mon, May 06, 2019 at 06:13:12AM +, Jayachandran Chandrasekharan Nair
wrote:
> Perhaps someone from ARM can chime in here how the cas/yield combo
> is expected to work when there is contention. ThunderX2 does not
> do much with the yield, but I don't expect any ARM implementation
> to treat
On Mon, May 6, 2019 at 10:06 AM Steven Rostedt wrote:
>
> Can you try booting with:
> [ snip snip ]
>
> And see if it boots?
No it doesn't.
Dang, I tried to figure out what's up, but now I really have to start
handling all the puill requests..
I thought it might be an int3 that happens on the
On 5/5/19, 9:24 PM, "Andrew Jeffery" wrote:
On Sat, 4 May 2019, at 03:43, Vijay Khemka wrote:
> Corrected some of return values with appropriate meanings and reported
> relevant messages as debug information.
>
> Signed-off-by: Vijay Khemka
Thanks for
On Mon, May 6, 2019 at 10:57 AM Dave Hansen wrote:
>
> > -static inline void remove_memory(int nid, u64 start, u64 size) {}
> > +static inline bool remove_memory(int nid, u64 start, u64 size)
> > +{
> > + return -EBUSY;
> > +}
>
> This seems like an appropriate place for a WARN_ONCE(), if
On 5/6/19 11:01 AM, Dan Williams wrote:
>>> +void __remove_memory(int nid, u64 start, u64 size)
>>> {
>>> +
>>> + /*
>>> + * trigger BUG() is some memory is not offlined prior to calling this
>>> + * function
>>> + */
>>> + if (try_remove_memory(nid, start, size))
>>> +
The following changes since commit 17403fa277eda1328a7026dfca7e40249f27dc6b:
Merge tag 'ext4_for_linus_stable' of
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2019-03-24 13:41:37
-0700)
are available in the Git repository at:
Hi,
On Tue, May 07, 2019 at 01:08:39AM +0800, Frank Lee wrote:
> On Tue, May 7, 2019 at 12:52 AM Icenowy Zheng wrote:
> >
> > 在 2019-05-06一的 14:28 +0200，Maxime Ripard写道：
> > > Hi,
> > >
> > > On Sun, May 05, 2019 at 04:22:15PM +0100, Jonathan Cameron wrote:
> > > > On Fri, 3 May 2019 03:28:07
Pavel
On 4/30/19 5:01 PM, Pavel Machek wrote:
> On Tue 2019-04-30 14:17:25, Dan Murphy wrote:
>> Document the ramp-up and ramp-down property in the binding.
>> Removing the "sec" from the property definition as seconds is
>> implied.
>>
>> Reviewed-by: Rob Herring
>> Signed-off-by: Dan Murphy
On Mon, May 6, 2019 at 6:59 PM Andrew Lunn wrote:
>
> > /*
> > * 'process_lock' exists because ocores_process() and
> > ocores_process_timeout()
> > @@ -239,8 +240,13 @@ static irqreturn_t ocores_isr(int irq, void *dev_id)
> > struct ocores_i2c *i2c = dev_id;
> > u8 stat =
This amends commit 10dce8af3422 ("fs: stream_open - opener for
stream-like files so that read and write can run simultaneously without
deadlock") in how position is passed into .read()/.write() handler for
stream-like files:
Rasmus noticed that we currently pass 0 as position and ignore any
Just to make this clear, I won't apply Christoph's patch (the one in
this email thread) and instead the only change I will make is to
rename dma_limit to dma_mask.
On Tue, Apr 30, 2019 at 1:05 PM Robin Murphy wrote:
>
> On 30/04/2019 12:32, Christoph Hellwig wrote:
> > On Tue, Apr 30, 2019 at
Hi!
> > > [ Upstream commit fa3a419d2f674b431d38748cb58fb7da17ee8949 ]
> > >
> > > The call to of_parse_phandle returns a node pointer with refcount
> > > incremented thus it must be explicitly decremented after the last
> > > usage.
> > >
> > > Detected by coccinelle with the following warnings:
Em Tue, 7 May 2019 01:08:58 +0800
Changbin Du escreveu:
> This converts the plain text documentation to reStructuredText format and
> add it to Sphinx TOC tree. No essential content change.
>
> Signed-off-by: Changbin Du
> Cc: Mauro Carvalho Chehab
> ---
> Documentation/x86/{boot.txt =>
On Mon, 6 May 2019 10:00:26 +0200, Maxime Chevallier wrote:
> Hello Jakub,
>
> On Sat, 4 May 2019 02:53:53 -0400
> Jakub Kicinski wrote:
>
> >On Tue, 30 Apr 2019 15:14:25 +0200, Maxime Chevallier wrote:
> >> Compared to the first submissions, the NETIF_F_NTUPLE flag was also
> >> removed,
dtlk_open currently has 2 calls to nonseekable_open which are both
executed on success path. It was not hurting to make the extra call as
nonseekable_open is only changing file->f_flags in idempotent way.
However the first nonseekable_open is indeed both unneeded and looks
suspicious.
The first
The Wilco Embedded Controller is able to send telemetry data
which is useful for enterprise applications. A daemon running on
the OS sends a command to the EC via a write() to a char device,
and can read the response with a read(). The write() request is
verified by the driver to ensure that it is
On 06/05/2019 19:28, Masahiro Yamada wrote:
> These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
> successfully compiled because they are never built as a module by
> anyone, i.e, the MODULE_ALIAS() calls are always no-op.
>
> A problem showed up when a patch "moduleparam: Save
The 0xF6 command, intended to send and receive 256 byte payloads to
and from the EC, is not needed. The 0xF5 command for 32 byte
payloads is sufficient. This patch removes support for the 0xF6
command and 256 byte payloads.
Signed-off-by: Nick Crews
---
On Mon, May 6, 2019 at 6:49 PM Andrew Lunn wrote:
>
> On Mon, May 06, 2019 at 06:23:58PM +0530, Sagar Shrikant Kadam wrote:
> > Add DT binding for OpenCore's based i2c device as found in
> > FU540 Chipset on HiFive Unleashed Platform (Rev A00).
> >
> > The doc explains, how to add DT support for
> On Mon, May 06, 2019 at 05:46:56PM +0200, Esben Haabendal wrote:
>> Andy Shevchenko writes:
>> >> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote:
>> >> >> Andy Shevchenko writes:
>
>> As an example, the sm501.c driver, the only driver in drivers/mfd/ which
>> uses serial8250
Linus,
Minor updates to ktest.pl
- Handle meta characters in grub memu
- Use configurable reboot return code for handling ssh reboots
- Display names and iteration number on error message
Please pull the latest ktest-v5.1 tree, which can be found at:
Linus,
Please consider applying the following stream_open related patches:
- The first one removes unnecessary double nonseekable_open from
drivers/char/dtlk.c as noticed by Pavel Machek while reviewing
nonseekable_open -> stream_open mass conversion.
- The second one is the mass conversion
Hi,
On 06-05-19 14:12, Andy Shevchenko wrote:
On Mon, Apr 29, 2019 at 5:38 PM Hans de Goede wrote:
When the ideapad-laptop driver was first written it was written for laptops
which had a hardware rfkill switch. So when the first ideapad laptops
showed up without a hw rfkill switch and it
Hi Carmeli,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1 next-20190506]
[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
Fixed pep8/flake8 python style code for lsvmbus tool.
The TAB indentation was on purpose ignored (pep8 rule W191) to make
sure the code is complying with the Linux code guideline.
The following command do not show any warnings now:
pep8 --ignore=W191 lsvmbus
flake8 --ignore=W191 lsvmbus
These files do not define (USBHS_)DRIVER_NAME. Yet, they can be
successfully compiled because they are never built as a module by
anyone, i.e, the MODULE_ALIAS() calls are always no-op.
A problem showed up when a patch "moduleparam: Save information about
built-in modules in separate file" is
Hi Rob,
PING...
From: Kuppuswamy Sathyanarayanan
If PF does not implement ATS and VF implements/uses it, it might lead to
runtime issues. Also, as per spec r4.0, sec 9.3.7.8, PF should implement
ATS if VF implements it. So add additional check to confirm given device
aligns with the spec.
Cc: Ashok Raj
Cc:
From: Kuppuswamy Sathyanarayanan
Current implementation of ATS, PASID, PRI does not handle VF dependencies
correctly. Following patches addresses this issue.
Changes since v1:
* Added more details about the patches in commit log.
* Removed bulk spec check patch.
* Addressed comments from
From: Kuppuswamy Sathyanarayanan
When IOMMU tries to enable PRI for VF device in
iommu_enable_dev_iotlb(), it always fails because PRI support for PCIe
VF device is currently broken in PCIE driver. Current implementation
expects the given PCIe device (PF & VF) to implement PRI capability
before
On Mon, May 6, 2019 at 7:48 AM Ingo Molnar wrote:
> > - unsigned int pkgid = topology_logical_package_id(cpu);
> > + unsigned int pkgid = topology_logical_die_id(cpu);
> There's many such instances left in this series, please review the whole
> patchset for such problems.
I agree, the
From: Kuppuswamy Sathyanarayanan
As per PCIe r4.0, sec 9.3.6, VF must not implement Enhanced Allocation
Capability. So skip pci_ea_init() for virtual devices.
Cc: Ashok Raj
Cc: Keith Busch
Suggested-by: Ashok Raj
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/pci/pci.c | 7 +++
From: Kuppuswamy Sathyanarayanan
Currently all VF's needs to be disable their ATS service before
disabling the ATS service in corresponding PF device. But this logic is
incorrect and does not align with the spec. Also it might lead to
some power and performance impact in the system. As per PCIe
Fixed pep8/flake8 python style code for lsvmbus tool.
The TAB indentation was on purpose ignored (pep8 rule W191) to make
sure the code is complying with the Linux code guideline.
The following command doe not show any warnings now:
pep8 --ignore=W191 lsvmbus
flake8 --ignore=W191 lsvmbus
On 05/06/19 12:01, Steven Rostedt wrote:
> On Mon, 6 May 2019 16:33:17 +0100
> Qais Yousef wrote:
>
> > On 05/06/19 10:46, Steven Rostedt wrote:
> > > On Mon, 6 May 2019 15:42:00 +0100
> > > Qais Yousef wrote:
> > >
> > > > I can control that for the wrappers I'm introducing. But the actual
From: Kuppuswamy Sathyanarayanan
When IOMMU tries to enable PASID for VF device in
iommu_enable_dev_iotlb(), it always fails because PASID support for PCIe
VF device is currently broken in PCIE driver. Current implementation
expects the given PCIe device (PF & VF) to implement PASID capability
Hi Linus,
Please pull these changes for v5.2-rc1. This is effectively part of my
gcc-plugins tree, but as this adds some Clang support, it felt weird
to still call it "gcc-plugins". :) This consolidates Kconfig for the
existing stack variable initialization (via structleak and stackleak
gcc
On 5/6/19 7:06 AM, Zhiqiang Liu wrote:
> From: Kai Shen
>
> spinlock recursion happened when do LTP test:
> #!/bin/bash
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
> ./runltp -p -f hugetlb &
>
> The dtor returned by
On Sun, May 5, 2019 at 11:13 PM Jayachandran Chandrasekharan Nair
wrote:
>
> > It's not normal, and it's not inevitable.
>
> If you look at the code, the CAS failure is followed by a yield
> before retrying the CAS. Yield on arm64 is expected to be a hint
> to release resources so that other
On Tue, May 7, 2019 at 12:52 AM Icenowy Zheng wrote:
>
> 在 2019-05-06一的 14:28 +0200，Maxime Ripard写道：
> > Hi,
> >
> > On Sun, May 05, 2019 at 04:22:15PM +0100, Jonathan Cameron wrote:
> > > On Fri, 3 May 2019 03:28:07 -0400
> > > Yangtao Li wrote:
> > >
> > > > For some SOCs, there are more than
On Mon, 6 May 2019 09:17:19 -0700
Linus Torvalds wrote:
> So what is it that doesn't actually work? I've looked at the patch
> even more, and I can't for the life of me see how it wouldn't work.
>
> Of course, I didn't test any of the actual ftrace parts, since I
> short-circuited them
We could always switch it to strncpy :)
In any case - he is correct, it is better than what was there because
we should not strcat unless the array were locked across the whole
function
On Mon, May 6, 2019 at 11:57 AM Jeremy Allison wrote:
>
> On Mon, May 06, 2019 at 11:53:44AM -0500, Steve
From: Trac Hoang
The iproc host eMMC/SD controller hold time does not meet the
specification in the HS50 mode. This problem can be mitigated
by disabling the HISPD bit; thus forcing the controller output
data to be driven on the falling clock edges rather than the
rising clock edges.
Fixes:
From: Trac Hoang
The iproc host eMMC/SD controller hold time does not meet the
specification in the HS50 mode. This problem can be mitigated
by disabling the HISPD bit; thus forcing the controller output
data to be driven on the falling clock edges rather than the
rising clock edges.
This
This patch allows for O_BENEATH and O_THISROOT to safely permit ".."
resolution (in the case of O_BENEATH the resolution will still fail if
".." resolution would resolve a path outside of the root -- while
O_THISROOT will chroot(2)-style scope it). "magic link" jumps are still
disallowed entirely
The need to be able to scope path resolution of interpreters became
clear with one of the possible vectors used in CVE-2019-5736 (which
most major container runtimes were vulnerable to).
Naively, it might seem that openat(2) -- which supports path scoping --
can be combined with
Patch changelog:
v6:
* Drop O_* flags API to the new LOOKUP_ path scoping bits and
instead introduce resolveat(2) as an alternative method of
obtaining an O_PATH. The justification for this is included in
patch 6 (though switching back to O_* flags is trivial).
v5:
*
Hi!
On Mon, May 06, 2019 at 04:31:38PM +, Christophe Leroy wrote:
> However, I've tried your suggestion below and get unnexpected result.
> >you can do
> >
> > __asm__ __volatile__ ("dcbf %0" : : "Z"(addr) : "memory");
> >
> >to save some insns here and there. ]
This should be "dcbf
On 5/6/19 11:38 AM, Vinod Koul wrote:
On 06-05-19, 09:48, Pierre-Louis Bossart wrote:
+struct dentry *sdw_bus_debugfs_get_root(struct sdw_bus_debugfs *d)
+{
+ if (d)
+ return d->fs;
+ return NULL;
+}
+EXPORT_SYMBOL(sdw_bus_debugfs_get_root);
_GPL()?
Oops, that's a
Add the following flags to allow various restrictions on path
resolution (these affect the *entire* resolution, rather than just the
final path component -- as is the case with most other AT_* flags).
The primary justification for these flags is to allow for programs to be
far more strict about
On Mon, May 06, 2019 at 11:53:44AM -0500, Steve French via samba-technical
wrote:
> I think strcpy is clearer - but I don't think it can overflow since if
> R, W or W were written to "message" then cinode->oplock would be
> non-zero so we would never strcap "None"
Ahem. In Samba we have :
IMA can be configured to measure and appraise a file's integrity being
mmap'ed execute. Files can be mmap'ed read/write and later changed to
execute to circumvent IMA's mmap measurement and appraisal policy rules.
To prevent this from happening, this patch similarly calls
ima_file_mmap() for
I think strcpy is clearer - but I don't think it can overflow since if
R, W or W were written to "message" then cinode->oplock would be
non-zero so we would never strcap "None"
On Mon, May 6, 2019 at 10:26 AM Christoph Probst wrote:
>
> Change strcat to strcpy in the "None" case as it is never
The primary motivation for the need for this flag is container runtimes
which have to interact with malicious root filesystems in the host
namespaces. One of the first requirements for a container runtime to be
secure against a malicious rootfs is that they correctly scope symlinks
(that is, they
在 2019-05-06一的 14:28 +0200，Maxime Ripard写道：
> Hi,
>
> On Sun, May 05, 2019 at 04:22:15PM +0100, Jonathan Cameron wrote:
> > On Fri, 3 May 2019 03:28:07 -0400
> > Yangtao Li wrote:
> >
> > > For some SOCs, there are more than one thermal sensor, and there
> > > are
> > > currently four sensors
The kernel calls deny_write_access() to prevent a file already opened
for write from being executed and also prevents files being executed
from being opened for write. For some reason this does not extend to
files being mmap'ed execute.
>From an IMA perspective, measuring/appraising the
Hi Linus,
Please pull the following Kselftest update for Linux 5.2-rc1
This Kselftest update for Linux 5.2-rc1 consists of
- fixes to seccomp test, and kselftest framework
- cleanups to remove duplicate header defines
- fixes to efivarfs "make clean" target
- cgroup cleanup path
- Moving the
This patch series fixes data hold timing issues for various sdhci-iproc
ip blocks that do not meet the HS50 data hold time. NO_HISPD bit is set
in quirks.
Trac Hoang (2):
mmc: sdhci-iproc: cygnus: Set NO_HISPD bit to fix HS50 data hold time
problem
mmc: sdhci-iproc: Set NO_HISPD bit to
Fix typos in the HyperV toolchain.
Signed-off-by: Adrian Vladu
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Sasha Levin
Cc: Alessandro Pilotti
---
tools/hv/hv_get_dhcp_info.sh | 2 +-
tools/hv/hv_kvp_daemon.c | 6 +++---
tools/hv/hv_set_ifconfig.sh | 2 +-
HyperV KVP and VSS daemons should exit with 0 when the '--help'
or '-h' flags are used.
Signed-off-by: Adrian Vladu
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Sasha Levin
Cc: Alessandro Pilotti
---
tools/hv/hv_kvp_daemon.c | 2 ++
tools/hv/hv_vss_daemon.c | 2 ++
2
401 - 500 of 1279 matches
Mail list logo
