On Sat, 2020-11-21 at 14:03 -0800, Jakub Kicinski wrote:
> Applied to net with the typo fixed, thanks!
Thanks!
Is there any chance it'll be in 5.10 or will it have to wait for the 5.11
merge window?
Also it should be applied to all supported/stable kernels. I guess that'll
have to wait until it'
On Fri, 2020-11-20 at 12:15 +0300, Sergei Shtylyov wrote:
> > Investigation on the matter shows that UDP and ICMP traffic from the
> ^ "no" missing?
Yes indeed. Thanks and sorry for the typo.
Regards,
--
Yves-Alexis
t.
Tested-by: Matti Vuorela
Signed-off-by: Yves-Alexis Perez
Link:
https://lore.kernel.org/linux-usb/caan0qaxmysj9vx3zemkviv_b19ju-_exn8yn_usefxpjs6g...@mail.gmail.com/
Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038
Cc: sta...@vger.kernel.org
---
drivers/net/usb/ipheth.c
On Tue, 2019-01-01 at 13:33 +0100, Yves-Alexis Perez wrote:
> Hi,
>
> with the upgrade to 4.19 in Debian sid, I experienced a regression with CIFS
> filesystems.
>
> The server is running Debian stretch with samba, the clients are running
> Debian sid or stretch. With 4.18
Hi,
with the upgrade to 4.19 in Debian sid, I experienced a regression with CIFS
filesystems.
The server is running Debian stretch with samba, the clients are running
Debian sid or stretch. With 4.18 kernels everything is fine, but with 4.19
while the mount succeeds, any read() syscall on a file
On Thu, 2018-02-22 at 13:02 +0100, Yves-Alexis Perez wrote:
> On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> > Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> > files there say?
>
> Unfortunately I don't have access to a power
On Fri, 2018-02-23 at 00:16 +1100, Michael Ellerman wrote:
> With the patches I just sent, for pseries and powernv, the mitigation
> should be in place. On machines with updated firmware we'll use the
> hardware-assisted L1 flush, otherwise we fallback to doing it in
> software.
So as of 4.9.82 me
On Thu, 2018-02-22 at 12:08 +0100, Greg Kroah-Hartman wrote:
> Did you look at /sys/devices/system/cpu/vulnerabilities/ to see what the
> files there say?
Unfortunately I don't have access to a powerpc box where I could run a new
kernel and try it on. I'll check with our ppc porters and see if I c
On Thu, 2018-02-22 at 12:01 +1100, Michael Ellerman wrote:
> So I guess this patch is OK for now, but we do need a full back port of
> 222f20f to 4.9.
Hi,
in the light of this, do you know the full status of protections against
Meltdown on powerpc/ppc64el architecures on 4.9?
Regards,
--
Yves-A
On Tue, 2018-02-20 at 14:25 -0800, Jacob Pan wrote:
> I didn't know about chipsec but reading the code seems to rely on an
> out-of-tree kernel module. I don't think it matches what we need here.
Yes good indeed, I had forgot about that. Maybe the userland part is still
useful, but there's definit
On Tue, 2018-02-13 at 13:40 -0800, Raj, Ashok wrote:
> This version has only hw dumps for now, but we plan to add some other things
> like walking 2nd level page-tables, or get some SVM specific data from the
> driver in the future.
Hi,
I'm not sure how much you know about chipsec [1], but with
On Sat, 2018-02-17 at 09:35 -0800, Guenter Roeck wrote:
> Hmm, that chunk really doesn't do what the original patch is supposed to do,
> meaning it won't provide the vulnerability protection it is supposed to
> provide
> (AFAICS that is Meltdown). Just a note in case anyone is concerned about
> ac
On Tue, 2018-02-13 at 16:29 +0100, Greg Kroah-Hartman wrote:
> > arch/powerpc/kernel/entry_64.S: Assembler messages:
> > arch/powerpc/kernel/entry_64.S:260: Error: unrecognized opcode:
> > `rfi_to_user'
> > arch/powerpc/kernel/entry_64.S:270: Error: unrecognized opcode:
> > `rfi_to_kernel'
> > ar
On Wed, 2018-02-07 at 20:46 +0100, Yves-Alexis Perez wrote:
> Maybe. I tried with removing the MTU setting, and I get (on ping again)
>
> févr. 07 20:44:01 scapa kernel: mtu: 1266
>
> which means I would get -EINVAL on standards kernels, which is not really good
> eithe
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez
>
> Hi Yves-Alexis -
>
> I apologize for the problem. It seems to me that tunneling with an
> outer MTU that causes the inner MTU to be smaller than the min, is
> po
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
> I'll try to printk the mtu before returning EINVAL to see why it's lower than
> 1280, but maybe the IP encapsulation is not correctly handled?
I did:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
in
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote:
> Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
> to an IPv6 address I get:
>
> ping: sendmsg: Invalid argument
I forgot an important bit of information: due to the way routers usually broke
path M
Hi Mike,
I noticed a regression in 4.14.16 stable kernel (I assume it's also
present in mainline).
I'm using an IPsec setup where I tunnel all my IP trafic to a gateway.
The tunnel can use either IPv6 or IPv4 (depending on what's available
locally) and will route both IPv4 and IPv6 (my gateway wi
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> We don't refuse to load the affected microcodes; just refuse to use SPEC_CTRL
> if they're detected.
Hi David,
Are we sure those microcodes instability are only related to SPEC_CTRL?
Regards,
--
Yves-Alexis
signature.asc
Description:
On Wed, 2018-01-24 at 16:57 +, David Woodhouse wrote:
> Some old Atoms, anything in family 5 or 4, and newer CPUs when they advertise
> the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO bit set, are not
> vulnerable.
>
> Roll the AMD exemption into the x86_match_cpu() table too.
>
> Base
On Mon, 2018-01-08 at 19:26 +0100, Willy Tarreau wrote:
> You're totally right, I discovered during my later developments that
> indeed PCID is not exposed there. So we take the hit of a full TLB
> flush twice per syscall.
So I really think it might make sense to redo the tests with PCID, because
On Mon, 2018-01-08 at 18:07 +0100, Yves-Alexis Perez wrote:
> On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> > - the highest performance impact on VMs comes from having PTI on the
> > guest kernel (-45%). At this point it makes no difference whether
> > t
On Sun, 2018-01-07 at 11:18 +0100, Willy Tarreau wrote:
> - the highest performance impact on VMs comes from having PTI on the
> guest kernel (-45%). At this point it makes no difference whether
> the host kernel has it or not.
Hi Willy,
out of curiosity, is the pcid/invpcid flags expos
On Fri, 2018-01-05 at 15:26 +0100, Paolo Bonzini wrote:
> Those from November seem way too early to include IBRS/IBPB. Maybe the
> two from December 3rd, but I wouldn't be 100% sure.
So, for my CPU with updated microcode:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
mod
On Fri, 2018-01-05 at 14:28 +0100, Greg KH wrote:
> > iucode-tool -L -tr n10ur16w.iso |grep 2017-11
> >001/020: sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size
> > 18432
>
> That's been out for a while now:
> https://downloadcenter.intel.com/download/27337/Linux-Processor-Mi
On Thu, 2018-01-04 at 11:10 -0800, Tim Chen wrote:
> > Are there plans to make the corresponding microcode support available?
> >
>
> The microcode patches should be released soon.
In the meantime, Lenovo has started issuing BIOS/UEFI updates which include
microcode updates for this.
See for ex
On Thu, 2018-01-04 at 09:56 -0800, Tim Chen wrote:
> @@ -44,6 +47,7 @@ static inline void apm_bios_call_asm(u32 func, u32 ebx_in,
> u32 ecx_in,
> "=S" (*esi)
> : "a" (func), "b" (ebx_in), "c" (ecx_in)
> : "memory", "cc");
> + unprotected_formw
Regards,
>
> --
>
> From: Yves-Alexis Perez
>
> commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.
>
> When you use the firmware usermode helper fallback with a timeout value set
> to a
> value greater than INT_MAX (2147483647) a cast overflow issue causes
riable and only set retval in specific
cases.
Signed-off-by: Yves-Alexis Perez
Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()"
Cc: Luis R. Rodriguez
Cc: Ming Lei
Cc: Bjorn Andersson
Cc: Greg Kroah-Hartman
Cc: sta...@vger.ke
On Thu, 2016-11-10 at 11:48 -0800, Luis R. Rodriguez wrote:
> > I haven't verified that this particular use case actually worked before,
> > but this code works with lower timeout values (e.g. 60 in the fallback
> > case), so this looks isolated.
>
> This is true, but as I noted the broken aspect
On Wed, 2016-11-09 at 23:02 +0100, Luis R. Rodriguez wrote:
> Actually... we also set the timeout to MAX_JIFFY_OFFSET when FW_OPT_UEVENT is
> not set. This happens *only* when the UMH was explicitly requested on the
> async call, when the second argument to request_firmware_nowait() is false.
> The
On Sun, 2016-10-30 at 15:50 +0100, Yves-Alexis Perez wrote:
> wait_for_completion_interruptible_timeout() return value is either
> -ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
> or the number of jiffies left until timeout. The return value is stored in
>
From: Yves-Alexis Perez
wait_for_completion_interruptible_timeout() return value is either
-ERESTARTSYS (in case it was interrupted), 0 (in case the timeout expired)
or the number of jiffies left until timeout. The return value is stored in
a long, but in _request_firmware_load() it's sil
Hi,
when trying to (ab)use the firmware loading interface in a local kernel module
(in order to load the EEPROM content into a PCIE card), I noticed that the
manual firmware loading interface (the one from
/sys/class/firmware//{loading,data}) was broken.
After instrumenting the kernel I noticed a
On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote:
> > This security feature reduces the predictability of
> > the kernel slab allocator against heap overflows.
>
> I would add "... rendering attacks much less stable." And if you can
> find a specific example exploit that is foiled by this, I wo
On mer., 2016-04-06 at 12:02 -0700, Linus Torvalds wrote:
> So yeah, maybe swap partitions are still more common than I thought.
> And I didn't even consider the possibility that people would hibernate
> a desktop like you do.
To be fair, it's *my* use case, because suspend won't work but I'm lazy
On mer., 2016-04-06 at 11:43 -0700, Linus Torvalds wrote:
> Hibernation is really quite nasty when you have to have a fairly big
> special partition for it, and shrink your memory down. Writing things
> to disk was a whole lot more reasonable back in the days when laptops
> had 16MB of memory.
Act
On dim., 2015-10-18 at 20:41 -0500, Serge E. Hallyn wrote:
> We shouldn't need a long-term solution. Your concern is bugs. After
> some time surely we'll feel that we have achieved a stable solution?
But this is actually the whole point: we need a long term solution, because
they will always be
On jeu., 2015-05-14 at 14:35 +0200, Yves-Alexis Perez wrote:
> +# Generate a change file
> +(cd $KBUILD_OUTPUT; dpkg-genchanges -b >
> ../linux_${packageversion}_${debarch}.changes)
> +
Actually cwd during the build is KBUILD_OUTPUT already, so the cd part
is unnecessary (I can
A changes file (also called Debian upload control file) contains
information about binary packages, including the changelog entry, the
maintainer, the package list and the checksums.
It can be used by various Debian tools like dput and dcmd to execute
action on all the build packages at once, for
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
> At Sat, 11 Apr 2015 09:31:35 +0200,
> Yves-Alexis Perez wrote:
> >
> > This model uses the same dock port as the previous generation.
> >
> > Signed-off-by: Yves-Alexis Perez
>
> Thanks, applied w
On sam., 2015-04-11 at 17:27 +0200, Takashi Iwai wrote:
> At Sat, 11 Apr 2015 09:31:35 +0200,
> Yves-Alexis Perez wrote:
> >
> > This model uses the same dock port as the previous generation.
> >
> > Signed-off-by: Yves-Alexis Perez
>
> Thanks, applied w
On sam., 2015-04-11 at 11:40 +0200, Toralf Förster wrote:
> Hi,
>
> /me wonders why you didn't add the new line directly under "Thinkpad X240" :
>
> SND_PCI_QUIRK(0x17aa, 0x2214, "Thinkpad X240",
> ALC292_FIXUP_TPT440_DOCK),
> SND_PCI_QUIRK(0x17aa, 0x2215, "Thinkpad",
> ALC269_FIXUP
I'm unsure how the ALSA
maintainers stand on this, but similar previous patches have been targeted to
stable so it might be worth adding it.
Regards,
--
Yves-Alexis Perez
Yves-Alexis Perez (1):
ALSA: hda - Add dock support for ThinkPad X250 (17aa:2226)
sound/pci/hda/patch_realtek.c | 1 +
This model uses the same dock port as the previous generation.
Signed-off-by: Yves-Alexis Perez
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 7438213..2087728 100644
--- a/sound/pci/hda
On jeu., 2015-03-19 at 11:58 -0400, Benjamin Tissoires wrote:
> >
> > Am I right? Thanks for the information, I'll also try to point our
> > kernel maintainers to that thread and ask them if it's possible to
> > backport them to the 3.16 kernel for Jessie.
>
> Yes, please do. For the record, they
On Thu, Mar 19, 2015 at 01:06:49PM -0400, Benjamin Tissoires wrote:
> To solve your problem, your desktop environment must have a "disable
> touchpad" switch in the configuration panel. At least, gnome has. This
> way, your settings should come back at each login.
> And if this is not sufficient en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 11:58:31AM -0400, Benjamin Tissoires wrote:
> On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
> > Am I right? Thanks for the information, I'll also try to point our
> > kernel maintainers to that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Mar 19, 2015 at 10:46:27AM -0400, Benjamin Tissoires wrote:
> On Mar 19 2015 or thereabouts, Yves-Alexis Perez wrote:
> > So I have two questions/remarks about this:
> >
> > - if I don't use the touchpad, do I ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, Feb 06, 2015 at 03:04:28PM -0500, Benjamin Tissoires wrote:
> Hi,
>
> This is the second episode of the Lenovo 2015 party :)
>
> Thanks to Andrew, we now have an idea within the driver of what are the extra
> buttons aimed for, and the patc
On sam., 2013-10-12 at 00:10 +0200, Rafael J. Wysocki wrote:
> On Friday, October 11, 2013 12:42:43 PM Josh Boyer wrote:
> > On Fri, Oct 11, 2013 at 9:27 AM, Aaron Lu wrote:
> > > v5:
> > > 1 Introduce video.use_native_backlight module parameter and set its
> > > value to false by default as sug
On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote:
> If we are to use a Kconfig option, why don't we use one instead of rather than
> in addition to a command line option? Say, we have
> CONFIG_ACPI_VIDEO_WIN8_WORKAROUND and if that is set, the code will work like
> the previous version
On ven., 2013-09-27 at 15:05 -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 27 Sep 2013, Yves-Alexis Perez wrote:
> > On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > > Some testing on a *60 (T60,X60...) would also be best, I cannot test
> >
On ven., 2013-09-27 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> Some testing on a *60 (T60,X60...) would also be best, I cannot test
> this on
> my T43.
>
> Anyway, the code itself looks fine, so:
I can test on T61, would that help?
Regards,
--
Yves-Alexis
signature.asc
Description:
from previous work done by Matthew Garrett,
> Chun-Yi Lee, Seth Forshee and Rafael J. Wysocki.
>
> Signed-off-by: Aaron Lu
Tested-by: Yves-Alexis Perez
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
unctionality without affecting the other one.
>
> APIs to selectively remove backlight control interface and/or event
> delivery functionality can be easily added once needed.
>
> Signed-off-by: Aaron Lu
Tested-by: Yves-Alexis Perez
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
. the interface created by i915) is available and then do
> things accordingly(e.g. avoid register its own on Win8 systems).
>
> Signed-off-by: Aaron Lu
Tested-by: Yves-Alexis Perez
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
On mar., 2013-09-17 at 17:23 +0800, Aaron Lu wrote:
> v1 has the subject of "Rework ACPI video driver" and is posted here:
> http://lkml.org/lkml/2013/9/9/74
> Since the objective is really to fix Win8 backlight issues, I changed
> the subject in this version, sorry about that.
>
> This patchset h
On mer., 2013-09-11 at 08:45 +, Matthew Garrett wrote:
> On Wed, 2013-09-11 at 11:45 +0300, Jani Nikula wrote:
>
> > Before plunging forward, have you observed any difference between the
> > boot modes? We have reports [1] that the backlight behaviour is
> > different with UEFI vs. UEFI+CSM or
On mer., 2013-07-17 at 10:51 -0500, Felipe Contreras wrote:
> On Sat, Jun 22, 2013 at 4:46 PM, Yves-Alexis Perez wrote:
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys were handled by t
On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
> On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
> > On 07/01/2013 03:07 PM, Luca Barbato wrote:
> > > Hopefully I will carve some time next weekend to play the restricted
> > > bisect game.
>
On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
> On 07/01/2013 03:07 PM, Luca Barbato wrote:
> > Hopefully I will carve some time next weekend to play the restricted
> > bisect game.
>
> Release 3.10 apparently doesn't show the problem, I guess problem solved
> for me =)
>
> lu
>
I've j
On mar., 2013-06-25 at 22:33 +0100, Matthew Garrett wrote:
> > I was referring to “standardize the behaviour by leaving up to
> > userspace”. A lot of thinkpads (for example) (all the pre-windows 8
> > ones) have a perfectly working ACPI backlight interface.
>
> And this patchset won't alter their
On mar., 2013-06-25 at 22:14 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 11:10:11PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> > > I agree, we should standardise the behaviour. And the only way we can
>
On mar., 2013-06-25 at 21:54 +0100, Matthew Garrett wrote:
> On Tue, Jun 25, 2013 at 10:43:57PM +0200, Yves-Alexis Perez wrote:
> > On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> > > Right, the kernel has special-casing to hook the backlight keys up to
> &
On mar., 2013-06-25 at 17:08 +0100, Matthew Garrett wrote:
> On Sat, Jun 22, 2013 at 11:46:39PM +0200, Yves-Alexis Perez wrote:
>
> > Before Linux support for acpi_osi("Windows 2012") (and when booting with
> > acpi_osi="!Windows 2012"), brightness keys we
On dim., 2013-06-09 at 19:01 -0400, Matthew Garrett wrote:
> The first two patches in this series are picked from other patchesets aimed at
> solving similar problems. The last simply unregisters ACPI backlight control
> on Windows 8 systems when using an Intel GPU. Similar code could be added to
>
On lun., 2013-03-18 at 17:32 -0400, Matthew Garrett wrote:
> This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability
> indicates that a process is empowered to perform tasks that may result
> in
> modification of the running kernel. While aimed at handling the
> specific
> use-case of
On mer., 2013-03-06 at 21:30 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 04 Mar 2013, Borislav Petkov wrote:
> > I get this in dmesg with 3.9-rc1:
> >
> > [ 12.951434] thinkpad_acpi: unhandled HKEY event 0x6050
> > [ 12.951438] thinkpad_acpi: please report the conditions when this
> ev
On lun., 2013-01-28 at 11:42 -0500, Matthew Garrett wrote:
> Secure boot makes it possible to ensure that the on-disk representation of
> the kernel hasn't been modified. This can be sidestepped if the in-memory
> representation can be trivially altered. We currently have a large number
> of interf
70 matches
Mail list logo
