Hi Olaf,
On Mon, Mar 29, 2021 at 06:37:21PM +0200, Olaf Hering wrote:
> On Thu, Dec 17, Andrea Parri (Microsoft) wrote:
>
> > Check that the packet is of the expected size at least, don't copy data
> > past the packet.
>
> > + if (hv_pkt_datalen(desc) < sizeof(struct vstor_packet) -
>
On Thu, Dec 17, Andrea Parri (Microsoft) wrote:
> Check that the packet is of the expected size at least, don't copy data
> past the packet.
> + if (hv_pkt_datalen(desc) < sizeof(struct vstor_packet) -
> + stor_device->vmscsi_size_delta) {
> +
On Sat, Feb 27, 2021 at 02:02:21AM +0300, Alexey Dobriyan wrote:
> There are rules and schemes about how to create guard macro.
>
> Should it be prefixed by underscore?
> Should it be prefixed by two underscores?
> Should it be full path uppercased or just last path component?
> Should the guard
From: Alexey Dobriyan
> Sent: 26 February 2021 23:02
>
> On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan
> > wrote:
> > >
> > > I want to sent treewide "#pragma once" conversion:
> >
> > Are there *any* advantages to it?
> >
On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan wrote:
> >
> > I want to sent treewide "#pragma once" conversion:
>
> Are there *any* advantages to it?
>
> It's non-standard,
It is effectively standard:
On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan wrote:
>
> I want to sent treewide "#pragma once" conversion:
Are there *any* advantages to it?
It's non-standard, and the historical argument for it ("it can reduce
compile times because the preprocessor doesn't open the file twice" is
pure and
Linus wrote:
> I'm hoping to just do -rc1 this weekend after all - despite my late
> start due to loss of power for several days.
>
> I'll allow late stragglers with good reason through, but the fewer of
> those there are, the better, of course.
I want to sent treewide "#pragma once"
On Thu, 17 Dec 2020 21:33:18 +0100, Andrea Parri (Microsoft) wrote:
> This series is to address the problems mentioned in:
>
> 4da3a54f5a0258 ("Revert "scsi: storvsc: Validate length of incoming packet
> in storvsc_on_channel_callback()"")
>
> (cf
Andrea,
> This series is to address the problems mentioned in:
>
> 4da3a54f5a0258 ("Revert "scsi: storvsc: Validate length of incoming packet
> in storvsc_on_channel_callback()"")
>
> (cf., in particular, patch 2/3) and to re-introduce the validatio
From: Andrea Parri (Microsoft) Sent: Thursday,
December 17, 2020 12:33 PM
>
> Check that the packet is of the expected size at least, don't copy data
> past the packet.
>
> Reported-by: Saruhan Karademir
> Signed-off-by: Andrea Parri (Microsoft)
> Cc: "James E.J. Bottomley"
> Cc: "Martin K.
> From: Andrea Parri (Microsoft)
> Sent: Thursday, December 17, 2020 12:33 PM
>
> Check that the packet is of the expected size at least, don't copy data
> past the packet.
>
> Reported-by: Saruhan Karademir
> Signed-off-by: Andrea Parri (Microsoft)
> Cc: "James E.J. Bottomley"
> Cc: "Martin
Check that the packet is of the expected size at least, don't copy data
past the packet.
Reported-by: Saruhan Karademir
Signed-off-by: Andrea Parri (Microsoft)
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/storvsc_drv.c | 6 ++
1 file
Hi all,
This series is to address the problems mentioned in:
4da3a54f5a0258 ("Revert "scsi: storvsc: Validate length of incoming packet in
storvsc_on_channel_callback()"")
(cf., in particular, patch 2/3) and to re-introduce the validation in
question (patch 3/3); pa
On Mon, Dec 14, 2020 at 08:06:25AM -0500, Konstantin Ryabitsev wrote:
On Mon, Dec 14, 2020 at 02:07:11PM +0300, Dan Carpenter wrote:
On Sat, Dec 12, 2020 at 07:09:01PM +0100, Andrea Parri wrote:
> Hi Sasha,
>
> On Sat, Dec 12, 2020 at 11:07:56AM -0500, Sasha Levin wrote:
> > From: "Andrea Parri
On Mon, Dec 14, 2020 at 02:07:11PM +0300, Dan Carpenter wrote:
> On Sat, Dec 12, 2020 at 07:09:01PM +0100, Andrea Parri wrote:
> > Hi Sasha,
> >
> > On Sat, Dec 12, 2020 at 11:07:56AM -0500, Sasha Levin wrote:
> > > From: "Andrea Parri (Microsoft)"
> > >
> > > [ Upstream commit
On Sat, Dec 12, 2020 at 07:09:01PM +0100, Andrea Parri wrote:
> Hi Sasha,
>
> On Sat, Dec 12, 2020 at 11:07:56AM -0500, Sasha Levin wrote:
> > From: "Andrea Parri (Microsoft)"
> >
> > [ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
>
> FYI, we found that this commit introduced a
On Sat, Dec 12, 2020 at 07:09:01PM +0100, Andrea Parri wrote:
Hi Sasha,
On Sat, Dec 12, 2020 at 11:07:56AM -0500, Sasha Levin wrote:
From: "Andrea Parri (Microsoft)"
[ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
FYI, we found that this commit introduced a regression and
Hi Sasha,
On Sat, Dec 12, 2020 at 11:07:56AM -0500, Sasha Levin wrote:
> From: "Andrea Parri (Microsoft)"
>
> [ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
FYI, we found that this commit introduced a regression and posted a
revert:
From: "Andrea Parri (Microsoft)"
[ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
Check that the packet is of the expected size at least, don't copy data
past the packet.
Link: https://lore.kernel.org/r/20201118145348.109879-1-parri.and...@gmail.com
Cc: "James E.J. Bottomley"
Cc:
From: "Andrea Parri (Microsoft)"
[ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
Check that the packet is of the expected size at least, don't copy data
past the packet.
Link: https://lore.kernel.org/r/20201118145348.109879-1-parri.and...@gmail.com
Cc: "James E.J. Bottomley"
Cc:
From: "Andrea Parri (Microsoft)"
[ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
Check that the packet is of the expected size at least, don't copy data
past the packet.
Link: https://lore.kernel.org/r/20201118145348.109879-1-parri.and...@gmail.com
Cc: "James E.J. Bottomley"
Cc:
From: "Andrea Parri (Microsoft)"
[ Upstream commit 3b8c72d076c42bf27284cda7b2b2b522810686f8 ]
Check that the packet is of the expected size at least, don't copy data
past the packet.
Link: https://lore.kernel.org/r/20201118145348.109879-1-parri.and...@gmail.com
Cc: "James E.J. Bottomley"
Cc:
On Fri, Dec 11, 2020 at 09:59:34AM -0500, Martin K. Petersen wrote:
>
> Wei,
>
> > Sorry for the last minute patch. We would very like this goes into
> > 5.10 if possible; otherwise Linux 5.10 is going to be broken on
> > Hyper-V. :-(
>
> Applied to 5.10/scsi-fixes.
Thanks Martin.
Wei,
> Sorry for the last minute patch. We would very like this goes into
> 5.10 if possible; otherwise Linux 5.10 is going to be broken on
> Hyper-V. :-(
Applied to 5.10/scsi-fixes.
--
Martin K. Petersen Oracle Linux Engineering
On Fri, Dec 11, 2020 at 02:14:04PM +0100, Andrea Parri (Microsoft) wrote:
> This reverts commit 3b8c72d076c42bf27284cda7b2b2b522810686f8.
>
> Dexuan reported a regression where StorVSC fails to probe a device (and
> where, consequently, the VM may fail to boot). The root-cause analysis
> led to
This reverts commit 3b8c72d076c42bf27284cda7b2b2b522810686f8.
Dexuan reported a regression where StorVSC fails to probe a device (and
where, consequently, the VM may fail to boot). The root-cause analysis
led to a long-standing race condition that is exposed by the validation
/commit in
On 04/12/20 22:46, Ashish Kalra wrote:
I would prefer that userspace does this using KVM_SET_MSR instead.
Ok.
But, this is for a VM which has already been migrated based on feature
support on host and guest and host negotation and enablement of the live
migration support, so i am assuming
Hello Paolo,
On Fri, Dec 04, 2020 at 12:22:48PM +0100, Paolo Bonzini wrote:
> On 05/05/20 23:22, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > For source VM, live migration feature is enabled explicitly
> > when the guest is booting, for the i
On 05/05/20 23:22, Ashish Kalra wrote:
From: Ashish Kalra
For source VM, live migration feature is enabled explicitly
when the guest is booting, for the incoming VM(s) it is implied.
This is required for handling A->B->C->... VM migrations case.
Signed-off-by: Ashish Kalra
---
arc
On 05/05/20 23:22, Ashish Kalra wrote:
From: Ashish Kalra
For source VM, live migration feature is enabled explicitly
when the guest is booting, for the incoming VM(s) it is implied.
This is required for handling A->B->C->... VM migrations case.
Signed-off-by: Ashish Kalra
---
arc
On Wed, 18 Nov 2020 15:53:48 +0100, Andrea Parri (Microsoft) wrote:
> Check that the packet is of the expected size at least, don't copy
> data past the packet.
Applied to 5.10/scsi-fixes, thanks!
[1/1] scsi: storvsc: Validate length of incoming packet in
storvsc_on_channel_ca
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work() and
ieee80211_rx_list(). This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
Signed-off-by: Marco Elver
Reviewed-by: Johannes Berg
Check that the packet is of the expected size at least, don't copy
data past the packet.
Reported-by: Saruhan Karademir
Signed-off-by: Andrea Parri (Microsoft)
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-s...@vger.kernel.org
---
Based on hyperv-next.
face_work() and
> > > ieee80211_rx_list(). This will enable coverage-guided fuzzing of
> > > mac80211 code that processes incoming 802.11 frames.
> >
> > I have no idea how we'll get this merged - Jakub, do you want to take
> > the whole series? Or is somebody else r
uzzing of
> > mac80211 code that processes incoming 802.11 frames.
>
> I have no idea how we'll get this merged - Jakub, do you want to take
> the whole series? Or is somebody else responsible for the core kcov
> part?
Typically core kcov changes have been going via the -mm tree.
On Thu, 2020-10-29 at 17:36 +, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh
>
> Add KCOV remote annotations to ieee80211_iface_work() and
> ieee80211_rx_list(). This will enable coverage-guided fuzzing of
> mac80211 code that processes incoming 802.11 frames.
I have no
On Wed, Oct 28, 2020 at 10:25 PM Johannes Berg
wrote:
[...]
> Wouldn't it make more sense to push that a layer down
> into ieee80211_rx_napi(), or actually now perhaps even
> better ieee80211_rx_list(), so we get it even if the driver called that
> API in the first place?
>
> You might only care
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work() and
ieee80211_rx_list(). This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v4 -> v5:
* Using ieee80211_rx_list() inst
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v1 -> v2:
* The commit now affects ieee80211_rx inst
On Wed, 2020-10-28 at 18:20 +, Aleksandr Nogikh wrote:
> From: Aleksandr Nogikh
>
> Add KCOV remote annotations to ieee80211_iface_work and
> ieee80211_rx. This will enable coverage-guided fuzzing of
> mac80211 code that processes incoming 802.11 frames.
>
> Signed-off
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v1 -> v2:
* The commit now affects ieee80211_rx inst
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_rx. This will enable coverage-guided fuzzing of mac80211
code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
v2:
* The commit now affects ieee80211_rx instead
From: Aleksandr Nogikh
Add KCOV remote annotations to ieee80211_iface_work and
ieee80211_tasklet_handler. This will enable coverage-guided fuzzing of
mac80211 code that processes incoming 802.11 frames.
Signed-off-by: Aleksandr Nogikh
---
net/mac80211/iface.c | 2 ++
net/mac80211/main.c | 2
On Thu, 24 Sep 2020, Geliang Tang wrote:
This patch added the RM_ADDR option parsing logic:
We parsed the incoming options to find if the rm_addr option is received,
and called mptcp_pm_rm_addr_received to schedule PM work to a new status,
named MPTCP_PM_RM_ADDR_RECEIVED.
PM work got
This patch added the RM_ADDR option parsing logic:
We parsed the incoming options to find if the rm_addr option is received,
and called mptcp_pm_rm_addr_received to schedule PM work to a new status,
named MPTCP_PM_RM_ADDR_RECEIVED.
PM work got this status, and called mptcp_pm_nl_rm_addr_received
MICROSOFT URGENT NOTIFICATION MEMO
10 of your new incoming messages has been suspended from entry into your email
box account because your email box account has not been
verify<https://osas14.wixsite.com/mysite> for some months now. Do therefore
verify immediately so that all yo
MICROSOFT URGENT NOTIFICATION MEMO
10 of your new incoming messages has been suspended from entry into your email
box account because your email box account has not been verify for some months
now. Do therefore verify<https://alicedolan.wixsite.com/mysite> immediately so
that all yo
MICROSOFT NOTIFICATION MEMO
10 of your incoming messages has been suspended and your email box account will
be suspended also because your email box account has not been verified for
this year. do click on verify now below to verify your email box account
VERIFY<https://general3
From: David Howells
[ Upstream commit 2ad6691d988c0c611362ddc2aad89e0fb50e3261 ]
There's a race between the retransmission code and the received ACK parser.
The problem is that the retransmission loop has to drop the lock under
which it is iterating through the transmission buffer in order to
From: David Howells
[ Upstream commit 2ad6691d988c0c611362ddc2aad89e0fb50e3261 ]
There's a race between the retransmission code and the received ACK parser.
The problem is that the retransmission loop has to drop the lock under
which it is iterating through the transmission buffer in order to
From: David Howells
Date: Thu, 11 Jun 2020 21:57:00 +0100
> There's a race between the retransmission code and the received ACK parser.
> The problem is that the retransmission loop has to drop the lock under
> which it is iterating through the transmission buffer in order to transmit
> a
There's a race between the retransmission code and the received ACK parser.
The problem is that the retransmission loop has to drop the lock under
which it is iterating through the transmission buffer in order to transmit
a packet, but whilst the lock is dropped, the ACK parser can crank the Tx
On Tue, May 5, 2020 at 2:22 PM Ashish Kalra wrote:
>
> From: Ashish Kalra
>
> For source VM, live migration feature is enabled explicitly
> when the guest is booting, for the incoming VM(s) it is implied.
> This is required for handling A->B->C->... VM migrations case
MICROSOFT NOTIFICATION MEMO
10 of your incoming messages has been suspended and your email box account will
be suspended now because your email box account has not been verified for this
year. do click on verify now below to verify your email box account
<https://bility12.wixsite.com/mys
nterface clk_x clock cycles,
> controller should wait from read enable going low to sending
> out a strobe of clk_x for capturing of incoming data.
>
> Currently, acc_clks is calculated only based on tREA, the delay on the
> chip side. This does not include additional delays
From: Ashish Kalra
For source VM, live migration feature is enabled explicitly
when the guest is booting, for the incoming VM(s) it is implied.
This is required for handling A->B->C->... VM migrations case.
Signed-off-by: Ashish Kalra
---
arch/x86/kvm/svm/sev.c | 7 +++
1 file c
MICROSOFT URGENT NOTICE
20 of your incoming messages has been suspended because your email box account
needs to be verify now.Do click on the verify below to verify your email box
account now.
VERIFY<http://de43e.000webhostapp.com/>
Microsoft Verification Team
Copyright © 2019 Mic
From: Eric Dumazet
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls
From: Eric Dumazet
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls
From: Eric Dumazet
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls
From: Eric Dumazet
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls
From: Eric Dumazet
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls
From: Eric Dumazet
[ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls
MICROSOFT NOTIFICATION MEMO
15 of your incoming messages has been suspended because your email box account
needs to be verify now. Do Verify<http://bbg58.000webhostapp.com/> now to
release your messages
Microsoft Verification Team
Microsoft Webmail .Inc . © 2019
On 7/19/19 12:56 AM, Andrew Morton wrote:
>
> The rest of MM and a kernel-wide procfs cleanup.
>
>
>
> Summary of the more significant patches:
Thanks for that!
Perhaps now it would be nice if this went also to linux-mm and lkml, as
mm-commits is sort of hidden.
Vlastimil
On 7/17/19 6:13 PM, Linus Torvalds wrote:
> On Wed, Jul 17, 2019 at 1:47 AM Vlastimil Babka wrote:
>>
>> So I've tried now to provide an example what I had in mind, below.
>
> I'll take it as a trial. I added one-line notes about coda and the
> PTRACE_GET_SYSCALL_INFO interface too.
Thanks.
>
On Wed, Jul 17, 2019 at 09:13:26AM -0700, Linus Torvalds wrote:
> On Wed, Jul 17, 2019 at 1:47 AM Vlastimil Babka wrote:
> >
> > So I've tried now to provide an example what I had in mind, below.
>
> I'll take it as a trial. I added one-line notes about coda and the
> PTRACE_GET_SYSCALL_INFO
On Wed, Jul 17, 2019 at 1:47 AM Vlastimil Babka wrote:
>
> So I've tried now to provide an example what I had in mind, below.
I'll take it as a trial. I added one-line notes about coda and the
PTRACE_GET_SYSCALL_INFO interface too.
I do hope that eventually I'll just get pull requests, and
Cool !!
On 10:47 Wed 17 Jul , Vlastimil Babka wrote:
On 7/17/19 1:25 AM, Andrew Morton wrote:
Most of the rest of MM and just about all of the rest of everything
else.
Hi,
as I've mentioned at LSF/MM [1], I think it would be nice if mm pull
requests had summaries similar to other
On 7/17/19 1:25 AM, Andrew Morton wrote:
>
> Most of the rest of MM and just about all of the rest of everything
> else.
Hi,
as I've mentioned at LSF/MM [1], I think it would be nice if mm pull
requests had summaries similar to other subsystems. I see they are now
more structured (thanks!), but
MICROSOFT VERIFICATION NEEDED
A lot of your incoming messages has been suspended because your email box
account is not verify by Microsoft verification team. In order to receive your
messages do verify<https://qwertyuiutyuiopiuy.wixsite.com/mysite> now, We
apologise for any inconve
[ Upstream commit 099e6cc1582dc2903fecb898bbeae8f7cf4262c7 ]
Currently incoming ARP Replies, for example via a DHT-PUT message, do
not update the timeout for an already existing DAT entry. These ARP
Replies are dropped instead.
This however defeats the purpose of the DHCPACK snooping
[ Upstream commit 099e6cc1582dc2903fecb898bbeae8f7cf4262c7 ]
Currently incoming ARP Replies, for example via a DHT-PUT message, do
not update the timeout for an already existing DAT entry. These ARP
Replies are dropped instead.
This however defeats the purpose of the DHCPACK snooping
[ Upstream commit 099e6cc1582dc2903fecb898bbeae8f7cf4262c7 ]
Currently incoming ARP Replies, for example via a DHT-PUT message, do
not update the timeout for an already existing DAT entry. These ARP
Replies are dropped instead.
This however defeats the purpose of the DHCPACK snooping
[ Upstream commit 099e6cc1582dc2903fecb898bbeae8f7cf4262c7 ]
Currently incoming ARP Replies, for example via a DHT-PUT message, do
not update the timeout for an already existing DAT entry. These ARP
Replies are dropped instead.
This however defeats the purpose of the DHCPACK snooping
MICROSOFT VERIFICATION NEEDED
A lot of your incoming messages has been suspended because your email box
account is not verify by Microsoft verification team. In order to receive your
messages do verify<https://vl.wixsite.com/mysite-1> now, We apologise for
any inconve
On 4/12/19 12:19 PM, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev
>
> This will limit the incoming pixels per frame from the sensor.
> Currently, the ISC will stop sampling the frame only when the vsync/hsync
> are detected.
> If we misconfigure the resolution i
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ]
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ]
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered
From: Benjamin Tissoires
[ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ]
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in
From: Benjamin Tissoires
[ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ]
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in
From: Benjamin Tissoires
[ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ]
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in
From: Benjamin Tissoires
[ Upstream commit 7dd8db68949a7acc5bd528ee0ecb8f8720f49921 ]
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in
On Fri, 12 Oct 2018, Benjamin Tissoires wrote:
> If userspace only reads the trackstick node, and no one is listening to
> the touchpad nor the hidraw node then, the device is not powered on.
>
> Add open/close callbacks to allow users to disable the touchpad in Gnome
> while keeping the
On Fri, 12 Oct 2018, Benjamin Tissoires wrote:
> If userspace only reads the trackstick node, and no one is listening to
> the touchpad nor the hidraw node then, the device is not powered on.
>
> Add open/close callbacks to allow users to disable the touchpad in Gnome
> while keeping the
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in Gnome
while keeping the trackstick active.
Link:
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in Gnome
while keeping the trackstick active.
Link:
* Pavel Machek <pa...@ucw.cz> [180508 21:53]:
> Hi!
>
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
>
> > AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_s
* Pavel Machek [180508 21:53]:
> Hi!
>
> I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
>
> > AT+CNMI=?
> < +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
> < OK
> ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string(
Hi!
I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
of
Hi!
I have problems with incoming SMS. ofono tries to use +CNMI=1,2,2,1,0
> AT+CNMI=?
< +CNMI: (0,1,2),(0,1,2,3),(0,2),(0,1,2),(0,1)
< OK
ofonod[3070]: drivers/atmodem/sms.c:build_cnmi_string()
ofonod[3070]: drivers/atmodem/sms.c:construct_ack_pdu()
> AT+CNMI=1,2,2,1,0
< OK
of
From: Sowmini Varadhan <sowmini.varad...@oracle.com>
[ Upstream commit 10beea7d7408d0b1c9208757f445c5c710239e0e ]
Each time we get an incoming SYN to the RDS_TCP_PORT, the TCP
layer accepts the connection and then the rds_tcp_accept_one()
callback is invoked to process the incoming conn
From: Sowmini Varadhan
[ Upstream commit 10beea7d7408d0b1c9208757f445c5c710239e0e ]
Each time we get an incoming SYN to the RDS_TCP_PORT, the TCP
layer accepts the connection and then the rds_tcp_accept_one()
callback is invoked to process the incoming connection.
rds_tcp_accept_one() may
hen we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed b
)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed because the consequences
hen we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed b
)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed because the consequences
hen we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed b
)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed because the consequences
hen we are in tcp_v4(6)_reqsk_send_ack(), we are replying
to an incoming segment from tcp_check_req() that failed the seq-number
checks.
Thus, to find the correct key, we need to use the skb's saddr and not
the daddr.
This bug seems to have been there since quite a while, but probably got
unnoticed b
1 - 100 of 435 matches
Mail list logo
