On Wed, Oct 28, 2020 at 3:47 PM Kees Cook wrote:
>
> On Wed, Oct 28, 2020 at 12:18:47PM +0100, Camille Mougey wrote:
> > (This is my first message to the kernel list, I hope I'm doing it right)
>
> 1- self-confinement
> 2- launching external processes
> a) cooperating
> b)
On Wed, Oct 28, 2020 at 12:18:47PM +0100, Camille Mougey wrote:
> (This is my first message to the kernel list, I hope I'm doing it right)
Looks good to me! The key was CCing real people. ;)
> From my understanding, there is no way to delay the activation of
> seccomp filters, for instance
On Wed, Oct 28, 2020 at 7:35 PM Rich Felker wrote:
> On Wed, Oct 28, 2020 at 07:25:45PM +0100, Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 6:52 PM Rich Felker wrote:
> > > On Wed, Oct 28, 2020 at 06:34:56PM +0100, Jann Horn wrote:
> > > > On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> >
On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey wrote:
> > You're just focusing on execve() - I think it's important to keep in
> > mind what happens after execve() for normal,
On Wed, Oct 28, 2020 at 6:52 PM Rich Felker wrote:
> On Wed, Oct 28, 2020 at 06:34:56PM +0100, Jann Horn wrote:
> > On Wed, Oct 28, 2020 at 5:49 PM Rich Felker wrote:
> > > On Wed, Oct 28, 2020 at 01:42:13PM +0100, Jann Horn wrote:
> > > > On Wed, Oct 28, 2020 at 12:18 PM Camille Mougey
> > >
er->id], i);
> - dma->chan = of_dma_request_slave_channel(disp->dev->of_node,
> - dma_channel_name);
> + dma->chan = dma_request_chan(disp->dev, dma_channel_name);
> if (IS_ERR(dma->chan
ue.c
index 42c8ad10d75eb..a367584f0d7b3 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -573,8 +573,8 @@ static int k3_udma_glue_cfg_rx_flow(struct
k3_udma_glue_rx_channel *rx_chn,
/* request and cfg rings */
ret = k3_ringacc_request_rings_p
From: Mike Snitzer
[ Upstream commit 681cc5e8667e8579a2da8fa4090c48a2d73fc3bb ]
It is unnecessary to force request-based DM to call into bio-based
dm_submit_bio (via indirect disk->fops->submit_bio) only to have it then
call blk_mq_submit_bio().
Fix this by establishing a request-ba
events
> > > + * Master-read : both IS_S_RX_EVENT_SHIFT and
> > IS_S_RD_EVENT_SHIFT
> > > + *events or only IS_S_RD_EVENT_SHIFT
> > > + */
> > > + if (status & BIT(IS_S_RX_EVE
The pull request you sent on Sun, 25 Oct 2020 13:37:45 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-5.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0746c4a9f3d37caf73fb93420bcf34a841019a40
Thank you!
--
Deet-doot-dot, I am a
Linus,
I2C has a regression fix which should go into rc1 and to stable kernels
as well.
Please pull.
Thanks,
Wolfram
The following changes since commit d76913908102044f14381df865bb74df17a538cb:
Merge tag 'block-5.10-2020-10-24' of git://git.kernel.dk/linux-block
(2020-10-24 12:46:42
X_EVENT_SHIFT and
> IS_S_RD_EVENT_SHIFT
> > + * events or only IS_S_RD_EVENT_SHIFT
> > + */
> > + if (status & BIT(IS_S_RX_EVENT_SHIFT) ||
> > + status & BIT(IS_S_RD_EVENT_SHIFT)) {
> > + /* disable slave interrupt
sp->dev->of_node,
-dma_channel_name);
+ dma->chan = dma_request_chan(disp->dev, dma_channel_name);
if (IS_ERR(dma->chan)) {
dev_err(disp->dev, "failed to request dma channel\n");
Hello,
syzbot found the following issue on:
HEAD commit:9ff9b0d3 Merge tag 'net-next-5.10' of git://git.kernel.org..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=140e3e7850
kernel config: https://syzkaller.appspot.com/x/.config?x=d13c3fa80bc4bcc1
The pull request you sent on Wed, 21 Oct 2020 14:54:11 +0200:
> git://www.linux-watchdog.org/linux-watchdog.git tags/linux-watchdog-5.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f804b3159482eedbb4250b1e9248c308fb63b805
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Wed, 21 Oct 2020 08:55:00 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-5.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b5df4b5c28b232d1fc0b48660f44668faebb0bcb
Thank you!
--
Deet-doot-dot, I am a
Hi Linus,
Please pull the watchdog changes for the v5.10 release cycle.
This series contains:
* Add Toshiba Visconti watchdog driver
* it87_wdt: add IT8772 + IT8784
* several fixes and improvements
The output from git request-pull
Linus, everyone,
during this short break of my holidays, I send the first pull request of
I2C for 5.10. Main changes:
* if a host can be a client, too, the I2C core can now use it to emulate
SMBus HostNotify support (STM32 and R-Car added this so far)
* also for client mode, a testunit has
Since the introduction of 'BT_TAG_ITER_STARTED' by commit 602380d28e28
("blk-mq: add blk_mq_all_tag_iter"), the bt_tags_for_each() is not only
used for started request, e.g., in below case:
blk_mq_hctx_has_requests()
-> blk_mq_all_tag_iter()
-> __blk_mq_all_tag
De Mr Armand AGBO
Je suis Mr Armand AGBO de nationalitй bйninoise, gestionnaire de compte dans
une institution bancaire. Je vous prie de m'excuser pour cette intrusion
inattendue de ma part car c'est suite а une recherche via internet que j'ai
trouvй votre contact et aprиs avoir parcouru votre
From: Shuo Liu
An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
For each User VM, there is a shared 4-KByte memory region used for I/O
requests
> Subject: [PATCH 11/13] remoteproc: Properly deal with detach request
>
> This patch introduces the capability to detach a remote processor that has
> been attached to or booted by the remoteproc core. For that to happen a
> rproc::ops::detach() operation need to be available.
> Subject: [PATCH 10/13] remoteproc: Properly deal with a stop request when
> attached
>
> This patch introduces the capability to stop a remote processor that has been
> attached to by the remoteproc core. For that to happen a rproc::ops::stop()
> operation need to be availabl
status & BIT(IS_S_RX_EVENT_SHIFT) ||
> > + status & BIT(IS_S_RD_EVENT_SHIFT)) {
> > + /* disable slave interrupts */
> > + val = iproc_i2c_rd_reg(iproc_i2c, IE_OFFSET);
> > + val &= ~iproc_i2c->slave_int_mask;
> > +
FFSET);
> + val &= ~iproc_i2c->slave_int_mask;
> + iproc_i2c_wr_reg(iproc_i2c, IE_OFFSET, val);
> +
> + if (status & BIT(IS_S_RD_EVENT_SHIFT))
> + /* Master-write-read request */
> + iproc_i2c->s
On Mon, Oct 12, 2020 at 3:42 PM Ingo Molnar wrote:
>
>
> * Sedat Dilek wrote:
>
> > Hi,
> >
> > yesterday, I saw Ingo tagged "locking-urgent-2020-10-11" in tip Git.
> >
> > Did you drop it or was this for Linux v5.9 final and the git-pull
&g
On Mon, Oct 12, 2020 at 3:42 PM Ingo Molnar wrote:
>
>
> * Sedat Dilek wrote:
>
> > Hi,
> >
> > yesterday, I saw Ingo tagged "locking-urgent-2020-10-11" in tip Git.
> >
> > Did you drop it or was this for Linux v5.9 final and the git-pull
&g
* Sedat Dilek wrote:
> Hi,
>
> yesterday, I saw Ingo tagged "locking-urgent-2020-10-11" in tip Git.
>
> Did you drop it or was this for Linux v5.9 final and the git-pull
> request was simply forgotten?
>
> Just curious.
So I ran the pull reques
Hi,
yesterday, I saw Ingo tagged "locking-urgent-2020-10-11" in tip Git.
Did you drop it or was this for Linux v5.9 final and the git-pull
request was simply forgotten?
Just curious.
Regards,
- Sedat -
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tag/?h=locking-u
before processing control request and return error if it is
NULL.
Signed-off-by: Vijayavardhan Vennapusa
Signed-off-by: Jack Pham
Signed-off-by: rickyniu
---
drivers/usb/gadget/function/f_accessory.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/function/f_accessory.c
#syz fix: net_sched: check error pointer in tcf_dump_walker()
Handle single or multi byte master read request with or without
repeated start.
Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave
mode")
Signed-off-by: Rayagonda Kokatanur
---
drivers/i2c/busses/i2c-bcm-iproc.c | 215 +++--
1 fi
This series of patches adds the following,
- Handle master abort error
- Fix support for single/multi byte master read request with/without
repeated start.
- Handle rx fifo full interrupt
- Fix typo
Rayagonda Kokatanur (6):
i2c: iproc: handle Master aborted error
i2c: iproc: handle only slave
The pull request you sent on Sat, 10 Oct 2020 20:28:52 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/da690031a5d6d50a361e3f19f3eeabd086a6f20d
Thank you!
--
Deet-doot-dot, I
Linus,
here a some more driver bugfixes for I2C. Including a revert - the
updated series for it will come during the next merge window.
Please pull.
Thanks,
Wolfram
The following changes since commit 549738f15da0e5a00275977623be199fbbf7df50:
Linux 5.9-rc8 (2020-10-04 16:04:34 -0700)
rote:
> > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > > > do nothing for i915. Because i915 doesn't request any regions, like
> > > > pretty much all drm pci drivers. I guess this is some very old
> > > > remnants from the
y
> > > do nothing for i915. Because i915 doesn't request any regions, like
> > > pretty much all drm pci drivers. I guess this is some very old
> > > remnants from the userspace modesetting days, when we wanted to
> > > co-exist with the fbdev driver. Which usually r
On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > do nothing for i915. Because i915 doesn't request any regions, like
> >
On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> do nothing for i915. Because i915 doesn't request any regions, like
> pretty much all drm pci drivers. I guess this is some very old
> r
On Thu, Oct 08, 2020 at 09:00:21PM +0800, Wen Yang wrote:
> After the process exits, the following three dentries still refer to the pid:
> /proc/
> /proc//ns
> /proc//ns/pid
>
> https://bugzilla.kernel.org/show_bug.cgi?id=208613
>
> According to the commit f333c700c610 ("pidns: Add a limit on
When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
do nothing for i915. Because i915 doesn't request any regions, like
pretty much all drm pci drivers. I guess this is some very old
remnants from the userspace modesetting days, when we wanted to
co-exist with the fbdev driver
I am sorry for interrupting your day, with due respect trust and humility, I
write to you this proposal, which I believe would be of great interest to you.
I am looking for a reliable and capable partner that will assist my family and
I to transfer funds to his personal or company account for
After the process exits, the following three dentries still refer to the pid:
/proc/
/proc//ns
/proc//ns/pid
https://bugzilla.kernel.org/show_bug.cgi?id=208613
According to the commit f333c700c610 ("pidns: Add a limit on the number of
pid namespaces"), if the pid cannot be released, it may
Hi Bjorn,
On Wed, Oct 07, 2020 at 10:43:14AM -0500, Bjorn Helgaas wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=209321
>
> Not much detail in the bugzilla yet, but apparently this started in
> v5.8.0-rc1:
>
> DMAR: [DMA Read] Request device [03:00.0] PASID f
https://bugzilla.kernel.org/show_bug.cgi?id=209321
Not much detail in the bugzilla yet, but apparently this started in
v5.8.0-rc1:
DMAR: [DMA Read] Request device [03:00.0] PASID fault addr fffd3000
[fault reason 06] PTE Read access is not set
Currently assigned to Driver/PCI
Once the driver gets sync_reset_request from firmware it prepares for the
coming reset and sends acknowledge.
After getting this event the driver expects device reset, either it will
trigger PCI reset on sync_reset_now event or such PCI reset will be
triggered by another PF of the same device. So
Hello,
syzbot found the following issue on:
HEAD commit:22fbc037 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=133731eb90
kernel config: https://syzkaller.appspot.com/x/.config?x=4e672827d2ffab1f
syzbot has bisected this issue to:
commit 0fedc63fadf0404a729e73a35349481c8009c02f
Author: Cong Wang
Date: Wed Sep 23 03:56:24 2020 +
net_sched: commit action insertions together
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12c2065790
start commit: 2172e358 Add
syzbot has found a reproducer for the following issue on:
HEAD commit:2172e358 Add linux-next specific files for 20201002
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12ba75ff90
kernel config:
The pull request you sent on Sat, 3 Oct 2020 07:32:34 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f35c08e0bb9dfab1bb5b9c244149bcb150bebf67
Thank you!
--
Deet-doot-dot, I
Linus,
some more driver fixes from I2C.
Please pull.
Thanks,
Wolfram
The following changes since commit ba4f184e126b751d1bffad5897f263108befc780:
Linux 5.9-rc6 (2020-09-20 16:33:55 -0700)
are available in the Git repository at:
I am sorry for interrupting your day, with due respect trust and humility, I
write to you this proposal, which I believe would be of great interest to you.
I am looking for a reliable and capable partner that will assist my family and
I to transfer funds to his personal or company account for
On 9/30/2020 11:36 AM, Thomas Gleixner wrote:
On Tue, Sep 15 2020 at 16:28, Dave Jiang wrote:
+#define INT_HANDLE_IMS_TABLE 0x1
+int idxd_device_request_int_handle(struct idxd_device *idxd, int idx,
+ int *handle, enum idxd_interrupt_type
irq_type)
Once the driver gets sync_reset_request from firmware it prepares for the
coming reset and sends acknowledge.
After getting this event the driver expects device reset, either it will
trigger PCI reset on sync_reset_now event or such PCI reset will be
triggered by another PF of the same device. So
On Tue, Sep 15 2020 at 16:28, Dave Jiang wrote:
>
> +#define INT_HANDLE_IMS_TABLE 0x1
> +int idxd_device_request_int_handle(struct idxd_device *idxd, int idx,
> +int *handle, enum idxd_interrupt_type
> irq_type)
New lines exist for a reason and this glued
@ struct apu_request {
__u8 data[0];
};
+struct apu_iommu_mmap {
+ __u32 fd;
+ __u32 da;
+};
+
/* Send synchronous request to an APU */
#define APU_SEND_REQ_IOCTL _IOW(0xb7, 0x2, struct apu_request)
#define APU_GET_NEXT_AVAILABLE_IOCTL _I
From: Julien STEPHAN
In order to improve performances and flexibility,
add support of async request.
Signed-off-by: Julien STEPHAN
Signed-off-by: Alexandre Bailon
---
drivers/rpmsg/apu_rpmsg.c | 208 ++---
include/uapi/linux/apu_rpmsg.h | 6 +-
2 files
I am sorry for interrupting your day, with due respect trust and humility, I
write to you this proposal, which I believe would be of great interest to you.
I am looking for a reliable and capable partner that will assist my family and
I to transfer funds to his personal or company account for
On Sun 27-09-20 09:07:02, Takashi Iwai wrote:
> On Sat, 26 Sep 2020 22:48:15 +0200,
> syzbot wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:98477740 Merge branch 'rcu/urgent' of git://git.kernel.org..
> > git tree: upstream
> > console output:
syzbot has bisected this issue to:
commit 58956317c8de52009d1a38a721474c24aef74fe7
Author: David Ahern
Date: Fri Dec 7 20:24:57 2018 +
neighbor: Improve garbage collection
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d3167590
start commit: 12450081 libbpf: Fix
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev
and after this change.
=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12#22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16#23
L2CAP: Connection Re
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia
From: Mike Snitzer
[ Upstream commit 6ba01df72b4b63a26b4977790f58d8f775d2992c ]
Partitioned request-based devices cannot be used as underlying devices
for request-based DM because no partition offsets are added to each
incoming request. As such, until now, stacking on partitioned devices
would
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia
and after this change.
=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12#22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16#23
L2CAP: Connection Re
and after this change.
=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12#22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16#23
L2CAP: Connection Re
and after this change.
=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12#22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16#23
L2CAP: Connection Re
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia
From: Zeng Tao
[ Upstream commit b872d0640840018669032b20b6375a478ed1f923 ]
The vfio_pci_release call will free and clear the error and request
eventfd ctx while these ctx could be in use at the same time in the
function like vfio_pci_request, and it's expected to protect them under
the vdev
From: Alex Williamson
[ Upstream commit 5c5866c593bbd444d0339ede6a8fb5f14ff66d72 ]
The next use of the device will generate an underflow from the
stale reference.
Cc: Qian Cai
Fixes: 1518ac272e78 ("vfio/pci: fix memory leaks of eventfd ctx")
Reported-by: Daniel Wagner
Reviewed-by: Cornelia
and after this change.
=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12#22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16#23
L2CAP: Connection Re
ct either the host cap is not implemented or there
> may be firmware specific issues. Firmware version is
> QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
>
> qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> quirk, then the host capability request does get
Hello,
syzbot found the following issue on:
HEAD commit:92ab97ad Merge tag 'sh-for-5.9-part2' of git://git.libc.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13d29c0390
kernel config: https://syzkaller.appspot.com/x/.config?x=ffe85b197a57c180
Hello,
syzbot found the following issue on:
HEAD commit:805c6d3c Merge branch 'fixes' of git://git.kernel.org/pub/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15dfd07590
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
Hello,
syzbot found the following issue on:
HEAD commit:307eea32 dt-bindings: net: renesas,ravb: Add support for r..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=13b7e29d90
kernel config: https://syzkaller.appspot.com/x/.config?x=240e2ebab67245c7
On Sat, 26 Sep 2020 22:48:15 +0200,
syzbot wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:98477740 Merge branch 'rcu/urgent' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1793087590
> kernel
Hello,
syzbot found the following issue on:
HEAD commit:98477740 Merge branch 'rcu/urgent' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1793087590
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
according to the spec.
Here's some btmon traces.
//--- Without Patch ---//
> ACL Data RX: Handle 256 flags 0x02 dlen 24 #58 [hci0] 21.570741
L2CAP: Configure Request (0x04) ident 5 len 16
Destination CID: 64
Flags: 0x
Option: Unknown (0x10) [mandat
irmware version is
> > > QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
> > >
> > > qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > > quirk, then the host capability request does get accepted,
> > > but we run into fatal "m
Hi Archie,
> When receiving an L2CAP_CONFIGURATION_REQ with an unknown config
> type, currently we will reply with L2CAP_CONFIGURATION_RSP with
> a list of unknown types as the config param. However, this is not
> a correct format of config param.
>
> As described in the bluetooth spec v5.2, Vol
qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > quirk, then the host capability request does get accepted,
> > but we run into fatal "msa info req rejected" error and
> > WiFi interface doesn't come up.
> >
> > Attempts are being made to debug
be firmware specific issues. Firmware version is
> > > QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
> > >
> > > qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > > quirk, then the host capability request does get accepted,
> >
On Fri, Sep 25, 2020 at 02:54:47PM +0300, Oded Gabbay wrote:
> Hello Greg,
>
> This is habanalabs second pull request for the merge window of kernel 5.10.
> It contains an important fix to our ASIC reset flow and a few other minor
> changes. Details are in the tag.
>
Hello Greg,
This is habanalabs second pull request for the merge window of kernel 5.10.
It contains an important fix to our ASIC reset flow and a few other minor
changes. Details are in the tag.
Thanks,
Oded
The following changes since commit 9eb29f2ed95edda511ce28651b1d7cdef3614c12:
Merge
ct either the host cap is not implemented or there
> may be firmware specific issues. Firmware version is
> QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1
>
> qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> quirk, then the host capability request does get accep
From: Archie Pusaka
When receiving an L2CAP_CONFIGURATION_REQ with an unknown config
type, currently we will reply with L2CAP_CONFIGURATION_RSP with
a list of unknown types as the config param. However, this is not
a correct format of config param.
As described in the bluetooth spec v5.2, Vol
syzbot has found a reproducer for the following issue on:
HEAD commit:12450081 libbpf: Fix native endian assumption when parsing..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=17fedf8b90
kernel config:
On Tue, Sep 22, 2020 at 07:08:37PM +0300, Oded Gabbay wrote:
> Hello Greg,
>
> This is habanalabs pull request for the merge window of kernel 5.10. It
> contains many small improvements to common and GAUDI code. Details are in
> the tag.
>
> Thanks,
> Oded
>
> The
Hello Greg,
This is habanalabs pull request for the merge window of kernel 5.10. It
contains many small improvements to common and GAUDI code. Details are in
the tag.
Thanks,
Oded
The following changes since commit 8fd0e2a6df262539eaa28b0a2364cca10d1dc662:
uio: free uio id after uio file
I am sorry for interrupting your day, with due respect trust and humility, I
write to you this proposal, which I believe would be of great interest to you.
I am looking for a reliable and capable partner that will assist my family and
I to transfer funds to his personal or company account for
AHLSWMTPLZ-1
> >
> > qcom,snoc-host-cap-8bit-quirk didn't help. If I use this
> > quirk, then the host capability request does get accepted,
> > but we run into fatal "msa info req rejected" error and
> > WiFi interface doesn't come up.
> >
>
>
Hello,
syzbot found the following issue on:
HEAD commit:70b97111 bpf: Use hlist_add_head_rcu when linking to local..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1375823d90
kernel config: https://syzkaller.appspot.com/x/.config?x=7e0ca96a9b6ee858
Hello,
syzbot found the following issue on:
HEAD commit:325d0eab Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=128d4dd990
kernel config: https://syzkaller.appspot.com/x/.config?x=b12e84189082991c
dashboard
The pull request you sent on Sat, 19 Sep 2020 18:02:06 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8d1a46f943877c08d1154a6f90f43a245a671cf
Thank you!
--
Deet-doot-dot, I
Linus,
here is another bunch of fixes for I2C. Only Jean's i801 patch is a
cleanup on top of Volker's i801 patch, but it will make dependency
handling much easier if those two go together.
Please pull.
Thanks,
Wolfram
The following changes since commit
701 - 800 of 18873 matches
Mail list logo