* Request for reviews for 4.4-st42, 4.4-cip77
@ 2023-07-05 8:58 Ulrich Hecht
2023-07-09 19:50 ` Pavel Machek
0 siblings, 1 reply; 4+ messages in thread
From: Ulrich Hecht @ 2023-07-05 8:58 UTC (permalink / raw)
To: pavel@denx.de, cip-dev@lists.cip-project.org
Hi!
Here are the manual backports for the upcoming 4.4-st42 and 4.4-cip77 releases that should be reviewed, and that can currently be found in https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-st-rc
trivial backports:
** m | 61256d2d6 None o+ | netfilter: nft_dynset: do not reject set updates with NFT_SET_EVAL
** m | 42ca9589c 138906 o | USB: core: Add routines for endpoint checks in old drivers
** m | 72197f21d b8c75e o | media: dvb-core: Fix kernel WARNING for blocking operation in wait_event*()
** m | 66e262ad9 280a8a o | media: dvb-core: Fix use-after-free due to race condition at dvb_ca_en50221
** m | 22fb46cc1 2474e0 o+ | tty: serial: fsl_lpuart: use UARTCTRL_TXINV to send break instead of UARTCTRL_SBK
** m | 1a5353475 fb686c o | btrfs: check return value of btrfs_commit_transaction in relocation
** m | ff0e8ed8d 85f02d o | btrfs: unset reloc control if transaction commit fails in prepare_to_relocate()
** m | 1ba0925b4 b6ebaa o | xen/blkfront: Only check REQ_FUA for writes
** m | 2b88ccb93 50d927 o | ocfs2: fix use-after-free when unmounting read-only filesystem
** m | 6f40a2503 7651e2 + | IB/isert: Fix possible list corruption in CMA handler
** m | 5304616a6 48bfd0 . | drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
slightly more interesting backports with non-trivial differences in context:
** m | 4e0dbab57 None o+ | netfilter: nf_tables: do not allow SET_ID to refer to another table
** m | 6119cae79 5c34c0 F+ | power: supply: bq27xxx: Fix bq27xxx_battery_update() race condition
** m | 3bd7816c9 efb6b5 o+ | usb: gadget: f_fs: Add unbind event before functionfs_unbind
** m | 4bb5329c7 1e5c64 o+ | rfs: annotate lockless accesses to sk->sk_rxhash
** m | b221b7189 409e87 o | ceph: fix use-after-free bug for inodes when flushing capsnaps
Thank you!
CU
Uli
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Request for reviews for 4.4-st42, 4.4-cip77
2023-07-05 8:58 Request for reviews for 4.4-st42, 4.4-cip77 Ulrich Hecht
@ 2023-07-09 19:50 ` Pavel Machek
2023-07-10 16:47 ` [cip-dev] " Ulrich Hecht
[not found] ` <17708F7C47443676.32062@lists.cip-project.org>
0 siblings, 2 replies; 4+ messages in thread
From: Pavel Machek @ 2023-07-09 19:50 UTC (permalink / raw)
To: Ulrich Hecht; +Cc: pavel@denx.de, cip-dev@lists.cip-project.org
[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]
Hi!
> Here are the manual backports for the upcoming 4.4-st42 and 4.4-cip77 releases that should be reviewed, and that can currently be found in https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.4.y-st-rc
>
> trivial backports:
>
a| 61256d2d6 None o+ | netfilter: nft_dynset: do not reject set updates with NFT_SET_EVAL
Usual marking is "Commit xxx upstream.", this one has [ xxx ].
a | 42ca9589c 138906 o | USB: core: Add routines for endpoint checks in old drivers
a | 72197f21d b8c75e o | media: dvb-core: Fix kernel WARNING for blocking operation in wait_event*()
a | 66e262ad9 280a8a o | media: dvb-core: Fix use-after-free due to race condition at dvb_ca_en50221
a | 22fb46cc1 2474e0 o+ | tty: serial: fsl_lpuart: use UARTCTRL_TXINV to send break instead of UARTCTRL_SBK
a | 1a5353475 fb686c o | btrfs: check return value of btrfs_commit_transaction in relocation
a | ff0e8ed8d 85f02d o | btrfs: unset reloc control if transaction commit fails in prepare_to_relocate()
a | 1ba0925b4 b6ebaa o | xen/blkfront: Only check REQ_FUA for writes
a | 2b88ccb93 50d927 o | ocfs2: fix use-after-free when unmounting read-only filesystem
a | 6f40a2503 7651e2 + | IB/isert: Fix possible list corruption in CMA handler
a | 5304616a6 48bfd0 . | drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
> slightly more interesting backports with non-trivial differences in context:
a | 4e0dbab57 None o+ | netfilter: nf_tables: do not allow SET_ID to refer to another table
Again, usual marking is "Commit xxx upstream.", this one has [ xxx
]. And.. no this is not trivial backport.
a | 6119cae79 5c34c0 F+ | power: supply: bq27xxx: Fix bq27xxx_battery_update() race condition
a | 3bd7816c9 efb6b5 o+ | usb: gadget: f_fs: Add unbind event before functionfs_unbind
a | 4bb5329c7 1e5c64 o+ | rfs: annotate lockless accesses to sk->sk_rxhash
a | b221b7189 409e87 o | ceph: fix use-after-free bug for inodes when flushing capsnaps
So... all seems to be good.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [cip-dev] Request for reviews for 4.4-st42, 4.4-cip77
2023-07-09 19:50 ` Pavel Machek
@ 2023-07-10 16:47 ` Ulrich Hecht
[not found] ` <17708F7C47443676.32062@lists.cip-project.org>
1 sibling, 0 replies; 4+ messages in thread
From: Ulrich Hecht @ 2023-07-10 16:47 UTC (permalink / raw)
To: cip-dev, Pavel Machek
Thanks for the reviews!
> On 07/09/2023 9:50 PM CEST Pavel Machek <pavel@denx.de> wrote:
> a| 61256d2d6 None o+ | netfilter: nft_dynset: do not reject set updates with NFT_SET_EVAL
>
> Usual marking is "Commit xxx upstream.", this one has [ xxx ].
That's how the commits come in from stable. Are we using that in an automated way anywhere? If not, I'd rather not spend time fixing stuff like that.
CU
Uli
^ permalink raw reply [flat|nested] 4+ messages in thread
* Upstream hash format in commit messages; was: Re: [cip-dev] Request for reviews for 4.4-st42, 4.4-cip77
[not found] ` <17708F7C47443676.32062@lists.cip-project.org>
@ 2023-08-01 15:24 ` Ulrich Hecht
0 siblings, 0 replies; 4+ messages in thread
From: Ulrich Hecht @ 2023-08-01 15:24 UTC (permalink / raw)
To: cip-dev, Pavel Machek
> On 07/10/2023 6:47 PM CEST Ulrich Hecht <uli@fpond.eu> wrote:
> > On 07/09/2023 9:50 PM CEST Pavel Machek <pavel@denx.de> wrote:
> > a| 61256d2d6 None o+ | netfilter: nft_dynset: do not reject set updates with NFT_SET_EVAL
> >
> > Usual marking is "Commit xxx upstream.", this one has [ xxx ].
>
> That's how the commits come in from stable. Are we using that in an automated way anywhere? If not, I'd rather not spend time fixing stuff like that.
[For those playing along: Off-list discussion revealed that there are indeed automated ways in which these things are used, so we need to fix them in some way.]
I have come across the following variations in the previous and the next release:
[ Upstream commit {hash} ]
commit {hash} upstream.
Upstream commit: {hash}
[ {hash} ]
(cherry picked from upstream {hash})
(backported from upstream {hash})
Which one of those work, and which need to be fixed up?
CU
Uli
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-08-01 15:25 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-05 8:58 Request for reviews for 4.4-st42, 4.4-cip77 Ulrich Hecht
2023-07-09 19:50 ` Pavel Machek
2023-07-10 16:47 ` [cip-dev] " Ulrich Hecht
[not found] ` <17708F7C47443676.32062@lists.cip-project.org>
2023-08-01 15:24 ` Upstream hash format in commit messages; was: " Ulrich Hecht
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox