New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not rebase the rpi-3.12.y branch #584
Comments
Yes, the plan is to only merge the stable repo, but to rebase the future ones. |
tSed
pushed a commit
to tSed/buildroot-2
that referenced
this issue
May 4, 2014
Upstream has been playing evil-rebase on their tree, so they now no longer have the changeset we are currently referencing. They have now agreed to merge instead of rebasing: raspberrypi/linux#584 So, update the raspberrypi_defconfig to use a new changeset that currently exists right _now_, in the hope it will not disapear in the future (but we'll catch it pretty fast anyway, so we'll be able to seriously bug up upstream in that case ;-) ). Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr> Signed-off-by: yann.morin.1998@free.fr Cc: Jeremy Rosen <jeremy.rosen@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
3.12.y has just been updated to 3.12.19 with a merge. |
philenotfound
pushed a commit
to philenotfound/buildroot-cr15wi
that referenced
this issue
Sep 23, 2014
Upstream has been playing evil-rebase on their tree, so they now no longer have the changeset we are currently referencing. They have now agreed to merge instead of rebasing: raspberrypi/linux#584 So, update the raspberrypi_defconfig to use a new changeset that currently exists right _now_, in the hope it will not disapear in the future (but we'll catch it pretty fast anyway, so we'll be able to seriously bug up upstream in that case ;-) ). Reported-by: Jeremy Rosen <jeremy.rosen@openwide.fr> Signed-off-by: yann.morin.1998@free.fr Cc: Jeremy Rosen <jeremy.rosen@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
popcornmix
pushed a commit
that referenced
this issue
Oct 22, 2018
When sctp_wait_for_connect is called to wait for connect ready for sp->strm_interleave in sctp_sendmsg_to_asoc, a panic could be triggered if cpu is scheduled out and the new asoc is freed elsewhere, as it will return err and later the asoc gets freed again in sctp_sendmsg. [ 285.840764] list_del corruption, ffff9f0f7b284078->next is LIST_POISON1 (dead000000000100) [ 285.843590] WARNING: CPU: 1 PID: 8861 at lib/list_debug.c:47 __list_del_entry_valid+0x50/0xa0 [ 285.846193] Kernel panic - not syncing: panic_on_warn set ... [ 285.846193] [ 285.848206] CPU: 1 PID: 8861 Comm: sctp_ndata Kdump: loaded Not tainted 4.19.0-rc7.label #584 [ 285.850559] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 285.852164] Call Trace: ... [ 285.872210] ? __list_del_entry_valid+0x50/0xa0 [ 285.872894] sctp_association_free+0x42/0x2d0 [sctp] [ 285.873612] sctp_sendmsg+0x5a4/0x6b0 [sctp] [ 285.874236] sock_sendmsg+0x30/0x40 [ 285.874741] ___sys_sendmsg+0x27a/0x290 [ 285.875304] ? __switch_to_asm+0x34/0x70 [ 285.875872] ? __switch_to_asm+0x40/0x70 [ 285.876438] ? ptep_set_access_flags+0x2a/0x30 [ 285.877083] ? do_wp_page+0x151/0x540 [ 285.877614] __sys_sendmsg+0x58/0xa0 [ 285.878138] do_syscall_64+0x55/0x180 [ 285.878669] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This is a similar issue with the one fixed in Commit ca3af4d ("sctp: do not free asoc when it is already dead in sctp_sendmsg"). But this one can't be fixed by returning -ESRCH for the dead asoc in sctp_wait_for_connect, as it will break sctp_connect's return value to users. This patch is to simply set err to -ESRCH before it returns to sctp_sendmsg when any err is returned by sctp_wait_for_connect for sp->strm_interleave, so that no asoc would be freed due to this. When users see this error, they will know the packet hasn't been sent. And it also makes sense to not free asoc because waiting connect fails, like the second call for sctp_wait_for_connect in sctp_sendmsg_to_asoc. Fixes: 668c9be ("sctp: implement assign_number for sctp_stream_interleave") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
popcornmix
pushed a commit
that referenced
this issue
Nov 4, 2018
[ Upstream commit c863850 ] When sctp_wait_for_connect is called to wait for connect ready for sp->strm_interleave in sctp_sendmsg_to_asoc, a panic could be triggered if cpu is scheduled out and the new asoc is freed elsewhere, as it will return err and later the asoc gets freed again in sctp_sendmsg. [ 285.840764] list_del corruption, ffff9f0f7b284078->next is LIST_POISON1 (dead000000000100) [ 285.843590] WARNING: CPU: 1 PID: 8861 at lib/list_debug.c:47 __list_del_entry_valid+0x50/0xa0 [ 285.846193] Kernel panic - not syncing: panic_on_warn set ... [ 285.846193] [ 285.848206] CPU: 1 PID: 8861 Comm: sctp_ndata Kdump: loaded Not tainted 4.19.0-rc7.label #584 [ 285.850559] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 285.852164] Call Trace: ... [ 285.872210] ? __list_del_entry_valid+0x50/0xa0 [ 285.872894] sctp_association_free+0x42/0x2d0 [sctp] [ 285.873612] sctp_sendmsg+0x5a4/0x6b0 [sctp] [ 285.874236] sock_sendmsg+0x30/0x40 [ 285.874741] ___sys_sendmsg+0x27a/0x290 [ 285.875304] ? __switch_to_asm+0x34/0x70 [ 285.875872] ? __switch_to_asm+0x40/0x70 [ 285.876438] ? ptep_set_access_flags+0x2a/0x30 [ 285.877083] ? do_wp_page+0x151/0x540 [ 285.877614] __sys_sendmsg+0x58/0xa0 [ 285.878138] do_syscall_64+0x55/0x180 [ 285.878669] entry_SYSCALL_64_after_hwframe+0x44/0xa9 This is a similar issue with the one fixed in Commit ca3af4d ("sctp: do not free asoc when it is already dead in sctp_sendmsg"). But this one can't be fixed by returning -ESRCH for the dead asoc in sctp_wait_for_connect, as it will break sctp_connect's return value to users. This patch is to simply set err to -ESRCH before it returns to sctp_sendmsg when any err is returned by sctp_wait_for_connect for sp->strm_interleave, so that no asoc would be freed due to this. When users see this error, they will know the packet hasn't been sent. And it also makes sense to not free asoc because waiting connect fails, like the second call for sctp_wait_for_connect in sctp_sendmsg_to_asoc. Fixes: 668c9be ("sctp: implement assign_number for sctp_stream_interleave") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello!
Since you've now declared rpi-3.12.y to be the new stable [0], this is now used by automatic builders such as Buildroot. To get reproducible builds, Buildroot uses a sha1 (often the HEAD when we test it) in that rpi-3.12.y branch (we previously did so with the previous stable, rpi-3.10.y).
It worked so far with rpi-3.10.y, because you were merging linux-stable into the rpi-3.10.y branch. But now, with rpi-3.12.y, you are rebasing the branch onto the linux-stable branch. This means that it is no longer possible to use a sha1, and we have to use the branch name. This is not good, as we can not get reproducible builds.
Would it be possible that you revert to merging linux-stable in rpi-3.12.y, instead of rebasing, please?
Thanks! :-)
Regards,
Yann E. MORIN.
[0] http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=75895
The text was updated successfully, but these errors were encountered: