On Tue, 2014-12-16 at 16:51 +0100, Bart Van Assche wrote: > On 12/15/14 19:25, Vasu Dev wrote: > > On Mon, 2014-12-15 at 16:22 +0100, Bart Van Assche wrote: > >> Hello Vasu, > >> > >> Every now and then I receive an e-mail from an FCoE user who runs an > >> older kernel reporting an issue that was fixed by the patches that were > >> accepted upstream in kernel 3.13 (see also > >> http://thread.gmane.org/gmane.linux.scsi.open-fcoe.devel/12132). > > > > Hi Bart, > > > > The link is to your patches series applied earlier this year and not > > about any reported issues with older kernels. I don't know why one would > > report issues to you and not to open-fcoe.org with older stable kernels. > > Am I missing such reports and how can we have them on open-fcoe also ? > > Hello Vasu, > > If someone creates a setup with a Linux FCoE initiator and a target > system based on SCST and something does not work as expected usually a > bug report is sent to the scst-devel mailing list without figuring out > first which side was causing the unexpected behavior. An example can be > found on http://sourceforge.net/p/scst/mailman/message/33130107/. >
I've seen CC to open-fcoe from both target (SCST & TCM) mails lists for an fcoe specific issue and I think target maintainer should CC to open-fcoe once cause is ruled out of their target core and open-fcoe not already on the email thread by issue reporter. > > However that doesn't mean one would not run into any issue fixed > > upstream while using older stable kernel w/o that fix, so critical > > fixes should be CCed for stable kernel proactively but up to which > > older kernels version ? I don't recall any specific policy for that > > on either open-fcoe or linus-scsi, if any such linux-scsi policy then > > we could consider that as well. Do you know what is the policy on > > linux-scsi ? > > I'm not sure but I think for linux-scsi everyone who posts a patch must > decide himself whether or not that patch should be included in stable > kernels by adding "Cc: <[email protected]>" in the patch itself. > Yes that was my understanding also beside that I have seen stable kernel maintainer Greg KH making call to pick fixes for stable kernel/s. I think we should continue to use same process as used for linux-scsi since now open-fcoe kernel patches are also generated directly against linux-scsi gits. > >> This > >> made me wonder what the policy is for sending patches to the stable tree > >> ? The list of patches I would like to see being sent to the stable tree > >> is as follows (tested on top of kernel v3.10.62): > > > > Looks fine to apply these patches to older 3.10 if someone really wants > > to use that specific v3.10.62 kernel. > > > > I verified all these are in latest v3.18 kernel since these patches > > dates back in 2013 with top and bottom patches in the list as: > > > > commit e0335f67a281cb8eb11868e614ee9390fbbe9b1d > > Author: Mark Rustad <[email protected]> > > Date: Sat May 18 04:01:36 2013 +0000 > > libfc: Reject PLOGI from nodes with incompatible role > > > > > > commit 55d0ac5d2839fe270cea02fad44eed13750a0efd > > Author: Neil Horman <[email protected]> > > Date: Tue Oct 8 23:43:58 2013 +0000 > > fcoe: Fix missing mutex_unlock in fcoe_sysfs_fcf_add error path > > > > You may also want to include patches from your link above and possibly > > some more missing for 3.10 stable, so if possibly then better for user > > to move to v3.18 which has all recent fcoe fixes in it. > > Agreed that moving to a more recent kernel would be the best option. > However, it is a concern to me is that RHEL 7 is based on kernel 3.10. > Maybe the RHEL maintainers keep an eye on which patches are sent to the > stable branch and sending the relevant patches to the stable tree helps > to get these patches included in RHEL 7 ? Yes RHEL maintainers sync with patches on their releases beside there are times they have applied fcoe fixes to their maintenance updates thru their z-stream. Intel also helps distros (RHEL, SLES ..) to identify pending fixes and getting in sync with their releases but that is all out side open-fcoe working primary scope. Open-fcoe is for upstream only and likewise the case with any other Linux subsystems/drivers upstream work. Thanks Bart for the discussion and I hope this will help all understand open-fcoe process better. Vasu > > Bart. > _______________________________________________ fcoe-devel mailing list [email protected] http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
