On Wed, 6 Jan 2021 22:42:01 +0800 Sieng Piaw Liew wrote:
> This patch series aim to improve the bcm63xx_enet driver by integrating the
> latest networking features, i.e. batched rx processing, BQL, build_skb,
> etc.
>
> The newer enetsw SoCs are found to be able to do unaligned rx DMA by adding
On Thu, Jan 7, 2021 at 7:15 PM Nathan Chancellor
wrote:
> On Thu, Jan 07, 2021 at 09:22:00AM -0800, Kees Cook wrote:
> > I think this is:
> > https://github.com/ClangBuiltLinux/linux/issues/256
> > and that bug needs re-opening? Or maybe there's a new bug I can't find?
>
> The problem is that
On Sat, Dec 26, 2020 at 03:42:48PM +0800, Dinghao Liu wrote:
> If usnic_ib_qp_grp_create() fails at the first call, dev_list
> will not be freed on error, which leads to memleak.
>
> Signed-off-by: Dinghao Liu
> Reviewed-by: Leon Romanovsky
> ---
> drivers/infiniband/hw/usnic/usnic_ib_verbs.c
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Friday, January 8, 2021 7:58 AM
> To: Song Bao Hua (Barry Song)
> Cc: t...@linutronix.de; m...@kernel.org; linux-in...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux...@openeuler.org; Dmitry
On Thu, Jan 7, 2021 at 12:45 PM Jeremy Linton wrote:
>
> Hi,
>
> On 1/7/21 11:36 AM, Rob Herring wrote:
> > On Thu, Jan 7, 2021 at 9:24 AM Jeremy Linton wrote:
> >>
> >> Hi,
> >>
> >>
> >> On 1/7/21 9:28 AM, Rob Herring wrote:
> >>> On Mon, Jan 4, 2021 at 9:57 PM Jeremy Linton
> >>> wrote:
>
irq_hpd event can only be executed at connected state. Therefore
irq_hpd event should be postponed if it happened at connection
pending state. This patch also make sure both link rate and lane
are valid before start link training.
Signed-off-by: Kuogee Hsieh
---
There is HPD unplug interrupts missed at scenario of an irq_hpd
followed by unplug interrupts with around 10 ms in between.
Since both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts,
irq_hpd handler should not issues either aux or sw reset to avoid
following unplug interrupt be cleared
On Thu, Jan 7, 2021 at 12:25 PM Jason Gunthorpe wrote:
>
> Lots of places are relying on pin_user_pages long term pins of memory,
> and cannot be converted to notifiers.
>
> I don't think it is reasonable to just declare that insecure and
> requires privileges, it is a huge ABI break.
Also, I
Both AUX_SW_RESET and DP_SW_RESET clear pending HPD interrupts.
Therefore irq_hpd handler should not issues either aux or sw reset
to avoid following unplug interrupt be cleared accidentally.
Kuogee Hsieh (2):
drm/msm/dp: postpone irq_hpd event during connection pending state
drm/msm/dp:
> Do you see "Co-developed-by" in the title of that section? This is how
> you express co-authorship.
Yes, I do now.
>
> As it is now:
>
> Signed-off-by: Sunil Muthuswamy
> Signed-off-by: Boqun Feng (Microsoft)
>
> it says that you authored the patch and Boqun handled it further, i.e.,
>
Bing Song noticed the CMA heap was leaking memory due to a flub
I made in commit a5d2d29e24be ("dma-buf: heaps: Move heap-helper
logic into the cma_heap implementation"), and provided this fix
which ensures the pagelist is also freed on release.
Cc: Bing Song
Cc: Sumit Semwal
Cc: Liam Mark
Cc:
On Thu, Jan 7, 2021 at 12:17 PM Linus Torvalds
wrote:
>
> I still think the real fix is "Don't do that then", and just take the
> write lock.
The alternative, of course, is to just make sure the page table flush
is done inside the page table lock (and then we make COW do the copy
inside of it).
On Thu, Jan 07, 2021 at 03:04:00PM -0500, Andrea Arcangeli wrote:
> vmsplice syscall API is insecure allowing long term GUP PINs without
> privilege.
Lots of places are relying on pin_user_pages long term pins of memory,
and cannot be converted to notifiers.
I don't think it is reasonable to
The pull request you sent on Thu, 07 Jan 2021 17:09:30 +:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
> tags/regmap-fix-v5.11-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc37784dc71bc9dd3a00a2f01906b3966e4034f2
Thank you!
--
The pull request you sent on Thu, 07 Jan 2021 17:09:55 +:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
> tags/regulator-fix-v5.11-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a1a7b4f32433e91f0fff32cde534eadc67242298
Thank you!
The pull request you sent on Thu, 07 Jan 2021 17:10:22 +:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
> tags/spi-fix-v5.11-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f5e6c330254ae691f6d7befe61c786eb5056007e
Thank you!
--
On Thu, Jan 07, 2021 at 08:16:28PM +, Sunil Muthuswamy wrote:
> > What is this SoB chain supposed to say?
>
> Quoting from the link you shared:
> "The Signed-off-by: tag indicates that the signer was involved in the
> development of
> the patch, or that he/she was in the patch's delivery
On Thu, 7 Jan 2021 19:45:49 +
Russell King - ARM Linux admin wrote:
> I think you're not reading the code very well. It checks for bytes at
> offset 1..blocksize-1, blocksize+1..2*blocksize-1, etc are zero. It
> does _not_ check that byte 0 or the byte at N*blocksize is zero - these
> bytes
On Thu, Jan 07, 2021, Paolo Bonzini wrote:
> On 07/01/21 10:38, Maxim Levitsky wrote:
> > The code to store it on the migration exists, but no code was restoring it.
> >
> > One of the side effects of fixing this is that L1->L2 injected events
> > are no longer lost when migration happens with
> There seems to be a long tradition of dreaming up random formats for
> the subject lines of Hyper-V-related patches. Look at all the
> different ways these are spelled, hyphenated, and capitalized:
>
I am reading this as a suggestion to unify the format of the subject of
the Hyper-V patches.
> What is this SoB chain supposed to say?
Quoting from the link you shared:
"The Signed-off-by: tag indicates that the signer was involved in the
development of
the patch, or that he/she was in the patch's delivery path."
My intent to include Boqun in the Signed-off by tag was to indicate that
On Fri, Dec 18, 2020 at 03:30:18PM -0800, Randy Dunlap wrote:
> Hi--
>
> On 12/1/20 2:34 PM, mgr...@linux.intel.com wrote:
> > From: mark gross
> >
> >
> > Reviewed-by: Mark Gross
> > Signed-off-by: Mark Gross
>
> My reading of submitting-patches.rst seems to indicate that
> the Reviewer
On Thu, Jan 7, 2021 at 12:04 PM Andrea Arcangeli wrote:
>
> However there are two cases that could wrprotecting exclusive anon
> pages with only the mmap_read_lock:
I still think the real fix is "Don't do that then", and just take the
write lock.
The UFFDIO_WRITEPROTECT case simply isn't that
Hi,
On Tue, Dec 22, 2020 at 01:52:48AM -0800, Joe Perches wrote:
> On Tue, 2020-12-22 at 09:52 +0100, Greg KH wrote:
> > On Mon, Dec 21, 2020 at 08:25:47AM -0800, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > Attributing the function allows the compiler to more thoroughly
> > > check
Hello,
I prepared in 2/2 a fix to make UFFDIO_WRITEPROTECT and
clear_refs_write cope with page_count in do_wp_page. It'd stack
perfectly on top of 1/2 from will which fixes an orthogonal regression
and it'd need to be applied first since its Fixes tag comes first.
I hope this patchset shows and
NOTE: the "Fixes" tag used here is to optimize the backporting, but
09854ba94c6aad7886996bfbee2530b3d8a7f4f4 is completely
correct. Despite being correct it happened to uncover some implicit
assumption some other code made on a very specific behavior in
do_wp_page that had to be altered by such
From: Will Deacon
Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double
flush"), TLB invalidation is elided in tlb_finish_mmu() if no entries
were batched via the tlb_remove_*() functions. Consequently, the
page-table modifications performed by clear_refs_write() in response to
a
On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a
On Wed, Dec 23, 2020 at 11:30:41AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> This change fixes the checkpatch warning described in this commit
> commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of
> unnecessary %h[xudi] and %hh[xudi]")
>
> Standard integer promotion is
On Thu, 7 Jan 2021 16:15:24 +0200, Claudiu Beznea wrote:
> This patch makes the LPM pin as optional as this may be controlled
> in the last phase of suspend procedure to decrease the power consumption
> while suspended. Along w/ this update the MAINTAINERS entry for this
> driver.
>
> Thank you,
On Thu, 7 Jan 2021 14:23:55 +0200, Matti Vaittinen wrote:
> The ROHM PMIC regulator drivers only need the regmap pointer from
> the parent device. Regmap can be obtained via dev_get_regmap()
> so do not require parent to populate driver data for that.
Applied to
On 1/7/21 4:32 AM, Miaohe Lin wrote:
> In hugetlb_sysfs_add_hstate(), we would do kobject_put() on hstate_kobjs
> when failed to create sysfs group but forget to set hstate_kobjs to NULL.
> Then in hugetlb_register_node() error path, we may free it again via
> hugetlb_unregister_node().
>
>
Exclude RMII from modes that report 1 GbE support. Reduced MII supports
up to 100 MbE.
Fixes: 14fceff ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Aleksander Jan Bajkowski
---
drivers/net/dsa/lantiq_gswip.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
On 1/7/21 11:58 AM, Aleksander Jan Bajkowski wrote:
> Exclude RMII from modes that report 1 GbE support. Reduced MII supports
> up to 100 MbE.
>
> Fixes: 14fceff ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Signed-off-by: Aleksander Jan Bajkowski
Reviewed-by: Florian Fainelli
--
On Thu, Jan 07, 2021 at 11:33:36AM -0800, Linus Torvalds wrote:
> In fact, even some threaded app that does what I suspect it could do
> would likely be ok with it 99% of the time. Because the situation
> where you change the fd in the poll array is likely not the common
> case, and even if some
From: Alexander Usyskin
Send the stop command to the firmware on watchdog unregister
to eleminate false event on suspend.
Cc:
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/watchdog/mei_wdt.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hello,
Requesting to provide review comments.
Thanks & Regards,
Nadeem Athani
> -Original Message-
> From: Nadeem Athani
> Sent: Wednesday, December 30, 2020 5:35 PM
> To: Tom Joseph ; lorenzo.pieral...@arm.com;
> r...@kernel.org; bhelg...@google.com; kis...@ti.com; linux-
>
On 1/7/21 12:13 PM, Paolo Bonzini wrote:
On 04/01/21 21:20, Tom Lendacky wrote:
From: Tom Lendacky
Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
where the guest vCPU register state is updated and then the vCPU is VMRUN
to begin execution of the AP. For an SEV-ES
On Mon, Jan 04, 2021 at 08:58:23PM -0600, Mike Ximing Chen wrote:
> Introduce the dlb device ioctl layer and the first three ioctls: query
> device version, query available resources, and create a scheduling domain.
> Also introduce the user-space interface file dlb_user.h.
>
> The device version
On Thu, Jan 07, 2021 at 06:57:10AM -0800, Doug Anderson wrote:
> Hi,
>
> On Wed, Jan 6, 2021 at 6:22 PM Dmitry Torokhov
> wrote:
> >
> > Hi Doug, Stephen,
> >
> > On Wed, Jan 06, 2021 at 05:16:10PM -0800, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Fri, Dec 4, 2020 at 4:48 PM Stephen Boyd
On Wed, Jan 6, 2021 at 8:45 PM Willem de Bruijn wrote:
>
> But there are three other kmap_atomic callers under net/ that do not
> loop at all, so assume non-compound pages. In esp_output_head,
> esp6_output_head and skb_seq_read. The first two directly use
> skb_page_frag_refill, which can
On Thu, Jan 07, 2021 at 06:19:23PM +0100, Andrew Lunn wrote:
> > -static int sfp_quirk_i2c_block_size(const struct sfp_eeprom_base *base)
> > +static bool sfp_id_needs_byte_io(struct sfp *sfp, void *buf, size_t len)
> > {
> > - if (!memcmp(base->vendor_name, "VSOL", 16))
> > -
Hi,
On 1/7/21 11:36 AM, Rob Herring wrote:
On Thu, Jan 7, 2021 at 9:24 AM Jeremy Linton wrote:
Hi,
On 1/7/21 9:28 AM, Rob Herring wrote:
On Mon, Jan 4, 2021 at 9:57 PM Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config
Hello,
On 1/7/21 2:02 PM, Rob Herring wrote:
On Wed, Jan 6, 2021 at 10:35 PM Masahiro Yamada wrote:
On Wed, Jan 6, 2021 at 12:21 AM Rob Herring wrote:
On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar wrote:
Hello,
Here is an attempt to make some changes in the kernel to allow building
of
On Mon, Jan 04, 2021 at 08:58:23PM -0600, Mike Ximing Chen wrote:
> Introduce the dlb device ioctl layer and the first three ioctls: query
> device version, query available resources, and create a scheduling domain.
> Also introduce the user-space interface file dlb_user.h.
>
> The device version
On Mon, Jan 04, 2021 at 08:58:23PM -0600, Mike Ximing Chen wrote:
> Introduce the dlb device ioctl layer and the first three ioctls: query
> device version, query available resources, and create a scheduling domain.
> Also introduce the user-space interface file dlb_user.h.
>
> The device version
On Mon, Jan 04, 2021 at 08:58:22PM -0600, Mike Ximing Chen wrote:
> Introduce dlb_bitmap_* functions, a thin convenience layer wrapping the
> Linux bitmap interfaces, used by the bitmaps in the dlb hardware types.
No, you created custom #defines:
> --- a/drivers/misc/dlb/dlb_hw_types.h
> +++
05.01.2021 20:11, Krzysztof Kozlowski пишет:
> On Thu, Dec 17, 2020 at 09:05:50PM +0300, Dmitry Osipenko wrote:
>> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
>> power consumption and heating of the Tegra chips. Tegra SoC has multiple
>> hardware units which belong to
On Thu, Jan 7, 2021 at 11:15 AM Greg Kroah-Hartman
wrote:
>
> Linus, can you take this directly, or is this going through some other
> tree?
I was _assuming_ that I'd get it through the normal printk pull
request, it doesn't seem to be that timing-critical.
But if there is nothing else pending,
On Mon, Jan 04, 2021 at 08:58:20PM -0600, Mike Ximing Chen wrote:
> +static int dlb_probe(struct pci_dev *pdev,
> + const struct pci_device_id *pdev_id)
> +{
> + struct dlb *dlb;
> + int ret;
> +
> + dlb = devm_kzalloc(>dev, sizeof(*dlb), GFP_KERNEL);
> + if (!dlb)
On Thu, Jan 7, 2021 at 11:04 AM Al Viro wrote:
>
> BTW, changing 'event' field in place from another thread is going to
> be interesting - you have two 16bit values next to each other and
> two CPUs modifying those with no exclusion. Sounds like a recipe
> for massive trouble...
It's perfectly
On Thu, Jan 7, 2021 at 12:09 PM Saravana Kannan wrote:
>
> On Thu, Jan 7, 2021 at 10:39 AM Rob Herring wrote:
> >
> > On Wed, Jan 6, 2021 at 11:53 AM Saravana Kannan
> > wrote:
> > >
> > > On Sat, Jan 2, 2021 at 3:37 AM Marc Zyngier wrote:
> > > >
> > > > On Thu, 31 Dec 2020 21:12:40 +,
>
03.11.2020 06:57, Yejune Deng пишет:
> devm_reset_control_array_get_optional_shared() looks more readable
>
> Signed-off-by: Yejune Deng
> ---
> drivers/usb/dwc3/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>
03.11.2020 12:25, Yejune Deng пишет:
> of_reset_control_array_get_optional_exclusive() looks more readable
>
> Signed-off-by: Yejune Deng
> ---
> drivers/usb/dwc3/dwc3-of-simple.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
>
5fdc7db644 ("module: setup load info before module_sig_check()")
moved the ELF setup, so that it was done before the signature
check. This made the module name available to signature error
messages.
However, the checks for ELF correctness in setup_load_info
are not sufficient to prevent bad
On Thu, Jan 7, 2021 at 3:44 AM wrote:
>
> Hi Atish,
>
> On 12/4/20 8:58 AM, Atish Patra wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Add initial DTS for Microchip ICICLE board having only
> > essential devices (clocks, sdhci,
On Thu, Jan 7, 2021 at 3:40 AM wrote:
>
> Hi Atish,
>
> On 12/4/20 8:58 AM, Atish Patra wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > Add Microchip PolarFire kconfig option which selects SoC specific
> > and common drivers that
On Thu, Jan 07, 2021, Ashish Kalra wrote:
> On Thu, Jan 07, 2021 at 09:26:25AM -0800, Sean Christopherson wrote:
> > On Thu, Jan 07, 2021, Ashish Kalra wrote:
> > > Hello Steve,
> > >
> > > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > > > Avoiding an rbtree for such a
On Thu, Jan 07, 2021 at 10:16:50PM +0300, Dmitry Osipenko wrote:
> 03.11.2020 06:57, Yejune Deng пишет:
> > devm_reset_control_array_get_optional_shared() looks more readable
> >
> > Signed-off-by: Yejune Deng
> > ---
> > drivers/usb/dwc3/core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1
Hi,
On 1/7/21 12:14 PM, Will Deacon wrote:
On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply a firmware abstraction. The ARM PCI SMMCCC spec
On Thursday 07 January 2021 17:40:06 Russell King - ARM Linux admin wrote:
> On Thu, Jan 07, 2021 at 06:19:23PM +0100, Andrew Lunn wrote:
> > Did we loose the comment:
> >
> > /* Some modules (Nokia 3FE46541AA) lock up if byte 0x51 is read as a
> > * single read. Switch back to reading 16 byte
On Thu, Jan 7, 2021 at 6:25 PM Vincenzo Frascino
wrote:
>
> Hi Andrey,
>
> On 1/7/21 4:29 PM, Andrey Konovalov wrote:
> > On Wed, Jan 6, 2021 at 12:56 PM Vincenzo Frascino
> > wrote:
> >>
> >> MTE provides an asynchronous mode for detecting tag exceptions. In
> >> particular instead of
On Thursday 07 January 2021 18:19:23 Andrew Lunn wrote:
> > + if (sfp->i2c_block_size < 2) {
> > + dev_info(sfp->dev, "skipping hwmon device registration "
> > + "due to broken EEPROM\n");
> > + dev_info(sfp->dev, "diagnostic EEPROM area cannot be
03.11.2020 06:57, Yejune Deng пишет:
> devm_reset_control_array_get_optional_shared() looks more readable
>
> Signed-off-by: Yejune Deng
> ---
> drivers/usb/dwc3/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>
On Thu, Jan 07, 2021 at 05:44:00PM +0100, Petr Mladek wrote:
> This reverts commit 757055ae8dedf5333af17b3b5b4b70ba9bc9da4e.
>
> The commit caused that ttynull was used as the default console
> on many systems. It happened when there was no console configured
> on the command line and
kmod 28 is out:
https://www.kernel.org/pub/linux/utils/kernel/kmod/kmod-28.tar.xz
https://www.kernel.org/pub/linux/utils/kernel/kmod/kmod-28.tar.sign
- Improvements
- Add Zstandard to the supported compression formats using libzstd
(pass --with-zstd to
On Thu, Jan 07, 2021, Paolo Bonzini wrote:
> On 07/01/21 18:00, Sean Christopherson wrote:
> > Ugh, I assume this is due to one of the "premature"
> > nested_ops->check_events()
> > calls that are necessitated by the event mess? I'm guessing
> > kvm_vcpu_running()
> > is the culprit?
> >
> >
On 1/7/21 4:34 AM, Miaohe Lin wrote:
> The huge page size is encoded for VM_FAULT_HWPOISON errors only. So if we
> return VM_FAULT_HWPOISON, huge page size would just be ignored.
>
> Fixes: aa50d3a7aa81 ("Encode huge page size for VM_FAULT_HWPOISON errors")
> Signed-off-by: Miaohe Lin
> Cc:
>
On Thu, Jan 7, 2021 at 10:39 AM Rob Herring wrote:
>
> On Wed, Jan 6, 2021 at 11:53 AM Saravana Kannan wrote:
> >
> > On Sat, Jan 2, 2021 at 3:37 AM Marc Zyngier wrote:
> > >
> > > On Thu, 31 Dec 2020 21:12:40 +,
> > > Rob Herring wrote:
> > > >
> > > > On Mon, Dec 21, 2020 at 09:30:45AM
On Thu, Dec 17, 2020 at 10:31:25AM +0100, Juergen Gross wrote:
> Instead of only supporting to modify instructions when a specific
> feature is set, support doing so for the case a feature is not set.
>
> As today a feature is specified using a 16 bit quantity and the highest
> feature number in
Hi Paul,
Happy to see this patch. It was on my TODO list,
but I hadn't had time to bringup my rk3326 device.
A few comments.
On Thu, 2021-01-07 at 14:41 +0100, Paul Kocialkowski wrote:
> The PX30 SoC includes both the VDPU2 and VEPU2 blocks which are similar
> to the RK3399 (Hantro G1/H1 with
On Thu, Jan 07, 2021 at 10:47:07AM -0800, Linus Torvalds wrote:
> Now, the "whole entry" is just 8 bytes, so it's possible that it would
> actually be faster to do a copy of the whole thing rather than write
> just the 16 bits. But I got very nervous about it, because I could
> easily see some
This feature allows userspace to intercept "minor" faults. By "minor"
fault, I mean the following situation:
Let there exist two mappings (i.e., VMAs) to the same page(s) (shared
memory). One of the mappings is registered with userfaultfd (in minor
mode), and the other is not. Via the non-UFFD
This ioctl is how userspace ought to resolve "minor" userfaults. The
idea is, userspace is notified that a minor fault has occurred. It might
change the contents of the page using its second non-UFFD mapping, or
not. Then, it calls UFFDIO_CONTINUE to tell the kernel "I have ensured
the page
On 20-12-08 16:24:11, Ben Widawsky wrote:
[snip]
> +static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm,
> + struct mbox_cmd *mbox_cmd)
> +{
> + u64 cmd, status;
> + size_t out_len;
> + int rc;
> +
> + lockdep_assert_held(>mbox_lock);
> +
> + /*
Overview
This series adds a new userfaultfd registration mode,
UFFDIO_REGISTER_MODE_MINOR. This allows userspace to intercept "minor" faults.
By "minor" fault, I mean the following situation:
Let there exist two mappings (i.e., VMAs) to the same page(s) (shared memory).
One of the
On Wed, Jan 6, 2021 at 10:35 PM Masahiro Yamada wrote:
>
> On Wed, Jan 6, 2021 at 12:21 AM Rob Herring wrote:
> >
> > On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar wrote:
> > >
> > > Hello,
> > >
> > > Here is an attempt to make some changes in the kernel to allow building
> > > of device tree
On Thu, 7 Jan 2021, Matthew Wilcox wrote:
> On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote:
> > I'd like to ask about this piece of code in __kernel_read:
> > if (unlikely(!file->f_op->read_iter || file->f_op->read))
> > return warn_unsupported...
> > and
On Thu, Jan 07, 2021 at 10:47:07AM -0800, Linus Torvalds wrote:
> On Thu, Jan 7, 2021 at 10:34 AM Al Viro wrote:
> >
> > I'm not sure it's the best approach, TBH. How about simply
> > for (walk = head; walk; ufds += walk->len, walk = walk->next) {
> > if
On Thu, 7 Jan 2021 09:12:25 -0800
Tony Luck wrote:
> Steven,
Hi Tony,
>
> I've been remiss about updating the mce_record trace as new fields
> have been added to "struct mce". What are the ABI implications of a
> patch like the one below (sample only ... there are a couple more fields
> that
On Tue, Jan 05, 2021 at 03:14:11PM +1300, Barry Song wrote:
> Many drivers don't want interrupts enabled automatically due to
> request_irq(). So they are handling this issue by either way of
> the below two:
> (1)
> irq_set_status_flags(irq, IRQ_NOAUTOEN);
> request_irq(dev, irq...);
> (2)
>
On Thu, Jan 07, 2021 at 06:40:58PM +, Al Viro wrote:
> do_sys_poll(): do the wholesale copyout
>
> Don't bother with patching up just one field - 16 bits out of each 64.
> The amount of memory traffic is not going to be greater (might be
> smaller, actually) and the loop in copy_to_user() is
This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as
R_X86_64_PC32"), but for i386. As far as Linux kernel is concerned,
R_386_PLT32 can be treated the same as R_386_PC32.
R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the
requirement that the symbol address is
On 01/07, Can Guo wrote:
> On 2021-01-07 16:46, Jaegeuk Kim wrote:
> > On 01/07, Can Guo wrote:
> > > On 2021-01-07 16:07, Jaegeuk Kim wrote:
> > > > On 01/07, Can Guo wrote:
> > > > > On 2021-01-07 15:47, Jaegeuk Kim wrote:
> > > > > > From: Jaegeuk Kim
> > > > > >
> > > > > > This fixes a
On Thu, Jan 07, 2021 at 08:53:15AM +0100, Stephan Mueller wrote:
> >
> > > RFC5869
> > > allows two optional parameters to be provided to the extract operation:
> > > the salt and additional information. Both are to be provided with the
> > > seed parameter where the salt is the first entry of
From: Jaegeuk Kim
When non-fatal error like line-reset happens, ufshcd_err_handler() starts to
abort tasks by ufshcd_try_to_abort_task(). When it tries to issue tm request,
we've hit two warnings.
WARNING: CPU: 7 PID: 7 at block/blk-core.c:630 blk_get_request+0x68/0x70
WARNING: CPU: 4 PID: 157
Change log from v4:
- remove RESERVE tag for tm command
- remove waiting IOs and let full reset handle it
- avoid verbose error log which causes cpu lock up
When gate_work/ungate_work gets an error during hibern8_enter or exit,
ufshcd_err_handler()
ufshcd_scsi_block_requests()
ufshcd_reset_and_restore()
ufshcd_clear_ua_wluns() -> stuck
ufshcd_scsi_unblock_requests()
In order to avoid it, ufshcd_clear_ua_wluns() can be called per
On Thu, Jan 07, 2021 at 08:49:52AM +0100, Stephan Mueller wrote:
> > > -int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
> > > +int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, u8 *master_key,
> > > unsigned int master_key_size);
> >
> > It shouldn't be
/pci.git next
config: x86_64-randconfig-a005-20210107 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5c951623bc8965fa1e89660f2f5f4a2944e4981a)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
On Thu, Jan 7, 2021 at 10:34 AM Al Viro wrote:
>
> I'm not sure it's the best approach, TBH. How about simply
> for (walk = head; walk; ufds += walk->len, walk = walk->next) {
> if (copy_to_user(ufds, walk->entries,
> walk->len *
Hi,
These three patches clean up intel_pstate a bit:
[1/3] makes it always use READ_ONCE() for reading hwp_cap_cached
[2/3] changes the first argument of intel_pstate_get_hwp_max()
[3/3] renames to functions (to avoid possible confusion).
Please see patch changelogs for details.
Thanks!
From: Rafael J. Wysocki
Rename intel_cpufreq_adjust_hwp() and intel_cpufreq_adjust_perf_ctl()
to intel_cpufreq_hwp_update() and intel_cpufreq_perf_ctl_update(),
respectively, to avoid possible confusion with the ->adjist_perf()
callback function, intel_cpufreq_adjust_perf().
Signed-off-by:
From: Rafael J. Wysocki
All of the callers of intel_pstate_get_hwp_max() access the struct
cpudata object that corresponds to the given CPU already and the
function itself needs to access that object (in order to update
hwp_cap_cached), so modify the code to pass a struct cpudata pointer
to it
From: Rafael J. Wysocki
Because intel_pstate_get_hwp_max() which updates hwp_cap_cached
may run in parallel with the readers of it, annotate all of the
read accesses to it with READ_ONCE().
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/intel_pstate.c | 13 +++--
1 file
Capitalize subject to match the rest of the series.
"Add support to handle .." is redundant; "Add support for ..." would
be equivalent and shorter.
But this patch actually doesn't add anything at all by itself, since
it checks pci->phy_zrxdc_compliant but never sets it.
On Thu, Jan 07, 2021 at
On Thu, Jan 07, 2021 at 09:26:25AM -0800, Sean Christopherson wrote:
> On Thu, Jan 07, 2021, Ashish Kalra wrote:
> > Hello Steve,
> >
> > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > > Avoiding an rbtree for such a small (but unstable) list seems correct.
> > >
> > > For
> On Jan 7, 2021, at 17:41, Liu, Jing2 wrote:
>
> static void kvm_save_current_fpu(struct fpu *fpu) {
> + struct fpu *src_fpu = >thread.fpu;
> +
> /*
>* If the target FPU state is not resident in the CPU registers, just
>* memcpy() from current, else save CPU state
On Thu, Jan 07, 2021 at 06:33:58PM +, Al Viro wrote:
> On Thu, Jan 07, 2021 at 09:43:54AM -0800, Linus Torvalds wrote:
>
> > Before, it would do the whole CLAC/STAC dance inside that loop for
> > every entry (and with that commit d55564cfc22 it would be a function
> > call, of course).
> >
>
On Wed, Jan 6, 2021 at 11:53 AM Saravana Kannan wrote:
>
> On Sat, Jan 2, 2021 at 3:37 AM Marc Zyngier wrote:
> >
> > On Thu, 31 Dec 2020 21:12:40 +,
> > Rob Herring wrote:
> > >
> > > On Mon, Dec 21, 2020 at 09:30:45AM +, Marc Zyngier wrote:
> > > > On 2020-12-18 21:07, Saravana Kannan
401 - 500 of 1274 matches
Mail list logo
