Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • X xcap-capability-linux
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • xcap
  • xcap-capability-linux
  • Repository
Switch branch/tag
  • xcap-capability-linux
  • net
  • mac80211
  • mesh_pathtbl.c
Find file BlameHistoryPermalink
  • Pavel Emelyanov's avatar
    mac80211: Fix sleeping allocation under lock in mesh_path_node_copy. · 8566dc3f
    Pavel Emelyanov authored May 07, 2008
    
    
    The mesh_path_node_copy() can be called like this:
    mesh_path_add
     `- write_lock(&pathtbl_resize_lock); /* ! */
     `- mesh_table_grow
         `- ->copy_node
               `- mesh_path_node_copy
    
    thus, the GFP_KERNEL is not suitable here.
    
    The acceptable fix, I suppose, is make this allocation GPF_ATOMIC -
    the mpath_node being allocated is 4 pointers, i.e. this allocation
    is small enough to survive even under a moderate memory pressure.
    Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
    Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    8566dc3f

Replace mesh_pathtbl.c

Attach a file by drag & drop or click to upload


Cancel
GitLab will create a branch in your fork and start a merge request.