Robert Love wrote:
> On Mon, 2009-10-19 at 17:17 -0700, Robert Love wrote:
>> I've pulled out the obvious fixes from fcoe-next and applied them to
>> fcoe-fixes (scsi-rc-fixes based) and will mail them to linux-scsi for
>> the current RC phase. I then rebased fcoe-next to fcoe-fixes and applied
>> the remaining patches.
>>
>> While testing the updated series I could not get the stack to work with
>> the highmem patch. I'm not convinced that there's anything wrong with
>> the patch, it may just be exposing something else. I've removed it from
>> the tree until I can root-cause the issue I'm seeing. Other than that
>> all patches in both trees have passed my tests.
>>
> BTW: The problem was not in the highmem patch. The problem was that in
> fc_ct_fill() we were filling out the FC4 types (line 135 below), which
> we shouldn't have been.
>
> 131 case FC_NS_RPN_ID:
> 132 ct = fc_ct_hdr_fill(fp, op, sizeof(struct
> fc_ns_rn_id));
> 133 hton24(ct->payload.rn.fr_fid.fp_fid,
> 134 fc_host_port_id(lport->host));
> 135 ct->payload.rft.fts = lport->fcts;
> 136 put_unaligned_be64(lport->wwpn,
> &ct->payload.rn.fr_wwn);
> 137 break;
>
> The highmem patch introduced skb cloning and when assigning the FC4
> types we were overwriting the reference count on the skb shared data.
>
> This line is removed in the "libfc: RPN_ID is obsolete and unnecessary"
> so as long as the highmem patch is after RPN_ID removal everything is
> fine.
>
> //Rob
Good find. A copy/paste bug, I guess.
I submitted a patch to delete that same line
in the RNN_ID case, but that was after RPN_ID had been removed.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
